🔏API Testing

API là một tập hợp các commands, functions, protocol, objects ... giúp hai phần mềm có thể tương tác trao đổi dữ liệu với nhau .

API Recon

Trước khi bắt đầu kiểm thử API, điều quan trọng đầu tiên là thu thập thông tin về API để xác định bề mặt tấn công

Xác định API Endpoint

GET /api/books HTTP/1.1
Host: example.com

Trong trường hợp này, API endpoint là /api/books, nó được sử dụng để lấy danh sách sách từ một thư viện. Một endpoint khác có thể là /api/books/mystery, giúp lấy danh sách sách thuộc thể loại trinh thám.

Tìm hiểu cách tương tác với API

Dữ liệu đầu vào mà API xử lý:
- Bao gồm các tham số bắt buộc và không bắt buộc mà API yêu cầu.
Các loại yêu cầu mà API chấp nhận:
- Bao gồm các phương thức HTTP được hỗ trợ như GET, POST, PUT, DELETE và các định dạng dữ liệu như JSON, XML.
Giới hạn tốc độ (Rate Limits) và cơ chế xác thực:
- Tìm hiểu xem API có giới hạn số lượng yêu cầu trong một khoảng thời gian hay không.
- Xác định các phương thức xác thực như API Key, OAuth, hoặc JWT.

API Document

Discovering API documentation

Dùng Burp Scanner để quét
Manual bằng các endpoint có thể chứa API Documenrt

/api
/swagger/index.html
/openapi.json

Có thể dùng các tool để fuzzing nó ra bằng cách dùng các list API quen thuộc - wordlist

Lab: Exploiting an API endpoint using documentation

Machine-readable API Documentation

Công cụ phân tích và kiểm thử tài liệu API

Burp Suite:
- Burp Scanner:
  - Tự động quét và kiểm tra bảo mật tài liệu API theo chuẩn OpenAPI (Swagger).
  - Xác định các lỗ hổng bảo mật như Injection, Broken Authentication, Rate Limiting.
- OpenAPI Parser BApp:
  - Một tiện ích mở rộng trong Burp Suite giúp phân tích tài liệu OpenAPI, tự động trích xuất các endpoint và tạo yêu cầu thử nghiệm.
Postman:
- Công cụ kiểm thử API phổ biến, cho phép nhập tài liệu OpenAPI để tự động tạo yêu cầu HTTP.
- Hỗ trợ kiểm tra tính đúng đắn của phản hồi và xác thực API bằng các phương pháp như OAuth, API Key, JWT.
SoapUI:
- Kiểm thử API SOAP và REST với các kịch bản tự động dựa trên tài liệu API.
- Cho phép mô phỏng các yêu cầu phức tạp và thực hiện kiểm thử chức năng.

Quy trình kiểm thử API dựa trên tài liệu

Phân tích tài liệu API:
- Sử dụng Burp hoặc Postman để nhập và trích xuất các endpoint.
- Xác định các thông số đầu vào, phương thức HTTP được hỗ trợ và quy tắc xác thực.
Gửi yêu cầu kiểm thử:
- Kiểm tra API bằng cách gửi yêu cầu thông qua Postman hoặc SoapUI.
- Phân tích phản hồi và kiểm tra lỗi logic hoặc bảo mật.
Kiểm tra bảo mật tự động:
- Sử dụng Burp Scanner để phát hiện lỗ hổng như SQL Injection, XSS, Authentication Bypass.
- Kiểm tra tính chống chịu của API với giới hạn tốc độ (rate limiting) và kiểm tra lỗi xử lý đầu vào.

Identifying API endpoints

Tự động quét bằng Burp Scanner:
- Burp Scanner có thể thực hiện quá trình crawling (thu thập dữ liệu) để phát hiện các endpoint API.
- Sau khi quét, kiểm tra các kết quả liên quan đến các endpoint đáng ngờ hoặc chưa được ghi nhận.
Duyệt ứng dụng thủ công bằng Burp's browser:
- Sử dụng trình duyệt proxy của Burp để quan sát các yêu cầu gửi đi trong thời gian thực và tìm kiếm dấu hiệu của API.

