Technical InsightVulnerabilities

A Single-Site Browser’s impact on XSS, CSRF, and Clickjacking

A Single-Site Browser (SSB) is a highly restricted Web browser only capable of connecting to a single website. A “website” can be defined as a white-listed collection of one or more hostnames, IP addresses, ports, and protocols. For example, the SSB may only connect to Yahoo Mail “*.yahoo.com”, Facebook “https://www.facebook.com,” or Bank of America “https://www.bankofamerica.com/” and nothing else. In addition to these hostnames, an SSB would likely also need to have entries for off-domain content delivery networks and any required third-party Web widgets, but you get the idea. With a Yahoo Mail SSB you could not visit Facebook and a Facebook SSB could not visit Yahoo Mail.

Practically no one in the marketplace offers SSBs, you have to build them yourself. When you think about it though, an SSB is functionally similar to a mobile application often provided by service providers very much like these. Often enough, a mobile app is basically a browser without a location bar, rendering a stripped down HTML/Javascript version of their website. SSBs are also very interesting from a security perspective as they have a profound impact on Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Clickjacking attacks.

Hypothetically, let’s say I’m an average online user. My “important” online accounts are Yahoo Mail (email), Facebook (social network), and Bank of America (bank). These are the online accounts I REALLY don’t want hacked. I’m disciplined to only use these services, and more importantly, log-in to them with their respective SSB. All my other promiscuous Web surfing is conducted with a general purpose Web browser like Chrome, Firefox, and Internet Explorer.

Next, let’s consider a common attack flow for XSS. Assume I’m logged-into Twitter’s website with Chrome, and I click on a link from someone I follow — you know one of those shortened link things that are impossible to know if they’re safe. That link is a disguised (reflected) XSS attack targeting Yahoo Mail, Facebook, or Bank of America, aka the accounts I care about. If the XSS vulnerability is located on an authenticated section of the website, more than likely, I’ll get redirected and asked to log-in. Obviously I’ll know not to enter my username and password because that is only for that websites SSB. So, I’m safe and not auto-hacked.

If the vulnerability does NOT require authentication, I’ll get XSS’ed. While the attacker has a control over my browser, at least temporarily, he can’t steal my authenticated session cookies because they don’t exist on this browser. Unless I break my rule of logging-in without my SSB my “important” accounts remain safe.

What about CSRF? While using a general purpose Chrome browser I click on some random link, could be on a blog post, message board, or news story. This link sends my browser to a malicious website that attempts to CSRF me on Yahoo Mail, Facebook, or Bank of America. Chrome can always be forced to send forged HTTP request to whatever target website, the nature of CSRF, but since I’m not authenticated nothing will happen that will compromise or even adversely affect my “important” accounts. The exact same is true for a Clickjacking attack. Any XSS, CSRF, or Clickjacking payload a bad guy chooses to deploy is limited to unathenticated attacks, which can still be damaging, but the accounts I care about remain safe.

Now let’s assume I’m operating within an SSB on Yahoo Mail, a website that consumes and redistributes user-supplied content in the form of email. User-supplied content, email, could include some form of HTML/Javascript. Should that content execute Javacript inside the SSB where I’m logged-in to Yahoo, technically a persistent XSS vulnerability, the bad guy can do some real damage. The security benefits of an SSB in this context with respect to XSS are more limited. Technically the XSS payload can do anything I can do (ie read, send, delete email). Data exfiltration, such as stealing session cookies which can lead to account compromise, may also take place via the same mechanisms (email). What the attacker can’t do is chain multi-site XSS attacks.

Keep in mind, though, that allowing users to send HTML/Javascript content to each other is an inherently dangerous feature to begin with and fortunately it is not all that common on the highly trafficked websites outside of WebMail providers. For example, Facebook and Bank of America do not offer this functionality. As a result, persistent XSS vulnerabilities like the one previously described are rare.

Another beneficial aspect of SSBs is that if I click on an off-website link, it’ll simply open a new tab in my default general purpose browser.  Any XSS, CSRF, or Clickjacking attack an off-website link tries is now separated from my SSB. That’s huge! However, if the link is on-website then I have to be careful as it could be a non-persistent XSS attack and do everything the early mentioned persistent XSS vulnerability could. A possible exception being calling in additional Javascript payload.

When everything is considered, the only time I can get my accounts compromised by XSS, CSRF, or Clickjacking is while I’m within the SSB. This dramatically cuts down my risk profile when traversing the Web. Suddenly general purpose browsing with Chrome, Firefox, and Internet Explorer become safer because sessions are separated by desktop application boundaries.