Login

**NINZA** · 05-04-2020, 06:15 PM

0			0

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 information from other users and could be established 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 allows 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 a web server for changing his secret value but he is willing to perform some mischievous action that will change the secret value for another user.
[Image: 1.png?w=687&ssl=1]

Using burp suite we had captured the request of the browser where you can see in the given image login user is the bee and secret value is hello; now manipulate the user from another user.
SQLquery = “SELECT * FROM useraccounts WHERE account = ‘bee’;
[Image: 2.png?w=687&ssl=1]

Now let’s change user name into raj as shown in the given image. To perform this attack in an application it requires at least two user accounts.
SQLquery = “SELECT * FROM useraccounts WHERE account = ‘raj’;
[Image: 3.png?w=687&ssl=1]

Great!!! We have successfully changed the secret value for raj.
Note: in any official website the attacker will replace user account from an admin account.
[Image: 4.png?w=687&ssl=1]

Let take another scenario that looks quite familiar for most of the IDOR attack.
Many times we book different order online through their web application, for example, bookmyshow.com for movie ticket booking.
Let consider the 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.
[Image: 5.png?w=687&ssl=1]

Now you can see we have intercepted request were highlighted text contains a 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 desired price.
[Image: 6.png?w=687&ssl=1]

I had changed it into 1 EUR which means now it will reduce only 10 EUR from the account, you can observe it from a given image then forward the request.
[Image: 7.png?w=687&ssl=1]

Awesome!!! We had booked the 10 tickets in 10 EUR only.
[Image: 8.png?w=687&ssl=1]

The dynamic Web applications may make the most of the 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 lead to OS command injection. OS Command injection is referred as shell injection attack arise when an attacker tries to perform system level commands through a vulnerable application in order to retrieve information of web server or try to make unauthorized access into the 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 the user to PING an IP another user so that it get confirms that the host connection
[Image: 1.png?w=687&ssl=1]

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 the 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 is symbolic operators which are used 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 the attacker will inject his payload dir using metacharacter that retrieves a present directory of the web server.
[Image: 2.png?w=687&ssl=1]

As result, it will dump the following output as shown in the given image where it has validated wrong user input.
[Image: 3.png?w=687&ssl=1]

OS Command Injection Operators
The developer possibly will set filters to obstruct 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 runs 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

Code:
The contents of this section are hidden for your group

Register or Login
” && echo $variable
()
It is used to nest commands
#
It is used as a 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 an attacker injects a command through an input parameter and the output of that command is displayed on the certain web page, it proves 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 be 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

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 caused 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 a document object model instead of the 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 the browser; now login with admin: password into a web application and Set security level low.
[Image: 1.png?w=687&ssl=1]

Select the DOM cross-site scripting vulnerability from a given list of vulnerability. The web application allows the user to select any language from drop-down list.
[Image: 2.png?w=687&ssl=1]

Now let’s understand the current scenario when security is low; in this part, the developer has not added any filter while framing the code for a 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.
[Image: 3.1.png?w=687&ssl=1]

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
1
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 shows English as output. Now attacker will inject following code into URL <script>alert(“hack”);</script> and send this link to the client through social engineering.
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English<script>alert("hack");</script>
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English<script>alert("hack");</script>
Great!! Now you can check the output in the given screenshot.
[Image: 3.png?w=687&ssl=1]

Medium Security
Let change the security level from low to medium level
[Image: 4.png?w=687&ssl=1]

In medium security, the developer has tried to add a simple pattern matching to remove any references to “<script” to disable any JavaScript for location default =English, hence above JavaScript code will not run to execute malicious script in medium security level. Find a way to run JavaScript without using the script tags
[Image: 5.1.png?resize=613%2C273&ssl=1]

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
Similarly, this time attacker will try a different technique to exploit the vulnerability, he can insert malicious script using JavaScript onload function >onload=alert(“XSS”)> and send the link to victim. In this level attacker first, need to break out the select block to inject body onload or image tag.
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English>/opttion></select><body onload=alert("XSS")>
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English>/opttion></select><body onload=alert("XSS")>
[Image: 5-1.png?resize=687%2C521&ssl=1]

