I recently had to test a REST API with Burp Suite with a couple of unusual conditions. The first was I had a thick client to talk to the API that had no understanding of proxies. I could use curl to do the same thing but the client was still something I wanted to test. The second was the only access I had to target server was via SSH to a gateway system to get into the network the target was on. I knew I could tunnel Burp over SSH and I knew I could set up Burp as an invisible proxy. There are how tos out there about doing either thing separately but I didn’t find anything about doing them together. It took some trial and error with varying levels of success until I managed land at this solution that gave me the best results. Continue reading “Using Burp Suite as an Invisible Proxy Tunneled Over SSH”
Excerpt from my latest blog post at Cigital…
More and more organizations are using static analysis tools to find security bugs and other quality issues in software long before the code is tested and released. This is a good thing, and despite their well-known frustrations like high false positive rates and relatively slow speeds, these tools are helping improve the overall security of software. Unfortunately, these known frustrations may also introduce a dangerous blind spot in these tools which do not know modern frameworks as well as they know the base languages.
The blind spot
Frameworks are doing more and more of the basic work—providing common functionality of an application. This is a fantastic leap forward in terms of productivity and the ability to release software faster and faster. This frees up more time to focus on the core business functionality of applications.
Sometimes these frameworks are clearly separate things (like Spring, for example) and sometimes they are a mix of basic functionality and advanced features (like the .Net Framework where the tools understand some features but not others). These frameworks are virtually exploding around us, offering many options to take care of the basic drudge work of application writing.
This explosion is happening fast and it seems to be accelerating. New versions and even new frameworks are appearing faster than most can keep up with. Static analysis tools are doing a decent job keeping up with basic languages. However, there is almost no way they can keep up with all these frameworks and handle even a few of them well, let alone all of them. As these frameworks take care of more and more of the plumbing within applications, this inability to understand what they are doing creates a blind spot in which code gets scanned and nothing gets reported.
Frameworks create data flows that the static analysis tools may be blind to. They introduce sources of tainted data that the static analysis tools know nothing about. Therefore, there is nothing to trace to the sinks created in code where problems could occur. These frameworks may introduce new sinks, but since the tools do not know of them, the sources in code cannot be traced to them. They also provide functionality behind the scenes that the static analysis tools do not see at all.
If the static analysis tools cannot see it, they cannot report it. If they do not report it, organizations are left feeling secure when they are not.
False positives are annoying. False negatives are dangerous.
My article Developer Training: Recognizing the Problems and Closing the Gaps has been published in the March/April edition of CrossTalk.
Analyzing source code for security bugs gets a lot of attention and focus these days because it is so easy to turn it over to a static analysis tool that can look for the bugs for you. The tools are reasonably fast, efficient, and pretty good at what they do. Most can be automated like a lot of other testing. This makes them very easy to use. But if you are not careful, you may still be missing a lot of issues lurking in your code or you may be wasting developers’ time looking at false positives the tool was not sure about. As good as these tools have become, they still need to be backstopped by manual code review undertaken by security experts who can overcome the limitations of these tools. Let’s examine how manual code review compliments static analysis tools to achieve code review best practices.
This isn’t the only place my blogging appears. The Benefits of Code Scanning on Cigital’s Blog:
“All software projects are guaranteed to have one artifact in common – source code. Because of this guarantee, it make sense to center a software assurance activity around code itself.”
-Gary McGraw, Software Security: Building Security In
When an author sits down to write today, they have great tools available to automatically check their spelling and grammar. They no longer need somebody to tediously proofread their work for the mundane errors; the computer does that for them. Tools such as these won’t help if the author has nothing to say, but the simple errors that have long plagued writers are quickly found by modern tools. By the time a work is reviewed, the simple problems have been identified and resolved.
Modern developers have similar tools available to them to address common problems in code. Static analysis tools, also known as code scanners, rapidly look at code and find common errors that lead to security bugs. The tools identify the common problem patterns, alert developers to them and provide suggestions on how to fix the problems. These tools will not take care of underlying design flaws, but they often help developers avoid many security bugs in code long before that code is turned over to testers or is put into production.
Why do developers need secure development training as well as their regular training? The answer to that starts with a side trip into the aviation world.
Have you ever wondered why the windows on commercial airliners have rounded corners instead of square ones?
In the 1950s when jet service was fairly new there were a series of crashes of de Havilland DH 106 Comets, the first production commercial jetliner. During the investigations into the crashes it was discovered that the hulls experienced metal fatigue, something that was little understood at the time, and could fail catastrophically. As the cabin was pressurized and depressurized over and over and encountered repeated changes in temperature while changing altitude it cause metal fatigue that weakened the structure. In some areas of the structure there were special stress points that experienced more problems than others. One of these special stress points were the corners of the square cornered windows on the original versions of the Comet. The square corners caused levels of stress two to three times greater than the rest of the fuselage. The metal was going to fail after a number of flight cycles with one of the crashes coming from as few as 900 flights. Continue reading “Secure Development Training – Learning from Failure”