Beginner Guide to Insecure Direct Object References

Insecure Direct Object References (IDOR) has been placed fourth on the list of OWASP Top 10 Web application security risks since 2013. It allows an authorized user to obtain the information of other users, and could be establish in any type of web applications. Basically it allows requests to be made to specific objects through pages or services without the proper verification of requester’s right to the content.

OWASP definition: Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

The Application uses untested data in a SQL call that is accessing account information.

Let consider a scenario where a web application allow the login user to change his secret value.

Here you can see the secret value must be referring to some user account of the database.

Currently user bee is login into web server for changing his secret value but he is willing to perform some mischievous action that will change the secret value for other user.

Using burp suite we had captured the request of browser where you can see in the given image login user is bee and secret value is hello; now manipulate the user from another user.

SQLquery = "SELECT * FROM useraccounts WHERE account = ‘bee’;

Now let’s change user name into raj as shown in given image. To perform this attack in an application it requires atleast two user accounts.

SQLquery = "SELECT * FROM useraccounts WHERE account = ‘raj’;

Great!!!  We have successfully changed the secret value for raj.

Note: in any official website the attacker will replace user account from admin account.

Let take another scenario that look quite familiar for most of IDOR attack.

Many times we book different order online through their web application for example bookmyshow.com for movie ticket booking.

Let consider same scenario in bwapp for movie ticket booking, where I had book 10 tickets of 15 EUR for each.

Now let’s confirm it and capture the browser request through burp suite.

Now you can see we have intercepted request where highlighted text contains number of tickets and price of one ticket i.e 15 EUR it means it will reduce 150 EUR from my (user) account; now manipulate this price from your desire price.

I had changed it into 1 EUR which means now it will reduce only 10 EUR from account, you can observe it from given image then forward the request.

Awesome!!! We had booked the 10 tickets in 10 EUR only.

Understanding DOM Based XSS in DVWA (Bypass All Security)

This article is written to bring awareness among all security researchers and developers so that they may be able to learn the level of damage cause by XSS attack if the web server is suffering from cross site scripting vulnerability.

DOM Based XSS (TYPE 0)

The DOM-Based Cross-Site Scripting is vulnerability which appears in document object model instead of html page. An attacker is not allowed to execute malicious script on the user’s website although on his local machine in URL, it is quite different from reflected and XSS because in this attack developer cannot able to find malicious script in HTML source code as well as in HTML response, it can be observed at execution time.

This can make it stealthier than other attacks and WAFs or other protections which are reading the page body does not see any malicious content.

Let’s start!!!

Target: DVWA

Low security

 For this tutorial I had targeted DVWA and explore localhost IP in browser; now login with admin: password into web application and Set security level low.

Select the DOM cross site scripting vulnerability from given list of vulnerability. The web application allows the user to select any language form drop down list.

Now let’s understand current scenario when security is low; in this part the developer has not add any filter while framing the code for web site that could check for any malicious activity. Hence if an attacker opens the website in low security and tries for XSS attack possible he gets successful in his deed.  

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English

The JavaScript code obtains value from the URL parameter “default” and writes the value in the webpage and as the result the web page show English as output. Now attacker will inject following code into URL and send this link to the client through social engineering.

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English>

Great!! Now you can check the output in the given screenshot.

Medium Security

Let change the security level from low to medium level

In medium security the developer has tried to add a simple pattern matching to remove any references to "

Beginners Guide to Cross Site Scripting (XSS)

Java Script

JavaScript is the programming language of the web. It's one of the most popular and in demand skills in today's job market for good reason. JavaScript enables you to add powerful interactions to websites

A Scripting Language understood by the browser.

JS is embedded in HTML Pages

The Browser RUNS the js instead of displaying it

The tags.

Event Handler

When JavaScript is used in HTML pages, JavaScript can "react" on these events.

When the page loads, it is called an event. When the user clicks a button, that click too is an event. Other examples include events like pressing any key, closing a window, resizing a window, etc.

Onload 

Basically java script uses onload function to load an object on any web page. For example I want to generate an alert for user those who visit my website; I will give the following JavaScript code.

