Single Page Application security help
|Richard Harris in HTML5 Tuesday, October 23, 2018|
Single page application security is one of the most critical concerns when programming an application using the SPA method. We spoke with an expert from WhiteHat security to give you some tips on dealing with it.
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.
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?
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?
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.