We run a vulnerability reporting program through HackerOne. Many reports we receive through this program are extremely valuable and this program is an important part of keeping Phabricator secure.

However, report quality can also be uneven, and sometimes we receive reports from researchers who haven't put in the work to fully analyze and understand the issue they're reporting. A particular common pitfall is reports with titles like "CSRF Vulnerability", which describe this "vulnerability":

Alice (a victim) can make a request to Phabricator and receive a CSRF token in the response.

On its own, this is not a vulnerability. Researchers who report this as a vulnerability are fundamentally misunderstanding CSRF attacks and the behavior of CSRF defenses. This is the normal behavior of all CSRF systems, and this behavior indicates that the CSRF system is working properly and behaving exactly as designed.

In particular, this behavior does not imply that this attack works:

1. Alice (a victim) can make a request to Phabricator and receive a CSRF token in response.
2. That must mean that Eve (an attacker) can make a request to Phabricator and receive one of Alice's tokens, too.
3. Thus, Phabricator is vulnerable to CSRF.

This is wrong. Here's a similar "attack" which does not work for the exact same reasons:

1. Alice can make a request to Phabricator and receive her private messages in response.
2. That must mean that Eve can make a request to Phabricator and receive Alice's private messages, too.
3. Thus, anyone can read anyone else's private messages.

Both of these chains of reasoning are wrong. In step (2), Eve can only receive information for Alice (her CSRF tokens, or her private messages) if she controls Alice's session key.

If you've found a way that Eve can gain Alice's session key, great! You may have found a real vulnerability. We'd be happy to receive a report of it. But this is a session theft vulnerability, not a CSRF vulnerability.

This attack also does not work, for very similar reasons:

1. Eve can trick Alice into visiting evil.com, a site Eve controls.
2. That site can make a request to Phabricator using Alice's session key, then read Alice's CSRF token from the response.
3. Thus, Phabricator is vulnerable to CSRF.

This is wrong. Here's a similar "attack" which does not work for the exact same reasons:

1. Eve can trick Alice into visiting evil.com, a site Eve controls.
2. That site can make a request to Phabricator using Alice's session key, then read Alice's private messages from the response.
3. Thus, anyone can read anyone else's private messages.

Both of these chains of reasoning are wrong. In step (2), evil.com can not read responses from Phabricator. A wide array of browser-level and application-level protections and safeguards, including the Same Origin Policy and JSON response shields, prevent evil.com from making a request to a different domain using the user's cookies and reading the response.

Attackers can not do this, and their inability to do this is a fundamental building block of internet security.

If you've found a way to read the response, great! You may have found a real vulnerability. We're happy to receive a report, including a proof of concept which details how you've managed to get around all of the mechanisms in Phabricator and in browsers which are intended to prevent you from doing this.

If you have found a way to do this in the general case, congratulations! You have discovered a major vulnerability in the infrastructure of the internet that affects nearly every site which uses any kind of authentication.