Website Hacking

Ground Zero – How to Identify all Entry Points in Web Application?

If hacker has to identify vulnerabilites in any web application or website, his/her first task is to collect the list of all application entry points. This is why this stage is also referred as Ground Zero Step of any hack attempt. Hacker needs to zero in the attack surface in order to find all potential vulnerability areas. Before beginning any hack attempt, hacker should have good understanding of application, like how user and web browser communicates with web application or website. So Friends, lets learn about Ground Zero i.e. Identify all entry points in web application or website in detail.

As we all know a web application is all about requests and responses i.e. what we are requesting and what we are getting as response. Since we are talking about web application or website, we should be more curious about HTTP requests (GET or POST) and have to identify when GET requests are used and when POST requests are used to pass parameters to web application. Also we need to pay special attention towards all thoses variables or parameters (specially web form fields) which are passed to the application. But main question rises, HOW??

There are multiple ways of identifying what parameters are sent via POST or what parameters are sent via GET. Easiest one is to get via intercepting ZED ATTACK PROXY Tool by OWASP. You can also use INSPECT feature ( provided in Mozilla Firefox and Google Chrome) of latest web browsers to get that details with help of some more plugins like tamper data and cookie master. But beleive me ZED attack proxy is the best as it traps almost each and every request sent and response received. This is very time taking process but you will get smarter as time and practice goes on.

We have tried to Zero in your work by identifying all possible type of requests and response that can be a potential entry point into the system. Note: There are PUT and DELETE type of requests too but they are rarely used and not covered in our listing. Lets have a closer look that what type of requests and response can be possible entry points in web application or website.

REQUESTS that needs special attention:

Hacker needs to identify all parameters used in a POST request (these can be found in body part of HTML).
Needs to identify where GET requests are used and where POST request are used. (again body part of HTML)
Within the POST request, pay special attention to any hidden parameters. When a POST is sent all the form fields (including hidden parameters) will be sent in the body of the HTTP message to the application. These typically aren’t seen unless a proxy or view the HTML source code is used. In addition, the next page shown, its data, and the level of access can all be different depending on the value of the hidden parameter(s).
Needs to identify all parameters used in a GET request (i.e., URL), in particular the query string (usually after a ? mark).
Need to identify all the parameters of the query string. These usually are in a pair format, such as foo=bar. Also note that many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
When it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute the attacks. The hacker needs to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application.
Need to check for any additional or custom type headers not typically seen (such as debug=False).

RESPONSE’S That need to be monitored:

Identify where new cookies are set (Set-Cookie header), modified, or added to.
Identify where there are any redirects (3xx HTTP status code), 400 status codes, in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e., unmodified requests).
Check for some interesting headers like “Server: BIG-IP” indicates that the site is load balanced. Thus, if a site is load balanced and one server is incorrectly configured, then the tester might have to make multiple requests to access the vulnerable server, depending on the type of load balancing used.

Now lets learn with examples that how to identify entry points in web applicaiton:

Consider an example of Shopping Cart application or ecommerce website. Suppose user has selected an item, below is example of sample GET request:

GET https://abcdefg.com/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
Host: abcdefg.com
Cookie: SESSIONID=IGlzIGZvbyBhbmQgcGFzc3dvcmQga

The above request contains following parameters that need to verified for potentical vulnerabilites: CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state).

Below is an example of POST request for login request into above shopping application:

POST https://abcdefg.com/ShoppingApp/authenticate.asp?service=login
Host: abcdefg.com
Cookie: SESSIONID=WRpY3RhYmxlIGNvb2tpZXMgNA==
CustomCookie=00my00trusted00ip00is00x.x.x.x00

and body of the POST message will be something like below:

user=admin&pass=password123&debug=true&fromtrustIP=true

In above request we need to note all those parmeters that we previously noted but we also need to pay attention on parameters which are passed in body part of html i.e. user, pass, debug, fromtrustIP and also need to check Session Custom cookie.

Now we need to validate all these parameters one by one for all possible vulnerabilities to zero in all entry points. One entry point is sufficient to break down any web application, so Developers must make secure applications to avoid all possible type of vulnerabilities.

