> Have you ever encountered a website that runs jQuery(location.hash)?
No. Actually I have never seen a website do that. What sites do that? What is the actual use of grabbing an element that has an ID that matches the URL hash?
And this attack will only work on those sites.
This is just one more variation of the best practice: don't trust user/client supplied data.
Edit: Though academically I actually find how this was implemented to be really interesting. I'm just not sure what uses it would have in the wild.
> What is the actual use of grabbing an element that has an ID that matches the URL hash
Well normally when you load such a page the browser will scroll down to that element. Perhaps this JavaScript wants to do something like highlight the section or extract the heading to send to some analytics?
I use it for linking to comments on my site. Users can copy a link to a particular comment, and the link directs people to the appropriate topic and location on the page.
I'm assuming that using X-Frame-Options to prevent the page from appearing in a frame prevents this type of attack.
> I use it for linking to comments on my site. Users can copy a link to a particular comment, and the link directs people to the appropriate topic and location on the page.
That works out of the box, it's a native HTML/browser feature.
Sometimes, due to your in-page navigation or some other fixed position element, you need to actually scroll to a point before the actual element, so that it doesn’t get covered. The native behavior would not give it the lead space and you’d see some of the element’s content covered by a static element.
In scenarios where you can’t redesign the html structure or css to give the element more padding, you pretty much have to use javascript to get the window-x position of the element.
Oh, my mistake, it's been a while since I wrote the code. I use it to style the linked comment. So, the browser automatically scrolls to the appropriate location, and then jQuery adds a style to that comment so the user can easily locate it, or refind it if they scroll up and down the page.
I’m not 100% sure but the first thought I had when reading it are the SPA routers that start with # by default?
I only read it on my phone without following along but if that’s the case then the text seems to hint at potentially brute forcing the authentication tokens? At least judging from the variable names.
Yes, it happens. It happens enough that jquery has fixed several times previous bugs that let you get immediate xss out of this. But yea, devs still need to also validate their input.
Browser do it based on name="" on anchor tags not ID. And if you are implementing your own version you should probably also be using name not ID. Best practice is t use JS to progressively enhance the page not reinvent the wheel so name is the logical choice.
Edit: Also, word of advise. Lose the "Ha!"... it could potentially make your comment come across as arrogant.
Edit 2: Leaving my original comment intact even though I was wrong. Apparently my knowledge is out of date on this one. Thank you "re" for correcting me.
Thank you. That is good to know. I really appreciate this info and the links. I'll file it under "things I learned 20 years ago that are now obsolete :("
I don't understand the point of this. What elements will a timing attack work against that you can't read the value from directly? I didn't notice any discussion of this in the article.
Edit: I see how this works. It will allow you to exfiltrate data from 3rd party websites that pass the URL hash into jQuery. An interesting idea but limited in scope.
It's described right in the article: embed the victim page in an iframe. Because of the same-origin policy you shouldn't be able to access its DOM, but with this trick, you can.
May be it is time for browsers to disable iframes by default and ask the end user if they want to run them via the standard browser confirmation mechanisms site by site.
And then you have a confirmation on almost every page, and then you run into dialog box fatigue where users will blindly click through them, and you've gained nothing.
yes. I block iframes globally and the web never been better.
it will show a checkered pattern with a link to open the frame in another window. so you don't even have to whitelist sites or anything. if you care about the frame, like for a embedded video, just open it on its own tab with a single click
uMatrix can block frames and js requests on a domain/sub-domain level. afaik, it can't block at url level, if that's what you meant.
That said, uMatrix, from what I remember, uses the webRequest api which does work from urls. So if you know JS, you can always create an extension and add your own filter.
To be clear, on the JS side I'm talking about providing whitelist-only access to things like the ambient light level, which is provided through a standardized browser API.
"Site Isolation" is the name of a specific feature. As of Chrome 67, Site Isolation is enabled by default on desktop, so only tabs from the same (scheme, eTLD+1) can share processes, and cross-origin iframes are moved out-of-process based on the same rule.
No. Actually I have never seen a website do that. What sites do that? What is the actual use of grabbing an element that has an ID that matches the URL hash?
And this attack will only work on those sites.
This is just one more variation of the best practice: don't trust user/client supplied data.
Edit: Though academically I actually find how this was implemented to be really interesting. I'm just not sure what uses it would have in the wild.