Educación

0

1: let domain, n such that hDNSResolve, domain, ni ≡ m if possible; otherwise stop hi, sd 0

2: if domain ∈ sd 0 then

3: let addr := sd

0[domain]

4: let m0 := hDNSResolved, domain, addr , ni

5: stop hhf, a, m0ii, sd 0

6: stop hi, sd₀

2.10. Web Browsers

Web browsers are the most complex entity defined in the WIM. The detailed model captures many important parts of the behavior of real-world web browsers.

A web browser b is an atomic Dolev-Yao processes (Ib, Zwebbrowser, Rwebbrowser, s0b). The

relation Rwebbrowser modeling the behavior of browsers is defined by AlgorithmsA.1–A.11in the

appendix. The states Zwebbrowser are of the form

hwindows, ids, secrets, cookies, localStorage, sessionStorage, keyMapping, sts, DNSaddress, pendingDNS , pendingRequests, wsConnections, rtcConnections, isCorrupted i .

We will introduce the individual subterms of browser states over the next sections and give examples for concrete values.

2.10.1. Browsers and Users

We think of a browser to be used by one honest user—as long as the browser has not been corrupted by an attacker, see below. The user is a part of the browser model. Actions a user takes are modeled as nondeterministic actions of the web browser. For example, the web browser can spontaneously open new windows (tabs) and access random URIs. A browser randomly follows links in a document—here modeled as nondeterministic actions of the script that represents the document.

A browser’s initial state contains, in the subterm ids, user secrets and user identities. A browser can have multiple user identities, public information such as email addresses that is accessible to any script. For example, if a browser is set up with the two identities

ids = [email protected], [email protected] ,

then a login script can use either of these identities to log the user into some web site.

User secrets, such as passwords, are stored in the browser state subterm secrets indexed by origins and are only released to documents (scripts) with the corresponding origins.4 For example, if the initial state of a browser contains a mapping of the form

secrets = [hexample.com, Si:n5, hexample.com, Pi:n6]

then scripts loaded from the origin https://example.com (S for secure) would have access to the nonce (secret) n5, and scripts loaded from the origin http://example.com (P for plain)

would have access to n6.

2.10.2. Two Types of Corruption

We also allow browsers to be taken over by attackers (dynamic corruption). In the real world, an attacker can exploit buffer overflows in web browsers, compromise operating systems, and physically take control over shared terminals. We model two types of corruption of browsers, namely full corruption and limited corruption, which are triggered by special network messages. Full corruption models an attacker that gained full control over a web browser and its user. More precisely, the attacker gains access to all data, including secrets, stored in the browser, and can use the browser’s IP address to send and receive arbitrary messages. Besides modeling a compromised operating system, full corruption can also serve as a vehicle for the attacker to participate in a protocol using secrets of honest browsers: Typically, in a concrete analysis, an attacker starts with no user secrets in its knowledge, but may fully corrupt any number of browsers and by this impersonate browsers/users.

Limited corruption models a browser that is taken over by the attacker after a user finished 4_{Since user secrets are restricted to certain origins, user identities and user secrets are not stored in the same}

data structure in the browser, i.e., there is no mapping from identities to secrets. A script can, however, non-deterministically select the correct secret for any identity.

her browsing session, i.e., after closing all windows of the browser. This form of corruption is relevant in situations where one browser can be used by many people, e.g., in an Internet caf´e. Limited corruption removes from the browser’s state all open documents, pending requests, user secrets, session storage, and session cookies before the attacker takes control over the browser. Non-session cookies and localStorage information (see Section2.10.4) is left intact and can be misused by the attacker.

Whether or not a browser is corrupted is stored in the browser state subterm isCorrupted . By default, a browser is honest, i.e., we have isCorrupted = ⊥. Otherwise, we have that isCorrupted = FULLCORRUPT or isCorrupted = LIMITEDCORRUPT. In Section 2.10.9 we describe in more detail how a browser becomes corrupted and how a corrupted browser behaves. A browser, once corrupted, can never become honest again.

