Cross Site Scripting

Posted: January 24, 2013 in Application Security

Cross-Site Scripting also known as an XSS is a kind of a vulnerability typically exist in most of the web applications. Every web application has “Same-origin” policy because of which the application executes only its own script. XSS enables the attacker to break the “same-origin” policy of the application and insert malcious script or code into the web-pages.

Attacker can perform different kinds of attacks by using using XSS. Few of them are

  •  Stealing Credentials
  •  Stealing Session ID (cookie value)
  •  Defacing the Web-site
  •  Causing DOS (Denial of Service) and many more….

XSS exists in different forms:

  •  Reflected or non-persistant XSS
  •  Stored or Persistant XSS
  •  DOM Based XSS

Destiny is same but the approach is different. All these types of xss are used for the same purpose and there are several features in common but the flavors(identifying and exploiting) are different 😀

Reflected XSS:
This kind of vulnerability normally exists in the application that uses dynamic pages to display content to the user (for ex: error messages). In general these applications takes a parameter containing a message and simply renders back to the user.
Consider the URL :

Above url shows a message “learn hacking” in the response of the application. Here the application extracting the message from the url, processes and displays to the user. So the url processes user supplied input and inserts it into the servers response that leads to REFLECTED XSS. And if there is no proper sanitization then the application is definitely vulnerable to Reflected XSS.

The attacker can form a crafted url as follows:<script>alert(1)</script&gt;

Requesting the above url generates the page that contains the script and displays the alert message.

Exploiting the Reflected XSS:


  1. User login’s to the web application and application issues an unique id (session id)  to the URL
  2. Attacker sends crafted URL to the user through some means of communication
  3.  User requests the crafted URL fed by the attacker 
  4. Server processes the url and responds to the user’s request. As the URL is framed with the malicious script, script is executed in the user’s browser in the same way it does on other code.                                                                                                                                                                                       Assume the attackers url is framed as :;
  5. The code causes the browser to send a request to And the request contains current session id
  6. Attacker uses the Session Id or Cookie Id and hijacks the users session. Now the attacker can perform all the actions in the same way how the user does.

Stored XSS:
This type of vulnerability is quite difference from the Reflected XSS. Normally these kind of vulnerability exist when an application takes an input from the end-user and stores it in the application, then displays to the other users.  For example: Consider Facebook application which allows to comment on pictures or status updates and then displays to all other users on their wall. If the application doesn’t sanitize the input properly then an attacker can write a script in the comment area, so that the users who visits or views particular page or post will be effected.  These kind of vulnerability normally exists in forums, bidding applications etc…..

So Stored XSS attacks typically consists of two things to do.. Initially the attackers visits the application and enters the malicious script into the application. Secondly the user enters into the application and visits the vulnerable page. And the script is executed in the back-end without the knowledge of the user.

DOM Based XSS:

DOM Stands for Document Object Model. To know how this attack works firstly we need to now what is DOM. Find the details from here. DOM Based is quite different from Reflected and Stored XSS. In DOM based when the user clicks on the crafted URL, server response doesn’t consist of any attackers script. Instead the browser executes the attacker’s script while processing the response.
This is because the Document Object Model of the browser has a capability to determine the URL used to load the current page. Script issued by the application may extract the data from the URL and process it. Then it uploads the content of the page dynamically depending upon the script executed through the URL.




Network Scanning Using Nessus

Posted: December 25, 2012 in Network Security

What is Nessus

If you are looking for vulnerability scanner, you might have came across several expensive commercial products and tools, with wide range of features and benefits.

If a full featured free vulnerability scanner is on your mind, then it’s time to know about Nessus. The article covers installation, configuring and select policies, starting a scan, analyzing the reports using NESSUS Vulnerability Scanner.

Nessus was founded by Renuad Deraison in the year 1998 to provide to the Internet community a free remote security scanner. It is one of the full fledged vulnerability scanners which allow you to detect potential vulnerabilities in the systems. Nessus is the world’s most popular vulnerability scanning tool and supported by most of the research teams around the world.

