Summary of the second-part of this Stanford’s web security course taught by Feross. Topics include: SQLi, HSTS, TLS, Local Server Security, DNS Rebinding, Browser Architecture

Lecture 10 (Code Injection)

Blind SQL injection

There are 2 types of SQLi:

  • Content based
  • Time based: bruteforcing each letter of password when true do a slow thing else do a speedy thing.

SQLi Defense:

  • Never build SQL queries with string concat!
  • use either Parameterized SQL or ORMs.

Lecture 11 (TLS)

We want a communication that is private (man in the middle cannot eavesdrop the content of the message), cannot be tampered (integrity) and authenticated (we know who we are talking to)

Diffie-Hellman key exchange

  • To validate which server are client communicating with
  • The Diffie-Hellman algorithm provides the capability for two communicating parties to agree upon a shared secret between them. Its an agreement scheme because both parties add material used to derive the key (as opposed to transport, where one party selects the key). The shared secret can then be used as the basis for some encryption key to be used for further communication.
  • Need to add authentication -> use signature schemes

Signature schemes

A triple of algorithms generator, signer, validator (G,S,V)

  1. G() -> (pk, sk) - generator returns public key and secret key
  2. S(sk, msg) -> t - signing returns a tag t for input msg
  3. V(pk, x, t) -> accept | reject - checks validity of tag t given input msg

Algorithm properties

  1. V(pk, msg, S(sk, msg)) = accept
  2. V(pk, msg, t) for random t != accept

How do the client get the public key in the first place?

  • Certificate Authority (CAs) -> which certify that SUBJECT_NAME is indeed the owner of a certain PUBLIC_KEY

HTTPS attack: TLS Strip

Usually when you make a http request to a site (by leaving out the protocol or sent “http://"), the browser will sent a 301 response to redirect you to the https site.

However, if a man in the middle intercepts the first HTTP request (which is unencrypted), it can then impersonate the client, and handles the HTTPS redirect itself. When it gets the response from the server, it can read out the response, and change all https links to the server to http, thus naming it TLS strip. The client donot know this, and the site that they are served will forever be in the http land.

Defenses might include setting the HSTS (Strict-Transport-Security) header (basically the server saying to the browser to always use https when talking to me). However, this needs at least 1 time for the client to talk to the server. Example was when you first time ssh, it will ask if you trust this server’s fingerprint.

Lecture 12 (HTTPS in the real world - Emily Stark & Chris Palmer of Google Chrome)

Other than the summary below, the talk also talks some of the details of Certificate Transparency logs, specifically what has been done before, what are the problems faced, and how the current solution using CT logs are being implemented to minimize CAs from issuing malicious certificates.

Some HSTS problems

  • no way to set includeSubdomains for all-but-one-or-two subdomains
  • no standardized way to set HSTS broader than your subdomain. In practice, usually ***.example.com will load an invisible pixel from example.com, which will set HSTS for the whole domain.
  • no way to undo HSTS besides waiting for the max-age to expire
  • Do not protect on first visit. To mitigate this, browsers maintain a preload lists of websites that only want to be contacted via HTTPS
  • can be used for HSTS tracking. More on that below.

HSTS Tracking (at a high level)

Setting the cookie:

Users visits shopping-site.com, which load a script from ad-network.com. Ad-network.com script assign visitor a unique binary number (say, 0b11010001), and loads a subresource for each bit set in the identifier. Each subresource will then set HSTS for that subdomain.

  • 1.ad-network.com
  • 5.ad-network.com
  • 7.ad-network.com
  • 8.ad-network.com

Reading the cookie:

Users visit news-site.com, loads script from ad-network.com and the script will try to load subresource for each bit and observes which subresource redirect to https://

  • 1.ad-network.com
  • 2.ad-network.com
  • 8.ad-network.com

Lecture 13 (Authentication)

New updated password requirement best practices

  • min pswd length >= 8 chars
  • max pswd length <= 64 chars (to prevent long password DOS)
  • check passwords against known breach data
  • rate-limit authentication attempts
  • encourage use of second FA

Beware of logging HTTP requests, because user send password using a HTTP POST request.

On Captcha

Newest Captcha -> will run in the background to determine whether IP is a real person based on mouse clicks or other interactions with the web.

Other mitigation

  • Reauthenticate for sensitive features before change password, change email, add new shipment address
  • Give generic response on login / account creation / reset password
  • Also beware of timing response discrepancy (return early in the code)
  • Other mitigation might include friendly message but rate-limit them

How to store passwords?

  • Never store passwords in plaintext. (instead, hash them.)
  • Some problems with “just hashing” -> identical passwords are easy to spot, precomputed lookup attacks are easy (put in strings into hash beforehand)
  • Use: salt the password + hash the salted password. -> store salt next to the password.
  • General Advice: just use bcrpyt to store passwords.

Time Based OTP (Multi Factor Authn)

  • Server choose random secretKey for the username
  • Server share secretkey through QR code
  • Phone scan QR code and combines it with current counter (taking current time) and calculate a 6 number OTP locally
  • Server did the same
  • User input OTP generated by phone to server, and server validates it

Lecture 17 (Safe coding practices)

  • Complexity is the enemy of security - Goal of abstractions is to hide complexity from the developer. The more edge cases an abstraction, the “leakier” it is.
  • Explicit code is better than clever code - Writing overly clever, succinct, or “magic” code can increase complexity
  • Fail early / Crash early
  • Code defensively - Your assumptions may be violated, so always verify them upfront

Bad API design

  • Insecure defaults require developer to set options to get secure behaviour

  • Polymorphic function signatures which put lots of unrelated functionality into same function, e.g. the $ function of jQuery.

  • Behaving differently based on function arity

    e.g. old Node Buffer can be exploited to sent raw server memory if user input is of type number

Lecture 18 (Local HTTP server security)

case discussed

  • zoom site sends a GET request to the local server to open up the zoom client app
  • How a “preflighted” request can help to mitigate this? By changing GET method to PUT method, we basically make the request not a “simple” request anymore, and so the browser will make a preflight request to the local server to ask if the PUT action is permitted

Lecture 19 (DNS Rebinding Attacks)

Most IOT devices are / were vulnerable to DNS rebinding attacks

DNS Rebinding attacks trick the browser to think that local victim server is the same origin to attacker.com. Attackers uses the browser as a “proxy” to access local network.

The trick here is to send a request from www.attacker.com to www.attacker.com. When the page first loads, it loads from the attacker IP address. Detecting that the victim is now on the page, the attacker “rebinds” its ip address to your local network ip address (say 127.0.0.1 or 192.168.0.1). Now, when the a request was sent to www.attacker.com, the request will instead go to your local network and can send packets to IOT devices connected to your local network.

DNS rebinding doesnt violate browser’s Same Origin Policy, because as far as the browser’s concerned, it is a same-origin request. Remember that two origins are the same if they have the same protocol + hostname + port. It doesnt care about ip address. (Aside: can we update that same-origin policy enforce ip address? then it might be hard to do load balancing etc.)

Why is it more dangerous in local servers? What if we redirect it to some server on the internet (say, the bank server)

  • If the server is on HTTPS, then when connecting with the bank server, the browser will do a TLS handshake, and the browser will receive a certificate from our bank server, but it will discard it because the browser perceives that it is talking to attacker.com and not our bank server,
  • Even if the server is on HTTP, as we are talking to attacker.com, the browser will not attach those “cookies that are for our bank server” to the request. In both cases the damage is limited

Defenses

  • You might configure your network firewall to not allow any request from the internet that goes to your local network.
  • Add a middleware inside your server that throw an error if the host request headers is not what you expected

Conclusion

JS safe coding practices

  • Always use === in javascript
  • use strict or a linter
  • If you need to access Object properties, use Object.prototype.<method name>

Key ideas

  • Think like an attacker!
  • Never trust user input - always sanitize it, at time of use
  • Use defense-in-depth - provide redundancy in case security controls fail
  • Salt and hash user passwords - ‘just use bcrpyt'
  • Beware of ambient authority - use SameSite cookies!
  • Don’t write clever code - explicit code is safer than magical code
  • Dangerous code should look dangerous - make it standout
  • You can never be too paranoid - practice constant vigilance