Infosec Pals

One of my biggest pet peeves is arguing with other security experts. I think my main problem is that some hackers in the community get such big ego’s that they are not willing to listen, and believe that they are always in the right, what I call, “old school mentality”. Old school mentality comes from hackers who hung out in IRC channels and heard the questions, “How do I hack”, or “Can you teach me how to hack”, way too many times.

I am digressing a little, so back on subject, The most recent discussion that I had was the following:

I identified a parameter in a web application that was sent to the application server to be rendered. The URL was similar to that below:

http://www.victimssite.com/blah.php?i=“><?php print(997*1009);?>

The inserted code was then ran on the application server and then rendered back to the user. (in this case “1005973″ was printed in the page)

Now, this is where the fight that I mentioned before begins. Some people call this “Server Side Include Vulnerability.” (SSI) Which I hate to tell you is not the case. You can use this vulnerability to cause an SSI Vulnerability, but it in of itself is not what the vulnerability should be identified as.

Standard SSI vulnerabilities are very similar to what you see above, but the payload would look like this:

http://www.victimssite.com/blah.php?i=“><!–#printenv –>

Now, this is doing something different then the previous code presented above. This code would print the environment variables. The difference between the two, is that this code is handled by the web server (Apache) not the application server (PHP).

If the code is truly a Server Side Include, it is handled by the web server, if not it is a “type” of code injection. But my research doesn’t bring up an actual “term” for application handled code injection vulnerability other than “Code Injection”.

Code injection is an umbrella term for many different specific types of vulnerabilities, including SQL Injection, Cross-Site Scripting, OS command injection, and even SSI Vulnerabilities.

I have no idea how this issue should be resolved so that the know-it-all’s will stop calling things by the wrong names. Just my two cents.

Chris Eng has an excellent post on his observations from the PCI community meeting in Toronto. To quote from his blog entry at: http://www.veracode.com/blog/?p=63

Requirement 6.6 of the PCI-DSS becomes mandatory in June 2008 and requires all web-facing applications to either undergo a code review OR be protected by a web application firewall.

For all AppSec companies this could be good fodder, I except to see many ‘code-review on a budget’ offerings. But code review done right is time consuming and expensive, PCI should also provide the option of doing a webapp pen-test from a certified third party. This will help many small-mid size companies be PCI complaint while not hurting their budget.