Introduced protections against user-controlled internal request forwarding

[pixeebot]

This change hardens all ServletRequest#getRequestDispatcher(String) calls against attack.

There is a built-in HTTP method for sending clients to another resource: the client-side redirect. However, the getRequestDispatcher(String) method is unique in that performs a forward which occurs totally within the server-side.

There is some security that usually comes within redirecting users back through the "front door". For instance, attackers could never directly request sensitive resources like /WEB-INF/web.xml. However, this isn't true for request dispatcher forwarding. Therefore, we must take special care that the path being forwarded isn't towards any known sensitive data.

Our change introduces an API that offers some validation against forwards that target sensitive data or attempt to access application code.

+ import static io.github.pixee.security.jakarta.PathValidator.validateDispatcherPath;
  ...
+ validateDispatcherPath(path);
  request.getRequestDispatcher(path).forward(request, response);

More reading

• https://cwe.mitre.org/data/definitions/201
• https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html#dangerous-forward-example

I have additional improvements ready for this repo! If you want to see them, leave the comment:

@pixeebot next

... and I will open a new PR right away!

🧚🤖 Powered by Pixeebot

Feedback | Community | Docs | Codemod ID: pixee:java/validate-jakarta-forward-path

[pixeebot]

This library holds security tools for protecting Java API calls.

License: MIT ✅ | Open source ✅ | More facts

[pixeebot]

This library holds security tools for protecting Java API calls.

License: MIT ✅ | Open source ✅ | More facts

[pixeebot]

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!

[pixeebot]

Forwarding is a dangerous by nature, and this API helps -- but some access to protected resources may be intended, so the control can't be very aggressive.

I think you should merge this protection to address some obvious risks and prevent exploitation by automated tools which can only target common and predictable targets. However, long term, I think you should consider an alternative architecture which doesn't rely on forwarding.

If there are other concerns about this change, I'd love to hear about them!

[pixeebot]

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.