Tìm kiếm trong file JavaScript:

Nhiều endpoint API có thể được tham chiếu trong các file JavaScript tải xuống từ trình duyệt.
Dùng công cụ JS Link Finder BApp của Burp Suite để tự động phân tích và trích xuất các đường dẫn API từ mã nguồn JavaScript.
Cũng có thể kiểm tra thủ công bằng cách duyệt và phân tích các file .js trong Burp Suite.

Interacting with API endpoints

Xác định các endpoint API và sử dụng Burp Repeater, Burp Intruder để kiểm tra.
Quan sát hành vi của API và phát hiện bề mặt tấn công tiềm ẩn.
Kiểm tra phản hồi của API khi thay đổi phương thức HTTP và loại dữ liệu.
Phân tích kỹ thông báo lỗi và phản hồi để thu thập thông tin hữu ích.
Sử dụng thông tin thu được để xây dựng yêu cầu HTTP hợp lệ.

Identifying supported HTTP methods

HTTP method xác định hành động được thực hiện trên một tài nguyên.
Ví dụ về các HTTP method phổ biến:
- GET: Lấy dữ liệu từ một tài nguyên.
- PATCH: Thay đổi một phần của tài nguyên.
- OPTIONS: Lấy thông tin về các phương thức HTTP được hỗ trợ trên tài nguyên.
Một endpoint API có thể hỗ trợ nhiều phương thức HTTP khác nhau, do đó cần kiểm tra tất cả các phương thức tiềm năng để khám phá thêm chức năng của endpoint và mở rộng bề mặt tấn công.
Ví dụ, endpoint /api/tasks có thể hỗ trợ các phương thức sau:
- GET /api/tasks: Lấy danh sách công việc.
- POST /api/tasks: Tạo một công việc mới.
- DELETE /api/tasks/1: Xóa một công việc.
Burp Intruder có sẵn danh sách các HTTP method để tự động kiểm tra hàng loạt phương thức khác nhau.
Lưu ý:
- Khi kiểm tra các phương thức HTTP, nên thử nghiệm trên các đối tượng có mức độ ưu tiên thấp để tránh tác động không mong muốn như thay đổi dữ liệu quan trọng hoặc tạo ra quá nhiều bản ghi.

Identifying supported content types

Các endpoint API thường yêu cầu dữ liệu theo một định dạng cụ thể.
API có thể phản hồi khác nhau tùy thuộc vào kiểu nội dung (content type) được gửi trong yêu cầu.
Việc thay đổi kiểu nội dung có thể giúp bạn:
- Kích hoạt lỗi để thu thập thông tin hữu ích.
- Bypass các biện pháp phòng thủ không chặt chẽ.
- Khai thác sự khác biệt trong logic xử lý, ví dụ: API có thể an toàn khi xử lý JSON nhưng dễ bị tấn công injection khi xử lý XML.
Để thay đổi kiểu nội dung, cần chỉnh sửa tiêu đề Content-Type và định dạng lại phần thân (body) của yêu cầu cho phù hợp.
Công cụ Content Type Converter BApp có thể tự động chuyển đổi dữ liệu trong yêu cầu giữa XML và JSON, giúp dễ dàng thử nghiệm nhiều định dạng khác nhau.

Lab: Finding and exploiting an unused API endpoint

Using Intruder to find hidden endpoints

Dùng Burp Intruder để tìm endpoint ẩn sau khi xác định các endpoint ban đầu.
Kiểm tra biến thể của endpoint bằng cách thêm các chức năng phổ biến như delete, add.
Sử dụng wordlists với các quy ước đặt tên API phổ biến và thuật ngữ ngành.
Bổ sung từ khóa liên quan dựa trên thông tin thu thập ban đầu - wordlist

Mass assignment vulnerabilities

Mass Assignment là một kỹ thuật trong lập trình web cho phép gán giá trị cho nhiều thuộc tính của một đối tượng (object) cùng lúc, thường bằng cách sử dụng dữ liệu từ request của người dùng (ví dụ: JSON, form data). Nó giúp lập trình viên giảm thiểu công sức viết code khi xử lý nhiều trường dữ liệu cùng một lúc.

