J_K9 @ Linux

The Problem With PHP Application Security

January 13, 2007 on 9:40 pm | In Security, PHP |

PHP application security and the vulnerabilities which are often found in PHP apps have already been discussed at length. PHP is a great language, but it suffers in that it provides no simple method of escaping special characters when handling input and thus leaves many budding programmers’ web applications vulnerable to remote file inclusion (RFI) exploits, Cross Site Scripting (XSS), SQL injection and a host of other remote exploitation techniques which may allow the attacker to steal confidential data (such as clients’ credit card details), disrupt services and cause many other problems. These techniques allow the attackers to use the web application to do things it was not originally designed for.

The programmer in question can be blamed to a certain extent for not reading up on how to secure their web application, but the problem is that many new programmers are not aware of the fact that they need to escape and clean the data they receive from the application’s inputs in order to stop it from doing what it was not designed to do. They are probably unaware that such types of attacks exist anyway. However, PHP provides limited, complex and slightly obscure functions to secure input handling which are usually insufficient and lack the functionality required to prevent certain attacks. Worse still, many books and tutorials written to teach people with no previous experience how to code in PHP usually omit secure data handling techniques or tips, and provide examples thoughout the book/tutorial which are vulnerable to the attacks mentioned above! This is irresponsible on the authors’ behalf: it’s no wonder that PHP application vulnerabilities accounted for 43% of the security issues found in 2006.

However, all hope is not lost. The Open Web Application Security Project (OWASP) have produced a set of PHP filters which allow the newest of PHP programmers to secure their input data handling methods. Doing so is a simple as downloading the filters, including them in the web app (with a command such as require_once(’sanitize.inc.php’)), storing the input into a variable and then sanitizing the data as shown on the project’s homepage.

It would be better if the PHP developers added functions such as OWASP’s PHP filters into the PHP code itself and if the authors of PHP instruction material added sections on securing input handling, but these filters are far better than nothing

10 Comments »

RSS feed for comments on this post. TrackBack URI

We have updated filters coming soon, which will bring Stinger levels of input validation, along with:

CSRF library
AntiXSS library with hard core escaping

Keep watching.

Andrew van der Stock
Executive Director, OWASP

Comment by Andrew van der Stock — January 15, 2007 #
Using Safari 419.3 on Mac OS X
Excellent! I’m actually writing a short tutorial at the moment about using your PHP filters to secure user input, which should help those new to PHP to secure their web apps. I’m focusing mainly on the paranoid filter function, but that is too extreme for some situations so I intend to outline the usage and appropriate situations for the other filtering functions.

Thanks for letting me know - I look forward to the updated filters

Comment by J_K9 — January 15, 2007 #
Using Internet Explorer 6.0 on Windows XP
Being a long time PHP programmer I think that the PHP language is a little “tackled” together and this shows:

-creating a common API to allow unified access to both local and remote files feels more like a “cool factor” than a feature which would be useful.

-only the recently released mysqli interface has support for prepared queries (and even that has a braindead interface). Compare this with the perl DBI interface which had support for prepared queries independent of the database driver (because it implements its own SQL parser) since 1991 (that’s right, for more than 15 years)

-what other language is there with an .ini file?

Comment by Cd-MaN — January 28, 2007 #
Using Mozilla Firefox 2.0.0.1 on Ubuntu Linux
It’s me again

I’ve put together a short list which can server as a starting point for securing your PHP code, both from a coder and a sysadmin perspective: http://hype-free.blogspot.com/2007/01/php-coders-of-world-secure-your-code.html

Comment by Cd-MaN — January 28, 2007 #
Using Mozilla Firefox 2.0.0.1 on Ubuntu Linux
I agree, Cd-MaN - I’m not quite sure what the advantages of being able to include remote files is, and why this “feature” would be enabled by default is beyond me.

I’ve just finished coding a login brute force protection system, so I’m hoping to open source the code as soon as I get a chance to clean it up and comment it properly

And thanks for that excellent list - it deserves some exposure, so I suggest you submit it to sites like LinuxSecurity.com and LXer.com. That’ll hopefully allow a few more people to be taught how to secure their code!

Another good article I’ve recently come across is this one: http://www.owasp.org/index.php/PHP_Top_5

Comment by J_K9 — January 28, 2007 #
Using Mozilla Firefox 2.0.0.1 on Windows XP
Pubesent Teens…

Pubesent Teens…

Trackback by Anonymous — April 3, 2008 #
Using Internet Explorer 6.0 on Windows XP
Abigail Fraser Free Hardcore Video…

Abigail Fraser Free Hardcore Video…

Trackback by Anonymous — April 4, 2008 #
Using Internet Explorer 6.0 on Windows XP
Cipro shipping….

Cipro shipping….

Trackback by Cipro shipping. — June 9, 2008 #
Using Unknown browser
Reboxetine….

Vestra reboxetine. Reboxetine edronax. Reboxetine….

Trackback by Vestra reboxetine. — July 18, 2008 #
Using Unknown browser
Actions monitor 1.02….

Monitor computer actions….

Trackback by Monitor computer actions. — November 12, 2008 #
Using Unknown browser