Quasar Secure — Chat E2EE & Zero-Trust Architecture

Author
Eduardo Camarillo [Noir0x63]
Date
Version
VERIFIED v2.0

Quick Answer

Detailed walkthrough of Quasar Secure. WebRTC P2P connections, JWT session controls, FIM checksum monitoring, SQLite crypt-WAL databases.

Key Takeaways

  • Category: Quasar Secure
  • Version: VERIFIED v2.0
  • Published: 2026-05-29
  • Keywords: zero-trust messaging, WebRTC P2P encryption, E2EE chat architecture, JWT session security, FIM monitoring

Quasar Secure — Technical Audit & Zero-Trust Architecture Analysis

Date: Fecha: May 29, 2026
Author: Autor: Noir0x63
Version: Versión: VERIFIED v2.0
PASSED E2EE & FIM ACTIVE

1. Executive Summary & Core Paradigm

Quasar Secure is a secure real-time communication platform engineered under Zero-Trust principles. Departing from typical web chat designs, Quasar utilizes multi-layered cryptography to guarantee confidentiality: communications (audio, video, screen-sharing) utilize Direct P2P WebRTC tunnels, while application state, profiles, messages, and files are stored fully encrypted at rest. An extensive source audit of the repository reveals undocumented security defenses at both system and application layers.

2. Real-Time File Integrity Monitoring (FIM)

To prevent runtime tampering of the Node.js application process, Quasar implements a strict, continuous File Integrity Monitor (FIM) inside its production initialization sequence (backend/index.js):

  • // ROOT PRIVILEGE PROHIBITION: The server checks process.getuid() === 0 at startup. If executed as root, it immediately terminates (process.exit(1)) to limit potential container breakouts or host compromise.
  • // FS.WATCH REAL-TIME DAEMON: In production, the backend initiates fs.watch() handlers over critical core files: index.js, auth.js, and config.js. The moment any modification event is detected, the server logs a critical alert and triggers an instant self-destruct shutdown, neutralizing dynamic cold-patch injections.

3. Dual-Method Cryptographic Authentication

Quasar provides dual-layer protection for administrative credentials, protecting the backend endpoints:

  • // TIMING-ATTACK RESISTANT HASHER: Standard passwords are hashed and validated at /login. The verification utilizes crypto.timingSafeEqual via the AuthModule.safeCompareHashes helper. If the input and stored hashes differ in length, the system executes a dummy timing-safe comparison against the stored hash itself to guarantee constant execution time, preventing timing-leakage side-channel attacks.
  • // RSA CHALLENGE-RESPONSE PROTOCOL: For passwordless administration, the system implements an asymmetric challenge-response flow. The client requests a cryptographically secure 32-byte hex challenge from /admin/challenge (valid for 60s). The client must sign this challenge with their RSA Private Key and POST it to /admin/verify. The server validates the signature using the pre-loaded admin_public.pem via crypto.verify("sha256", challenge, key, signature) before setting a strict HttpOnly, SameSite=Strict session cookie.

4. Database Encryption at Rest & WAL Optimizations

Quasar relies on an SQLite database backed by better-sqlite3. To ensure that database file extraction yields zero readable data, symmetric database encryption is applied:

  • // CRYPTOGRAPHIC KEY DERIVATION (KDF): Instead of using the raw DB_SECRET, the application passes it through a Key Derivation Function: crypto.scryptSync(secret, 'secure_salt_quasar', 32) to output a 256-bit symmetric key.
  • // COLUMN-LEVEL AES-256-CBC ENCRYPTION: Sensitive database fields are encrypted via aes-256-cbc with random 16-byte IV vectors prepended (format: iv:ciphertext). Sensitive data includes username_enc and avatar_enc in the users table, payload_enc in the messages table, and filename_enc in the uploaded_files table.
  • // WAL & SYNCHRONOUS TUNING: To maintain high-performance messaging under constant read-writes, SQLite journal mode is set to Write-Ahead Logging (db.pragma('journal_mode = WAL')) and the synchronous mode is set to NORMAL, yielding stable performance without risk of corruption.

5. Encrypted File Streaming & Traversal Mitigation

File transfers are end-to-end encrypted (E2EE) and isolated from the host filesystem structure:

  • // ENCRYPTED UPLOAD FLOW: Uploading to /upload requires a valid JWT. The client sends custom headers: x-file-iv, x-file-name, and x-file-type. The server validates size limitations (up to 10MB) dynamically, streams the encrypted payload into a random UUID v4 filename inside data/uploads/, and encrypts the metadata (filename) in the database using encryptDB().
  • // PATH TRAVERSAL DEFEAT: The download endpoint /file/:id validates the file ID against a formal UUID v4 regular expression: /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. Any path traversal attempt (e.g. ../../etc/passwd) is blocked at the routing layer with a 400 Bad Request.

6. Automated Garbage Collection & DB Sanitization

To maintain a low footprint and secure volatile state, the server runs a background job every 30 minutes:

// Message History Cap / Límite de Historial de Mensajes
DELETE FROM messages WHERE id NOT IN (SELECT id FROM messages ORDER BY timestamp DESC LIMIT 300)
// 7-Day File Retention & DB Vacuuming / Purga de Archivos de 7 Días y Desfragmentación
// Deletes files older than 7 days from physical disk & database
// Runs SQLite VACUUM to reclaim disk sectors and scrub fragments

7. Signaling Orchestration & Frontend Sanitization

Beyond server infrastructure, the frontend client introduces unique features and DOM XSS mitigations:

  • // SECURE USER LIST IMAGE PROTOCOLS: To prevent persistent XSS via bad image attributes (e.g. onerror or javascript: execution in profile cards), the React UserList.jsx component filters incoming user avatars. It parses the URL, validating that the protocol matches http:, https:, or safe data:image/ schemes, falling back to a safe neutral avatar upon mismatch.
  • // MULTI-STREAM SIGNALING: The socket connection separates media signaling into three standard scopes: WebRTC audio/video connections (signal), multi-recipient screen sharing (screen_signal), and synchronized media streaming (music_sync) to coordinate live client playback.
` }; window.ARTICLES_CONTENT['quasar-hardening-architecture'] = { title: "Quasar Secure — Architectural Hardening & Vulnerability Mitigation", date: "2026-05-29", author: "Eduardo Camarillo [Noir0x63]", version: "VERIFIED v1.0", content: `

Quasar Secure — Beyond Cryptography: Architectural Hardening & Vulnerability Mitigation

Date:
STATUS: AUDITED

1. The Core Thesis: Why Strong Crypto is Never Enough

A common pitfall in secure software engineering is relying solely on cryptographic algorithms to secure a system. An application can employ mathematically flawless AES-GCM or RSA-4096 tunnels, yet remain entirely vulnerable to compromise if its architectural foundation is weak. If an attacker can exploit a Path Traversal bug to read the server's .env configuration file, they will extract the raw database keys and JWT secrets, rendering the database encryption useless. If the process runs with root privileges, any remote code execution (RCE) grants host takeover. If the UI lacks protocol sanitization, an attacker can bypass encryption entirely by injecting an XSS payload that exfiltrates decrypted messages straight from client memory. Quasar's design demonstrates that true security is a function of system-wide architectural hardening.

2. OS Execution Hardening & System Restraints

Quasar implements defenses at the boundary between the application and the host operating system, reducing the potential impact of exploits:

  • // PRIVILEGE REDUCTION & CONTAINER SECURITY: The server checks process.getuid() === 0 at startup. If executed inside a root context, it immediately aborts. This prevents attackers from gaining full root access to the host kernel or docker host interface if they find an application exploit, suppressing privilege escalation vectors.
  • // DYNAMIC RUNTIME TAMPER MITIGATION (FIM): Memory injection and hot-patching are active threats to Node.js servers. The continuous fs.watch() daemon monitors core modules. If any script is altered on disk or dynamic patch attempts are made, the server shuts down immediately. This mitigates persistent server-side malware implants.

3. Sandboxed File Operations & Sandboxed Routing

File uploads are high-risk entry points. Quasar sandboxes files on disk and isolates them at the routing level to mitigate path traversals and arbitrary system reading:

  • // FILENAME SANITIZATION & METADATA SEPARATION: When a file is uploaded, the original name is encrypted in the SQLite DB. On disk, the file is saved under a cryptographically random UUID v4 string (e.g. data/uploads/9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d). This destroys the original extension and name, blocking attackers from uploading executable scripts (e.g. .js or .php) and triggering them on the host.
  • // REGEX UUID PATH TRAVERSAL DEFENSE: The download route /file/:id utilizes a strict UUID validation regex: /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. If an attacker submits a path-traversal request (e.g. /file/../../.env), the server rejects it at the regex layer, preventing unauthorized system file extraction.

4. API Rate Limiting & Denial of Service (DoS) Hardening

To prevent memory depletion and application lockups caused by abuse, Quasar includes active DoS protection mechanisms:

  • // SLIDING-WINDOW API LIMITER: The socket.io handlers and authentication routes are bounded by sliding-window rate limit maps. IPs that exceed 5 events per second are temporarily throttled, neutralizing brute-force password checking and automated message flooding.
  • // STREAM BUFFER SIZE RESTRICTION: Upload streams are dynamically bounded. The server monitors incoming chunks in real-time, aborting the request, destroying the active write stream, and deleting the temporary disk buffer instantly if the upload size exceeds MAX_UPLOAD_BYTES. This mitigates RAM starvation and disk-fill attacks.

5. DOM-Level Sanitization & XSS Prevention

Cross-Site Scripting (XSS) is a critical threat to E2EE chats. If an attacker can inject and run JavaScript inside another client's browser, they can extract the E2EE keys or read raw chat texts directly. Quasar mitigates this through defensive measures:

  • // PROTOCOL WHITELIST FILTERING: To prevent malicious URLs from injecting javascript (e.g. <img src="javascript:alert(1)">) inside user avatar links, the React component UserList.jsx parses and checks incoming links against strict protocol schemes (http:, https:, and safe data:image/ types), stripping malicious protocols instantly.
  • // GLOBAL CONTENT-SECURITY-POLICY (CSP) RESTRICTIONS: The backend applies strict CSP headers on every request. Scripts can only be executed if they originate from 'self' or strict verified CDNs. Object injections are disabled (object-src 'none'), base URI modifications are banned (base-uri 'none'), and framing is completely disabled (X-Frame-Options: DENY) to prevent Clickjacking and script injection bypasses.

Related Articles