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

SSRF攻撃の防止

URLを検証し、外部へのネットワーク要求を制限することで、Server-Side Request Forgery（SSRF）の脆弱性を特定して軽減する方法を学習します。

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

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

Understanding SSRF Attacks

Server-Side Request Forgery (SSRF) is a critical web security vulnerability. It tricks a server into making requests to an unintended location, often internal resources or other external services.

Imagine your backend application acts as a proxy, fetching data or resources on behalf of a user. If an attacker can control the destination of these requests, you have an SSRF vulnerability.

How SSRF Works

Here's how SSRF typically works:

  • Your application accepts a URL from a user.
  • The server then makes a request to that URL to fetch data (e.g., an image, a file, a webpage).
  • An attacker provides a malicious URL, pointing to an internal IP address or a sensitive service.
  • The server, trusting the input, makes the request, potentially exposing internal data or services.

The Dangers of SSRF

The consequences of a successful SSRF attack can be severe:

  • Access to internal systems: Attackers can scan internal networks, access databases, or administrative interfaces.
  • Cloud metadata exposure: On cloud platforms (AWS, GCP, Azure), SSRF can expose sensitive instance metadata, including temporary credentials.
  • Interaction with other services: The server might be forced to interact with other APIs or services it has access to, performing unauthorized actions.
  • Port scanning: Attackers can use the server to scan ports on other internal or external machines.

Vulnerable Code in Action

Consider a simple backend service that fetches content from a user-provided URL. This Java example shows a common pattern that can lead to SSRF.

The fetchContent method directly uses a user-supplied URL to make an HTTP request without validation.

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;

public class Main {
  public static void main(String[] args) {
    // In a real app, this URL would come from user input (e.g., a web parameter)
    String userSuppliedUrl = "http://example.com/data.txt";
    // Malicious example: "http://169.254.169.254/latest/meta-data/"

    try {
      System.out.println("Fetching content from: " + userSuppliedUrl);
      String content = fetchContent(userSuppliedUrl);
      System.out.println("--- Fetched Content ---");
      System.out.println(content.substring(0, Math.min(content.length(), 100)) + "...");
      System.out.println("-----------------------");
    } catch (Exception e) {
      System.err.println("Error fetching content: " + e.getMessage());
    }
  }

  public static String fetchContent(String urlString) throws Exception {
    URL url = new URL(urlString);
    URLConnection connection = url.openConnection();
    BufferedReader in = new BufferedReader(
        new InputStreamReader(connection.getInputStream()));
    String inputLine;
    StringBuilder content = new StringBuilder();
    while ((inputLine = in.readLine()) != null) {
      content.append(inputLine);
    }
    in.close();
    return content.toString();
  }
}

The Power of Whitelisting

The most robust defense against SSRF is whitelisting. Instead of trying to block bad inputs, you should only allow known, safe inputs.

For URLs, this means defining a strict list of permitted domains, hostnames, or IP addresses that your application is allowed to connect to. Any request to a destination not on this list should be blocked.

Code for URL Whitelisting

Let's update our previous example to include a whitelist check. We'll define allowed domains and check the input URL against them before making any network requests.

This makes sure the server only connects to trusted external services.

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;
import java.util.Arrays;
import java.util.List;

public class Main {
  private static final List<String> ALLOWED_HOSTS = Arrays.asList(
      "example.com", "mytrustedapi.com"
  );

  public static void main(String[] args) {
    String safeUrl = "http://example.com/data.txt";
    String maliciousUrl = "http://badsite.com/evil.php";

    try {
      System.out.println("\nAttempting to fetch from: " + safeUrl);
      String content = fetchContentSafely(safeUrl);
      System.out.println("Fetched (safe): " + content.substring(0, Math.min(content.length(), 50)) + "...");
    } catch (Exception e) {
      System.err.println("Error fetching (safe): " + e.getMessage());
    }

    try {
      System.out.println("\nAttempting to fetch from: " + maliciousUrl);
      String content = fetchContentSafely(maliciousUrl);
      System.out.println("Fetched (malicious): " + content.substring(0, Math.min(content.length(), 50)) + "...");
    } catch (Exception e) {
      System.err.println("Error fetching (malicious): " + e.getMessage());
    }
  }

  public static String fetchContentSafely(String urlString) throws Exception {
    URL url = new URL(urlString);
    String host = url.getHost();

    if (!ALLOWED_HOSTS.contains(host)) {
      throw new IllegalArgumentException("Host not allowed: " + host);
    }

    URLConnection connection = url.openConnection();
    BufferedReader in = new BufferedReader(
        new InputStreamReader(connection.getInputStream()));
    String inputLine;
    StringBuilder content = new StringBuilder();
    while ((inputLine = in.readLine()) != null) {
      content.append(inputLine);
    }
    in.close();
    return content.toString();
  }
}

Blacklisting: A Risky Approach

You might think blacklisting known bad IPs or domains is easier. However, blacklisting is inherently weak against SSRF.

Attackers can use various tricks to bypass blacklists:

  • IP address encoding: Using decimal, octal, or hexadecimal representations (e.g., http://0x7f000001 for localhost).
  • DNS rebinding: Changing DNS records to point a 'safe' domain to an internal IP after the initial check.
  • URL shorteners: Masking malicious URLs behind a seemingly benign short URL.
  • Special protocols: Using file://, gopher://, or data:// schemes if not explicitly blocked.

Always prefer whitelisting!

Layered Defense: Network Rules

Beyond application-level URL validation, you should also implement network-level controls:

  • Firewall rules: Configure firewalls to block outgoing connections from your application server to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1/8).
  • Network segmentation: Isolate the server making external requests into its own network segment, with minimal access to other internal resources.
  • Least privilege: Ensure the application's runtime environment has only the necessary network access.

These measures provide a crucial second layer of defense.

Tricky URLs and Redirects

SSRF attacks can also exploit nuances in URL handling:

  • Inconsistent URL parsers: Different libraries or systems might interpret a URL differently, potentially bypassing your validation. Always use a consistent, robust parser.
  • HTTP Redirects: An attacker might provide a whitelisted URL that then redirects to a blacklisted internal IP. Your application must follow redirects carefully and re-validate the final destination URL.

Always validate the resolved URL after any redirects and before making the final request.

Preventing SSRF Attacks

Which of the following is the most effective strategy to prevent Server-Side Request Forgery (SSRF) vulnerabilities?

Recap: Secure Against SSRF

You've learned how to identify and prevent SSRF attacks!

  • SSRF allows a server to make unauthorized requests to internal or external systems.
  • The most effective defense is URL whitelisting, allowing connections only to trusted destinations.
  • Avoid blacklisting, as it's prone to bypasses.
  • Supplement application-level defenses with network firewalls and segmentation.
  • Be cautious of URL parsing inconsistencies and always re-validate URLs after redirects.

Keep your backend secure by strictly controlling outgoing connections!

よくある質問

「SSRF攻撃の防止」レッスンは無料ですか？

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

「SSRF攻撃の防止」で何を学びますか？

URLを検証し、外部へのネットワーク要求を制限することで、Server-Side Request Forgery（SSRF）の脆弱性を特定して軽減する方法を学習します。 ブラウザで直接実行するハンズオンコードでSecure Coding & OWASP Top 10 for Backendを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

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

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

「SSRF攻撃の防止」レッスンにはどのくらい時間がかかりますか？

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

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

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

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

  1. 安全なRESTful APIの設計
  2. GraphQL APIのセキュリティ
  3. SSRF攻撃の防止
  4. APIのレート制限とスロットリング
← Secure Coding & OWASP Top 10 for Backendに戻る