Assignments and Labs

Lab - Building a secure website

• Step 1. Protected path and see the passwords. (1~5 by 1/26, all by 1/27)
  1. Get a virtual machine. VMWare is available here for free. If you have Windows, you can use Windows Virtual PC. Make sure that your VM is set up to use Shared Network (NAT).
  2. Install a guest OS. Windows 10 is available here for free. (If the link doesn't work, go to ITS eStore and search for Microsoft.)
  3. Download and install WireShark in the guest OS.
  4. Install your favorite web browser in the guest OS.
  5. Download and install a web server in the host OS. You may use MAMP. Alternatively, if you wish to use a web-hosting service from a third party, make sure that you have PHP and MySQL support.
  6. Use htaccess to protect a directory with a password. Hint.
  7. Access the protected directory in the host OS from the web browser in the guest OS, while capturing packets in the guest OS using WireShark. Use Wireshark to see your passwords. A good reference book is available on Safari, Packet Analysis with Wireshark by Anish Nath.
  8. Save and submit the pcap files from the capture above in Canvas.
  
  
• Step 2. Cookies (by 2/3)
  1. Implement a login page that uses username/password. Do not use htaccess, and do not store the plaintext of the password on the server. Any passwords should be hashed before being stored. You don't have to use a database to store passwords. You may use salt, but it is not required. Set a permanent cookie once login is sucessful, i.e. the cookie does not expire. Implement a private page that requires this cookie, i.e. a page that only logged-in users can see. You may use PHP or javascript to set the cookie. (The university offers free training on Apache+PHP+MySQL at Lynda.com. Login to USF Connect, click on Learning Technologies, and then click on Lynda.com. You can search for Apache.)
  2. From the client web browser, visit your login page, and capture the packets to show how the username, password, and cookie is exchanged between the website to the browser. Close your web browser, visit the private page that requires cookie again, and capture the packets to show how the cookie is sent from your browser to the website. Clear the cookie in the web browser, and then visit the private page again, while capturing the packets. Your website should deny access to this page. Submit the source code of your login and private pages with the pcap file and README that explains how you implemented login and private pages.
  3. Read the article Logging out of facebook is not enough. Create a Facebook account if you don't have one. Start packet capture. Login, logout, and visit 3rd-party websites (non-Facebook websites) with Like button such as this. Submit the pcap file and show which packets send the Facebook cookies to Facebook when your browser visits the 3rd-party websites and README that explains what you can learn from these Facebook Cookies about your account.
  4. Add SSL to your website to support https for username/password login. Do not use htaccess, but implement a login page. Use Wireshark to verify that the passwords are not visible. You may use Apache-SSL. Submit the source code of your login page if it has changed and a README. The README should explain how you added SSL, and also whether the cookie is visible or not.
  
  
• Step 3. Replay attack (by 2/10)

  Sniff the packets from a web browser to your server using 1)http and (optional) 2)https while a legitimate user logs in to your website. Write a program that takes the packet capture file (txt format is fine), the URL of your website, and launches a replay attack on your website to access the restricted content as the legitimate user. Make sure that your web server responds with the restricted content only when the cookie is valid. In other words, this replayed cookie is an authentication cookie. Does the capture file from 1) works? (Optional) How about from 2)? Explain your answer in the README. You will need to do some socket programming to make your program act like a web browser.

  Submit your source code of the website, README, the user-side program, and a sample packet capture file by 2/10 in Canvas. Grading will be done by demo.

• Step 4. ZBoxlive.com comes live (due 2/27)

  You will implement a server (website) and a client in this step. Let's call your server ZBoxlive.com. When a user sets up an account, ZBoxlive.com provides a unique public and private key pair. You may assume that the account setup is already done, so your client knows the private key and the server knows the username, the hash value of the password, and the corresponding public key.

  When the user wants to log into ZBoxlive.com, he or she types in username and password to the client program. The client program sends (username, password hashed and encrypted with his private key) to the server, i.e. (username, Ru < H(password) >), where Ru is the private key of the user, H is a secure hash function and H(password) is a hash value of the password. Based on the username, the server pulls the public key for that user from its database and decrypts the second part using this public key. The descrypted hash value is compared with the hash value stored in the database. If the two values match, access is granted. Assume that ZBoxlive.com does not share the public key of a user with other users.

  1. ZBoxlive.com is vulnerable to replay attack. Explain the details of the replay attack in README.
  2. Modify your website to prevent replay attack. Hint: every login message should be fresh

  Submit your source code of the website and the client program by 3/1 in Canvas. Grading will be done by demo, along with the Step 5 demo. Demo of both steps will take about 30 minutes, and should be done by 3/27. A demo sign-up will be circulated in Canvas on 3/21. Failure to schedule a demo is not an excuse for extension.

• Step 5. Secure website for multiple users (by 3/22)

  Design and implement a server (website) for multiple users in this step. You may design the login protocol and the cookie content in any way you wish, as long as your website satisfies the following requirements. You may not use https.

  • A new user can create an account.
  • Once a user logs in successfully, show a private webpage that has personalized content for this user.
  • The user needs to login once, and then can browse private pages repeatedly without providing login credentials.
  • Once the user logs out or closes a web browser, the user cannot revisit the private pages without providing login credentials.
  • A passive attacker, who can sniff the packets in the same subnetwork as the user is in, cannot impersonate the user to the server. (If the attacker can access the private page for the user using replay attack, we conclude that the attacker impersonated the user successfully.)

  Submit the source code of this website, including any database if you are using one, and README to Canvas by 3/22. Grading will be done by demo, along with Step 4 demo. Demo of both steps will take about 30 minutes, and should be done by 3/27. Sign-up link will be available in Canvas on 3/21.

• Step 6. Man-in-the-middle attack (by 3/27)

  Implement the man-in-the-middle attack on slide 3 of SSL lecture. You will need to implement Alice, Bob, Charlie separately, demonstrate how Alice and Bob work in a normal situation, and also demonstrate how Charlie can sit between Alice and Bob to authenticate himself as Alice to Bob. Note that Bob needs to be a website, but you may implement Alice and Charlie as a stand-alone program. You may use a 3rd-party RSA library, e.g. PHPseclib.

  Submit the source codes of Alice, Bob, Charlie, and README to Canvas by 3/27. Grading will be done by demo, along with the Step 7 demo. Demo of both steps will take about 30 minutes, and should be done by 11/5. Sign-up link will be available in Canvas on 10/22.

• Step 7. SQL injection prevention (by 4/17)

  Add a database (e.g. MySQL) as the backend to your website that stores username and password. Build a login website so that you can demonstrate an SQL injection attack that will show all the usernames and passwords. (Hint: your website can login to the database as the admin to read username and password for the user.) This login website should act normally, e.g. this website should not be displaying the username and password in clear in a normal login process even for an admin account. Implement another version of the login website that prevents the attack you showed. (Hint: input sanitization)

  Submit the source codes of two websites and a README to Canvas by 4/17. Grading will be done by demo, along with optional revised Steps 4 and 5. Demo of both steps will take about 30 minutes, and should be done by 5/1. Sign-up link will be available in Canvas on 4/18.

  
  
• Step 8. Intrusion Detection (by 4/24)

  Install suricata on your computer and analyze three pcap files in step8.zip in Canvas.

  For each pcap file, explain what intrusions are detected, and how they are detected. For example, when there is a traffic from a well-known spam host, then suricata finds out that this is a spam host by comparing the IP address to a blacklist, e.g. spamhaus blacklist. Submit your report to Canvas by 4/24. No demo necessary.