The tool is free of cost and non-commercial for non-enterprises.  Nessus uses web interface to set up, scan and view repots. It has one of the largest vulnerability knowledge bases and because of this KB the tool is very popular.

Key Features:

  • Identifies Vulnerabilities that allow a remote attacker to access sensitive information from the system.
  • Checks whether the systems in the network has the latest software patches.
  • Tries with Default passwords, common passwords, on systems account
  • Configuration audits
  • Vulnerability analysis
  • Mobile Device audits
  • Customized reporting

For more details on the features of Nessus visit:

Operating Systems that Supports Nessus

Microsoft Windows XP/Vista/7
Mac OS X (10.5 and higher).
Free BSD
Sun Solaris and many more

Installation & Configuration

  • You can download the Nessus home feed (free) or professional feed from the following link:

  • Once you download the Nessus tool, you need to register with nessus official web-site for generating the activation key which is required to use Nessus tool. You can do it from the following link


  • Click on “Nessus for Home” and enter the required details.
  • An e-mail with an activation key will be sent to your mail.
  • Install the tool. (Installation of nessus tool will be quite confusing where tutorials should be useful).For installation guidelines goto: ( Check for your operating system and follow the steps mentioned in the PDF
  • Open the Nessus in the browser, normally it runs on the port 8834.

(http://localhost:8834/WelcomeToNessus-Install/welcome) and follow the screen.

  • Create an account with Nessus
  • Enter the activation code you have obtained by registering with the Nessus website. Also you can configure the proxy if needed by giving proxy hostname, proxy username and password.
  • Then scanner gets registered with Tenable and creates user.
  • Then downloads the necessary plugins.  (It takes some time for downloading the plugins, while you are watching the screen you can go through vast list of resources we have for nessus users)

Once the plug-ins are downloaded then it will automatically redirects you to a login screen. Provide the Username and password that you have created earlier to login.

Running the Tool:

Nessus gives you lots of choices when it comes to running the actual vulnerability scan. You’ll be able to scan individual computers, ranges of IP addresses or complete subnets. There are over 1200 vulnerability plugins with Nessus using which you’ll be able to specify individual or set of vulnerabilities to test for. In contrast to other tools nessus won’t assume for explicit services running on common ports instead it will try to exploit the vulnerabilities.

One of the foundations for discovering the vulnerabilities in the network are:

  • Knowing which systems exist
  • Knowing which ports are open and which listening services are available in those ports
  • Determining which Operating System is running in the remote machine

Once you login to the Nessus using web-interface, you will be able to see different options like

  • Policies –Using which you can configure the options required for scan
  • Scans -for adding different scans
  •  Reports -for analyzing the results

Basic workflow of Nessus tool is to Login, Create or Configure the Policy, Run the Scan and Analyze the Results.


Policies are nothing but the vulnerability tests that you can perform on the target machine. By default Nessus has 4 policies.


Figure shows the default polices that comes with Nessus tool.

External Network Scan:

The policy is pre-configured in such a way that Nessus scans externally facing hosts, which provides services to the host. It scans all 65,535 ports of the target machine. It is also configured with Plugins required for web application vulnerabilities test like XSS.

Internal Network Scan:

This policy is configured to scan large internal networks with many hosts, services, embedded systems like printers, etc… This policy scans only standard ports instead of scanning all 65,535 ports.

Web App Tests:

Nessus uses this policy to detect different types of vulnerabilities exist in web applications. It has the capability to spider the entire web site and discovers the content and links in the application. Once the spider process has been completed then Nessus starts to discover the vulnerabilities that exist in the application.

Prepare for PCI DSS audits:

This policy consists of PCI DSS (Payment Card Industry Data Security Standards) enabled. Nessus compares the results with the standards and produces a report for the scan. The scan doesn’t guarantee for a secure infrastructure.  Industries or Organizations preparing for PCI-DSS can use this policy to prepare their network and systems.

Apart from these pre-configured policies you can also upload a policy by clicking on “Upload” or configure your own policy as per your scan requirement by clicking on “New Policy”.

Configuring the Policy:

  • Click on the policies tab on the top of the screen
  • Click on the New Policy button to create a new policy

Under the General settings tab select the “setting type” based on scan requirement, like Port Scanning, Performance scanning etc… Based on the type Nessus prompts different options that has to be filled. For example ‘Port Scanning’ has the following options


Figure shows configuring options of Port Scanning

Enter the port scan range. By default Nessus scans all the TCP ports in /etc/services file. You can limit the ports by specifying it manually (like 20-30). You have different scanners like Nessus SNMP scanner, SSH scanner, ping remote host, TCP Scanner, SYN scanner, etc…. Enable by checking the check box as per the scan requirement.

  •  Enter the credentials for scan to use. You can use single set of credentials of multiple set of credentials if you have. You can also work it out without entering the credentials.
  • The plugins tab has number of plugins. By default Nessus will have all the plugins enabled. You can enable or disable all the plugins at a time or enable few from the plug-in family as per the scan you’d like to perform. You can also disable some unwanted plugins from the plug-in family by clicking on particular plug-in.


Figure shows the sub-plugins for the plugin Backdoors

In the above Figure the green one shows the parent plugin and the blue once shows the sub-plugins or the plugins under the plugin (backdoor). You can enable or disable by simply clicking on the enabled button.

  • In the Preferences, you are provided with a drop down box to select different types of plugins. Select the plugin based on the scan requirement and specify the settings as per the plugins requirement. Click finish once completed. For example: configure the database


Figure shows the configuration of Database settings plugin


Once you are done with configuring the policies as per your scan requirement, you need to configure the scan details properly. You can do it under Scan tab

Under the Scan tab, you can create a new scan by clicking “New Scan” on the top right.  Then a pop up appears where you need to enter the details like Scan Name,  Scan Type, Scan Policy, Target.

  • Scan Name: The name that you are willing to give to the scan
  • Scan Type:  You have options to RUN the scan instantly by selecting “RUN NOW”. Or you can make a template which you can launch later when you are willing to run. All the templates are moved under the TEMPLATE tab beside the SCAN tab.
  • Scan Policy: Select the policy that you have configured previous in the policies section.
  • Select Target: Enter the target machine which you are planning to test. Depending upon the targets Nessus takes time to scan the targets.


Once the scanning process has been completed successfully, results can be analyzed from RESULTS.

  • Once the scan has been completed, you can see the name of the scan under the results section. Clicking on the name to see the report.
  • Hosts: Specifies all the target systems you have scanned
  • Vulnerabilities: Displays all the vulnerabilities on the target machine that has been tested
  • Export Results: You can export the results into difference formats like html, pdf, etc…  You can also select an individual section or complete result to export based on your requirement.
Let us try out an example now

I have configured a policy named “Basic Scan”. We have many options while configuring or building the policy like port scanners, performance of the tool, Advanced etc.


Figure shows configuration settings of Port Scanning for the policy “Basic Scan”

You don’t need credentials now, so skip the credentials tab and move to Plugins tab. You need to configure the specific plug-in as per the scan requirement that you are willing to perform on remote machine.


Figure shows the plugins I have enabled for the policy “Basic Scan”. I have enabled few plugins for windows machine scan.


Figure shows the configuring the Scan.

I have configured the scan to run instantly with the policy that I have created earlier. And the scan target specify the IP address I am willing to scan

Once all the details has been entered click on Create Scan which shows the Scan is running as shown in the below Figure.


Once the scanning has been completed then you can see the results in Results tab. Below Figure shows the same


Double clicking on the title displays the scan results.


Figure shows the Hosts details. It includes all the targets that you have scanned during the test. Double clicking on the host address displays the vulnerabilities Nessus have identified during the test. You can also click on Vulnerabilities tab to check out the vulnerabilities.


Figure shows the Vulnerabilities that Nessus found during its scan. Based on the Risk Nessus marks it as high, medium, info etc… Clicking on the Vulnerability gives you brief description of it.

For example let us go with Netstat portscanner, displays you the following information


Figure shows the ports opened in the target machine.

In the same manner you can analyze complete details by clicking on the vulnerabilities. Nessus also suggests the solutions or remedies for the vulnerabilities with few references.


Nessus is a tool which automates the process of scanning the network and web applications for the vulnerabilities also suggests solutions for the vulnerabilities that are identified during the scan.

I have written an article for infosec institute about this. Complete article is available at infosec institute. Take a look at the web application security course offered by infosecinstitute.

I have given an overview of SQL INJECTION (SQLI) in my previous post. As I mentioned you that the SQLI can be done in two ways


Here we are going to discuss the Manual method of injection.

Manual SQL Injection is done by Manually pen-testing the application where the pen-tester or the attacker exploits the SQLI by injecting the malicious/vulnerable string into the application directly by interacting with it and digs juicy information from the application like usernames, passwords, SSN, etc… without using any tool.

Things Required for doing manual Injection is:

  •  SQLI vulnerable site
  •  Burp Suite(to observe request and responses)
  • Patience
  •  Bit knowledge in SQL or the database that the application uses.
  •  And Brain 😀

(we can use cheat-sheet present in Pentest Monkey for database help)

Learning Objectives:

After going through this post you will be able to

  •  Various types of SQL Injection attacks
  •  Causes for SQLI
  •  Design strategies for avoid SQLI
  •  Exploiting the SQLI


In-general they are broadly categorised into three

1) In-band
2) Out-of-band
3) Blind SQLI

