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:
+ import io.github.pixee.security.Urls;
+ import io.github.pixee.security.HostValidator;
...
String url = userInput.getServiceAddress();
- URL u = new URL(url);
+ URL u = Urls.create(url, Urls.HTTP_PROTOCOLS, HostValidator.DENY_COMMON_INFRASTRUCTURE_TARGETS);
InputStream is = u.openConnection();
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.
Remediation
This change fixes findings identified by CodeQL.
Details
This change sandboxes the creation of
java.net.URLobjects 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.jarand 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.
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
Feedback | Community | Docs | Codemod ID: codeql:java/ssrf