11 comments

[ 3.3 ms ] story [ 33.8 ms ] thread
Created by wtfismyip.com - had a good laugh
Is there a bug bounty? I found an open redirect.
"You cannot add 127.0.0.1 or localhost as a callback URL"

...watch me.

Fortunately, redirection to a file: URL will result in a browser error. Unfortunately, the browser does not explain what is wrong (although the redirect can be viewed in the developer tools, you might not know to look there, and it still doesn't have an error message to explain the problem).
While that is true for modern browsers, some backend http client libraries will follow the redirects. So; if you have a system that given an URL that fetches + displays the content, and you use a service that issues redirects to things like the AWS metadata service, or file:///etc/passwd --- well, the backend library is gonna redirect to the bad place, if it only checks the initially submitted url.

  metadata.301party.com: 169.254.169.254
  ipv6.metadata.301party.com: [::169.254.169.254]
Why not just one name with both A and AAAA records? ...er, and why not fd00:ec2::254? (I now suspect that there's a subjoke here that I'm missing)
Couple of s/redirct/redirect typos
Can someone explain what this is?
I found a couple of fun tricks you can do with this (for some definition of "fun" anyway).

Go's http.Redirect function allows non-3xx statuses, and also renders a trivial page with a status message and link:

https://301party.com/451?url=javascript:alert(%27hello%27)

Alas not infinitely recursive but enough to make your browser give up:

https://301party.com/301?url=/301?url=/301?url=/301?url=/301...

[edit to add:] https://301party.com/0 causes a panic

I'm so used to getting 451's that the example flew right over my head. First reaction was, "ugh this again [reaches for vpn]".