Distributed denial-of-service attacks, SQL injections, and other security breaches are lurking in the cloud for their chance to wreak havoc on computers, servers, networks, and mobile devices. Security standards, such as NIST (SAMATE), CWE, OWASP, and PCI DSS offer invaluable guidance, but enforcing a security policy based on these standards is shady at best.
In this webinar, we’ll discuss the most effective development testing activities for ensuring application security, as well as how to ensure that your development team is consistently adhering to your development policy.
We’ll also cover:
New cloud service technologies that have made software infrastructure more vulnerable.
The exorbitant costs of failing to meet security standards.
The most effective development testing solution for improving application security.
Hope to see you there. After you can view a recording of the webinar at the same link.
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.
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
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 analysiscan 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.
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.
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.
Enable empirical research based on large test sets
Encourage improvement of tools
Speed adoption of tools by objectively demonstrating their use on real software
I find SATE interesting because it takes a couple of different approaches that are pretty useful to people trying to understand what static analysiscan and cannot due. One approach is to have several full-fledged applications with known bugs, and versions of the application with those bugs fixed. These have the effect of showing what static analysis tools can do in the real world. Unfortunately, they don’t help much when trying to find out what kinds of issues static analysiscan handle overall.
To do that, NIST has developed a test suite that has thousands of test cases with specific issues in them. Part of SATE is running various tools on the test applications and test suites, and then trying to analyze what they can find, how much noise they produce, etc. It’s an interesting exercise. You should check it out.
This year I was privileged give a presentation myself. I wanted to talk about some of the pragmatic aspects of actually trying to use static analysis in the real world. To that end, I created a slide show around the top 10 user mistakes, meaning things that prevent organizations from realizing the value they expected or needed from static analysis. These range from improper configuration to poor policy to dealing with noise.
Take a look for yourself. If you love or hate any of them, let me know. If you have others I missed, feel free to mention it in the comments, or email me or reach me on twitter.
As part of my ongoing series about Static Analysis issues I want to talk about the relationship between the traditional static method and the newer dynamic or flow analysis method. People seem to misunderstand how the techniques relate and what each is good at. In particular, many seem to think that flow analysis is a replacement for non-dynamic analysis, which couldn’t be more wrong.
For the sake of having a simple term to identify both methods, I’ll refer to the older “static” method of static analysis and “pattern-based” and the newer flow-based method as “flow-based”. This is somewhat of a misnomer in that both types are really based on patterns, but seems to be a somewhat common way of referring to the two methods. If the terms I use bother you, feel free to do a search-replace function in your head when reading. I’m not too worried at this point about a strict technical explanation of each, but rather to their relationship. The goal is to have a way to differentiate in terms these two particular types of static analysis. Of course there are other types of static analysis as well, but I’ll leave that for another day.
Let me begin by saying that there is in fact a very strong relationship between pattern-based and flow-based static analysis, at least at an academic level. In almost every situation there are a set of pattern-based rules that would allow you to code in such a way that would prevent the occurrence of the issue being found by the flow-based rule. Given the nature of how flow analysis works, it can never find all possible paths through an application. This makes it a good idea to start programming in a more pro-active way to prevent the possibility of issues you’re concerned about.
For example, in security, one of the basic problems is using tainted data. Somewhere in the application between getting data from the user and operating on the data, you need to check if the data is safe. Depending on how far apart the operations are, it can be extremely difficult if not impossible to check every possible path. Security code scanners that rely on flow-based analysis attempt to find possible paths between user input and uses of the input that allow tainted data to be operated on. They can never find every possible path even if you let them run for an incredibly long time.
Instead, if you restructure your code so that input validation is done at the moment of input, then you don’t have any paths to chase, and you don’t have to worry about tainted data in your application. Flow-based tools won’t find anything anymore, because you won’t have any unprotected paths. This is sometimes a more difficult sell for developers, since it doesn’t provide them with a single broken piece of code that needs to be fixed. Rather it tells them that the way they’re writing code now could be improved – a bitter pill to swallow.
However applying this same principle to things like memory corruption, resource consumption, etc. can make the program far more robust than chasing possible paths ever could.
An excellent methodology is to start with flow-based analysis and fix the low-hanging fruit. Once you have compliance with your flow-based rule set, then review what you’re doing with flow and compare it to pattern-based static analysis. Determine as best you can how to apply static analysis and catch all possible potential problems before they happen, and put that into place. This moves you from a reacting to issues in your software to a more preventative stance.
There are those who say that flow-based analysis is preventative, but it’s still symptom driven – namely trying to find the openings and bugs you left in your code. Pattern-based analysis, when deployed properly, can be used to address the root problems. In our tainted data example, this means changing our coding style so that we don’t have paths where data could be tainted – root problem handled.
Essentially, flow-based analysis finds real bugs in possible paths. When you get a message from it, you just decide whether you care about that path or not. Static on the other hand tells you about the potential for a bug, not necessarily about the existence of a bug. Again, with our security example, Flow-based says “you used tainted data” where pattern-based says “this data could be tainted before use”.
When compared, you can see that flow-based analysis is a great way to find low-hanging fruit, because it’s looking for bugs instead of you doing it. On the other hand, because it works by guessing (flow fans hate the “guessing” term) at possible paths through your code, it will always be by it’s very nature incomplete.
Pattern-based analysis on the other hand requires restructuring your code and behavior if you want to achieve it’s full value. Some code is not well suited to such change, such as working legacy code.
Used together you have a very powerful solution that is much more robust than either technique on it’s own.
As a reminder, I work for Parasoft, a company that among other things make static analysis tools. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else at all.