Last week at the BlackHat security conference, a new attack on SSL secured content was unveiled. This attack is called BREACH, and has been generating a lot of buz on the internet. Tech blogs have been plastering their sites with articles about how there’s no fix, and how you can try to defend against BREACH. Well respected security people have been writing about it.

And I’m here to say don’t worry about it.

At the current point in time there exists a very significant SQL Injection vulnerability in the WordPress code base. I want to make it abundantly clear that this does not affect anyone using WordPress “off the shelf”. It only is exploitable if you use certain WordPress code outside of a WordPress install. So this is not a very “attackable” vulnerability. Or to put it in other terms, this is a high level vulnerability which has a very low threat level. It is also worth noting that it has not been fixed by WordPress (even 90 days after disclosure).

In the April issue of the PHPArch magazine (also published on her blog), Elizabeth Tucker Long wrote a really interesting editorial piece coining a concept she called Security-Driven-Development. She (quite correctly) identified a problem in the current development community where security has become an after-thought (if it’s thought of at all). This isn’t a new concept, in fact it’s a concept that I and many others have been preaching for quite a while now. However I’ve been coming to realize that I’ve had it wrong the whole time. And I think the entire industry is getting it wrong today.

It’s been a little while since I’ve posted anything here or on YouTube. I’ve been working on some interesting ideas that hopefully will be pretty decent, so it wasn’t time wasted. But I figured now would be a good time to tell you about some upcoming speaking engagements that I have, and where I’ll be over the next few months. So with no further adue:

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.

Today, I’m doing a talk at PHP Benelux 13 on Password Storage and Attacking in PHP. Here are the slides for that talk, as well as the accompanying GitHub repo that I use throughout the talk. When the videos are posted, I’ll make a followup post that links to it. Without rambling on further, click through for the links!

There are numerous articles on the web about how to properly use bcrypt in PHP. So this time, rather than write yet-another-how-to-use-bcrypt article, I’m going to focus on the mistakes that are commonly made when implementing bcrypt. So, let’s dive right in:

The fourth video in the Programming With Anthony series is live! In this video, we’ll explore the basic principles of prepared statements, and why you should use them instead of using escaped input directly in queries.

The other day, PHP 5.5 Alpha 1 was released to the public for the first round of testing the new features that are coming out. One of those new features is the Simplified Password Hashing API that I proposed (and was accepted). I have received a lot of feedback and criticism of the new API in the months since it’s been committed. I figured now that Alpha 1 is out and people can play with it, I should respond to some of those items, and give a little bit more insight into why it was built the way it was…

Almost two years ago I had stumbled upon a pretty significant vulnerability in the StackExchange network. I say stumbled, because I wasn’t actually trying to attack the site. Circumstance just showed me a door. The actual attack is pretty interesting, and it holds a lesson for everybody who builds or maintains websites or server infrastructure. So here’s the story on how I hacked StackOverflow…