Attacking JavaScript Web Service Proxies with Burp

JavaScript Web Service Proxies are an alternative to WSDL (Web Services Description Language) files for interacting with WCF Web Services. The proxy files function as a description of the web service methods, exposing the available service methods as well as their parameters. JavaScript Service Proxies, or JSWS (JavaScript Web Services) as I will be calling them for brevity’s sake, are a component of an AJAX framework and can typically be used in place of WSDLs for the same web services. JSWS uses JavaScript to model the descriptor file, and JSON in transit making it a good alternative to WSDL’s XML as JavaScript and JSON are heavily integrated into all browsers. The client side application will either load the JSWS upon need, or it may be embedded into the page. The JSWS contains JavaScript code that will instruct the browser in the creation of the JSON request. An example of one of these files can be seen below.

After the file is loaded the subsequent request will be formatted in the following way.

A side effect of this file instructing the browser in how the requests must be formatted is that it can also aid an attacker in enumerating web service methods and potential injection points. Before these can be used, it is important to understand when JSWS is in use, and how to identify it.

Identifying JSWS

There are multiple different ways to identify when these services are being used in an application. The application may request a JSWS file allowing it to be identified through proxy logs by looking for https://some.domaim.com/WebService.asmx/js. The application may also request the same file with the debug information, https://some.domain.com/WebService.asmx/jsdebug. The jsdebug file will contain additional information about the datatypes of the parameters needed, and which parameters are required. Even if the application is not requesting the jsdebug file it is likely still available.

Alternatively, the application may be using the PageMethods technique, which means the JSWS will be embedded directly into the page.

This will typically be on an aspx page rather than asmx, but it could be present with any extension. This method can be identified by searching server responses for the ‘PageMethods’ string, or by inspecting proxy logs for the method calls (e.g. https://some.domain.com/WebService.aspx/GetInformation)

The JSWS Extension

After identifying that this technology is being used an attacker is able craft all the request variations the web service will accept, but this takes time and can be quite tedious. After starting to see JSWS in assessments more often, I decided to create a Burp extension that would automate this process. The tool is modeled after Eric Gruber’s Wsdler, and functions in the same way. The JSWS extension can be downloaded from https://github.com/NetSPI/JSWS, and is available in the BApp store.

To use this tool, simply right click on the request or response containing the JSWS and click Parse JSWS. If the application is loading the JSWS file, the file should already be in the proxy logs.

It is recommended to parse the jsdebug file rather than the js file, as it will give the user more information about which types of parameters to tamper with.

If the application uses the PageMethods representation of JSWS, right click on the request or response containing the PageMethods code and click Parse JSWS.

The JSWS extension will then open a JSWS tab, as well as a subtab for the service just parsed. Under this tab are two panes, the top containing all available methods, and the bottom containing the JSON template.

From here the request can be handled as any JSON request, and can be sent to Repeater for manual testing, or Intruder and Scanner for automated testing.

Conclusion

The extension does not currently detect the presence of JSWS through passive scanning. This is being implemented and will be released in a future build. For any feature requests or bugs you may find please email me or create a ticket on Github.

The 11 Essential Falco Cloud Security Rules for Securing Containerized Applications at No Cost

Hack-Proof Your Cloud: The Step-by-Step Continuous Threat Exposure Management CTEM Strategy for AWS & AZURE

Web-Based PLC Malware: A New Technique to Hack Industrial Control Systems

The API Security Checklist: 10 strategies to keep API integrations secure

11 ways of hacking into ChatGpt like Generative AI systems

How to send spoof emails from domains that have SPF and DKIM protections?

Silent Email Attack CVE-2023-35628 : How to Hack Without an Email Click in Outlook

How to Bypass EDRs, AV with Ease using 8 New Process Injection Attacks

Alisa Esage G

Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.