The Exakat.io blog has a post with an interesting method for preventing the execution of multiple instances of a script at once - locking execution with an external indicator (like files, semaphores and streams/sockets).

Like everything, it all started from a simple problem : how to prevent multiple PHP scripts at the same time. And turned into an odyssey of learning, full of evil traps and inglorious victories. In the end, it works, that’s the most satisfying and it possibly matters to no one except me. But "the way is the goal", as said Confucius, so, I decided to share the various findings.

Exakat runs in command line, and it uses a graph database. The database is central to the processing, and it is crucial to avoid running several scripts at the same time : they will write over each other. So, the problem is simple : preventing several instances to run at the same time, on the database. In commandline, there is no web server that may serve as common place between scripts, sharing some memory and implementing a locking system. It requires to use another common ground : the system.

He shares some of the methods he tried to help prevent the simultaneous execution of the Exakat process including:

• file locking using flock
• creating a "lock" file
• making it "crash proof"
• using semaphores
• using a socket for the lock

He describes some of the issues he found when running the tool using locking inside of a Docker container and, finally, the use of sockets and streams to place a "hold" until the script closes (also preventing issues on a crash). He ends the post talking about the "final boss" in his battle for locking support - the handing off of the socket connection to another process between parent and child. The final list in the post is a list of each method he tried, their benefits and downsides (but only in certain situations).

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.

Anthony Ferrara has written up a new post to his site looking at efective use of CSRF tokens and a few different strategies for generating them.

There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

While not specific to PHP, security is something that all developers need to think about in their applications. To that end, the Infosec Institute has published this guide to helping you prevent SQL injection attacks that could come in via the HTTP headers of requests to your site.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren’t they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

• X-Forwarded-For
• User-agent
• Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

On PHPClasses.org today they've posted their latest "Lately in PHP" podcast - episode 21, "Is PHP Source Quality really Good or is it still Insecure?".

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).

Dave Marshall has a new post to his blog showing one method for defending against cache stampedes from assaulting your caching servers and (possibly) bringing them down.

I’ve recently had a problem with a rather large operation (that could probably be optimised considerably, but nevermind), where by if the cached result of the operation expired, several web server threads would attempt the operation, causing some major headaches for our database and web servers. This is something I’ve come across before, and is commonly(?) known as a Cache Stampede. This is bad, this post describes the basics of what I’ve done to deal with it.

His example uses a Zend_Cache interface to Memecache, but it could be applied in other places too. His method uses a binary semaphore to check and see if there's a "lock" and sleep for a bit before checking again. Sample code is included showing how to create this system and how to refresh the data with a new expiration on a cache miss.

When it comes to limiting the spam that comes through on your site (usually on the open comments), a CAPTCHA can do some of the best work. It provides a good alternative to convoluted techniques for restricting the commenting system of your site, and does it in a simple, easy for a human to use, kind of system. Implementing them, however, can be a bit tricky, so this new article on Dublish.com is here to help.

The article steps you through the creation of the single-script functionality to generate the image. It's an image with a series of random characters on a gradient background created with the GD libraries. The code used in the CAPTCHA is stored in a session variable for validation later. He adds a few graphical touches to make it look a bit nicer, and finishes off with an example of its use.

When it comes to limiting the spam that comes through on your site (usually on the open comments), a CAPTCHA can do some of the best work. It provides a good alternative to convoluted techniques for restricting the commenting system of your site, and does it in a simple, easy for a human to use, kind of system. Implementing them, however, can be a bit tricky, so this new article on Dublish.com is here to help.

The article steps you through the creation of the single-script functionality to generate the image. It's an image with a series of random characters on a gradient background created with the GD libraries. The code used in the CAPTCHA is stored in a session variable for validation later. He adds a few graphical touches to make it look a bit nicer, and finishes off with an example of its use.