Closed pixeebot[bot] closed 7 months ago
Unable to locate .performanceTestingBot config file
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information
Processing PR updates...
Thanks @pixeebot[bot] for opening this PR!
For COLLABORATOR only :
To add labels, comment on the issue
/label add label1,label2,label3
To remove labels, comment on the issue
/label remove label1,label2,label3
Check out the playback for this Pull Request here.
Server-Side Request Forgery (SSRF) vulnerabilities are caused when an attacker can supply or modify a URL that reads or sends data to the server. The attacker can create a malicious request with a manipulated URL, when this request reaches the server, the server-side code executes the exploit URL causing the attacker to be able to read data from services that shouldn't be exposed.
PR Details of @pixeebot[bot] in pytorch-serve : | OPEN | CLOSED | TOTAL |
---|---|---|---|
15 | 15 | 30 |
[!IMPORTANT]
Auto Review Skipped
Bot user detected.
To trigger a single review, invoke the
@coderabbitai review
command.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
I'm confident in this change, but I'm not a maintainer of this project. Do you see any reason not to merge it?
If this change was not helpful, or you have suggestions for improvements, please let me know!
Besides the SSRF risks described above, a control like the one I suggested will also help protect against URL parsing bugs where attackers can present a URL that looks like one thing, but ends up being acted on as something else. A leading hacker in this space, Orange Tsai, has a nice visual of showing how humans and parsers will see the same URL differently in his legendary BlackHat talk:
This is why I wanted to introduce an API that forces you to provide the expectations of the URL at parsing time. There's really no downside, and this code will leave practically no opportunity of ending up in a confused and possibly vulnerable state. The code will be more clear and more safe.
If there are other concerns about this change, I'd love to hear about them!
This change may not be a priority right now, so I'll close it. If there was something I could have done better, please let me know!
You can also customize me to make sure I'm working with you in the way you want.
This change sandboxes the creation of
java.net.URL
objects so they will be more resistant to Server-Side Request Forgery (SSRF) attacks.Most of the time when you create a URL, you're intending to reference an HTTP endpoint, like an internal microservice. However, URLs can point to local file system files, a Gopher stream in your local network, a JAR file on a remote Internet site, and all kinds of other unexpected and undesirable stuff. When the URL values are influenced by attackers, they can trick your application into fetching internal resources, running malicious code, or otherwise harming the system. Consider the following code:
In this case, an attacker could supply a value like
jar:file:/path/to/appserver/lib.jar
and attempt to read the contents of your application's code.Our changes introduce sandboxing around URL creation that force the developers to specify some boundaries on the types of URLs they expect to create:
This change alone reduces attack surface significantly, but can be enhanced to create even more security by specifying some controls around the hosts we expect to connect with:
Note: Beware temptation to write some validation on your own. Parsing URLs is difficult and differences between parsers in validation and execution will certainly lead to exploits as attackers have repeatedly proven.
:x: The following packages couldn't be installed automatically, probably because the dependency manager is unsupported. Please install them manually:
Gradle
dependencies { implementation("io.github.pixee:java-security-toolkit:1.1.3") }Maven
More reading
* [https://www.hacksplaining.com/prevention/ssrf](https://www.hacksplaining.com/prevention/ssrf) * [https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf) * [https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) * [https://www.rapid7.com/blog/post/2021/11/23/owasp-top-10-deep-dive-defending-against-server-side-request-forgery/](https://www.rapid7.com/blog/post/2021/11/23/owasp-top-10-deep-dive-defending-against-server-side-request-forgery/) * [https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)I have additional improvements ready for this repo! If you want to see them, leave the comment:
... and I will open a new PR right away!
Powered by: pixeebot (codemod ID: pixee:java/sandbox-url-creation)