-
Notifications
You must be signed in to change notification settings - Fork 8k
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
X-Forwarded-For handling is unsafe #2474
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2474 +/- ##
==========================================
+ Coverage 98.64% 98.66% +0.02%
==========================================
Files 41 41
Lines 1989 2026 +37
==========================================
+ Hits 1962 1999 +37
Misses 15 15
Partials 12 12
Continue to review full report at Codecov.
|
0ca3c51
to
12da875
Compare
Squashed according to contribution guidelines. |
Breaks API, but immensely improves security Fixes gin-gonic#2473
12da875
to
de0f9eb
Compare
looks good, @thinkerou this really should be merged, it's somewhat dangerous with the current implementation. and scary to realize this has been going wrong for 6yrs, since it was simplied; |
If you trust the proxy, the code would be a bit slower to get clientIp than before. |
no, anyone can add a |
If app is not behind proxies, "ForwardedByClientIP" should be set to false, so "X-Forwarded-For" will be ignored. |
but when it is behind a proxy it's very important that it will parse I guess I don't think the default |
Gin is suposed to be fast. |
You can't solve this problem with firewalls. I don't want to spend more time on this. Without this patch, spoofing client IP's is a cakewalk and there's no way way to prevent it. It's only a matter of time before it blows up in someone's face. Not mine, because if the Gin maintainers really don't think this sort of thing is important, who knows what other security problems are left around because speed is considered more important? |
I agree, this is basically a CVE worthy vulnerability... |
Hi @sorenh and @rubensayshi, |
@thinkerou this really should get some priority! |
Maybe you can define a client IP extractor. |
that's not the problem, the problem is that the current implementation for handling X-Forwarded-For is unsafe |
I disagree. The issues is not with the current implementation but with the general understanding of the community, for I find this PR to be a complicated and complex "fix" for something that can be managed and avoided with a simple config and general good "hygine". |
you're both making an great argument that gin should either not handle X-Forwarded-For at all, or do it the right way... either it needs to completely remove X-Forwarded-For handling (and let the middleware live in a different contrib repo), or it needs to do it properly. I'm of the opinion it should do it right, but not doing it at all would be acceptable as well to me. |
Not doing it at all sounds like a terrible idea to me. If the authors of a framework like Gin can't get this stuff right, expecting application developers to get it right isn't likely to get better results. |
Indeed.
Good for you. Not everyone does and nowhere in the documentation tells you do to this. Also, your setup is not the correct setup for many, many use cases. |
This is a complete no-brainer. There's a proposed fix that doesn't even change the default, terrible behavior. I thought leaving the defaults as-is would get this merged in a jiffy. I'd be more than happy to change the defaults to something that's actually secure, but come on, people. Unless you see actual problems with the patch, what possible reason could there be for not merging it? It solves real problems and doesn't change anything for people who don't care. |
@hadasbloom I think a CVE for this issue is perfectly reasonable, whether it gets fixed right now today or not. It's an existing vulnerability. Whether it ever gets fixed is anybody's guess at this point, but anything to alert users of this problem would be good. |
@sorenh I agree and hope it will be fixed soon. This was assigned the cve - CVE-2020-28483. |
@sorenh I agree and hope it will be fixed soon. |
@thinkerou @javierprovecho We need to take a look. |
This was flagged up by our vulnerability management tools, and I agree with the above, this behaviour needs to either be documented clearly or fixed. Great to see the maintainers jumping in and acknowledging that something needs to be done to fix this security issue. A shame we had to wait 6 month though, especially since someone spent some time to fix this at the time. It will raise question on how serious the team is about security. |
} | ||
|
||
func isTrustedProxy(ip net.IP, e *Engine) bool { | ||
for _, trustedProxy := range e.TrustedProxies { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be worth it to precompute the array of CIDR on engine.Run()
and save it to: engine.trustedCIDR
so we don't need to parse the list of trusted proxies every time, the ClientIP() is called
Original maintainer here! happy to jump and help to get this merged asap! |
After reviewing this PR we had some feedback about implementation to apply. Therefore @manucorporat opened a new DRAFT PR here, keeping the commit history: #2632 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not merge, we’re reviewing this PR.
I don't really understand why you can ignore this for almost 6 months and then suddenly hijack it. 🤦 Extremely bad form, people. |
We didn't hijack it, but I offered a different solution, also I forked your PR as a way you ensure you will be a Co-Author. Nothing has been merged yet, both PRs are open! While I am the original creator of Gin I have been out of the project for years already, just jumped to offer some help :) |
That sounds like textbook hijacking to me. I've been doing this stuff for decades, so idgaf, but this kind of thing drives new contributors away. I put time and effort into fixing this security issue. Then it gets ignored for 6 months and then, instead of providing constructive feedback, you just create another PR to fix it up. Especially when it's been sitting there for 6 months and then all of a sudden it can't wait another few days for me to address your concerns? Why even bother trying? Again, I've grown a lot of thick skin over the years, so I personally don't care, but if you care at all about future contributors, don't do this again. |
I'm in the same boat as above. Any updates on this pull request? For example, when a new version with a "fix" will be released? |
This pull request is for the 6 month old, functional patch that succesfully addresses a CVE, but the maintainers don't want. #2632 is the one that might have a chance of getting merged someday. Also: Seriously reconsider if you can use something other than gin. Since this is the attitude towards security problems, I'm out. |
Wow. Just wow. |
Allow specifying which headers to use for deducing client IP.
Allow specifying which proxies you trust to provide those headers.
Set defaults to match current behaviour.
Fixes #2473 and #2232