Send email Copy Email Address

Annabelle Theobald

The security lottery

Cybercriminals attempt to obtain money, data, and the computing power of web users using a wide variety of methods. To keep this danger as low as possible, modern browsers support several security mechanisms. "However, whether these are actually effective depends on how and from where users access some websites. This is like a security lottery and should not be the case," says Sebastian Roth. In his paper "The Security Lottery: Measuring Client-Side Web Security Inconsistencies," the CISPA researcher revealed that inconsistencies could occur even on large websites, which can undermine client-side security measures. The good news is that inconsistencies are the exception, not the rule. Roth also presented his work at the prestigious USENIX Security Symposium.

Every day, we navigate the World Wide Web (WWW), arguably the most well-known Internet service. "Web applications are one of the most important access points to security-related data and functions. Therefore, they represent a primary target for attackers," says Sebastian Roth. The WWW is based on the so-called client-server model. This means that in a network, various tasks have to be distributed and performed by programs. To do this, one program (the client) sends requests to which another program (the server) responds and provides services, for example. The client then processes the server's responses. What sounds complicated is actually quite simple and takes place within milliseconds, as Sebastian Roth explains. "For example, if users want to open an Internet page, their browser, which in this case acts as a client, sends a request in the form of the Internet address entered to a Web server. This then sends the corresponding files back to the browser, which displays these files user-friendly, i.e., shows the user the requested website in the usual form."

To prevent attackers from tapping into this communication process between client and server and manipulating it or introducing malicious code, several security measures can now be taken on the client side. They are designed to prevent possible attacks or at least limit their potential damage if there are vulnerabilities in the client-side code. "To enforce these protective measures, the server must communicate them to the client." That's because only the server has the necessary insight into the page's structure and knows which services and data from different sources are embedded on the website. And this is the crux of the matter: the server responses can be different for the same users, depending on where on earth they call up the pages, which browser they use, which operating system is used, or which network access they use. According to Roth's research, even the language settings they choose can affect whether security mechanisms are effective.

But how did the researcher determine this? Together with colleagues, Roth looked at four different client-side security mechanisms, all of which need feedback from the server to work: X-Frame Options, Content Security Policy (CSP), HTTP Strict Transport Security, and cookie security attributes. "We wanted to know how well the security mechanisms worked when calling the top 10000 web pages. It was important for our study that the tested websites could be accessed via the encrypted HTTPS protocol. This was the only way to ensure our measurement results could not be manipulated." In addition, the researchers first had to find out how many of these websites support the aforementioned security mechanisms.

Then the systematic testing began: using the Tor network and VPN servers, the researchers simulated website accesses from 218 countries worldwide. "The choice of operating system and browser remained the same." Then, keeping the access location the same, they changed the browser choice, then the operating system choice, and so on. "In the end, we evaluated more than 13 million different server responses for our analysis," Roth says.

The result was that 321 websites showed inconsistent behavior, meaning that different security mechanisms are effective at one time and not at another when users access the site. How can this be? "One reason is that clients accessing the same web application from different locations are served by different servers. Another reason is that the operators of large websites have several servers and always direct requests to the currently least busy server. If that server is misconfigured, deviant behavior occurs." In addition, Roth says users access Web applications differently. "For example, on their desktop computer, they use the Windows operating system and the Chrome browser, and on their mobile device, they use the iOS operating system and the Safari browser. These constellations can trigger different website security behavior due to faulty configurations." All of the security mechanisms examined were affected in one constellation or another.

"If attackers are aware of these inconsistencies, they may continue to make attack attempts until they succeed with them or target a specific group of users right away," Roth says. But a bigger problem arises for researchers, according to Roth. "Inconsistencies like this can affect the results of mechanism safety measurements and have done so in the past, leading to incorrect measurement results."  

The good news: According to Roth, the overall number of inconsistent websites is not high enough to invalidate past studies or become a real problem for users. "We have alerted the affected website owners to the inconsistencies. If they configure the servers correctly, these problems can easily be fixed. The problem is not technical; it is human error. But possible follow-up work could look at how to help operators set up websites securely."
And then web security would no longer be a gamble.