Lecture 14: Cross-Site Scripting (XSS) and UI Attacks

• Slides
• Playlist (length: 1:52:43)
• Source code for the Squigler demo

Intro to XSS, Review

Stored XSS

If the user input is stored on the server and displayed as HTML, how can an attacker inject Javascript?

<script> tags in HTML allow Javascript to be embedded in HTML page.

XSS Demo

Real-world XSS Attacks

Reflected XSS

(True/False) Reflected XSS requires the victim to visit a malicious link crafted by the attacker, but Stored XSS does not.

True. In Reflected XSS, the malicious script is passed through the URL, so the attacker needs the victim to visit a link that contains the malicious script. However, in Stored XSS, the malicious script is stored on the server, so the victim could load the malicious script by visiting a legitimate website.

XSS Defenses

Consider an escaper that finds all instances of <script> and </script> in user input and removes them. Can an attacker still perform an XSS attack with <script> tags? If yes, write a malicious input that would bypass this escaping function. If no, explain why.

Yes. Consider this input: <scr<script>ipt>alert(1);</scr<script>ipt>. The escaper will find two instances of <script> and remove them, but after they’re removed, the input is now <script>alert(1);</script>!

Important takeaway: Building an escaper is hard, and attackers have many creative ways of bypassing escape functions.

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

Clickjacking

How does clickjacking subvert the same-origin policy?

The user is interacting with a fake attacker-controlled user interface, which runs with the attacker’s origin, not the origin of the legitimate website.

Cursorjacking

Clickjacking Defenses

(True/false) If we enabled dialogue boxes asking for confirmation on every website, clickjacking attacks would never work.

False. Careless users could still unintended clicks and confirm them if they don’t check the dialogue box carefully. Also, attackers could create their own fake confirmation boxes.

(True/false) Clickjacking attacks can only happen when you are visiting an attacker’s website.

False. A legitimate website could load a frame that tries to perform a clickjacking attack. For example, a streaming website might load an advertisement that shows you a fake Download button.

Defense: Framebusting

Defense: Ensuring Visual Integrity

Defense: Enforcing Temporal Integrity

Defense: X-Frames-Options

Browser-in-Browser Attack