Ask Jesse answer: Finding security holes

Jeff Walden tried to ask:

How do you find security holes?

This isn't a very coherent answer, and I don't know which parts are the most correct or most useful.

I'm good at ad-hoc testing, where I try to find and report as many bugs as I can. From this perspective, a security hole is just a bug that can be abused by an attacker in a way that hurts the user.

I frequently ask myself "What might the author of this code not have considered?". Sometimes I ask myself "How can I prove that this code is correct and secure?" instead.

I spent a lot of time triaging and testcasing Mozilla bugs, so I know a little about many Gecko and Firefox features. I know of many JavaScript and DOM features that tend to hurt security: getters and setters, eval and the version of setTimeout that takes a string, the with statement, prototype chains, and dynamic typing with implicit coercions. I know of several other Mozilla features that tend to lead to security holes: javascript: and data: protocols, synthetic events, security dialogs. I know of some security checks that are scattered and frequently missing: same-origin checks, CheckLoadURI calls.

I take note of places in Gecko where user data interacts with pages: visited link coloring, file upload controls, pasting from the clipboard. These exceptions often interact with other features to create security holes.

Even though I usually have access to source code, I rarely use it. Using Mozilla source is slow for me because lxr is slow, Google Desktop Search refuses to index my Mozilla source tree, and I'm not good at reading Mozilla source. Testing Mozilla like a black box is fast for me because I have tools like the JavaScript Shell.

2 Responses to “Ask Jesse answer: Finding security holes”

  1. Jeff Walden Says:

    Okay, that’s getting in the direction I wanted. This sort of stuff has always intrigued me, because I’ve never had many ideas for how one would go from having what seems to be a fully working program to poking it in unorthodox ways to discovering bugs that can be used to twist the system beyond where it can safely fail. This article gives me a more informed starting point.

    Incidentally, I very, very recently (after I asked the question) stumbled upon a good online example of the sort of article I was requesting. See the article SQL Injection Attacks by Example for a good introduction to finding security holes in database-enabled web applications, which goes through the process of starting from one web form to getting privileged access to the back-end data.

  2. killo Says:

    Great series of articles. I love the honesty with which you compare objectively where each rival browser is more or less secure than Firefox.

    Compare and contrast the people on Mozilla blogs to the sycophantic blog posters on the IEBlog with moronic comments like:

    Can you please tell E-Eye to remove the lies they are spreading about Internet Explorer security holes:

    Monthly security patches were issued _after_ the first two were disclosed, but they are still saying “unpatched” on that page!

    Saying ‘Microsoft leaves security holes unpatched for 2 months’ is typical of the sort of lie that the FireFox kiddies will use to try to unfairly discredit Microsoft’s security record.