5. Securing Applications and Data

Symmetric Encryption

Symmetric encryption uses a single shared key to both encrypt and decrypt data. Both parties must possess the same key before communication can begin.

• Algorithm: AES (Advanced Encryption Standard) — 128-bit, 192-bit, or 256-bit key lengths. Current industry standard for bulk data encryption.
• Advantage: Very fast — suitable for encrypting large volumes of data.
• Disadvantage: The key distribution problem — how do two parties securely share the key in the first place? If the key is intercepted, all encrypted data is compromised.
• Use cases: Encrypting files at rest (disk encryption), encrypting bulk data once a secure channel is already established (e.g., after a TLS handshake).

Asymmetric Encryption

Asymmetric encryption uses a mathematically linked key pair: a public key (shared freely) and a private key (kept secret by the owner). Data encrypted with the public key can only be decrypted with the private key, and vice versa.

• Algorithm: RSA (Rivest–Shamir–Adleman) — key sizes of 2048-bit or 4096-bit are standard.
• Advantage: Solves the key distribution problem — the public key can be shared over any channel without risk.
• Disadvantage: Much slower than symmetric encryption — not suitable for bulk data.
• Use cases: Key exchange (securely sharing an AES session key), digital signatures, certificate-based authentication.

The Hybrid Model: How TLS Works

TLS (Transport Layer Security, the protocol behind HTTPS) combines both encryption types in a handshake process:

1. Handshake begins: Client and server agree on cipher suites and TLS version.
2. Certificate presented: Server sends its X.509 certificate (containing its public key). Client verifies the certificate against a trusted Certificate Authority.
3. Key exchange: Client uses the server's public key (asymmetric) to securely send or derive a shared session key.
4. Symmetric encryption begins: All subsequent data is encrypted with the shared AES session key (fast, symmetric). The asymmetric exchange is complete.

Why hybrid? Asymmetric is too slow for bulk data; symmetric has the key distribution problem. TLS uses asymmetric to solve the key distribution problem once, then symmetric for everything after.

Digital Signatures

A digital signature provides authentication (the message came from the claimed sender), integrity (the message was not altered in transit), and non-repudiation (the sender cannot later deny sending it).

How signing works:

1. The sender computes a hash of the message.
2. The sender encrypts the hash with their private key — this is the digital signature.
3. The recipient decrypts the signature using the sender's public key, recovering the hash.
4. The recipient independently hashes the received message. If both hashes match, the message is authentic and unaltered.

Non-repudiation: Only the owner of the private key could have produced the signature — so the sender cannot later deny having sent the message.

PKI and X.509 Certificates

Public Key Infrastructure (PKI) is the system of trust that verifies that a public key actually belongs to who it claims to belong to.

• Certificate Authority (CA): A trusted third party that issues digital certificates. Root CAs are pre-installed in operating systems and browsers. Intermediate CAs issue certificates to end entities.
• X.509 certificate: A digital document containing the subject's identity (domain name, organization), their public key, the CA's signature over the certificate, and an expiry date.
• Certificate chain: From the end-entity certificate up through intermediate CA(s) to the root CA. Browsers verify the entire chain.
• Revocation: If a certificate is compromised before expiry: CRL (Certificate Revocation List) — a published list of revoked certificates; OCSP (Online Certificate Status Protocol) — a real-time revocation check.
• HSTS (HTTP Strict Transport Security): A server response header instructing browsers to only connect via HTTPS, even if the user types HTTP. Prevents downgrade attacks.

Application Vulnerabilities

Vulnerability	Mechanism	Countermeasure
SQL Injection	Attacker inserts SQL code into an input field. If the application concatenates the input directly into a query, the malicious SQL executes, exposing or modifying the database.	Parameterized queries (prepared statements) — the database treats user input as data, never as executable SQL code.
Cross-Site Scripting (XSS)	Attacker injects malicious JavaScript into a web page. When other users load the page, their browser executes the script, enabling session hijacking, credential theft, or page defacement.	Input validation (reject unexpected characters); output encoding (convert special characters to HTML entities so they display rather than execute).
Buffer Overflow	Program writes more data to a memory buffer than it can hold. Excess data overwrites adjacent memory, potentially redirecting execution to attacker-supplied code.	Input length validation; memory-safe programming languages; stack canaries; ASLR (Address Space Layout Randomization).
Insecure Direct Object Reference (IDOR)	Application exposes internal object identifiers (e.g., user IDs in a URL). Attacker manipulates the ID to access another user's data without authorization checks.	Server-side authorization checks on every request; indirect references (map user-visible IDs to internal IDs server-side).

Secure Coding Practices

• Input validation: Reject, sanitize, or escape all input that does not conform to expected type, length, and format before it reaches any processing layer.
• Parameterized queries: Use database APIs that separate SQL structure from user-supplied data, preventing SQL injection regardless of the input content.
• Error handling: Never expose internal system details (stack traces, database error messages, file paths) in error responses visible to users — these provide reconnaissance to attackers.
• Least privilege for application accounts: The database account used by a web application should have only SELECT/INSERT/UPDATE permissions needed — never DROP TABLE or CREATE USER.

Data Protection: At Rest vs. In Transit

• Encryption at rest: Data stored on disk, in databases, or in cloud storage is encrypted so that physical theft of storage media does not expose plaintext data. Full-disk encryption (FDE) and transparent database encryption are common approaches.
• Encryption in transit: Data moving across a network is encrypted so that packet capture cannot expose plaintext. TLS/HTTPS protects web traffic; VPNs protect network-level traffic.
• Data classification: Organizations classify data by sensitivity (public, internal, confidential, restricted) to determine appropriate controls for each tier.
• DLP (Data Loss Prevention): Tools that monitor data movement and block unauthorized exfiltration — e.g., preventing an employee from uploading a file matching a confidential pattern to a personal cloud storage service.

Worked FRQ Scenario: Unit 5 Style