2.10.3. Windows and Documents

A browser may have a number of windows open at any time (representing the tabs in a real browser). The browser state subterm windows contains a list of windows opened in a web browser. Roughly speaking, documents in these windows and iframes are represented as subterms of windows.

More precisely, each window contains a list of documents of which one is “active”. Being active means that this document is currently presented to the user and is available for interaction, similarly to the definition of active documents in the HTML5 specification [Ber+17]. The document list of a window represents the history of visited web pages in that window. A window may be navigated forward and backward (modeling forward and back buttons). This deactivates one document and activates its successor or predecessor.

Documents may contain subwindows, which correspond to iframes in real-world browsers, that may again contain other documents, and so on, effectively creating a forest of windows and trees. This structure induces a notion of a top-level window (a window which is not a subwindow), parent window (the window of which the current window is a direct subwindow) and ancestor window (some window of which the current window is a not necessarily direct subwindow) to describe the relationships in a tree of windows and documents.

A document inside a window is specified by a term which essentially contains the name of a script, the current state of the script, the input that the script obtained so far (from XML- HttpRequests, postMessages, WebRTC, and WebSocket messages), the origin of the document, and a list of subwindows.

A term describing a window or a document also contains a unique nonce, which we refer to by document/window reference. These references are used to match HTTP responses to the corresponding windows and documents from which they originate.5

Top-level windows may have been opened by another window. In this case, the term of 5

We use references in several places. Some references are visible outside of the process using it, like the references in HTTP messages described above, while others stay internal to a process, like document references.

the opened window contains a reference to the window by which it was opened (the opener ). Following the HTML5 standard, we call such a window an auxiliary window. Auxiliary windows are always top-level windows.

We call a window active if it is a top-level window or if it is a subwindow of an active document in an active window. The active documents in all active windows are exactly those documents a user can currently see/interact with in the browser.

The following is a slightly simplified6 example of a list of windows containing a single window term carrying the window reference n7, two documents identified by their document references

n8 and n9, and a window reference to an opener (n10):

windows = hhn7,hhn8, hexample.com, Pi, SCRIPT LOGIN, hcsrf, n3i, hi, hi, ⊥i,

hn9, hexample.com, Si, SCRIPT HOME, hi, hi, hi, >ii, n10ii .

The first document (reference n8) was loaded from the origin hexample.com, Pi, which translates

into http://example.com. Its script is SCRIPT LOGIN, the script state is hcsrf, n3i, and the

input history of this script is empty. The document does not have subwindows and is inactive (⊥). The second document (reference n9) was loaded from https://example.com, the script is

SCRIPT HOME, the script state is empty, there are no subwindows, and the document is active (>).

2.10.4. Cookies and Web Storage

The browser model supports two mechanisms that allow web sites to persist data in the user’s browser: Cookies and Web Storage.

Cookies

Cookies are name-value pairs that can be set either by scripts, or by web servers using the Set-Cookie header in a response. Once a browser has received a cookie, it will automatically add the cookie (in a Cookie header) to HTTP(S) requests to the domain from which it received the cookie.

Browsers store cookies per-domain and together with their attributes secure, httpOnly, and an expiration time. If secure is set, the cookie is only delivered to HTTPS origins. If httpOnly is set, the cookie cannot be accessed by JavaScript. The expiration time is optional: If it is not set, the cookie should be deleted by the browser when the user session ends, i.e., when the browser is closed. Otherwise, the cookie is kept in the browser until the expiration time is reached.7

6

For brevity of presentation we omitted from the document term the full URL and the headers. See Definition41

for details.

7_{Real-world browsers actually know two different attributes to determine the expiration time: “max-age” defines}

the maximum lifetime of the cookie in seconds, “expires” defines a concrete date and time on which the cookie will be deleted.

A cookie is, in our model, represented as a term of the form

hname, hvalue, secure, session, httpOnlyii .

