David Howe  

Today, Rapid7 is pleased to announce an AppSpider (application security scanning) update that includes enhanced support for JavaScript Single Page Applications (SPAs) built with ReactJS. This release is significant because SPAs are proliferating rapidly and increasingly creating challenges for security teams. Some of the key challenges with securing SPA's are: Diverse frameworks - The diversity and number of JavaScript frameworks contributes to the complexity in finding adequate scan coverage against all modern Single Page Applications. Custom events - These frameworks implement non-standard or custom event binding mechanisms, and in the case for ReactJS, it creates a so-called “Virtual DOM” which provides an internal representation of events outside of the real browser DOM. It is important to discover the type and location of every actionable component on the page. Tracking the event bindings on a real DOM is relatively straightforward by shimming EventTarget.prototype.addEventListener and determining the event type, and which node it is bound to. For example: However, in cases where a framework manages its own event delegation (such as in the ReactJS Virtual DOM) it becomes more efficient to hook into the framework, effectively providing a query language into the framework for its events (instead of listening for them). According to ReactJS page: Event delegation React doesn't actually attach event handlers to the nodes themselves. When React starts up, it starts listening for all events at the top level using a single event listener. When a component is mounted or unmounted, the event handlers are simply added or removed from an internal mapping. When an event occurs, React knows how to dispatch it using this mapping. AppSpider has now created a generalized lightweight framework hooking structure that can be used to effectively crawl/discover/scan frameworks that do things ‘their own way.'  Look for an upcoming announcement on how you can incorporate and contribute your own custom framework scanning hooks with AppSpider. What's New? So what is AppSpider doing with ReactJS now? AppSpider is leveraging Facebook's open source developer tools (react-devtools) that are wrapped in a generalized framework hook and now crawled exhaustively by AppSpider. Additionally, ‘doin' it their own way' event binding systems (such as the ReactJS Virtual DOM) are being considered and executed. It is still the case that frameworks are supported right out of the box including AngularJS, Backbone, jQuery, Knockout, etc., without the need for tuning. Only where needed are we adding specific support for frameworks with custom techniques. Why is this important? Web application security scanners struggle with understanding these more complex types of systems that don't rely on fat clients and slow processes. Scanners were built using standard event names relying on these ever-present fields to allow them to interact with the web application. Without these fields, a traditional scanner no longer has the building blocks necessary to correctly interact with the web applications it is scanning. Additionally, they have used the ever-present DOM structure to better understand the application and assist with crawling. This becomes difficult if not impossible for a traditional scanner when they have to deal with applications that process information on the server side instead of the client side. If this creates such an issue, why are people flocking to these frameworks? There are several reasons: Two-way data bindings which allow a better back and forth between client side and server side interactions Processing information on the server side which increases performance and gives a better user experience Flexibility to break away from the fat client side frameworks These capabilities can make a dramatic difference to developers and end users but they also introduce unique issues to security teams. Security teams and their tools are all used to the standard event names like OnClick or OnSubmit. These events drive how we interact with a web application, allowing our standard tools to crawl through the application and interact with them. By using these standard events we have been able to automate the manual tasks of making the application think we interacted with it. This becomes much more complicated when we introduce custom event names. How do you automate interacting with something that changes from application to application or even worse whenever you refresh the same application? AppSpider answers that question by allowing you to connect directly into the framework and have the framework tell you what those custom events are before it even begins to crawl/attack. Security experts have relied upon the DOM to know what was needed to test an application and monitor this interaction to understand potential weaknesses. Server side processing complicates this as all processing is done on the server side, away from the eyes and tools of the security expert and displaying only the end results. With AppSpider, you can now handle applications that are utilizing server side processes because we are not dependent on what is shown to us; instead we already know what is there. Currently, the only way for pen testers to conduct web application tests on applications using ReactJS and other modern formats is to manually attack them, working their way one-by-one through each option. This is a time consuming and tedious task. Pen testers lack the tools to be able to quickly and dynamically scan a web application using these SPA frameworks to identify potential attack points and narrow down where they would like to do further manual testing. AppSpider now allows them to quickly and efficiently scan these applications, saving them time and allowing them to focus efforts where they will be the most effective. How can you tell if your scanner is supporting these custom event names? Answering this question can be difficult as you have to know your application to truly understand what is being missed. You can typically see this quickly when you start to analyze the results of your scans. You will see areas of your application completely missed or parameters that don't show up in your logs as being tested against. Know your weaknesses.  Can your scanner effectively scan this basic ReactJS application and find all of the events? http://webscantest.com/react/ Test it and find out!  Is your scanner able to get see past the DOM? AppSpider can.