Identifying hidden parameters

Xác định tham số ẩn: Các tham số ẩn có thể được phát hiện bằng cách kiểm tra thủ công các đối tượng do API trả về.

Ví dụ:

Yêu cầu PATCH /api/users/ để cập nhật username và email với dữ liệu JSON:
```
{
    "username": "wiener",
    "email": "wiener@example.com"
}
```

Một yêu cầu đồng thời GET /api/users/123 trả về:

{
    "id": 123,
    "name": "John Doe",
    "email": "john@example.com",
    "isAdmin": "false"
}

Điều này cho thấy các tham số ẩn như id và isAdmin có thể tồn tại và được ràng buộc vào đối tượng người dùng nội bộ, bên cạnh các tham số được cập nhật như username và email.
Kết luận: Kiểm tra phản hồi từ API có thể giúp phát hiện tham số ẩn, cho phép khai thác hoặc kiểm tra lỗ hổng bảo mật liên quan đến mass assignment.

Kiểm tra lỗ hổng Mass Assignment

Bước 1: Thử thêm tham số ẩn vào yêu cầu PATCH
- Gửi yêu cầu cập nhật thông tin người dùng với tham số isAdmin được thêm vào:
  { "username": "wiener", "email": "wiener@example.com", "isAdmin": false }
- Nếu ứng dụng chấp nhận yêu cầu mà không có phản hồi lỗi, có thể tham số này đang được xử lý nội bộ.
Bước 2: Kiểm tra phản hồi với giá trị không hợp lệ
- Gửi yêu cầu PATCH với giá trị không hợp lệ cho isAdmin:
  { "username": "wiener", "email": "wiener@example.com", "isAdmin": "foo" }
- Nếu ứng dụng phản hồi khác nhau giữa giá trị hợp lệ và không hợp lệ, điều này có thể cho thấy tham số đang tác động đến logic xử lý của ứng dụng.
Bước 3: Khai thác lỗ hổng bằng cách thay đổi giá trị thành true
- Gửi yêu cầu PATCH với giá trị isAdmin là true:
  { "username": "wiener", "email": "wiener@example.com", "isAdmin": true }
- Nếu tham số này không được kiểm tra và xác thực đúng cách, người dùng có thể được cấp quyền admin ngoài ý muốn.
Bước 4: Kiểm tra quyền truy cập
- Đăng nhập vào ứng dụng bằng tài khoản wiener và kiểm tra xem có thể truy cập các tính năng dành cho admin hay không.
- Nếu có thể truy cập, chứng tỏ ứng dụng đã bị khai thác lỗ hổng mass assignment.

Kết luận: Nếu ứng dụng không kiểm tra và lọc tham số ẩn hợp lý, kẻ tấn công có thể lợi dụng để chiếm quyền kiểm soát hoặc thay đổi dữ liệu quan trọng.

Lab: Exploiting a mass assignment vulnerability

Preventing vulnerabilities in APIs

Khi thiết kế API, yếu tố bảo mật cần được chú trọng ngay từ giai đoạn đầu. Để đảm bảo an toàn, hãy thực hiện các bước sau:

Bảo vệ tài liệu API:
- Nếu API của bạn không dành cho công khai, hãy bảo mật tài liệu để hạn chế truy cập trái phép.
Cập nhật tài liệu thường xuyên:
- Đảm bảo tài liệu luôn phản ánh đúng hiện trạng của API, giúp các tester hợp pháp dễ dàng kiểm tra và xác định bề mặt tấn công.
Hạn chế phương thức HTTP:
- Chỉ cho phép những HTTP method cần thiết (như GET, POST) bằng cách sử dụng danh sách cho phép (allowlist).
Xác thực loại nội dung (Content-Type):
- Kiểm tra và đảm bảo rằng mỗi yêu cầu (request) hoặc phản hồi (response) chỉ chứa loại nội dung phù hợp với dự kiến.
Ẩn thông tin trong lỗi:
- Thay vì cung cấp thông báo lỗi chi tiết, hãy sử dụng các thông báo lỗi chung chung để tránh rò rỉ thông tin mà kẻ tấn công có thể lợi dụng.
Bảo mật trên tất cả các phiên bản API:
- Không chỉ tập trung vào phiên bản production, mà mọi phiên bản (bao gồm cả phiên bản cũ hoặc beta) đều cần được áp dụng các biện pháp bảo vệ tương tự.
Ngăn ngừa lỗ hổng "Mass Assignment":
- Sử dụng danh sách cho phép (allowlist) để giới hạn các thuộc tính mà người dùng có thể cập nhật. Đồng thời, chặn những thuộc tính nhạy cảm bằng danh sách chặn (blocklist) để ngăn chặn truy cập không mong muốn.

