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 PatternsA 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 ConsortiumSeems like a start, though I haven't seen much put into place here. However, it's news, and interesting.

Hardened-PHPHardened-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 DevShedThe 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.

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

XSS cheatsheetf 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.

Last edited by jason on Mon Jan 31, 2005 9:08 am, edited 2 times in total.

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.

"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

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 ...

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.

jshpro2 wrote:

Additional steps need to be taken to prevent xss then just htmlentities

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:

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum