-
-
Notifications
You must be signed in to change notification settings - Fork 734
ascanrules: Added Detection for SSTI when a Redirect Occurs #6295
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
base: main
Are you sure you want to change the base?
Conversation
All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
Please investigate the unit test failures. Your change seems to have impacted some expected behaviour. You should add test(s) to cover the new behaviour as well. Also CHANGELOG.md should be updated. |
New Issues (5)Checkmarx found the following issues in this Pull Request
Fixed Issues (9)Great job! The following issues were fixed in this Pull Request
|
5447876
to
689c92e
Compare
…tatus of redirect created a work around instead of following a redirect to avoid SSRF fixed formatting removed getting the Location header
I am still struggling to find out why an SSRF vulnerability has been introduced in my code. I thought changing it to not follow redirects would solve this, but it hasn't. Any thoughts? Or advice on how to get more details on why/where this vulnerability may be emerging? |
Are you referring to something in the results above from psiinon? You can ignore that. |
Overview
In OWASP Juice Shop, a 302 redirect occurred after the SSTI payload was sent. This caused the POST response to contain information describing the redirect instead of proof that this field was vulnerable to SSTI. By adding one extra line allowing the sendandreceive function to follow the redirect the POST response now contains the changed username that proves there is an SSTI vulnerability and an alert is raised.
Related Issues
This solves issue #8816
Checklist
./gradlew spotlessApply
for code formatting