Final exam, Part 1

Due 11:59PM Wednesday, 19 November 2025
Hand in as final1.pdf via Moodle

This is an open-notes, open-Internet, open-book exam. You may post questions about the exam on #general on our Slack workspace, but otherwise you may not discuss the exam with anybody other than Jeff Ondich.

Throughout, try to explain what you have done as clearly as possible. Screenshots and copied commands are often very helpful in clarifying your actions and reasoning, so don't hesitate to include them.

Note that Part 2 of the final will be due 5:00PM Monday, 24 November 2025.

Here is the policy for LLM use on this exam. You are responsible for reading and abiding by this policy.

1. Session Cookies Working as Intended (12 points)

We spent a lot of time this term trying to understand various client/server/attacker interactions by understanding what messages were sent when, what data was stored where, what was encrypted and how, etc.

You can apply this protocol-and-attack-oriented perspective to understand the process of logging into (and staying logged into) web accounts like Amazon or Facebook or gmail. This and the next problem will encourage you to explore how web logins work.

Do the following experiments, and then answer the questions below.

Go back to our old friend, the Fake Discussion Forum (FDF).
If you're logged in as somebody (it will tell you so at the very top of the page), Logout.
Open your browser's inspector and look at the cookies.
Login as Alice (email=alice@example.com, password=alice).
Look at the cookies again.
Open a different browser (or an incognito window in the same browser) and go to FDF.
Copy Alice's cookies from the old browser window to the new browser window. (How exactly to do this may vary by browser.)
Reload the page in your new browser.

Here are the questions.

[1] What new cookie did you see when you logged in as Alice?
[2] What is a session cookie?
[1] What happens when you copy Alice's cookies to the new browser window and reload?
[6] Draw a diagram and/or list of events that explains clearly how you normally go from not logged-in to logged-in, and also how you stay logged-in when you navigate to other pages on the same site. (When I say "normally", I mean "when you click the Login button and fill out and submit the login form".) Make sure you include the actions of the user, browser, and server.

Your diagram should, among other things, address the question of how the server knows that a given session cookie corresponds to a given user.
[2] Think like an attacker: what opportunities do session cookies open to you?

2. Stealing Session Cookies (12 points)

Do the following experiments, and then answer the questions below. Note that for these experiments, you're simulating an attack, where your host OS will act as the victim (Alice) and your Kali VM will act as the attacker (Eve). Keep in mind that Eve cannot look at the stuff on Alice's computer, and Eve also does not know Alice's FDF password. Eve can only see what she can see inside Kali.

Using a browser on Kali, go to the Fake Discussion Forum (FDF), logout, and login as Eve (email=eve@example.com, password=eve).
Figure out your Kali's IP address.
Look at the post entitled "[JO] Malicious Code for Final". Copy that post's Javascript payload into a new post of your own, but replace "KALI_IP" with your Kali IP address, replace "KALI_PORT" with whatever port necessary to achieve the goals below, and entitle your post "[YOUR-USER-NAME] Final Problem 2". (If you need to do this more than once, just change the title to use 2.1, 2.2, etc. as needed)
Do some kind of suitable setup on Eve's machine (Kali) to receive information from the malicious Javascript in your FDF post.
On your host OS, open a new browser, go to FDF, and login as Alice. IMPORTANT: Use Firefox or Safari for this. Chrome by default has some protections enabled that Firefox and Safari do not.
Click on Eve's "[YOUR-USER-NAME] Final Problem 2" post.
Go back to Kali. As Eve, if the above steps have gone correctly, you should now have access to enough information to login to FDF as Alice.

Here are the questions.

[2] Show an exact copy of your FDF post as Eve (specifically, the post that worked for you). Give a brief explanation of what the Javascript in your FDF post does.
[1] What did you do on Eve's machine (Kali) to prepare to receive Alice's information?
[1] Show the form (as text or a screenshot) in which Alice's information arrived on Kali.
[1] What can Eve do now to login to FDF as Alice?
[4] Diagram clearly the sequence of events in Eve's attack on Alice via the FDF.
[3] Session cookies have a standard mechanism (which I have disabled on FDF) for preventing this kind of attack. Research and explain "HttpOnly". Show exactly where in your diagram of the attack that the use of HttpOnly would prevent Eve's attack from working.

3. Entertaining Jeff (2 points)

What should I read, watch, listen to, or try out to amuse myself during winter break? (If somebody asks nicely in class, I'll provide some of my own suggestions.)

4. Don't write your own cryptography (9 points)

All term, we have used RSA with public key (n,e) and private key (n,d). And we have also used generic functional notation like E(S_B, H(M)) to represent the notion of a digital signature (i.e., Bob alone has access to the private key S_B, so E(S_B, H(M)) constitutes a form of digital signature that only Bob could have generated). That's all well and good, and has given you a way of thinking about the roles of asymmetric cryptography and digital signatures in modern security. Our E, H, and their friends have given us a kind of proof-of-concept for the notions of asymmetric crypto and digital signatures.

But it turns out that vanilla RSA and the simplistic digital signature that you can generate with it have mathematical vulnerabilities that make them unsuitable for practical cryptography without modification. Furthermore, if you try to write your own cryptographic primitives, you are almost guaranteed to make mistakes that will undermine your users' security. (If you're interested, listen starting around 38:00 of this podcast for an example from last year of a company that made the mistake of implementing their own cryptographic code without enough expertise.)

So instead of a "solve this digital signature puzzle", I want you to do an exercise with a different couple of messages.

First, cryptography is really hard to get right, and if you're writing software with cryptographic requirements, you should use libraries that have been developed and tested by experts.

And second, there's a big literature of mathematical attacks on every kind of cryptographic primitive. If you're interested in cryptography, you should seek out this literature.

So, with that preamble complete, here are a few questions for you.

[2] Do a little research on the term textbook RSA, and give me two reasons why you shouldn't use textbook RSA in practice. You may answer this one by providing short explanatory quotes from sources you find, along with links to those sources.
[3] Identify one specific real-life digital signature algorithm based on RSA (as opposed, for example, to Elliptic Curve Cryptography). Give me a brief summary (with suitable links to sources) of how it works. In your summary, point out where the algorithm is doing something similar to our E(S_B,H(M)) "textbook RSA signature", and where the algorithm has added steps or data or whatever.
[1] For the signature algorithm in the previous item, describe one type of attack that the weird parts of the algorithm are designed to resist. Provide a reference/link to more detailed information about that attack.
[2] Show me how to generate a public/private key pair and a digital signature for the message "security is weird" using the openssl command. Include in your submission your key pair, your signature, and the sequence of commands you used to create them.
[1] Suppose Alice was doing the signing in the previous item. Show me how you, as Bob, will validate Alice's signature using openssl.