High Security
Now increase the security level from medium to high.
[Image: 6.png?resize=267%2C129&ssl=1]

In high security, the developer is now whitelisting only the allowed languages, you must find a way to run your code without it going to the server.
[Image: 7.1.png?resize=622%2C365&ssl=1]

http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
The fragment section of a URL anything after the # (hash) symbol does not get sent to the server and so cannot be blocked. The bad JavaScript being used to make the page reads the content from it when creating the page.
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English#<script>alert("you have been hacked");</script>
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English#<script>alert("you have been hacked");</script>
Awesome!!! We have successfully bypassed all three security level of DVWA
[Image: 7.png?resize=655%2C405&ssl=1]

JavaScript
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
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 clicks to is an event. Other examples include events like pressing any key, closing a window, resizing a window, etc.
Onload
Basically, javascript uses the 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.
<body onload=alert(‘Welcome to Hacking Articles’)>
So whenever the body tag loads, an alert will pop up with the 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 the 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 the following code:
<a onmouseover=alert(“50% discount”)>surprise</a>
Now when the 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 a 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 <script>alert(HACK);</script>
Print “<html>”
Print “<h1>Recent History</h1>”
Print request.Recent History print “</html>“
Users visiting the web page will get the following HTML page without his knowledge.
<html>
<h1> Recent History </h1>
<script>alert (HACK);</script>
</html>
[Image: 0.jpg?w=687&ssl=1]

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 was known as stored XSS because through this vulnerability the injected malicious script get permanently stored inside the web server 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 executed by the browser. The most common example is comment option on blogs, which allow the users to POST their comment for the administrator or another user.
Persistent XSS is considered more dangerous because the malicious payload is stored inside the web server as the more visitors will interact with the website will result in more XSS infected user. The attack does not require the phishing technique to target its users.
Example:
An example of a web application vulnerable to stored XSS as shown in the screenshot.
<script>alert(document.cookie)</script>
1
<script>alert(document.cookie)</script>
This JavaScript gets stored in the database of the web application and gets executed on the victim’s browser, which captures the cookie and sends it to the attacker
[Image: 4.png?w=687&ssl=1]

Read complete article from

[To see content please register here]

Non-Persistent
The non-persistent XSS is also known as reflected XSS occurs when the web application responds immediately on user’s input without validating the inputs this lead an attacker to inject 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 the 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.
<script>alert(“hellllooo”)</script>
1
<script>alert(“hellllooo”)</script>
It is also known as type 1 because this attack is carried out through a single request/response then gets executed on the victim’s browser, and will prompt an alert “hellllooo” to his browser.
[Image: 2.png?w=687&ssl=1]

Read complete article from

[To see content please register 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 the 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
[Image: 1.gif?w=687&ssl=1]

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 on the page

The DOM-Based Cross-Site Scripting is vulnerability which appears in a document object model instead of the 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 the 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 executes that commands with the user’s privileges on that machine.
– The attacker easily gains control of the victim computer.
Example:
The following screenshot is an example of a web application server that is affected with DOM-based XSS attack. The web application let you choose the following language and will execute through URL.
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English
The attacker will add malicious script inside URL
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English#<script>alert("you have been hacked");</script>
1
http://localhost:81/dvwa/vulnerabilities/xss_d/?default=English#<script>alert("you have been hacked");</script>
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.
[Image: 7.png?w=687&ssl=1]

Source:

[To see content please register here]

Login
Username: Password: Lost Password? Remember me
Or Register an account

Announcement : For Purchasing Advertising Contact Us | Jabber : [email protected] | Telegram :- @bhcis

Announcement :

For Purchasing Advertising Contact Us | Jabber : [email protected] | Telegram :- @bhcis