That’s all for today! Now we know our Ground Zero too. Enjoy and have happy learning.

DOM Based XSS Attack Tutorial – How it works?

In our previous tutorials we have learned about two types of cross site scripting i.e. Reflected Cross Site Scripting and Stored Cross Site Scripting. Most of our readers must be interested in do we have some XSS attack which is mixture of both. Yes, we have DOM based XSS. DOM Based XSS is an mixture of Reflected XSS and Stored XSS. In a DOM-based XSS attack, the malicious script is not actually parsed by the victim’s browser until the website’s legitimate JavaScript is executed. But before that we must understand what is DOM?

Wikipedia states that “The Document Object Model (DOM) is basically a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents. The nodes of every document are organized in a tree structure, called the DOM tree. Objects in the DOM tree may be addressed and manipulated by using methods on the objects. The public interface of a DOM is specified in its application programming interface (API). ”

To render a document such as an HTML page, most web browsers use an internal model similar to the DOM. The nodes of every document are organized in a tree structure, called the DOM tree, with topmost node named “Document object”. When an HTML page is rendered in browsers, the browser downloads the HTML into local memory and automatically parses it to display the page on screen. The DOM is also the way JavaScript transmits the state of the browser in HTML pages.

DOM BASED XSS ATTACK

DOM Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

In DOM-based XSS attack, there is no malicious script inserted as part of the page; the only script that is automatically executed during page load is a legitimate part of the page. The problem is that this legitimate script directly makes use of user input in order to add HTML to the page. Because the malicious string is inserted into the page using innerHTML, it is parsed as HTML, causing the malicious script to be executed.

Lets understand DOM based XSS attack with help of an example:

Suppose a developer made a website and he want’s to provide content in multiple languages i.e. he wants that his users can select language of their choice. But as per requirement, website mush have some default language too. This functionality can be invoked using below URL:

http://www.abcdefg.com/page.html?default=English

DOM based XSS can be achieved if hacker is able to insert his/her code in default tag and attack string will look something like below:

SCRIPT>></script>

When the victim clicks on this link, the browser sends a request for:

/page.html?default=<script><<MALICIOUS SCRIPT>></script>

to www.abcdefg.com. The server responds with the page containing the above Javascript code. The browser creates a DOM object for the page, in which the document.location object contains the string:

SCRIPT>></script>

The original Javascript code in the page does not expect the default parameter to contain HTML markup, and as such it simply echoes it into the page (DOM) at runtime. The browser then renders the resulting page and executes the attacker’s script:

<<MALICIOUS SCRIPT>>

Note that the HTTP response sent from the server does not contain the attacker’s payload. This payload manifests itself at the client-side script at runtime, when a flawed script accesses the DOM variable document.location and assumes it is not malicious.

Note : In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side.

That’s all for today! Enjoy guys and have happy learning.

How to find website is vulnerable to Stored XSS attack?

In our previous tutorial of Stored Cross Site Scripting, we learned what Stored XSS was and how it works. Today we will learn more abou tStored XSS and how to find a website is vulnerable to a Stored XSS attack. Let’s have a basic preview of how Stored XSS works, a recap of what we learned in our previous tutorial. Below are the basic steps involved:

Identify data entry points from where data is keyed into database.
Analyze the HTML code of input web forms for potential vulnerability.
Verify that input web form is vulnerable to Stored XSS.

The above process is somewhat similar to what we learned in the Reflected XSS Tutorial. Let’s learn each of the above points in detail to understand the Stored XSS attack.

Identification of Data Entry Points

The very first step is to identify all the data entry points from where a user can key data into a database i.e. from where all pages data is updated into database. Typical examples of stored user input can be located in:

File Manager: Application that allows users to upload files, for example avatars, images, documents etc.
Settings or Preferences: Pages that allow users to set preferences.
Forums: application that allows exchange of posts.
Comments on Blogs: blogs allowing users to submit comments
Shopping Carts: application that allows users to store items into cart which they can view later.
User profiles: Where user enters his/her info so that others can view it.
Logs: application that maintains user inputs in form of logs.

Every application which accepts data as input from the user and stores it somewhere in its database is a potential entry point into the system.

