Course 38 - Web Security Known Web Attacks | Episode 3: RFD, Mutation XSS, and RPO

Course 39 - NodeJS Security Pentesting and Exploitation | Episode 3: Hardening Code and Preventing Attacks

In this lesson, you’ll learn about: securing Node.js applications through safe coding practices, HTTP security headers, ReDoS protection, and preventing information disclosure1. Secure Coding in Node.js🔹 Key idea: Secure Node.js applications require strict control over execution context and defaults.🔹 Strict Mode * Enables safer JavaScript execution * Prevents accidental global variables * Forces explicit variable declarations 👉 Key Insight Strict mode reduces “silent” security bugs caused by sloppy scope handling2. HTTP Security Headers (Defense Layer)🔹 Tool: Helmet.js🔹 What it does: Automatically sets important security headers in Express apps.🔹 Key headers it manages: * Content Security Policy (CSP) → blocks malicious scripts * HTTP Strict Transport Security (HSTS) → forces HTTPS * XSS Protection headers → reduces injection risks 👉 Key Insight Headers act as a browser-level security shield3. Secure Cookies🔹 Important flags: * HttpOnly * Blocks JavaScript access to cookies * Secure * Ensures cookies are only sent over HTTPS 👉 Key Insight Even if XSS happens, HttpOnly cookies cannot be stolen via JS4. Regular Expression Denial of Service (ReDoS)🔹 What it is: A performance attack exploiting bad regex patterns🔹 How it works: * Complex input causes exponential backtracking * CPU usage spikes * Server becomes unresponsive 🔹 Common risk area: * Email validation * Input sanitization 👉 Key Insight A “valid” input can still be a computational attack5. Preventing ReDoS Attacks🔹 Strategies: * Avoid overly complex regex patterns * Limit input length * Use safe validation libraries * Benchmark regex performance 👉 Key Insight Security includes performance safety, not just access control6. Information Disclosure Risks🔹 Problem: Attackers learn stack/framework details from responses7. Hiding Technology Fingerprints🔹 Disable default headers * Remove X-Powered-By * Hide framework identity 🔹 Tools:Express.jsExample: * Default headers reveal backend technology * Removing them reduces attack surface visibility 8. Session Cookie Hardening🔹 Risk: Default cookies like connect.sid reveal framework usage🔹 Fix: * Rename cookies * Customize session identifiers 👉 Key Insight Small naming details can expose backend stack9. Custom Error Handling🔹 Problem: Default errors expose: * Stack traces * File paths * Internal logic 🔹 Fix: * Use production-safe error handlers * Return generic messages only 👉 Key Insight Errors should help users—not attackers10. Big PictureYou are learning how to:👉 Harden Node.js applications at multiple layers 👉 Prevent CPU-based DoS attacks (ReDoS) 👉 Reduce information leakage from HTTP responses 👉 Apply production-grade security middlewareMental ModelStrict mode → secure headers → safe cookies → regex safety → hidden fingerprints → controlled errors → hardened application surface You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy [https://linktr.ee/cybercode_academy]

Course 39 - NodeJS Security Pentesting and Exploitation | Episode 2: Mitigating RCE, OS Injection, and Path Traversal Vulnerabilities

In this lesson, you’ll learn about: critical Node.js vulnerabilities caused by unsafe user input handling, including RCE, command injection, XSS, and directory traversal1. Core Security Principle🔹 Key idea: Never trust user input👉 Any data from users must be treated as hostile by default Without validation, it can become a direct execution path into the system.2. Remote Code Execution (RCE) via eval()🔹 Dangerous functions: * eval() * setTimeout() * setInterval() * new Function() 🔹 Why they are riskyThese functions execute raw JavaScript strings🔹 Attack outcomes: * Infinite loops → server crash (DoS) * Forced termination (process.exit()) * Full server takeover (reverse shell execution) 👉 Key Insight If user input reaches an execution function → the server is effectively “remote-controlled”3. Remote OS Command Injection🔹 Vulnerable function: * child_process.exec 🔹 How the attack works: * Input is passed into shell commands * Attacker injects separators like ; * Extra commands execute on the OS 🔹 Example impact: * Read sensitive files (e.g., system password data) * Execute arbitrary system commands 🔹 Safer alternatives: * execFile * spawn 👉 Why they are safer: They treat input as arguments, not executable shell strings4. Cross-Site Scripting (XSS)🔹 Cause: Unsanitized user input reflected into browser output🔹 Impact: * Script execution in victim’s browser * Session hijacking potential * UI manipulation 👉 Key Insight Server-side mistake becomes client-side compromise5. Directory Traversal (Path Traversal)🔹 Technique: Using patterns like: * ../ * repeated directory jumps 🔹 Impact: * Access files outside intended directory * Read sensitive system files * Break application file boundaries 6. Big PictureThis episode shows how Node.js apps fail when: * Input is executed instead of validated * System commands are built from raw strings * Output is rendered without escaping * File paths are not restricted Mental ModelUser input → execution boundary → system access If that chain is not broken at validation → full compromise becomes possible You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy [https://linktr.ee/cybercode_academy]

Course 39 - NodeJS Security Pentesting and Exploitation | Episode 1: From V8 Fundamentals to Namespace and Parameter Pollution

In this lesson, you’ll learn about: Node.js runtime architecture, single-threaded execution risks, global scope vulnerabilities, and HTTP Parameter Pollution (HPP)1. What is Node.js?🔹 Definition: A JavaScript runtime built on: * Node.js * Chrome V8 engine 🔹 Purpose: * Run JavaScript outside the browser * Build scalable server-side applications 👉 Key Insight Node.js is not a framework—it’s a runtime environment2. Node.js Architecture🔹 Core model: * Single-threaded * Event-driven * Non-blocking I/O 🔹 How it works: * One main event loop handles all requests * Async tasks delegated to system threads 👉 Key Insight It scales well—but one bad crash can affect everything3. Single-Threaded Risk🔹 Problem: * One runtime thread handles all requests 🔹 What can go wrong: * Uncaught exception → entire server stops * Memory leak → whole app affected 👉 Key Insight Scalability comes with system-wide fragility4. Global Namespace Pollution🔹 Definition: * Variables declared globally in Node.js are shared across requests 🔹 Risk in Express.js: * Data leakage between users * Shared state corruption 🔹 Example risk: * One user modifies a global variable affecting all users 👉 Key Insight Global state in server apps = security vulnerability5. Why Global Variables Are Dangerous🔹 Issues: * No request isolation * Cross-session data exposure * Hard-to-debug behavior 👉 Key Insight Server logic must be stateless by design6. HTTP Parameter Pollution (HPP)🔹 Definition: * Sending multiple values for the same parameter Example:?id=1&id=2 🔹 Node.js behavior: * Captures all values as an array 👉 Key Insight Unlike some frameworks, Node.js does not automatically collapse parameters7. Why HPP Becomes a Security Issue🔹 Risks: * Bypass filters * Confuse validation logic * Manipulate backend decisions 🔹 Example: * WAF expects single value but receives array 👉 Key Insight Ambiguous input = exploitable behavior8. Comparison With Other Systems🔹 Some frameworks: * Take first value * Or last value 🔹 Node.js: * Keeps all values 👉 Key Insight Predictability differences create security gaps9. Secure Coding Practices🔹 Recommendations: * Avoid global variables * Use request-scoped data only * Validate input as single/expected type * Normalize query parameters 👉 Key Insight Security in Node.js = strict state control10. Big PictureYou are learning:👉 How Node.js architecture enables scalability 👉 Why its design can introduce security risks 👉 How input handling differences create vulnerabilitiesMental ModelEvent loop → shared runtime → global state risk → multi-value input → ambiguous parsing → exploitation opportunity You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy [https://linktr.ee/cybercode_academy]

Course 38 - Web Security Known Web Attacks | Episode 5: SOP Fundamentals and SOME Attack Exploitation via Flash Callbacks

In this lesson, you’ll learn about: Same Origin Policy (SOP), its controlled exceptions, and how attackers exploit it using SOME via Flash callbacks1. What is the Same Origin Policy (SOP)🔹 Definition: * A core browser security rule that restricts how documents interact 🔹 Enforced in: * Web Browsers 🔹 Rule: Two URLs can interact only if all match: * Protocol (HTTP / HTTPS) * Host (domain) * Port 👉 Key Insight SOP prevents unauthorized access between different websites2. Why SOP Exists🔹 Purpose: * Protect user data (cookies, sessions, DOM) 🔹 Without SOP: * Any site could read or modify another site 👉 Key Insight SOP is the foundation of web security isolation3. Soft Exclusions to SOP🔹 Allowed interactions: * * embedding * postMessage API 🔹 Why they exist: * Enable cross-origin communication safely 👉 Key Insight SOP is strict—but not absolute4. Introducing SOME (Same Origin Method Execution)🔹 Definition: * A technique to execute methods across windows using references 🔹 Related concept: * Reverse clickjacking 👉 Key Insight SOME doesn’t break SOP—it works around it5. Role of Flash in SOME Attacks🔹 Technology involved: * Adobe Flash Player 🔹 Bridge: * ActionScript ↔ JavaScript 🔹 Key function: * ExternalInterface.call() 👉 Key Insight Flash acts as a bridge to execute JS indirectly6. How Flash Callbacks Become Vulnerable🔹 Weakness: * Accept user-controlled input 🔹 Restrictions: * Often limited to: * Letters (a–z, A–Z) * Numbers (0–9) * Dot (.) 🔹 Still dangerous because: * Can call existing JS functions 👉 Key Insight Limited input ≠ safe input7. SOME Attack Lifecycle🔹 Step-by-step: 1. Victim visits attacker page 2. Malicious page opens new tab 3. Uses window.opener reference 4. Parent tab redirected to target site 5. Payload executes via callback 👉 Key Insight Attack uses tab relationships + timing8. DOM Manipulation via SOME🔹 Target: * Document Object Model (DOM) 🔹 What attacker can do: * Trigger clicks * Submit forms * Change UI state 👉 Key Insight User actions are simulated without consent9. Real-World Example: WordPress Exploit🔹 Platform: * WordPress 🔹 Vulnerability: * Flash file (video-js.swf) with weak callback 🔹 Attack outcome: * Plugin activated automatically 👉 Key Insight Even mature platforms can have legacy weak points10. Bypassing Filters🔹 Challenge: * Only alphanumeric + dot allowed 🔹 Solution: * Call existing functions like: * window.opener.someFunction 👉 Key Insight Attackers reuse existing trusted functions11. Chaining Actions🔹 Advanced technique: * Open multiple tabs 🔹 Result: * Simulate complex workflows: * Activate plugin * Delete files * Change settings 👉 Key Insight Simple actions can be chained into full compromise12. Why SOME is Powerful🔹 Works when: * XSS is blocked * CSRF is mitigated 🔹 Because: * Uses legitimate browser behavior 👉 Key Insight Security controls can be bypassed via unexpected paths13. How to Prevent SOME Attacks🔹 Remove legacy risks: * Disable Flash completely 🔹 Secure callbacks: * Validate inputs strictly * Avoid dynamic execution 🔹 Protect windows: * Use rel="noopener noreferrer" 👉 Key Insight Modern security = eliminate legacy + validate everything14. Big PictureYou are learning:👉 How SOP protects—but also limits 👉 How attackers abuse allowed behaviors 👉 Why legacy tech (Flash) is dangerousMental ModelSOP restriction → allowed exceptions → weak callback → window reference → method execution → silent attack You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy [https://linktr.ee/cybercode_academy]

Course 38 - Web Security Known Web Attacks | Episode 4: From Phishing to Reverse Clickjacking

In this lesson, you’ll learn about: window.opener risks, phishing via tab manipulation, and Same Origin Method Execution (SOME)1. What is window.openerUsing JavaScript:🔹 Definition: * A property that gives a newly opened tab access to its parent tab 🔹 When it exists: * When a link uses target="_blank" 👉 Key Insight A child tab can control or modify the parent tab2. Why window.opener is Dangerous🔹 Core issue: * Trust between tabs is implicit 🔹 Risk: * The new tab may be malicious or compromised 👉 Key Insight Opening external links creates a hidden trust boundary3. Phishing via window.opener🔹 Attack flow: 1. User clicks link on trusted site 2. New tab opens (attacker-controlled) 3. Attacker uses window.opener 4. Parent tab is redirected to fake login page 👉 Key Insight User thinks they’re still on the trusted site4. Why This Phishing Works🔹 Psychological factor: * User trusts the original tab 🔹 Technical factor: * URL changes silently in background 👉 Key Insight This attack combines technical manipulation + human trust5. Same Origin Method Execution (SOME)🔹 Definition: * Triggering actions in another window using limited scripting capabilities 🔹 Also known as: * Reverse clickjacking 👉 Key Insight Even without full XSS, attackers can still execute actions indirectly6. How SOME Works🔹 Core idea: * Child tab keeps reference to parent * Waits for parent to reach sensitive state * Triggers actions programmatically 👉 Key Insight Timing + reference = powerful attack vector7. Weak Callback Exploitation🔹 Targets: * JSONP endpoints * Legacy browser integrations 🔹 Why they matter: * Accept limited characters * Still allow function execution 👉 Key Insight Even restricted inputs can be abused for execution8. Example Impact of SOME🔹 Possible actions: * Trigger button clicks * Submit forms * Perform sensitive operations 👉 Key Insight User doesn’t need to interact—actions happen silently9. Relation to Other Attacks🔹 Similar to: * Cross-Site Scripting (XSS) * Cross-Site Request Forgery (CSRF) 🔹 Difference: * Uses browser relationships instead of direct injection 👉 Key Insight SOME is a bypass technique when XSS/CSRF are blocked10. Preventing window.opener Attacks🔹 Best practices: * Add rel="noopener noreferrer" to links * Avoid unnecessary target="_blank" * Use strict Content Security Policy (CSP) 👉 Key Insight You must explicitly break the opener relationship11. Defense Against SOME🔹 Strategies: * Avoid JSONP and legacy callbacks * Validate all actions server-side * Implement CSRF protections 👉 Key Insight Never rely on client-side trust12. Big Security Lesson🔹 Core idea: * Browser features can be weaponized 🔹 Reality: * Even “normal” functionality can become an attack vector 👉 Key Insight Security requires understanding how features interact, not just codeKey Takeaways * window.opener allows child tabs to control parent tabs * Can be used for stealth phishing attacks * SOME enables action execution without full XSS * Legacy features increase risk * Proper link attributes and validation are critical Big PictureYou are learning:👉 How browser tab relationships create vulnerabilities 👉 How attackers exploit trust and timing 👉 How modern defenses evolved from these weaknessesMental ModelUser click → new tab → opener reference → parent manipulation → exploitation You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy [https://linktr.ee/cybercode_academy]