The Paragon Initiative has posted a new tutorial that wants to provide you with everything you need to know about preventing cross-site scripting in PHP applications.

Cross-Site Scripting (abbreviated as XSS) is a class of security vulnerability whereby an attacker manages to use a website to deliver a potentially malicious JavaScript payload to an end user. XSS vulnerabilities are very common in web applications. They're a special case of code injection attack; except where SQL injection, local/remote file inclusion, and OS command injection target the server, XSS exclusively targets the users of a website.

[...] Cross-Site Scripting represents an asymmetric in the security landscape. They're incredibly easy for attackers to exploit, but XSS mitigation can become a rabbit hole of complexity depending on your project's requirements.

He introduces the concept of cross-site scripting (XSS) for those new to the term and provides a brief "mitigation guide" for those wanting to jump to the end. He then gets into some examples of what a XSS vulnerability could look like, both stored and reflected and provides the "quick and dirty" method for preventing them. He also mentions some tips in implementing your solution including avoiding HTML in your data if at all possible. He goes on to talk about the use of HTMLPurifier to prevent attacks, context-sensitive escaping (HTML vs JS vs CSS) and some of the browser-level features that help prevent XSS for the user.

Pádraic Brady has a new post to his blog about the state of output escaping in PHP and the steps that need to be taken to help prevent and protect applications from the real threat of cross-site scripting.

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.

Pádraic Brady has written up an exhaustive guide to using htmlspecialchars correctly and securely in your applications (though it's technically how "not to use it"). This is part one of a series looking at preventing cross-site scripting in PHP applications.

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.

Brandon Savage has a new post to his blog about what he calls a XSS vulnerability in the making, something to watch out for when you're doing validation in PHP involving the possibility of numbers as strings.

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

On the DeveloperDrive.com site there's a recent post anyone wondering about cross-site scripting should give a read. They introduce you to the basic concept and two things you can do to help prevent them.

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.

In a recent post to his blog Jason Stiles takes a look at some of the things you can do with PHP to help protect your site from XSS (cross-site scripting attacks) with some basic filtering.

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.

Padraic Brady has a new post looking at a cross-site scripting issue he came across when working with CodeIgniter 2.0.2 and some fixes and recommendations he has about correcting the situation.

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.

On Secunia.com, two new updates for the Debian linux distribution have been posted - on for PHP4 and the other for PHP5:

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

On Secunia.com, two new updates for the Debian linux distribution have been posted - on for PHP4 and the other for PHP5:

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 this post to his blog, Chris Shiflett talks about some issues surrounding character encoding and the cross-site scripting issues it can open up in your application.

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.