In-band: Also know as Error-Based SQLI. Here the application responds with an error. Uses single channel for communication. It is straight forward method.

Out-of-band: Communication happens using two way channel. Attacker enters data directly but the application responds by sending e-mails etc….

Blind SQL Injection: Here the applications doesn’t pops any error. Instead the attacker need to extract the data by giving true/false questions and observing the responses of the application.

Causes for SQL Injection:

There might be many causes for any kind of vulnerability in the application. They might be because of

  • Improper coding
  • Developer might not be aware of the vulnerabilities
  • Improper validation
  • Improper filtering or escaping of the special characters
  • Directly inserting the values got from the web-form into the SQL query.

Avoiding SQLI:

  •  Using prepared statements is the best solution for avoiding SQLI as the interpreter doesn’t come into the picture each and every time the query is framed.
  •  Doing proper validation
  •  Escaping the suspicious strings or characters
  •  Using Filters or white lists (Allowing only required characters)

Exploiting the Vulnerability:

In-order the exploit the vulnerability, first we need to confirm that the application is vulnerable to SQL Injection. We can test it in many ways by inserting various logical strings to the application like ‘, ‘or’=’, ‘ or 1=1, ‘ or ‘a’=’a’ etc….

I have written an article for exploiting and extracting complete data from the database using all the three types (In-band, Out-of-band, Blind). You can find the article here: Dumping database using SQL Injection.

