A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written

Josh — Wed, 24 Feb 2010 02:30:16 +0000

I've spent a lot of time over the past few months writing an enterprise application in PHP. Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code. Anyway, I'm at the point in my development lifecycle where I decided that it was ready to run an application vulnerability scanner against it. What I found was interesting and I think it's worth sharing with you all.

Let me preface this by saying that I'm the guy who gives the training to our developers on the OWASP Top 10, writing secure code, etc. I'd like to think that I have a pretty good handle on programming best practices, input validation, and HTML encoding. I built all kinds of validation into this application and thought that the vulnerability scan would come up empty. For the most part I was right, but there was one vulnerability, one flaw in particular, that found it's way into every form in my application. In fact, I realized that I've made this exact same mistake in almost every PHP form that I've ever written. Talk about a humbling experience.

So here's what happened. I created a simple page with a form where the results of that form are submitted back to the page itself for processing. Let's assume it looks something like this:

<html>
 <body>
  
  <form action="">
   <input type="hidden" name="submitted" value="1" />
   <input type="submit" value="Submit!" />
  form>
 body>
html>

It looks fairly straightforward, right? The problem has to do with that $_SERVER['PHP_SELF'] variable. The intent here is that PHP will display the path and name of the current page so that the form knows to submit back to the same page. The problem is that $_SERVER['PHP_SELF'] can actually be manipulated by the user. Let's say as the user I change the URL from http://www.webadminblog.com/example.php to http://www.webadminblog.com/example.php">. This will end the form action part of the code and inject a javascript alert into the page. This is the very definition of cross site scripting. I can't believe that with as long as I've been writing in PHP and as long as I've been studying application security, I've never realized this. Fortunately, there are a couple of different ways to fix this. First, you could use the HTML entities or HTML special character functions to sanitize the user input like this:

htmlentities($_SERVER['PHP_SELF]);

htmlspecialchars($_SERVER['PHP_SELF]);

This fix would still allow the user to manipulate the URL, and thus, what is displayed on the page, but it would render the javascript invalid. The second way to fix this is to use the script name variable instead like this:

$_SERVER['SCRIPT_NAME'];

This fix would just echo the full path and filename of the current file. Yes, there are other ways to fix this. Yes, my code example above for the XSS exploit doesn't do anything other than display a javascript alert. I just wanted to draw attention to this issue because if it's found it's way into my code, then perhaps it's found it's way into yours as well. Happy coding!

Coding Secure with PHP – OWASP AppSec NYC 2008

Josh — Wed, 24 Sep 2008 22:34:58 +0000

This presentation was by Hans Zaunere, Managing Member, and it is entitled "PHundamental Security - Ecosystem Review, Coding Secure with PHP, and Best Practices". Take a look at http://www.nyphp.org/phundamentals/ for the ongoing guide and best practices. Guru Stefan Esser recently presented an excellent talk at Zendcon.

Security fundamentals are common across the board. Different environments have different requirements (desktop apps different from web/internet apps). Web/internet have a huge number of touch points. PHP isn't responsible for all of them, but the developer is. Different languages handle in different ways. PHP is no different except "More internet applications speak PHP than any other". PHP gets a bad rap. Low point of entry and great flexibility. There's been some mistakes like weak default configuration, too forgiving for amateurs, the infamous magic_* of PHP, PHP Group argues what's a security flaw.

It's easy to shoot yourself in the foot with C. In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg. - Bjarne Stroustrup, Inventor of C++

Three zones of responsibility. PHP is effectively a wrapper around libraries and data sources. Many external dependencies and touch points.

Poorly written code by amateur developers with no programming background. Primary cause for the security ecosystem around PHP. Laziness - letting PHP do it's magic_*. "Program smart"
Extensions and external libraries. PHP's greatest asset. Sometimes library binding is faulty. Sometimes the external library has faults, or behaves in an unforeseen way when in a web environment - possible in any environment. Know what extensions you're using, use the minimal number of extensions, and be aware of the environment they were originally designed for. "Know thy extensions"
PHP Core - "PHP". Secunia says 19 advisories for PHP between 2003-2008. Java had 38+ and Ruby 11+. "The list goes on - PHP is not alone". One advisory in 2008. "More internet applications speak PHP than any other"

Best Practices

Best practices are common to any well run enterprise environment. PHP is growing into this environment very quickly.
Web security is largely about your data and less about exploits in the underlying platform. Buffer overflows aren't so much the hot-topic.
Installation - Avoid prepackaged installs, including RPMs, .deb, etc. If you use them, review their default deployment. Installation touch points also typically include MySQL/Apache.
Configuration - Use php.ini-recommended. Better yet, take the time to know what you're doing and tune configuration files yourself.
Don't make PHP guess what you mean. Be explicit with variables and types. Don't abuse scope - know where your variables come from. Avoid magic_* and implicitness - BE EXPLICIT.
Keep code small, organized, and maintainable. Use OOP techniques to enforce code execution paths. Use includes to keep things organized.
Don't use super-globals directly - wrap for protection.

Be aggressive - B.E. aggressive

It's always about data
One of PHP's greatest strengths - loosely typed. Also it's biggest weakness. Don't make PHP guess what you mean.
Cast variables, know their type and the data you expect. Let PHP do it's magic only when you want it to - not by chance.
Keep tabs on your data's path, lifecycle and type. Know where it's come from, what it's doing, and where it's going. Filter/escape/cast and throw exceptions every step of the way.
Input validation, output validation, CASTING.
Don't be lazy, be explicit, use OOP.

Casting isn't just for movie producers

No system has a single security pressure point
Don't take the easy way out just because you can
Put PHP in the same well managed enterprise environment as other technologies
PHP/AMP respond very well to TLC

Conclusions

PHP is just part of the ecosystem and there is awareness and experience on the PHP side. The ying/yang of PHP's history overshadows reality. Stand by PHP and it'll stand by you. Web/internet applications are deep and complex. Users, interoperability, data, architecture, support, compliance. Phishing, hijacking, spam, sopcial engineering - BROWSERS!

PHP is the least of your worries

Web Admin Blog » php

A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written

Coding Secure with PHP – OWASP AppSec NYC 2008