Beginner Guide to Insecure Direct Object References (IDOR)

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.

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Beginner Guide to OS Command Injection

The dynamic Web applications may make the most of scripts to call up some functionality in the command line on the web server to process the input that received from the client and unsafe user input may led to OS command injection.  OS Command injection is refer as shell injection attack arise when an attacker try to perform system level commands through a vulnerable application in order to retrieve information of  web server or try to make unauthorized access into server .

Impact Analysis

Impact: Critical

Ease of Exploitability: Medium

Risk Rating: High

In this attack the attacker will inject his unwanted system level command so that he can fetch the information of web server; for example: ls , whoami , uname -a and etc.

Let’s consider a scenario where web application allows user to PING an IP other user so that it get confirms that the host connection 

Verify parameters to inject data

 The following parameters should be tested for command injection flaws, as the application may be using one of these parameters to build a command back at the web server:

  • GET: In this method input parameters are sent in URLs.
  • POST: In this method, input parameters are sent in HTTP body.
  • HTTP header: Applications frequently use header fields to discover end users and display requested information to the user based on the value in the headers.

Some of the important header fields to check for command injection are:

  • Cookies
  • X-Forwarded-For
  • User-agent
  • Referrer

METACHARACTER

Using vulnerability scanner attacker come to know that current web application is vulnerable to command injection and try injecting system level unwanted command using Meta character.

Metacharacter are symbolic operators which are use to separate actual command from unwanted command. The ampercent (&) was used as a separator that would divide the authentic input and the command that you are trying to inject.

It will more clear in following image where attacker will inject his payload dir using metacharacter that retrieve present directory of web server.  

As result it will dump following output as shown in given image where it has validated wrong user input.

OS Command Injection Operators

 The developer possibly will set filters to obstruct the some metacharacter. This would block our injected data, and thus we need to try out with other metacharacters too, as shown in the following table:

Operators Description
; The semicolon is most common metacharacter used to test an injection flaw. The shell would run all the commands in sequence separated by the semicolon.
& It separates multiple commands on one command line. It runs the first command then the second command.
&& It runs the command following  && only if the preceding command is successful
||(windows) It run the command following || only if the preceding command fails. Runs the first command then runs the second command only if the first command did not complete successfully.
|| ( Linux) Redirects standard outputs of the first command to standard input of the second command
The unquoting metacharacter is used to force the shell to interpret and run the command between the backticks. Following is an example of this command: Variable= “OS version `uname -a`” && echo $variable
() It is used to nest commands
# It is used as command line comment

Steps to exploit – OS Command Injection

Step 1: Identify the input field

Step 2: Understand the functionality

Step 3: Try the Ping method time delay

Step 4: Use various operators to exploit OS command Injection

Type of Command Injection

 Error based injection: When attacker injects a command through an input parameter and the output of that command is displayed on the certain web page, it proof that the application is vulnerable to the command injection. The displayed result might be in the form of an error or the actual outcomes of the command that you tried to run. An attacker then modifies and adds additional commands depending on the shell the web server and assembles information from the application.

Blind based Injection: The results of the commands that you inject will not displayed to the attacker and no error messages are returned it similar as blind SQL injection. The attacker will use another technique to identify whether the command was really executed on the server.

Mitigation-OS Command Injection

  • Strong server side validation
  • Implement a white list
  • OS Hardening
  • Use build in API’s for interacting with the OS if needed. More secure!!
  • Avoid applications from calling out directly the OS system commands

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Understanding the HTTP Protocol

HTTP (Hyper Text Transfer Protocol) is basically a client-server protocol, wherein the client (web browser) makes a request to the server and in return the server responds to the request. The response by the server is mostly in the form of HTML formatted pages. HTTP protocol by default uses port 80, but the web server and the client can be configured to use a different port.

HTTP is a stateless protocol which means that server does not retain the information by each user. HTTP is the backbone of the World Wide Web (www) and for it being stateless simply means that it does not remember each and every client that connects to the internet and it does not matter if a single user sends multiple requests one after another, they all will still be treated as independent requests by the server.

We are currently using HTTP 2, its predecessors were HTTP 1.0 and 1.1, and the major differences between 1.X and 2, at a higher level, are:

  • Http 2 is binary and not textual
  • Http 2 is multiplexed, it can use a single connection for parallelism, Http one on the other hand is based on ordering and blocking.
  • Http 2 uses compression in its headers to reduce the overhead.
  • Http2 gives servers the capability to “push” responses to client servers proactively.

HTTP works through different methods and these methods are:

HTTP Request Methods

Method Description
GET Used to retrieve information from the given URL
POST Used to send data to the server, for example, customer information, file upload, etc. using HTML forms
DELETE Delete a File of the specified URL
PUT Uploads a File of the specified URL
TRACE Trace on the jsp resource returns the content of the resource.
HEAD GET only HTTP headers and no document body
OPTIONS HTTP methods that the server supports

There is major difference between GET and POST method which people fail to understand. Once you understand these properly, you can manipulate and increase the security of your web application. The differences are as follows:

GET POST
Get request can be cached Post request are never cached
Remain in browser history Do not remain in browser history
It can be bookmarked It cannot be bookmarked
Get request should never be used when dealing with sensitive data Post should always be used for sensitive data
Get request has length restriction post request have no length restriction
Get request should be used to retrieve data
It is less secure It is more secure

An HTTP client sends an HTTP request to a server in the form of a request message which includes following format

http://yahoo.com/

GET / HTTP/1.1

Host: yahoo.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Connection: keep-alive

Upgrade-Insecure-Requests: 1

There are several fields in the header, but we will discuss the more important ones:

Host: This field is in the header and it is used to identify individual website by a hostname if they are sharing the same IP address. The client web browser also sets a user-agent string to identify the type and version of the browser.

User-Agent: This field is set correctly to its default values by the web browser, but it can be spoofed by the end user. This is usually done by malicious user to retrieve contents designed for other types of web browsers.

Cookie: This field stores a temporary value shared between the client and server for session management.

Referer: This is another important field that you would often see when you are redirected from one URL to another. This field contains the address of the previous web page from which a link to the current page was followed. Attackers manipulate the Referer field using an XSS attack and redirect the user to a malicious website.

Accept-Encoding: This field defines the compression scheme supported by the client; gzip and Deflate are the most common ones. There are other parameters too, but they are of little use to penetration testers.

Response

Response: When a request is sent to the server; the server replies in the form of response. Following is an example of response:

HTTP/1.1 200 OK

Date: Sat, 10 Jun 2017 05:17:18 GMT

Set-Cookie: autorf=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/;

domain=in.yahoo.com

Content-Type: text/html; charset=UTF-8

Server: ATS

Expires: -1

Content-Length: 477864

HTTP Response Code: The Status-Code element is a 3-digit integer where first digit of the Status-Code defines the class of response and the last two digits do not have any categorization role. There are 5 values for the first digit

Code Meaning Example
1xx Information 100: server agrees to handle client request.
2xx Success 200: request succeeded.

204: no client present.

3xx Redirection 301: page moved.

304: cached page still available.

4xx Client error 403: forbidden page.

404: page not found.

5xx Server error 500: internal server error.

503: try again later.

HTTP Version: A server supporting HTTP version 1.1 will return the following version information

 Date: The date and time that the message was originated

 Set-Cookie: This field, if defined, will contain a random value that can be used by the server to identify the client and store temporary data

Server: This field is of interest to a penetration tester and will help in the recon phase of a test. It displays useful information about the web server hosting the website.
Content-Length: This field will contain a value indicating the number of bytes in the body of the response. It is used so that the other party can know when the current request/response has finished.

Source:
https://www.tutorialspoint.com/http/index.htm

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
https://www.httpwatch.com/httpgallery/

AuthorYashika Dhir is a passionate Researcher and Technical Writer at Hacking Articles. She is a hacking enthusiast. contact here.

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

<?php

echo “<p>Copyright &copy; 2010-” . date(“Y”) . ” hackingartices.in</p>”;

?>

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

<html>

<body>

<h1>Welcome to Hacking Articles</h1>

<p>Some text.</p>

<p>Some more text.</p>

<?php include ‘footer.php’;?>

</body>

</html>

 Example 2

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

<?php

$color=’red’;

$car=’BMW’;

?>

 

<html>

<body>

 <h1>Welcome to my home page!</h1>

<?php include ‘vars.php’;

echo “I have a $color $car.”;

?>

 </body>

</html>

 

 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

 <html>
<body>
<h1>Welcome to my home page!</h1>
<?php include ‘noFileExists.php’;
echo “I have a $color $car.”;
?>
</body>
</html>

 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:

 <html>
<body>

<h1>Welcome to my home page!</h1>
<?php require ‘noFileExists.php’;
echo “I have a $color $car.”;
?>
</body>
</html>

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
<?php
echo “Hello”;
?>

test.php
<?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

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Related Posts Plugin for WordPress, Blogger...