
Exploiting URL Parser in Programming Languages (2017) [pdf] - tosh
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
======
treve
Am I correct to understand that the main exploit here is:

A) A server that makes HTTP requests. B) It does so based on a white or
blacklist C) These white or blacklists are circumvented due to bad parsing D)
This can be used to call unintended services (and sometimes protocols).

I had an idea to build a generic Webhook service. My thought was that the
actual machine that does the requests should be 100% isolated from our VPS and
only have public network access. Would that largely stop this attack? Perhaps
it should also have a rate limiter to prevent DDOS attacks.

Waiting for every url parser to be fixed seems impracticable. This to me is a
great example of why the WHATWG url specification is so terrible. It's so much
harder to implement than RFC 3986.

Things that aren't browsers should just implement RFC3986 and reject anything
invalid.

~~~
nothrabannosir
Check out the TLS SNI exploit. The attack allows embedding CRLF in a TLS
payload. The entire handshake leading up to it is ignored by an SMTP server,
and the next command is valid SMTP. Meaning that if you ask something to e.g.
load an image from, or send a callback to
"[https://smtp.targetcorp.com<space><CR><LF>...smtp](https://smtp.targetcorp.com<space><CR><LF>...smtp)
instructions to send mail here...:25/" it'll actually work. As far as I
understand this is the TLS handshake so even before any HTTP is done; post,
get, whatever. All works.

Good moment to lock down outgoing requests, I guess. At least to port 25 :)

~~~
userbinator
I've not communicated with SMTP servers manually all that much, but I remember
my ISP's SMTP server would just close the connection if you sent it something
it didn't understand.

~~~
Kalium
That sounds like most SMTP servers - they just reject what they don't
understand.

The wrinkle here that might be, in the opinion of some, worth noting is that
this gives SMTP servers something they understand fully. The HTTP server has
been convinced to send perfectly well-formed and valid SMTP commands.

------
subcosmos
Saw this talk at Defcon last year. Left the room .... pretty nervous ....

This isn't it, but same title and content
[https://www.youtube.com/watch?v=D1S-G8rJrEk](https://www.youtube.com/watch?v=D1S-G8rJrEk)

~~~
charlysl
Yet another one:

[https://www.youtube.com/watch?v=2MslLrPinm0](https://www.youtube.com/watch?v=2MslLrPinm0)

------
nebulous1
This doesn't seem designed to be read without the accompanying speech

------
Go0the0gophers
Just fuzz every parser you write. And the problem is solved.

~~~
whyever
I agree with the idea, but I don't think it is enough: A fuzzer does not
necessarily find all problems.

~~~
Go0the0gophers
I wrote several parsers that I fuzzed with tools like AFL or gofuzz. And I
promise you that fix lot ugly corner cases.

------
LolNoGenerics
Wow this is brutal! I wonder how safe apache and nginx are?

------
enedil
It was posted before [1] and thus I know the paper isn't from 2018. Should it
be added to title?

[1]
[https://news.ycombinator.com/item?id=14879488](https://news.ycombinator.com/item?id=14879488)

~~~
dang
Added now. Thanks!

~~~
billpg
It was only a year ago. Would it be substantially different if written today?

~~~
dang
It's just an HN convention to have the year in the title when the article
isn't the current year. Not only does it not imply badness, it's associated
with goodness, since most things from previous years have lost their interest.

