CS Security Comps Deliverables, Fall 2024

[I have shown required actions in red below to help you keep track.]

The final delivery of your project will consist of a compressed archive, which you will deliver to Mike Tie and me as either a .zip file or a .tar.gz file. Name your file after your group members. For example, if Layla and I were project partners, we would name our delivery file loesper-jondich.tar.gz.

The due date is 9:00PM Monday, November 25.

Your file should contain the following elements.

A tiny static website

This will act as the homepage for your project, from which a reader can access all the elements of your project. To see a few recent examples, check out the "Final Results" links at the top of this 2023-2024 project. You'll see the wide range of "tiny website" types, including one that doesn't even use CSS. It's up to you how fancy you want to get.

Name the home page (which may also be the only page) index.html.

Keep it simple. A couple sentences describing the project, possibly lifted verbatim from your project explanation (see below). Who you are. Links to resources you created (source code, documentation, project explanation, demo video) which may be externally hosted or included as static files in your tiny website. References.

The overall goal is to enable Mike decompress your stuff into a folder on the cs.carleton.edu website, link to your index.html from the corresponding comps project description, and from there, a person could get to all your project's stuff. You can test this by copying your .zip or .tar.gz archive to a temp folder, uncompressing it there, and double-clicking on the index.html file. If you can get to all the project materials from that page in your browser, you're good to go.

Source code

This should typically be in the form of a link from the index.html file to a publicly available git repository (GitHub or BitBucket or whatever). There are other alternatives, but this is certainly the easiest approach.

Source documentation

This is probably best delivered as a link to the usual README.md that is generated when you create a GitHub/BitBucket/... repo. Your readme should include:

Project explanation

This explanation should be in the style of an explainer-blog or explainer-video. You may pitch your exposition to an audience consisting of your CS major peers, or thereabouts. They'll know what an IP address is, and maybe even what TCP is for, but you can't count on them having taken our Security or Networks courses.

You may include this explainer in your project as static files (e.g., pdf or html or mp4) or as links to public web resources (e.g., youtube, medium.com).

Your explainer should enable a reader/viewer to get started studying your topic with a good initial background in the relevant concepts. You should certainly include information about what your software does and how to run it. But you should also include explanations of how the software works.

For example, two of our teams use ARP cache poisoning to achieve AITM status. Their explainers should certainly describe the command-line commands or python function calls or whatever they use to actually do the poisoning of the target's ARP cache. But they will also need to provide short introductions to the purpose and functioning of ARP itself so their readers/viewers will be able to understand the sequence of events that leads to the victim's network packets getting routed to the attacker.

Another example. If your project is a password sprayer and one of your attacks involves HTTP Basic Authentication systems, you'll need to provide an introduction to the mechanisms of Basic Auth (i.e., original GET request, 401 Authorization Required status + WWW-Authenticate header, new GET request with Authorization header, and 200 OK or 403 Not Authorized response). And similarly for other authentication types, captcha analysis, or whatever other core concepts your tool depends on.

If you want help calibrating your exposition for the intended audience (and for my expectations), I'm happy to talk about it any time.

Video demo

This should be a very simple video--just show a walkthrough of typical uses of your tools. I'm expecting most of you can pull this off in a video of under 5 minutes, even if you spend a little time pointing out some nuances of the results.

This is a good opportunity to show off your successes, so make it a little fun if you can.

If your project explainer (see above) is in video form, you may include your demo in that video. If you do that, it would be great if you could provide a link to the start-time of the demo on your website's list of links.

One more thing: an end-of-comps survey

In addition to the above, please fill out this survey. Thank you.

Questions?

You know where to find me. Have fun!