WEBAPPAUTH: An Architecture to Protect from Compromised

First-Party Web Servers

Pascal Wichmann

, Sam Ansari, Hannes Federrath and Jens Lindemann

Universit

at Hamburg, Germany

Keywords:

Code Authenticity, Web Applications, Client-Side Security, Web Security.

Abstract:

We present the WEBAPPAUTH architecture for protecting client-side web applications even from attackers

who fully control the web server. WEBAPPAUTH signs all ﬁles sent to the client on a secure ofﬂine device

or a hardware security module never accessible by the web server. Public keys are propagated through a key

registry that is maintained by two independent key registration authorities, thus protecting users even on their

ﬁrst visit to the web application. Our threat model covers attackers who gain full control over the targeted

domain and its DNS and DNSSEC conﬁguration.

1 INTRODUCTION

Web applications can implement security mecha-

nisms such as encryption or signature validation in

client-side code. However, the architecture of the web

relies on web servers to provide the client-side code,

thus requiring trust into the authenticity of the code

provided by the web server.

Solutions exist to protect the authenticity of web

assets, such as Transport Layer Security (TLS) for

veriﬁcation of the server identity and ensuring the

conﬁdentiality of connections, or Subresource In-

tegrity (SRI), which allows to pin external resources

to ﬁxed contents via hashes. However, most of these

solutions do not consider compromised ﬁrst-party

web servers where an attacker is able to use TLS cer-

tiﬁcates valid for the targeted domain or modify re-

sources served by the ﬁrst-party server.

While such an attacker would have very strong ca-

pabilities, protecting from them is important for sev-

eral types of applications that can still provide sufﬁ-

cient protection if the browser does not execute ma-

nipulated script assets. Examples are end-to-end-

encrypted applications supposed to conceal contents

from the web server where – without protection –

such an attacker could turn off the end-to-end encryp-

tion, or web-based crypto currency wallets, where the

attacker could extract the private keys. Thus, we pro-

https://orcid.org/0000-0002-8969-4277

https://orcid.org/0000-0003-0103-2461

pose WEBAPPAUTH, an architecture that provides

protection even if the ﬁrst-party web server is com-

promised. To provide this protection, we rely on sign-

ing all assets using private keys that are stored and

used at a location inaccessible to the web server, e. g.,

on a device never connected to the Internet.

We assume the party responsible for the applica-

tion (“web application operator”) to be trustworthy.

However, any servers involved in the operation of the

application, including those of the ﬁrst party, may be

under full control of an attacker.

The remainder of this paper is structured as fol-

lows: In Section 2, we present our architecture, which

we evaluate in Section 3. In Section 4, we discuss the

practicability and limitations of our architecture. Sec-

tion 5 presents related work on the authenticity of web

application code. We conclude our work in Section 6.

2 ARCHITECTURE

In this section, we describe the architecture of WEB-

APPAUTH. We start by discussing our threat model.

Subsequently, we describe the components of our ar-

chitecture, followed by the deployment and retrieval

of web applications. Lastly, we describe operational

tasks, such as key revocation.

548

Wichmann, P., Ansari, S., Federrath, H. and Lindemann, J.

WebAppAuth: An Architecture to Protect from Compromised First-Party Web Servers.

DOI: 10.5220/0012141700003555

In Proceedings of the 20th International Conference on Secur ity and Cryptography (SECRYPT 2023), pages 548-556

ISBN: 978-989-758-666-8; ISSN: 2184-7711

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

2.1 Threat Model

We assume a very strong attacker with full control

over all servers of the targeted web application, in-

cluding ﬁrst-party servers. Hence, the attacker can

also manipulate all communication between any web

server of the attacked web application and its users.

Alternatively, the attacker may manage to control the

DNS and DNSSEC data of the targeted domain, ob-

tain a valid TLS certiﬁcate for it, and redirect trafﬁc

to an own server.

WEBAPPAUTH relies on key registration authori-

ties to manage published public key material. These

authorities are assumed to be trustworthy and outside

of the control of the attacker. The authorities follow

the protocol and do not tamper with the integrity of

the data they are responsible for.

2.2 Components of WEBAPPAUTH

Figure 1 gives an overview of the components of

WEBAPPAUTH. The architecture relies on a web

application key registry (Section 2.2.1), which is

checked by the browser to establish whether a do-

main uses WEBAPPAUTH. The registry is adminis-

tered and published by two key registration authori-

ties (Section 2.2.2). To check a concrete web applica-

tion, the browser further processes a web application

manifest (Section 2.2.3) and individual ﬁle signatures

(Section 2.2.4) published by the web server alongside

the application.

2.2.1 Web Application Key Registry

The key registry contains a SHA-256 hash of the pub-

lic key for all web applications that employ WEBAPP-

AUTH. Every registry entry is associated with exactly

one such key. Applications are identiﬁed by their do-

main name. The registry entry deﬁnes the subdomains

that use WEBAPPAUTH. The entry may be overwrit-

ten by a revocation message and can contain a ﬂag

that marks the entry for deletion at a speciﬁc time.

The domain name should be an eTLD+1 name.

It is possible to deploy WEBAPPAUTH for a non-

eTLD+1 subdomain. However, the set of subdomains

covered by two entries may not overlap. This ensures

a single deﬁnitive trust source for each application

and prevents operators from keeping old keys in the

registry.

All browsers that support WEBAPPAUTH keep a

veriﬁed local copy of the key registry updated at least

daily. This prevents downgrade attacks, i. e., attack-

ers who manage to impersonate a web server cannot

disable WEBAPPAUTH. On every update, the author-

ities provide deltas to every previous registry version

of the past week. Consequently, if browsers have a

current version of the registry that is less than a week

old, they can retrieve a single delta ﬁle and the signa-

ture of the new version. The delta ﬁles can be applied

in a deterministic way, i. e., always produce a consis-

tent registry ﬁle.

Every version of the registry contains a timestamp

that is covered by the signatures of the authorities.

To allow public auditing of the registry, a log of all

changes between every published version of the key

registry is published using a Merkle hash tree equiv-

alently to certiﬁcate transparency logs (Laurie et al.,

2013).

In addition to the registry hosting provided by the

authorities, a copy of the key registry including the

signatures from the authorities is hosted by additional

mirror servers, improving the availability of the reg-

istry.

2.2.2 Key Registration Authorities

The key registration authorities are responsible for

maintaining the key registry. To prevent an individ-

ual registration authority from manipulating, we rely

on two independent authorities.

Both key registration authorities independently

verify that requests to add a domain to the key registry

are authentic, i. e., the requestor has control over the

domain. Each authority sends a challenge that con-

sists of a randomly generated string to the requestor

who then deploys a DNS TXT record containing the

string for the domain. Additionally, the TXT record

contains a SHA-256 hash of the requested registry en-

try to prevent manipulations of the requests, e. g., by

a man-in-the-middle attacker.

Requests must always be sent to both authori-

ties. The authorities coordinate submission attempts

and block requests that do not fulﬁll this require-

ment. To prevent malicious deployments when an

attacker has temporarily gained control over a do-

main, an email is sent to the addresses hostmaster,

postmaster, security, and abuse of the domain ev-

ery hour throughout the 72 hours following the suc-

cessful ownership veriﬁcation. The high email fre-

quency is chosen to mitigate attacks temporarily ma-

nipulating the DNS email conﬁguration of the do-

main. After the 72 hours, the domain is added to

the key registry unless disputed by the legitimate do-

main owner. Within the ﬁrst 14 days after addition,

an immediate removal can be requested by the legit-

imate domain owner after ownership validation (late

dispute). Afterwards, the entry is permanent and the

regular removal procedure (cf. Section 2.6) must be

used for removal.

The authenticity of the key registry is veriﬁed us-

WebAppAuth: An Architecture to Protect from Compromised First-Party Web Servers

549

Web Application Key Registry

Domain Public Key Hash and Domain Conﬁguration

example.org SHA-256( ), {"subdomains": ["", "*"]}

secure.my-bank.com revoked

newspaper.com SHA-256( ), {"subdomains": ["", "*"],

"markedForDeletion": "2023-02-26"}

site.org SHA-256( ), {"subdomains": [""]}

Web Browser

Web Server

Web Application Operator

Independent Key Reg-

istration Authorities

Private Key

(D1) Web application operator gen-

erates key pair and stores private

key in a secure place never accessi-

ble by the web server.

(D2) Web application operator

initially requests inclusion of

public key for site.org.

Both authorities maintain and

sign the registry.

(D3) Operator stores

signatures of all web

application assets on

the server.

(R1) User wants to visit web

application at domain site.org.

(R2) Browser re-

trieves domain key for

site.org from local

copy of registry.

(R3) Browser re-

trieves and veriﬁes

web application assets

and signatures from

site.org’s server.

Figure 1: Overview of the architecture of WEBAPPAUTH. The steps (D1) to (D3) are required to deploy the mechanism to a

web application at a new domain site.org. The steps (R1) to (R3) are performed upon every retrieval of a web application

using WEBAPPAUTH.

ing signatures from both authorities. Both have an

identical copy of the key registry as they enforce that

all modiﬁcations are registered with both authorities.

The public key of both authorities is included in

the browser and used to verify the authenticity of the

registry. Each authority is responsible for its private

key’s security and must store it on a hardware security

module or a device not connected to the Internet.

The communication between the web application

operators and the key registration authorities is pro-

tected through TLS. The TLS certiﬁcates of the au-

thorities are signed with the private key used for the

key registry for ensuring their authenticity, but use a

separate key pair for the communication itself. This

separate key pair cannot be used to sign registry ver-

sions, implying lower security requirements for the

protection of the private keys. In particular, key reg-

istries can store their key pair for signing the registry

on a dedicated secure device not connected to the In-

ternet while still being able to deploy the separate

communication key pair on their server connected to

the Internet.

Both authorities use independent implementations

of WEBAPPAUTH using different software stacks.

This reduces the likelihood that both have identical

vulnerabilities or bugs.

2.2.3 Web Application Manifest

Every web application that utilizes WEBAPP-

AUTH has to provide a manifest as a JSON

ﬁle at the path /.well-known/auth-protec-

tion/manifest.json. A signature of the manifest

created with the private key of the web application

operator is provided and veriﬁed by the browser (cf.

Section 2.2.4). If no valid manifest ﬁle exists or the

signature veriﬁcation fails, the browser refuses to

load any part of the web application. If WEBAPP-

AUTH is enabled for more than one subdomain, each

subdomain has to provide its own manifest ﬁle.

An example of a manifest ﬁle is shown in List-

ing 1. Every manifest contains the following infor-

mation:

• The public key used for asset validation. Its hash

has to match the entry in the key registry.

• The creation time of the manifest ﬁle. It is used to

prevent a malicious rollback to a previous version.

• A list of ﬁle types excluded from the authentic-

ity protection, i. e., these ﬁle types do not require

signatures. This can be useful where ﬁles are gen-

erated automatically, e. g., images, documents or

HTML pages. Signing such ﬁles would be im-

practical without allowing the web server to have

direct access to the private key.

WEBAPPAUTH suppresses the snifﬁng of

(MIME) media types by the browser to prevent

SECRYPT 2023 - 20th International Conference on Security and Cryptography

550

possible exploitation (Barth et al., 2009). It

enforces that only scripts can be executed.

• The excludePath option disables protection for

speciﬁc paths. The browser does not verify

signatures underneath these paths. However,

it is not possible to load any ﬁles from ex-

cluded paths from origins that are not excluded.

For example, if /staging/ is excluded, a ﬁle

at path /app/foo.html cannot load a resource

/staging/script.js from an unprotected loca-

tion.

• The Content Security Policy (CSP) that must be

set for all protected resources. It must disallow

the inclusion of scripts from third-party origins.

Different CSPs can be set for different path pre-

ﬁxes. If a resource uses a CSP that does not match

the conﬁguration in the manifest, the request is

blocked by WEBAPPAUTH. The manifest must

set a CSP for every path, i. e., requests for re-

sources for which the manifest does not specify

a value are blocked.

The restriction of the CSP prevents attacks that

exploit media types that are excluded from pro-

tection. For example, without a restrictive CSP

and with the text/html media type excluded, an

attacker could use inline scripts to bypass protec-

tion of script ﬁles.

{"publicKey": "d2ljaG1hbm5wYXNjYWwtcGF...",

"time": "2022-12-19T13:39:52.362346",

"excludeMediaTypes":

["application/json"],

"excludePaths": ["/staging/"],

"CSP": {"/": "default-src 'self';"}}

Listing 1: Example web application manifest ﬁle

2.2.4 File Signatures

For every asset of the web application that is not ex-

cluded through the manifest ﬁle, a signature is pro-

vided by the web server validating both the media

type and the content. Two ways are supported to pro-

vide the signatures:

• Through an HTTP header Asset-Signature

containing the base64-encoded signature value.

• As a separate ﬁle at the same path with an addi-

tional .sig extension. This does not require mod-

iﬁcations to the web server conﬁguration, as they

can be deployed like regular web application ﬁles.

If the web server supports it, this approach can

be combined with HTTP/2 server push to provide

the signature ﬁles before the browser explicitly re-

quests them.

The browser always checks for the existence of the

Asset-Signature HTTP header ﬁrst. Only if the

header is not present, it tries to retrieve the separate

signature ﬁle.

2.3 Deployment for a New Web

Application

To deploy the mechanism for a web application at a

domain that has not previously been used with WEB-

APPAUTH, the following steps are performed (cf.

Figure 1):

(D1) The web application operator generates an

asymmetric key pair consisting of a public and

a private key. The key generation is performed

in a secure environment. The private key is al-

ways stored in a secure location inaccessible to

the web server, e. g., on an ofﬂine device that is

never connected to the Internet, or a hardware

security device.

In addition, the application operator generates a

revocation message that is signed with the pri-

vate key. It can be used to revoke the key reg-

