Securing Web Applications Built On ReactJS Frameworks

7月 27, 2016

In today’s Whiteboard Wednesday, Dan Kuykendall, Sr. Director of Application Security at Rapid7, will talk about securing Single Page Applications (SPA) that are built on ReactJS frameworks.

As web applications become more complex, web application security scanners need to evolve to be able to fully scan these web apps to truly measure the security risks. In recent years, we have seen the challenge of keeping up with modern applications grow due to the adoption of applications powered by HTML5 and HTTP.

Single Page Applications, or SPAs, are the latest technology used to power web applications. Since this is a relatively new type of web application, most web application security scanners are unable to properly scan them. As web app security vendors rush to support single page applications, there is a coverage gap that is potentially leaving you vulnerable to an attack. It is absolutely critical that your web application security program is leveraging a web app scanner that is able to fully scan these modern applications.

Watch this week’s Whiteboard Wednesday to learn more.

Video Transcript

Hello, and welcome to this week's Whiteboard Wednesday. I'm Dan Kuykendall. I'm the Senior Director of Application Security at Rapid7. Today I'm gonna be talking about single page applications and ReactJS in particular. ReactJS and single page applications are really the most modern incarnation of the web and the web applications of today. If we look at the history of web applications, they started off early on as kind of being really nothing more than brochureware. They were static pages, they had very little interactive content. Things started to develop where we started providing more data, more input, we started kind of getting more dynamic web, especially in the early 200Os, late, yeah, very early 2000s, we started seeing JavaScript. JavaScript started giving us some dynamic user interfaces. Initially it was really for, like, dynamic menus. So the menu could be very simple along the top and drop down when you hover over it or when you click on it. So JavaScript was giving us some initial dynamic feel to a web application.

Show more Show less

Then we started getting know, let's say the 2006, 2007 time frame...we started seeing really an explosion of JavaScript and what we called AJAX. AJAX was basically a way for JavaScript to make calls to a backend. The first good examples of that were things like Google Suggest, so as you were typing your search, it was suggesting things that you might be trying to search for. We're used to that nowadays; it just seems very commonplace, but it was a revolution at the time and AJAX really started powering a lot of dynamic applications, especially the first versions of Gmail, where it was very dynamic. You could click on something and it was immediately like, you'd see your list of messages, you'd click on one, it would display the message. It was doing that through something that we'll talk about in a minute, but was these backend APIs. The browser was reaching out to the backend, to another webpage that wasn't really for display, but is just what we call a web service and it provides data. So you make a request, you ask it for some things, it gives specific data back. And it's in a data format, not a presentation format like HTML.

These REST APIs really started to grow and the use of JavaScript started to grow. They started to get so big and so complex that people started to build these frameworks like ReactJS. ReactJS is one of many; there's Angular, there's Ember, there's a whole bunch of different ones out there. They're all very powerful, but we're gonna talk about React a little bit because it has some very interesting special techniques that they do to make it really powerful. One of the things that it does is not only does it give you the very rich client interface and that's really what React is focused on is the client portion, so the thing that displays the webpage, lets the user interact with it, that's all powered by React. It has some complexities that I'm gonna drill into, but one of the things that it does...because you're loading up one page and that one page is then responsible for doing all of the different activity. It's including other bits of JavaScript, but it's really making a lot of requests to the backend REST APIs. These backend REST APIs are really what power single page applications. When you wanna read an e-mail, it's the thing that goes out, grabs the con [SP] to that e-mail, brings it back and then React displays it for you. When you click on Reply and you type it in, that's all React and then when you hit Send, it's sending it through RESTful APIs. And Gmail's not on React, but you can get the concept.

This is really powerful and it allows for very complex applications. One of the things that's interesting about React is that it has something called a virtual DOM. So in the normal browser or a normal application, the browser generates this thing called a DOM, a Document Object Model, which is a way to look at the whole webpage itself in a very dynamic structure. That's a great way for JavaScript developers to actually interact with the elements. So when you clicked on that mouse or on that menu button and it dropped down, that's handled through JavaScript activity reacting to the DOM elements. Well, with things like React, the applications started to get so complex and the DOM was very difficult sometimes to deal with, so they created an easier version which they call their virtual DOM. It then reacts with the real DOM, but the developers are just functioning with the virtual DOM. And so one of the things that happens in web app scanning and when you're doing automated testing is the scanner needs to be able to understand what the browser would normally do and it has to react to it the same way a real browser would. And if it does not, then it misses things. The discovery piece, the crawling of a web application, is how we find what's there to be tested. If you can't crawl it, if you can't find it, you can't attack it.

So it's vital that you test, that you can actually discover what's there. And mostly what you're discovering is a bunch of RESTful APIs. So you need to be able to discover. You need to have a tool that can handle the, you know, AJAX applications and even very specific SPA frameworks like React, which have a virtual DOM, the scanner needs to be able to support even that level of complexity so that it can do discovery. Then once it has discovered, it's gonna find these REST APIs. It needs to be able to test those REST APIs. They may be in JSON or XML formats, it doesn't matter; the scanner needs to be able to understand how to interpret what it's seeing coming from the Angular or the client side and how it's tested in the backend. It's all very vital that you have every component tested for. If you don't, you miss out on things. You're gonna potentially not be testing your entire application. Single applications create many, many problems.  

One final one that I wanna mention is interconnected or interdependent applications. Sometimes applications...let's take, like, a Netvibes, where it's a homepage, it's a portal, where it's gonna go get resources from other sites. Mostly it's gonna do RSS feeds, which are pretty straightforward. Those are actually RESTful APIs, but in a standard that is very common and we're all used to dealing with. But sometimes if you set it up right, it can actually monitor your Twitter feed and show you your Twitter feed in the one portal. It's going out...that client is not only talking to its own RESTful APIs, it's talking to third-party interconnected applications. Those third-party API calls are also part of what's going on in this application and you have to be able to understand that and test it. So every piece is important in a single page application. You need to be able to test everything or you're gonna miss out on issues. So ReactJS, single page applications, there's a lot to worry about. Like I said, a single page application creates many, many problems. Thank you.

See AppSpider in Action

Find out from the experts how AppSpider can find and reduce risk in even your most complex applications.

Watch Demo