Threat model
⚠️ WARNING: This document is not finished. The details in this document are subject to change.
Threat Model Document: Peer-to-Peer Chat Application
Section 1: Identify and Categorize Assets
In the context of the peer-to-peer chat application, the primary assets include both tangible and intangible components crucial for the app's functionality and the user's security and privacy. These assets are potential targets for threats and therefore require appropriate security measures.
1.1 User Data
- Messages : Text and possibly media that are exchanged between users. These are transient but can be intercepted or logged by malicious actors during transmission or by exploiting client storage.
- Encryption Keys : Keys used for encrypting and decrypting messages. They are crucial for maintaining the confidentiality and integrity of the communications.
- User Settings and Preferences : Stored locally within the browser, these include any configuration options that the user can set within the app.
1.2 Infrastructure
- AWS S3 : Used for hosting the static content of the app, including HTML, CSS, and JavaScript files. It serves as the initial download point for users accessing the app.
- PeerJS Server : A third-party service utilized for orchestrating connections between peers. This server plays a critical role in the setup of peer-to-peer communication channels.
- nLevel analytics : Used for used for logging and monitoring user interactions with the application.
- openstreetmap.org : Used for displaying the map in the application.
1.3 Codebase and Dependencies
- React Application : Built with Webpack, using React as the primary framework for the user interface.
- PeerJS Library : Manages the peer-to-peer interactions and is integral to the communication capabilities of the app.
- Third-Party Libraries : Various JavaScript libraries and frameworks included in the project, which could introduce vulnerabilities through external dependencies.
1.4 External Services
- AWS S3 : As mentioned, used for serving the static files necessary for the app’s operation.
- Default PeerJS Server : External service for peer connection management; potential vulnerabilities here could affect the overall security of the peer connections.
- nLevel analytics : External service for logging and monitoring user interactions with the application.
- openstreetmap.org : External service for displaying the map in the application.
1.5 Security Measures
- Content Security Policy (CSP) : Implemented to restrict resources the browser can load, helping prevent XSS attacks and other injection vulnerabilities.
Section 2: Define Trust Boundaries
In a peer-to-peer chat application, trust boundaries delineate areas where data crosses from a trusted to a less trusted or untrusted zone, or vice versa. These boundaries are critical for understanding and implementing security measures that control how data is accessed and used throughout the application.
2.1 External Networks
- Data Transmission Between Peers : Since the application operates over the internet without a centralized server for data handling (except for connection management), the transmission path between any two peers represents a significant trust boundary. Data must be encrypted during transit to prevent interception by untrusted networks or third parties.
2.2 AWS S3 Hosting
- Static Content Delivery : The static content (HTML, CSS, JavaScript files) hosted on AWS S3 is served to the client’s browser. The boundary here is between the AWS-hosted environment and the user’s device. While the static files themselves are not sensitive, any manipulation at this level (such as replacing the JavaScript files with malicious versions) could compromise the client-side of the application.
2.3 Third-Party Services
- PeerJS Server Interaction : The application relies on the**
peerjs-server
** for orchestrating peer connections. This third-party service forms a trust boundary as it manages the signaling required for peers to find and connect with each other. Trust must be carefully managed here, particularly concerning how much control this service has over the connection setup and any data it might log or mishandle.
2.4 Browser Environment
- Client-Side Execution and Storage : Any code execution and data storage that happen in the user’s browser are considered within a trusted boundary. However, the boundary is the browser itself, which interfaces with potentially untrusted data sources (e.g., input from other peers). Strong input validation and sandboxing techniques are necessary to maintain this as a secure zone.
2.5 User Data Interaction
- Input and Output of Data : Every point where user data is entered (input fields) or displayed (message views) is a critical trust boundary. These areas are susceptible to attacks such as XSS if not properly handled. The application must ensure that all data displayed to or received from the users is sanitized to prevent script injections.
2.6 Device Level
- Local Storage and Processing : Data stored locally on a user's device (e.g., encryption keys, chat history) and processing done by the app form a trust boundary against the device's other applications and systems. Ensuring data is stored securely and that the app has the necessary permissions isolated from other applications is crucial.
Section 3: Identify Entry Points
Entry points are interfaces through which data enters the system or where significant interactions occur. Identifying these helps in understanding potential attack vectors and in designing effective security controls.
3.1 Browser-Based Client Interface
- User Interface Interactions : Every interaction the user has with the application's interface, including message input fields, settings configurations, and any other forms of data entry. These are critical entry points for data validation and sanitization to prevent injection attacks.
3.2 Network Communications
- Peer-to-Peer Data Exchange : This is the primary method of communication within the app, where messages and possibly media files are exchanged directly between peers. This communication needs robust encryption to secure data against eavesdropping and tampering.
- Signaling for Peer Connection Setup : Handled by the**
peerjs-server
** , this includes the exchange of IP addresses, session descriptions, and any other signaling data necessary to establish a peer-to-peer connection. Ensuring the integrity and confidentiality of this exchanged data is paramount.
3.3 Third-Party Integrations
- AWS S3 : The entry point for the app's static resources like HTML, CSS, and JavaScript files. Integrity checks must be in place to ensure these files are not tampered with in transit.
- PeerJS Server API : Interactions with the PeerJS server API for managing peer sessions and connections. Authentication and authorization mechanisms must be robust to prevent unauthorized access and manipulation of session data.
3.4 Application Code Execution
- JavaScript Execution : As a single-page application built using React, the execution of JavaScript code is a significant entry point that must be secured against various client-side vulnerabilities, including cross-site scripting (XSS) and cross-site request forgery (CSRF).
3.5 Local Storage Access
- Browser Storage : The application stores configuration settings and potentially sensitive encryption keys in local storage. Ensuring secure storage and access practices are in place is necessary to prevent access by malicious scripts or cross-origin requests.
3.6 External Data Inputs
- User-generated Content : Any content generated by users, including messages and file transfers, can be an entry point for malicious data. Implementing content validation and proper handling of file types and sizes is crucial to maintain application security.