New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Header injection and path forgery [security issue] #511
Comments
n0npax
added a commit
to n0npax/http
that referenced
this issue
Dec 23, 2020
This was referenced Dec 23, 2020
|
|
n0npax
added a commit
to n0npax/http
that referenced
this issue
Apr 26, 2021
…-http-header-injection-fix
n0npax
added a commit
to n0npax/http
that referenced
this issue
Apr 29, 2021
natebosch
added a commit
to n0npax/http
that referenced
this issue
Apr 29, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I believe there is a security issue with the current implementation of
Request.The full example can be found here
What's wrong:
Requestis passing method verb as is to the stream without any kind of validation.basically:
generates request like:
What I'd expect
If HTTP verb(method) is not a part of the known set of verbs (GET/PUT/HEAD/...) I'd expect an exception to be thrown
Why this is a security risk
If the developer is using
Requestto abstract generating HTTP calls and he's accepting amethodparam from the user, the user can do some magic like header injection or path forgery.This can be exploited in many ways and seems to be quite important especially in case there is a reverse proxy is in place. A proxy may just pass someone's request to any host.
By running snippet behind a proxy, I was nicely redirected(like this) to
example.comwhich was injected as per the example above.Let's assume I'm replacing
example.comwithmy-hackery-uservice.organd the victim is working in a company behind the proxy. This means I can redirect calls with headers/cookies(tokens) and blah blah blah.The text was updated successfully, but these errors were encountered: