Software [In]security: Web Applications and Software Security

November 17, 2008

Gary McGraw has posted another article in his InformIT column, this time specifically on web applications and software security.

Its a great article, and Gary is spot on, but I had a couple of points I wanted to discuss, so I emailed them off.  Thankfully, Gary is a friend, and is really good at arguing any points I might have.  For interest, here’s some of that email exchange.

MA: CSRF I don’t really consider to be an interposition attack - the attacker isn’t really getting "in between" anything, but causing something to happen (with trust) that otherwise wouldnt. In many ways I think this is more of a replay/reuse attack.
GM: I think it is a classic interposition. In this case, the browser is being treated AS the user, which is incorrect and leads to the vuln.

I sort of agree in that the browser is being treated as the user in some way, but I still think of this attack as a form of "replay" attack (perhaps even "reflected replay", as with the SMB vuln patched recently).  Interposition is, according to the dictionary, something that is interposed, which is defined as "in between" (which CSRF is not – the attack is an initiator. In any case, I think this is just semantics.  Would be interested in what other people think this class of attack is.

MA: CSRF isnt "always" in play when XSS is present - on .NET for example, the viewstate has a MAC created by the server on each request. If you add random data (for example) the session ID to the viewstate (various ways of doing that) the attacker can’t create/send the viewstate (as they can’t hash/re-sign it), and therefore the server discards the request. That’s on the .NET platform - I dont think I know of any other platforms/technologies like that, but there might be. There’s lots of "but if’s" in there, but that’s quite a "normal" case.
GM: Thanks for this example. Didn’t know of it prior. I stole the thinking about the one implies the other from Felten (see the link off the SB page)

It’s really common that any protection measures put in place against CSRF totally fail when XSS is present.  There’s one case that I know of though where this isn’t totally true and that’s in .NET.  The reason is when the viewstate is used, it’s value has a MAC, and any tampering of parameters can be detected by the server.  On it’s own this still doesn’t protect from CSRF, but if "random" data is added in (preferably with each request), then even if the attacker has XSS on the page and can read the anti-CSRF token (the viewstate), they can’t reuse it in another request because it’s a) changed after some interval and b) they can’t send a valid viewstate (re-created or modified by an attacker) because they can’t "sign" it (add the checksum) as they don’t know the server-side secret.  If the viewstate doesn’t match what the server expects, it throws an error.

It’s certainly an edge case, but one I hope that other anti-CSRF systems consider.  Alex Smolen (colleague, ASP.NET guru and MSFT MVP) knows much more about this, the issues, and has posted about them here.

MA: Web vulns / web security have a lot of attention for a few reasons I think.
  - it’s easier than "traditional" security. you can test without have to set a lot of stuff up, and the protocol/tools are very simple to write/use
  - it’s not rocket science. Jer/RSnake are certainly pushing the state-of-the-art, but a lot of it is still down to server (input) validation and browser insecurity. I’ve not seen a "new" attack in the web space for a number of years now
  - Lots of software is going onto the web. I read somewhere that it was the most dominant dev platform (in terms of number of people programming for it). *All* of that software is in one of the most hostile places to be (accessible remotly, often containing some level of assets), so people focus on it
  - it’s a very fertile ground. WebAppPenTesting is still a "fish in a bucket" exercise. Devs are *still* getting basic things like XSS wrong, although I dont like just searching for vulns - as you mention, you should be looking for architectural issues and the root causes of vulns, as otherwise it’s just "penetrate and patch" and the client doesn’t really learn anything

Lots of acknowledgments between myself and Gary here, so I won’t bore anyway with the details.  There is the challenge for me to actually find the reference of the web being the most dominant dev platform, which I’ll have to look for.  Anecdotally though, by far the most software that the security consultancies I know are reviewing/pen-testing is web-based, although that my have a self-selecting bias (because of risk/exposure).  I don’t have any hard figures, but I (and Gary) would certainly be interested to see them if anyone has them.  Otherwise I’ll have to rack my brain in where I saw that (and also hope that it wasn’t just in some marketing literature!)

One thing that Gary did put me straight on was the following

MA: The tools that are out there are just useless. Even more useless than the code review tools are, and we know what it takes to get them running and making an impact. The issue is that each and every webapp is custom, and although there’s a nice simple protocol, actually recognizing when something went "wrong" (discovered a vuln, got logged out, not discovered all the pages, etc, etc) is actually very hard. Jer is being generous in saying that a tool can only find 50% of the issues. Press a little more, and that is "a tool that is well configured, knows the app well, and has a good idea of the vuln and it’s external characteristics" - the stars really do have to align to get even close to that 50%. We really need tools though as this issue it’s scalable to the number of people we have looking it.
GM: I disagree with this one. The tools find lots of "stupid" things you should have known better about. That is a good thing. How much can QA people do as a smoke test?

I think that this falls into my last sentence.  I really do believe that we need tools, as otherwise it’s just not scalable, and as Gary says, how often can QA people look at something to give it "a quick test" for certain issues.  That’s why I think the "badness-ometer" quote is so good and great advice.  In general I would like to see these tools catch up, and for some level of acknowledgement (other than from a few people) in that they will never replace a human for a large part of the testing.  This really has to start to change, and I have thoughts on that (which I’ve shared with various people), but save them for another post.

My final point was

MA: the final thing about web security (both tools, practitioners, and research) is that it’s much more often than not done black-box. This "stabbing in the dark" is only going to find so much, and even then only some things. There’s still this pervasive attitude out there that pen testing, even webapps, is enough. Im amazed that we (still) find as much as we do, which is a sorry state for the webappsec field.

I’m certainly guilty of my work being based around black-box techniques, but that seems to be what clients want and are willing to pay for.  There’s few-and-far-between clients that want to go "deeper", and often that’s because (IMHO) they don’t see a ROI/benefit in going any further.  Black-box is a good place to start, but I’ve always considered it just one stage in a multi-pronged approach.  However, one has to realize that the majority of companies out there do not make their living of their software – it’s an "enabler" for them to do business, and therefore it only has to be "good enough" – any more and (in some way) they are wasting their money.  You don’t have to outrun the bear, you only have to outrun the last person.

In any case, I really like having discussions with Gary (even thought the roles were reversed this time), and can’t wait until I have another opportunity to sit down by his river, chat, drink, and watch the world (and black hawk helicopters) go by.

Posted in Musings, Security