Automatic escaping has a certain appeal given its goal of removing the need to type escape() all over your templates. Funny thing, though, is that this is basically its one and only advantage. The second claimed goal is to remove a factor of human error (i.e. forgetting to type escape() somewhere), however, this hasn't posed an issue for me in the past where simple analysis of templates can quickly locate such omissions. And no, using automatic escaping does not remove the need to analyse templates for security issues - that's still needed regardless.

He goes on to define what "automatic escaping" is and isn't and how it relates to the context of the information (the same data may not always be filtered the same way in every place). He talks about scope-limited escaping, context-aware escaping and an idea that could help make life easier - a content security policy defining how the client should behave when interpreting HTML.

While it's no harm poking fun at ourselves, in PHP we do have a serious problem. Cross-Site Scripting (XSS) remains one of the most significant classes of security problems afflicting PHP applications. Despite years of education, community awareness and the development of frameworks which can offer a huge boost in consistent practices - things are not getting any better.

So, I finally figured out what the core problem is: PHP programmers are completely clueless about XSS. It's that simple. Instead of going out and studying the topic, we blindly follow some preferred herd of people offering advice with heartfelt conviction despite the fact that they are probably just as ignorant as the rest of us. Does that sound like the behaviour of something which allegedly evolved into an intelligent species? The result is a mix of ignorance and stagnant knowledge that leaves PHP in an unenviable position beset by wrongheaded zealots.

He introduces the htmlspecialchars function and how it has been generally assumed a good method for presenting XSS attacks. He talks about issues with quotes, problems that IE6 seems to have that no one else does and the all-important third parameter of the function (character set detection) and the optional fourth (decoding HTML entities automatically).

He's created this github repository with the examples from the post.

Back in September, Socorro received a security bug relating to the method we were using for processing inputs for the duration of certain reports. The vulnerability included a proof of concept, with an alert box popping up on production when the link was followed. [...] I was quite surprised at the root cause of the vulnerability. We had opted to compare the incoming data against a known set of valid values - a common practice when whitelisting certain inputs. [...] As expected, when this [example] code is tested, a string of '3' and an integer of 3 work equally well, and a string of '5' and an integer of 5 fail equally.

This automatic casting that PHP does internally caused another issue as well - if the string passed in even started with a valid number from their whitelist set, it still passed.

At first we thought this surely had to be a bug in PHP. However, Laura Thomson told me "If comparing two values, type juggling is performed first, which means that the string is converted to a number. This is done by taking the first number found in the string. So this may be confusing/a quirk/a gotcha, but it isn't a bug." And she's right: this isn't a bug per se, but it's certainly an interesting "gotcha."

This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

Cross-Site Scripting (XSS) is a type of attack where a hacker attempts to inject client-side scripting into a webpage that others are able to view. The attack could be as simple as an annoying alert window or as sophisticated as stealing a logged in user's credentials (commonly saved in browser cookies). [...] Since these types of user input can immediately be displayed to other user's, the attack could be spread pretty quickly and even without your knowledge.

He provides a basic function to get you started filtering the input from your users - a "xss_protect" method that takes in the data, whether to strip HTML tags or not and an optional set of allowed tags if you do. He also asks for opinions and better methods in his comments:

No solution is going to be perfect, but at least now you have a head start! If you have ways of improving this function, let myself and everyone else know in the comments.

EllisLabs' news release for CodeIgniter 2.0.2 makes mention of "a small vulnerability". This small vulnerability is mentioned no where else (not even the actual changelog for 2.0.2). In reality, I reported seven distinct vulnerabilities across two classes. These vulnerabilities might allow an attacker to inject arbitrary HTML, CSS or Javascript, i.e. Cross-Site Scripting (XSS) into an application's output.

He gives a list of four recommendations that CodeIgniter 2.0.2 users can take to creating (or updating) their applications including using HTMLPurifier when you need sanitization and ensuring that views and templates from third parties are clear of XSS issues.

Debian has issued an update for php4/5. This fixes some vulnerabilities, which can be exploited by malicious people to conduct cross-site scripting attacks, cause a DoS (Denial of Service), and potentially compromise a vulnerable system.

You can get more information and links to the downloads here:

• PHP4 announcement
• PHP5 announcement

In the post [on Good and Bad PHP Code], he provides a few useful PHP interview questions, including some questions from Yahoo. He explains that good PHP code should be Structured, Consistent, Portable and Secure

In the comments, many additional improvements have been suggested, but there's one that has yet to be mentioned. When using htmlspecialchars() without specifying the character encoding, XSS attacks that use UTF-7 are possible.

Included in the post is an example to illustrate the point as well as a solution, a simple one involving the header() function, to help correct the problem and prevent bad things from happening.

Be sure to check out the comments for more great tips.]]> Wed, 20 Jun 2007 09:35:00 -0500 http://www.phpdeveloper.org/news/7776 http://www.phpdeveloper.org/news/7776 Secunia.com has posted a PHP-related issue that users of the PHPChain application should look into:

r0t has discovered some vulnerabilities in PHPChain, which can be exploited by malicious people to conduct cross-site scripting attacks.

Input passed to the "catid" parameter in settings.php (when "action" is set to "edit") and cat.php is not properly sanitised before it is returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

If a user is logged in and the exploit is in place, the attacker could gain access to the application and gain access to a user's information. The recommended fix is to correct the source code so that the information coming in is correctly sanitized.

rgod has discovered two vulnerabilities in TCExam, which can be exploited by malicious people to conduct cross-site scripting attacks or to compromise a vulnerable system.

The two issues is related to two different inpus not being handled properly - the mishandling of the SessionUserLang cookie and the _SERVER[SCRIPT_NAME] value. Neither of these are being sanitized.

This issue effects users of the TCExam 4.x series but a new version, 4.1.000, has already been released and made available for download.