istry entry in case the private key is lost (cf.

Section 2.7). A secure storage of the revoca-

tion message is essential to the availability of

the domain, as any attacker gaining access to

the revocation message can disable the web ap-

plication.

(D2) The application operator sends a request for in-

clusion in the web application key registry to

the authorities, consisting of the domain name,

the SHA-256 hash of the public key, and the list

of subdomains that should enforce WEBAPP-

AUTH. Before the registries accept the request,

both independently verify the domain owner-

ship via DNS-based authentication (cf. Sec-

tion 2.2.2).

The application operator also provides a contact

email address and optionally a postal address.

The email address should (but does not have to)

belong to a separate domain that is independent

from the registered domain. This contact infor-

mation is used to inform the private key holder

of security-relevant information about their do-

main, such as a removal request or a revocation.

The authorities verify that they received identi-

cal contact information. The contact informa-

tion is not published, however.

(D3) The web application operator signs the mani-

fest and all assets of the web application and

uploads the signatures to the web server. On

WebAppAuth: An Architecture to Protect from Compromised First-Party Web Servers

551

every web application update, signatures for the

new and changed assets are uploaded.

Deploying WEBAPPAUTH for a domain is a per-

manent action. Consequently, domain owners must

carefully consider whether to add their domain to the

key registry. If the key is lost or it becomes inconve-

nient to continue the support of WEBAPPAUTH for a

web application (e. g., due to changed application re-

quirements), the protected domain cannot be further

used. While in the latter case, it is possible to use the

manifest to disable WEBAPPAUTH for most parts of

the application, in the case of a lost key, it is not pos-

sible to perform any further modiﬁcations, including

to the protected ﬁle types. However, WEBAPPAUTH

provides a removal procedure (cf. Section 2.6) that

allows to remove a domain from the key registry with

a delay of two months.

2.4 Retrieval of a Protected Web

Application

A browser with support for WEBAPPAUTH performs

the following steps for every retrieval of a web appli-

cation and any other ﬁle received from a web server

(cf. Figure 1):

(R1) The browser receives the request to load a spe-

ciﬁc URL.

(R2) The browser uses its veriﬁed local copy of the

key registry to check whether the respective do-

main uses WEBAPPAUTH. If no matching entry

is found, the browser continues to handle the in-

struction as usual. If an entry comprises the do-

main and contains a revocation ﬂag, the browser

refuses the request. If a matching entry is found

that marks the domain for deletion in the past,

the entry is ignored and the browser continues

to handle the user instruction as usual. Other-

wise, the public key hash from the entry is used

to verify the public key.

Next, the browser retrieves the manifest ﬁle

for the web application from the /.well-

known/auth-protection.json path of the

domain the request is sent to and veriﬁes its sig-

nature. To verify the signature, the browser ﬁrst

checks the Asset-Signature HTTP header of

the response. If missing, the signature at the

path with .sig sufﬁx is requested. If no valid

signature is found, the request is blocked.

The manifest is cached locally according to the

cache conﬁguration in the HTTP headers. If

a cached version not yet expired exists, the

browser does not request the manifest again. If

the browser previously retrieved a manifest ﬁle

from this domain, it veriﬁes that the timestamp

of the new manifest is more recent than the pre-

vious, blocking all requests to this domain oth-

erwise.

(R3) Concurrently to the previous step, the browser

requests the URL from the server. Unless the

manifest excludes this media type or path, the

browser veriﬁes its signature using the public

key from the manifest. The browser veriﬁes

the signature of the manifest as explained in the

previous step. The last performed check veriﬁes

that the CSP of the response matches the one

conﬁgured in the WEBAPPAUTH manifest for

the respective path. If the CSP does not match,

the request is blocked.

When a request is blocked, the user is warned.

However, the user is not provided with the ability to

suppress such errors.

2.5 Update of a Key Registry Entry

The list of included subdomains of an entry can be

updated. The process is identical to the deployment

of a new web application (cf. Section 2.3) but the

requestor must use the existing key pair. After suc-

cessful domain ownership veriﬁcation and 72 hours

dispute time, the existing entry is updated.

This process can only be used to extend the list

of subdomains. It is not possible to remove any sub-

domains this way. Removing a subdomain is subject

to the key registry entry removal process (cf. Sec-

tion 2.6).

However, it is possible to split an entry, i. e. cre-

ate a new, separate entry for a subdomain. To pre-

vent an attacker from exploiting this for publishing a

(compromised) key for a subdomain that would then

be used instead of the legitimate key from the origi-

nal entry, a waiting period of two months, similar to

the removal of an entry (cf. Section 2.6) has to be ob-

served. After this period has passed, the subdomain is

removed from the original entry. Simultaneously, the

requested new entry for this subdomain is published.

