Many people probably do something similar, but for years I’ve kept a running list of unsolved technology problems that I’ve come across. Typically specific things I’d like to build, design, or break. As it applies to Web security some are potential hacks, defense measures, or conceptual designs mostly regarding Web browsers and Websites. This serves as a nice in-flight activity as opposed to crossword puzzles, some being more compelling to work on than others. When I post some little trick here it usually comes off this list, still the list always seems to grow instead of shorten. ;)
Anyway, I thought it might be interesting for others too see several of the things currently on my list. See below.
What unsolved Web security problems are you working on?
Unsolved Problems:
- Create a better CAPTCHA that scores a better on the Effectiveness Test than the current image version everyone hates
- Develop a CSRF defensive measure that’s effective in the presence of an XSS vulnerability on the same target domain
- Obtain a users NAT'ed IP address using ONLY HTML/JavaScript
- Send a valid XML web services request cross0domain in a browser using only HTML/JavaScript. Do not use any of the new FF cross-domain features as the target server should not need to opt-in.
- Design a conceptual replacement for the Web browser same-origin policy that addresses its deficiencies
- Find a way to SCRIPT SRC or included within the DOM a JSON feed wrapped using curly braces
19 comments:
Well, when I knew about new cross-site W3C's spec, the first my thought was that, possibly, the target server doesn't have to opt in if it's vulnerable to the HRS. Then we could try to inject Access-Control headers into the response.
I didn't try that yet myself, though.
Hmph, wow. Now that's clever. Hey, who says vulnerabilities don't come in handy? ;)
Hi Jer, Amit here.
Just a quick comment to note that in order to "send a valid XML web services request cross-domain in a browser using only HTML/JavaScript", you can employ one of the two already known tricks:
1. DNS rebinding (the first two tricks - using the cache a-la "timeless" - http://viper.haque.net/~timeless/blog/11/, or shutting down the port a-la Martin Johns and Kanatoko - http://shampoo.antville.org/stories/1451301/).
2. (only when using a forward proxy server) inject a second HTTP request via an XHR invocation (my own writeup -http://www.cgisecurity.com/lib/XmlHTTPRequest.shtml, look esp. at notes #1 and #2).
BTW - love your list :-)
Wow, post a couple of web security problems and the real hackers come out in force. :) Both of Amit's recommendations should work, a little hacky, but hey my fault for not drilling deeper into the rules. :)
"Develop a CSRF defensive measure"
Theoretically impossible, barring browser changes, although I imagine it might be possible to make it very difficult for it to work.
"Find a way to SCRIPT SRC or included within the DOM a JSON feed wrapped using curly braces"
I've seen some research on this. For Internet Explorer, the object is instantiated, but there's no way to access it by overloading a constructor. Firefox results in a parse error, as it attempts to use the brace as a code segment, so it's totally inaccessible.
Some research I'd like to see done are the interactions between object tags and the corresponding backends in major browsers.
Jeremiah,
could you please clarify your restrictions for CSRF problem? By "target domain" do you mean the same domain as the attacked form or any victim's domain?
sure. sitea.com has an XSS and a CSRF vulnerability. I want an effective defense against CSRF without doing anything about the XSS issue. Make sense?
Put Joe White down for Single-Site Browser (SSBs) as a solution to CSRF in the presence of XSS. Hey could work, but would require a lot of it.
> Design a conceptual replacement for the Web browser same-origin policy that addresses its deficiencies
It's called "capabilities." As far as I can tell, all of the cross-site problems are instances of the confused-deputy problem. There is a long history of addressing this problem with the capability-security-model. A more recent example, and relevant to your problem, is CapDesk.
Of course, this implies rewriting the browser.
I've been following you, Schneier, and ha.ckers.org, and am surprised that none of you have mentioned capabilities, or the confused deputy problem.
(The wikipedia article, http://en.wikipedia.org/wiki/Capability-based_security, is only a bit confused, and has references to capability systems. Information on CapDesk seems a bit thin in the web: http://en.wikipedia.org/wiki/CapDesk)
It strikes me as wrong that to submit a comment, I have to enable javascript and cookies on a site that focuses on browser vulnerabilities.
Bah.
Hi again,
just some ideas about CSRF:
http://sandals-on-my-head.blogspot.com/2008/03/no-csrf-in-presence-of-xss.html
"Develop a CSRF defensive measure that’s effective in the presence of an XSS vulnerability on the same target domain" - is solved prety well by SessionSafe: http://shampoo.antville.org/stories/1586524/
It had some implementation issues, but it got hacked a bit and now the implementation looks solid: http://shampoo.antville.org/stories/1607502/
"Send a valid XML web services request cross0domain in a browser using only HTML/JavaScript. Do not use any of the new FF cross-domain features as the target server should not need to opt-in." - What does a valid XML web services request look like? Maybe you could do it with the URLRequest object in flash?
Oh, and regarding Firefox's cross-domain XHR: if they can be GET requests then the server doesn't have to opt-in.
Amit here, again. Note that Stefano just posted yesterday two interesting XHR injection attacks against IE7. Serves as a nice illustration for my previous comment.
Wouldn't the solution to the first be an almost effective solution against the second? Assuming CAPTCHA the way it's implemented now, by sight and sound, is ineffective, wouldn't something else (out-of-band - you have to SMS us to make the transaction happen, maybe?) also be effective against XSRF?
While Amit's solution works for XS WS (and a whole host of other things people don't think about), it does require a few stars to be aligned. I think an exploitation model without requiring browser vulnerabilities and caching servers' inexplicable forgiveness should be researched.
There are some nuances in the browser and in some Web Service platforms that might allow this to happen but we are not quite there yet. I will write up something this week on my research. I have a funny feeling if I put what I know out there, somebody who reads this blog may be able to provide the missing links to make this work (at least against a particular Web Service platform).
Also, I love the way you worded it - "Unsolved Problems". Meaning, the fact that these attacks haven't been real yet is a problem.
=)
@Sylvan von Stuppe:
I don't think OOB-solutions are good CAPTCHAs since OOB solutions are just using a different communications channel; you simply need to get your spam-bot or whatever to be able to interact with the OOB channel, e.g. SMS (which is really quite easy - I can say this as I've done it before :p).
Now, if you're relying on mobile numbers as a means of letting users only create one account, that's workable.
And while I don't know the pricing models on SMS auth, it's clear that it will definitely have additional cost; and imagine a website an SMS every time you're currently seeing a CAPTCHA...that doesn't seem feasible.
Of course, OOB auth does solve the second issue, I just don't think it solves the first. So should we all move to OOB auth? I'm not sure it's affordable for most websites. And definitely not if your app is going to run on the iPhone ;)
In terms of solving CRSF with XSS, wont implementing per-page nonces plus having a very short session timeout for inactivity more or less solve this?
@Alexander & kuza55, thank you. This will make for some good reading. I'll dig in and likely post a follow-up.
@kuza55, for our purposes here lets say the post data I want to send is "<* xml>foo<* /xml>". All the trick I've tried so far have leading "=" because of the nature of HTML forms. Also, I want to use HTML/JS only... no Flash or the new cross-domain XHR (needed it to be cross-platform if possible). With flash its possible using a crossdomain.xml, but that requires an opt-in which I wanted to avoid.
@Arshan, mind of a hacker, what can I say. :)
@Anonymous, ugly solution with some nasty side effects, but that should technically work. I guess we'll put that method on the list as a possible solution and see if we can add more to it.
Post a Comment