Also have a look at Web application Security Course offered by InfosecInstitute.

SQL Injection with SQLMAP

Posted: October 15, 2012 in Application Security

SQL Injection:

SQL Injection (SQLi) is a web based attack used by hackers to steal sensitive information from organizations through web applications. It is one of the most common application layer attacks used today. This attack takes advantage of improper coding of web applications, which allows hackers to exploit the vulnerability by injecting SQL commands into the prior web application.The underlying fact that allows for SQLi is that the fields available for user input in the web application allow SQL statements to pass through and interact with or query the database directly.

For example, let us consider a web application that implements a form-based login mechanism to store the user credentials and performs a simple SQL query to validate each login attempt. Here is a typical example:

select * from users where username=’admin’ and password=’admin123′;

If the attacker knows the username of the application administrator is admin, then he can log into the app as admin by entering the username as admin’– and without supplying any password. The query in the back-end looks like:

Select * from users where username=’admin’--’ and password=’xxx’;

Note the comment sequence (–-) causes the followed query to be ignored, so query executed is equivalent to:

Select * from users where username=’admin’;

Hence the password check is bypassed and the attacker is logged into the app as admin. SQL Injection can be tested in two ways – Manual Pen-Testing & Automation.

1) Manual Pen-Testing: This is the process of detecting & exploiting the vulnerability manually. We need to test the vulnerability manually by passing the malicious strings and exploit it. I’ll give a clear explanation of exploiting SQLi manually in my next post.