Analyze the HTML Code for Tracing Vulnerability

Most website or web applications use HTML tags and Javascript for storing input from the user. Finding vulnerability is one thing but understanding the base line is another. So let’s first learn how input is stored in a web page or application.

Consider an example of normal login form of any portal which has login functionality say xyz.com; its logging snippet will look something like below if you inspect the HTML code.

<input id=”Email” name=”Email” placeholder=”Email” value=”abc@email.com” spellcheck=”false” class=”” ENGINE=”email”>

We are interested in the value of “value” tag. In the above case, the hacker has to identify a way to inject the arbitrary code outside the input tag as shown below:

<input id=”Email” name=”Email” placeholder=”Email” value=”abc@email.com” spellcheck=”false” class=”” ENGINE=”email”>Arbitrary Malicious Code Snippet <!– />

Verify Input Web Form for Stored XSS Vulnerability

This step involves verification of input validations and filtering criteria of web application. Suppose we inject the below code in above login snippet:

<script>alert(document.cookie)</script> or %3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

Then above login snippet will become something like below:

<input id=”Email” name=”Email” placeholder=”Email” value=”abc@email.com” spellcheck=”false” class=”” ENGINE=”email”><script>alert(document.cookie)</script>

Now if the input from the user is not correctly validated by the web owner then the above code will result into a popup containing cookie values. If you get a pop up with cookie values then it means the website is vulnerable to stored XSS and now you can inject whatever you wish (browser executable script).

Now every user will get this popup when he/she will reload the infected website or web page.

Stored XSS can be exploited by advanced JavaScript exploitation frameworks like XSS Proxy, BeEF, Backframe etc.

That’s all for today! In our next tutorial we will learn how to use BeEF framework to exploit Stored XSS in any webpage, so stay connected.

What is Stored Cross Site Scripting or Stored XSS ?

As we know that there are two types of Cross Site Scripting namely Reflected Cross Site Scripting (Reflected XSS) and Stored Cross Site Scripting (Stored XSS). In our previous articles we have learned about Reflected XSS and how does it works. Today we will learn about most dangerous type of Cross Site Scripting attack i.e. Stored Cross Site Scripting. Web applications which allow users to store data are usually exposed to Stored Cross Site Scripting.

Stored Cross Site Scripting or Stored XSS usually occurs when a web application (say website) takes input from a user via some web forms (usually input forms for example, shopping cart, Forum, contact page, user or profile pages, blogs, settings page etc i.e. from where application accepts data and store it into database) and user injects malicious code into it, and the field in which user has entered the malicious code is not validated correctly and data is stored in some database for future use. As a result, the malicious data inserted by hacker appears to be part of the website or web application and runs in victim’s web browser (as per privileges set for web application) and it can result into complete hold over victim’s machine based on the arbitrary code inserted by the hacker. Likes we studied in Reflected XSS, an XSS attack allows hackers to install browser based Keyloggers, steal session cookies or sensitive information or change data on the web page usually download links etc.

In case of Stored XSS, there is not need of exploiting a malicious link. An exploit automatically triggers when any user visits the web page containing stored XSS. We can define a typical Stored XSS attack in below steps:

Hacker identifies the vulnerable website which asks for data from user and stores it into website database.
Attacker injects the arbitrary code into the vulnerable page.
User visits the vulnerable page on website which contains the Stored XSS.
Arbitrary or malicious code is executed by the user’s web browser.

This is how stored XSS attack works. Now below are after effects that a hacker can achieve after successful XSS attack:

Hijacking User’s Web browser
Install JavaScript or vbscript browser based Keyloggers to capture key strokes of victim.
Capture sensitive information of the users visiting the vulnerable website like session cookies etc.
Can deface website
Redirect users to other malicious websites.
Changed download links and expose users to download other malicious software’s like Rat’s, Trojans, Keyloggers etc.

Stored Cross Site Scripting attack can be exploited using various browser based exploitation frameworks available online like XSS Proxy, Backframe, BeEF etc.

That’s all for today! We will learn Stored XSS in detail with help of practical examples in later tutorials, so keep connected.