What is a Web Service?
A web service is any software that is used for communication over a network. One could imagine a web service as any function that performs a specific operation.Web service may or may not include input parameters and may or may not return output parameters. Input / Output parameters can be used as attack points to gain an entry into web service to access confidential information. This guest blog post is to brief you about some attacks one could perform to keep a tab on security vulnerabilities within the web service.
Enumeration & Profiling
Suppose, there is a shopping website http://shoppy.com. A user could place an order by clicking on “Place Order” button. The user is taken to http://shoppy.com/buy. An attacker can check if a web service is involved or not by accessing http://shoppy.com/buy?wsdl. WSDL file for the web service becomes accessible through a browser. In this particular case, “buy” is a web service whose WSDL file can be accessed by attaching “?wsdl” as the query parameter in the URL. The WSDL file shouldn’t be allowed for public view in the first place. An authentication process needs to be in place to check if an authorized user is accessing the WSDL or not. Once WSDL is accessible, attacker can get information about web methods, data types of input and output parameters, end point information and others. This in turn can be used to exploit it further.
Attacker gets to know about input and output parameters through Enumeration & Profiling of web service. He can exploit web services using different types of parameters.
Meta characters: He could tamper using Meta characters like single quote, double quote, ampersand, percentage and dollar symbols as input values for web methods which consider an input.
Data type mismatch: Attacker may provide numeric values to string data type or null values to arrays.
Large Buffer / Abnormal values: Attacker could also provide large values in the range 0 – 2^31. Highest value or lowest value for the input parameters may also break the system.
Once inputs are provided and web methods are serviced by the web service, note the messages in the web service response to the user. These should not contain any confidential information about the web service.
The following Web service accepts username and password as input and issues a security token as output.
Web Service Request
Web Service Response
<?xml version=”1.0″ encoding=”utf-8”>
One could add exploitable elements into existing XML build a SOAP envelope around it and process it as a web service request. If appropriate validation is not in place, exploitable elements might get into database or query critical information from the server. Attacker can also use this attack to observe messages returned in the response to gather information about the server.
Attacker could look for Autoexec.bat script by keying in../../../../Autoexec.bat or using different versions of the same command to get hold of automatically executable batch files. <faultstring> messages sometimes return directory paths.
Consider following example:
Server was unable to process request. –> Could not find file & quot;c:\inetpub\wwwroot\news\junk&quot;.
Attacker now knows about c:\inetpub\wwwroot\news\junk!
Keying in symbols like single quote, double quote, hyphen, asterisk, and common parenthesis may result in different <faultstring> messages provided the input parameters were acting as direct inputs to the database query executed at the server level.
Using 1’ or 1=1 may return complete records of username.
In above web service request, replace JohnA with 1’ or 1=1 as input. If the web service was performing a query like Select * from username where username=’JohnA’, using the input 1 or 1=1 would result in a query Select * from username where username=’1’ or 1=1 hence displaying complete details for the first record in the table. Using this, user may even drill down to other records in the table using smart SQL queries.
HTTP method tampering
Web services will include a GET or POST method to support its operations. Using GET method to transfer confidential data is not secure enough. Any services using GET need to be cross checked by processing them using Burpsuite or wsKnight tool and checking what data gets submitted and returned through the web service. POST methods need to be converted to GET and check if any confidential information gets revealed.
SOAP message tampering
1. Providing * in input fields in web service request above may return several records if suitable validations are absent
2. Attackers could use brute force method to continuously key in username and password to gain illegal entry into secure area of the server. Note that there is no account lockout policy at Soap request level (Good Catch?)
3. Parameter Guessing can be used to continuously guess username and password using social engineering attacks, observe the <faultstring> messages, and fine tune guessing method to get access to web service.
OS command execution
Users could append valid operating system commands to input parameters and get access to confidential information.
For eg. “JohnA” | ls –r
Above input may process JohnA as username and also pass on ls –r command to list down directories in Unix OS.
This blog post is a guideline on how web services can be exploited during testing. Attackers can devise many more powerful attacks to gain access to web services.
Parimala has eight plus years of experience in testing, managing and mentoring teams of software testers. Apart from testing that she is most passionate about, she loves mentoring testers and has mentored over 30 testers. She frequently writes about her testing experiences at http://curioustester.blogspot.com. She has authored/co-authored articles for testing magazines like Better Software, Testing Circus and Testing Planet. Apart from testing, she loves to play with her two lovely kids, read books, magazines, articles and many more. She is a self-claimed emotional over eater who eats to beat every emotion in the world!
Parimala currently works as a Test Manager at Moolya Software Testing Pvt Ltd, Bangalore. She can be reached at firstname.lastname@example.org.