Web Application Attacks ECE 4112 Fall 2007 Group 9 Zafeer Khan & Simmon Yau

Web Application AttacksECE 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).


HTTP Response Splitting http://website/redirect.php?page=http://website/

welcome.html http://website/redirect.php?page =0d%0aContent-Type:

%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%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>


Cross Site Scripting http://website/redirect.php?page=http://website/

hacked.html Runs a JavaScript popup asking for Credit Card

Number


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%20logintable%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 notAbility to gain access to private account informationLarge sums of money involvedHackers 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. register_globals was enabled (usually disabled

for security purposes)

2. 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?somepage=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/downloads/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-

In-PHP-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

Documents

Web Application Attacks ECE 4112 Fall 2007 Group 9 Zafeer Khan & Simmon Yau