NopSec.com uses cookies to make interactions with the Company’s Websites easy and meaningful. When you visit one of the Company’s Websites, NopSec.com’s servers send a cookie to your computer. Standing alone, cookies do not personally identify you; they merely recognize your Web browser. Unless you choose to identify yourself to NopSec.com, either by responding to a promotional offer, opening an account, or filling out a Web form (such as a “Contact Us” or a “Free Trial” Web form), you remain anonymous to the Company. Please go to our privacy statement for details.

Acknowledge

Leveraging Exposed WADL XML in Burp Suite

Recently on a customer engagement, I discovered an application that exposed its Web Application Description Language (WADL) XML that describes the services provided by a REST endpoint. Having a description of the service is extremely helpful from a penetration testing perspective, however I found that Burp Suite doesn’t parse these descriptions so the services aren’t added to the target site map. I’m not terribly fond of reading XML, so I started searching the Burp BApp store for extensions that could help use this information.

Unfortunately the extensions that exist for handling WSDL service endpoint don’t support WADL descriptions. I ended up finding the very helpful “Unsafe JAX-RS” extension by Mikhail Egorov on github here:

https://github.com/0ang3el/Unsafe-JAX-RS-Burp

This extension offers additional active scanning rules that target services such as those described by WADL. The extension even helpfully detects when an application exposes the WADL description, as you can see in the following figure.

The extension doesn’t add the ability to parse WADL in Burp, but helpfully suggests using SoapUI to manually test the service. I downloaded the free version of SoapUI from www.soapui.org, and saved the WADL XML as text files for importing in SoapUI.

In SoapUI I created a new REST project, and chose to import an existing WADL file as seen below:

 

Importing the saved XML file gave me a site map in SoapUI of the service endpoint. I was able to select methods, set parameter values, and see the response from the server. This is a fine solution for manual testing, but I have found quite a few WADL XML descriptions, and didn’t have time for extensive manual testing across the entirety of the services. I really wanted to use my fuzzing and active scanning tools in Burp suite to speed things up.

I found that I would right click on a project in SoapUI and export the services as a Swagger file.

SoapUI will export the service description into an “api-docs.json” file. This json file can be imported and parsed using the “Swagger Parser” extension that’s available in the BApp store.

The Swagger Parser extension can import the the api-docs.json file exported from SoapUI.

For these swagger files I had to manually enter the host:port and then the scheme, in my case HTTPS. After parsing the swagger file the service endpoints and parameters were conveniently listed in the Swagger Parser tab.  

You can now select all, right click, and choose what to do with your newly parsed service. I added it to the project site map and fired off an active scan. The “Unsafe-JAX-RS” extension adds new scanner rules for these types of services that cover a few CVEs, which proved very helpful in my assessment.

Not the most direct route to get your WADL described service properly parsed in Burp suite for testing, but it worked for me. If anyone reading this knows of a more direct way of handling this please let me know. Otherwise, if you stumble upon a WADL description, hopefully this helps you get it properly parsed and imported into Burp Suite.

Schedule a Product Demo Today!

See how NopSec's security insights and cyber threat exposure management platform can organize your security chaos.