WebFund 2016W Lecture 22
Video
The video for the lecture given on March 31, 2016 is now available.
Notes
In Class
Lecture 22 ------------ Web Security Security in isolated systems - no networking What is the threat model? Threat model - what attacks are you trying to defend against - what attacks are you NOT trying to defend against Computer in an isolated room - ignore physical attacks, e.g. sledgehammers How to compromise this computer? - someone bad starts typing - someone inserts malicious media/device - parking lot flashdrive attack (solution: epoxy) - electromagnetic emissions (live in a faraday cage) Computer on a network - all local attacks - attacker can send arbitrary network data to system - attacker can listen in on network traffic - attacker can change outgoing traffic Basic defense: network crypto - encrypt to hide, sign data to protect integrity, verify authenticity Who will access? - authenticated, authorized users - unauthorized individuals/systems - attackers (can be either of the above) How can an attacker be "authorized"? - social engineering (can you please reset my password?) - brute force (try all the passwords) - technical compromise of credentials (keylogger) - authorized user turns/is malicious (insider attack) And now the web Who can access your application? - ANYBODY - for public web apps, ANYBODY is an authorized user So just from this we can see that web security is going to be hard. The other half of the nightmare: the browser Ideally, to secure systems you isolate components - build big walls Your web browser has walls between pages...but there are BIG HOLES (on purpose) - cookies, in particular, are shared - this is bad because the scope of cookies is determined by DNS (domain name system) DNS has almost no security - there is DNSSEC but nobody uses it, yet at least You can better protect cookies by using HSTS - force HTTPS everywhere on a page/domain - protects against mixes of http/https content and downgrade attacks Why do we have cookies in the first place? - because HTTP was supposed to be stateless Also... Cross-site Scripting (XSS) attacks - not necessarily cross-site, not necesarily scripting - "web injection attacks" - see anywhere attacker can inject content into a page - (ads) - comments - social media - "user-generated content" - failure to sanitize untrusted input that is inserted into a web page (adding a comment to a page) - otherwise, you can insert arbitrary HTML, CSS, and JavaScript into the page Cross-site request forgery - makes use of cookies automatically being sent to domain, no matter where the link came from - can stop using tokens in URLs, or checking Referer/Origin headers (and a few other ways) Same-origin policy - data should only be loaded from the originating server - but, you can load almost anything else from anywhere - images - sound - javascript So what about JSON? - when you load it with AJAX, you have same origin policy - but if you just treated it as a script... - and what if you were logged in - bank sending data as JSON JSON files are valid JavaScript but they don't specify the name to give to the data structure - so you can't access it, unless To build an object, you have to call the object's constructor - why not replace the constructor with our own method? e.g., override Array - this is solved in regular browsers for JSON by only using a clean JavaScript environment for JSON.parse() This doesn't help you for code, but who cares about code, right? - many websites dynamically generate JavaScript and put personal information into it Solution? Don't mix code and data! WebAssembly ----------- * Many, many people hate JavaScript * Lots of code that isn't JavaScript * But people want everything to run on the web in a browser Past efforts at having alternative languages all had a basic problem - they couldn't see the DOM - e.g., Java applets, Flash, Silverlight And, what about all those other languages? - C, C++??! - how about games? Unreal runs in a web page - there's WebGL which is pretty fast So, why can't we compile code and have it run in the browser? Two old solutions: - NaCl (Google) - asm.js (Mozilla) They joined up and are now making WebAssembly This will be good for functionality and bad for security. - security won't go well because code isn't designed for the web - but it will be cool to play games in a browser at full speed :-)