JavaScriptServlet causing noise in various bug bounty programs

[kwwall]

It has come to my attention that less senior security researchers participating in various bounty bounty programs are reporting that when they call an application protected by CSRFGuard and using JavaScriptServlet and the researcher attempts something like (say) https://example.com/myapp/JavaScriptServlet, they see it returning JavaScript source code and they are reporting that as the application's proprietary source code as being leaked!! Apparently they are too busy to note that the JavaScript source code that is displayed is clearly identified as being part of OWASP CSRFGuard Project. Based on the JavaScriptServlet source code, it appears that this is intentional (it will even display the JavaScript code if CSRFGuard is disabled), but this particular behavior is creating noise by it getting reported in various bug bounties because it takes time to triage these and respond to the researcher. (As an example, for a single application, this was reported twice in just a matter of a few days.)

So, my question is, is this behavior, especially on GET requests, really needed, or is it just some sort of debugging? And if it is the latter, would it been too much trouble if it looked at some new debug related property in csrfguard,properties and just emitted "Debug is disabled" as the default? Or, if the present doGet() is not just for debugging (I expected it to find something similar to ajax.html, but under 'csrfguard/src/main'), can we at least figure out some better way to not have non-attentive junior security researchers not report it, but making it harder to trigger, etc.?

[forgedhallpass]

Hello @kwwall,

1. they see it returning JavaScript source code and they are reporting that as the application's proprietary source code as being leaked

In case of applications that require an authenticated session to access the functionalities, the login filter should not allow access to resources (including to the CSRFGuard JS logic) for un-authenticated users. If this doesn't happen, less experienced hunters might think of it as a vulnerability.

Either way, this is client side JavaScript logic which is meant to be interpreted by client browsers. Everyone is welcome to analyze the JS code and look for vulnerabilities there :)

2. Based on the JavaScriptServlet source code, it appears that this is intentional

This is intentional, indeed. Please refer to #52 (comment)

3. (it will even display the JavaScript code if CSRFGuard is disabled)

If CSRFGuard is disabled, the JavaScript code is NOT returned. Please see:

www-project-csrfguard/csrfguard/src/main/java/org/owasp/csrfguard/servlet/JavaScriptServlet.java

Line 168 in a2179c1

final String javaScriptCode = "console.log('CSRFGuard is disabled');";

4. but this particular behavior is creating noise by it getting reported in various bug bounties because it takes time to triage these and respond to the researcher

This is unfortunate, and I can imagine it can be frustrating, but this is not a problem of this solution. If the target application doesn't make use of JSPs, the JavaScript logic is needed on the client side to request and assign CSRF tokens.

5. So, my question is, is this behavior, especially on GET requests, really needed, or is it just some sort of debugging?

It is really needed and it is not for debugging.

6. I expected it to find something similar to ajax.html, but under 'csrfguard/src/main'

The ajax.html is only used to test the JavaScriptServlet's AJAX functionalities within the demo/test application.

7. can we at least figure out some better way to not have non-attentive junior security researchers not report it, but making it harder to trigger, etc.?

The problem seems to be with the bug bounty program scope and education of people reporting such non-issues. Maybe creating a standard response for such cases and limiting the BB scope would solve this.

Because on how CSRFGuard was designed, I don't see a way around this, and even if there was one, changing the architecture of a solution for such reasons simply wouldn't make sense/worth the significant effort.

Implementing #31 (JS code minification) could also potentially discourage hunters to report such (non-)issues, but it is not a priority because nobody requested it, and I haven't found a nicely integratable solution to do so either. That being said, as a quick solution, I can do the minification manually and can create a new release with it, if you think that helps.

[kwwall]

@forgedhallpass - Thanks for your reply. I suppose we could also have our development teams alias JavaScriptServlet to something like OwaspCSRFGuardJavaScriptServlet and maybe that would help clue in the less experienced researchers who apparently are too inconvenienced to notice the initial copyright notice of the returned JavaScript. Sigh.

P.S.- I unmarked your reply as an answer and marked it that way myself as believe the intent of these Q&A discussions is that they answer is in the eyes of the questioner and especially makes sense in the light that multiple replies to the question might be made. Plus, as a responder, I think you get more brownie points it you are not grading your own paper! 🥇