Hi Adrián, You're absolutely right. Browsers will take characters with special meaning like the null byte or the percent sign and encode them to prevent mucking up the processes working with the data. As we're entering encoded data, we need to do it in such a way that the browser won't encode it again. One way of doing this, as you mentioned, is to put the data directly in the URL. If the data isn't being submitted as a GET parameter (i.e. in the URL) we can use an intercepting proxy such as Burp Suite to modify the request and include our null byte. It's great to hear feedback about the tool, especially that people like yourself are enjoying it! More challenges are in the works for both SQLol and XMLmao, so stay tuned! Cheers, -- dc

@Lopj Yes, it's what I meant by "if the conditions are right". As I said in a previous comment, this method has gained me code execution in more than one pen test. Trust me, it works. To clarify: The application must allow uploading of .php files to the Web root as executable in a predictable place (or any of the equivalent extensions such as .php3, .php4, .phtml, .phtm...) OR There must be a file inclusion flaw OR If it's on Apache you can provide a double extension such as .php.gif (the gif is not assigned a handler, but it will be used as a mimetype and the .php extension will be used to determine the handling) OR You can upload a .htaccess file which defines .png or some other extension as PHP code Anyway, it's more common than you might think. Developers generally put only one layer of defense against attacks in place, so if they're already checking the image properties to ensure it's an image, they will likely not place restrictions on file extensions. That said, I most commonly find file extension blacklisting used to defend upload scripts so this trick is often not necessary.

@Mike: Here's an example. http://www.cvedetails.com/cve/CVE-2006-2330/ @Thetestmanager: It depends on how the upload script checked. If it is done using HTML attributes, this only controls the browser's behavior. If the size of the file (not the image dimensions) were checked server-side, this attack would not be possible.

@Mike: This particular trick of combining files has gained me code execution on two or three different penetration tests in the past. This is tried and true. In fact, there are even some antivirus systems which will flag PHP code embedded in images. It's also worth noting that this concept extends beyond combining PHP and PNG, there are many more applications for this concept.

@Albinowax Assuming that angle brackets are filtered as well as equals signs and you're injecting into the middle of an HTML tag, I'd look to see if the encoding was specified when the page loads. If not, you could inject UTF-7 characters or some such thing to try to get the browser to interpret the content in a different encoding to bypass the filter (since it's operating on byte values). If that's a no-go too, I think you're SOL unless the attribute you're injecting into is particularly interesting (like the src attribute of an img tag, for instance).