Contact Jason White
The 80/20 Problem
I wrote a short blog on my personal site about this recently. The extra short intro is that 80% of our code comes from libraries these days. The other 20%? Well, a good bit of that comes from StackOverflow. No, those aren’t hard numbers, but they depict well the landscape of software development and its composition. What’s the security implication there? Well, for one we may or may not have lurking vulnerabilities in those import , include and use statements (sorry if I didn’t include your favorite language’s syntax), see A-9 from OWASP.
Then consider this more recent revelation in relation to the other 20%. Yep, StackOverflow holds quite a few answers containing examples that are vulnerable to SQL Injection. The peak is in March/April 2014 with 1655 and 1725 samples containing SQL Injection (just for php). It reminds me of my college days when the solution to getting something running (according to an online forum) was ‘chmod 777 <someFileOrDirectory>’.
The 80/20 Approach
OK, so it’s not a solution, but ‘Problem and Approach’ doesn’t make for a catchy clickable title, right? Anyway … You want to approach your problems such that you can solve 80% of them with 20% of your effort/time/resources. Edge cases and digging into details details takes time and you want to leave time for that. Unexpected things always come up, so control the expected as much as you can. This includes security. Security issues after all, are just bugs or abuses of design flaws. While application security is hard, there’s plenty of things that we know about that have straightforward solutions .
Developer Responsibility In Security
Lately, there’s a good bit of talk about responsibility, accountability, liability and even software/security guarantees. At the same time, there’s a common refrain of “we don’t expect developers to become security experts”. So, how do we reconcile the need for software security accountability without requiring developers to become security researchers?
One way is to bolt on WAF’s, RASP’s and/or run an IDS out in front of your web-facing assets. Even with those, there are issues that some of those solutions will not catch. Insecure Direct Object References is one that comes to mind. Similar logical or access control attacks for example are hard (if not impossible in many cases) for those to detect/stop.
Fact is, developers need to know enough security to start building the basics in . We can expect them to build/test for things that are well-known and are readily solvable. To that end …
An Example for the 20% Problem, 80% Solution
Granted, this example is still somewhat pseudo-code. However, that’s OK as you shouldn’t just blindly copy vulnerable code (as we’ve already touched on). This is an XSS control example. It’s definitely a big problem and something that’s very testable with unit and/or other automated testing.
Your code might look something like what’s below. Let’s assume you have a search endpoint which instantiates a results model and in it you use user input in the output (which will eventually make it back to the browser display). Additionally, let’s assume this term is taken off of a client-side route (e.g. my.site.tld/myApp#search/{someTermHere}). Yes, you could also potentially encode in the DOM if this is an SPA (which this is modeled as), but still … humor me.
@RequestMapping(path = "/service/search", produces ="application/json", method = RequestMethod.GET) public @ResponseBody searchResultsModel searchSomething (@RequestParam (value="query") String userSearchTerm) { return new SearchResultsModel(userSearchTerm); }And then the model that is invoked from the endpoint
package com.my.appropriate.package; import org.owasp.webgoat.encoder; // what we are using for encoding public class SearchResultsModel {
private String searchTerm;
private SearchResults searchResult;
private int numberResults;
@Autowired
private SearchService searchService;
public SearchResultsModel (String searchTerm) {
this.searchResult = searchService.getResults(searchTerm);
this.numberResults = this.searchResult.getCount();
//encode return value to be displayed in HTML
this.searchTerm = Encoder.enlesson.getSubmitMethod();
}
//GETTERS AND SETTERS as appropriate below here, but not shown in this example
}
Now, we can just trust the encoder since it’s an OWASP project, right? Well, maybe, but I like to trust and verify , so let’s add a unit test (stored off in src/test/java/com/my/appropriate/package of course).
@Test public void TestSearchTermIsEncoded() { SearchResultsModel searchResults = new SearchResultsModel(String "<script>alert('xss')</script>search this!"); assert(searchResults.getSearchTerm().startsWith("<")); // ... and so on, even adding much more complex examples }You could even set the test up to read off a list of evasion techniques , testing for escape and asserting failure or success accordingly. Just remember, that successful evasion is actually a failure in this case and should be asserted accordingly.
Small Wins, Building Culture
The great thing is that once this work is initially done, it’s running all the time. You can add to it if you find a new edge case you want to check. The other thing this does is promote a culture of security with small wins , because developers hate red. If another developer causes it to go red, they will want to fix it.
You will also likely be ahead of most (maybe even in 80th percentile or higher) of the others out there being chased by the proverbial [security] lion.