In his most recent post Anthony Ferrara gives a lesson in security prompted by the recent major issue with a SQL injection vulnerability in Drupal. He gets into detail about the vulnerability itself and the ultimate question: "how could this happen?"

Recently, a severe SQL Injection vulnerability was found in Drupal 7. It was fixed immediately (and correctly), but there was a problem. Attackers made automated scripts to attack unpatched sites. Within hours of the release of the vulnerability fix, sites were being compromised. And when I say compromised, I'm talking remote code execution, backdoors, the lot. Why? Like any attack, it's a chain of issues, that independently aren't as bad, but add up to bad news. Let's talk about them: What went wrong? What went right? And what could have happened better? There's a lesson that every developer needs to learn in here.

He details (complete with code examples) where the vulnerability was, how it could be exploited and what the resulting SQL would look like when it was abused. Fortunately, the fix for the issue was relatively simple, but fixing is easy - distributing that fix is much more difficult.

How did this happen? Everyone makes mistakes. Everyone. It's going to happen sooner or later. Heck, this vulnerable code was in the database layer since 2008, and was just discovered two weeks ago. That says something about how complex vulnerabilities can be.

He suggests that the bigger lesson here isn't about who made the mistake or even the code that caused it. It's more about how it was handled, and that, in using any kind of CMS/framework like this there's always risk. People are human, people make mistakes - "the key is how you deal with it".

In his latest post Allan MacGregor talks about something commonly referred to as Swiss Army Knife Syndrome, a common problem in software development where features and functionality are added "just in case" and aren't needed.

The inspiration for the "Swiss Army Knife Syndrome" came from my frustration in dealing with project managers, clients, and even other developers, that think in too much of a narrow, particular way. I call it the "Swiss Army Knife Syndrome". [...] The term 'Swiss Army Knife' is often used to describe a collection of useful items or tools that are able to perform well in multiple scenarios. While this may be useful, there are risks to be aware of as well.

He points out that not only can software with unnecessary features become cumbersome over time, it can also have the potential for being mostly useless (and unmaintainable). He suggests a few ways the syndrome can show up in your process including scope creep, early optimization and anything that assumes that "more features" is the same as "more value" in the product. In his opinion, software with a clear purpose and that does its job well is more valuable that one packed with features, especially ones no one wants to use.

The SitePoint PHP blog has a new post today about the challenges of password hashing and some of the common risks that can come with it. It's a continuation of a previous article about the actual techniques for hashing in PHP.

The fact that the output of a hash function cannot be reverted back to the input using an efficient algorithm does not mean that it cannot be cracked. Databases containing hashes of common words and short strings are usually within our reach with a simple google search. Also, common strings can be easily and quickly brute-forced or cracked with a dictionary attack.

He points to a video demonstrating a method for getting the password data and why just salted hashes aren't a secure method for storing this information. He mentions a "randomness issue" (and PHP's rand function). Instead, he shows an example with openssl_random_pseudo_bytes o pull a chunk of randomized data. He then talks some about password stretching using the PBKDF2 handling in PHP. Finally, he goes past the hashing and gets into encryption, mentioning "password tweaking" as an alternative to generating a single key for every user.

On The Nerdery's blog today there's a new post suggesting that most of the reports of WordPress' insecurity are wrong and they're going to set the record straight.

I have often heard the remark “WordPress is insecure!” My response is “Where did you hear that?” and “When did you hear that?” [...] WordPress core is, in fact, very secure, just as secure as any other Content Management System, just as secure as any other software suite or Operating System. Security issues most often arise from administrators and users. In other words, you are the weakest link.

They suggest that between the high-profile nature of WordPress and the constant (sometimes wrongful) warning being put out there about its security, people perpetuate the message sometimes unknowingly. Besides the human element being the largest risk, they also point out a few others including issues around shared hosting and the availability of easy-to-find tools to exploit flaws. They talk about a brief history of the WP core security and how they define the real security of a product - how quickly it responds to security issues. They also include a few suggestions for you to help harden your own WP installation.

In this new post Snipe looks at something that we, as web developers, don't seem to think about too much when designing our applications and architectures - risk (and how to manage it).

When I talk about risk as it relates to web applications, people usually assume I'm talking about hardening applications from hackers, spammers and other ne'er-do-wells. While malicious attacks are absolutely a non-trivial part of risk management, there's a lot more to it that's just as important.

She introduces some of the basic concepts behind risk management, specifically as it relates to web applications. She points out that it's not always an external threat you'll need to worry about either. Sometimes its your own development group that introduces bugs or something that makes the system come to a crashing halt. She recommends starting all projects "risk first" and include it into your planning process. She shows how to create a "risk matrix" to get insight into the problem and the data that should be on it.

Finally, she reminds you of a few good rules (including "keep your systems simple") and that analyzing risk doesn't have to be a boring process. Figuring out where things will break, how to break them and what happens when they do can be an interesting process.

In this new post to the Zend Developer Zone Cal Evans asks open source projects and companies alike - "what's your bus factor?"

In a previous job I had it was the "Beer Truck" factor (you can see where our heads were) but the common term these days is Bus Factor. Put simply, it's your projects exposure to the risk of key members disappearing tomorrow. To be crude if your project can't survive a key member of your project being hit by a bus tomorrow then you have a very high "Bus Factor".

He points out that it's not just an open source problem, but something that companies should take into consideration as well. Technology groups are especially bad about having single developers consistently working on certain parts of a system. If the time comes that that developer can't do the work (bus, leaves company, etc), how much of an impact will that have? Cal suggests a few ways that it can be avoided including spreading the work around a bit more, moving developers to places in the codebase they don't know and avoiding the "black boxes" created by certain developers.