The attributes secure, session, and httpOnly can either be > (true) or ⊥ (false). If the session attribute is >, the cookie is deleted when the browser is closed (this is only relevant for corruption, see Section 2.10.9). Otherwise, since the model does not have a notion of time, cookies are kept forever or until they are overwritten by a cookie of the same name.

An example for a server setting a cookie can be seen in the response resp in Section2.8above. Browsers store cookies in the subterm cookies of their state. The browser receiving resp would store the following subterm:

cookies = [example.com:[SID:hn2, ⊥, >, ⊥i] = hhexample.com, hhSID, hn2, ⊥, >, ⊥iiiii .

In a request, say, req0 that follows resp, the browser would then include the cookie’s name and value (the attributes are not transferred to the server):

req0 := hHTTPReq, n11, GET, example.com, /anything, hi, [Cookie:[SID:n2]], hii .

Web Storage

Web Storage is an API with a similar purpose as cookies, but with two major differences: First, WebStorage can only be accessed by JavaScript. Second, WebStorage is designed to handle much more data than cookies, which traditionally are limited to about 4 kilobytes of data. Web Storage offers two different kinds of storage: localStorage and sessionStorage. LocalStorage data is separated by origins, i.e., any script loaded from the same origin shares the same localStorage data set, but scripts cannot access other origin’s localStorage data. SessionStorage is additionally indexed by top-level windows, i.e., two windows need to share the same origin and same top-level window in order to access the same sessionStorage data set.

Our implementation of Web Storage is straightforward: Scripts receive from the browser the localStorage and sessionStorage data sets accessible to them. This data is represented as arbitrary terms. The scripts can alter both terms and then output the new values for localStorage and sessionStorage. Browsers store the data, indexed by origin or by origin and top-level window nonce, in their state’s subterm localStorage and sessionStorage, respectively.

For example, assume that a script from example.com stored strings in each localStorage and sessionStorage and the top-level window of the window in which the script runs has the window nonce n7. Then, the two subterms of the browser state would contain the following data:

localStorage = [example.com:foo] sessionStorage = [hexample.com, n7i:bar]

2.10.5. HTTP(S) Message Dispatching

We now take a closer look at the two steps needed for browsers to send an HTTP request. In Section2.10.9, we will then see how browsers handle incoming messages.

First, recall that every HTTP(S) request contains a nonce created by the browser. A server is supposed to include this nonce into its HTTP response. By this, the browser can match the response to the request (a real web browser would use the TCP sequence number and port number for this purpose).

Browsers can send HTTP(S) requests

– “spontaneously” by nondeterministically reloading some document or by navigating to some URI (both of which can happen at any time),

– triggered by a Location header redirection (i.e., in response to an incoming HTTP re- sponse),

– or triggered by a script that follows a link, opens a new iframe, submits a form, sends an XMLHttpRequest, or tries to establish a WebSocket connection (one of the script commands HREF, IFRAME, FORM, XMLHTTPREQUEST, or WS OPEN, described in more detail in Section2.10.9).8

In all of these cases, the browser first resolves the domain name to an IP address.

Step 1: DNS Resolution

To this end, the browser first records the HTTP request in a subterm of its state called pendingDNS along with the original URL for the request and a reference:

– In the case of HTTP(S) requests, the reference is the constant string REQ plus the window reference of the window from which the request originated.

– In the case of XMLHttpRequests, the reference is a sequence of three elements, the constant string XHR, the document reference of the document from which the request originated, and a term (usually a fresh nonce) that was chosen by the script that issued the XMLHttpRequest. This enables the script to have multiple XMLHttpRequests running in parallel.

– In the case of WebSocket connections, the reference is of the same form as in the previous case, except the first element is now the constant string WS.

For example, let req0 be an HTTP request as above, url be the URL9 of req0, n7 be the window

from which the request originated, and n4 the nonce chosen by the browser for the DNS request

8

An HTTP request can also be triggered when a WebRTC proxy script is loaded, see Section2.12.

(as in the example in Section2.9). Until the DNS resolution for req0finishes, pendingDNS would be of the form

pendingDNS = [n4:hhREQ, n7i, req0, url i] .

The browser then sends the DNS request required to resolve the domain name into an IP address.

Step 2: Dispatching the HTTP Request

After receiving the corresponding DNS response, the browser sends the HTTP request and stores it (along with the window/document reference, the original url, and the resolved IP address) in pendingRequests. Before sending the HTTP request, the cookies stored in the browser for the domain of the request are added as Cookie headers to the request. (Cookies with attribute secure are only added for HTTPS requests.) The browser also checks if the domain of the request is contained in the browser’s list of strict transport security domains, and, if that is the case, rewrites the request from HTTP to HTTPS (see below).

In our example, assuming that example.com was resolved into the IP address addr , the browser state subterm pendingDNS would then be of the following form (see below for the meaning of ⊥ in this term):

pendingRequests = hhhREQ, n7i, req0, url , ⊥, addr ii .

As we see below in more detail, when an HTTP response arrives, the browser uses the nonce in this response to match it with the corresponding HTTP request (if any is recorded) and checks whether the address of the sender is as expected. The reference recorded along with the request then determines to which window/document the response belongs.

HTTPS Requests

For HTTPS requests, a fresh symmetric key (a nonce) is generated and added to the request by the browser before the request is sent. The resulting message is then encrypted using the public key corresponding to the domain in the request. The symmetric key is recorded along with the request in pendingRequests. If, for example, the key n12 was chosen, pendingRequests

would look like this:

pendingRequests = hhhREQ, n7i, req0, url , n12, addr ii .

The response is, as mentioned above, supposed to be encrypted with the symmetric key n12.

2.10.6. WebSockets

WebSockets enable real-time bidirectional communication between JavaScript (in a browser) and a server. On a high level, WebSockets work as follows: First, the WebSocket protocol, which is always initiated by the client-side JavaScript, starts as a regular HTTP(S) request in

which the browser indicates that it wants to create a WebSocket connection. The server, if it supports WebSockets, then agrees to this upgrade in the HTTP(S) response. From then on, server and browser can, at any time, send WebSocket messages containing arbitrary data over the TCP connection used for the HTTP(S) request and response, which is kept open. When a browser receives a WebSocket message, its contents are delivered to the script that started the connection.

The WebSocket protocol is defined in [RFC6455], but we do not need to introduce all details here. The important details of the protocols are captured in our model of WebSockets, which we delineate in the following.

In the WIM, scripts in a browser can issue the command WS OPEN to create a new WebSocket connection to some URL. Just as in the model for XMLHttpRequests, the script identifies this connection using a freely chosen reference, the WebSocket reference.

To create the requested WebSocket connection, the browser first (just as in a real-world browser) sends a regular HTTP(S) request. In this request, the browser sends an Upgrade header to inform the server of its intent to switch to the WebSocket protocol:

hHTTPReq, n, GET, host, path, parameters, hhUpgrade, websocketii, hii .

This request can additionally be encrypted if the script requested a WebSocket connection over TLS.

The server is then expected to respond with an HTTP(S) response with status code 101 and the same Upgrade header.10 Upon receiving this response, the connection is considered “open” and the browser stores connection information (WebSocket reference, HTTP request nonce, symmetric encryption key) in the list of open WebSocket connections (browser state subterm wsConnections).

Now, server and browser can (at any time) send data to each other using network messages of the form

hWS MSG, nonce, datai

(possibly encrypted using the symmetric key from the TLS connection as above). In the browser, a script can send such a message by calling the command WS SEND and providing, as a parameter to the command, the WebSocket reference created when opening the WebSocket connection. Incoming WebSocket messages are appended to the script’s inputs (see Section2.10.9 for more details).

2.10.7. Strict Transport Security

With the security mechanism Strict Transport Security (STS or HSTS), defined in [RFC6797], servers can send a special header, Strict-Transport-Security in HTTPS responses. When a 10_{In the real-world handshake, the browser also has to send a nonce in a special header which must then be hashed,}

together with a static string, by the server. This is intended to ensure that the server actually understands