SystemsSec 2016W Lecture 22

From Soma-notes

Topics and Readings

Notes

- Any attack on user space in Linux could work on Windows - If we make it easy to run Android apps on Windows OS, who would want to develop windows applications? - Azure is already multiplatform; allowing Linux applications to run on Windows.

Web Security Review

 - Questions to discuss:
   - What is the threat model of web security?
   - Who is the attacker? The defender?
   - What is happening?
 - An example of the attacker targeting a user is phishing (taking credentials)
 - An example of the attacker targeting a web server: sending random data/traffic (ie. comment spams)
 - The attacker messes with the browser through the network connection and can then run arbitrary code inside the browser
 - The browser contains tokens that help access information from the web server
 - The purpose of getting access to a token – impersonation
 - The web in general, has a lot of depth and richness, opening up vast amounts of vulnerabilities.
 - The execution of the model is strange
   - Where does the web application live?
     - It doesn't just live in the browser, it consists of the entire web model/mesh
     - It's distributed
     - Not every entity of the model is trusted
     - All these web applications are running on the same system, but each have API's that allow them to connect to the rest of the world
     - The design of the model is convoluted
 - Web security is complex because of web browsers
   - Web browsers weren't initially designed for a shared environment that executes a large variety of applications
   - Because of all the interactions the browser allows, it affects the security of everything in the infrastructure.

Cookies

 - It's data that contains the state of the user or session
 - Efforts to delete the cookies every so often can be useful, but can reduce security
 - Cookies are used to mark your browser as special or known
 - Professor suggests using a different browser configuration for banking related activities
 - Firefox allows you to setup different configurations through profiles, which have their own cookie stores, history, etc.
 - Just because a browser, such as Chrome, is sandboxed, it doesn't mean that it's secure. Cookies stores are still shared
 - Cookie stores are little file systems, but with not high integrity
 - Cookies belong to domain names -> You can specific general domain names or specific routes
 - Domain names can be bad if you're connecting to untrusted networks
 - DNS is a distributed database for mapping host names to IP addresses
 - Example:
   - Accessing 'scs.carleton.ca'
   - Find who has authority for 'ca' -> then for Carleton -> then for scs
   - Going through different systems to find names, there's also no cryptographic protection against DNS (There are a lot of attacks that can fake it)
   - Networks at Starbucks intercept the DNS. Splash page pops up when visiting a site. DNSSEC can be used to mitigate against it, but not used often.
 - Everything depends on DNS. If tampered with, everything breaks.
 - Cookies are insecure because DNS is insecure
 - You can hijack cookies because you can mess with DNS

Protocols

 - Browsers don't distinguish well between HTTP and HTTPS, therefore not guaranteeing a secured connection over HTTPS.
 - Why do we use cookies? Why do we authenticate tokens?
   - HTTP was designed to be stateless, but we then wanted to have states
 - Technical standards aren't always better. Ie. Local Storage for cookies
 - You keep things secure by isolating them
 - Lack of isolation for functional purposes – People want to do things
 - HSTS
   - Not really a new protocol
   - Enforces access over HTTPS
   - If not HTTPS, don't trust
   - It's because some web applications use both HTTP and HTTPS. The HTTPS downgrades to HTTP. HSTS won't let it talk to the page.
   - Downgrade attack:
     - Connection isn't encrypted at all
     - Very easy to intercept (Man in the middle attack) instead of breaking encryption

Some Types of Attacks

   - Cross-Site Scripting (XSS)
     - Untrusted data inserted into the page
   - Cross-Site Request Forgery (CSRF)
     - Impersonation
     - Sending unauthorized requests
 - Using JSON to attack
   - SOP not implemented for JSON markup files
   - It executes into an object; you gain a reference to it
   - You can override the array prototype methods to leak it
   - Doesn't work anymore, clean JS environment is used to parse the JSON

Paper: The Unexpected Dangers of Dynamic JavaScript

 - Paper is about loading JS script files from target websites into attacker's web application to gain access to sensitive data
 - Gain access to JS file by guessing location of the script
 - Once the JS script file is loaded, properties of JS such as global variables, scoping, prototype inheritance with method overwriting can be used to access the sensitive data
 - How to mitigate against it?
   - Don't keep sensitive data in dynamic JS files, keep it in the static files

Paper: Cookies Lack Integrity: Real-World Implications

 - In general, this paper is hard to keep track of
 - Web security in general, is very tough to handle in contrast to OS security where we have reference monitors and policies. Web security does contain similar elements, but they are scattered
 - The web is a bit is like a distributed OS in the sense that we know how to scale it, predict behavior, but don't have security guarantees

How to solve web security?

 - How would you architect it?
 - Perhaps isolate applications to domains
 - Have a trusted browser as the reference monitor
 - Make the browser as minimal as possible
 - Get rid of the DOM and JS; instead have some mediary format
 - Every website can reqest a particular running environment by using hashes.
 - Secure web security would essentially break the entire revenue model of the web - advertising.

ASM.JS

 - A subset language of JS that allows arbitrary code to be compiled to JS with assembly-like speed.
 - Still have all the protection that JS would have
 - Problem:
   - People would start running all kinds of code in the browser that isn't designed for the web
   - Arbitrary environments
   - Whole new class of exploits
Retrieved from "https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_22&oldid=20914"