We all should stop reporting missing headers just because Burp Suite burps it

Sure, I’ve reported HSTS and cookie secure flags more times that I’d admit just because Burp says so.

Sometimes customers are ashamed to ask how things work or why any header would improve its security posture, sometimes even security consultants are afraid about it. One day a curious customer just asked about the headers issue and I was completly nude, my only argue was that Burp showed it in the Dashboard. From that moment I told myself that I wouldn’t report things that I cannot even understand or back up in a report readout, so I used a new fancy tool called Google to learn about headers and its purpose

Chapter 1 — Secure Cookie Attribute

Once upon a time there was a web application which session was managed exclusively through JWTin the Authorization header. There was, of course, some cookies and other headers injected by the underlying framework or the cloud load balancers, but none of them managed any aspect of the session or authorization. Someone just thought that it would be a good idea to report the absence of secure cookie attribute.

So what’s the deal here? According to OWASP:

The purpose of the secure attribute is to prevent cookies from being observed by unauthorized parties due to the transmission of the cookie in clear text. To accomplish this goal, browsers which support the secure attribute will only send cookies with the secure attribute when the request is going to an HTTPS page. Said in another way, the browser will not send a cookie with the secure attribute set over an unencrypted HTTP request.

The thing is, we’ve been always talking about cookies, but in our scenario there was no interesting cookies to be read/retrieved/stolen, everything relied on a JWT in an Auhtorization header, so it does not really matter if secure attribute was not set.

Chapter 2 — Content Security Policy in an API

Sometime we don’t take in mind the entire context of our scope, i.e. testing an API is not the same as a Web Application even though both are using HTTP requests. An API usually returns formatted text, json in most of cases, and if it’s properly configured then the Content-Type won’t be manipulable and we’ll receive all as application/json, no matter how. Here, another colleague though that it would be valuable to report the absence of CSP header for an API. Burp just triggered an alert!

According OWASP:

Is a W3C specification offering the possibility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification use “directive” where a directive defines a loading behavior for a target resource type.

Json responses are just formatted plain text that are not able to load resources and they’re not rendered by the browser in terms of loading images, links or scripts located on external sites as an HTML may do. So, does it have any sense to report the absence of CSP header for an API based on json?

Chapter 3 — JWT and localStorage

XSS has become one of the most popular attack vector on webapps, specially because you can pop-up and alert and that’s so 1337! Regarding XSS, one of its most mentioned and harmful technique is the cookie stealing through the document.cookie statement and that’s because (IMHO) some developers -and their bootcamps- have become afraid about cookies and all its messy attributes.

As a result of this, JWT has been widely adopted as a value for theAuthorization header and some frameworks and developers prefered to manage this tokens through localStorage, but OWASP recommendation says:

Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.

Conspiracy against cookies

Surprisingly, cookie, one of the most attacked and valuable attributes on web environments is still secure enough to trust on it sensitive data if it’s properly configured, but localStorage remains as the prefered location to save bearer tokens for those developers that just learnt that way.

Take in mind that localStorage has no security attributes and values will be always accessible by Javascript, so they could be retrieved by an XSS just using alert(localStorage.getItem('<key>')) and, as far as I know, there’re no mitigations for this purpose.

Conclusion

For sure, nobody wants to deliver an empty report and missing HTTP headers are always there to raise, at least, an informational misconfiguration flaw, but we should never rely on tools’ results just to fill a report with random and worthless recomendations without context or trust on wide used configurations.