HTTP status code Psiphon use check vulnerability

[Adam P]

Read:
"Abusing HTTP Status Codes to Expose Private Information"
https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information
Quote:
"When you visit my website, I can automatically and silently determine if you're logged into Facebook, Twitter, GMail and Digg. There are almost certainly thousands of other sites with this issue too, but I picked a few vulnerable well known ones to get your attention. You may not care that I can tell you're logged into GMail, but would you care if I could tell you're logged into one or more porn or warez sites? Perhaps http://oppressive-regime.example.org/ would like to collect a list of their users who are logged into http://controversial-website.example.com/?"

(You can skip to "BADDER STUFF STARTS HERE" section below.)

It seems to me that:
- We're safe from the attack if JavaScript is disabled.

If JS is enabled and links rewritten:
- If the attack site isn't loaded through Psiphon (but Facebook, etc., are), then the attack won't work.
    - Unless the attacker knows the Psiphon proxy that the user is browsing through (and so can construct links that use it).
- If the attack site is loaded through Psiphon (along with Facebook, etc.), then the attack *will* work ... but in that case they already know the user is using Psiphon, so the extra info about Facebook, etc. doesn't seem like such a big deal (maybe).

BADDER STUFF STARTS HERE

I've thought of a variation on this attack that allows attackers to passively discover Psiphon users (maybe this isn't new, but...):

- Start with popular attacker-controlled or -influenced site. Say Baidu.
- Every time attack learns of a proxy, before they block it, they put a hidden image on the Baidu main page that looks like this:

<img style="display:none;"
     onload="logged_in_to_psiphon_proxy()"
     onerror="not_logged_in_to_psiphon_proxy()"
     src="https://psiproxy.com/b/http://baidu.com/littleimage.jpg"/>

If the browsing user is logged into the Psiphon proxy, Baidu -- and so the attacker -- will find out. The attacker could put a chunk of code like that for every proxy that they know about (and haven't yet blocked).

An obvious -- but not enforceable by us -- defense is for the user to disable Javascript or use private browsing mode.

From our end, possibly checking the referrer (as suggested in the article) would would. (Maybe we're already doing this? Anyone?)
[In response to that, Eugene says: "I believe that one can fake the Referer header in XHR. The code will have to be a little more complicated though."]

[Adam P (adam+)]

There's an extension of this attack that will allow the attacker to determine what kind of user type/group a particular user is. If the XHR or iframe src is to www.psiproxy.com/users.php and the response is successful, then the attack knows the user is an admin.

(This would also work for Propagators, but maybe not for Power Users, since they don't have any distinct pages.)

[Adam P (adam+)]

A defense against this attack would be to use a CSRF-esque, per-session token in every request URL -- both browsing requests (/b/) and internal stuff (/profile.php). The attacker would then be unable to guess a URL that would return a non-error HTTP code.

A previously-considered change that would not be a complete defense against this attack would be to use the login suffix in every request URL rather than using /b/ (or the CSRF token). But the attack is predicated on the attacker learning about a proxy domain name in the first place, and it's not a big jump to assume that they also would have discovered the login suffix.

Note that part of the point of using using /b/ (and no longer using URL "encryption") was to keep the URL proxy-cruft as short as possible, so that the user could see where they're going before they click a link. If we put a large CSRF token in the URL (before the destination URL fragment), then we should consider adding ALT text and/or JavaScript tooltips or status bar changes to show the user what the actual destination URL is.