Message Processing

As usual in our model, all actions of the web browser atomic Dolev-Yao process need to be triggered by an incoming message. The only “entry point” into the web browser is the algorithm outlined in the following (see Algorithm A.11for details). Figure 2.4provides an overview of the structure of this algorithm.

If the browser is corrupted, i.e., isCorrupted 6= ⊥, it acts as an attacker process: it simply adds the input message m to its current state (i.e., knowledge) and then nondeterministically outputs an event derivable from its state. More formally, when a corrupted browser in the state s receives a message m for the browser’s IP address a, the browser adds m to the subterm 11_{A Strict-Transport-Security header also contains a lifetime in seconds. After the lifetime has expired, the}

browser will remove the domain from the STS list if no new Strict-Transport-Security header was received in the meantime. This lifetime is not reflected in our model.

Processing Input Message mmm

m = FULLCORRUPTm = FULLCORRUPTm = FULLCORRUPT: Set isCorrupted := FULLCORRUPT.

m = LIMITEDCORRUPTm = LIMITEDCORRUPTm = LIMITEDCORRUPT: Clean secrets, windows, cookies, storage, set isCorrupted := LIMITEDCORRUPT. m = TRIGGERm = TRIGGERm = TRIGGER: nondeterministically choose action:

actionactionaction is script: Call script of some active document. Outputs new state and command cmd . cmd = HREFcmd = HREFcmd = HREF: Initiate HTTP(S) request to URL in link.

cmd = IFRAMEcmd = IFRAMEcmd = IFRAME: Create subwindow, initiate request to load URL into iframe. cmd = FORMcmd = FORMcmd = FORM: Initiate HTTP(S) GET/POST request to given URL with form data. cmd = SETSCRIPTcmd = SETSCRIPTcmd = SETSCRIPT: Change script in given document.

cmd = SETSCRIPTSTATEcmd = SETSCRIPTSTATEcmd = SETSCRIPTSTATE: Change state of script in given document. cmd = XMLHTTPREQUESTcmd = XMLHTTPREQUESTcmd = XMLHTTPREQUEST: Initiate XMLHttpRequest.

cmd = BACKcmd = BACKcmd = BACK or FORWARDFORWARDFORWARD: Navigate given window. cmd = CLOSEcmd = CLOSEcmd = CLOSE: Close given window.

cmd = POSTMESSAGEcmd = POSTMESSAGEcmd = POSTMESSAGE: Send postMessage to specified document.

cmd = WS OPENcmd = WS OPENcmd = WS OPEN: Initiate HTTP(S) request to create new WebSocket connection. cmd = WS SENDcmd = WS SENDcmd = WS SEND: Send WebSocket message over established WebSocket connection. cmd = RTC CREATE PEERCONNECTIONcmd = RTC CREATE PEERCONNECTIONcmd = RTC CREATE PEERCONNECTION: Create a new WebRTC connection object. cmd = RTC GET OFFERcmd = RTC GET OFFERcmd = RTC GET OFFER: Create and return WebRTC offer document.

cmd = RTC SET REMOTEcmd = RTC SET REMOTEcmd = RTC SET REMOTE: Consume remote WebRTC offer.

cmd = RTC GET IA INFOcmd = RTC GET IA INFOcmd = RTC GET IA INFO: Return information needed for identity assertion. cmd = RTC SET IAcmd = RTC SET IAcmd = RTC SET IA: Store the local identity assertion in WebRTC connection.

cmd = RTC GET CHECK IA INFOcmd = RTC GET CHECK IA INFOcmd = RTC GET CHECK IA INFO: Return information to check remote identity assertion against. cmd = RTC CHECKED IAcmd = RTC CHECKED IAcmd = RTC CHECKED IA: Set flag that remote identity assertion was checked.

cmd = RTC SENDcmd = RTC SENDcmd = RTC SEND: Send WebRTC message over established WebRTC connection. actionactionaction is urlbar: Initiate request to some URL in new window.

actionactionaction is reload: Reload some document.

actionactionaction is forward: Navigate some window forward. actionactionaction is back: Navigate some window back.

mmm is a DNS response: Send HTTP(S) request that was waiting for DNS resolution.

mmm is a HTTP(S) response: (Decrypt m,) handle headers (Set-Cookie, Location, etc.), find reference: reference to window: Create document in window.

reference to document: Add response body to document’s script input. reference to websocket: Finish WebSocket connection setup.

mmm is a WebSocket message: (Decrypt m,) find WebSocket connection, deliver data to respective document.

mmm is a WebRTC message: Find WebRTC connection, decrypt data, deliver data to respective docu- ment.

Figure 2.4. The basic structure of the web browser relation Rp_{with an extract of the most important}

processing steps, in the case that the browser is not already corrupted. Includes the WebRTC extensions presented in Section2.12.

pendingRequests of its state.12 The browser is now in a new state, say s0. It then creates and sends an event ha0, a, m0i with the receiver address a0 being a nondeterministically chosen IP address, the sender address being a, and the message m chosen nondeterministically from d(s0).

