In a new post to his blog Paul Reinheimer talks about replacing sessions with cookies and some of the (security) pitfalls that can come with it.

I've seen several instances where people have demonstrated the ease with which encrypted cookies can replace sessions within PHP. Michael Nitschinger wrote a piece recently demonstrating the switch with Lithium, while CodeIgniter does this by default (optionally encrypting). The problem is that while replacing sessions with cookies works, it introduces a few risks not present with native session support, and these risks tend to be under documented.

He gives an illustration of an attacker who sits between Amazon and one of their warehouses. Despite encrypting their order details, all it would take is the attacker to grab an order and copy it and resend (a "replay attack"). He's created an example application to illustrate the point (source on github). The attacker doesn't even have to know what the encrypted information contains - they only have to replicate it.

In response to some of the comments being made about the hash table Denial of Service attack recently posted Freek Lijten has posted his thoughts about the real problem with the whole situation - how it was handled by the communities involved.

Interesting they may be, but I want to address what in my opinion is the real problem: The way the communication around it was handled by different projects and the fact that the exploit could still exist at all. [...] In the presentation Wälde and Klink talk about their disclosure process. The PHP project had them wait 3 weeks for a first response while this is obviously a serious matter.

He argues that things like a commit message mentioning a DoS prevention fix instead of just mentioning the fix have the potential to do more harm than good. He also points out that other communities were notified of the problem (like Python) and some still haven't responded to the issue.

This attack was the result of good research and it is important that it is disclosed. More importantly however is the fact that organisation got by with years of not noticing it and even worse, reacted very poor after being informed. I can't say I have a ready solution to avoid these kind of things in the future, perhaps that will prove to be an interesting discussion.

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.

They list nine easy things you can do to help prevent the attacks:

• Patch your SQL server regularly
• Limit the use of dynamic queries
• Escape user input
• Store database credentials in a separate file
• Use the principle of least privilege
• Turn magic quotes off
• Disable shells
• Disable any other DB functionality you don't need
• Test your code

In a recent post to his blog Artur Ejsmont looks at an attack that could potentially leave a hole open in your PHP-based application for a cross-site scripting (XSS) attack - HTTP response splitting (mail headers too).

There are two similar security issues both taken care of by Suhosin patch and strict escaping/encoding rules. They both relate to injecting new lines into headers of network protocols. They are not very well known and i think its worth mentioning it. HTTP response splitting is a web based attack where hacker manages to trick the server into injecting new lines into response headers along with arbitrary code. If you use GET/POST parameters in the headers like cookie or location, then someone could provide new lines with XSS attack.

He gives some examples of how it might work via the header function so that superglobals might be abused (like adding information on the URL to inject into $_GET). To prevent the attack, you just have to ensure that no special characters make it into the headers or cookies. He also mentions that the Suhosin patch takes care of the issue automatically.

In a new post to his blog Padraic Brady takes a look at remote timing attacks that happen on a nanosecond scale and whether or not we, as application developers, should take them seriously. Timing attacks involve gleaning information off of systems based on the response and execution time.

I've been following the progress of Remote Timing Attacks with a lot of interest over the years, during which time there has been an obvious trend in improving the technique. The most recent reported cases of Remote Timing Attack vulnerabilities, for example, were against the OpenID and OAuth protocols when it was reported in July 2010 that numerous open source implementations of these protocols did not prevent the disclosure of timing information that could enable a Remote Timing Attack. It is important to note that, as with many potential attacks, the protocols themselves contain no vulnerability. This is strictly a potential vulnerability contingent on the method of implementation.

He starts off by defining timing attacks in a bit more detail, including an example of how an attacker could determine the validity of a username based on the response time of how its handled. He continues on talking about how important the nanosecond is to attacks like this (might as well be minutes) and how things like the C function memcmp can be used to catch these tiny time differences. There's plenty more detail in between, but he finishes the post off with a look at what you can do to help prevent this type of attack from being useful on your applications.

On Kavoir.com there's a new post that reminds you that hashing isn't enough anymore to protect your users and their passwords. They offer a suggestion or two of what you can do to help lock things down a bit more.

The common practice is to hash the user password and store the hash string of the password in the database. When the user tries to log in and supplies his password, it is used to generate a hash string to be compared to the one stored in the database. [...] This approach may be secure in the 70s of the last century, but barely any more.

Computing has evolved enough to where hashed can be matched, sometimes in less than two or three minutes. Their answer to the problem? Generate a random salt each time you create the hash with a constant being used as a base. A code snippet calling a user-defined function and the sha1 function are included.

In this new post to his KillerPHP.com blog Stefan Mischook looks at a few of the basic steps you can take to help prevent SQL injection attacks in your application.

You should protect your relational databases (like MySQL) from the dreaded SQL injection attack. These attacks are conducted by evil sniveling nerds, trying to insert damaging SQL code into your HTML form fields (and query strings too) to do things like drop database tables or even wipe out your database altogether!

There's three things he recommends as good places to start - mysql_real_escape_string, using an ORM layer with its own escaping and using something like PDO that cleans up the input for you.

According to the CyberInsecure.com website around a half-million websites running PHPBB were hacked in a large coordinated effort.

More than half a million websites have been compromised in a new round of attacks that hacked domains in order to infect unsuspecting users' PCs with a variety of trojans. This ongoing campaign includes new malware hosting domains and new trojans variations. All of the sites are running older or misconfigured versions of "phpBB," an open-source message forum manager. Open-source popular applications like phpBB tend to be often targeted by mass scanning and exploiting tools.

The hack redirected visitors through several steps ultimately ending up on a page that tried to take advantage of errors in older Internet Explorer and RealPlayer versions. The article talks about exactly which viruses could have caused the problems and the wide range of sites (both in topic and location) that were effected.

The best way to protect you and your PHPBB install from something like this happening is to get the latest version of the software and learn how to configure it correctly.

Stuart Herbert has posted about a very helpful method server admins can use out there to not only help secure their server but possibly make their web hosting users more happy in the long run - using suphp on a shared server (security).

The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. [...] This has created a gap that a number of third-party solutions have attempted to fill. One of the oldest of these is suphp, created by Sebastian Marsching.

He works through the whole process - the installation (this is all on a Gentoo linux system), configuring for your Apache install, changing Apache to make it work with suphp and finally some benchmarks and parting comments concerning its use.

Matthew McCool has a few reminders for developers out there thinking of using Ajax in your applications - mainly to remember that it has the potential of adding another vulnerability to your application.

Consider a registration form built out of PHP. Any aspect of your script that accepts and processes data is a potential point of attack. If you add Ajax, what you're doing is increasing the complexity of the application and, by extension, introducing greater vulnerability. More points of entry equal a larger attack surface, and that means potential problems for your application.

He continues his login form example and mentions a few things you could do to help protect your application and its users (including using the escaping functions built in to PHP to help remove some harmful input).