Server-side parameter pollution

Một số hệ thống chứa các API nội bộ không được truy cập trực tiếp từ internet. Lỗ hổng Server-side Parameter Pollution (SSPP) xảy ra khi một trang web nhúng đầu vào của người dùng vào yêu cầu gửi đến API nội bộ mà không thực hiện mã hóa đầy đủ. Điều này cho phép kẻ tấn công thao túng hoặc tiêm các tham số khác, dẫn đến:

Ghi đè các tham số hiện có.
Thay đổi hành vi của ứng dụng.
Truy cập dữ liệu trái phép.

Testing the query string

1. Kiểm tra cắt chuỗi truy vấn (Truncating query strings)

Khi kiểm tra khả năng cắt chuỗi truy vấn, bạn có thể thêm ký tự đặc biệt như #, &, hoặc = vào đầu vào của mình để quan sát phản hồi từ ứng dụng.

Ví dụ minh họa: Ứng dụng dễ bị tấn công cho phép tìm kiếm người dùng bằng tên đăng nhập:

GET /userSearch?name=peter&back=/home

Máy chủ sẽ gửi yêu cầu nội bộ sau:

GET /users/search?name=peter&publicProfile=true

Để thử cắt chuỗi truy vấn, bạn có thể thêm ký tự # (đã mã hóa URL):

GET /userSearch?name=peter%23foo&back=/home

Máy chủ sau đó có thể gửi yêu cầu nội bộ như sau:

GET /users/search?name=peter#foo&publicProfile=true

Lưu ý: Ký tự # cần được mã hóa URL (ví dụ %23). Nếu không, ứng dụng phía front-end sẽ coi đó là "fragment identifier" và không chuyển nó đến API nội bộ.
Dấu hiệu khai thác thành công:
- Nếu phản hồi trả về kết quả cho người dùng "peter" mà không cần kiểm tra publicProfile, truy vấn đã bị cắt thành công.
- Nếu phản hồi trả về lỗi như "Invalid name", có thể foo đã bị xử lý như một phần của tên người dùng.

2. Tiêm tham số không hợp lệ (Injecting invalid parameters)

Bạn có thể sử dụng ký tự & (đã mã hóa URL) để thêm tham số mới vào yêu cầu nội bộ.

Ví dụ: Sửa chuỗi truy vấn như sau:

GET /userSearch?name=peter%26foo=xyz&back=/home

Khi đó, API nội bộ sẽ nhận yêu cầu:

GET /users/search?name=peter&foo=xyz&publicProfile=true

Quan sát phản hồi:
- Nếu không có thay đổi, tham số foo có thể đã được tiêm nhưng bị ứng dụng bỏ qua.
- Tiếp tục thử nghiệm để hiểu rõ cách tham số này được xử lý.

3. Tiêm tham số hợp lệ (Injecting valid parameters)

Khi tìm ra các tham số hợp lệ có thể tiêm, bạn có thể thêm chúng vào yêu cầu nội bộ.

Ví dụ: Nếu phát hiện tham số email, bạn có thể thêm nó:

GET /userSearch?name=peter%26email=foo&back=/home

Yêu cầu nội bộ sẽ trở thành:

GET /users/search?name=peter&email=foo&publicProfile=true

Quan sát phản hồi:
- Nếu tham số email được xử lý, bạn có thể kiểm tra xem nó ảnh hưởng thế nào đến phản hồi.

