SSRF là gì? Hướng dẫn chi tiết và cách phòng chống trong WordPress

SSRF là gì? Hướng dẫn chi tiết và cách phòng chống trong WordPress

SSRF (Server-Side Request Forgery) đang ngày càng xuất hiện nhiều trong các báo cáo pentest, bug bounty và cả lỗ hổng WordPress core. Nếu bạn đang viết plugin/theme hoặc vận hành site WordPress, hiểu rõ SSRF và cách phòng chống là chuyện bắt buộc phải biết, không chỉ là “nice to have”.

SSRF (Server-Side Request Forgery) là gì?

SSRF là lỗ hổng bảo mật cho phép kẻ tấn công lợi dụng chính server của bạn để gửi các request tới tài nguyên nội bộ (internal services), localhost hoặc hệ thống bên ngoài khác. Thay vì tấn công trực tiếp từ máy của hắn, attacker “mượn tay” server để gửi request, từ đó có thể vượt qua firewall, WAF hoặc các cơ chế kiểm soát truy cập thông thường.

Điểm chung của các lỗi SSRF là: ứng dụng cho phép người dùng truyền vào một URL, sau đó server sẽ dùng URL đó để gọi ra ngoài (HTTP request, tải file, proxy hình ảnh, gọi API…), nhưng lại không kiểm tra hoặc kiểm tra không đủ chặt URL mà người dùng truyền vào.

Các kiểu tấn công SSRF phổ biến

Về cơ bản, có hai kiểu SSRF chính:

