Single Page Application security help

Single-page applications, or SPAs, are web apps that load a single HTML page and dynamically update that page as the user interacts with the app. Their origins are unclear but the concept was discussed as early as 2003 according to the archives on Wiki. SPAs use AJAX and HTML5 to create fluid and responsive Web apps, without constant page reloads - that literally means, the entire app runs in a single web page. 

There are advantages and disadvantages to building software this way. On the one hand SPAs tend to be less noisy, and faster, because they force you to handle the processing on the client-side. But the negative ramifications of SPAs include forcing Javascript usage by the client, having only one entry point into the site, handling analytics, SEO drop-offs, security, and more.

SPA websites have become more popular in recent years because applications behave more like a desktop app than a traditional website. Gmail is a great example of a popular program written in the form of an SPA, and their not alone. Twitter, and Facebook (almost), also join the ranks of popular applications that run in an SPA scope.
 
Jeannie Warner, Security Manager at WhiteHat Security - the company behind WhiteHat Sentinel Dynamic product (an always-on security scanner for websites), knows a thing or two about SPAs, and the vulnerabilities they expose. We recently asked her if she could offer her insight into SPAs - both good, and bad.

ADM: Why do you think single-page application sites have become so popular, and what are some of the advantages they provide?

Warner: Single-page applications or SPAs are popular for speed of load, allowing for a great user experience in their browser. They are a one-page stop with a lot of content loaded via some form of JavaScript or AJAX (etc). The speed is clear – take a Gmail account, for example. For the first three pages of navigation, the app will stay on the same URL and dynamically add the new content as you click through.

ADM: Some people say SPAs are like re-living flash websites all over again, where the navigation is tricky, back buttons don't exist, the entire experience is frustrating. How are SPAs improving and what would you say to those people?

Warner: I’d say they have a point – and there are navigational challenges. There’s nothing more annoying than filling in a form which, if there’s an error or problem, takes you back to an unfilled form. I love this site for the developer view of how things are improving – a little technical, a little humor.

ADM: We have seen some complete fails in terms of SPAs and page refreshes in enterprise applications, where data sets have to be retrieved every time the page is loaded. What is the best practice for SPAs that need to retrieve data regularly?

Warner: This is part of how to deal with  question 2. To developers - Improving error messaging (Are you sure you want to back up and lose unsaved data?) as part of ‘the before unload’ event would be great. Lazy error/exception handling is actually a problem we often identify in testing for more than just SPA pages.

ADM: As usability enhancements like SPA begin changing the nature of how websites behave, will security vulnerabilities continue to be an issue?

Warner: Of course they will. JavaScript hacks happen all the time – so a page that dynamically loads a lot of JS via whatever platform is liable to continue to have vulnerabilities, if nothing else, then in patching/versioning.

ADM: One of the drawbacks of SPA sites is that it can be challenging to fully investigate them for security vulnerabilities. Can you address why that is?

Warner: First is by the nature of a scanner – the heart and guts of most scanners is to run through a URL listing. With SPAs, the URL often doesn’t change with dynamic content, so they have to be treated differently. For example, Selenium knows when a page has finished loading. However, SPAs load pages with AJAX, or JSON, or others, and they don’t have a universally clear “done” signal they send to a scanner.

Testing SPAs is more complicated with the domain spidering, and will need to handle timeouts. This can also lead to slower execution, if one is sitting and watching a clock tick by. This is especially true if you have a constantly changing site that sees frequent updates – so there’s no “once and done” domain crawl that will remain effective.

ADM: Have any recent headlining breaches been caused by such vulnerabilities?

Warner: Hard to say. There’s SPA on Facebook, and then the Wordpress hacks of last year. In general, an XSS is an XSS, and using an SPA isn’t going to offset vulnerabilities. No one is out there saying, My SPA got hacked.

ADM: Could you talk about some of the ways vendors have attempted to address these security challenges?

Warner: I think the hybrid SPA is one way – SPAs being ‘all the rage’ in developer circles has come around to, “Okay, we want these sections only to be SPA, while the rest of the side has a traditional architecture.” All the AST vendors who scan Dynamic pages have an SPA solution in place to spider the sites via some form of virtual browser, Selenium playback tool or homegrown.

ADM: Are certain scanning approaches more effective than others in catching these vulnerabilities?

Warner: Sure – if you don’t have the ability to add whitelist / blacklist URLs in scanning, or manual browsing, or a full domain crawl with a browser or have a special SPA setting for your scanning tools, there will be coverage problems. A full Pen Test can always catch the various pages through manual clicking – but automated discovery is best/most efficient. At best, a web application pen test is a snapshot in time – so constant scanning is the best policy wherever possible to catch new features as they are released.

ADM: What are other key features, beyond SPA scanning, help to fill out a company’s application security portfolio?

Warner: I can’t speak highly enough about having automation built into a ticketing system (presenting the vulnerabilities to the development team for remediation) – which of course means that there needs to be SOMEONE somewhere who is catching, fixing, updating the sites. If the web app was developed by a third party over which one has no control, a Web App Firewall (WAF) can virtually patch the problem for risk mitigation.