4. Ghi đè tham số hiện có (Overriding existing parameters)

Để kiểm tra lỗ hổng, bạn có thể thử tiêm một tham số trùng tên để ghi đè giá trị ban đầu.

Ví dụ: Sửa chuỗi truy vấn như sau:

GET /userSearch?name=peter%26name=carlos&back=/home

Yêu cầu nội bộ sẽ trở thành:

GET /users/search?name=peter&name=carlos&publicProfile=true

Cách xử lý phụ thuộc công nghệ web:
- PHP: Chỉ xử lý tham số cuối cùng (carlos).
- ASP.NET: Kết hợp cả hai tham số (peter,carlos).
- Node.js / Express: Chỉ xử lý tham số đầu tiên (peter).
Dấu hiệu khai thác:
- Nếu ghi đè thành công, bạn có thể thử thêm tham số như name=administrator để thực hiện hành vi khai thác (ví dụ: đăng nhập dưới quyền admin).

Lab: Exploiting server-side parameter pollution in a query string

Testing for server-side parameter pollution in REST paths

Một API RESTful có thể sử dụng tên và giá trị tham số trong đường dẫn URL thay vì chuỗi truy vấn. Ví dụ, xét đường dẫn sau:

/api/users/123

Đường dẫn URL có thể được phân tích như sau:

/api là điểm cuối gốc của API.
/users là tài nguyên, trong trường hợp này là người dùng.
/123 là tham số, ở đây là định danh cho người dùng cụ thể.

Ví dụ về ứng dụng dễ bị tấn công: Một ứng dụng cho phép chỉnh sửa hồ sơ người dùng theo tên đăng nhập. Yêu cầu được gửi đến endpoint sau:

GET /edit_profile.php?name=peter

Yêu cầu phía máy chủ sẽ là:

GET /api/private/users/peter

Kẻ tấn công có thể thao túng tham số đường dẫn phía máy chủ để khai thác API. Để kiểm tra lỗ hổng này, bạn có thể thêm các chuỗi path traversal để thay đổi tham số và quan sát cách ứng dụng phản hồi.

Ví dụ thử nghiệm: Bạn có thể gửi giá trị mã hóa URL peter/../admin cho tham số name:

GET /edit_profile.php?name=peter%2f..%2fadmin

Điều này có thể dẫn đến yêu cầu phía máy chủ sau:

GET /api/private/users/peter/../admin

Nếu API hoặc máy chủ phía back-end chuẩn hóa đường dẫn (normalize path), nó có thể giải quyết thành:
```
GET /api/private/users/admin
```

Lab: Exploiting server-side parameter pollution in a REST URL

{
  "error": "Unexpected response from API server: {
    \"openapi\": \"3.0.0\",
    \"info\": {
      \"title\": \"User API\",
      \"version\": \"2.0.0\"
    },
    \"paths\": {
      \"/api/internal/v1/users/{username}/field/{field}\": {
        \"get\": {
          \"tags\": [
            \"users\"
          ],
          \"summary\": \"Find user by username\",
          \"description\": \"API Version 1\",
          \"parameters\": [
            {
              \"name\": \"username\",
              \"in\": \"path\",
              \"description\": \"Username\",
              \"required\": true,
              \"schema\": {
                \"type\": \"string\"
              }
            },
            {
              \"name\": \"field\",
              \"in\": \"path\",
              \"description\": \"Field to retrieve (e.g., email, passwordResetToken)\",
              \"required\": true,
              \"schema\": {
                \"type\": \"string\"
              }
            }
          ]
        }
      }
    }
  }"
}

Endpoint phân tích chi tiết:

/api/internal/v1/users/{username}/field/{field}:
- Method: "get" (phương thức GET để lấy dữ liệu từ server).
- Parameters:
  - "username":
    Loại tham số: "in": "path" (tham số nằm trong URL).
    Bắt buộc ("required": true).
    Có mô tả: "description": "Username".
  - "field":
    Đây là một tham số khác trong endpoint, cho phép bạn xác định loại thông tin cần lấy từ API (ví dụ: email, token...).

PreviousServer-side topics NextRace conditions

Last updated 10 months ago