Another edition of php|architect has been published. I was especially excited to read this one, because it's Ilia's first month writing Security Corner. It's nice to see a topic explained from a different point of view, and there is still too little interest in security within the PHP community. (In other words, this is a rare opportunity.)

He discusses cross-site request forgeries, an attack first mentioned in php|architect back in 2003. Sadly, it remains one of the most dangerous, yet relatively unknown attacks. It deserves more attention.

I was a bit concerned that Ilia might liken it to cross-site scripting (XSS), because he has in the past:

As far as CSRF, I don't really consider it to be separate from XSS [...] CSRF is a subset of cross site scripting in my opinion.

(I didn't debate this point at the time, because the Myspace worm had caused a fair amount of confusion by combining both attacks, an approach I had been researching). My concern was quickly put to rest:

Closer examination reveals that CSRF and XSS are entirely different beasts.

There are still a few minor points where Ilia and I seem to disagree, but that's the real beauty of having different points of view. Hopefully Ilia will forgive me for it. :-) My points of contention are:

• There are many different attack vectors for CSRF - it's best to find the commonality between them, so you can eliminate the root cause of the problem. Focusing on one attack vector can yield weak solutions.
• An attack can be launched from any web site, so preventing your own site from being a platform for CSRF does not protect you from the attack itself.

In order to explain these items further, I want to share a secret with you. The comment form on my blog is vulnerable to CSRF. No images are allowed, and no XSS vulnerability exists (to my knowledge), but it's still vulnerable. This was a design decision I made when I first decided to allow comments, because:

• I already allow anonymous comments, so there's nothing to gain by forging a request from someone else. In other words, I'm not putting readers at risk.
• I was curious to see whether CSRF's lack of popularity applies to exploits as well as vulnerabilities.

Surprisingly, no one has exploited the vulnerability, despite the fact that there have been a countless number of XSS attempts. That may all change now that I've mentioned it, but when it does, I'll implement a simple and effective safeguard. Can you guess what it is?