.comment-link {margin-left:.6em;}
Xavier's Security Post
Tuesday, September 20, 2005
  some thoughts on web security (PHP)
Even before the whole register_globals mess, sites were being exploited in many more ways than one. And it seems to me that although there has been plenty of public disclosure, discussion, and finally penetration due to the carelessness in development, many PHP developers seem to lack coding practices that are needed to avoid the common security holes in todays web-based software.

There is a lot of documentation out there that site developers could use to improve upon their own coding practices -- but what perplexes me is that somehow after all the years of penetration, and people losing their jobs, and data being stolen, or data being destroyed, the situation stays the same. There are potentially millions of sites out there with some kind of security hole, from the highest level (code execute) to the lowest (sensitive data/path disclosure).

So, what is the solution?

Finding a solution for the problem will not be easy, because no matter what the situation; people will make mistakes. Proper coding practice must be established. Manuals, whitepapes, tutorials, books, ebooks, any document of any sort that discusses web development especially via an interpreted language like PHP, should contain valid examples of how to set variables and execute things properly, even in the case of PHP's register_globals being turned ON.

Open Source projects that rely on interpreted languages like PHP for example should be audited from the get go before any public releases are made. There should be some sort of public organization that with the assistance of several security-minded folks, can queue standard security audits via automation and finally before acceptance will audit the code manually to make sure nothing slipped through. Such an organization could be used to not only discover holes before they reach the public domain, but also educate the developers and the public about strange and odd vulnerabilities that might arise.

I understand that there are too many projects going on, and some projects are extremely large and may take some serious time to audit. But I'm sure a structure can be put together to handle the stress. Look at OSVDB, they have an interesting setup where vulnerabilities will be passed along a group of security-minded individuals who will research the said vulnerability in the noted software, and to an extent either audit the software or verify the vulnerabilities are present.

Also, besides education and community wide auditing I also think that a warning system inside of PHP would be nice. I refer not to its exception handling, nor its error reporting but to a function that'll evaluate the code and disclose a warning to developers (during debugging most preferably) if any security flaws are possible.

Here is an example of a session between a developer and the PHP interpreter:

Server A has register_globals = ON. And safe mode is turned OFF.
Then, the developer writes something like the following:

... other code here ...

if ($GoingToBeIncluded) {
include($GoingToBeIncluded)
}
... other code here ...

PHP before executing evaluates this code, and brings up the red flag about possible remote inclusion vulnerabilities. It can also suggest a solution, in case the developer is a bit mature. A solution to the code above would be to assign the variable to an empty string, if its not meant to actually be executed maliciously.

I'm thinking such evaluation can be done within the scope of the lint function already within the PHP language. I bet it'll be a pain in someones ass to code, though. :)
 
Comments: Post a Comment



<< Home
This public blog will be a place for me to output any Security findings, both technological and physical, that I have come about. I will post Security advisories I was apart of, and also other interesting bits of knowledge. email: xavier [at] tigerteam.se

RECENT RELEASES
Rocks Clusters <=4.1 mount-loop local root
Rocks Clusters <=4.1 umount-loop local root
TSEAD-200606-6 - Rocks Clusters <=4.1 local root
xorgmodroot.py - Xorg-server 1.0 / <=X11R6.9.0-7.0 local root
TSEAD-200509-5 - Multiple Netscape.com vulnerabilities.
TSEAD-200512-3 - Multiple vulnerabilities in KISBG <=v5.1.1
fsigk_exp.py - FSIGK for Linux <=2.10-431 local root
TSEAD-200510-4 - FSIGK for Linux <=2.10-431 advisory
ritk.php - remote inclusion pentest tool
owm_exp.py - openwebmail <=2.51+ local root
perliodebug_exp.py - perlIO_debug 5.8.* local root
bankfix.py - bank card number lookup tool
TSEAD-200412-2 - AOL XSS/file read vuln
TSEAD-200412-1 - AOL redir vuln

ARCHIVES
September 2005 / October 2005 / November 2005 / December 2005 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / September 2006 / October 2006 /