*These may seem obscure – because they ARE obscure – but they've lasted so long that I've heard of most of them and I'm not even a coder.
*As we rely more on software, these errors get more dangerous because there is more at stake.
*Hackers aren't getting smarter – one might even argue that they're getting sillier, more reckless and more careless – but they are getting more collectively intelligent because they can script-kid through social networking. Also, the body of potential recruits is colossal now. Plus, computer crime pays.
*There's nobody in charge of stitching up these gaping holes in our social fabric. The American Department of Homeland Security can list 'em, but you can bet that their most avid readers (a) aren't within reach of DHS jurisdiction and (b) don't have the best interests of the DHS at heart.
http://cwe.mitre.org/top25/#Listing
(...)
"These days, it seems as if software is all about the data: getting it into the database, pulling it from the database, massaging it into information, and sending it elsewhere for fun and profit. If attackers can influence the SQL that you use to communicate with your database, then suddenly all your fun and profit belongs to them. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security. They could modify the queries to steal, corrupt, or otherwise change your underlying data. They'll even steal data one byte at a time if they have to, and they have the patience and know-how to do so. In 2011, SQL injection was responsible for the compromises of many high-profile organizations, including Sony Pictures, PBS, MySQL.com, security company HBGary Federal, and many others...."
(...)
"Buffer overflows are Mother Nature's little reminder of that law of physics that says: if you try to put more stuff into a container than it can hold, you're going to make a mess. The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. However, copying an untrusted input without checking the size of that input is the simplest error to make in a time when there are much more interesting mistakes to avoid. That's why this type of buffer overflow is often referred to as "classic." It's decades old, and it's typically one of the first things you learn about in Secure Programming 101...."
