XHR redirects
in [JavaScript]
|
From: Jorge on 26 Feb 2010 13:53 On Feb 26, 6:59Â pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On Feb 26, 5:26 pm, Jorge wrote: > > On Feb 26, 6:06 pm, Richard Cornford wrote: > > >>>> Cookies should follow the rules for cookies. Which cookies > >>>> go with which requests depends on their (actual or implied) > >>>> Path and Domain parameters. > ><HERE> But you know that there are circumstances under which existing > >>> cookies are *not* sent.</HERE> > > >> That is what the rules for cookies say is possible. So your > >> point is? > > > That it might have been that this were another of these > > circumstances. > > That what might be "another of these circumstances"? See the <HERE> element, âââ above âââ -- Jorge.
From: Scott Sauyet on 26 Feb 2010 14:37 On Feb 26, 1:15 pm, Richard Cornford wrote: > On Feb 26, 5:58 pm, Scott Sauyet wrote: > > > On Feb 26, 12:40 pm, Richard Cornford wrote: > >> On Feb 26, 5:31 pm, Stefan Weiss wrote: > >>> I didn't try any other browsers, but I would be very surprised > >>> if any of them (the more recent ones, at least) could be tricked > >>> into sending an XHR which violates the browser's security > >>> policies by something as simple as an HTTP redirect. > > >> Why not? For a very long time it has been possible to 'trick' a > >> browser into making a request to another domain by setting > >> the - src - of a - new Image(); -. Making the request or not > >> is not that important so long as access to the result is denied. > > > ... and if the request is actually idempotent. > > Alright, what if the request is actually idempotent? I meant to qualify your statement further. I mean that making the request or not is not that important so long as both (1) access to the result is denied and (2) the request is actually idempotent. A GET request is supposed to be idempotent, but if it's not, then having that request made on redirect could cause problems. >> I know GET and HEAD requests are supposed to be, but we all >> remember the havoc caused with many sites when some >> prefetching was released (was it Google Web Accelerator?) > > I have absolutely no idea what you are talking about. At some point a few years back a browser plug-in was released; I think it might have been Google Web Accelerator. [1] This tool was supposed to speed up browsing by pre-fetching and caching links it thought you might visit off the current page. It makes perfect sense, except that a number of web applications out there had non-idempotent GET request, especially hyperlinked "delete row" actions. People started unintentionally altering all sorts of data using this tool. Granted, it was the fault of people not smart enough to develop properly with HTTP, but it was pretty easy to blame Google. The plug- in is long gone now. -- Scott ____________________ [1] http://en.wikipedia.org/wiki/Google_Web_Accelerator
From: Stefan Weiss on 26 Feb 2010 20:31 On 26/02/10 19:46, Jorge wrote: > This worry: > > 1.- You login to your bank at bank.com. > 2.- Your browser has a session cookie for bank.com > 3.- You open a new window. > 4.- You enter someOtherSite.com. > 5.- the page from someOtherSite.com does an XHR to someOtherSite.com > 6.- the response to that XHR is a redirect to bank.com > 7.- as a consequence of step#6, another request is made to bank.com > from the someOtherSite.com page > 8.- Does the request at step 7 carry the cookie of step 2 (that's my > worry) ? If the browser makes a request to bank.com (regardless of what causes the request), and it has a cookie for bank.com, and the secure flag of the cookie matches the request protocol - then yes, the cookie will be sent along with the request. You can't prevent that from happening on the client side, but it shouldn't be a big deal, because there are several layers of safe-guards which can limit the effect of this attack (see below). For reference, the problem you're describing is called "cross site request forgery" or CSRF (http://en.wikipedia.org/wiki/CSRF). Here are a few common limitations and work-arounds, most of which are in the back-end territory: 1) Request method: all sources of external requests on a web page (like <img>, <link>, <script>, CSS url, etc) except XHR and forms will trigger a GET request, and GET being idempotent, they won't cause any change in your bank account. Allowing GET requests to alter the server state* would be a serious fault in bank.com's backend, and I do hope that all netbanking sites are (now) safely beyond this beginner mistake. * actually, "altering the server state" is not a precise formulation, because GET requests can - and often do - reset the session timeout counter, for example. Other side effects on the server (like logging) could also be perceived as "altering the server state". 2) Same origin policy: XHR requests can use POST, but they are subject to the browser's SOP. Even if they did follow HTTP redirects (which, judging from my initial tests, they apparently don't), they wouldn't re-POST to the new location (as Richard explained). 3) Session duration/timeout: The user would have to be logged into bank.com's netbanking at the time of the attack, and the session would still have to be active. 4) Request tokens: a common way to prevent unrelated sites from spoofing a request from a logged-in user is to use one-time tokens on every form. These are created randomly and remembered on the server. Only requests which contain a valid token will be honored. 5) TAN/TAC, SMS, USB dongle, etc: most banks require some external code to finalize a transaction. Some send their customers a list of numbers with pre-generated codes, some use SMS to send that code, some require a USB device. I've even heard that some banks require you to boot from a CDROM they provide. All of these can effectively foil CSRF attacks. So, it's not that easy to get those $1000000 transferred to your account (jk ;-), but not all sites are as security conscious as bank sites (and even those have been known to use weak security). I've heard an account of one developer's boss who used the Alexa toolbar - I don't know if it still does it, but at that time the toolbar would automatically follow each and every link on a page, including /delete_item.php?id=123 etc. The boss managed to wipe the entire database several times before they recognized the problem and changed those links to forms. This was featured on DailyWTF, and the submitter apparently figured his boss or the toolbar were the problem, but they shouldn't have used links to delete records in the first place, IMO. -- stefan
From: Stefan Weiss on 26 Feb 2010 20:38 On 26/02/10 18:40, Richard Cornford wrote: > On Feb 26, 5:31 pm, Stefan Weiss wrote: >> On 26/02/10 18:06, Richard Cornford wrote: > <snip> >>> If an XML HTTP request object was going to refuse to >>> automatically redirect then it should present the status >>> 30X response to the calling code, and let it work out >>> what to do next. >> >> That is exactly what Firefox does. Opera also won't follow >> the redirect automatically, but its xhr.status value is 0 >> for some reason. >> >> I didn't try any other browsers, but I would be very surprised >> if any of them (the more recent ones, at least) could be tricked >> into sending an XHR which violates the browser's security policies >> by something as simple as an HTTP redirect. > > Why not? For a very long time it has been possible to 'trick' a > browser into making a request to another domain by setting the - src - > of a - new Image(); -. Making the request or not is not that important > so long as access to the result is denied. Yes, you're right. I addressed that in my reply to Jorge: an IMG src will always trigger a GET request, as will most other external references on a page. XHR is different in that it can send POST requests - but so can forms, and these, too, can be dynamically created and submitted. I've listed a few possible ways around that in my other reply. -- stefan
From: Ivan S on 27 Feb 2010 11:58
On Feb 27, 2:31 am, Stefan Weiss <krewech...(a)gmail.com> wrote: > 5) TAN/TAC, SMS, USB dongle, etc: most banks require some external code > to finalize a transaction. Some send their customers a list of numbers > with pre-generated codes, some use SMS to send that code, some require a > USB device. I've even heard that some banks require you to boot from a > CDROM they provide. All of these can effectively foil CSRF attacks. If I may add, hardware token generators and recently mobile software token generators which are becoming very popular (at least in Europe). Token number combins with (short) static password, as extra protection in cases of token generator theft or something like that. So ... there is always more than one way of authorization for banking transations. |