So whenever the body tag loads, an alert will pop up with following text Welcome to Hacking Articles for the visitors. Here the loading of the body tag is an event or a happening and onload is an event handler which decides what will action will happen on that event.

Similarly, there are many JavaScript event handlers which define what event occurs for such type of action like scroll down of page, or when an image fails to load etc.

Onmouseover

Onmouseover, when the user moves his cursor over the text, the additional code will be executed. For example let understand following code:

surprise

Now when user moves his cursor over the surprise the displayed text on the page, an alert box will pop up with 50% discount.

onclick:	Use this to invoke JavaScript upon clicking (a link, or form boxes)
onload:	Use this to invoke JavaScript after the page or an image has finished loading
onmouseover	Use this to invoke JavaScript if the mouse passes by some link
onmouseout	Use this to invoke JavaScript if the mouse goes pass some link
onunload	Use this to invoke JavaScript right after someone leaves this page.

Cross Site Scripting (XSS)

XSS is listed as top third web application security risk in the OWASP to top 10 risk model 2017.

Cross-site scripting (XSS) is a flaw in a web application that allows an attacker to execute malicious JavaScript through code injection attack in another victim's browser.

In this attack user is not directly targeted through a payload, although attacker shoot the XSS vulnerability by inserting malicious script into a web page that appears to be a genuine part of the website to the users, whenever any user visit that website it will automatically send the malicious JavaScript code in his browser without his knowledge.

Let’s take an example that following code is XSS vulnerable, an attacker may possibly present a history that holds a malicious payload such as 

Print ""

Print "

Recent History

"

Print request.Recent History print "

"

Users visiting the web page will get the following HTML page without his knowledge.

Recent History

              Types of XSS:

There are actually three types of Cross-Site Scripting, commonly named as:

·         Persistent XSS

·         Non-persistent XSS

·         DOM-Based XSS

Persistent

A persistent XSS also known as stored XSS because through this vulnerability the injected malicious script get permanently stored inside the webserver and the application server give out it back to the user when he visits the respective website. Hence when the client will click on payload which appears as an official part of the website, the injected JavaScript will get execute by the browser. The most common example is comment option on blogs, which allow the users to POST their comment for administer or other user.

Persistent XSS is considered more dangerous because the malicious payload is stored inside web server as the more visitors will interact with the website will result into more XSS infected user. Attack does not require phishing technique to target its users.

Example:

An example of a web application vulnerable to stored XSS as shown in the screenshot.

This JavaScript gets stored in the database of the web application and gets executed on the victim's browser, which capture the cookie and send it to the attacker.

Read complete article from here

Non-Persistent

The non-persistent XSS is also known as reflected XSS is occurs when the web application respond immediately on user’s input without validating the inputs this lead an attacker to injects browser executable code inside the single HTML response. It’s named as “non-persistent” since the malicious script does not get stored inside the web server, therefore attacker will send the malicious link through phishing to trap the user.

The most common applying of this kind of vulnerability is in Search engines in website: the attacker writes some arbitrary HTML code in the search textbox and, if the website is vulnerable, the result page will return the result of these HTML entities.

Example:

An example of a web application vulnerable to reflected XSS as shown in the screenshot.

It is also known as type 1 because this attack is carried out through single request/response then gets executed on the victim's browser, and will prompt an alert “hellllooo” to his browser.

Read complete article from here

DOM-Based:

The Document Object Model (DOM) is an API that increases the skill of programmers or developers to produce and change HTML and XML documents as programming objects.

The JavaScript language is used in DOM, which is also used for other websites. Through JavaScript it allows programmer to make the dynamic changes in HTML document can be accessed, modify, deleted, or added using the DOM.

When an HTML document is loaded into a web browser, it becomes a document object.

The document object is the root node of the HTML document and the "owner" of all other nodes

The HTML DOM model is constructed as a tree of Objects

With the object model, JavaScript gets all the power it needs to create dynamic HTML:

·         JavaScript can change all the HTML elements in the page

·         JavaScript can change all the HTML attributes in the page

·         JavaScript can change all the CSS styles in the page

·         JavaScript can remove existing HTML elements and attributes

·         JavaScript can add new HTML elements and attributes

·         JavaScript can react to all existing HTML events in the page

