Jason Gilmore has posted an article to the Easy Laravel Book site with a bit more detail about how the framework prevents some common security issues including SQL injection and cross-site request forgery.

A reader recently e-mailed me and asked about Laravel 5’s native security features. While I talk about various security-related matters throughout the book, this information isn’t consolidated into any particular chapter and so I thought it would be useful to do so in a single blog post. Laravel helps to secure your web application by protecting against three serious security risks: SQL injection, cross-site request forgery, and cross-site scripting.

He goes through each of the types and talks about the built-in functionality Laravel includes to protect against each one. A bit of code is tossed in when needed to help clarify the point too. Fortunately for the user, a good bit of the technical pieces of these protections are behind the scenes and don't need much effort to use.

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 posted a 20 point list that wants to help you prevent cross-site scripting (XSS) issues in your applications.

Summarising knowledge has as much value as writing a 200 page treatise on a topic, so here is a list of 20 brief points you should bear in mind when battling Cross-Site Scripting (XSS) in PHP. Minus my usual book length brain fart . Chances are good that ignoring or acting contrary to any one of these will lead to a potential XSS vulnerability. It’s not necessarily a complete list – if you think something needs to be added, let everyone know in the comments.

His tips include things like:

• Never pass data from untrusted origins into output without either escaping or sanitising it.
• Remember that anything not explicitly defined in source code has an untrusted origin.
• Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
• Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
• Validate all complete URLs if constructed from untrusted data.
• Remember that HTMLPurifier is the only HTML sanitiser worth using.
• Ensure that cookies which must only be transmitted over HTTPS are marked Secure.

He points out that XSS is still one of the most "popular" (and easy to exploit) attack methods out there, so keep these tips in mind when writing up your code.

Gareth Heyes has posted about some bypasses that he's found for getting around the XSS Auditor functionality in some browsers:

I had a look at XSS Auditor for a bit of fun because Mario said it’s getting harder to bypass. Hmmm I don’t agree. I seem to remember the same flaws are present from the last time I checked it with a little variation. It is also a very limited XSS filter not supporting detection of script based attacks (very common).

He includes three of his own bypasses - using a "formaction" on the submit input in a form, using "target" to override the iframe external resource restriction and the injection of a specially placed anchor tag. Each of these comes with a proof-of-concept example and another is also included courtesy of Mario Heiderich.

PHPMaster.com has posted a new article with some high level security tips and reminders for PHP developers when wanting to help prevent issues with their applications. The article provides eight tips, each with a brief description.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

Anson Cheung has posted about some security attacks (six of them) that you need to watch out for when developing your apps.

Be aware of the most common security threats to PHP applications is the important step to secure your PHP scripts may not be immune. Here, the article is going to go over top 6 common security threads in PHP scripts. You may familiar with this, if not, this is a good time for you to read and keep in mind.

The top six on his list are:

• SQL Injection
• Cross-Site Scripting (XSS)
• Session fixation
• Session capturing/hijacking
• Cross-Site Request Forgeries (CSRF)
• Code Injection

For each item, he includes a bit of explanation as to what the issue is and a common solution as to how to prevent it.

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.

In this recent post to Reddit.com, the question of application security is asked - the poster wants recommendations on how he should keep his app safe from would-be attackers:

I can code fairly well in PHP these days, but my security isn't so hot. Is there a tutorial or plugin you guys can recommend as to how I should be protecting my php pages/inputs? I want to avoid common attacks like XSS, inputs with NULL or DROP TABLE etc?

Responses on the post include recommendations related to:

• Using the Chorizo scanner to find common issues in your code
• Using PDO for database connections (with bound parameters)
• Not trusting "$_SERVER"
• Data sanitization

There's also links to a few other resources with more details.

PHPMaster.com has a new tutorial posted today (by George Fekete) about preventing cross-site scripting attacks in your PHP-based applications.

Unfortunately, cross-site scripting attacks occurs mostly, because developers are failing to deliver secure code. Every PHP programmer has the responsibility to understand how attacks can be carried out against their PHP scripts to exploit possible security vulnerabilities. Reading this article, you’ll find out more about cross-site scripting attacks and how to prevent them in your code.

Included in the tutorial is an example with a simple form and definitions of different types of XSS attacks - reflected XSS, persistent XSS and three ways to prevent them: data filtering, output filtering and data validation. He also links to a few "cheatsheets" to help even more (including this guide and a Zend Framework set of XSS test data.

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.