Most web applications that implement login functionality have resources that are only available post-authentication, and separate resources available to unauthenticated, anonymous visitors. Common behaviors web applications might use are replying with a 403 or 404 HTTP status code when a request for an authenticated resource occurs from an unauthenticated user, or with a 200 status code if the user requesting the resource is logged in. Another common behavior is replying with a 302 HTTP Redirect status code when requesting a nonexistent resource that is under a path protected by authentication. For example, let’s say you request http://browserhacker.com/ admin/non_existent, where all resources under the /admin/ path require the user to be authenticated. The web application replies with a 302 status code if you request /admin/non_existent as an unauthenticated user, redirecting back to the login page at /admin/login. Instead, if you are an authenticated user and you request /admin/non_existent, you get a 404 Not found error. Mike Cardwell analyzed multiple social networking sites, checking whether they use HTTP status codes in a similar way. His analysis revealed interesting results.8 Twitter, for example, behaves like the second example, returning a 302or 404 on non-existent resources depending on whether or not the user session is authenticated. Consider that the script HTML tag fires the onerror event if the resource you want to load returns a 403, 404, or 500 status code, and fires the onload event if the resource returns with a 200 or 302 status code. Also consider that Twitter requires authentication to access resources under the /account/* path. Armed with these two details, you can reliably determine if the hooked browser is logged in to Twitter on one of its open tabs (or windows), and you can do it crossorigin without violating the SOP. The following code snippet will do the trick:
var script = document.createElement(“script”); script.onload = function(){ alert(‘not logged in’) }; script.onerror = function(){ alert(‘logged in’) }; script.src = “https://twitter.com/account/non_existent"; var head = document.getElementsByTagName(“head”)[0]; head.appendChild(script);
As you can see from Figure 9–6, if the hooked browser is not logged in to Twitter, a 302 response code is returned if a nonexistent resource such as / account is requested. This results in the script firing the onload event
If the hooked browser is logged in to Twitter, as you can see in Figure 9–7, requesting the same non-existent resource returns a 404 status code instead, resulting in the onerror event being executed.
