By Larry Loeb
Web designers love Single Page Applications (SPAs), because such apps load quickly in the browser and cover up connection deficiencies. They also drive an increasing number of data breaches.
A web application that consists of a single HTML page has long been favored by web designers who need a focused and limited page form factor.
The single page app will load into the client browser quickly, and the content inside of the single page application can be dynamically updated. The SPA’s loading speed helps mask problems that are caused by a bad network.
From a security perspective, this advantage comes at a steep (and increasing) price, as recent research shows. Web apps in general and SPAs in particular are vulnerable to many well-known attack methods. According to the Verizon 2020 Data Breach Investigations Report (VDBIR), web applications were involved in 43% of data breaches.
“The widespread use of this technology,” writes Laura Paine on the blog of application security specialist Veracode, “provides a unique challenge for security teams looking to mitigate their risk of breach, as traditional scanning methods may not provide the necessary coverage.”
Paine points out that SPAs are especially vulnerable to the XSS style of attacks. According to UK-based firm Precise Security, almost 40 percent of all cyber-attacks in 2019 was performed by using cross-site scripting.
Danger foreseen, prevention failed
A danger foreseen is a danger that can be avoided, yes?
Far from it, says NTT subsidiary WhiteHat Security. In WhiteHat’s annual Application Security Statistics Report (2019), the researchers warn: “Despite widespread knowledge of this vulnerability and its broad and crippling impacts, the industry continues to fail to address XSS issues.”
While single page app vulnerabilities arise from many causes, not only from cross-site scripting, some are considered to be structural. One example is that SPAs can be opaque to automated security scan tools that observe network data flow.
Additionally, the large number of SPAs deployed over the years has vastly expanded the attack surface. That has made life easier for attackers and their automated tools: A form of attack that performs on one SPA may well work on another.
All of the above begs the question: If web applications have become the #1 target for attacks, and vulnerable SPAs are ever more popular, what’s keeping companies from preventing such exploits in the first place?
The answer, in short, is the browser.
How SPA Exploits Leverage Local Browser Vulnerabilities
At their core, the long-standing problems with SPAs are rooted in how such apps interact with the local browser, which processes web content on the user’s local device.
Given the tight integration of the browser with system resources, this opens the door for a wide array of methods to steal and manipulate user data. Common SPA exploit methods include:
- SPA attacks through XSS
The cross-scripting attacks mentioned earlier become possible because the traditional browser's HTML parser can be tricked to switch into an execution mode of operation (such as script, style, or event handlers) without encountering an explicit directive to do so.
That means the browser doesn’t encounter an "escape" (which denotes the end of HTML information) in the HTML source, thus allowing untrusted code to be processed without restrictions.
Including a fail-safe escape is a complex task - too complex, it turns out, for many web coders. There are so many unusual contexts within HTML that the specifics of escaping syntax rules can be overwhelming.
Validating this kind of URL before it is performed cuts off one kind of problem, but there will always be something else popping up. What if the URL changes its content after it is assumed to be good, for example?
Whatever the approach - we also cannot assume that all the latest security library updates are present in the user's browser. And even if they are - zero-day exploits happen. This is one more reason why SPAs need to be handled with care.
Wanted: an additional layer of security to prevent the SPA from compromising the local machine and network by way of the browser.
- SPA attacks through Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) are possible because a session cookie does not expire until the browser has been closed.
Having an unexpired cookie means that if a user logs in to one site and then navigates to another, then that user will still be authenticated against the first site on the second one.
The second site can then submit requests to the form on the first while pretending to be the user.
This is a prime example of how form forgeries get created: An HTML form may be changed from the version originally loaded by a browser. Other servers can modify the form on the path as the browser is redirected to different sites.
The same original valid form may present itself to multiple SPA apps and be modified, in turn, by malware.
Here again, the need for a centrally managed security framework becomes obvious. In this example, its role would be to generate and check for the presence of anti-forgery tokens in forms. There are different methods to do this, the technique can stop a forgery attack.
More SPA Security Concerns
A general overview (like this post) of the inherent risks of SPAs slights the details that may be encountered in a concrete problem.
Stephan Walther has examined the implications in more detail on his blog, where he looked into the interaction between ASP.NET and the SPA. His conclusion: “Whatever type of web application you build – regardless of whether it is a Single Page App, an ASP.NET MVC app, an ASP.NET Web Forms app, or a Rails app – you must constantly guard against security vulnerabilities.”
In light of these facts, what’s left of the initial appeal of SPAs?
Making web apps more usable through simplicity may not be as simple as first thought, and outright dangerous if we trust the local browser to do the right - secure - thing.