I can imagine you could work around that issue just by once redirecting onto your own site first.
On the surface, sounds like a difficult problem to solve safely. On a related note, I often have the back button not work because I hit back and chrome cached a redirect to some other page and it immediately redirects again before i can even spam back again. Need to long press back to get a longer history to go back further.
I don't understand. Are you suggesting that if you arrive at a site from Google, the history API should just not work?
For example, let's say a user arrives at a single-page application from Google, and clicks a link on that page to get more information. The site adds a history entry with pushState, but doesn't reload the entire page. Are you saying that in this case, when the user clicks back they should get sent back to Google instead of to the site's home page? If so, that seems like rather unexpected behavior. And if not, isn't the attack still viable?
It's possible to create a redirect loop, i.e, a URL that redirects to itself. I don't know if it's something that should happen or not, but Chrome gives me an error after too many redirects.
Note that the original redirect is a 301, so Chrome will keep redirecting you even if you paste the URL in a new window. Clear your cache or use incognito to avoid it.
Potential workaround: redirect a more bearable amount of times (2-3) every time a user clicks a link on your website. An aggressive ad network could also do this across websites.
The issue is that some web applications don't load what traditionally were discrete pages (e.g. PAJAX) with their own URLs. It's a trend you'll find in sites built to feel more like applications. Scroll the the bottom of an onion.com article and watch your URL update to the next page without a page refresh. This was done so modern sites built like this could still allow the user to navigate back and forward. It let's the site update the browsers location history and effectively what URL that back button will point to. I could imagine blocking this behavior if it points to a site off the TLD and it's sub domains. Hard pressed to figure out how they could prevent this, definitely a flaw in the trust model but probably worth the trade off.
You can use javascript frame busting techniques to redirect back to the main page. You can also use mod_rewrite or some proxy setups to make it so a completely different set of pages shows up for people coming from that site. This is better than just blocking it because it's a bit more subtle and lets you tell that site's users what's happening.
That would make for terrible UX, and I'd expect most users to just shrug it off as your website being weird, so it wouldn't even help you "catch pages that use the wrong protocol".
Why not just do the redirect that you know is right, but log it (with referer, so you know what needs fixed)?
For future reference, you can rate limit bandwidth with dev tools in Chrome (and probably Firefox), which makes it a lot easier to dodge redirects in situations like this.
I doubt it, as this method breaks forward/back functionality, thus probably breaking most sites.
Having said that, for all links, you could do a further re-write using the history API, before allowing the redirect to take place. I guess that would actually make it usable even if, as you say, it's futile in the end.
Suppose I send you a link to a page I own. I start this thing on said page and track what you do with the rest of the session on the off-chance that you do something sensitive with it. It's like a single-tab key/screenlogger. Combine this with traditional phishing methods (which already work) and you might get valuable data. It's going to be at least as effective as current phishing methods, with the added advantage of not asking for personal data on the landing page as well (so users don't get scared off).
A similar attack would be to override the back button. You know those sites where the back button takes you to a redirect that takes you to the same page? Take one of those, but on the redirect page save the referring URL. Then when the user hits back, have the redirect page start the session sharing and redirect to the referrer. Sounds plenty dangerous to me.
Tip from me: If the user tries to visit a specific URL and they have to log in first, redirect the user back to the original URL once they've logged in instead of sending them to some generic account page. It's super annoying and disorientating otherwise.
Isn't that impossible? You can redirect to a page (under your control) that redirects to itself, if your goal is to get the user stuck in a redirect loop. Until their browser decides enough is enough, that is.
Anybody have any idea about how they did it? Sorry for the noob question but I can't really figure out how they did it, since the original page loads fine and only after this there's some kind of redirect.
And as I can see it only affects certain pages so maybe there's a compromised component that's loaded on those pages?
One slightly annoying thing, if I'm logged into manage.statuspage.io and I browse to statuspage.io, please don't redirect me back to manage.statuspage.io. I really did want to re-read your web site content whilst fiddling around trying this out for the first time. Don't make me log out to do this.
Also, after having logged out I browsed to statuspage.io (exactly what I typed) which redirected me to https://www.statuspage.io and Chrome complains that some content is not secure.
Other than that I've passed the url around some of our folks to see if we could use this.
I'm interested If that behavior will be the same when using web.dev
Usually when I enter a site to test it there, it always tells me to avoid redirects. I think HSTS would would have also solved this, but our (managed) hosting provider does not offer this as a default, and doing it manually for the amount of sites is not really practical. At least not the sites that are already done.
On the surface, sounds like a difficult problem to solve safely. On a related note, I often have the back button not work because I hit back and chrome cached a redirect to some other page and it immediately redirects again before i can even spam back again. Need to long press back to get a longer history to go back further.
This is a really interesting "attack" to see.
reply