Set up your app to listen for HTTPS requests on port 443 using a self-signed certificate and nginx running in a separate docker container. All features from the previous learning objectives must still be functional (With some reasonable exceptions. For example, it's ok if guest chat isn't working now that you have authenticated chat). You must include the following:
When this objective is complete, you should be able to run your app using docker and navigate to https://localhost to use your app. Since you are now using default ports, you don't have to specify the port. You should also be able to visit http://localhost and see a redirect to https://localhost. When visiting your app for the first time, you should expect the browser to give you a warning about using a self-signed certificate.
You will need to generate a private key and a self-signed certificate to enable HTTPS. For this objective, you may use an additional script to accomplish this. You should name this script "setup.sh" and save it in the root directory of your project. If this file exists, we will run it before starting your app while grading. The intent is for this script to generate your encryption keys, though you have the freedom to do whatever setup you'd like in this script. You may also choose to not include a script and set up your keys in your Dockerfile if you prefer. You may assume this script will be executed in a *nix environment with openssl installed.
When we test your app we will:
Security: Do not include any private encryption keys in your submission.
Security: Your auth token must use the secure directive.
For this objective, you will both launch a DoS slow send attack and protect against such an attack.
Attack: In the root directory of your project, write a python script named "dos.py" that will launch your slow send attack. Your attack must meet the following criteria:
Countermeasure: Protect against this attack. Any method of prevention is acceptable, though the intended approach is to add a timeout to your buffering code. When you detect that your app has been buffering for a while, close the connection. Your countermeasure must meet the following criteria:
Create a separate authentication (auth) server that will issue JWTs when a user logs in. This auth server must run in a 4th container using docker compose. This server will handle all registration and login requests for your app. When a user connects to an endpoint of your app that requires authentication, it will use the self-contained JWT to verify the user. You have some freedom in your design as long as your app meets the following criteria:
You will have to solve the problem of generating a public/private key pair, storing the private key only on the auth server, and sharing the public key with your app server. There are several ways to solve this problem with the intended approach being to add to your setup.sh script and handle it there. Note that you call a Python script from setup.sh if you prefer to do this in Python. Alternatively, you may generate these keys in your auth server and provide an endpoint for your app to ask the auth server for the public key. This is the only direct communication allowed between the two servers.
You are allowed to use libraries to sign and verify JWTs.
Security: Do not include any private encryption keys in your submission.
Security: Your JWT's must use the secure and httpOnly directives set.
Security: Your JWT's must be cryptographically signed in a way that they cannot be forged.
Security: Any private key(s) must only be known to you auth server. Not even your app server should have access to this key.
Submit all files for your server to Autolab in a .zip file
If you used any external libraries, be sure to add them to your requirements.txt. Autolab will install all dependencies in this file, and no other dependencies, before starting your server.
Each objective will be scored on a 0-3 scale as follows:
| 3 (Complete) | Clearly correct |
| 2 (Complete) | Mostly correct, but with some minor issues |
| 1 (Incomplete) | Not all features outlined in this document are functional, but an honest attempt was made to complete the objective |
| 0.3 (Incomplete) | The objective would earn a 3, but a security risk was found while testing |
| 0.2 (Incomplete) | The objective would earn a 2, but a security risk was found while testing |
| 0.1 (Incomplete) | The objective would earn a 1, but a security risk was found while testing |
| 0 (Incomplete) | No attempt to complete the objective or violation of the assignment (Ex. Using an HTTP library) |
Note that for your final grade there is no difference between a 2 and 3, or a 0 and a 1. The numeric score is meant to give you more feedback on your work.
| 3 | Objective Complete |
| 2 | Objective Complete |
| 1 | Objective Not Complete |
| 0 | Objective Not Complete |
Autograded objectives are graded on a pass/fail basis with grades of 3.0 or 0.0.
For each objective for which you earned a 0.3 or 0.2, you will still have an opportunity to earn credit for the objective by submitting an essay about the security issue you exposed. These essays must:
Any submission that does not meet all these criteria will be rejected and your objective will remain incomplete.
Due Date: Security essays are due 1-week after grades are released.
Any essay may be subject to an interview with the course staff to verify that you understand the importance of the security issue that you exposed. If an interview is required, you will be contacted by the course staff for scheduling. Decisions of whether or not an interview is required will be made at the discretion of the course staff.
When you don't have to write an essay: