User:Rjain9

M1654: Improve network security features for Servo (cookies and strict referrer policies)

Introduction

Servo

Servo is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

HTTP Cookie

An HTTP Cookie is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

Rust

Rust is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

Project Description

The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

Tasks

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the Leave Secure Cookies Alone specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure

After Refactoring

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of Deprecate modification of 'secure' cookies from non-secure origins which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specific order for a action.

Approach

First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactoring of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be a penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

Continuous Integration

Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.

Design

In the images below, the code changes reflect the code refactoring involved in changing vector implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines). Whenever a new cookie is added, the cookie's base domain name is extracted out and is looked up in the HashMap. If no entry is found a new Vector is created and appended to it.
When the number of cookies for a base domain reaches the maximum set limit (max_per_host), eviction policy is used to decide the cookies which cookie(s) need to be eliminated to accommodate the new cookie. In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):

1. Expired cookies.
2. Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
3. Cookies that share a "domain" field with more than a predetermined number of other cookies.
4. All cookies.

A preview of the file diffs is as shown below. Complete file diffs are available at this link.

Testing

Automated Testing

We have implemented the following scenarios to test the cookie eviction and max_per_host features:

1. Evict expired cookies when max per host is reached: In this scenario, we delete all the expired cookies from Cookie Store when number of cookies in the base domain reaches maximum threshold (max_per_host)
2. Evict oldest non-secure cookie: When there are no expired cookie in the cookie storage and maximum threshold has been reached (max_per_host), then the oldest non-secure cookie is evicted out.
3. Do not evict secure cookie when maximum threshold is reached (max_per_host) when new cookie being added is non-secure.
4. Evict oldest secure cookie when all cookies in the Cookie Storage are secure and the incoming cookie is also a secure cookie.

All the aforementioned scenario have been implemented as unit tests. In order to test it please use the following commands:

./mach build --dev
./mach test-unit -p net

Manual testing from UI

This is not part of required tasks and has been implemented purely for demonstration purpose.

./mach run https://coookietester.herokuapp.com/cookies

Files modified

• /servo/components/cookie_storage.rs
• /servo/components/net/cookie.rs
• /servo/test/unit/cookie.rs
• /servo/components/servo/cargo.toml
• /servo/components/servo/cargo.lock
• /servo/components/net/http_loader.rs
• /servo/components/net/resource_thread.rs

Key People

Developers

• Guru Darshan
• Raghavendra Nayak
• Rishi Jain
• Tsung-Ying Chuang

Mentor

• Ed Gehringer