0Pricing
Secure Coding & OWASP Top 10 for Backend · レッスン

高度なSQLiおよびNoSQLiの手法

より複雑なSQLインジェクションおよびNoSQLインジェクションのシナリオを検証し、効果的に対処するための高度な防御コーディングパターンを学習します。

「高度なSQLiおよびNoSQLiの手法」はCoddyKit上の無料Secure Coding & OWASP Top 10 for Backendレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSecure Coding & OWASP Top 10 for Backend学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Secure Coding & OWASP Top 10 for Backendコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Deeper Dive into SQLi

You've learned about basic SQL injection (SQLi), where direct user input manipulates database queries. However, attackers use more subtle and complex methods to bypass defenses.

In this lesson, we'll explore these 'advanced' SQLi techniques, like blind and second-order injections, and then shift our focus to NoSQL injection vulnerabilities. Most importantly, we'll cover how to defend against them effectively!

What is Blind SQL Injection?

Blind SQL Injection (Blind SQLi) occurs when an application is vulnerable to SQLi, but its HTTP responses do not directly show the results of the SQL query or any error messages.

Instead, an attacker must infer information by observing the application's behavior or response times. There are two main types of Blind SQLi:

  • Boolean-based Blind SQLi: The attacker observes changes in page content (e.g., a specific message appears or disappears) based on true/false conditions of injected statements.
  • Time-based Blind SQLi: The attacker infers data by observing delays in the server's response time, triggered by injected database functions.

Time-Based Blind SQLi Demo

Attackers can use database functions that delay execution, such as SLEEP() (MySQL) or PG_SLEEP() (PostgreSQL), to infer data. If a condition they inject is true, the delay occurs; if false, it doesn't.

For example, a *vulnerable* query might be exploited to check if the first letter of a password is 'a':

SELECT * FROM users WHERE username = 'admin' AND IF(SUBSTRING(password, 1, 1) = 'a', SLEEP(5), 0);

A secure approach always uses parameterized queries, treating all user input as data, not code. Try running the secure example:

import sqlite3
import time

def get_user_data_secure(username):
    conn = sqlite3.connect(':memory:')
    cursor = conn.cursor()
    cursor.execute('''
        CREATE TABLE IF NOT EXISTS users (
            id INTEGER PRIMARY KEY,
            username TEXT NOT NULL,
            password TEXT NOT NULL
        )
    ''')
    cursor.execute("INSERT INTO users (username, password) VALUES (?, ?)", ('admin', 'securepassword'))
    conn.commit()

    # Secure query using parameterized statement
    query = "SELECT username FROM users WHERE username = ?"
    start_time = time.time()
    cursor.execute(query, (username,))
    result = cursor.fetchone()
    end_time = time.time()

    print(f"Query for '{username}' took {end_time - start_time:.4f} seconds.")
    if result:
        print(f"Found user: {result[0]}")
    else:
        print("User not found or query failed.")

    conn.close()

if __name__ == "__main__":
    print("--- Secure Query Example ---")
    get_user_data_secure("admin")
    get_user_data_secure("nonexistent")

Protecting from Blind SQLi

The best defense against blind SQLi is the same as for regular SQLi: parameterized queries or prepared statements. These methods ensure that SQL code is strictly separated from user input.

By treating all user-provided data as literal values, it becomes impossible for an attacker to inject malicious commands, regardless of whether the output is visible or not.

  • Always validate and sanitize user input rigorously.
  • Use a Web Application Firewall (WAF) to filter malicious requests.
  • Monitor database access patterns for anomalies or unusually long query times.

Second-Order SQL Injection

Second-Order SQL Injection occurs when malicious input is first stored in a database (or another persistent storage) and then later retrieved and used in another query without proper re-sanitization.

This type of injection is often harder to detect during initial testing because the first interaction with the input might seem harmless. The vulnerability only manifests when the stored data is used in a different context or at a later time.

Think of it like a delayed-action bomb – the fuse is lit now, but the explosion happens later!

Second-Order SQLi Scenario

Consider a scenario where a user registers with a username like 'admin'--. When this username is initially stored, it might be handled safely.

However, later, an admin panel fetches user details using a query constructed by concatenating the stored username:

SELECT email FROM users WHERE username = ' . $username_from_db . ';

If $username_from_db (which now contains 'admin'--) is not re-sanitized before being used in this second query, the comment (--) could truncate the query. This might allow the attacker to bypass conditions or reveal sensitive data, as the query effectively becomes SELECT email FROM users WHERE username = 'admin'.

Introduction to NoSQL Injection

NoSQL databases, such as MongoDB, Cassandra, and Redis, do not use the traditional SQL query language. However, they are still vulnerable to injection attacks if user input is not handled correctly.

Attackers manipulate the data structures (e.g., JSON, BSON, XML) used in NoSQL queries to:

  • Bypass authentication and gain unauthorized access.
  • Access or modify unauthorized data.
  • Perform denial-of-service attacks by crafting complex queries.

