https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=WebFund_2024F_Lecture_21 2026-06-02T19:50:48Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2024F_Lecture_21&diff=24903&oldid=prev 2024-11-28T19:29:00Z

<p>Created page with &quot;==Video== Video from the lecture for November 28, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec21-20241128.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec21-20241128.cc.vtt auto-generated captions] ==Notes== &lt;pre&gt; Lecture 21 ---------- Web Security What are the goals of computer security? - confidentiality, integrity, availability (CIA) - (entity authe...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture for November 28, 2024 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec21-20241128.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec21-20241128.cc.vtt auto-generated captions]<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 21<br /> ----------<br /> <br /> Web Security<br /> <br /> What are the goals of computer security?<br /> - confidentiality, integrity, availability (CIA)<br /> - (entity authentication)<br /> <br /> What does this mean in the context of web applications?<br /> - make sure web apps stay up (keep running) &lt;-- availability<br /> - ensure data stored in a web app isn&#039;t corrupted &lt;-- integrity<br /> - ensure data and services are only provided to authorized entities &lt;--- confidentiality<br /> <br /> What have we done mostly right wrt security?<br /> - secure password storage<br /> - sessions with expiration and strong session IDs<br /> - proper parameterization of database queries (avoiding SQL injection vulnerabilities)<br /> <br /> What is SQL injection?<br /> - attacker is able to execute arbitrary SQL queries by &quot;injecting&quot; malicious inputs to the application<br /> <br /> Approaches to avoiding SQL injection is to sanitize inputs<br /> - escape/quote characters like &quot;;&quot;<br /> - this is very hard to do in general, very error prone<br /> - separate definition of SQL command from user inputs<br /> - this is much better, very safe<br /> - done right, no way for attacker to turn malicious input into SQL code<br /> <br /> <br /> SQL injection is just one example of the general class of code injection attacks<br /> - attacker provides input to an application that is meant to be treated as data<br /> but gets interpreted as code, typically running in a privileged context<br /> <br /> <br /> Classic examples of code injection are buffer overflow attacks<br /> - typically in C code, but can come up in any code that uses a C library<br /> - C by default doesn&#039;t do proper bounds checking on arrays<br /> - very easy to write data outside the bounds of an array<br /> - if you know how memory is laid out, you can overwrite key bits of data<br /> (pointers, esp return stack pointer) that then allow an attacker to take over the program,<br /> control how it executes<br /> <br /> Modern systems have many defenses against buffer overflow and related memory corruption attacks<br /> - stack canaries<br /> - ASLR (address space layout randomization)<br /> - no-execute memory<br /> <br /> Web code is mostly written in languages that automatically manage memory<br /> - so there isn&#039;t much opportunity for memory corruption attacks<br /> - however, there are MANY opportunities for code injection attacks, they just use different code!<br /> <br /> Wherever you have a code execution engine, you have an opportunity for code injection.<br /> <br /> Where do we have code execution engines?<br /> - client-side JavaScript, HTML, CSS, WebAssembly<br /> - server-side JavaScript (or whatever other language is running)<br /> - server-side SQL<br /> <br /> code injection vulnerabilities in server-side SQL are common (SQL Injection)<br /> code injection vulns in server-side JavaScript are rare (require use of eval mostly)<br /> - i.e., construct a string and then run it as JavaScript code<br /> - was much bigger of an issue when JSON parsing was done using regular JavaScript<br /> <br /> <br /> client-side code is VERY vulnerable to code injection attacks because &quot;code&quot; is dynamically constructed and naturally co-exists with untrustworthy data<br /> <br /> cross-site scripting attacks (XSS) are a well-known class of web application vulns<br /> - but XSS attacks don&#039;t have to be cross-site and don&#039;t have to involve scripting!<br /> - better thought of as code injection attacks at the level of HTML/CSS/JavaScript<br /> - but with a server component<br /> <br /> The classic template for XSS:<br /> * a malicious user uploads content to a web server<br /> * victim accesses web app and is compromised<br /> <br /> Vuln arises because attacker can send malicious data to their target VIA THE WEB SERVER<br /> <br /> <br /> In authdemo2, how could we potentially perform an XSS attack?<br /> - student could upload an assignment with embedded HTML/CSS/JavaScript<br /> - when instructor/admin views submissions (/list), the malicious payload executes<br /> - maybe sends all submissions to attacker?<br /> <br /> How do you mitigate vulnerabilities in client-side code?<br /> - filter &lt;--- make sure untrusted input fits a safe pattern<br /> (e.g., student IDs are all numeric digits)<br /> - escape &lt;--- transform characters that could allow code to be injected into safe forms<br /> <br /> To prevent HTML from being inserted, you have to prevent tags from being inserted<br /> - and tags are formed using &lt;&gt;<br /> - so you replace &lt; with &amp;lt; and &gt; with &amp;gt;<br /> &lt;/pre&gt;</div>

Soma