CS 161 Final Review

May 6, 2020

CS 161 Course Staff

Announcements

• Grade projections will be out tonight (ETA: 6-7pm PT)
• Course eval for extra credit: https://course-evaluations.berkeley.edu
• Live solve of sp19 final tomorrow at 4pm PT

Table of contents

• Networking
• (4) Low-layer stuff, ARP, DHCP
• (20) IP, UDP, ports, TCP
• (32) TLS
• (46) DNS
• (57) DNSSEC (it’s just a link to Dave’s great slides)
• (63) DoS, Firewall, Detection
• Crypto
• (78) IND-CPA, block cipher designs
• (88) Diffie-Hellman, El Gamal
• (93) Hashing/pRNG

• Web
• (98) HTML, JS, SOP
• (111) Cookies
• (139) SQL injection
• (158) XSS, CSRF

Networking

Layering

• The internet is like an onion: layers!
• Each layer relies on services provided by next layer below… and provides services to layer above it
• Similar to levels of abstraction when you program

Layering

• Layer 1: Physical (bits on a wire, radio waves for WiFi, etc.)
• Layer 2: Link -- communication between "local" hosts
• Layer 3: InterLink -- communication between different "remote" hosts (IP)
• Layer 4: Transport -- TCP / UDP (more details soon)
• Layers 5/6: nobody cares.
• Layer 7: Application: things like HTTP (websites), SSH, etc.

OSI Layer 1: Physical layer

• Analogy:
• Something that moves data.
• Carrier pigeons. Pizza delivery guy.
• How to attack: shoot down the pigeon.

OSI Layer 1: Physical layer

• In reality:
• Bits moving over space.
• Voltage signals, electrical signals, etc.
• How to attack: cut the wire.

OSI Layer 2: Link layer

• Analogy:
• Two post offices connected by a carrier pigeon/delivery guy.
• Local: you can only communicate between the post offices.

OSI Layer 2: Link layer

• In reality:
• Defines communication between local hosts (think Wi-Fi network)
• Support for broadcast protocols
• Main protocol we care about here: ARP

MAC addresses

• Analogy:
• Like an apartment number.
• Useful for identifying somewhere in the local area, but useless for identifying somewhere in the world.

Attacker Definitions

(for the purposes of this class)

• Man-in-the-middle (aka in-path): Attacker can see and modify traffic.
• On-path: Attacker can see but not modify traffic.
• Off-path: Attacker can’t see anything. (Still knows public information)

Remember all attackers can send whatever packets they want!

Think about what fields an attacker would need to guess correctly!

ARP: Address Resolution Protocol

• Problem: Translate a global (IP) address to a local (MAC) address.
• Analogy:
• Mysterious package arrives addressed to someone in the complex.
• We are going to have trust someone if they claim it’s theirs.

ARP: Address Resolution Protocol

Converts IP addresses to MAC addresses.

• Host A wants to send a message to Host B
• Host A gets Host B’s IP address (Call it X) from DNS
• Host A broadcasts “What is the MAC address of X?”
• Host B sends a message only to A “My IP is X and my MAC address is _”.
• The IP, MAC pair gets cached

(If the X is outside the local network, then the gateway responds with their MAC address)

ARP: Spoofing

The ARP request is public. What happens if

• Alice sends out an ARP request for Bob’s MAC address
• Mallory responds with hers instead and beats Bob’s response.

ARP: Spoofing

Alice now believes Mallory’s MAC address is Bob’s and will send her packets intended for Bob.

DHCP: Dynamic Host Configuration Protocol

• Analogy:
• When you first move into your new apartment, you need to learn your new address and figure out where the laundromat is.
• You don’t know anyone here, so you’re going to trust any neighbor’s advice.

DHCP: Dynamic Host Configuration Protocol

When you first connect to a network, you need a few things:

