Tag Archives: infosec

Hybrid Security Talk at Better Software Conference West

Better Software Conference West I’m speaking tomorrow at the Better Software Conference West at Caesars Palace in Las Vegas. If you’re going to be at the conference come join in.

The topic is security and I’ll be talking about Hybrid Security Analysis: Bridging the Gap between Inside-Out and Outside-In. The basic idea is how you coordinate and get value from the outside testing like penetration testing and then relate it to development efforts like unit test and static analysis.

If you can’t make the session, feel free to stop by our booth, plus I’m doing one of the Q&A sessions on Thursday at 10:15am as well. Hope to see you there.

SQL Injection Hall of Shame updated

Shameful Eyes Just a reminder for those who aren’t aware – I maintain a list here I like to call the “SQL Injection Hall of Shame“. There was a quiet period at the first of the year, but now we seem to be back at it. I’ve added a couple of updates – one a large breach that was probably SQL injection and one a small one in healthcare that was for sure.

CodeCurmudgeon’s SQL Injection Hall of Shame

Check it out and let me know if I’ve missed any security breaches that you’re aware of.

Resources

SQL Injection is So “2000-and-Late”

Planking p019 © by uvw916a

I’m kind of surprised, or at least disappointed that we are still talking about SQL injection breaches. About a year ago I wrote about SQL Injection and yet it’s still hitting major web sites. For example Hackmageddon has an interesting chart of cyber attacks in June (not just SQL injection). But for me writing about SQL injection feels a bit like writing about planking, it’s so 2000-and-late.

Companies that are losing passwords, especially plain-text passwords via SQL injection are passing from bad-luck to poor-quality to downright negligent. Adrian Lane of Securosis LLC suggest that hearing the same old headlines about it has made it uninteresting. In his words:

SQL injection? Not sexy, but it sure is effective.

The latest entry in the SQL Injection Hall of Shame is Yahoo (YHOO). I’m sure you’ve heard by now about the hundreds of thousands of user email addresses and plain-text password that were stolen from Yahoo using SQL injection. There is much to be learned from this event.

  • SQL injection attacks are completely preventable
  • Using static analysis flow-analysis tools will not catch all security errors
  • Storing plain-text passwords is inexcusable
  • Substandard security can lead to liability

Preventable

Let’s make this really simple. SQL injection is preventable. I like the way Randy Abrams, research director at NSS Labs put it.

The only place we should be seeing SQL injection attacks today is in the classroom, as IT professionals are being trained to prevent such attacks

If SQL injection is getting through your system, you have a process/infrastructure problem. Or maybe a testing problem, but really that’s secondary. I’d go so far as to say if any testing or penetration tools find a SQL injection, see answer number one, you have a process/infrastructure problem. Seriously, if you’re running flow analysis for example and it finds a SQL injection error, don’t just fix that one, address the underlying root problem, IE you’re using unvalidated user input, and fix it everywhere, not just the instances that static flow analysis found.

As long as organizations play hunting games to find SQL injection they will continue to be vulnerable and pay the price. If nothing else learn this, SQL injection as well as other input validation errors are totally preventable, if you’re having problems then you’re doing it wrong.

Catching ALL the errors

Really this concept is just an extension of the previous one. Namely, you need to look at the root cause for SQL injection and put in place a development and testing methodology that requires 100% compliance. In this case as in many other security issues, the root cause is the use of user input that hasn’t been validated. You need to code in such a way that you don’t leave any room for unvalidated input to be used, ever.

Now the trendy thing to do these days is use flow-analysis tools to find “bugs” in software. Disclaimer for those who haven’t figure it out yet, my day job is at Parasoft who is a maker of static and flow analysis tools among other things. The problem is that people frequently misunderstand what flow analysis can do, and then either don’t follow through with what it’s told them, or have a false sense of security that they’ve done all they can.

Both behaviors are incorrect and will lead to vulnerabilities in your software. It’s important to understand that flow analysis isn’t a thorough methodology. It’s somewhat random in that it’s attempting to determine possible paths through your code without human intervention. By it’s nature it will miss things. On the upside it will tell you something you didn’t know about your code without any human effort.

The right response to finding security vulnerabilities in flow analysis isn’t to simply fix the ones found, but rather to ask yourself what the underlying cause is, then create a policy drive programming approach that will negate the possibility of such conditions surviving your development and test efforts.

