Review Videos for Lecture 14: Cross-Site Request Forgery (CSRF) + Cross-Site Scripting (XSS)

• Summer 2020 Slides (CSRF)
• Summer 2020 Slides (XSS)
• Playlist (length: 1:23:44)

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

Cross-Site Scripting (XSS)

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.