The specific techniques depend heavily on the NoSQL database type and its unique query language or API.

MongoDB Operator Injection

A common NoSQL injection technique in MongoDB involves manipulating query operators. MongoDB queries often use JSON-like objects with special operators (e.g., $eq for equals, $gt for greater than, $ne for not equal).

If a backend constructs a MongoDB query directly from user input without validation, an attacker could inject these operators. For example, injecting {"password": {"$ne": null}} into a password field could bypass authentication by matching any non-null password, rather than a specific one.

This allows them to find records that match conditions other than exact equality.

NoSQLi Example (MongoDB)

Consider a login function that takes a username and password. If the password is used directly in a MongoDB query without sanitation, an attacker can bypass it.

Here's a *simulated* secure Python example, showing how proper handling prevents injection, even if an attacker tries to pass a crafted string like '{" $ne": None}'.

def simulate_mongodb_login(username, password):
    # Simulate a collection in memory
    users_db = [
        {"username": "admin", "password": "secure_password123"},
        {"username": "guest", "password": "guestpass"}
    ]

    print(f"Attempting login for '{username}' with password '{password}'")

    # --- VULNERABLE CONCEPT --- 
    # If 'password' was parsed as a JSON object directly into the query:
    # Attacker input: password = {"$ne": None}
    # This would become: {"username": "admin", "password": {"$ne": None}}
    # which means "password not equal to None" and matches any non-null password.

    # --- SECURE APPROACH --- 
    # Always treat user input as a literal string unless explicitly parsed and validated.
    # This ensures 'password' is treated as a literal string, preventing operator injection.
    for user in users_db:
        if user["username"] == username and user["password"] == password:
            print(f"Login SUCCESS for {username} (secure). ")
            return True
    print(f"Login FAILED for {username} (secure).")
    return False

if __name__ == "__main__":
    print("--- NoSQLi Secure Login Example ---")
    simulate_mongodb_login("admin", "secure_password123") # Correct password
    simulate_mongodb_login("admin", "wrong_password")     # Incorrect password
    # Simulate attempted bypass with a crafted password string:
    simulate_mongodb_login("admin", '{"$ne": None}') # Still fails due to secure handling

Preventing NoSQL Injection

The primary defense against NoSQL injection is rigorous input validation and sanitization. Since NoSQL databases have diverse query languages, the specific defenses can vary, but core principles remain:

  • Whitelisting: Only allow known safe characters, patterns, or specific data types. Reject anything that doesn't fit.
  • Strong Typing: Ensure that expected numbers are numbers, strings are strings, and boolean values are booleans.
  • Driver APIs: Always use the NoSQL database driver's built-in APIs for query construction. These APIs are designed to prevent injection by treating user input as data, not code.
  • Avoid Concatenation: Never concatenate user input directly into query strings or JSON structures without proper escaping or parameterization.
  • Least Privilege: Database users should only have the minimum necessary permissions.

Quick Check: Injection Types

Test your understanding of advanced injection techniques.

Recap & Next Steps

We've explored advanced SQL and NoSQL injection techniques that go beyond simple direct manipulation:

  • Blind SQLi (both time-based and boolean-based) infers data without direct database output.
  • Second-Order SQLi involves storing malicious input which is executed in a later, separate query.
  • NoSQL Injection targets NoSQL query structures (e.g., MongoDB operators) to manipulate database operations.

The best defenses remain robust input validation, parameterized queries for SQL, and using safe driver APIs for NoSQL. Always assume all input is hostile and validate everything!

よくある質問

「高度なSQLiおよびNoSQLiの手法」レッスンは無料ですか？

はい。「高度なSQLiおよびNoSQLiの手法」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Secure Coding & OWASP Top 10 for Backendコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Secure Coding & OWASP Top 10 for Backendコースには全4レッスンが含まれています。

「高度なSQLiおよびNoSQLiの手法」で何を学びますか？

より複雑なSQLインジェクションおよびNoSQLインジェクションのシナリオを検証し、効果的に対処するための高度な防御コーディングパターンを学習します。 ブラウザで直接実行するハンズオンコードでSecure Coding & OWASP Top 10 for Backendを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Secure Coding & OWASP Top 10 for Backendを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSecure Coding & OWASP Top 10 for Backendは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。

「高度なSQLiおよびNoSQLiの手法」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSecure Coding & OWASP Top 10 for Backendレッスンでコードを書いて実行できますか？

はい。すべてのSecure Coding & OWASP Top 10 for Backendレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 高度なSQLiおよびNoSQLiの手法
  2. 包括的な入力検証戦略
  3. バックエンド向けContent Security Policy（CSP）
  4. コマンドインジェクションとLDAPインジェクションの防止
← Secure Coding & OWASP Top 10 for Backendに戻る