WebFund 2016W Lecture 22

From Soma-notes
Revision as of 21:10, 31 March 2016 by Soma (talk | contribs) (Created page with "==Video== The video for the lecture given on March 31, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec22-31Mar2016.mp4 is now availab...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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