Year Of Security for Java – Week 42 – Break Something

No Gravatar

What is it and why should I care?
Breaking something (legally, of course) is one of the best ways to learn how it works. Software is no different. Breaking software is sometimes trivial and sometimes extremely complex, but either way is a great exercise. In particular for developers, it forces you out of the mindset of building, and gets you to think about how your software might break. It also brings you to a harsh reality of securing anything: the protector has to secure every avenue of attack, whereas an attacker only has to find a single path unprotected. The scales are a bit unfair in that respect.

In software testing, we generally look at blackbox or whitebox testing. Blackbox testing is testing externally, essentially focused on the inputs and outputs. Whitebox testing is testing internally where you know the internal properties of the software. Both are extremely useful, and I’ve discussed both in previous posts. However, for the sake of our discussion in breaking something, we’re usually talking about some form of blackbox testing.

What should I do about it?

What I generally recommend to people learning about a new type of attack or vulnerability is to do 3 things (in a loop):

1. Build it
Let’s say you were wanting to learn about SQL injection. In order to “break it”, you have to have something to break. The first thing to do is go out and collect or build code samples that perform SQL queries. Some may be susceptible, and some may not, but you’ll need code to get started. If you’re talking about some other attack, or even an SQL injection attack through an application, you will need some type of running site. That means setting up local servers and applications, etc. There are lots of vulnerable applications available (ala webgoat) in order to practice your skills.

2. Break it
Once you have an environment, you can begin to try and break what you’ve created. Start simple and get a boost from exploiting something trivial. Work your way up to something more difficult. As you learn more techniques to exploit individual vulnerabilities (think of all the XSS options!), you’ll want to try some of them out. A tool with progressive “lessons” like webgoat can be great for this reason. It can be enlightening (and frightening) to see your application fail in so many spectacular ways.

3. Secure it
Lastly, you’ll want to work on building protections. It’s great to show something can be broken, but that’s not enough. Remediation can be very complex depending on the issue, but is always necessary. Also, you’ll find that many of your attempts at remediation are either lacking in completeness or affect functionality in other portions of the system or both. Building appropriately scoped controls is a difficult but necessary task. The good news here is that there is a lot of good information available to help with this, but the bad news is that it’s not in common developer guides. Most of the time, you have to go to a security-specific resource to get this information.

Here are a few extra thoughts around breaking software

– Keep your test cases around
It turns out to be really helpful to have a collection of small sample code snippets that express a single issue in a contained way. I end up using my rough collection of vulnerable code in lots of different unexpected ways. There’s no reason to throw away work you’ve done anyhow. Also, it gives you that warm feeling of fright when you see code you wrote from years ago.

– Sometimes breaking something is the only way to prove it can be broken.
This is true in a couple respects. First, sometimes the only way to prove to a developer that they’re writing insecure code is to show it breaking (but make sure you’re doing this legally :>). Second, while it is sad, this is often a helpful way to get non-technical folks on board with security. If they see something break, something just clicks for them. I’ve often seen this technique used to help justify security investment, though I’d argue that there are better alternatives for that.

– Try a bug bounty program and win!
Over the last few years, a number of organizations have come forward with bug bounty programs, essentially a financial incentive for finding bugs in their software and then being “nice” by reporting the bug to them and letting them fix it before exposing it to the world. This is an interesting concept for a lot of reasons, but for the person interested in learning to break something, it can be a great option since you can get paid if you find something.

In conclusion, breaking software can be a great way to learn how it works, and can be a crucial link in the effort to secure it. Go forth and break!

Be Sociable, Share!

Technorati Tags: , ,

One thought on “Year Of Security for Java – Week 42 – Break Something

Leave a Reply

Your email address will not be published. Required fields are marked *