• An IP address
• The DNS server’s IP address
• The gateway’s (router's) IP address

DHCP: Handshake

Client Discover: “I need configuration information!”

Server Offer: “Here’s some possible configurations: A, B, C”

Client Request: “I want to use configuration C”

Server Acknowledge: “Okay, I have given you config C”

Client messages are broadcast across the local network

DHCP: Spoofing

What happens when Alice accepts Mallory’s configuration?

Mallory now controls Alice’s:

• Gateway
• DNS (we talk about this later)

What can she do with this?

OSI Layer 3: (Inter)network Layer

• Analogy:
• Make lots of hops from post office to post office. Now you can send messages anywhere in the world!
• Apartment numbers (MAC addresses) now useless. Instead we need global addresses (IP addresses)

OSI Layer 3: (Inter)network Layer

• Global routing
• No guarantee of reliability
• Packet delivery between different local networks, “best effort”

Headers: IP

OSI Layer 4: Transport Layer

• Analogy:
• Now that we can send messages anywhere in the world, we can start conversations.
• Pen pals, correspondence chess, etc.

OSI Layer 4: Transport Layer

• Connection: one service (on a host) to another
• TCP: Reliable, in-order, connection-oriented transport
• UDP: Unreliable, datagram-based transport
• A datagram is a single packet message

Headers: UDP

Quick detour: Ports

• Analogy:
• Alice is pen pals with Carol. Alice’s roommate Bob is also pen pals with Carol.
• Carol’s replies are addressed to the same global (IP) address. How to tell which letters are for Bob and which are for Alice?

Quick detour: Ports

• Analogy:
• Solution: Add a room number (port) inside the letter.
• In private homes like Alice/Bob, the port numbers are meaningless.
• In a public office (server) like Cory Hall, the port numbers are constant and known.

TCP: Transmission Control Protocol

Three-way handshake:

• Client sends: SYN, SEQ= x (arbitrary by the client)
• Server sends: SYN-ACK, SEQ= y (arbitrary by the server), ACK = x + 1
• Client sends: ACK, ACK = y + 1

The SEQ and ACK values swap depending on who’s sending the message. (You ACK the SEQ you receive.)

Headers: TCP

TCP: Vulnerabilities

• TCP is not inherently secure
• No confidentiality or integrity of data by default
• A malicious entity who knows the sequence numbers, port numbers, and IP addresses can spoof a connection
• This means on-path attackers can easily inject data.
• If an off-path attacker can guess this information, they can also inject data
• It also does not provide availability
• TCP RST injection lets an attacker terminate connections

Layer 6.5: Secure communication

• Analogy:
• Protect against correspondence chess pirates.
• (Not a real layer, because OSI is ancient and predates the invention of security.)

Layer 6.5: Secure communication

• TCP is not inherently secure
• No confidentiality or integrity of data by default
• A malicious entity who knows the sequence numbers, port numbers, and IP addresses can spoof a connection
• This means on-path attackers can easily inject data.
• If an off-path attacker can guess this information, they can also inject data
• It also does not provide availability
• TCP RST injection lets an attacker terminate connections

TLS

• Goal is to create a secure channel
• Confidentiality: nobody can see the data communicated
• Integrity: you know the data has not been changed in-transit
• Timeliness: you are guaranteed that old data is not being replayed by a MITM
• DOES NOT PROVIDE:
• Anonymity: easy to figure out who is talking with whom
• Availability: TLS does not prevent DoS or messages being adversarially dropped
• Padding^*: one can tell how much data is being communicated
• Non-repudiability: not possible to prove that this was the message you received

HTTPS Connection (SSL / TLS)

​

• Browser (client) connects via TCP to Amazon’s HTTPS server
• Client picks 256-bit random number R_B, sends over list of crypto protocols it supports
• Server picks 256-bit random number R_S, selects protocols to use for this session
• Server sends over its certificate
• Client now validates cert

Browser

Amazon

Server

PS via RSA

• Client generates premaster secret (PS), encrypts it with server's public key, and sends it to server
• "If you really have the RSA private key, prove it to me by decrypting this PS."

​

• Both sides use PS (along with R_b, R_s) to derive symmetric keys.

Browser

Here’s my cert

~2-3 KB of data

{PS}_PKAmazon

PS

PS

Amazon

Server

Q: Forward secrecy?

A: No forward secrecy because attacker can decrypt PS and knows R_B, and R_S and computes secrets

PS via Diffie-Hellman

• For Diffie-Hellman, server generates random a, sends public params and g^a mod p
• Signed with server’s private key
• Browser verifies signature using PK from certificate
• (provides security against classic Diffie-Hellman MITM)
• Browser generates random b, computes PS = g^ab mod p, sends g^b mod p to server
• Server also computes PS = g^ab mod p
• Both sides use PS to derive symmetric keys.

Browser

Here’s my cert

~2-3 KB of data

PS

PS

Amazon

Server

Q: Forward secrecy?

A: Has forward secrecy because shared secret never sent over the network! If attacker as SK_Amazon, cannot find a.

Symmetric Key Generation

• Both sides now have PS.
• Using PS, both sides derive four keys:
• C_b - encryption key for messages from browser to the server
• C_s - encryption key for messages from server to the browser
• I_b, I_s - integrity keys (directional as above)

​

​

• Both sides now compute a MAC on the dialog (all messages from both sides).
• If a MITM tampered with the earlier steps (say, R_b, R_s, cipher suite agreement, &c), then they will be detected now.

Browser

PS

PS

Amazon

Server

…

TLS

Nice property of TLS: End-to-end security

• Properly implemented TLS is end-to-end secure.
• Literally anybody between you and your pal can MITM attack you, and your communication would still be secure.

TLS Limitations/Issues

• The system requires us to trust ALL Certificate Authorities
• Certificate management is complicated
• TLS can’t protect against logical errors on hosts.

OSI Layer 7: Application Layer (aka L5)

• Application-to-application connection
• DHCP, HTTP, DNS, SSH, TLS, etc.
• Welcome to web security...

If you receive an HTTP Packet it might look like this

What is the TCP payload?

What is the IP payload?

​

If you receive an HTTP Packet it might look like this

What is the TCP payload?

What is the IP payload?

​

If you receive an HTTP Packet it might look like this

What is the TCP payload?

What is the IP payload?

​

DNS

DNS: Domain Name System

Protocol for translating human-friendly domain names to a numerical address: www.berkeley.edu -> 52.10.99.247

Nameservers at least responsible for pointing to you in the right direction: .edu’s name server might not know how to get to www.berkeley.edu, but it knows that berkeley.edu’s name server knows and that name server’s IP address.

DNS: Example (borrowed from cs168)

DNS client�(me.cs.berkeley.edu)

DNS server

.org NS

wikipedia.org servers

Where is www.wikipedia.org?

Where is www.wikipedia.org?

Where is www.wikipedia.org?

​

Where is www.wikipedia.org?

Go ask .org nameserver at 1.2.3.4

Go ask wikipedia.org server at 5.6.7.8

Answer record: 9.10.11.12

ROOT

DNS: Resource Record (RR) Types

Each RR has a type and TTL (How long the record should be cached)

• A or AAAA: Matches a name w/ an IPv4 or IPv6 address

berkeley.edu 600 A 35.163.72.93

• NS: Gives you a name server responsible for a domain

edu. 172800 NS a.edu-servers.net

A typical DNS response: “Hey I found what you’re asking for”

​

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39459

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

​

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION: (What domain was queried for)

;berkeley.edu. IN A

​

;; ANSWER SECTION: (What the address of the queried domain is)

berkeley.edu. 16 IN A 35.163.72.93

​

;; AUTHORITY SECTION: (What the name servers responsible for berkeley.edu are)

berkeley.edu. 43860 IN NS adns2.berkeley.edu.

berkeley.edu. 43860 IN NS adns1.berkeley.edu.

​

;; ADDITIONAL SECTION: (Possibly helpful additional information: Where the nameservers are)

adns1.berkeley.edu. 90569 IN AAAA 2607:f140:ffff:fffe::3

adns2.berkeley.edu. 693 IN A 128.32.136.14

adns2.berkeley.edu. 1598 IN AAAA 2607:f140:ffff:fffe::e

​

Another typical DNS response: “I don’t know, but I can tell you who does and where they are”

​

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53577

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

​

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION: (What domain was queried for)

;berkeley.edu. IN A

​

;; ANSWER SECTION: (What the address of the queried domain is. Note the lack of value)

​

;; AUTHORITY SECTION: (What the name servers responsible for .edu are)

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

​

;; ADDITIONAL SECTION: (Possibly helpful additional information: Where the nameservers are)

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

​

Headers: DNS

DNS: Vulnerabilities

• Malicious DNS server
• .edu name server telling us berkeley.edu’s name server is ns1.stanford.edu’s IP address
• Why doesn’t bailiwick protect against this?
• On-path eavesdropper
• Spoofing
• Off-path attacker
• Blind-spoofing

What do spoofers need to guess correctly to be accepted by the victim?

DNS: Off-path spoofing

Eve

DNS resolver

wikipedia.org NS

Where is www.wikipedia.org?

www.wikipedia.org 1200 A 198.35.26.96

www.wikipedia.org 1200 A 6.6.6.6

Eve can’t see the source UDP port or the DNS ID field in this scenario.

DNS: Kaminsky Attack

• Once a resolver receives a response, it will cache the results. So not only does the spoofer need to beat the real result, once it loses, it can’t try again for a bit.
• Kaminsky’s attack subverts this by trying to poison the name server’s IP address in the Additional section.

DNS: Kaminsky attack

Eve

DNS resolver

wikipedia.org NS

Where is aaaaaaa.wikipedia.org?

aaaaaaa.wikipedia.org does not exist

wikipedia.org 1200 NS ns1.wikipedia.org

ns1.wikipedia.org A 6.6.6.6

If this attack succeeds, then any future query for any domain in wikipedia.org will be sent to Eve.

​

If it doesn’t, it doesn’t matter. The cache has not been altered. Just ask on another random subdomain.

DNSSEC

Why DNSSEC?

DNS provides poor security, so DNSSEC was introduced as an alternative, guaranteeing these properties:

• Integrity (not confidentiality) via signatures
• Cache-ability of the signatures
• Extends and remains backwards compatible with DNS

​

DNSSEC

I’m not making DNSSEC slides. Let’s go to https://cs161.org/assets/lectures/lec21_dnssec.pdf

Start at slide 11.

NSEC

• Problem: how to assert a domain DOES NOT exist?
• We could sign: "Domain X does not exist" using our signing key
• But that would require online cryptography ⇒ added latency
• NSEC provides offline authenticated denial to solve this
• Can do all the crypto "in advance"

NSEC

berkeley.edu

berkeley.edu

a.berkeley.edu

ab.berkeley.edu

cd.berkeley.edu

Give me an NSEC for bc.berkeley.edu.

(Prove to me that no such domain bc.berkeley.edu exists.)

ab.berkeley.edu. NSEC cd.berkeley.edu.

ab.berkeley.edu. RRSIG NSEC <signature>

Enumerating NSEC

• [Perceived] Problem with NSEC: it allows an attacker to discover all subdomains of a site
• Keep making requests for invalid domain names, and collect all NSEC records
• Faster than trying to guess valid subdomains and making DNS requests for them
• NSEC3 tries to solve this by using hashes
• Attest that there are no domains whose HASH H falls between H(N) and H(M)
• Not very effective against modern GPUs which can make many hash tries per second

DoS, Firewall, and Detection

​

Denial of Service

• Attack on availability
• Prevents legitimate users from using a service
• DDoS - Distributed Denial of Service is when a server is flooded with traffic from multiple different devices

Denial of Service Techniques

• Deny service using program flaw
• Deny service using resource exhaustion

Problem - Unequal Playing Field

• DoS through network exhaustion - easy to escape detection by using IP spoofing
• Amplification techniques make cost for an attacker low compared to the damage they can cause

Denial of Service Techniques

• DNS Lookup
• The response is typically much larger than the request
• SYN flooding
• Can spoof IP and cause server to maintain TCP state

Denial of Service Mitigation

• Throw money/resources at it
• Ex. Cloudflare
• For SYN flooding specifically, we can use SYN cookies (see lecture 22)
• Isolation and scheduling mechanisms
• OS may do this by killing programs that are taking too much memory

Firewalls

• Way to protect networks cheaply at scale
• For this class, think of firewalls as a set of rules that the network follows (drop or accept packet)

Stateless vs Stateful

• Stateless packet filters examine packets and deny or allow them based on the information in the packet alone
• Stateful packet filters keep track of the connection context of each packet

Firewalls cont.

• Example rule: allow tcp connection 4.5.5.4:* -> 3.1.1.2:80
• Allow any packets associated with tcp connections that start from host at 4.5.5.4 with any port and are connecting to 3.1.1.2 at port 80 (HTTP)
• Example rule: allow tcp connection *:*/int -> *:*/ext
• Allow any packets associated with a tcp connection that originated inside the network
• Example rule: allow tcp connection *:*/ext -> 1.2.2.3:80/int
• Allow any packets associated with a tcp connection that are directed toward our internal HTTP server at 1.2.2.3.

Firewall Disadvantages

• Assumes that insiders are trusted
• Some applications don’t work with firewalls
• May reduce network’s usefulness (a rule that blocks an intended legitimate connection)

Firewall Advantages

• Centralized control of a potentially large network, allowing for added security for many machines
• Attack surface reduction (we specify what is allowed)

Detection

• NIDS - network intrusion detection system
• HIDS - host based intrusion detection system
• Logging - log all activity, (maybe) analyze offline

Base Rate Fallacy

• Don’t take false positive and false negative rates at face value - we need more information to analyze them
• Frequency of attack
• Cost of false positive vs. cost of false negative

Detection Strategies

• Signature based - memorize specific features of an attack
• Behavior based - look for evidence of compromise
• Anomaly based - look for unusual activity
• Learn normal behavior
• Once we have a model of normal behavior, look for deviations from this pattern
• Specification based
• Specify what is allowed
• Eg. decide that all URL parameters sent to foocorp.com servers must have at most one ‘/’ in them

See lecture 25 for more details

End of networking.

​

Cryptography

Cryptography: Symmetric Keys

• Concept
• Encrypting and decrypting use the same key
• Goals
• Confidentiality
• Indistinguishability Under Chosen-Plaintext Attack (IND-CPA)
• A crypto game which has little to do with actually decrypting a message

​

Chosen Plaintext Attack (IND-CPA)

ECB

Why is this bad?

ECB

If P1 = P2, C1 = C2!

Ask challenger to re-encrypt both messages and see which one matches!

AES

Design

Patterns

OTP-like

Examples: OFB, CFB, CTR

Properties:

Plaintext does not need to be padded

Use encryption block on decrypt

Decrypt looks similar to encrypt

*On non OTP-like schemes,

decrypt looks like a mirror image

of encrypt.

Identification:

Plaintext xored with AES output

​

CTR

Identification: Plaintext xored with AES output

​

Properties:

Plaintext does not need to be padded

Use encryption block on decrypt

Decrypt looks similar to encrypt

Feedback

Examples: OFB, CFB, CBC

Properties:

Plaintext feedback:

Decryption not parallelizable

Ciphertext/output feedback:

Encryption not parallelizable

Identification:

Arrow from one block to the next.

​

CBC

Identification:

Arrow from one block to the next.

​

Properties:

Plaintext feedback:

Decryption not parallelizable

Ciphertext/output feedback:

Encryption not parallelizable

IV reuse litmus test

Three source of entropy: key, IV, plaintext

Default:

OTP reuse on entire ciphertext.

Plaintext-incorporated (plaintext or ciphertext) feedback:

OTP reuse only up to but NOT including block containing first difference.

OTP-like:

+ OTP reuse on block containing first difference.

Asymmetric Cryptography

Diffie-Hellman Key Exchange

• Semantically secure: Like IND-CPA except for public key crypto
• g (some group generator) and p (some prime) are public

​

• KeyGen:
• Alice randomly samples a, and sends g^a mod p to Bob
• Bob randomly samples b, and sends g^b mod p to Alice
• Both can compute g^ab mod p, but no one else can!
• How can they do this? Why can no one else?

Public parameters g and p

The secrets a and b

Disguise your secret with the common paint.

g^a mod p, g^b mod p

Add in the missing piece.

(g^a)^b mod p

(g^b)^a mod p

g^ab mod p

Swap disguised secrets.

MITM Diffie-Hellman

• Diffie-Hellman does nothing to stop man-in-the-middle.
• Definition: man-in-the-middle is an attacker who sees all of the communication between Alice and Bob and can change the messages between Alice and Bob.
• How does Alice know she is talking to Bob? No way to tell.
• How does Bob know he is talking to Alice? No way to tell.

ElGamal

• Like Diffie-Hellman, except one side is going to sleep through it.
• g and p public parameters as before.�
• Bob: Generate private key b, public key g^b mod p. Goes to sleep.
• Alice: Generates private key r, public key g^r mod p.
• Alice: Encodes message with secret key: m x (g^b)^r mod p.
• Bob: Wakes up. Decodes with m x (g^b)^r x (g^r)^(-b) mod p.

Hashing / PRNG

Properties of Hash Functions

• One-Way Function
• Easy to find H(x)=y given x. Hard to find x given y=H(x).
• Second Pre-Image Resistant
• Given x and H(x), it is hard to find x’ such that x != x’ and H(x) = H(x’)
• Collision Resistant
• Hard to find ANY x and x’ such that H(x) = H(x’)

Pseudorandom Number Generators

Deterministic way of generating bits which look random (pseudo-random) given some actually random bits

Initialize(entropy): Given some truly random bits "entropy" initializes the internal state of the RNG

Generate(n): Generate n pseudorandom bits

Reseed(entropy): Add more entropy to the PRNG

Properties of pRNG

• Unpredictability
• Rollback resistance
• If attacker knows state of the pRNG (key and counter) at time T, they shouldn’t be able to find out the state at time T-1

End of cryptography.

​

Web Security

What can you do with Javascript?

Change HTML content, images, style of elements, hide elements, unhide elements, change cursor, read and change cookies...

Read cookie with JS:

var x = document.cookie;

Change cookie with JS:

document.cookie = "username=John Smith; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/";

Outer page can specify only sizing and placement of the frame in the outer page.

We can load frames from different websites!

Frame isolation: Outer page cannot change contents of inner page. Inner page cannot change contents of outer page.

This is an important exception to the same-origin policy!

Can Access?

Can Access?

Cookies

Session management is like wristbands...

• First entrance:
• present ticket, ID
• ticket guy hands you a wristband
• Later entrances:
• show your wristband to get in

​

• First request:
• send username, password
• server gives you a session token
• Later requests:
• send the session token with your request

Cookies are also like wristbands...

• The server sets cookies according to cookie policy
• Like distributing wristbands�
• The browser sends cookies according to cookie policy
• Like showing a wristband at the entrance

URL breakdown

https://box.unicornbox.com/files/evanbot/doodle-ai.go

URL breakdown

https://box.unicornbox.com/files/evanbot/doodle-ai.go

When breaking down a URL, make a split at the double-slash...

then another split at the first slash after that.

URL breakdown

https://box.unicornbox.com/files/evanbot/doodle-ai.go

Part 1: Protocol

• Look for it before the double slash
• Tells us if we use HTTP or HTTPS

URL breakdown

https://box.unicornbox.com/files/evanbot/doodle-ai.go

Part 2: Domain

• Look for it between the double-slash and the first single slash
• Tells us which web server to contact (using DNS)

URL breakdown

https://box.unicornbox.com/files/evanbot/doodle-ai.go

Part 3: Path

• Everything after the first single slash
• Tells the web server what to show you

Cookie policy

Use setting rules if the server is setting the cookie (handing out a wristband).

Use sending rules if the browser is sending the cookie (showing a wristband).

Use domain rules on the domain part of the URL.

Use path rules on the path part of the URL.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y = admin.box.unicornbox.com

​

X ends in Y? False. Cookie is not set.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y = box.unicornbox.com

​

X ends in Y? True. Cookie is set.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y = evanbot.unicornbox.com

​

X ends in Y? False. Cookie is not set.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y = unicornbox.com

​

X ends in Y? True. Cookie is set.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y = cornbox.com

​

X ends in Y? False. Cookie is not set.

​

Note that “ends with” is domain matching, not string matching. Everything between the dots must match.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y =

​

X ends in Y? True. Cookie is set.

Cookie policy rule 1

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the domain part of the URL.

X can set a cookie with domain Y if X ends with Y and Y is not a TLD.

​

X = box.unicornbox.com

Y = .com

​

X ends in Y? True. But cookie is not set due to exception.

​

TLDs include: .com, .org, .edu.

Cookie policy rule 2

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the path part of the URL.

X can set a cookie with path Y always.

​

X = box.unicornbox.com

Y = /files

​

Always? Always. Cookie is set.

Cookie policy rule 2

This rule is for servers setting cookies (handing out wristbands).

This rule applies to the path part of the URL.

X can set a cookie with path Y always.

​

X = box.unicornbox.com

Y = /

​

Always? Always. Cookie is set.

Cookie policy rule 3

This rule is for browsers sending cookies (showing wristbands).

This rule applies to the domain part of the URL.

Browser sends X a cookie with domain Y if X ends with Y.

​

X = https://box.unicornbox.com/files/evanbot/doodle-ai.go

Y = unicornbox.com

​

X ends in Y? True. Cookie is sent.

Cookie policy rule 4

This rule is for browsers sending cookies (showing wristbands).

This rule applies to the path part of the URL.

Browser sends X a cookie with path Y if X begins with Y.

​

X = https://box.unicornbox.com/files/evanbot/doodle-ai.go

Y = /files/evanbot

​

X begins with Y? True. Cookie is sent.

Cookie policy rule 3-4 shortcut

To determine if a cookie is sent, I like to use this matching trick combining rules 3-4.

https://box.unicornbox.com/files/evanbot/doodle-ai.go

​

unicornbox.com/files/evanbot

(domain)

Concatenate the cookie domain and path. Line it up below the requested URL at the first single slash.

(path)

Cookie policy rule 3-4 shortcut

To determine if a cookie is sent, I like to use this matching trick combining rules 3-4.

https://box.unicornbox.com/files/evanbot/doodle-ai.go

​

unicornbox.com/files/evanbot

(domain)

Can you get everything to match? If yes, cookie is sent.

(path)

Cookie policy rule 3-4 shortcut

To determine if a cookie is sent, I like to use this matching trick combining rules 3-4.

https://box.unicornbox.com/files/evanbot/doodle-ai.go

​

unicornbox.com/files/admin

(domain)

Can you get everything to match? If no, cookie is not sent.

(path)

Cookie policy rule 3-4 shortcut

To determine if a cookie is sent, I like to use this matching trick combining rules 3-4.

https://box.unicornbox.com/files/evanbot/doodle-ai.go

​

cornbox.com/files/evanbot

(domain)

Can you get everything to match? If no, cookie is not sent.

(path)

Cookie policy: in summary

• Rule 1: X can set a cookie with domain Y if X ends with Y and Y is not a TLD.
• Rule 2: X can set a cookie with path Y always.
• Rules 3-4: Write out domain+path underneath URL. If everything matches, the cookie gets sent to URL.

Cookies

• Cookies are name-value pairs.
• There are cookie flags:
• Domain: which domain this cookie is for (viz., www.google.com/foo/bar)
• Path: which path this cookie is for (viz., www.google.com/foo/bar)
• secure: indicates the browser should only send this cookie via HTTPS
• HttpOnly: indicates the browser should stop accesses to this cookie through Javascript
• Beware: Cookie policy =/= same-origin policy

A web server on foo.example.com tries to set a cookie with the following domains. Will the cookie be set? If so, which domains will receive the cookie? (Some rows are filled in as examples.)

A web server on foo.example.com tries to set a cookie with the following domains. Will the cookie be set? If so, which domains will receive the cookie? (Some rows are filled in as examples.)

​

SQL Injection

SQL injection step 1: what does the SQL interpreter see?

SQL injection step 1: what does the SQL interpreter see?

> INSERT INTO cart (session, item)� VALUES ('____________', '____________')

​

sessionToken item

SQL injection step 2: what do we want the SQL interpreter to see?

SQL injection step 2: what do we want the SQL interpreter to see?

> INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

SQL injection step 3: compare

The SQL interpreter sees:

​

> INSERT INTO cart (session, item)� VALUES ('____________', '____________')

​

sessionToken item

​

We want the SQL interpreter to see:�

> INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

SQL injection step 3: compare

The SQL interpreter sees:

​

> INSERT INTO cart (session, item)� VALUES ('____________', '____________')

​

sessionToken item

​

We want the SQL interpreter to see:�

> INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

SQL injection step 4: ??? step 5: profit

The SQL interpreter sees:

​

> INSERT INTO cart (session, item)� VALUES ('____________', '____________')

​

sessionToken item

​

We want the SQL interpreter to see:�

> INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

​

sessionToken = 123

item = toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper

Prepared statements: the previous attack no longer works

We can’t do injection in sessionToken

SQL injection step 1: what does the SQL interpreter see?

> INSERT INTO cart (session, item) VALUES ('____________', '____')

​

sessionToken item

​

> SELECT item FROM cart WHERE session = '____________' LIMIT 1

​

sessionToken

​

> SELECT link FROM items WHERE item = '_______'

item

The third query is the vulnerable one, but the first query is where the malicious input happens

SQL injection step 2: what do we want the SQL interpreter to see?

The SQL interpreter sees:

> SELECT link FROM items WHERE item = '_______'

item

​

We want the SQL interpreter to see:�

�> INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

SQL injection step 3: compare

The SQL interpreter sees:

> SELECT link FROM items WHERE item = '_______'

item

​

We want the SQL interpreter to see:�

�> INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

Problem: the queries don’t match at the beginning

SQL injection step 3: compare

The SQL interpreter sees:

> SELECT link FROM items WHERE item = '_______'

item

​

We want the SQL interpreter to see:�

> SELECT link FROM items WHERE item = 'whatever';� INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

Solution: Add a dummy query to force the queries to match

SQL injection step 3: compare

The SQL interpreter sees:

> SELECT link FROM items WHERE item = '_______'

item

​

We want the SQL interpreter to see:�

> SELECT link FROM items WHERE item = 'whatever';� INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper')

Problem: the endings don’t match

SQL injection step 3: compare

The SQL interpreter sees:

> SELECT link FROM items WHERE item = '_______'

item

​

We want the SQL interpreter to see:�

> SELECT link FROM items WHERE item = 'whatever';� INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper') --'

Solution: use comments to force a match

SQL injection step 4: ??? step 5: profit

The SQL interpreter sees:

> SELECT link FROM items WHERE item = '_______'

item

​

We want the SQL interpreter to see:�

> SELECT link FROM items WHERE item = 'whatever';� INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper') --'

​

item = whatever';� INSERT INTO cart (session, item)� VALUES ('123', 'toilet paper'), ('123', 'toilet paper'),

('123', 'toilet paper'), ... ('123', 'toilet paper') --

Cross-Site Scripting (XSS)

• Attacker inserts malicious script into another site's webpage that will be viewed by a user.
• Script runs in user's browser and bypasses same-origin policy!
• For example, if there was an XSS in Piazza, an attacker could make a user run Javascript as if Piazza had sent it
• Since Javascript is very powerful, this can perform actions as the victim user

Two types of XSS

Stored XSS:

• Attacker leaves Javascript lying around on a benign web service for victim to load
• Think: Facebook Wall Post.
• Attacker makes a post like <script>alert(1)</script>
• IF the site does not escape HTML before showing it back to the user, then this could be a stored XSS.

Reflected XSS:

• Attacker gets user to load a specially-crafted URL with Javascript encoded in the URL
• Think: Google's search results
• To search: google.com/?query=X
• Outputs "No results for X."
• Parts of URL appear in output
• IF Google did not do the proper escaping, then this could be a reflected XSS!

End of web security.

​

Good Luck!