2

I am running a pentest on a web application, and I detected a vulnerability but I am not sure how to report it. I am confused if I should split it or document it as 1 finding. I will explain below.

So the finding is, a JWT token with large TTL value(finding 1 ) that is being saved in the browser local storage(finding 2), and and XSS script in one of the urls (finding 3). The combination of these 3 findings helped me do an exploit, the exploit requires the user to click on a link and sign in, and then the JWT Token of the user is sent to a remote server.

If I want to report all this, what is the best approach? Shall I report 3 findings + 1 poc? Or 1 finding and 1 poc? or ? And is the poc considered a finding here or it is just an exploit of the vulnerabilities detected?

1 Answer 1

3

My advise is to make three findings:

  • XSS: High risk, include the PoC here. The details of the other issues are naturally included because you have to write reproduction steps.
  • JWT token with large TTL: Low risk. Not a big deal in itself.
  • JWT token in local storage: Low risk. Not a big deal in itself.

The main reason for making three findings is that the fix for one doesn't fix the rest. If you combine them, retesting becomes terrible. If they accept the risk of one of the three, the finding will always be "partially fixed" even though they mitigated the main issue.

In the management summary and the findings meeting you can note that with some quick wins they can mitigate the risk of the XSS vulnerability by fixing the other two. However, because a pentest is a snapshot in time, fixing the other vulnerabilities doesn't change the risk in the report.

9
  • but why you considered JWT token findings are with Low risk? having a large TTL means the token if exposed to a malicous user, then it can be used for several days (ttl=10 days), and tthe fact that token is being saved in local storage, which means it is never deleted from the browser, this also raises a risk that someone with access to the browser to grab the token. When you say low risk, roughly what is the cvss score?
    – anonymous
    Apr 1 at 11:07
  • @anonymous: Where else do you propose the token be stored? It has to be stored somewhere in order to be used, and in a browser that means local storage or a cookie, and from the perspective of client browser compromise, there's no real difference. I'd consider the token storage 'finding' useless noise. The TTL is more debatable, and is a tradeoff in UX. It's real annoying to be frequently signed out (assuming there's no automatic token exchange mechanism).
    – josh3736
    Apr 1 at 12:24
  • I don't like to work with CVSS, but I take risk = chance x impact on a scale of Low, Medium of High. The chance of someone stealing the token is low, and the impact is medium (depending on the context and customer needs), so from my current knowledge it dangles between low and medium risk. The JWT token in local storage could just be the design. They can for example choose to accept the risk if they set the TTL to a reasonable timeframe. Apr 1 at 12:24
  • Hey we commended on the same time. Indeed, I agree that the storage thing doesn't need to be an issue. I'd discuss it with the devs or the client. Btw OWASP does have some pointers to harden local storage, like a fingerprint in the token: cheatsheetseries.owasp.org/cheatsheets/… Apr 1 at 12:28
  • @josh3736 but sacing the token in the local storage means that it is saved forever. However, if the token was saved in the cookie it will be deleted right after the session expires. In addition to that, cookie can protect from XSS in case it has the httponly attribute.
    – anonymous
    Apr 1 at 12:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .