Since this comes up somewhat regularly and I keep writing examples anew, this is a small post with some difficult URLs.
The format of these items will be:
https://example.comexample.comClick and hold the black area to reveal it. Try to think about it first and then see if you got it right. Here we go:
https://example.com.example.net:example.nl@example.org
Controller: example.org
https://one.example.com%2eexamp1e.org/example.net
Controller: examp-one-e dot org (examp1e.org)
https://example.com@example.org:example.net%73%6f9ui%33oqkrt@bai4u.tk%2e%6c%67%6d%73%2e%6e%6c/%7d%45%61%35.example.nl/%37%38%62%33%68%77%6a%55%49lgms.nlThe next one is a bit of a trick question, but a real-world situation. We find this at customers fairly regularly. This link might be sent to you as part of a "password expired and needs to be changed" kind of message, if your organisation does that. If you work at example.net, where does this link go?
https://secure.example.net/change-password/userId=414%23314%814&session-login-token=%24c8%5b/%2e%2e/.%2e/l%6f%67o%75t?%72%65%64i%72%65%63%74%5f%75%72%6c=%6cg%6d%73.%6e%6clgms.nlThe tricky parts of the above link are these:
Mixed use of URL-encoding to obfuscate where it goes
The /change-password part of the link does not even exist. The link tells the browser "please navigate to /change-password/userId=whatever/go-one-step-back/go-another-step-back/" and only then the actually existing part starts. An attacker can put something completely legitimate-looking there, no matter whether this exists. Your browser resolves this part of the URL, so the server can't detect or block the attack.
It uses the logout link. What happens if you weren't logged in? Many logout systems still redirect you to the indicated link as next page. This doesn't rely on your login status.
https://secure.example.net/change-password/userId=414#3144&sessionid=$c8[/../../logout?redirect_url=lgms.nlI think we should agree that knowing where a link goes is not trivial.
All of these links can be made to have the green padlock, look identical to the originals, etc. That's all trivial and we should not tell people to look for those features to establish authenticity. The padlock indicates security, but not who you're talking to... well, it tells you that you're talking to whatever domain you're on, but figuring out which domain you're on turns out to be hard.
But luckily, in real-world cases, if you see a lot of weird-looking characters in a URL, you know something fishy is going on... right?
https://u710123.ct.sendgrid.net/ls/click?upn=wWR-2Am6ZbrnHXrgXm9T21nSCr31DUXP7Dt5YU2nFF2EfEbIAue40j-2FbURhaoirKVKsd-2Fl1TLlfn1imGKL[...]
This goes where, exactly? That's from the latest newsletter I received, completely legitimate, but there is no way to know when clicking the link.
Perhaps we should just tell users to not click links in emails. Your company wants you to change your password? Great, go to your company intranet the usual way. You need to login to your bank for some KYC procedure? No problem, just visit your bank the usual way.
Companies can also do their part by not putting links with calls to post-login actions in emails.