No announcement yet.

Is there a problem with clean_array_gpc()?

  • Filter
  • Time
  • Show
Clear All
new posts

  • [Forum] Is there a problem with clean_array_gpc()?

    I've been working on a project that involves sending large blocks of code (PHP, JavaScript, HTML etc) by AJAX to a file that uses filesystem functions (in short, I'm building a replacement for cPanel that goes in the adminCP). The vB_AJAX_Handler sends data only by POST and I want the target PHP file to receive data only by $_POST i.e., $vbulletin->input->clean_array_gpc('p', ......). The problem is all my +'s disappear.

    I assume this is because some url decoding is taking them to be filling in blank spaces in the url and is converting them back to blanks. If I receive data using $_REQUEST ('r' in the usual vB method) the problem goes away. Something seems wrong here -- $_POST data needs to be encoded with encodeURIComponent() before it's sent as a parameter in AJAX but it's my understanding that PHP automatically handles decoding on the receiving end and no further url decoding is necessary. So, if you follow me so far, somewhere what is automatically decoded by PHP is decoded again, wiping out all the real +'s. But as I said earlier, it only happens with $_POST data, not with $_REQUEST

    The upshot is you simply can't use $_POST unless you are certain there aren't any +'s in the data. All through vB coding I see data received by $_REQUEST that I think should be received only by $_POST. This seems to make various kinds of hacking easier, as files can receive data by $_GET.

    Isn't this an avoidable vulnerability?

    Actually none of this matters in my project -- I found out there's some length limit (about 4.5 kb) to strings sent by vB_AJAX_Handler and I had to build my own AJAX handler to handle large param strings. My handler seems to avoid this problem. But then maybe someone could tell me how to get vB_AJAX_Handler to send long strings??? And maybe also how to avoid the + problem?

Related Topics