Web Server Design Week 12 Old Dominion University

Slides:



Advertisements
Similar presentations
2/9/2004 Web and HTTP February 9, /9/2004 Assignments Due – Reading and Warmup Work on Message of the Day.
Advertisements

FTP (File Transfer Protocol) & Telnet
CP476 Internet Computing Lecture 5 : HTTP, WWW and URL 1 Lecture 5. WWW, HTTP and URL Objective: to review the concepts of WWW to understand how HTTP works.
Web Programming Week 1 Old Dominion University Department of Computer Science CS 418/518 Fall 2010 Martin Klein 8/31/10.
Web Server Design Week 8 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 3/3/10.
Web Server Design Week 4 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 2/03/10.
CIS679: Lecture 13 r Review of Last Lecture r More on HTTP.
Web Server Design Week 11 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 3/24/10.
Web Server Design Assignment #2: Conditionals & Persistence Due: 02/24/2010 Old Dominion University Department of Computer Science CS 495/595 Spring 2010.
Web Server Design Week 13 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 4/7/10.
Web Server Design Assignment #4: Authentication Due: 04/14/2010 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein.
Web Server Design Week 6 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 2/17/10.
Web Server Design Assignment #5: Unsafe Methods & CGI Due: 05/05/2010 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin.
Web Server Design Week 12 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 3/31/10.
Web Server Design Week 10 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein 3/17/10.
Web Server Design Week 5 Old Dominion University Department of Computer Science CS 495/595 Spring 2012 Michael L. Nelson 02/07/12.
Web Programming Week 1 Old Dominion University Department of Computer Science CS 418/518 Fall 2007 Michael L. Nelson 8/27/07.
Web Server Design Week 13 Old Dominion University Department of Computer Science CS 495/595 Spring 2012 Michael L. Nelson 04/03/12.
Web Server Design Week 15 Old Dominion University Department of Computer Science CS 495/595 Spring 2009 Michael L. Nelson 4/20/09.
Web Server Design Week 3 Old Dominion University Department of Computer Science CS 495/595 Spring 2006 Michael L. Nelson 1/23/06.
Web Server Design Week 6 Old Dominion University Department of Computer Science CS 495/595 Spring 2006 Michael L. Nelson 2/13/06.
Block 5: An application layer protocol: HTTP
Hypertext Transfer Protocol
HTTP – An overview.
Web Server Design Week 10 Old Dominion University
Web Server Design Week 4 Old Dominion University
Web Server Design Assignment #5: Unsafe Methods & CGI
Hypertext Transfer Protocol
Hypertext Transport Protocol
Web Server Design Assignment #4: Authentication
Web Server Design Assignment #2: Conditionals & Persistence
Web Server Design Week 8 Old Dominion University
Web Server Design Week 11 Old Dominion University
Web Server Design Week 7 Old Dominion University
HTTP Protocol.
Web Server Design Assignment #5 Extra Credit
HTTP Hypertext Transfer Protocol
Web Server Design Week 4 Old Dominion University
Web Server Design Week 15 Old Dominion University
Web Server Design Week 5 Old Dominion University
Web Server Design Week 13 Old Dominion University
CS 5565 Network Architecture and Protocols
Web Server Design Assignment #2: Conditionals & Persistence
HTTP GET vs POST SE-2840 Dr. Mark L. Hornick.
Web Server Design Week 8 Old Dominion University
Web Server Design Week 8 Old Dominion University
Web Server Design Week 6 Old Dominion University
Web Server Design Week 10 Old Dominion University
Web Server Design Week 13 Old Dominion University
Web Server Design Week 13 Old Dominion University
Web Server Design Week 8 Old Dominion University
Web Server Design Week 3 Old Dominion University
Web Server Design Week 11 Old Dominion University
Web Server Design Week 5 Old Dominion University
Web Server Design Week 11 Old Dominion University
Web Server Design Week 3 Old Dominion University
Web Server Design Week 4 Old Dominion University
HTTP Hypertext Transfer Protocol
Web Server Design Week 16 Old Dominion University
Web Server Design Week 12 Old Dominion University
Web Server Design Week 12 Old Dominion University
Web Server Design Week 14 Old Dominion University
Web Server Design Assignment #1: Basic Operations
Web Server Design Week 6 Old Dominion University
Web Server Design Assignment #5 Extra Credit
Web Server Design Week 3 Old Dominion University
Web Server Design Week 3 Old Dominion University
Web Server Design Week 7 Old Dominion University
Web Programming Week 1 Old Dominion University
Web Server Design Week 7 Old Dominion University
Presentation transcript:

Web Server Design Week 12 Old Dominion University Department of Computer Science CS 495/595 Spring 2012 Michael L. Nelson <mln@cs.odu.edu> 03/27/12

Problems with Basic Authentication Password sent in clear Cannot authenticate the server to the client e.g. “phishing” attacks uid/passwd may be used at other sites too

Digest Authentication Does: securely transmit the password bi-directional authentication But does not protect the session!!! “https” uses 1 of: Secure Socket Layer http://wp.netscape.com/eng/ssl3/ retroactively published as RFC 6101 Transport Layer Security http://www.ietf.org/html.charters/tls-charter.html RFC 5246

Replay Attacks Eavesdrop on the unencrypted c/s conversation With basic, the bad guy has access to all URIs protected with that u/p With digest: replay is limited to the resource the bad guy already overheard the vulnerability “window” is determined by the nonce value PUT/POST methods need stronger nonce values (e.g., one-time use) and/or qop=auth-int

Multiple Authentication Schemes According to section 14.47 of RFC 2616 (and section 4.6 of RFC 2617), a single “WWW-Authenticate” header can provide more than 1 challenge it is up to the client to choose the strongest challenge it understands (n.b., I’m not sure how to do this with Apache; we will not issue multiple challenges in our project) RFC 2616, sec. 14.47: … User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.

Dictionary Attacks Digest authentication offers no real protection against poorly chosen passwords grabbing the nonce/response pair(s), eavesdropper can quickly run through a dictionary of common passwords trying to recreate the response Dictionary = {root,$user,$user$user,reverse($user),Spock, Whorf,Gandalf,eagle,mustang,password, mypassword,123,asdf,fluffy,fido,…} Make dictionary attacks harder with salt. # user format = name:realm:md5(name:realm:password) mln:Colonial Place:53bbb5135e0f39c1eb54804a66a95f08 # user format = name:realm:md5(name:realm:password:salt):salt mln:Colonial Place:e65c90343b763abb9e442dd03ae79aac:12

Man in the Middle A corrupted proxy (or a “phishing” server) could request your credentials: basic: now it has your passwd (good for all URIs) digest: it has authentication for a single URI The very existence of “basic” is a problem passwords are often shared among domains, realms, auth methods client s/w & users have to be smart

Chosen Plaintext Attack MITM attacks (or phishing server) have control of generating the nonce values knowing the original input makes cryptoanalysis a little bit easier: http://web.archive.org/web/19970607055704/http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm “Cribs” http://www.cs.miami.edu/~harald/enigma/ http://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma client can counter w/ cnonce, since MITM will not know what the original input was for the cnonce value

Batch Bruce Force Attacks Variation on the plaintext attack: MITM/phisher collects multiple responses from multiple users for the same nonce Time to find first passwd decreases by the factor of the known nonce/response pairs

Precomputed Dictionary Attack Combination of dictionary + plaintext Compute a dictionary of (response,passwd) pairs for the known nonce value(s) Computation can be done in parallel on zombie machines

Password Files Even though the server (Apache) stores passwords in the form of: user:realm:md5(user:realm:passwd) if the passwd file is compromised (e.g., filesystem access), then the URIs in that realm are compromised password does not need to be guessed treat this passwd file as if the passwds are in the clear (unlike standard unix passwd file)

“Unsafe” Methods Safe methods: “read” operations; do not change the status of the server GET, HEAD, OPTIONS, TRACE n.b.: in practice, GET can have side effects: http://www.foo.com/a/b/c.php?var1=foo&var2=bar Unsafe methods: “write” operations; change the state of a resource PUT, POST, DELETE

Idempotent Methods Idempotent: get the same result if you do it over and over again Safe & Idempotent: GET (no side effects), HEAD, OPTIONS, TRACE Unsafe & Idempotent PUT, DELETE Unsafe & ~Idempotent POST, GET (w/ side effects) e.g. http://foo.edu/counter.cgi?action=increment&variable=x

PUT vs. POST PUT tells the server to use the uploaded entity to create a resource at the specified URI Unix semantic equivalent: echo “hello world” > /home/mln/hw.txt POST tells the server to submit the uploaded entity to the existing resource at the specified URI echo “hello world” | /usr/bin/spell

POST If the request does not result in a resource that can be identified with a URI, then the response codes should be: 200 OK an entity describing the result 204 No Content no description If the result does produce a URI identifiable resource, the result should be: 201 Created, and: “Location” header specifying the new URI

PUT If a new resource is created: If an existing resource is modified: response code is returned If an existing resource is modified: 200 OK if there is an entity describing the results 204 No Content if there is no entity describing the results

DELETE If the URI is successfully deleted, then valid response codes are: 200 OK if there is an entity describing the results 204 No Content if there is an not entity describing the results 202 Accepted the request was understood, queued and might be successful in the future. an entity is returned with this response, but there is no provision for the server to relay the eventual success or failure of the original request

Failure Response Codes 403 Forbidden Server understood the request, but will not honor it. Authentication will not help; do not repeat. 405 Method Not Allowed method/URI combination not valid cf. "501 Not Implemented"! 411 Length Required “Content-Length” header is missing on client upload 413 Request Entity Too Large configurable server value; prevent DOS attacks note the “Content-Length” header may lie! 414 Request-URI Too Long

Reality… PUT, DELETE are rarely (never?) implemented as specified in the RFC security considerations, limited client support, incomplete semantics PUT sometimes implemented by redirecting to a CGI script: http://httpd.apache.org/docs/2.0/mod/mod_actions.html Web Distributed Authoring and Versioning (WebDAV) is the preferred implementation for “write” operations http://www.webdav.org/ We will do neither approach; we’ll implement native support for unsafe methods

Allowing PUT/DELETE Recursively allow PUT / DELETE in a directory via these directives in WeMustProtectThisHouse! file: ALLOW-PUT ALLOW-DELETE Orthogonal to the uid/passwd info: # ALLOW-PUT ALLOW-DELETE authorization-type=Basic realm="Fried Twice" bda:9177d249338e2b2394f65faa17a46a29 jbollen:6c4bea736ded1341eb8c507d4b0baa5b mln:ae33d20c70e59a4c734d9f2c19c0df56 vaona:81e5a6b538844ed0c494149a96310a85

PUT Example PUT /~mln/fairlane.txt HTTP/1.1 Host: www.cs.odu.edu Connection: close User-Agent: CS 595-s07 Automatic Testing Program Content-type: text/plain Content-length: 193 ______________ // \\ ---------//--------------\\------- | __ __ | |--/ \--------------------/ \---| \__/ \__/

DELETE Example DELETE /~mln/fairlane.txt HTTP/1.1 Host: www.cs.odu.edu Connection: close User-Agent: CS 595-s07 Automatic Testing Program

Reminder: OPTIONS Be sure to give the correct values for the OPTIONS method PUT, DELETE depend on the values in “WeMustProtectThisHouse!” POSTing to URI that is not an executable file? Apache seems to allow it… but not to directories We will not (status 405) % telnet www.cs.odu.edu 80 Trying 128.82.4.2... Connected to xenon.cs.odu.edu. Escape character is '^]'. POST /~mln/index.html HTTP/1.1 Connection: close Host: www.cs.odu.edu HTTP/1.1 200 OK Date: Mon, 17 Apr 2006 14:54:07 GMT Server: Apache X-Powered-By: PHP/4.4.2 Content-Length: 5357 Content-Type: text/html <html> <head> <title>Home Page for Michael L. Nelson</title> [deletia] % telnet www.cs.odu.edu 80 Trying 128.82.4.2... Connected to xenon.cs.odu.edu. Escape character is '^]'. POST /~mln/pubs/ HTTP/1.1 Host: www.cs.odu.edu Connection: close HTTP/1.1 404 Not Found Date: Mon, 17 Apr 2006 23:50:59 GMT Server: Apache Content-Length: 272 Content-Type: text/html; charset=iso-8859-1 [deletia]

POST Typically the result of HTML “Forms” http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4 Two types of values in the client’s “Content-type” request header: application/x-www-form-urlencoded   (original & default) multipart/form-data introduced in RFC-1867; allows file upload http://www.ietf.org/rfc/rfc1867.txt

HTML Examples <FORM action="http://server.com/cgi/handle" enctype= "application/x-www-form-urlencoded" method="post"> <P> What is your name? <INPUT type="text" name="submit-name"><BR> <INPUT type="submit" value="Send"> <INPUT type="reset"> </FORM> <FORM action="http://server.com/cgi/handle" enctype="multipart/form-data" method="post"> <P> What is your name? <INPUT type="text" name="submit-name"><BR> What files are you sending? <INPUT type="file" name="files"> <BR> <INPUT type="submit" value="Send"> <INPUT type="reset"> </FORM> based on examples from: http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4

application/x-www-form-urlencoded POST /~mln/foo.cgi HTTP/1.1 Host: www.cs.odu.edu Connection: close Referer: http://www.cs.odu.edu/~mln/bar.html User-Agent: CS 595-s06 Automatic Testing Program Content-type: application/x-www-form-urlencoded Content-Length: 134 action=restore&manufacturer=ford&model=fairlane+500XL &year=1966&status=modified&engine=427+sideoiler &transmission=4+speed+toploader functionally the same as (modulo a possible 414 response): GET /~mln/foo.cgi?action=restore&manufacturer=ford&model=fairlane+500XL &year=1966&status=modified&engine=427+sideoiler&transmission=4+speed+toploader HTTP/1.1 Host: www.cs.odu.edu Connection: close Referer: http://www.cs.odu.edu/~mln/bar.html User-Agent: CS 595-s06 Automatic Testing Program

multipart/form-data (with file upload) POST /~mln/foo.cgi HTTP/1.1 Host: www.cs.odu.edu Connection: close Referer: http://www.cs.odu.edu/~mln/bar.html User-Agent: CS 595-s06 Automatic Testing Program Content-type: multipart/form-data; boundary=----------0xKhTmLbOuNdArY Content-Length: 698 ------------0xKhTmLbOuNdArY Content-Disposition: form-data; name=”action" restore Content-Disposition: form-data; name=”manufacturer" ford Content-Disposition: form-data; name=”model" fairlane 500xl Content-Disposition: form-data; name=”year" 1966 Content-Disposition: form-data; name=”picture"; filename="fairlane.txt" Content-Type: text/plain ______________ // \\ ---------//--------------\\------- | __ __ | |--/ \--------------------/ \---| \__/ \__/ ------------0xKhTmLbOuNdArY-- multipart/form-data (with file upload) note the “--” to indicate the end