AppSpider's Interactive Reports Go Chrome We are thrilled to announce a significant reporting enhancement to AppSpider, Rapid7's dynamic application security scanner. AppSpider now has a Chrome Plug-in that enables users to open any report in Chrome and be able to use the real-time vulnerability validation feature without the need for Java or having to zip up the folder and send it off. This makes reporting and troubleshooting even easier! Enabling Security - Developer Collaboration to Speed Remediation AppSpider is a dynamic application security scanning solution that finds vulnerabilities from the outside-in, just as a hacker would. Our customers tell us that AppSpider not only makes it easier to collaborate with developers, but also speeds remediation efforts. Unlike other application security scanning solutions, we don't just report security weaknesses for security teams to ‘send' to developers. Our solution includes an interactive component that enables developers to quickly and easily review a vulnerability and replay the attack in real-time. This enables them to see how the vulnerability works all from their desktop without having direct access to AppSpider itself - and without learning how to become a hacker. Related Content [VIDEO] Why it's important to drive application security earlier in the software development lifecycle. Developers can then use AppSpider's interactive reports to confirm that their fixes have resolved the vulnerability and are actually protecting the application from the weaknesses found. Developer's don't need to have AppSpider installed in their environment to leverage this functionality, just the report, connection to the application they are testing and they're good to go. Related Content [VIDEO] Watch AppSpider interactive reports in action. AppSpider Interactive Reports - How it Works Pretty cool, huh? Well, here's how and why it works... For those who work in application security, we know all too well that many, if not most, of the application security vulnerabilities we deal with exist in the source code of custom applications that we are responsible for - often in the form of unvalidated inputs. As security professionals, we aren't able to resolve these vulnerabilities (or defects) with a simple patch. We need to work with the developers to resolve security defects, implement coding best business practices and then re-release the new code into production. At Rapid7, we have understood this for a long time and we have been helping security teams and development teams to collaborate more effectively through AppSpider. There are many reasons why effective DevSecOps collaboration is difficult. Developers aren't security professionals and reporting security defects to them is easier said than done. We have the logistical issues of emailing around spreadsheets or PDFs and then we have the communication issues related to us speaking security and them speaking to developer. Not to mention the pain of having to go back and forth re-testing their “fixes” to see if they are still vulnerable or not, ‘cause let's face it, most developers wouldn't know a SQL Injection from a Cross Site Request Forgery (CSRF), let alone know how to actually attack their code to see if it's vulnerable to these attack types. This is an area that we have always shined in however, until today AppSpider required the security professional and the developer to make use of a Java applet to accomplish this within our reports. Now that Chrome and Firefox have disabled Java support, some teams weren't able to leverage this awesome functionality. Are you looking to upgrade your dynamic application security scanner? Check out AppSpider in action? Check out this on-demand demo of our web application security solution here!

AppSpider's got even more Swagger now! As you may remember, we first launched improved RESTful web services security testing last year. Since that time, you have been able to test the REST APIs that have a Swagger definition file, automatically without capturing proxy traffic. Now, we have expanded upon that functionality so that AppSpider can automatically discover Swagger definition files as part of the application crawl phase. You no longer have to import the Swagger definition file, delivering an even easier and more automatic approach for security testing RESTful web services (APIs, microservices, and web APIs). This is a huge timesaver and another evolution along AppSpider's long history of being better at handling modern applications than other application security scanning solutions. Challenges with Security Testing RESTful APIs When it comes to RESTful web services, most application scanning solutions have been stuck in the traditional web application dark ages. As APIs have proliferated, security teams have been forced to manually crawl each API call, relying on what little - if any - documentation is available and knowledge of the application. With a manual process like that, the best we can hope for is to not miss any path or verb (GET, PUT, POST, DELETE) within the API. In this scenario, you also have to figure out how to stay current with a manually documented API. The introduction of documentation formats such as Swagger, API Blueprint, and RAML helped, but testing it was still a manual process fraught with errors. RESTful Web Services: Security Testing Made Easy Enter Rapid7. At the end of 2015, we released a revolutionary capability for testing your REST APIs with the introduction of Swagger-based DAST scanning. This ability for AppSpider to learn how to test an API by consuming a Swagger definition (.json) file revolutionized the way DAST solutions handle API security testing. Doing so allowed our customers for the first time, to easily scan their API without a lot of manual work. Now, we are taking it up another notch by making REST API security testing even easier. What's New? This is no trivial task as it's not just parsing data out. When our engineers started this task, the first thing they thought about was how customers would use this feature. We quickly realized that just like everything else in application security, when we start scanning new technologies in the web application ecosphere, we realize that we encounter the same challenges we did when learning to effectively scan traditional web applications. So, here are three of the latest enhancements we have made to speed REST security testing. Automated Discovery of Swagger Definitions - Instead of feeding your Swagger definition file into AppSpider, you can simply point AppSpider to the URL that contains your Swagger definition and AppSpider will automatically ingest it and begin to take action. Parameter Identification and Testing with Expected Results - Application security testing solutions always have the challenge of knowing what the parameters are and what data they are expecting. Web applications can have many different parameters, some of which may be unique to just that API. We knew that if this was going to be effective we needed to be able to account for these unique types of parameters. This led us to expand our capability so that you can give AppSpider guidance on what these parameters mean to your application. Your guidance allows AppSpider to improve the comprehensiveness of the testing. AppSpider remembers your guidance and uses it in subsequent tests. Quick tip: Regardless of which application security testing solution or experts you use, be sure that your scanner or testers are using expected results (a date for ‘date', a name for ‘last name' and a valid credit card number for ‘ccn'). Without expected results, the test is largely ineffective. Scan restrictions - Just like any other area of a web application, APIs have sensitive portions that you may not want to scan, a good example of this is a HTTP verb like DELETE. Many teams have effectively documented ALL of their REST API. This is great and is really where you should be, but we need to be able to avoid testing certain sections. We are already very good at customizing your web application scanning to make it the best it can be. We have just extended this capability into the handling of APIs. Now you can leverage AppSpider's scan restrictions capability and exclude any parameter or HTTP verb you do not want to use. By leveraging AppSpider's automated testing of RESTful web services that includes both parameter training with scan restrictions, you really have an unparalleled opportunity to test the security of your REST APIs quickly and frequently. We know you thought this was out of reach, but it's not! So keep this in mind next time you are having a discussion on how to efficiently scan and understand the security weaknesses in your APIs. If you're stuck in manual process it might be time to take a look at how to automate these processes using something like Swagger. Note, Swagger has been renamed to the (OpenAPI Specification). If you are already automated well then we can give you an answer you've always wanted..we can automate your API scanning like never before. You may also be interested in : AppSpider Release Notes Blog: AppSpider's Got Swagger: The first end-to-end security testing for REST APIs