csc 382/582: computer security

CSC 382/582: Computer Security Slide #1

CSC 382/582: Computer Security

Web Security


Topics

1. HTTP

2. Web Input

3. Canonicalization

4. Authentication

5. SQL Injection

6. Cross-Site Scripting

7. Client-side Attacks

8. Finding Web Vulnerabilities


Web Transactions

Web Browser

OS

Web Server

Network

HTTP Request

HTTP Response


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.


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

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

<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


URL Obfuscation

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


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


Cookies

Parameters• Name• Value• Expiration Date• Domain• Path• Secure Connections Only


Cookies

Server to ClientContent-type: text/html

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

Client to ServerContent-type: text/html

Cookie: foo=bar


Javascript Input Validation

• User-friendly– convenient, immediate feedback

• Not secure– Client can turn off Javascript– Client may not use your form– User input may be altered btw browser & server.


SSL

• Secure Sockets Layer (SSL)– Standard for HTTP encryption.– New version: Transport Layer Security (TLS)

• SSL Phases– Cipher negotiation– Public-key authentication + key exchange– Symmetric encryption of traffic

• Authentication– Both client and server can use digital certificates


Web Input Summary

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


Win/Apache Directory Traversal

• Apache 2.0.39 and earlier

• To view the file winnt\win.ini: http://127.0.0.1/error/%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cwinnt%5cwin.ini

which is the escaped form of

• http://127.0.0.1/error/\..\..\..\..\winnt\win.ini

http://127.0.0.1/error/%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5Cwinnt%5Cwin.ini




Naïve Solution to Name Issues

Remove or check for known insecure elements in original pathname, i.e.

“..”

“/cgi-bin” or other protected directories

“.exe” or other special filename extensions

Trailing “.” or “\”

URI-escaped characters


IIS Directory Traversal

• MS Internet Information Server 4 + 5

• Execute shell command: http://127.0.0.1/scripts/..

%c0%af../winnt/system32/cmd.exewhere %c0%af is 2-byte UTF-8 encoding “/”

• Problem: Too many ways to encode paths.


Canonicalization

• Resolve all names to canonical name using operating system functions.– Use standard OS function where available.

• Do access control using canonical name.


Web Authentication

• Initial authentication by password.

• How does web app remember authentication?– Cookies– Hidden form fields– URL paths

• Problem: client can tamper with all three.


Secure Web Authentication

• Encrypt and MAC auth data– User cannot read data to learn how to tamper.– MAC with secret key deters tampering attempts.

• What about replay attacks?– Include expiration time inside cookie.– Include client IP address.– Use dynamic session IDs, different on each page.


SQL Injectionuse DBI;

$dbh = DBI->connect($conn, $dbusername, $dbpassword) or die “Database connection failed.\n”;$sql = “SELECT count(*) from users where username =

‘$username’ and password = ‘$password’”;$sth = $dbh->prepare($sql) or die “Prepare failed.\n”;$sth->execute() or die “Execute failed.\n”;

What if user gives SQL code as name or password?


SQL Injection Attack #1

• Unauthorized Access Attempt:– password = ’ or 1=1 --

• SQL statement becomes:– select count(*) from users where username =

‘user’ and password = ‘’ or 1=1 --– Checks if password is empty OR 1=1, which is

always true, permitting access.


SQL Injection Attack #2

• Database Modification Attack:– password = foo’; delete from table users

where username like ‘%

• Database executes two SQL statements:– select count(*) from users where username =

‘user’ and password = ‘foo’– delete from table users where username like

‘%’


Beyond the Database

• ODBC allows shell injection via “|”– ‘|shell(“cmd /c echo “ & chr(124) & “format

c:”)|’

• MS SQL Server Extended Stored Procs– Shell: exec master..xp_cmdshell ‘format c:’– Create new DB accounts: xp_grantlogin– Read any file: bulk insert foo from “c:\d.txt”


The Problem: String BuildingBuilding a SQL command string with user input in any language is dangerous.

– Variable interpolation.– String concatentation with variables.– String format functions like sprintf().– String templating with variable replacement.


Bad Solution: BlacklistAttempted solution: Blacklist SQLmetacharacters, especially single quotes.

Problems:1. Numeric parameters don’t use quotes.

2. Database-escaped quotes: \’

3. URL escaped metacharacters.

4. Unicode encoded metacharacters.

5. Did you miss any metacharacters?

6. 2nd Order SQL Injection.


Numeric Parameters

• Solution: Escape single quotes

• Problem #1: What if you use stored user data?– Q: select count(*) from users where uid=$uid– User enters uid = 1 or 1=1– Query becomes:

• select count(*) from users where uid=1 or 1=1

• Once again, this query is always true.


Solution: Prepared Queriesuse DBI;

$dbh = DBI->connect(conn(), $db_username, $db_password) or

die “Database connection failed.\n”;

$sql = “SELECT count(*) from users where username = ? and password = ?”;

$sth = $dbh->prepare($sql) or die “Prepare failed.\n”;

$sth->bind_param(1, $username);

$sth->bind_param(2, $password);

$sth->execute() or die “Execute failed.\n”;


