CS253 Lecture Summaries: Part I Basics
Lecture One: Introduction
Starts with a story of an exploit Feross found when studying a precursor of the class.
Local storage is limited to 5mb per site, but that 5mb is isolated to subdomain. So you can spin up subdomains and each takes 5mb of storage, repeat until your target’s computer crashes. Create iframes, store 5mb each.
This is now fixed.
Another is clickjacking, create an invisible modal, user thinks they are clicking a button, actually they are giving permission for you to use their webcam…
goal 1 is the attacker mindset - if you’re not thinking like an attacker when you’re writing code, the code has vulnerabilities. If you’re not thinking of attacks when designing the system, that system is insecure.
goal 2 is the defender mindset - harder to defend than attack.
goal 3 is learn to architect secure systems - we need backups, one aspect can fail but the system is still safe.
Why is computer security hard?
Lots of buggy code.
Social engineering is very effective.
There’s money to be made by finding and exploiting vulnerable systems.
Marketplace for vulnerabilities
Marketplace for owned machines / stolen data
Many methods to profit from owned machines / stolen data. Use it to DDOS, ransomware, mine crypto, take personal info, send spam.
A vulnerability is a problem area of code, an area that requires a closer look. An exploit is when a vulnerability is actually weaponised.
Some attacks target a client machine, others target a server, which then might target any user communicating with the server.
There is a lot of data theft.
What is web security?
Multi-faceted concept, can mean several things, here are some of them:
Browser security. EG Same Origin Policy, the most important concept in web security. Isolates sites from each other while running in the same browser. For example that tabs are isolated from each other in memory, or that iframes can’t operate on their parents.
Server security. Attackers can run arbitrary HTTP clients; can send anything to the server. Users can modify your browser apps to do anything they like.
Client app security. The code that’s running in the browser needs to be secure for that user, ie that links on the page can’t allow another site to inject scripts into our page (XSS). It’s really easy to get users to visit a link - you just load an iframe and load the page. So getting a user to visit a malicious URL is really easy. We have to defend against that.
User security. Protect the user from social engineering, from trackers leaking private data.
Why is web security hard
extremely ambitious goal - run untrusted code securely.
Different sites interacting in same tab
low level features; hardware access
desire for high performance
APIs not designed from first principles
strict backwards compatibility, can’t break old websites.
Sites can: download content from anywhere, spawn worker processes, open sockets to a server, or to another user’s browser, display media in many formats, run custom code in the GPU, save/read data from the filesystem.
Part 1 will be about the browser security model, same origin policy.
Part 2 will be client security, attacks and defence
Part 3 will be server security, attacks, defence, authentication, TLS
Part 4 will be writing secure code
Reviews HTML
We’re going to spend a lot of time on the <link>, <style>, and <script> tags, as that is where the attacks come.
Reviews JS and Node
Node added support for filesystem, HTTP, DNS, sockets, module system, binary data support.
Less necessary now since JS itself has improved to plug many of the gaps, but still it’s geared for scripting locally.
People lump all the ‘JS APIs’ together. But APIs come from several sources:
the language spec (eg Array)
the browser, eg the DOM API is provided by the browser. Many bad APIs here.
Node.js, eg fs.readFile
Browser has lots of crusty old APIs, eg:
window.open(), pop up!
window.moveTo(), window.resizeTo() - can move and resize a window.