-
Notifications
You must be signed in to change notification settings - Fork 692
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
[security] Path parser inconsistency could lead to bypass several security checks in emicklei/go-restful #497
Comments
Thank you for reporting this. I will investigate this further. |
i was able to reproduce this issue. your example output
go-restful example:
go-restful output:
|
here, the slash is trimmed Line 167 in c2c010a
now the problem is that change this code will break existing behavior ; client of the package may be affected negatively. |
@emicklei May I know any update on this? As OTEL has used this package, it's affecting many other users using OTEL images. thanks! Report from Security scanning tools: |
Hello guys, Is there any update on this? |
hi all, sorry for the delay. I will add this feature flag as mentioned. Will that suffice? |
After the change, two test fail. Need to check if the test was correct in the first place
|
please check #511 |
@JamieSlome i believe the PR will fix the reported issue |
Looks like the PR is still not merged yet, probably due to the code test coverage filed? |
PRISMA-2022-0227. The fix or an ETA is appreciated. |
Should this PR be closed since PR #511 has been merged? |
hi. did the fix for this issue address PRISMA-2022-0227? a scan against v3.10.1 suggests the vulnerability is still here (?). |
I'm not sure this is a bypass. Yes, go-restful handles trailing slashes differently than net/http, but how could a bypass realistically occur? From above go-restful example,
The presence or absence of the trailing / won't cause the authorization check to be skipped, or the wrong route to be selected. I'm trying to think of a realistic example where it would, and I can't. |
This addresses PRISMA-2022-0227 which has no entry anywhere useful on the internet but is reported by IronBank. It has a fix for emicklei/go-restful#497. Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
Updates the go-restful dependency from version 3.8.0 to 3.10.2 to address the following: emicklei/go-restful#497
Upgrading go-restful package from 3.9.0 to 3.10.0 to address [PRISMA-2022-0227](emicklei/go-restful#497)
Is there a CVE assigned to this bug? |
Hey @emicklei - sorry to resurrect an old issue, but there has been a surprising amount of noise in the Go community around this - particularly due to the fact that Prisma cloud is reporting this as a high severity issue and the decision to not upgrade this dependency by some members of the k8s community (which I personally think is quite reasonable). I'm in agreement with @brutif above, I'm struggling to see how this bug would ever constitute a security vulnerability. Barring a very bespoke authorization system, I can't imagine a situation in which this issue could reasonably be considered a vulnerability. The code example provided in this issue feels contrived, and to me only demonstrates unusual/unexpected behavior. It takes quite a leap of logic to consider that behavior to be a security vulnerability, in my opinion. I'm wondering, as the maintainer of this project, do you consider this to be a valid vulnerability? If you do not think it is, and are willing to indicate so publicly in this issue, I'd be happy to open a case with Palo Alto to see if we can have the prisma-2022-0227 vulnerability removed from their database. Thank you! |
hi @eastebry , thank you for notifying me about this ongoing discussion. I need to spent some time on reading the status and reasons for not upgrading (btw the breaking change was reverted in a later release). I will get back to this issue later. |
Reported via huntr.dev here.
Created:
May 28th 2022
Description
There is a inconsistency between how golang(and other packages) and go-restful parses url path. This incosistency could lead several security check bypass in a complex system.
Steps to reproduce
Copy and run the code below
Now If you send a request to the http://localhost:8081/users/id_will_be_here then you will get a hit to the expected endpoint and it will check the authorization part
Now if you send a request to the http://localhost:8081/users/id_will_be_here/ (notice the extra / in last) then this server won't process this request as the path name doesn't match but the problem is that go-restful treat this path and the previous as same.
So this inconsistency could lead some issues in this scenerio as the first sever wont check the security checks but the second server(go-restful) will return user data.
Impact
Security check bypass
Occurrences
web_service.go L80
The text was updated successfully, but these errors were encountered: