Description

Overview In project 3, you will implement an HTTP server that serves secret user data. Access to this secret data will be authenticated through one of two mechanisms: (i) user name and password, and (ii) cookies presented from successful prior authentication. We will use the HTTP protocol and build simple versions of these authentication mechanisms to render browser-readable data. You will only work with one program in this project, server.py. Step 1: Let’s take it for a spin! The project archive comes with starter code for server.py. This file already implements an HTTP server which serves a login page. Start the server program by either typing python server.py which spins up the server on port 8080 (default), or you can type a port number of your choice: python server.py 45006 The best part about the HTTP protocol is that you can interact with the other endpoint using your browser. Spin up the local browser and type http://localhost:45006 (substitute 45006 by the port number you used when you started the server, which may be the default value 8080.) You may see something that looks like this: You can also interact with the server using a command line client like curl. You could type the command curl http://localhost:45006/ to perform a transaction through the command line. You will see the HTML content of the page printed on the terminal. You can get curl to print more information using the -v flag. Here is an example of what you may see when you invoke curl -v http://localhost:45006/ * Trying ::1… * TCP_NODELAY set * Connection failed * connect to ::1 port 45006 failed: Connection refused * Trying 127.0.0.1… * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 45006 (#0) > GET / HTTP/1.1 > Host: localhost:45006 > User-Agent: curl/7.54.0 > Accept: */* > 2 < HTTP/1.1 200 OK < Content-Type: text/html * no chunk, no close, no size. Assume close to signal end <

Please login

* Closing connection 0 You can ignore the error message at the beginning from the IPv6 connection attempt. If you go back to the terminal running the server program, it should have printed some helpful messages regarding the request it received and the responses it sent out. Example: Here is the headers “”” GET / HTTP/1.1 Host: localhost:45006 User-Agent: curl/7.54.0 Accept: */* “”” Here is the entity body “”” “”” Here is the response “”” HTTP/1.1 200 OK Content-Type: text/html

Please login

“”” Served one request/connection! 3 Step 2: Study server.py carefully In many ways, server.py is not that different from any of the TCP servers you implemented in project 1 or project 2. The key difference is that it receives HTTP protocol request messages and responds with HTTP protocol response messages. It will be worthwhile understanding how server.py unpacks the data in the HTTP request to extract the headers and the entity body of the request. You will build on this code to extract specific headers and information from the entity body. The server.py code also contains various strings that are helpful to return as entity bodies of the HTTP responses, such as login page, bad creds page, and so on. Pay specific attention to the places marked TODO:; these are the locations you will insert the main application logic for this project. Step 3: Building the databases The server should read all of the username and passwords stored in the file passwords.txt (in plain text) provided along with this project archive. This file will contain multiple lines, one per user of the system, with their username and password (always one word) in that order, separated by a space. For example, in the sample passwords provided, one of the users of the system is named bezos with the password amazon. Your program should read in all this user data and maintain a data structure for lookup when the user attempts to authenticate. The server should also read in the corresponding user secrets stored in plain text in the file secrets.txt, provided along with the project archive. This file will contain multiple lines, one per user of the system, with their username and secret data (always one word) in that order, separated by a space. For example, in the sample secrets provided, one of the users of the system is named bezos with the secret word kaching. Your program should read in all this user data and maintain a data structure to lookup for displaying after successful authentication. Step 4: Implementing username-password authentication The browser login form on http://localhost:45006/ is set up to send POST requests when these details are typed into the respective fields. (Beware, the file is stored in plaintext, and any information you type in the form is sent in plain text, so please do not put any sensitive information in these!) You can also send POST data from the command line using the curl tool. If you type the command curl -d “username=bezos&password=amazon” http://127.0.0.1:45006/ it has the same effect as form data posted from a browser window. The server.py terminal output should show Here is the entity body “”” 4 username=bezos&password=amazon “”” in place of the (empty) entity body from before. Specifically, the command flag -d makes curl send a POST request with the data inserted into the entity body of the HTTP request. Parse the entity body obtained by server.py to recover the username and password fields of the HTTP POST request. Compare these details with the information you read from passwords.txt in the previous step. Not all valid HTTP requests may contain these two fields in their entity body, so you must pay careful attention to handling different kinds of requests in your code. Case A: Username-password auth success. If the username and password fields do exist in the entity body, and they match with the username and password of a user in the passwords file, you can return the success page to this user with the corresponding secret information that you read in the previous step. An example of this output on the browser looks like this, after bezos successfully authenticates: To accomplish this in the code, you merely need to set the variable html content to send to success page + secret, where secret is the secret word of the corresponding user who just logged in. Case B: Username-password auth failure. If exactly one among the username or password fields is absent in the entity body (i.e., exactly one field is present), or if both fields are present but the username is not in the passwords file, or the password did not match the corresponding username in the passwords file, then we ask the user to log in again. This is accomplished by setting html content to send to bad creds page. You may see output like this: You should be able to see HTML source code corresponding to these pages using appropriate curl commands as well, in case you want to test your program quickly on the terminal. 5 Step 5: Generate, send, and store a cookie Now we get to the part where the server “remembers” prior successful authentications using cookies. Recall that cookies are a collaborative mechanism between the client and the server. The server assigns an opaque identifier to a successfully authenticated user, and sends it back in a Set-Cookie header in the HTTP response. Step 5.1 In case A in the previous step (successful username-password authentication), generate a cookie value which is a random 64-bit value. You can accomplish this by invoking random.getrandbits(64) in your code. Capture this header-value pair in a string that contains the entire HTTP header line. If you assign headers to send to this string, it will be sent to the client along with the rest of the message. An example of doing this is: rand_val = random.getrandbits(64) headers_to_send = ’Set-Cookie: token=’ + str(rand_val) + ’\r\n’ (The token= is helpful to have curl record and reuse (present) cookies, as we will see later.) An example output of the full HTTP response in this case from the terminal output of server.py looks like this: Here is the response “”” HTTP/1.1 200 OK Set-Cookie: token=24014456 Content-Type: text/html

Welcome!

Your secret data is here:

kaching “”” Step 5.2 Store the cookie rand val that you sent in step 5.2 into another data structure that can look up the cookie to obtain the corresponding pre-authenticated user name, if any. Storing and replaying cookies using curl. The curl tool allows recording and presenting cookies through its “cookie-jar” flags, -c and -b. Type the command curl -d “username=bezos&password=amazon” \ -c cookies.txt -b cookies.txt http://127.0.0.1:45006/ 6 and see the cookie token stored in the file cookies.txt. Subsequent browser requests should contain the cookie. If you open a new browser tab, pointing it to http://localhost:45006/, you must be able to see the Cookie: header printed in the request headers printed on server.py’s output in the terminal! Step 6: Implement cookie-based authentication Finally, we are ready to implement cookie-based authentication for users accessing our server. Browsers, and in general any HTTP clients implementing cookies correctly (including curl with cookie jar), are expected to present any cookies provided by a server in subsequent HTTP requests to that server. Your task now is to validate these cookies on the server side. From the HTTP request headers, extract the Cookie: header, and check if it corresponds to any user whose cookie you already recorded in step 5.2. Case C. Cookie validated. If there is a Cookie header in the request, and the cookie is one of the pre-recorded cookies, this corresponds (with high likelihood) to a successfully authenticated user. (In this project, we will not consider “attacks” where cookies are stolen from a user and presented on their behalf, or where a malicious client checks all possible cookie values by brute force.) In this case, the output is similar to that of case A in step 4: welcome the user and show their secret content. Case D. Cookie invalid. If there is a Cookie header in the request, and the cookie’s value isn’t one of the pre-recorded ones, you must present an error to the user similar to case B from step 4. Case E. No cookie header. If there is no Cookie header in the request, you must process the request as if you’re doing Step 4. Summary of application logic. After completing this step, the flow of application logic should look like: 1. (case C) cookie header present and valid. Show the user the secret page: send back success page with the secret. 2. (case D) cookie header present but invalid cookie: send back bad creds page 3. (case A from step 4) cookie header absent, username-password present in entity body, userpass combination successfully matches correct credentials from passwords file: send back success page with the secret, don’t forget to set a new cookie! 4. (case B from step 4) cookie header absent, either one of username/password fields missing or username-password both present in entity body, but user-pass combination does not match any correct credential from the passwords file: send back bad creds page 5. (basic case, already implemented in the starter code from step 1) cookie header absent, username-password absent in entity body. Send back login page 7 Step 7: Implement logout function Your browser will keep presenting the same cookie indefinitely if cookies aren’t cleared or don’t have an expiry date. The cookie we sent back in step 5 does not have an expiry date. Hence, a user, once logged in, must manually clear cookies each time they want to log out and avoid secret data being served by server.py. (Cookies can usually be cleared on a per-domain basis through the browser’s cookie settings.) In this step, you will send back a cookie header from the server that explicitly corresponds to clearing the cookie from the client. This is accomplished by setting an expiry date for the cookie that is in the past. For example, if you set headers to send to the string Set-Cookie: token=; expires=Thu, 01 Jan 1970 00:00:00 GMT\r\n it instructs the browser (HTTP client) to clear its cookie named token for the server’s domain, since the cookie is past its expiry date. If your server sends this header in the response, you can check on your browser’s cookie list as well as curl’s cookie jar file (cookies.txt in the examples above) that the cookie has disappeared. (I have sometimes observed that cookies.txt itself disappears if there are no other cookies stored in it.) Case F. Logout. Helpfully, the welcome HTML page that appears when a user is successfully authenticated contains a logout action button, that POSTs a hidden object called action with value logout to the server when the button is clicked. To implement a log-out function (clearing cookies in the process), all you need to do on the server side is to detect action=logout in the POST entity body, and send an expired cookie to the client when that happens. Further, send the HTML content corresponding to logout page back to the user indicating they have logged out. After implementing this step, the flow of application logic is enhanced by implementing step 7 at the beginning of the overall logic flow described in the summary at the end of step 6. That is, the full order of actions is 1. case F (step 7) 2. case C (step 6) 3. case D (step 6) 4. case A (step 4) 5. case B (step 4) 6. basic case (already implemented in step 1) What you must submit and how we will test it For your project submission on Canvas, please turn in server.py and your project report report.pdf. The command line of the program must be exactly the same as it was given to you (same as in step 1). The questions for the report are listed below. We will be running your code on the ilab machines with the default Python 2 version on those machines. Please compress the files into a single Zip archive before uploading to Canvas. Only one team member must submit. 8 Testing your program We will test your program at least with the following cases and more. We may run the client on the same or a different machine from the one running your server.py. You may use this as a guide to check that your program implements all the required functionality correctly (we also mention the desired end result in parentheses). In all tests, all input files will be well formed, and we will only send well-formed HTTP packets crafted through a browser or curl. You should be able to craft requests corresponding to these cases through either your browser, or more likely, curl. 1. basic: no username or password posted, no cookies (login) 2. correct username and password posted, no cookies (success) 3. non-existent username posted with password, no cookies (bad credentials) 4. existing username posted with bad password, no cookies (bad credentials) 5. exactly one of username or password posted, other field missing, no cookies (bad credentials) 6. no username or password posted, valid cookie (success) 7. non-existent username or bad password for existing username, valid cookie (success) 8. correct username and password, valid cookie (success) 9. correct username and password, invalid cookie (bad credentials) 10. logout posted, valid cookie (logout) 11. logout posted, invalid cookie (logout) Project report Please answer the following questions for the project report. 1. Team details: Clearly state the names and netids of your team members (there are 2 of you). 2. Collaboration: Who did you collaborate with on this project? What resources and references did you consult? Please also specify on what aspect of the project you collaborated or consulted. 3. Is there any portion of your code that does not work as required in the description above? Please explain. 4. Did you encounter any difficulties? If so, explain. 5. Describe two observations or facts you learned about HTTP and cookies in the process of working on this project. Please be specific and technical in your response. Contact the course staff on Piazza if you have any questions. 9