• Basic SSRF: Response từ server được trả ngược lại cho attacker. Ví dụ, attacker truyền URL trỏ vào dịch vụ nội bộ, server fetch nội dung và echo lại toàn bộ body, dẫn đến lộ config, credential, thông tin hệ thống…
• Blind SSRF: Response thực tế không được trả cho attacker (hoặc chỉ là status code/thông báo chung chung). Tuy nhiên, attacker vẫn có thể dùng nó để:
  • Scan port và liệt kê dịch vụ nội bộ dựa trên thời gian phản hồi hoặc status code.
  • Gửi request đến các endpoint nhạy cảm như metadata service của cloud (ví dụ http://169.254.169.254/).

Ngoài ra, SSRF không chỉ giới hạn ở HTTP. Nếu code hỗ trợ, attacker có thể lợi dụng các scheme như file://, gopher://, ftp://… để đọc file hệ thống hoặc tương tác với dịch vụ khác.

Vì sao SSRF nguy hiểm?

Mức độ nguy hiểm của SSRF phụ thuộc vào việc server của bạn có thể “nhìn thấy” những gì trong mạng nội bộ và hạ tầng cloud:

• Truy cập tài nguyên nội bộ: Database management, panel nội bộ, service admin chỉ mở trong LAN, API nội bộ…
• Đọc metadata cloud: Nhiều nhà cung cấp cloud có metadata service cho phép lấy credential hoặc thông tin nhạy cảm.
• Bypass firewall / WAF: Request xuất phát từ chính server nên nhìn từ ngoài vào rất “hợp lệ”, dễ vượt qua nhiều lớp lọc.
• Pivot sang tấn công sâu hơn: Từ SSRF có thể dẫn đến RCE, đánh cắp dữ liệu, chiếm quyền tài nguyên khác.
• DoS: Ép server spam request đến một mục tiêu hoặc tiêu tốn tài nguyên của chính server.

SSRF trong WordPress diễn ra như thế nào?

WordPress là một nền tảng thường xuyên kéo dữ liệu từ bên ngoài: oEmbed, pingback, REST API, image fetch, webhooks,… Kết hợp với vô số plugin lấy URL từ user input, SSRF trong WordPress trở thành dạng lỗ hổng rất thường gặp.

Một số pattern thường thấy trong plugin/theme WordPress:

• Form cho phép user nhập URL rồi server dùng wp_remote_get() hoặc wp_safe_remote_get() để fetch nội dung.
• Image proxy: truyền tham số ?url=... rồi server tải ảnh về và trả lại cho client.
• Webhook / integration với dịch vụ ngoài: “nhập URL webhook” và plugin gọi trực tiếp tới URL đó.
• Chức năng preview, link checker, oEmbed tự động lấy metadata từ URL người dùng nhập.

Ví dụ mã dễ bị SSRF trong WordPress

Ví dụ một đoạn code trong plugin:

<?php
// /wp-content/plugins/vulnerable-plugin/fetch.php

add_action( 'init', function () {
    if ( ! isset( $_GET['url'] ) ) {
        return;
    }

    // Sai lầm: dùng trực tiếp URL do user cung cấp
    $url      = $_GET['url'];
    $response = wp_remote_get( $url );

    if ( is_wp_error( $response ) ) {
        wp_die( 'Request error' );
    }

    // Sai lầm tiếp theo: trả nguyên body cho user
    $body = wp_remote_retrieve_body( $response );
    echo $body;
    exit;
} );

Attacker chỉ cần truy cập:

https://example.com/wp-content/plugins/vulnerable-plugin/fetch.php?url=http://127.0.0.1:8080/admin

Nếu server của bạn truy cập được service nội bộ tại 127.0.0.1:8080, toàn bộ response của trang admin có thể bị lộ ra bên ngoài.

Một vài case SSRF trên WordPress core và plugin

1. SSRF qua pingback trong WordPress core

Cơ chế pingback từng nhiều lần bị lợi dụng để thực hiện SSRF. Ý tưởng chung là WordPress tin tưởng URL trong pingback, dẫn tới việc gửi request tới các địa chỉ do attacker chỉ định (bao gồm cả internal host) nếu validation không chặt.

2. SSRF trong plugin WordPress

• Nhiều plugin bị ghi nhận SSRF do truyền URL user-input vào wp_remote_get() mà không validate, kết hợp thiếu CSRF check trong AJAX khiến attacker từ bên ngoài có thể trigger request.
• Các plugin AI/automation, marketing, backup… có chức năng “gọi API tùy chỉnh” hoặc “tự nhập URL endpoint” cũng thường là điểm rơi SSRF nếu dev không giới hạn domain.

3. wp_remote_get() vs wp_safe_remote_get()

wp_safe_remote_get() giúp giảm rủi ro hơn nhờ validation chặt hơn, nhưng nếu dev vẫn cho user nhập URL tuỳ ý thì SSRF vẫn xảy ra.

Cách phòng chống SSRF trong WordPress

1. Validate và sanitize URL

• Chỉ cho phép scheme http và https.
• Dùng esc_url_raw(), filter_var(), parse_url() kiểm tra host/port/path.

2. Dùng allowlist domain/IP

$allowed_hosts = array(
    'api.example.com',
    'cdn.example.com',
);

$host = wp_parse_url( $url, PHP_URL_HOST );

if ( ! in_array( $host, $allowed_hosts, true ) ) {
    return new WP_Error( 'forbidden_host', 'Host không được phép.' );
}

3. Không trả raw response

• Không echo thẳng body từ remote request.
• Nếu cần hiển thị, hãy parse hoặc lọc nội dung.

4. Chú ý redirect và DNS rebinding

• Tắt auto-follow redirect nếu không cần.
• Luôn re-validate URL sau redirect.
• Kiểm tra IP thực tế sau khi resolve DNS.

5. Không phụ thuộc hoàn toàn vào wp_safe_remote_get()

6. Tăng cường bảo mật hạ tầng

• Firewall outbound theo “deny by default”.
• Tách network cho các dịch vụ nhạy cảm.
• Giám sát outbound traffic bất thường.

7. Với admin site

• Luôn cập nhật WordPress/plugin/theme.
• Vô hiệu hóa pingback/XML-RPC nếu không cần.

Safe HTTP wrapper cho WordPress dev

<?php
function myplugin_safe_http_get( $url, $args = array() ) {
    $url = esc_url_raw( $url );
    if ( ! $url || ! filter_var( $url, FILTER_VALIDATE_URL ) ) {
        return new WP_Error( 'invalid_url', 'URL không hợp lệ.' );
    }

    $scheme = wp_parse_url( $url, PHP_URL_SCHEME );
    if ( ! in_array( $scheme, array( 'http', 'https' ), true ) ) {
        return new WP_Error( 'invalid_scheme', 'Scheme không được phép.' );
    }

    $allowed_hosts = array( 'api.example.com', 'cdn.example.com' );
    $host          = wp_parse_url( $url, PHP_URL_HOST );

    if ( ! in_array( $host, $allowed_hosts, true ) ) {
        return new WP_Error( 'forbidden_host', 'Host không được phép.' );
    }

    $default_args = array(
        'timeout'     => 5,
        'redirection' => 0,
    );

    $response = wp_safe_remote_get( $url, wp_parse_args( $args, $default_args ) );

    if ( is_wp_error( $response ) ) {
        return $response;
    }

    return wp_remote_retrieve_body( $response );
}

Kết luận

SSRF trong WordPress là lỗ hổng nguy hiểm và xuất hiện rất nhiều trong plugin lẫn core. Mọi chỗ cho phép user nhập URL đều cần được xem như “vùng nguy hiểm” cần kiểm tra chặt chẽ. Chỉ cần một lỗi nhỏ là attacker có thể bẻ lái server của bạn theo ý hắn.