Lecture 23: CSRF + Impersonation Attacks

Note: Together, lectures 23 and 24 cover three topics (CSRF, Impersonation Attacks, UI Attacks). Each topic is about 30-35 minutes long. We put two topics today and one topic on Monday, but you can also watch one topic today and two topics on Monday, or some other combination.

• Slides for CSRF
• Playlist for CSRF (length: 34:46)
• Slides for Impersonation Attacks
• Playlist for Impersonation Attacks (length: 29:57)

Cross-Site Request Forgery (CSRF)

HTML Forms

Why do we prefer sending HTML forms using HTTP POST requests instead of GET requests?

Submitting forms usually causes the server to change some internal state, like changing your bank account balance. By convention, we use POST requests when a request causes the server state to change.

Session Management with Cookies

Cross-Site Request Forgery (CSRF)

Fill in the blanks with (attacker/victim/server) or (GET/POST): In a CSRF attack, the ___ sends an HTTP ___ request to the ___. The ___ responds with some HTML that fills out a form with malicious input and some Javascript that sends the form to the ___. The ___ sends the filled-out form to the ___ as an HTTP ___ request, along with any browser cookies. The ___ thinks this request is legitimate and accepts the malicious form input.

In a CSRF attack, the victim sends an HTTP GET request to the attacker. The attacker responds with some HTML that fills out a form with malicious input and some Javascript that sends the form to the server. The victim sends the filled-out form to the server as an HTTP POST request, along with any browser cookies. The server thinks this request is legitimate and accepts the malicious form input.

Real-World CSRF Attacks

Defense: CSRF Tokens

Would the CSRF token defense work if the server used the same CSRF token for every request, regardless of user?

No. Now the attacker could make a request to the server, see the value of the CSRF token, and use the same value in a CSRF attack. The CSRF token needs to be different for every user.

Defense: Referer Validation

Would referer validation stop the CSRF attack shown at the beginning of the video? Assume the browser attaches the correct referer, and the referer field is not blank.

Yes. The referer field would show attacker.com because the victim was on the attacker’s website when they made the HTTP POST request with the malicious form.

CSRF Conclusion

Impersonation Attacks

Authentication and Impersonation

Two-Factor Authentication

What two factors are used when you sign into your Berkeley account?

Your password (something you know) and confirmation on your smartphone (something you have).

Session Hijacking

(True/false) Setting the HttpOnly flag on a cookie is a good defense against session hijacking by packet sniffers (on-path network attackers).

False. Packet sniffers view the content of an HTTP request when it’s sent over the network. They don’t interact with Javascript on the user’s browser, so setting the HttpOnly flag doesn’t stop them from seeing session tokens on unencrypted connections.

Intro to Phishing

Phishing Example

(True/false) There is no phishing attack on this webpage.

Phishing Defense: Check URLs

URL Obfuscation Attack

Homeograph Attack

Spear Phishing

Why Does Phishing Work?

Phishing Conclusion