🏆Capstone project: Project: CORS on Both Sides

The front end can now do its whole job, in four requests:

1. POST /tokens with credentials, to get a token for ana’s session.

2. GET /books with the token, after a preflight.

3. PUT /books/1 with the token and a JSON body, after a preflight.

4. GET /me with credentials, to show who is logged in.

Nothing yet says what a page on another origin cannot do. This project writes those tests, and it moves the server’s CORS answer to one place.

Four tests

All four go into tests/test_attacks.py. Three of them start the same way, with ana logged in through the reading list’s own page:

    state = steps.keyed_state()
    jar = []
    send = ana_logs_in(state, jar)

After that, a page’s request is visit.visit(page_origin, wanted, jar, send), and result["response"] is what the page’s script may read, or None.

test_the_front_end_can_work plays the four requests above from steps.APP and asserts on what the page read each time: a token, a status of 200, two books, the user ana.

test_attack_another_origin_cannot_read_the_list fetches /books with ana’s token, and /me with credentials, from steps.NOTES and from steps.OTHER. Every response must be None. First it asserts that the same fetch of /books works from steps.APP, so that the test cannot pass against a server on which nobody can read.

test_attack_another_origin_cannot_get_a_token sends the POST /tokens of Lesson 5 from the two other origins. The page reads nothing, and that alone proves too little: a server could make a token and merely not show it. A page never sees an answer it may not read. A test may:

    result = visit.visit(steps.NOTES, wanted, jar, send)
    assert result["response"] is None
    assert "token" not in helpers.json_of(send(result["requests"][0]))

test_cors_does_not_stop_a_plain_client uses no browser at all. It hands GET /books with a token and no Origin header straight to reading_server.handle and asserts 200 and two books.

The tests pass as soon as you write them, because Lesson 5 left the server correct. See two of them fail once. Put return True as the first line of origin_allowed, or take and values[0] in trusted out of cors_headers, and run:

python -m pytest -q -k another_origin

Each edit gives 1 failed, 2 passed: the token test for the first, the list test for the second. Undo both. Check my work does the same with servers of its own that each make one mistake.

One place

Five lines in five branches now add the CORS answer, and some responses miss theirs. Ask for /about twice from the front end, the second time with the etag of the first answer:

python -c "
import sys
sys.path.insert(0, 'tests')
import helpers, reading_server
state = reading_server.sample_state()
headers = {'Origin': 'https://app.reading.example'}
first = reading_server.handle(helpers.make_request('GET', '/about', headers=headers), state)
headers['If-None-Match'] = first['headers']['etag']
again = reading_server.handle(helpers.make_request('GET', '/about', headers=headers), state)
print(again['status'], list(again['headers']))
"

It prints 304 ['etag', 'cache-control']. not_modified() copies those two headers and drops the rest, vary among them. A 304 must carry the Vary that its 200 would have carried, so that a cache keeps one origin’s answer apart from another’s.

The remedy is the one of Chapter 8’s project: one place. cors_rule(segments) names the answer a path gets:

Then one block in route(), after the lines that replace a 200 with a 304 and before the no-store rule, applies it:

    rule = cors_rule(segments)
    if rule is not None:
        extra = cors_headers(request, state["trusted_origins"], credentials=rule == "session")
        for name in extra:
            response["headers"][name] = extra[name]

Remove the five add_headers lines of Lessons 2 to 5. Every response that reaches this block now leaves with the same answer: the 304, a 404, a 405, and the 401 for a missing token, which the front end can now read and explain to its user. One response of a CORS route never reaches it: the 403 of the Origin check on POST /tokens returns from the first lines of route(). It goes to an origin outside the set, or to a request without an Origin header, and neither would get a permission anyway. A path that gets None gets no CORS header at all. Run the python -c line again: the list ends in 'vary', 'access-control-allow-origin'.

What CORS did not do

Run python pl_sec.py cors and read its last request:

--- a client that is not a browser: GET /books with the token and no Origin header ---
  your server answered 200
        access-control-allow-origin: (not sent)
        vary: Origin
  books in the answer: 2. This client never looks at a CORS header.

Every Access-Control- header is addressed to a browser. Without them, a browser shows a page nothing from a simple request and never sends one that needs a preflight. That is real, and it is the browser’s doing. A client that is not a browser ignores all of it.

So CORS is not access control. It never stops a client that is not a browser. What protects the server is what you built before this chapter: the token check, the owner check, the Origin check, and the form token.

Milestones

1. The four tests, two of them seen failing once. python -m pytest -q ends with 41 passed.

2. cors_rule and the block, with the five old lines gone. Still 41 passed.

3. python pl_sec.py cors: the front end read 4 of 4 responses; pages on other origins read 0 of 4.

4. Row F12 of SECURITY.md, extended in your own words for the reading half. It names the two new attack tests beside the four it has, and says closed in 9.6.

One step is not graded. The supplied cors_compare.py sends five requests to your handle() and to Starlette’s CORSMiddleware, a ready-made CORS answer from a Python web toolkit, inside one program, and prints both answers side by side. Differences are expected and are not errors in your code. Where Starlette is not installed, the file says so in one line and stops.

The model does not hide response headers from a page. A browser shows a script on another origin only Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma, and whatever the server lists in Access-Control-Expose-Headers. Your tests read only bodies and statuses.

Every promise this service makes so far, from the Secure cookie to the origin of a page, assumes HTTPS. Chapter 10 looks at what that assumption rests on.

Then press Check my work.