2) Automated: This can be done by running the tools. There are many tools to find and exploit the SQLi vulnerability, some of them are SQLMAP, ABSINTHE, SQL NINJA, The Mole, etc… . I would love to use some tool which can be attached to a proxy that I use in my work regularly. So I chose SQLMap plugin for burp.


SQLMAP is an open source penetration testing tool that helps in automating the process of detecting and exploiting SQL injection vulnerabilities and taking full access over the database servers. SQLMAP comes with powerful detecting engine, and many niche features for the penetration tester and wide range of switches lasting from database fingerprinting, data fetching from the database, accessing the underlying file system and executing the commands on Operating System via Out-of-band Connections.

Since SQLMAP is developed in python it is a portable application, meaning that it will work in any operating system that supports python.

SQLMAP burp plug-in:

When we audit a web application, we normally configure an intermediate proxy to have more control over the request and response parameters. SQLMAP plug-in is an add-on feature that we can configure to the burp through which we can redirect a URL or a request directly to the SQLMAP with a single mouse click.

Plug-in Setup:

1. Download the plugin zip file from the following URL:
2. Unzip the file and keep it in the same folder where burp proxy is located.
3. Then execute the following command to run the burp with plug-in.


Java –classpath burpplugins.jar:”burpsuite_v1.4.0.1.jar” burp.StartBurp


Java –classpath burpsuite_v1.4.0.1.jar;burpplugins.jar burp.StartBurp

*Replace the burpsutie with the appropriate version that you are using. In my case I am using burpsuite_v1.4.0.1.jar. We also need to download the SQLMAP tool as we need to supply the executable to the burp plug-in.

Setting up SQLMAP:

For Windows,
1. Download and Install python 2.7 –
2. Download sqlmap –
3. Unzip the file to sqlmap directory.

For Ubuntu or Linux, run the below commands from the terminal

> Sudo apt-get install python-tk python2.7
> git clone git://
> cd sqlmap
> wget
> unzip

Setting up the environment:

– If you are using OWASP broken web application, then simply access one of the vulnerable site from your local browser where you are running SQLMAP.
– If you don’t use OWASP broken web application, then you need to set up a virtual machine that has a web server to host the vulnerable web application.
– Configure another VM with ubuntu where the attacker runs SQLMAP

Configuring the Proxy:

– If you are using Mozilla Firefox, then go to Edit > Preferences > Advanced > Network > settings and select “Manual Proxy Configuration” by enabling the radio button. Run the HTTP proxy with local-host and the port in which the proxy is running.
– If you are using Chrome, then go-to settings > Show Advanced Options > Network > Change proxy Settings > Connections > Lan settings.

How to use the plug-in:

Once you load the plug-in, then it is very easy to make use of it. Run the burp proxy with loaded plug-in. In the “site map” tab under the “target” you can see the particular domain that you are trying to test for SQLI and all the crawled pages related to the domain. On the right side click on the URL that you want to test, you can see the request parameters of the URL in the bottom panel. Right click on the request parameters and you can see the option “Send to sqlmap” as shown in the figure below.

Forward URL To Sqlmap burp plugin

Then you can see a new window (SQLMap wrapper) that will allow you to configure sqlmap. Below Image gives you a clear view of the wrapper.

sqlmap plugin window

Now lets have an over view of configuration features of the wrapper. In the “Target” text box specify the URL that you are willing to test. (Normally it will be filled by default as you have sent the request parameters previously, if needed you can change the URL).

Specify the method on which the domain is accessible (GET/POST).  In the “Bin-path” give sqlmap executable.

If you are aware of the DBMS of the web application, specify the database by selecting one of the options listed in the dropdown list. By default “auto” is selected which means that the SQLMAP wrapper tries with all the databases listed in the dropdown list to find out the database used by the application.

You can enumerate the database users, passwords, roles, privileges, databases etc by selecting the appropriate option from the Action drop down list. By default it is set to “auto” which means it will try to enumerate all the options listed in the drop down list in the sequential order.

