This application is not using CSRF token but they are still able to protect sensitive actions on the site

Question

This application is not using any CSRF token and not even cookies to identify users on their server. All they do is use a authorization header to identify users. Since an attacker doesn't know value of this header he can't send cross site requests unlike in case of cookies, where they are automatically send along with the request.

I've never seen something like this but this is interesting for me because instead of using cookies, they used a header to authenticate users. This do two things with just one implementation. It authenticates users and also prevents against CSRF attacks (since headers are not send automatically in cross site requests like cookies)

How the question, is there any way to still bypass this way implementation?

Answer 1

How the question, is there any way to still bypass this way implementation?

As you've already said, it is a good protection against CSRF since the Authorization header is a) unknown and b) is not sent cross-origin.

These properties are no longer true though if the attacker finds a XSS in the original site, since then it might be either possible to extract the Authorization information or to misuse existing code in the site to send requests controlled by the attacker but same-origin. But XSS is also a problem with classic CSRF protection, so this is not a new attack vector specific for this kind of protection.

Answer 2

As was mentioned in a comment, this is actually an extremely common pattern for web services. Specifically, using Authorization: Bearer <token goes here> is a secure way for a client to authenticate to a service, which incidentally happens to be secure against CSRF. It's slightly inconvenient for browser-oriented web apps, as it requires requests to be made using JS rather that via HTML forms or similar, but there are frameworks where JS-initiated requests are the default way of communicating with the server anyhow.

Note that if it instead uses Authorization: Basic ... or Authorization: Digest ..., those are actually not secure against CSRF. Those authorization headers are based on a password the browser prompts the user for, and the browser subsequently sends them on every request to the server (including forged / cross-origin requests). Look up "HTTP Basic Auth" (or Digest auth) to learn more. They're not commonly used on consumer-facing web apps, but are reasonably common on routers and other networking hardware, IoT devices, and so on.

Assuming the web service is using bearer tokens, and that the tokens are securely generated, used, and stored (like any authentication token, bearer tokens are not inherently secure; if not implemented correctly it might be possible to steal them, predict them, forge them, guess/brute-force them, bypass them, edit low-privilege ones for more access, or so on), CSRF is not possible. XSS could still expose the bearer token (it has to be stored in the client's memory somewhere, usually in a JS variable or local storage if the client is a browser) but XSS strictly dominates CSRF anyhow in terms of possible exploits.

---

Another advantage of this type of auth scheme is that it can be used with services that have different origins, without requiring setting cookies for multiple sites, via CORS requests. This requires that the cross-origin endpoints be configured to allow the relevant header in requests from the origin of the site.

This limitation of cross-site requests can also be used to implement CSRF protection even when using cookies or similar; if you require the client to both submit a session token in a cookie (or other location) and any custom header, then web browsers will refuse to send the request unless the target site confirms that it's OK with the custom header being sent from the attacker's origin (the process of obtaining this confirmation is a "CORS Pre-flight request" and is sent automatically by the browser when a cross-origin request with a custom header is attempted). In that case, the value of the header doesn't even matter; the simple ability to include it is proof the request isn't a CSRF, and the authentication/session token is sent in some other way (such as a cookie).