|
Top-level
 The slashes in the path part of the first url look different than the slashes in the scheme and everywhere in the second url. So my guess is that the first url is the malicious one. I would have missed it if I hadn't been looking for a difference though. Thanks for the info. 8 comments
@EnaWasHere @threetails @suprjami @bjb Both are true. Fake slashes make everything before the @ a “username” and v1271.zip the domain name.  @EnaWasHere @bjb @suprjami it's the @. Everything between http(s):// and @ in interpreted as a username and potentially a password, the part after the @ is the host and path. @dragonfrog @EnaWasHere @bjb @suprjami That's not quite right, the username/password part cannot contain (amongst other things) forward slashes. This attack is relying on using a unicode character that looks like a forward slash but isn't one. @jribbens @EnaWasHere @bjb @suprjami I see, it's both the @ and the pseudo-slashes. Thanks for pinning that out. @bjb @suprjami so basically this is yet another occasion where unicode hurts instead of actually helping.. why can someone register a domain with deceptive symbols in it?? @tizilogic @bjb @suprjami This attack doesn't involve unicode domains - there are unicode characters involved but they're not part of the domain name, which is entirely ascii. |
Gregory's Server
@bjb @suprjami ooooh I hadn't notice that detail! I was going for the @ in the address