Otherwise, if you stumble upon a WADL description, hopefully this helps you get it properly parsed and imported into Burp Suite. If anyone reading this knows of a more direct way of handling this please let me know. Not the most direct route to get your WADL described service properly parsed in Burp suite for testing, but it worked for me. 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. I added it to the project site map and fired off an active scan. You can now select all, right click, and choose what to do with your newly parsed service. After parsing the swagger file the service endpoints and parameters were conveniently listed in the Swagger Parser tab. The Swagger Parser extension can import the the api-docs.json file exported from SoapUI.įor these swagger files I had to manually enter the host:port and then the scheme, in my case HTTPS. This json file can be imported and parsed using the “Swagger Parser” extension that’s available in the BApp store. It comes equipped with a powerful arsenal of tools that you can use to identify and exploit vulnerabilities in web applications. It essentially works as a MITM (man-in-the-middle) proxy, enabling you to intercept, inspect, and manipulate traffic bi-directionally. SoapUI will export the service description into an “api-docs.json” file. Burp Suite is a powerful tool used to evaluate the safety of web applications. I found that I would right click on a project in SoapUI and export the services as a Swagger file. I really wanted to use my fuzzing and active scanning tools in Burp suite to speed things up.
#Burp suite icon manual
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 was able to select methods, set parameter values, and see the response from the server. Importing the saved XML file gave me a site map in SoapUI of the service endpoint. In SoapUI I created a new REST project, and chose to import an existing WADL file as seen below:
#Burp suite icon free
I downloaded the free version of SoapUI from and saved the WADL XML as text files for importing in SoapUI. The extension doesn’t add the ability to parse WADL in Burp, but helpfully suggests using SoapUI to manually test the service. The extension even helpfully detects when an application exposes the WADL description, as you can see in the following figure. This extension offers additional active scanning rules that target services such as those described by WADL. I ended up finding the very helpful “Unsafe JAX-RS” extension by Mikhail Egorov on github here: Unfortunately the extensions that exist for handling WSDL service endpoint don’t support WADL descriptions. I’m not terribly fond of reading XML, so I started searching the Burp BApp store for extensions that could help use this information. 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. 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.
0 kommentar(er)
