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:
- The browser issues a GET request for the desired URL with a Method-Check header listing the method of the request that will follow.
- The server responds with access-control headers telling it what methods are allowed or denied for a particular set of origins.
- 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.
mark August 7th, 2007
Hi!
Well, we just arrived home from Las Vegas on Sunday after delivering our talk at Blackhat about breaking C++ applications. It seemed to be received pretty well. For anyone interested, the slides should be available on their website, but we have also archived them here.
Enjoy!
mark July 9th, 2007
Hi there!
We would like to announce that we will be speaking at Blackhat in Las Vegas (beginning August 1) this year on the topic of C++. The basic premise for the speech is this: Most security literature about vulnerability analysis (or secure programming) for C/C++ tends to only address potential problems that can occur in C (dangerous API calls, integer overflows, pointer arithmetic, and so on). While these problems also affect C++, it is very rare that C++-specific problems are dealt with at all. As such, we are going to speak to a few problems that are specific to C++ and C++ runtime environments. There is too much material to address every potential problem that can occur in C++ in the time we have, but some of the things we intend to cover include VLA’s, the STL, and exception handling. So, if this sounds like your cup of tea, swing by and check it out!
We will also be doing a book signing on the first day of BlackHat at 12.30 PM.
Hope to see you there!
jm February 26th, 2007
A couple of interesting errata, courtesy of Herr Doktor Professor rCs:
Continue Reading »
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 »
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 »
blog January 18th, 2007
Robert C. Seacord of CERT was kind enough to provide us with the following proposal for addressing integral vulnerabilities in future versions of the C standard. It’s an intriguing approach that we hope generates some good discussion. So, without further adieu…
Ranged Integers and Saturation Semantics
By Robert C. Seacord
In 2005, I wrote that "Integers represent a growing and underestimated source of vulnerabilities in C and C++ programs" as the lead sentence in the "Integer Security" chapter of Secure Coding in C and C++. This prediction has been borne out in a recent study published by MITRE on the types of errors that lead to publicly reported vulnerabilities. "Integer overflows, barely in the top 10 overall in the past few years, are in the top 3 for OS vendor advisories."
Fortunately, some individual members of the ISO/IEC WG14 international standardization working group for the programming language C are starting to mull over some options for addressing integer issues. One idea is to adopt ranged integer types; a second idea is to implement saturation semantics for at least signed integer types.
Continue Reading »
mark January 9th, 2007
In languages that have direct memory access, string manipulation has always been tough to get right. When the dangers of buffer overflows were first realized, many applications that did any sort of string processing were found to have vulnerabilities that we would now consider to be obvious. Over the years, system string APIs have been updated, refined, and replaced. Interestingly, these various replacement functions have exhibited additional quirks, which can render an application vulnerable in more subtle ways than with standard buffer overflows. Some of these quirks are quite well-documented and well-known (such as the strncpy() function not NUL-terminating), and some of them are not. Windows actually provides quite a large number of string functions, each with their own subtle variances. It is important as auditors to know these differences so that you can accurately assess whether an application is vulnerable to potential memory corruption issues or not. With that in mind, I’ve put together a series of tables of quick facts about the various string functions available in a Win32 programming environment that should be useful as a reference when auditing string manipulation routines.
Continue Reading »
jm January 7th, 2007
You should check out the CERT Secure Coding Standards. We’ve started contributing to them recently, as we think they are interesting and quite well done. The standards are a community effort and a work in progress, so feel free to help out. The best way to start is by leaving comments on the appropriate pages with your ideas and/or criticisms.
One aspect of the system that I think is particularly good is the separation between rules and recommendations. Rules are things that you definitely don’t want to do in your code, as you’re very likely shooting yourself in the foot. Recommendations are more best practice coding standards or idioms that will buttress your code base against attack or help inform program design. So, for example, there is a rule that says "MEM31-C. Free dynamically allocated memory exactly once." Double frees are obviously something categorically bad, and should never occur in production code. An example of a recommendation is "MEM00-A. Allocate and free memory in the same module, at the same level of abstraction." This is absolutely sound advice. However, it’s a recommendation and not a rule because there are situations in real-world code where you might have solid reasons for violating this design. I think it’s this subtlety of analysis that will make the standard actually useful in real-world development efforts.
It looks like it will be a useful resource for its intended purpose as a baseline for secure coding standards. (i.e. if you need to put together secure coding guidelines for your organization, it should be a great starting point.) That said, it’s also useful for code auditing, as the rules encapsulate a lot of ideas about what can go wrong in code. It’s approaching the problem from a slightly different angle, but in general, for every rule, there are one or more implied insecure practices that you can audit against.
A quick plug: Robert C. Seacord is one of the chief contributors to the effort, and we might be able to coerce him to do a guest post later on. If you haven’t bought his book, "Secure Coding in C/C++," we highly recommend it.
blog January 3rd, 2007
In C++, objects can be dynamically allocated at runtime using the new operator and deallocated using the delete operator. Arrays of objects, however, require the use of slightly different operators for allocation and deallocation: new [] and delete []. Although the corresponding pairs of operators look very similar in source code, the way they function is actually quite different. Consequently, they can’t be mixed and matched - allocating an array with new [] and then deallocating it with delete, for example, will produce "undefined" results. This can catch developers off-guard, because you can often use the wrong operator without triggering a compiler warning or even causing a run-time crash.
Continue Reading »
