The Art of Software Security Assessment

justin January 10th, 2008

I honestly thought that Id covered all the ground I could on same-origin policy, but I just stumbled across the W3C draft on Access Control for Cross-site Requests. Apparently, this is implemented in the upcoming Firefox 3 and (given the author) can be expected to show up in Opera too. It seems this protocols sole purpose is to allow cross-site XMLHttpRequests to get through the same-origin policy. I admit serious dismay that no one is taking the opportunity to shore things up a bit while making new holes (especially considering my previous thoughts on the subject). However, I understand that developers are probably clamoring for the chance to make shiny new AJAX mashups and widgets. That said, I cannot understand is how this particular solution is the best we can get. Heres a rough explanation of how the protocol works:

For a cross-site GET, the request is issued, and the response is checked for access-control headers (or header directives in the document), which determine what requesting domains are allowed to make cross-site requests. If the requesting domain is allowed, the response is made available to the script; otherwise, it fails.

A POST (or DELETE) is a bit different, and is handled in multiple steps in order to prevent unwanted side effects:

1. The browser issues a GET request for the desired URL with a Method-Check header listing the method of the request that will follow.
2. The server responds with access-control headers telling it what methods are allowed or denied for a particular set of origins.
3. If the origin and method combination are allowed, the browser issues the cross-site POST request.

Now, this certainly adds some complexity to the browser implementations, but overall it isnt too bad. The protocol also includes authorization caching to reduce the chattiness. However, things get much more complicated when you look at the server. One notable fact is that access-control logic will have to be implemented for every server page that handles cross-domain requests. So, rather than consolidate things into one easy to audit policy file, the logic will instead be spread out across potentially any page on the site (because even the static pages can include access-control directives in XML headers). You can also expect to see a lot of mistakes with the POST handling.

So, I have to ask, what is the value in spreading the origin policy exceptions across the entire web site? Id expect that its going to make web-app security auditing a whole lot more complicated. I will preempt the argument that a policy file would expose site structure and cross-site relationships, as Id maintain that information is already more than easy enough to get when spidering the site. Finally, doesnt anyone else care about shoring up all the existing cross-site stuff so we have a little more defense against things like XSS and XSRF? Because I cant see any way of Access Control for Cross-site Requests ever addressing the security problems we currently see every day.

• Discussion , Web
• Comments(0)

justin February 17th, 2007

Last week I presented an overview of the same-origin policy and different attacks against it. This week I’m going to take a cue from Robert Seacord and propose a solution to the problem. It’s probably not the ideal solution, but maybe it will start some discussion and lead to something more complete. I had also intended on exploring some related proposals first, but I’ve decided I’ll present my own idea before I start a debate on other suggestions.

Continue Reading »

• Discussion , Web
• Comments(6)

justin February 8th, 2007

The last few years have seen a constant rise in vulnerabilities like cross-site scripting (XSS), HTTP response splitting, and cross-site request forgery (XSRF or CSRF). While the vectors and exploit of each of these vulnerability classes vary, they all have one common thread. Each of these vulnerabilities exploits trust shared between a user and a website by circumventing the same basic protection mechanism: the same-origin policy.

In my experience most developers—and even many security people—don’t really know what the same-origin policy is. Worse yet, the rise of AJAX and mash-ups seems to have turned same-origin into something developers are trying to break. Complicating the issue further are the weaknesses in most browsers’ implementations of same-origin, leaving open questions about the effectiveness of the policy itself. So, I’ve decided to try and capture all of the information surrounding same-origin in one place. I also have my own thoughts on the value of the model itself, but I’ll save those for the end.

Continue Reading »

• Web
• Comments(10)

mark December 27th, 2006

SQL injection vulnerabilities have plagued applications for many years. When a dynamic SQL query is constructed with any sort of user-controllable input, there exists the potential for an attacker to perform arbitrary SQL queries, which might lead to sensitive information disclosure or modification. Developers wanting to protect their applications from these kinds of attacks have typically instituted filtering of user data for SQL metacharacters, moved their database query code into stored procedures, or replaced their dynamic SQL statements with prepared SQL. Prepared SQL statements are precompiled SQL queries that accept user-defined parameters without allowing for SQL injection attacks to occur. Since the SQL query is compiled beforehand, the user’s data is never parsed by the SQL parser, and thus isn’t capable of triggering metacharacter attacks.
Continue Reading »

• Windows , Auditing , SQL , Web
• Comments(2)

jm December 26th, 2006

One thing we’ve been finding increasingly over the last year or so is a lot more instances of SQL injection within stored procedures. In order to set the stage for Mark’s SQL Truncation post, we’re presenting a brief cheat-sheet on how to audit for these issues.
Continue Reading »

• Auditing , SQL , Web
• Comments(2)