- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 7 Apr 2009 15:57:07 -0700
- To: Tyler Close <tyler.close@gmail.com>
- Cc: public-webapps@w3.org
On Tue, Apr 7, 2009 at 10:38 AM, Tyler Close <tyler.close@gmail.com> wrote: > On Mon, Apr 6, 2009 at 6:31 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Mon, Apr 6, 2009 at 5:36 PM, Tyler Close <tyler.close@gmail.com> wrote: >>> On Mon, Apr 6, 2009 at 5:21 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>>> Additionally, if the attacker can make a GET request happen to >>>> any URI but with a sensitive password added, it is quite likely that >>>> this could be directed to some URI on the site that will for example >>>> insert a comment into a forum, or otherwise publish the data to >>>> somewhere where it can be read. >>> >>> If the site abuses GET in this way, then it is vulnerable to damage >>> via a simple <img> tag constructed by the attacker (assuming the >>> password rides along in a cookie, as is common). >> >> I don't mean that the harm is in that you can use CSRF attacks against >> the site to insert forum posts. >> >> The attack against the site would go something like this: >> >> 1. Trick the site to issue a GET request to a URL that adds a post to >> a public forum. >> 2. Go to said public forum >> 3. Read the newly posted item >> >> The URL in 1 will include the password since that was added to the >> URL. It's possible that this will result in the password being part of >> the posted forum item. >> >> In step 3 then you can read the secret password. >> >> This works in todays browsers that don't have cross site XMLHttpRequest. > > But the client-side code that adds the password to the URL is the > site's own code, and so it knows it uses that parameter name to carry > the password. Why would the site's own server-side code then read the > password out of that query string parameter and put it in the forum > post. This seems silly. So we're talking about code running on 'targetsite.com' that looks something like this: function doSomeAction(uri) { var client = new XMLHttpRequest(); fullURI = uri + "?passwd=" + s3cretToken; client.open("GET", fullURI); client.onload = updateUI; client.onerror = updateUI; client.onabort = updateUI; client.send(); } Where the attacker has control over 'uri'. Right? So in this case the attacker could set 'uri' to something like http://targetsite.com/userSupportForum/addPost.cgi?name=evil+attacker&email=evil%40attacker.com&body=secret+token+to+follow This will result is that the secret token is posted to a publicly readable place. My point is that the design you are describing is extremely risky. Allowing yourself to send a secret token to an arbitrary uri on your website is an exploit waiting to happen. As I have said before. It is fully possible that this happens. It's even possible that someone does this intentionally and that they have vetted all CGIs running on the website to ensure that it is safe. And that they continue to do this vetting any time more CGIs are added to the website. But it does, to me, seem very unlikely. >> Additionally the API we're adding has a very >> subtle difference, and one that is different only in the security >> model. > > "only"? Since when is that an "only"? My point is that having two APIs that are identical and intended to be used for basically the same thing, except for that they use different security models, is a security bug waiting to happen. / Jonas
Received on Tuesday, 7 April 2009 22:58:04 UTC