If the browser is not corrupted, the input message m is expected to be one of the special messages TRIGGER, FULLCORRUPT, LIMITEDCORRUPT, an HTTP(S) response, a DNS response, a WebSocket message, or a WebRTC message. Other types of messages are discarded without any change in the browser’s state. The browser will then act as follows:

m = TRIGGERm = TRIGGERm = TRIGGER. Upon receipt of this message, the browser nondeterministically chooses one of five actions:

Action is scriptscriptscript: Some active (sub)window is chosen nondeterministically. Then the script of the active document of that window is triggered, as described in the next subsection.

Action is urlbarurlbarurlbar: A new HTTP(S) GET request (i.e., an HTTP(S) request with method GET) is created where the URL is some message derivable from the current state of the browser. However, nonces may not be used. This models the user typing in a URL herself, but we do not allow her to use secrets in the URL, e.g., passwords or session tokens. Otherwise, the attacker would trivially learn all of the user’s secrets. A new window is created to show the response.

Action is reloadreloadreload: Some active (sub)window is chosen nondeterministically and the document in that window is reloaded.

Action is forwardforwardforward or backbackback: Some active window or subwindow is chosen nondeterministically and navigated forward or back, respectively (cf. Section2.10.3).

m = FULLCORRUPTm = FULLCORRUPTm = FULLCORRUPT. If the browser receives this message, it sets isCorrupted to FULLCORRUPT. From then on the browser is corrupted as described above. Unlike for limited corruption (see next paragraph), the state of the browser is not cleared when this command is received. This means that the attacker gains full access to the browser’s internal state, including all secrets. m = LIMITEDCORRUPTm = LIMITEDCORRUPTm = LIMITEDCORRUPT. If the browser receives this message, it first removes the user secrets, open windows and documents, all session cookies, all sessionStorage data, and all pending DNS/HTTP(S) requests from its current state. LocalStorage data and persistent cookies are not deleted. The browser then sets isCorrupted to LIMITEDCORRUPT (and hence, from then on is corrupted). As mentioned in Section 2.10.2, this models that the browser is closed by a user and that then the browser is used by another, potentially malicious user (an attacker), such as in an Internet caf´e.

mmm is a DNS response. When a DNS response is received (and its nonce is contained in pendingDNS ), this means that there is an HTTP(S) request waiting for this response (recall Section2.10.5 above). Therefore, the corresponding HTTP(S) request will be dispatched. mmm is a HTTP(S) response. The browser performs the following steps:

(I) The browser identifies the corresponding HTTP(S) request q (if any) and the window or document from which q originated using the data recorded in pendingRequests. If q was an encrypted HTTPS request, m is decrypted using the symmetric key recorded together with q in pendingRequests.

(II) If there is a Set-Cookie header in the response, its contents are evaluated: The cookie’s name, value, and attributes (httpOnly, secure, session) are saved in the browser’s list

of cookies. If a cookie with the same name already exists, the old values and attributes are overwritten, as specified in [RFC6265].

(III) If there is a Strict-Transport-Security header in the response, the domain of q is added to the term sts. As defined in [RFC6797], all future requests to this domain, if not already HTTPS requests, are automatically modified to use HTTPS. This includes requests made by the user (urlbar action above.)

(IV) If there is a Location header (with some URL u) in the response and the HTTP status code is 303 or 307, the browser re-sends the original request to the URL u (unless the original request was an XMLHttpRequest and u does not have the same origin as the initial request’s URL, in which case the browser aborts). In line with [RFC7231], if the status code is 307, the browser retains the original request method and body in the redirected request. For 303, if the original request’s method is not GET or HEAD, the browser will change the method to GET and discard the request body. The Origin header value is replaced by a null value (⊥) as defined in the W3C Cross-Origin Resource Sharing specification [Ann14].

(V) Otherwise, if no redirection is requested, the browser does the following:

a) If the request originated from a window, a new document is created from the response body. For this, the response body is expected to be a term of the form hscript , statei where script is the name of a script and state is a term used as the script’s initial state. The document is then added to the window the reference points to, it becomes the active document, and the successor of the currently active document. All previously existing successors are removed.

b) If the request originated from a document (and hence, was the result of an XML- HttpRequest), the body of the response is appended to the script input term of the document. When later the script of this document is activated, it can read and process the response.

c) If the message is a response to a WebSocket connection establishment message, the browser expects a status code of 101 and an Upgrade header just as in the request. If this is the case, the browser stores the nonce and symmetric encryption key (if any) used in the HTTP messages for future use in the WebSocket connection in its local state subterm wsConnections.

mmm is a WebSocket message. To handle an incoming WebSocket message, the browser checks its list of open WebSocket connections for an entry matching the nonce (and possibly the encryption key) in the WebSocket message and adds the data contained in the WebSocket message to the script inputs of the script that initiated the connection.