Ask Jesse answer: Finding security holes
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.
May 5th, 2005 at 10:19 am
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.
May 6th, 2005 at 5:22 pm
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: