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 :-)