Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Grafana allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share beautiful dashboards with your team and foster a data driven culture. Grafana ONLY uses cookie flags for CSRF protection. This article is about abusing this.

In Grafana, cookies have been marked SameSite=lax on the session cookie since version 6.0. This theoretically prevents cross-site request forgery attacks against the website. What does the SameSite=lax actually entail though? The cookie will only be sent in two cases: top-level navigation (GET request) or a same-site request.

The top-level navigation on the application did not have any state changing actions. The same-site request seems like a tall order, but can be abused in some situations. First off, same-site does not mean same-origin. Same origin is defined as a domain being on the public suffix list. This means that all subdomains on a given domain (x.maxwelldulin.com and y.maxwelldulin.com) would both send the cookie. This is a subtle difference but is super important in the land of exploitation.

Since Grafana can have embedded pages inside of the website, an attackers embedded web page could launch CSRF attacks with the authorization cookie attached. Additionally, if another site was on the same domain, then an attacker could perform the CSRF attacks as well since it would be on the same site. Not good!

Within the application, it is also possible to turn off the SameSite cookie flag. Since Safari and Chrome (for 2 minutes) default to None for the setting, this makes the application vulnerable to CSRF attacks.

Grafana does use json though, which triggers a pre-flight request. From my understanding, only 3 MIME types for POST requests do not trigger a pre-flight request. However, there is more than what meets the eye here! According to the fetch standard, the essence of the MIME type specified must contain one of these three values.

This means that multiple entries in the header will NOT trigger the pre-flight request as long as a simple one (such as text/plain) is in the header. Damn, that is super interesting! The standard 'My JSON request is safe' from CSRF' should not be a given then. If the Content-Type validation is weak, then this could lead to a serious CSRF attack!

By launching this attack on the website, it worked! According to the code, the Content-Type must contain JSON instead of being JSON. This slight difference makes the CSRF attack possible since a pre-flight request does not occur and the Content-Type is not properly validated.

Overall, I enjoyed the article with a novel (at least, to me) CSRF protection bypass for pre-flight requests. The Same-Site cookie flag is not a solution for all of the problems; it should be considered defense in depth.