2.6 Removal of a Key Registry Entry

WEBAPPAUTH provides a removal procedure to al-

low domain owners to revert a deployment, for ex-

ample because they do not want to use it any longer

or the domain ownership has changed. However, the

removal enforces a delay of two months before tak-

ing effect to provide legitimate domain owners a suf-

ﬁcient time to dispute an illegitimate removal request.

To initiate the removal of a domain, the domain

owner sends a removal request to both key registra-

SECRYPT 2023 - 20th International Conference on Security and Cryptography

552

tion authorities. Both authorities independently verify

the domain ownership of the requestor via DNS-based

authentication analogously to the process of domain

inclusion (cf. Section 2.2.2). If both authorities have

veriﬁed the ownership of the requestor, they update

the speciﬁc key registry entry to mark it for deletion

after the delay of two months. On the marked date,

the authorities completely remove the respective en-

try.

As an alternative to removing a full entry, subdo-

mains can also be removed from an entry. This will

leave the rest of an entry intact, covering the remain-

ing subdomains. This is subject to the same process

and delay as removing an entry altogether.

2.7 Revocation of a Key Registry Entry

A revocation procedure exists that allows to mark a

key registry entry as revoked in case the private key of

a domain is leaked. When the browsers have updated

their registry copy to contain the revocation ﬂag of

the entry, they refuse any requests to its conﬁgured

(sub)domains, effectively disabling the domain for all

browsers supporting WEBAPPAUTH.

To perform the revocation, the operator sends their

domain’s signed revocation message they have pre-

pared during key generation (cf. Section 2.3) to both

key registries. The registries replace the domain con-

ﬁguration with a revoked ﬂag and publish a new ver-

sion of the key registry. The revocation procedure

does not trigger a removal. If desired, the operator

needs to follow the regular removal procedure (cf.

Section 2.6) to fully remove the entry.

3 EVALUATION

In this section, we evaluate the overhead of WEBAPP-

AUTH for users and servers. Browsers contain a copy

of the key registry. Each entry has a size of approx-

imately 150 B depending on the number of subdo-

mains. Assuming 10 000 entries, this results in a total

size of 1.5 MB stored locally. For comparison, the

HSTS preload list in Chromium contained approxi-

mately 198 000 entries as of March 30, 2023. Due

to the nature of WEBAPPAUTH, we assume a much

lower number of deployments than HSTS preload,

given primarily web applications with client-side se-

curity operations beneﬁt from WEBAPPAUTH.

Browsers update the registry at least daily if the

browser is used. As long as the last update is less than

a week ago, updates transfer only the delta to the pre-

vious version. Depending on the number of changes,

this adds a small amount of trafﬁc for every daily up-

date, e. g. just under 5 kB for 33 updates. If the

browser has not been used for more than a week, this

requires another full download of the registry, caus-

ing another 1.5 MB of trafﬁc for a registry of 10 000

entries.

To retrieve a web application, browsers ﬁrst check

whether the key registry contains an entry for the do-

main. Only domains included produce further over-

head: per protected domain, the browser retrieves the

manifest ﬁle, causing on average 500 B trafﬁc for the

request-response pair. In addition, each request for a

ﬁle that is not excluded from protection adds a sig-

nature that is less than 80 B long if retrieved as a

header. If deployed as a separate ﬁle, a somewhat

larger amount of trafﬁc of less than 400 B is gen-

erated, as a full request-response pair is needed. If

we assume a web application requires retrieval of 50

protected ﬁles, this causes a total of 4 kB (header) or

20 kB (separate signature ﬁles) of additional trafﬁc.

No additional delay is caused by checking the

manifest, as it is retrieved concurrently to the other

ﬁles. Checking the signatures also causes no addi-

tional delay if they are delivered in an HTTP header.

If the server does not deliver signatures through the

header, a signature ﬁle will be retrieved after the cor-

responding ﬁle, however. This induces a delay of one

round-trip time.

4 DISCUSSION

In this section, we discuss the practicability and limi-

tations of WEBAPPAUTH.

Relevance of the Threat Model. Our threat model

considers a very strong attacker who has full control

over all servers of a web application. Consequently,

the attacker can manipulate all server-side process-

ing of the application and access all data. How-

ever, client-side code can use cryptography to con-

ceal plaintext data from the web server and verify data

authenticity. Thus, the protection of client-side code

of such applications is essential even when the web

servers are malicious.

Number of Key Registration Authorities. The

number of authorities is a trade-off between trustwor-

thiness of the key registry (more independent parties

and thus higher trust) and overhead (more parties and

thus more peers to coordinate with). WEBAPPAUTH

uses two to keep the coordination overhead acceptable

while still preventing a single party from manipulat-

ing the registry.