If you are aware of the databases, users, tables, or columns, you can enumerate it by simply specifying it in the Database options.

Tampers are a kind of special characters or symbols that you are willing to insert into the query while pen-testing the application.

Once we configure the SQLMAP click on the “RUN”, this will open a new tab with execution of the program with the configuration that you have given to the wrapper or the SQLMAP. We can make any number of simultaneous execution tabs with difference instances. Below image shows the output tab.

Sqlmap output

Bored with theory, now lets see an example, the below URL is a vulnerable site for practicing the SQLI. You can also find the SQLI practice URL’s by goggling.

Id parameter in the above URL is vulnerable to SQLI; lets find it out through our SQLMAP wrapper (Burp suite plug-in).

Open the URL in the browser for which the proxy has been configured. In the proxy (burp) go to the “site map” and click on the URL and send it to the sqlmap by right clicking on the response parameters of the website, as I mentioned previously. Figure below shows you the wrapper opened for the above mentioned URL.

sqlmap plugin settings

The target specifies the URL we are testing, cookie specifies the cookie or session id.  Wrapper automatically identifies the positions in the URL where SQLI can be injected and specifies list of the parameters in “Parameters to test” text area (in our case we have only one possibility for injection which is “id” parameter).

In this example I have configured the SQLMAP wrapper to enumerate the list of databases that are configured in the backend database.

burp plugin sqlmap output

Above figure shows you the output tab which intend displays you how the plug-in tried to exploit the SQLI vulnerability in different ways

We can see that initially the wrapper tried to exploit the vulnerability by using “Boolean-based blind SQLI” by using AND operator. The payload shows how the tool tried to exploit the vulnerability. Here we can see the payload: id=22 AND 4626=4626, which is equivalent to the following URL: AND 4626=4626

As the URL is always true, the above URL returns the same page as of the original URL.

In the second trail it tried “error-based SQLI”. Later by using UNION operator.

Retreive database with sqlmap

From the above figure  we can observe more server details like web server, Operating System, back-end DBMS.

“Information_schema”  and “nilakantatrust” are the two databases that are used by the web application.

Now let us try to enumerate all the tables and the columns of the tables from the above databases.  To do so configure the SQLMAP wrapper Action field with the option “Enumerate database tables and columns”.  Below Figure shows you the same.

extract tables and columns using sqlmap

Below figure shows us the tables of the database “nilakantatrust”.

extracted tables and columns

Let us see the columns of these tables. Figure below shows the columns and their data types of two tables “est_notice” and “est_news” of  nilakantatrust database.

columns retreived using sqlmap

We can also dump complete database by selecting the option “dump dbms databases”.  And also store complete data into a file by using the option “save to file” in the output tab.

sqlmap output to file

Above figure shows the dumped data of the table “est_admin” from “nilakantatrust” database and storing it into a file.


SQLMAP is a powerful tool which is used to automate the process of detecting and exploiting the SQLI. I have written an article for infosec institute about this. Complete article is available at infosec institute. Take a look at the web application security course offered by infosecinstitute.

Hacking basics

Posted: October 5, 2012 in Application Security

What is ethical hacking?

Ethical hacking is also called as penetration testing or intrusion testing. It is a process of finding out the vulnerabilities or loopholes and breaking into the IT systems/applications and retrieving the information that is considered to be confidential.

Who are ethical hackers and hackers?

In general Ethical hacking is performed by Ethical hacker’s also known as white hat hackers. Ethical hacker is a skilled computer expert hired by the companies to use his programming skills to attack their networks and computer systems the same way a hacker would do. Ethical hacker uses the same techniques and tricks as those used by illegal hackers or black hat hackers.
So the only difference between the white hat hackers and black hat hackers is that the white hats hacks the system legally to protect or to increase the safety of their networks and systems from black hats. Whereas black hats perform it illegally to access the confidential data

Different kinds of attacks on web applications

According to the Open Web Application Security Project (OWASP) the most top 10 vulnerabilities in web applications are:

  •  SQL Injection (SQLI)
  •  Cross Site Scripting (XSS)
  •  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
  •  Invalidated Redirects and Forwards

To know more about owasp :