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 Resonant Core blog has a post today with a selection of tips and techniques you can use to help build secure applications in PHP, preventing several of the most common issues (several as mentioned in the OWASP Top 10).

There are but two causes for the unintentional creation of insecure web applications: A lack of knowledge about security [and] bad development habits. Developers who don't know about the risks involved with writing a widget a certain way are unlikely to make the secure choice. Thanks to the work of MITRE and OWASP, the most common vulnerabilities (and their consequences) are widely known and accessible. However, when teams are under pressure to meet a tight deadline, bad habits and insecure development practices may still emerge.

Most of the examples (at least the solutions) center around a framework they've created (Tuner) but the concepts are all there and could be adapted to other tools easily. They talk about the "pain" that can come with secure coding and how the right tools can make it much easier for the developer. He talks about how the framework offers a better database interface based on PDO and prepared statements to prevent SQL injection issues (with examples for each of the CRUD operations). He also shares a list of pre-existing PHP libraries that can help make the rest of you application secure too including:

The Code Yellow site has recently posted an article pointing out an issue that's all too common in PHP frameworks, more specifically those that bundle some kind of ORM into their functionality. They wonder if your framework is telling you everything about what they're doing to prevent SQL injection.

We've discovered that SQL injection is to this day not a fully solved problem, even in most popular frameworks. In this post, we'll explain how these frameworks fail at escaping parts of a query, culminating in the discovery of a critical vulnerability in the popular Laravel framework which affects a large percentage of applications.

He starts with an illustration using the FuelPHP framework and the protection it offers from garden variety SQL injection attempts. Unfortunately, things start to break down when it gets much past this typical case. They found this same issue to be a wide-spread problem in many PHP frameworks and tools including the Laravel, CodeIgniter and CakePHP frameworks, each with their own ORMs. He also talks about issues with blacklisting and whitelisting and how, sadly, most of the frameworks just don't support it for model data filtering. There's a mention of some of the work they've done to help try and fix the issue (including patches and contacting authors) and some recommendations of how to correctly quote identifiers in SQL statements.

Jani Hartikainen has shared a recommendations to library authors out there - don't make your library exploitable. That is, don't make it, by default, open to common attacks like SQL injection or cross-site scripting.

SQL injection is a pretty big deal. Its cousin shell injection is also a common issue, demonstrated quite well by a recent post to the PHP reddit. Although some suspect it was a troll, I heard echos from a variety of people who had seen pretty much exactly the same vulnerability in production.

This got me thinking: People writing libraries for doing things like shell commands, SQL, etc., don’t actually have to provide an interface that can be easily mis-used. An interface like this could just as easily be based on some other data type besides a plain string, completely side stepping issues caused by concatenation. “What on earth are you talking about?” – Let me explain...

He goes on to talk about more specifically about SQL injection issues (it is still first on the OWASP list after all) and makes a few suggestions to a better API. He points out a lot of it is about little or no education on security-related topics. He also suggests a "SafeSQL" kind of interface that would help prevent some of these common issues using something like Haskell.

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.

Never trust user input! Injection is a threat . You are the new web developer, aren’t you?. Never trust user input is the first rule I had to learn as a web developer in anchient times. Injection can happen whenever user input is interpreted or used to compose new data. A quick recap of the #3 mistake from todays Top 10 MySQL Tips and Mistakes for PHP Developers web presentation. A webinar recording should be available in a couple of days.

He points out a few "don't" things to avoid - like directly injecting superglobal values into your query and to remember that not all SQL injections are because of escaping issues. The real key? Validating input - be sure you're putting values into your query that are of the correct type and contain what you expect.

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.

From the Developer Drive blog there's a recent post with some suggestions on how you can help to prevent SQL injections in your PHP application and make it that much harder for would-be attackers to do what they shouldn't.

Why do SQL injections happen so often?
The shortest answer is that SQL injections are so popular because of poor programming. Hackers know about the potential of a successful SQL injection attack and they search for vulnerabilities. Unfortunately, very often they don’t have to search hard – vulnerabilities pop right in their face. [...] The good news is that fortunately, SQL injections are also relatively easy to prevent.

The materials teach how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas and caveats are included. I discuss why escaping is usually the wrong choice, which practices to avoid or follow and how stored procedures sometimes offer no protection at all.

The presentation (as posted to Slideshare) starts with some of the basics - what SQL injection is and an example of how it could be used to bypass security. He covers how to use prepared statements in each of the technologies (with code snippets), methods for escaping data and how to create stored procedures that are protected from the same threats.

On the Advanced PHP Tutorial site there's a recent post that suggests a few useful functions that can get you started on security and protecting your application from possible exploits. These aren't the only way to prevent these issues, but they're a start in the right direction.

Security is a very important aspect of programming. In PHP, there are few useful functions which is very handy for preventing your website from various attacks like SQL Injection Attack , XSS attack etc.Let’s check few useful functions available in PHP to tighten the security in your project. But note that this is not a complete list, it just list of functions which I found useful for using in your project.