WebAppAuth: An Architecture to Protect from Compromised First-Party Web Servers

553

Choice of Key Registration Authorities. The au-

thorities need to be trustworthy. Possible options for

this role may be browser vendors or well-known non-

proﬁt associations.

Attacks Prior to Initial WEBAPPAUTH Deploy-

ment. We assume that the initial deployment of

WEBAPPAUTH, i. e., the addition of the domain to

the key registry, happens before any attack attempts,

for example right at the initial deployment of the web

application. That is, WEBAPPAUTH cannot provide

its protection if attacks occur before the deployment.

Such attacks may include attacker-initiated attempts

to register a new domain that did not exist previously,

e. g., for phishing.

Attackers With Full Control of the Domain. At-

tackers fully controlling DNS(SEC) data of a domain

can break its availability. However, conﬁdentiality

and authenticity of data remain protected on the client

side. An attacker must control the domain for more

than two months to undergo the complete removal

procedure in order to impair the conﬁdentiality and

authentictiy of the client-side protected data.

Attacking Browsers. Attackers not covered by our

threat model may attempt to attack browsers to dis-

able WEBAPPAUTH or to manipulate the public keys

of the authorities. However, the capability to manip-

ulate browsers also gives the attacker the ability to

manipulate the client-side web application execution

independently of any authenticity protection.

Application Vulnerabilities. While WEBAPP-

AUTH can protect the authenticity of the client-side

code, it cannot protect from vulnerabilities that are

present in the authentic code provided by the web

application operator.

Risk of Temporary Domain Loss. If operators of a

WEBAPPAUTH-protected web application lose their

private key, they can no longer deploy updates to the

client-side code, making the domain practically unus-

able for web applications. This risk cannot be avoided

without losing protection from attackers who manage

to temporarily control the attacked domain, as such

attackers temporarily mock the role of the operator.

A removal procedure is available to re-gain control to

such a domain after a delay of two months.

Single Key per Entry. Our architecture does not al-

low to use more than one key pair per registry en-

try. Consequently, domains for example maintained

by larger organizations need to sign their assets in a

secure way without providing additional keys for or-

ganizational units. This way, the responsibility for the

key security and trust management lies with a central

entity within the organization. On a subdomain level,

separate non-overlapping key registry entries can be

used with individual keys to split responsibility within

the organization.

Required Changes for Deployment. To utilize the

protections of WEBAPPAUTH, some changes are re-

quired on the user and server side. Firstly, the browser

needs to support the mechanism. This support can be

added as a native browser functionality in the future.

Until then, a browser extension can be used to add

WEBAPPAUTH support to the browser, which does

not require implementation by browser vendors. Sec-

ondly, the web server needs to provide the signatures

for the protected assets. For ﬁle-based delivery, the

web application operator only needs to upload the

signature ﬁles to the server. For the more efﬁcient

header-based delivery, the web server software needs

to be conﬁgured to read the signatures from their cor-

responding ﬁles and add them to the header. Depend-

ing on the used software, this may require changes

to its code. However, if a servers hosts only a small

number of infrequently updated ﬁles, it is sufﬁcient to

statically conﬁgure the signature headers for the in-

dividual paths, which is possible in all popular web

server software without further changes.

5 RELATED WORK

In this section, we discuss prior work on web authen-

ticity.

Established Web Security Mechanisms. Several

security mechanisms are supported in all major

browsers. TLS (Rescorla, 2018) can protect the con-

ﬁdentiality and authenticity of the communication be-

tween the web server and the browser using trans-

port encryption and validation of server certiﬁcates.

HTTP Strict Transport Security (HSTS) (Hodges et

al., 2012) allows to enforce the use of TLS for a

domain and is activated through an HTTP header.

With HSTS preloading (Chromium Project, 2023),

domains can be added to a list in browsers to protect

the ﬁrst visit.

SRI (Akhawe et al., 2016) allows to protect in-

cluded subresources by specifying a cryptographic

hash of their contents. If a resources’ hash does not

match, the browser refuses to load it. SRI is intended

SECRYPT 2023 - 20th International Conference on Security and Cryptography

554

to protect from third-party servers hosting referenced

assets.

Signature-Based Authenticity. Sutter et al. (2021)

consider a compromised TLS connection between a

browser and a web server, e. g., a man-in-the-middle

attack where the attacker has obtained a valid TLS

certiﬁcate. The authors use service workers to ver-

ify the integrity of all HTTP responses from the

web server, allowing deployment in web applications

without changes to the browser. All responses from

the web application contain a signature in an HTTP

header which is veriﬁed by the service worker. The

signatures are generated on the web server or option-

ally on a separate server. The client must have vis-

ited the domain before for the mechanism to provide

protection. If an attacker manages to compromise the

