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 specification.

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 refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be 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.

Test Plan

There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set. 2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa. 3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.

Files to be 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

Key People

Developers

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

Mentor

• Ed Gehringer