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

----

Originally posted on J_K9@Linux.

Comments?

That's a nice set of scripts. Thanks.

Too many people don't realize that PHP input has to be hardened else the entire server can be compromised. I have a handful of scripts I have written for myself and keep in a library, but some of these are better than what I have written for myself, so I think I'll start using them.

Actually, I tend to approach it a bit differently than these scripts. These scripts clean up an input string, like from a form, while I just assume that an input string from a form that has invalid characters or codes in it is from a bad guy, and I drop the input. To that end, my scripts test for bad things and return true if found, false if not.

For instance, I verify form fields with this function, to prevent email relaying:

Where appropriate, I will do an eregi("('|\")",$ourstr);
in order to prevent sql injection attacks. Have to be careful there though because in comment fields quotes are perfectly OK.

Adding another take on filtering: PHP Input Filtering Library, don't forget to read the discussion (OWASP seems gets stuck halfway through the filtering idea), then go up one level and maybe check out topics like "Requested PHP Security Patches"...

Thanks unSpawn - as discussed in that article, the OWASP filters aren't perfect, but they can be put to good use by inexperienced and experienced programmers alike. Actually, Andrew van der Stock, OWASP's Executive Director, left a comment on my post saying that the filters are going to be updated soon, so I'm looking forward to the new version

Another article which pertains to this discussion is one by Jeremiah Grossman on the benefits of both input validation and output filtering. It's well worth the read.

Interesting reading but I would have put this thread (as well as the firefox one) in a not-only-linux part of LQ (Programming for example)
In general cases, it has nothing to do with Linux or any OS.
Nice content still. PHP is very often used to do harm and it is more complicated than it seems to secure it.
Thank you.

PHP guys rocks, I love this programing language!

Filters are now implemented in a native way, that´s wonderfull:
http://www.php.net/manual/pt_BR/ref.filter.php

[]´s, FMC!

Yea the problem is the colleges and universities... they don't focus on real world problems such as performance and security.

They focus on academic neatness and theoretical elegance which doesn't prepare people for the real world.

Nothing is a panacea for defensive coding practices.

You can't fix naivety with some functions.

There should be 4 levels(each being taught across 2 semesters) of required code security courses for CS and IS majors starting in the first year with philosophies such as default deny etc.

Right now the only way to learn this stuff is with osmosis and hard knocks, which isn't exactly great for your career.

-Viz

I take it there's some association between security and inelegant hacked-together solutions? Don't hate on schools for teaching "theoretical elegance" - IMHO there isn't enough of it being taught! Rather, how about we focus instead on how there is a lack of focus on common security issues in many classes (about which you *are* correct). Though it may not be the epidemic we should all fear; at least as of several years ago the teaching assistants at Purdue greatly enjoyed taking off points for programs which failed to properly and safely handle invalid input. Still, at some smaller universities I have witnessed a complete lack of concern surrounding security issues. Maybe it comes from some misconception that by using the right libraries you have nothing to fear, as these are the same schools which insist on using Java for everything. To be sure, there's a lot to be learned by writing everything yourself, and watching somebody else find a way to bend it to do their bidding.

I remember I used a php script called "SQuery" that had RFI vulnerability and I someone started to send ALOT of fraud emails through my host...
thanks for this useful post