ﬁrst connection of a user, they can suppress the corre-

sponding header to prevent the browser from enforc-

ing it, voiding all protection.

Levy et al. (2016) propose Stickler as an alter-

native to SRI that can be used to provide authentic-

ity to assets that are served through a content deliv-

ery network (CDN). The initial request is sent to the

ﬁrst-party web server, returning a script that contains

the Stickler code and the public key of the ﬁrst party.

This script retrieves a signed manifest ﬁle from the

CDN, allowing to retrieve and verify all further as-

sets from the CDN. Mignerey et al. (2020) propose

another browser extension that uses signatures to ver-

ify the authenticity of assets. Their solution assumes

the public key to be shared on an out-of-band channel

before the users visit the web application.

Cavage and Sporny (2019) propose a standard-

ization for end-to-end signing HTTP messages, i. e.,

preventing undetected tampering of messages during

their transmission. Their draft adds a Signature

header specifying the key used for signing as well as

the resulting signature. The other party can then ver-

ify the signature. However, Cavage and Sporny do not

cover the key exchange and key authenticity veriﬁca-

tion processes.

Transparency Logging. WAIT (Meißner et al.,

2021) provides transparency of client-side code

through a veriﬁable public log in which the web ap-

plication operators publish their code modiﬁcations.

This prevents web servers from tampering with the

client-side code sent to individual clients without pub-

lishing the speciﬁc modiﬁcation to the log.

Salvador et al. (2018) focus on digital elections

and propose a solution that monitors changes of

client-side web application code introduced by the op-

erators. They perform periodic scans of the web ap-

plication to analyze its code and prevent web server

operators from delivering malicious code to a wide

range of their users. However, this monitoring-based

approach cannot prevent targeted attacks, e. g., if the

server operator provides malicious code only to users

at speciﬁc IP addresses.

Code Reviews. Cap and Leiding (2018) propose an

architecture that relies on manual reviews of web ap-

plication code. All reviews are published in a public

log. A browser extension veriﬁes whether a valid re-

view for a retrieved version of a web application exists

in this log. It then provides the user with information

about the security of the application based on this.

Jansen et al. (2017) implement a browser exten-

sion that veriﬁes client-side web application code that

may be served from untrustworthy sources. They

consider a secure multi-party computation scenario

where multiple mutually distrusting parties want to

perform computations together through a web appli-

cation. All code is audited by multiple trusted parties

before it is executed on the clients.

Additional Trusted Servers. The required trust can

be split across additional parties or trusted servers.

Karapanos et al. (2016) propose Verena, which adds

an additional server to the deployment of a web ap-

plication, allowing clients to receive cryptographic

proofs of the application integrity. All requests requir-

ing end-to-end authenticity are passed through this

additional Verena server which generates a proof ver-

iﬁable by the browser. The developer deﬁnes which

application parts require such proofs. Verena allows

to protect from attackers who compromise the appli-

cation server and the database server as long as the

Verena server is not compromised.

Popa et al. (2014) consider a threat model in which

the attacker has full access to the web server. They

provide a web application framework that provides

client-side encryption, allowing keyword searches on

the server without decryption. Their architecture as-

sumes that attackers are unable to tamper with the ini-

tial user’s request to a ﬁrst origin, while manipulations

to all communication with a second origin can be de-

tected.

DNS-based Authenticity Protection. Multiple so-

lutions rely on DNS records to provide protection.

The SecureBrowse project (Chuk and Shapiro, 2019)

provides protection if the connection between the

client and the web server is compromised or a third-

party web server is malicious. It relies on DNS

TXT records that contain Subresource Integrity (SRI)

hashes of the web resources, including all ﬁrst-party

WebAppAuth: An Architecture to Protect from Compromised First-Party Web Servers

555

resources and the main page. To ensure the authen-

ticity of the DNS records, DNS-based Authentication

of Named Entities (DANE) is used. However, un-

like WEBAPPAUTH, SecureBrowse does not require

the key to be kept outside of the web server’s con-

trol and thus does not consider a compromised ﬁrst-

party web server. Beyond DANE, SecureBrowse does

not protect from a compromised DNS, for example if

an attacker manages to remove or replace an existing

DNSSEC key and set an own DNS nameserver for

the domain. Furthermore, unlike WEBAPPAUTH, Se-

cureBrowse is unable to protect from attackers who

are able to control the DNS for multiple days, includ-

ing the capability to manipulate DNSSEC keys. In ad-

dition, SecureBrowse does not allow to exclude assets

from protection, which makes it unsuitable in some

scenarios that are covered by WEBAPPAUTH, such as

dynamic generation of HTML or media ﬁles.

Varshney and Shah (2021) analyze the threat

of client-side manipulation of web application code

through browser extensions. They propose a DNS-

based security policy framework that enables the

browser to detect such manipulation. Their architec-

ture provides hashes of important pages of the web

application via DNS TXT records, which the browser

can compare with the hashes of the actual pages.

6 CONCLUSION

In this paper, we proposed WEBAPPAUTH that can

protect from very strong attackers who have full con-

trol over all web servers and the domain DNS. It re-

lies on signing client-side code with a private crypto-

graphic key, which the web application operator must

store in a secure location, such as on air-gapped de-

vices. Two independent key registration authorities

verify domain ownership and maintain a public reg-

istry containing the public keys of all domains. These

public keys can then be used by clients to verify

the authenticity of the web application. WEBAPP-

AUTH requires the transmission of only a relatively

low amount of extra data and can be deployed in a

way that does not cause additional delays when load-

ing a web application. It is robust to attackers fully

controlling an attacked domain for a limited time.

As future work, we intend to research server-

side authenticity within our threat model, e. g., using

trusted hardware.

REFERENCES

Akhawe, Devdatta et al. (2016). Subresource Integrity.

W3C Recommendation. URL: https : / / www . w3 . org /

TR/2016/REC-SRI-20160623/.

Barth, Adam, Juan Caballero, and Dawn Song (2009). Se-

cure Content Snifﬁng for Web Browsers, or How to

Stop Papers from Reviewing Themselves. In: 30th IEEE

S&P, pp. 360–371.

Cap, Clemens and Benjamin Leiding (2018). Ensuring

resource trust and integrity in web browsers using

blockchain technology. In: International Conference on

Advanced Information Systems Engineering, pp. 115–

125.

Cavage, Mark and Manu Sporny (2019). Signing HTTP

Messages. Internet-Draft draft-cavage-http-signatures-

12. URL: https://www.ietf.org/archive/id/draft-cavage-

http-signatures-12.txt.

Chromium Project (2023). HSTS Preload List Submission.

Accessed May 5th, 2023. URL: https://hstspreload.org.

Chuk, Brian and Paul Shapiro (2019). SecureBrowse

Project. URL: https : / / gitlab . com / securebrowse /

securebrowse/-/wikis/The-SecureBrowse-RFC.

Hodges, J., C. Jackson, and A. Barth (2012). HTTP Strict

Transport Security (HSTS). RFC 6797.

Jansen, Frederick et al. (2017). Brief Announcement: Fed-

erated Code Auditing and Delivery for MPC. In: Sta-

bilization, Safety, and Security of Distributed Systems -

19th International Symposium, SSS, pp. 298–302.

Karapanos, Nikolaos et al. (2016). Verena: End-to-End In-

tegrity Protection for Web Applications. In: 37th IEEE

S&P, pp. 895–913.

Laurie, B., A. Langley, and E. Kasper (2013). Certiﬁcate

Transparency. RFC 6962.

Levy, Amit, Henry Corrigan-Gibbs, and Dan Boneh (2016).

Stickler: Defending against Malicious Content Distri-

bution Networks in an Unmodiﬁed Browser. In: IEEE

Security & Privacy 14.2, pp. 22–28.

Meißner, Dominik, Frank Kargl, and Benjamin Erb (2021).

WAIT: protecting the integrity of web applications

with binary-equivalent transparency. In: SAC ’21: The

36th ACM/SIGAPP Symposium on Applied Computing,

pp. 1950–1953.

Mignerey, Josselin, Cyrille Mucchietto, and Jean-Baptiste

Orﬁla (2020). Ensuring the Integrity of Outsourced

Web Scripts. In: 17th International Joint Conference

on e-Business and Telecommunications, ICETE 2020 -

Volume 2: SECRYPT, pp. 155–166.

Popa, Raluca Ada et al. (2014). Building Web Applica-

tions on Top of Encrypted Data Using Mylar. In: 11th

USENIX Symposium on Networked Systems Design and

Implementation, NSDI, pp. 157–172.

Rescorla, E. (2018). The Transport Layer Security (TLS)

Protocol Version 1.3. RFC 8446.

Salvador, David, Jordi Cucurull, and Pau Juli

a (2018).

wraudit: A Tool to Transparently Monitor Web Re-

sources’ Integrity. In: Mining Intelligence and Knowl-

edge Exploration - 6th International Conference,

MIKE, pp. 239–247.

Sutter, Thomas et al. (2021). Web Content Signing with Ser-

vice Workers. In: arXiv:2105.05551.

Varshney, Gaurav and Naman Shah (2021). A DNS Secu-

rity Policy for Timely Detection of Malicious Modiﬁca-

tion on Webpages. In: 28th International Conference on

Telecommunications (ICT).

SECRYPT 2023 - 20th International Conference on Security and Cryptography

556