Cross-Site Scripting (XSS)

• #1 vulnerability in 2005 (16%), 2006 (21.5%)

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

• Typical Goal: obtain user auth cookies for– Bank site (transfer money to attacker)– Shopping site (buy goods for attacker)– E-mail


XSS Attacks

• MySpace worm (October 2005)– When someone viewed Samy’s profile:

• Set him as friend of viewer.• Incorporated code in viewer’s profile.

• Paypal (2006)– XSS redirect used to steal money from Paypal users in a

phishing scam.

• BBC, CBS (2006)– By following XSS link from securitylab.ru, you could

read an apparently valid story on the BBC or CBS site claiming that Bush appointed a 9-year old as head of the Information Security department.


Stored vs Reflected XSS

• Stored XSS– Injected script stored in comment, message, etc.– Requires ability to insert malicious code into

web documents (comments, reviews, etc.)– Persistent until message deleted.

• Reflected XSS– Injected script returned by one-time message.– Requires tricking user to click on link.– Non-persistent. Only works when user clicks.


Why does XSS Work?

• Same-Origin Policy– Browser only allows Javascript from site X to

access cookies and other data from site X.– Attacker needs to make attack come from site X.

• Vulnerable Server Program– Any program that returns user input without

filtering out dangerous code.


Anatomy of an XSS Attack

1. Login

2.

Cookie

Web Server

3. XSS Attack

Attacker User

4. User clicks on XSS link.

5. XSS URL

7. Browser runs injected code.

Evil Site saves cookie.

8. Attacker uses stolen cookie to hijack user session.

6. Page with injected code.


Anatomy of an XSS Attack1. User logs into legitimate site.2. Site sends user authentication cookie.3. Attacker sends user XSS attack containing injected code.4. User clicks on XSS link in email, web, IM.5. Browser contacts vulnerable URL at legitimate site with

cookie in URL.6. Legitimate site returns injected code in web page.7. Browser runs injected code, which accesses evil site with

cookie in URL.8. Evil site records user cookie.9. Attacker uses cookie to authenticate to legitimate site as

user.


XSS URL Exampleshttp://www.microsoft.com/education/?

ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><script>alert(document.cookie)</script>

http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=<script>alert(‘Test’);</script>

http://www.shopnbc.com/listing.asp?qu=<script>alert(document.cookie)</script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1

http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E


Preventing XSS• Client: Disable scripting

– Use NoScript to permit some sites to use scripts.• Server: Disallow HTML input

– Reject any input with HTML– Replace HTML special characters

• ex: replace < with < and > with >• also replace (, ), #, &

• Server: Allow only safe HTML tags– Escape all HTML tags except whitelisted ones

• Server: tagged cookies– Include IP address in cookie and only allow access to

original IP address that cookie was created for.


Client-side Attacks

• Buffer Overflow– 2004 iframe– 2004-05 jpeg

• Remote Code– ActiveX– Flash– Java– Javascript


ActiveX

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


Client Protection

• Disable ActiveX and Java.• 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 Vulnerabilities– Cross-Site Scripting– SQL Injection


References1. Chris Anley, “Advanced SQL Injection In SQL Server Applications,”

http://www.nextgenss.com/papers/advanced_sql_injection.pdf, 2002.2. CERT, “Understanding Malicious Content Mitigation for Web Developers,”

http://www.cert.org/tech_tips/malicious_code_mitigation.html, Feb. 2000 3. David Endler, “The Evolution of Cross-Site Scripting Attacks,”

http://www.cgisecurity.com/development/xss.shtml, 2002.4. Joris Evers, “Paypal fixes Phishing hole,” http://news.com.com/PayPal+fixes+phishing+hole/2100-

7349_3-6084974.html, 2006.5. Stephen J. Friedl, “SQL Injection Attacks by Example,” http://www.unixwiz.net/techtips/sql-

injection.html, 2005.6. Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security, McGraw-Hill

Osborne, 2005.7. Johnny Long, Google Hacking for Penetration Testers, Syngress, 2004.8. Johnny Long, Google Hacking Database, http://johnny.ihackstuff.com, 2006.9. Nate Mook, “Cross-Site Scripting Worm Hits MySpace,”

http://www.betanews.com/article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391, 2005.10. Gunter Ollman, “HTML Code Injection and Cross-Site Scripting,”

http://www.technicalinfo.net/papers/CSS.html, 2002.11. Samy, “MySpace Worm Explanation,” http://namb.la/popular/tech.html, 2005.12. Stuart McClure, Joel Scambray, and George Kurtz, Hacking Exposed, 5/e, McGraw-Hill, 2005.13. Stuart McClure, Saumil Shah and Shreeraj Shah, Web Hacking: Attacks and Defense, Addison-

Wesley, 2002.14. Joel Scambray, Mike Shema, Caleb Sima, Hacking Exposed Web Applications, Second Edition,

McGraw-Hill, 2006.15. Ed Skoudis, Counter Hack Reloaded, Prentice Hall, 2006.16. SK, “SQL Injection Walkthrough,” http://www.securiteam.com/securityreviews/5DP0N1P76E.html,

2002.

csc 382/582: computer security

Documents