1. Web Application Security
A Report on
Cross Site Scripting
and
Denial of Service Attack
Submitted by:
Mehreen Nadeem

2. Cross-Site Scripting:
Cross site scripting (XSS) is a vulnerability that can be exploited by an
attacker for an application that supports javascript and the browser is
javascript aware, to hijack the end client's identity. It is exploited when a
website echoes malicious javascript code to browser, which in turn gets
executed in the browser in current domain context which results in the
malicious code accessing cookies. Traditionally, the XSS attack is divided
into persistent and non persistent XSS.[1]
• Persistent XSS (a.k.a reflected XSS) exists if the web application
echoes the user input in the browser so an attacker can enter some
malicious script instead of required input which in turn gets executed
in the browser in current domain context.
• Non Persistent XSS (a.k.a stored XSS) exists if the application stores
some script on the server and echoes this stored information n browser.
When a user loads the targeted page, script gets executed and browser
gets compromised as the script may redirect the user to some cookie
stealing page crafted by attacker. This vulnerability is explained below
in detail:
Stored Cross-Site Scripting:
Stored cross-site scripting (Non Persistent XSS) arises when data submitted by
one user is stored within the application which is typically stored in a back
end database and displayed to other user without being filtered or sanitized
appropriately. These type of vulnerabilities are most common in applications
that support interaction between end users or administration access user
records and data within same application. For example this is possible on
online discussion site where users post messages. If a user can post a message
containing embedded Javascript and application does not filter this then the
attacker can post a message that executes an arbitrary script to execute within
the browser of anyone viewing that message board is a potential threat for
users using that application.[2]
Its is not typically an XSS attack as the code executed in user's browser
is actually contained by the page the user is actually viewing which is not
the case in (reflected)XSS. However, the former is more serious from security
perspective because the victim will definitely be using the application at the
time of code execution and if the concerned page is present in the authenticated

3. area of application then session hijacking can be done far successfully than
in reflected XSS where victim is sometimes persuaded to log in.
Nowadays all the browsers have anti-XSS protection feature in them for example
Firefox and other Gecko-based browsers has open source NoScript add-on which
has ability to enable scripts on a per-domain basis and provides some anti-
XSS protection even when scripts are enabled. Internet Explorer 8 has also
introduced a new feature, The XSS Filter, that detects JavaScript in URL and
HTTP POST requests. However, there is no client side prevention mechanism
developed so far to protect user from stored cross site scripting.[3]
IE-8 Cross-Site Scripting Filter:
According to [4], IE8's XSS filter provides a feature which is intended to
make reflected XSS vulnerabilities much more difficult to exploit from within
Internet Explorer 8. IE8 XSS filter detects the attack and uses output encoding
technique to renders the attack harmless. But this filter contains a flaw,
residing in a protection design of IE 8 to prevent XSS attacks against sites,
that can enable serious security attacks against websites that are otherwise
safe.[5]
The possible risks with the filter are that if the attacker figures out a bug
in IE 8's output encoding technique, it will allow him to insert a particular
value that will become malicious as a result of the translation. Attacker can
also craft a value that would evade detection by the filter.[6]
Many application have deployed the X-XSS-Protection: 0 header, which after the
discovery of filter flaw, is actually the safety switch disabling IE 8’s XSS
protection.
HTTP TRACE Methods Enabled:
HTTP TRACE method allows a client to receive back a copy of the request by
invoking a remote, application-layer loop-
back of the request message that it sent to a server. The final recipient
of request reflects back the contents of the request back to the client for
debugging purposes.[7]
The complete request, including HTTP headers, is returned in the entity-body of
a TRACE response. The website using ActiveX, Flash, Java or any other controls

4. that allow executing an HTTP TRACE request can be used to read sensitive user
information such as cookies or authentication data that it receives in header
of HTTP request enveloped in TRACE response.
Attackers can combine XSS weaknesses with this method to read sensitive header
information from third-party domains. This technique is known as "Cross-Site
Tracing," or XST. As this method returns the contents of client HTTP requests
in the entity-body of the TRACE response, an attacker may abuse this method to
trick your legitimate web users to give him their credentials, even if SSL is
being utilized.[8]
These types of attacks can be prevented by disabling HTTP TRACE support in web
servers.
Denial of Service Attack:
It is one of the simplest attacks on a network. Instead of trying to steal
information, this attack simply prevents access to a resource. This can be done
by number of ways that is by targeting a particular user's computer and its
network connection. Alternatively attacker may attack the computers and network
of the target sites. This attack can be used to hinder the accessing of email,
websites, online accounts (banking, etc.), or other services that rely on the
affected computer. DoS attack can be of two kinds that floods the services or
crashes the services.
DoS attacks that crash the services are just program exploits as they depend
upon the bugs in the program due to its poor implementation. Buffer overflow
is a common example of this kind of attack. These type of DoS attacks are
related to specific program or certain version. Crash in the network stack of
a machine operating system will definitely take down the kernel thus denying
service to whole machine. Many patches for these kinds of vulnerabilities are
there for all OSs but still this technique can be applied to most of them in
different situations.
Flooding with information is the next most common DoS attack that is done on
a network. Flooding basically overloads the server with requests, as server
can only process a certain number of requests at once, it stops processing
legitimate requests. Spam email messages generation is a similar attack on
email accounts. Specific quota is associated with evry email address which
limits the amount of data that can be there in the account at any given time. By

5. sending many, or large, email messages to the account, an attacker can consume
the account quota, preventing user from receiving legitimate messages.[9]
Flooding is of many types depends upon which network vulnerability is being
exploited in order to bring about the attack.[10]
• SYN flooding exhausts the states in TCP/IP stack. It takes advantage
of the finite limit of TCP/IP to track incoming connections. Attacker
using a spoofed address initiates the connection sending SYN packet and
victim in its response sends SYN/ACK packet and waits for ACK response.
These half open connection remain in the queue until time out period
expires thus preventing legitimate connections to be established.
• Ping of Death and Teardrop are the two DoS attacks that existed due
to vendors poor implementation of IP layer. In the former case ICMP
echo request with large message sizes crashed the whole stack while in
the latter case attacker used overlapping fragment offsets to crash
the victim's system. However, these vulnerabilities are patched in all
modern operating systems.
• Ping Flooding has the goal of consuming all the bandwidth of victim
by sending large ping packets so that legitimate traffic can not get
through. Amplification attacks are actually the refined form of ping
flooding as it uses spoofing and broadcast addressing to amplify a single
packet into hundreds of them. It is possible on a network where a large
number of active hosts are present and broadcasting is allowed.These
techniques are known as smurf and fraggle attacks.
References:
1. Shreeraj Shah: Web 2.0 Security: Defending Ajax, RIA, and SOA. p.121.
Course Technologies
2. Dafydd Stuttard, Marcus Pinto: The Web Application Hacker's Handbook:
Discovering and Exploiting Security Flaws. p. 383. Wiley Publishing Inc.
3. http://www.owasp.org/images/5/50/OWASP-Italy_Day_IV_Maone.pdf
4. http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-
filter.aspx
5. http://www.theregister.co.uk/2009/11/20/internet_explorer_security_flaw/
6. http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html
7. http://www.ietf.org/rfc/rfc2616.txt
8. http://www.securityspace.com/smysecure/catid.html?id=11213

6. 9. http://www.us-cert.gov/cas/tips/ST04-015.html
10. Jon Erickson: Hacking: The Art of Exploitation. p.251. William Pollock.