One more honorable mention in this area is that sometimes people do validation in the client using technologies such as JavaScript. While this is a great way to speed things up and improve the user experience, you need to also validate on the back-end. Remember that the client-side can be subverted, and validation mechanisms bypassed. So use client-side validation as a convenience for the user and an extension of your security, but never in place of back-end validation.

Storing Passwords

STOP storing plain text passwords – immediately! If people forget their passwords, do a reset. They don’t need the old one back, they couldn’t remember it anyway. And make sure you’re salting and putting strong encryption on the passwords. Perhaps the biggest mistake that Yahoo made was
storing usernames and passwords in plain text.

Liability

As I hinted earlier, allowing something so preventable and so well understood to happen to you can get you in trouble. Liability and negligence issues often revolve around issues of common practices. If you’re not preventing SQL injection, someone could try and make the case that you were negligent, as is the case for the recent LinkedIn security breach. There is currently a lawsuit against LinkedIn which claims they didn’t meet their privacy policy of “industry-standard protocols and technology” because they didn’t properly deal with password storage, IE salting their passwords. Note that what they were doing is still better than Yahoo with their plain-text passwords.

When doing security, it’s not only safest to deal with the root case, it can save your bacon later on. Always promote best practices and you should be able to limit liability to actual loss at worst.

I’d like to say that hopefully this will be the last time I write about SQL injection, but I’m willing to bet that it’ll happen again to a big company before the end of the year. In fact, I wouldn’t even be surprised if it happened again before the end of this summer. Sometimes we never learn. Feel free to sound off with your observations in the comments section or you can reach my on Twitter, Facebook, Google+, etc.

Resources

Can the Internet Survive Privacy

Bear Threat © by Mrs. Gemstone
Lately some have been suggesting that the internet is at risk. Much if not all of the hoopla stems from a recent interview with Sergey Brin from Google (GOOG). Brin says the biggest threats come from government crackdowns, attempts to control piracy, and “the rise of ‘restrictive’ walled gardens such as Facebook and Apple, which tightly control what software can be released on their platforms.”

If you look at the arguments, they essentially break down to “If Google can’t spy on your every behavior, then the internet will collapse.” This is because all information in applications that aren’t web-based can’t be crawled by web crawlers, and user behavior inside the application also cannot be monitored.

It sounds pretty ridiculous, when you think about it. People have been using applications for years on the desktop. Some of them are local to the desktop, others reach out and use the cloud (what we used to call the net, before that the internet, before that it was the network). Applications were, and continue to be a combination of proprietary software, commercial software, freeware, and other open-source models. What applications have usually NOT been on the desktop is ad-supported.

Much of the web has evolved itself into an old broadcast style model, IE advertising supports content. I know some will argue that the web “changes everything”, but think about it. The idea of having to put up with adds to get your news fix is nothing new at all. This is an old argument, is it better to have “free” content supported by ads, or paid content without advertising. In the modern era, we go beyond simple advertising as well. In addition to the cost of having to look at ads, people are giving up their privacy and allow advertisers to monitor their behavior. The rationalization is that this is saving them some money.

Again, it’s an old argument that is not going to be settled here, and I suspect won’t be settled at all. I prefer a world where you can choose whether or not you want ads, and pay for the content you get, or deal with advertising. Let the consumer choose. Personally, I don’t mind paying for software and content, like Netflix over Hulu. I prefer that over dealing with ads, even before the whole privacy issue came into play. But others feel differently and I don’t have a problem with that as long as I’m not forced down the same path.

What Brin is really saying is “If Google can’t spy on you, then advertising breaks down, and without advertising, the internet breaks down.” I don’t buy it. At all. If suddenly all advertising centric services were forced to simply serve up ads without regard to my exact movements, it would definitely have an affect on the bottom line of those serving up the ads. But advertising would go on. Don’t believe me? Turn on your television… see any advertising? Do they know who you are? Do they know what channel you just watched? Do they know that you called your mom during the show? Nope, and they don’t care. Actually they DO care, they’d love to have that information about you. But in absence of having the information, life goes on.

Google tries to obfuscates the issue by saying they’re against “Walled Gardens”. Of course they never address the issue that all traditional computing is “walled” in the sense that Google has no idea what you’re doing. But somehow that’s OK, while if use the same software on a tablet, it means death for the Internet. Ridiculous. There is in fact a considerable disagreement over whether Google themselves have a walled garden.

What it really means is that if strong privacy protections are put in place, Google will have to change or it will collapse, because they have no edge in selling ads over anyone else. That I believe.