Cross Site Scripting

1. REGT NO : 010650035
RANK : ASI(RM)
NAME : YASHVIR SINGH
UNIT : BICIT NEW DELHI
CROSS SITE SCRIPTING
MOI

2. Overview
Introduction
What is XSS?
Method Of XSS
Preventing XSS Attack
Conclusion
Questions

3. What is XSS?
 Cross-Site Scripting (XSS) attacks are a type of
injection, in which malicious scripts are injected
into otherwise benign and trusted websites. XSS
attacks occur when an attacker uses a web
application to send malicious code, generally in
the form of a browser side script, to a different
end user. Flaws that allow these attacks to
succeed are quite widespread and occur
anywhere a web application uses input from a
user within the output it generates without
validating or encoding it.

4. An attacker can use XSS to send a malicious
script to an unsuspecting user. The end user’s
browser has no way to know that the script
should not be trusted, and will execute the
script. Because it thinks the script came from a
trusted source, the malicious script can access
any cookies, session tokens, or other sensitive
information retained by the browser and used
with that site

5. Types of XSS
Reflected XSS
Stored XSS (“Persistent XSS”)
DOM Based XSS

6. Reflected XSS

7. Stored XSS
 JavaScript supplied by the attacker is stored by
the website (e.g. in a database)
 Doesn’t require the victim to supply the
JavaScript somehow, just visit the exploited web
page
 More dangerous than Reflected XSS
 Has resulted in many XSS worms on high profile sites
like MySpace and Twitter (discussed later)

9. DOM Based XSS
 The attacker provides the victim with some
malicious data. This is often done by persuading
the victim to clicking on a link, with the malicious
data embedded in the URL. At this point the
malicious data is still just data.
 Scripts running in the browser use the malicious
data in client-side DOM manipulation, as part of
their normal operation.
 The browser renders (or otherwise processes)
the DOM, running the malicious data as
commands. The bad thing (whatever the attack
was - e.g. sending user data or session IDs to
the attacker) happens.

10. The attacker provides the victim with some
malicious data. This is often done by persuading the
victim to clicking on a link, with the malicious data
embedded in the URL. At this point the malicious
data is still just data.
Scripts running in the browser use the
malicious data in client-side DOM manipulation, as
part of their normal operation.
The browser renders (or otherwise processes)
the DOM, running the malicious data as commands.
The bad thing (whatever the attack was - e.g.
sending user data or session IDs to the attacker)
happens.
DOM Based XSS

12. Is XSS Dangerous?
 Yes
 Defeats Same Origin Policy
 Just think, any JavaScript you want will
be run in the victim’s browser in the
context of the vulnerable web page
 Hmmm, what can you do with
JavaScript?

13. What can you do with JavaScript?
 Access/Modify DOM
 Access cookies/session tokens
 Pop-up alerts and prompts
 “Circumvent” same-origin policy
 Virtually deface web page
 Detect installed programs
 Detect browser history
 Capture keystrokes (and other trojan functionality)
 Port scan the local network

14. What can you do with
JavaScript? (cont)
 Induce user actions
 Redirect to a different web site
 Determine if they are logged on to a particular site
 Capture clipboard content
 Detect if the browser is being run in a virtual machine
 Rewrite the status bar
 Exploit browser vulnerabilities
 Launch executable files (in some cases)

15. Preventing XSS
 The first method you can and should use to prevent
XSS vulnerabilities from appearing in your
applications is by escaping user input. Escaping
data means taking the data an application has
received and ensuring it’s secure before rendering it
for the end user. By escaping user input, key
characters in the data received by a web page will
be prevented from being interpreted in any malicious
way. In essence, you’re censoring the data your web
page receives in a way that will disallow the
characters – especially < and > characters – from
being rendered, which otherwise could cause harm
to the application and/or users.

16. Validating input
Validating input is the process of ensuring an
application is rendering the correct data and preventing
malicious data from doing harm to the site, database,
and users. While whitelisting and input validation are
more commonly associated with SQL injection, they
can also be used as an additional method of prevention
for XSS. Whereas blacklisting, or disallowing certain,
predetermined characters in user input, disallows only
known bad characters, whitelisting only allows known
good characters and is a better method for preventing
XSS attacks as well as others.

17. A third way to prevent cross-site scripting attacks
is to sanitize user input. Sanitizing data is a strong
defense, but should not be used alone to battle XSS
attacks. It’s totally possible you’ll find the need to use all
three methods of prevention in working towards a more
secure application. Sanitizing user input is especially
helpful on sites that allow HTML markup, to ensure data
received can do no harm to users as well as your
database by scrubbing the data clean of potentially
harmful markup, changing unacceptable user input to an
acceptable format.

18. Conclusion
 XSS vulnerabilities are bad.
 Avoid introducing XSS vulnerabilities in
your code.
 Please. They will only cause delays in
getting your apps into production.