
URL obfuscation (2002) - freebyte
http://www.pc-help.org/obscure.htm
======
eridal
I used to use [http://127.1](http://127.1) for laziness until I've found that
I was able to use [http://0](http://0) which is even lazier :)

~~~
wybiral
Thank you. I had no idea...

------
jchw
Thanks to the rapid adoption of TLS, HTTP/1.1, and CDN services like
Cloudflare, it's hard to actually find IP addresses to test some of these
tricks on. However, it seems like at least some of this stuff really does
still work.

Here's one for example.com. Without the host header, it still misbehaves, but
it at least does something.

[http://1572395042](http://1572395042)

~~~
hdhzy
Firefox for Android displays it as
[http://93.184.216.34/](http://93.184.216.34/) after opening the page.

~~~
yorwba
Firefox on Linux also displays it as 93.184.215.34 on hover.

~~~
notamy
Same with Chromium on Linux.

------
jaclaz
>Last Updated Sunday, 13 January 2002

~~~
hdhzy
Yes, exactly. The @ trick is being removed from browsers because what the
author refers to as interesting trick has been used for phishing and other
scams.

~~~
frik
Since when is destroying web standards acceptable? There are so many internet
and intranet pages from 1994+.

In the name of security the change way too many moving parts lately to push
their hidden agenda.

Using HTTP in local LAN is fine. Using HTTP for non login-pages is fine. Using
"basic authentification" (user:pwd@IP) is fine for certain use cases. Stop
breaking things.

I am not using a Firefox anymore, they went insane lately, they don't bother
about their community anymore. I am worried about Chrome too, TLS only for
HTTP/2 is the wrong signal. So many times I couldn't open a HTTPS sites
because the browser thinks the cert is broken - it was just a trivial page
were I just want to read some text (not input anything) - just some me the
page - something that wouldn't be a problem with HTTP.

If Firefox, Chrome or whoever want to destroy access to 1994-2017 websites, go
to hell. Name your forked off thing TheMicrosoftNetwork (or what not) and see
it tank rather quickly.

~~~
Spivak
Keep in mind they're not breaking HTTP basic auth, they're just just removing
the ability to specify credentials in the URL because its legitimate use is
extremely rare but its use in phishing is common.

------
dmurray
These are interesting as curiosities, but most of them are not interesting
from the point of view of deceiving users, and this was the case even when the
article was written.

It's trivial to make users think they are not visiting evil.com, or just to
serve evil content from evil2.com instead. This means a blacklist model of web
addresses will never work, and even the most naive computer user uses a
whitelist instead, if they pay attention to urls at all.

The username:password@evil.com/... trick is the exception, and it's good that
browsers are working on ways to mitigate this.

~~~
styfle
A lot of large organizations purchase domains that are similar to theirs to
avoid typo-squatting as well as the impersonation you pointed out.

The creation of new TLDs in the last few years only increases the
permutations.

For example:

[http://google.com](http://google.com)

[http://com.google](http://com.google)

------
theEXTORTCIST
The data URL scheme is abusable.

Firefox and Chrome correctly redirect to localhost via javascript

    
    
      data:text/html,http://www.mostSecureInternetBankVictim.com/customerLogin.php%2FreallyLoginRandomData=130r193fj02jf-2jf023f23f-f2039f0239jf0a-39j029jg90wgj-9203f092jf0f-90e9f204fh0-9hf2ef8CUSTID=923r9032fdjnnvjddata%3Atext%2Fhtml%2C%3Cscript%3Ewindow.location%20%3D%20%22http%3A%2F%2F2130706433%22%3B%3C%2Fscript%3EValuedGoogleCustomer=?Security=trueEncrypted=trueSecureBrowsingSession=True

------
101km
[https://link_back_to_this_thread(doesntactuallyworkbecausecl...](https://link_back_to_this_thread\(doesntactuallyworkbecausecloudflare\)@0x68142C2C/69%74%65%6d%3f%69%64%3d%31%34%39%39%37%35%31%32)