·         JavaScript can create new HTML events in the page

The DOM-Based Cross-Site Scripting is vulnerability which appears in document object model instead of html page. An attacker is not allowed to execute malicious script on the user’s website although on his local machine in URL, it is quite different from reflected and XSS because in this attack developer cannot able to find malicious script in HTML source code as well as in HTML response, it can be observed at execution time.

The DOM-Based XSS exploits these problems on user’s local machines in this way:

– The attacker creates a well built malicious website
– The ingenious user opens that sites
– The user has a vulnerable page on his machine
– The attacker’s website sends commands to the vulnerable HTML page
– The vulnerable local page execute that commands with the user’s privileges on that machine.
– The attacker easily gain control on the victim computer.

Example:

The following screenshot is an example of a web application server that is affect with DOM based XSS attack. The web application let you to choose the following language and will execute through URL.

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English

Attacker will add malicious script inside URL

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English#

The major difference between DOM XSS and Reflected or Stored XSS flaw is that it cannot be stopped by server-side filters because anything written after the "#" (hash) will never forward to the server.

Beginner Guide to File Inclusion Attack (LFI/RFI)

You can insert the content of one PHP file into another PHP file before the server executes it, with the include () function. The function can be used to create functions, headers, footers or element that will be reused on multiple pages.

This will help developers to make it easy to change the layout of complete website with minimal effort.

If there is any change required then instead of changing thousands of files just change included file.

Assume we have a standard footer file called "footer.php", that looks like this

echo "Copyright © 2010-" . date("Y") . " hackingartices.in
";

?>

To include the footer file in a page, use the include statement

Welcome to Hacking Articles

Some text.

Some more text.

Example 2

Assume we have a file called "vars.php", with some variables defined:

$color='red';

$car='BMW';

?>

Welcome to my home page!

echo "I have a $color $car.";

?>

Output: I have red BMW

PHP Require Function

The require statement is also used to include a file into the PHP code.

However, there is one big difference between include and require; when a file is included with the include statement and PHP cannot find it, the script will continue to execute:

Example 3

Welcome to my home page!

 include 'noFileExists.php';
echo "I have a $color $car.";
?>

Output: I have a

If we do the same example using the require statement, the echo statement will not be executed because the script execution dies after the require statement returned a fatal error:

Welcome to my home page!

 require 'noFileExists.php';
echo "I have a $color $car.";
?>

No output result

PHP Required_once Function

Require_once() using this function we can access the data of another page once when you may need to include the called file more than once, It works the same way. The only difference between require and require_once is that If it is found that the file has already been included, calling script is going to ignore further inclusions.

Example 4

echo.php

echo "Hello";
?>

test.php

require('echo.php');
require_once('echo.php');
?>

outputs: "Hello"

Note

allow_url_include is disabled by default. If allow_url_fopen is disabled, allow_url_include is also disabled

You can enable allow_url_include from php.ini

/etc/php7/apache2/php.ini

allow_url_include = On

File Inclusion Attacks

It is an attack that allows an attacker to include a file on the web server through a php script. This vulnerability arises when a web application lets the client to submit input into files or upload files to the server.

This can lead following attacks:

·         Code execution on the web server

·         Cross Site Scripting Attacks (XSS)

·         Denial of service (DOS)

·         Data Manipulation Attacks

Two Types:

Local File Inclusion

Remote File Inclusion

Local File Inclusion (LFI)

Local file inclusion vulnerability occur when a file to which to PHP account has accessed is passed as a parameter to the PHP function “include”, or “require_once”

This vulnerability occurs, for example, when a page receives, as inputs the path to the file that has to be included  and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected.

Example – Local File Inclusion

http://192.168.1.8/dvwa/vulnerabilities/fi/?page=file1.php

http://192.168.1.8/dvwa/vulnerabilities/fi/?page=/etc/passwd

Read complete local file inclusion attack tutorial from here

Remote File Inclusion (RFI)

Remote File Inclusion occurs when the URI of a file located on a different server is passed to as a parameter to the PHP function “include”, “include_once” , “require” , or “require_once” . PHP incorporates the content into the pages. If the content happens to be PHP source code, PHP executes the file.

PHP Remote File inclusion allows and attacker to embed his/her own PHP code inside  a vulnerable  PHP script , which may lead to disastrous results such as allowing the attacker to execute remote commands on the web server, deface parts of the web or even steal confidential information.

http://192.168.1.8/dvwa/vulnerabilities/fi/?page=file1.php

http:// 192.168.1.8/dvwa/vulnerabilities/fi/?page=http://google.com

Read complete remote file inclusion attack tutorial from here

Mitigation

·         Strong Input Validation

·         A whitelist of acceptable inputs

·         Reject any inputs that does not strictly conform to specifications

·         For filenames, use stringent whitelists that limits the character set to be used

·         Exclude directory separators such as “/”

·         Use a whitelist of allowable file extensions

·         Environment hardening

·         Develop and run your code in the most recent versions of PHP available

·         Configure your PHP applications so that it does not use register_globals

·         Set allow_url_fopen to false, which limits the ability to include files from remote locations

·         Run your code using the lowest privileges

·         Use a vetted library or framework that does not allow this weakness.

Source: https://www.w3schools.com/ 

               https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion

               https://www.acunetix.com

How to Spider Web Applications using Burpsuite

Hello friends! Today we are doing web penetration testing using burp suite spider which very rapidly crawl entire web application and dump the formation of targeted web site.

Burp Spider is a tool for automatically crawling web applications. While it is generally preferable to map applications manually, you can use Burp Spider to partially automate this process for very large applications, or when you are short of time.

Source: https://portswigger.net/burp/help/spider.html

Let’s begin!!

First attacker needs to configure browser and burp proxy to work properly, www.tetphp.vulnweb.com will my targetd web site for enumeration.

Form given below screenshot you can see currently there is no targeted website inside site map of burp suite. To add your targeted web site inside it you need to fetch the http request send by browser to web application server, using intercept option of proxy tab.

Click on proxy tab and turn on intercept in order to catch http request.

Here you can observe that I had fetched the http request of www.tetphp.vulnweb.com; now send to spider with help of action tab.

Confirm your action by making click on YES; Burp will alter the existing target scope to include the preferred item, and all sub-items contained by the site map tree.

Now choose spider tab for further step, here you will find two sub categories control tab and option.

Burp Spider - Control Tab

This tab is used to start and stop Burp Spider, monitor its progress, and define the spidering scope.

Spider Status

Use these settings to monitor and control Burp Spider:

·         Spider is paused / running - This toggle button is used to start and stop the Spider. While the Spider is stopped it will not make any requests of its own, although it will continue to process responses generated via Burp Proxy (if passive spidering is enabled), and any newly-discovered items that are within the spidering scope will be queued to be requested if the Spider is restarted.

·         Clear queues - If you want to reprioritize your work, you can completely clear the currently queued items, so that other items can be added to the queue. Note that the cleared items may be re-queued if they remain in-scope and the Spider's parser encounters new links to the items.

Spider Scope

This panel lets you define exactly what is in the scope for the Spider to request.

The best way to handle spidering scope is normally using the suite-wide target scope, and by default the Spider will use that scope.

Burp Spider Options

This tab contains options for the basic crawler settings, passive spidering, form submission , application login, the Spider engine, and HTTP request headers .

You can monitor the status of the Spider when running, via the Control tab. Any newly discovered content will be added to the Target site map.

When spidering a selected branch of the site map, Burp will carry out the following actions (depending on your settings):

·         Request any unrequested URLs already present within the branch.

·         Submit any discovered forms whose action URLs lay within the branch.

·         Re-request any items in the branch that previously returned 304 status codes, to retrieve fresh (uncached) copies of the application's responses.

·         Parse all content retrieved to identify new URLs and forms.

·         Recursively repeat these steps as new content is discovered.

·         Continue spidering all in-scope areas until no new content is discovered.

Hence you can see the targeted website has been added inside the site map as a new scope for web crawling. Choose spider this host option by making right click on selected URL which automatically start web crawling.

When you click on preferred target site map further content which has been discover by spider will get added inside it as shown in given image below.

Form screenshot you can see its dump all items of web site even by throwing request and response of host.