API Security Testing (Phần 2)

Tín NguyễnJune 25, 2024

Xem nhanh

Chào mừng các bạn quay trở lại với loạt bài về API Security Testing. Ở Phần 1, chúng ta đã tìm hiểu khái niệm cơ bản, tầm quan trọng của việc kiểm thử bảo mật API, cách mà API bị xâm phạm và ảnh hưởng của nó đến sản phẩm cũng như người dùng và doanh nghiệp là lớn đến dường nào. Thông qua bài viết, chúng ta cũng khám phá được các lỗ hổng bảo mật API phổ biến dựa trên chuẩn OWASP Top 10 và qua đó thiết lập các bước đầu tiên để bắt đầu kiểm thử bảo mật cho API.

Trong Phần 2 này, chúng ta sẽ đi sâu hơn vào các kỹ thuật nâng cao phục vụ cho việc kiểm thử bảo mật API. Bài viết sẽ đề cập đến nhiều phương pháp kiểm thử phức tạp, các công cụ và các cách kiểm tra nhằm giúp xác định và giảm thiểu các lỗ hổng trong API. Bên cạnh đó, phần 2 này còn đưa ra các checklist cho việc phát triển cũng như kiểm thử, với mong muốn trang bị cho bạn các kiến thức và kỹ năng cần thiết để bảo vệ API trước các mối đe dọa ngày càng tinh vi và phức tạp. Nào chúng ta cùng bắt đầu nhé!

Tiến hành Kiểm thử Bảo Mật API

Một vài kỹ thuật Kiểm thử Bảo mật API

Kiểm thử bảo mật API bắt đầu bằng việc xác định xem API cần được kiểm tra như thế nào để phát hiện và xác định các lỗ hổng. Sau đó tiến hành các bài kiểm tra khác nhau bằng những kỹ thuật liên quan và cuối cùng là báo cáo chi tiết lỗ hổng API đến các đối tượng liên quan. Bên dưới là một số kỹ thuật cơ bản dùng để kiểm thử bảo mật cho API:

1. API Input Fuzzing

Fuzzing (làm mờ) hiểu đơn giản có nghĩa là cung cấp các dữ liệu ngẫu nhiên đến API cho đến khi nó làm lộ ra thứ gì đó, chẳng hạn như một số thông tin, một số thông báo lỗi hoặc bất cứ điều gì ngụ ý rằng các dữ liệu ngẫu nhiên đó đã được API xử lý.
Cách kiểm tra:
- Đối với input là số: thử số 0 hoặc số âm hoặc số rất lớn.
- Đối với input là chuỗi: thử các truy vấn SQL hoặc lệnh hệ thống hoặc các ký tự ngẫu nhiên như dấu nháy đôi “, dấu nháy đơn ‘, dấu // …
- Nhưng đó là khi kiểm tra thủ công. Nếu muốn tự động hóa toàn bộ quá trình, thì có một công cụ mã nguồn mở có tên Fuzzapi.

2. API Injection

API có thể dễ dàng bị tấn công tiêm nhiễm, trong đó mã độc hoặc lệnh độc hại được đưa vào các request API. Điều này có thể dẫn đến việc lộ dữ liệu trái phép, hệ thống bị xâm nhập hoặc nặng hơn là bị điều khiển bởi kẻ tấn công. Sau đây là hai loại Injection quen thuộc nhất:

2.1. SQL Injection (SQLi)

Các cuộc tấn công SQLi thành công khi dữ liệu đầu vào chưa được chuẩn hóa, mà được xử lý bởi cơ sở dữ liệu. Do đó, điều quan trọng là phải kiểm tra API để tìm ra bất kỳ lỗi SQLi nào.
Cách kiểm tra:
- Hãy thử cung cấp các lệnh SQL trong đầu vào [1] như: 'or 1=1--hoặc "and 1=1--. Nếu API dễ bị tấn công bởi SQLi, thì những giá trị được đưa vào tham số này có thể giúp vượt qua (bypass) một số hạn chế và phản hồi với trạng thái 200 OK.
- Tham khảo các SQLi Cheat Sheet và cập nhật thường xuyên để hỗ trợ cho việc kiểm thử.
- Công cụ SQLmap cho phép tự động quét và tìm ra các lỗi về SQLi nhanh chóng và tiết kiệm thời gian.

2.2. Command Injection

Các đầu vào cũng có thể bị tiêm nhiễm bởi các lệnh hệ điều hành khác nhau, các lệnh này sau đó được thực thi trên máy chủ. Tuy nhiên, đối với các hệ điều hành khác nhau (Windows, Linux, v.v.) thì các câu lệnh cũng sẽ khác nhau. VD: đối với Linux, lệnh rm / có thể xóa toàn bộ thư mục gốc. Khi URL được mã hóa, lệnh này sẽ trông giống như rm%20/.
Cách kiểm tra:
- Cũng tương tự như SQLi, hãy tiêm các câu lệnh nguy hiểm vô trong các đầu vào của API. Cùng xem xét một ví dụ, API được sử dụng để xem nội dung của một trang web, thì mã độc có thể được thực thi theo cách sau: https://example.com/view?name=file.txt;rm /
- Dấu chấm phẩy đặt sau file.txt có ý nghĩa kết thúc tham số đầu vào và thực thi lệnh xoá. Tuy nhiên, hãy cẩn thận với lệnh này vì nếu có lỗi xảy ra, nó có thể xóa toàn bộ thư mục.
- Ngoài ra, nếu muốn tự động hóa việc kiểm tra Command Injection, có thể dùng thử công cụ Commix.

3. Parameter Tampering

Thông thường, các tham số được gửi qua request có thể dễ dàng bị giả mạo. Bằng cách giả mạo tham số, kẻ tấn công có thể thay đổi và thao túng các thuộc tính của sản phẩm.
Cách kiểm tra:
- Ví dụ một trường hợp cụ thể sau: <input type="hidden" name="price" value="1,000,000" />. Ở đây ta thấy sản phẩm có giá 1.000.000, kẻ tấn công có thể sửa thành 1 và bằng cách nào đó có thể mua hàng thành công. Điều này có thể dễ dàng thực hiện bằng cách inspect element trong bất kỳ trình duyệt nào.
- Như vậy, hãy đảm bảo kiểm tra đầy đủ các trường hợp gửi request giả mạo đến các điểm cuối API.
- Có thể sử dụng Burp Suite kết hợp với Postman, để chặn API và thay đổi request.

4. Unhandled HTTP Methods

Các ứng dụng web giao tiếp bằng API thường sử dụng nhiều phương thức HTTP khác nhau. Các phương thức HTTP này được sử dụng để lưu, xóa hoặc lấy dữ liệu. Vì vậy, nếu máy chủ không hỗ trợ phương thức HTTP, thông thường nó sẽ hiển thị lỗi. Nhưng điều này không phải lúc nào cũng đúng, đặc biệt là đối với các API dễ bị tấn công.
Cách kiểm tra:
- Để kiểm tra xem API có cho phép các phương thức không an toàn hoặc không hợp lệ hoạt động hay không. Hãy thử gửi request bằng các phương thức không được sử dụng.
- Nếu nhận được phản hồi hợp lệ 200 OK mà không cần xác thực, chứ không phải mã lỗi (chẳng hạn như 405 Method Not Allowed hoặc 501), bạn cần chặn các phương thức đó.
- VD: Một API chỉ cho phép dùng phương thức GET và POST, nhưng kẻ tấn công gửi request và thay thế bằng phương thức HEAD và nhận được phản hồi 200 thành công. Đó có thể là một lỗ hổng cần được xem xét và đánh giá.

5. Cross-Site Scripting (XSS)

Kiểm tra XSS bằng cách chèn các ký tự lớn hơn, nhỏ hơn (<,>) vào tất cả các tham số và xem phản hồi liệu ứng dụng có mã hóa chúng thành > và < hay không.
Nếu một ứng dụng không thoát khỏi (escape) bất kỳ ký tự đặc biệt nào, thì ứng dụng đó có thể dễ bị tấn công từ phía máy khách như XSS.

Checklist cho Kiểm thử Bảo mật API

Đối với các tổ chức và doanh nghiệp, nhu cầu Kiểm thử bảo mật API ngày càng trở nên cấp thiết hơn. Checklist này hướng dẫn các nhà phát triển phần mềm cũng như các chuyên gia bảo mật về cách đạt được mức bảo vệ tối đa cho API, cũng như các dữ liệu nhạy cảm được lưu trữ và xử lý bên trong bằng cách tiến hành các bước kiểm tra bảo mật hiệu quả.

Danh sách kiểm tra thâm nhập và đánh giá lỗ hổng bảo mật sẽ đảm bảo rằng các doanh nghiệp sẽ không bỏ lỡ bất kỳ vị trí quan trọng nào trong API và đảm bảo mọi thứ được cấu hình chính xác với mức bảo mật cao nhất.

Dành cho nhà phát triển

	Nên	Không nên
Xác thực	- Mã hóa tất cả dữ liệu nhạy cảm. - Sử dụng Max Retry cho Đăng nhập.	Không sử dụng Xác thực Cơ bản (Basic Auth), thay vào đó hãy dùng Xác thực Tiêu chuẩn. (VD: JWT, OAuth)
Kiểm tra Đầu vào	- Xác thực đầu vào của người dùng để tránh các lỗ hổng phổ biến. (VD: XSS, SQL Injection, Thực thi mã độc từ xa, v.v.) - Xác thực đầu vào: độ dài / phạm vi (range) / định dạng và loại. - Xác thực đầu vào tiềm ẩn như: số, boolean, ngày, giờ trong các tham số API. - Xác định giới hạn kích thước request và từ chối các request vượt quá giới hạn với trạng thái phản hồi HTTP 413 Request Entity Too Large. - Sử dụng phương thức HTTP phù hợp theo thao tác: GET (đọc), POST (tạo), PUT/PATCH (thay thế/cập nhật) và DELETE (xoá) và phản hồi bằng 405 Method Not Allowed nếu phương thức được yêu cầu không phù hợp với tài nguyên được yêu cầu.	- Không tin tưởng các tham số (parameter) / đối tượng đầu vào. - Không sử dụng bất kỳ dữ liệu nhạy cảm nào (thông tin xác thực, mật khẩu, mã token bảo mật hoặc các API key) trong URL, mà hãy sử dụng header Authorization tiêu chuẩn.
Kiểm tra Đầu ra	- X-Content-Type-Options: nosniff header. - X-Frame-Options: từ chối header. - Content-Security-Policy: default-src 'none' header. - Xoá các tiêu đề (header) để lại dấu vết như: X-Powered-By, Server, X-AspNet-Version, v.v. - Trả lại các mã trạng thái phù hợp tuỳ theo thao tác hoàn thành. (VD: 200 OK, 400 Bad Request, 401 Unauthorized, v.v.).	Không trả lại dữ liệu nhạy cảm như thông tin xác thực, mật khẩu hoặc các mã token bảo mật.
Kiểm tra Loại Nội dung (Content-Type)	- Từ chối các request chứa tiêu đề loại nội dung không mong muốn hoặc bị thiếu với trạng thái phản hồi HTTP 406 Unacceptable hoặc 415 Unsupported Media Type. - Đối với các loại nội dung XML, hãy đảm bảo việc phân tích XML không mắc phải lỗ hổng XXE, xem bảng cheat sheet XXE. [2] - Đảm bảo loại nội dung trong phần phản hồi khớp với nội dung trong body. VD: application/json chứ không phải application/javascript.	Không vô tình làm lộ các loại nội dung ngoài ý muốn bằng cách xác định rõ ràng các loại nội dung.
JWT (JSON Web Token)	- Đặt thời gian hết hạn của mã token càng ngắn càng tốt. - Sử dụng khóa phức tạp ngẫu nhiên (JWT Secret) để khiến việc brute-force mã token trở nên khó khăn. - Bảo vệ JWT bằng Signature hoặc MAC, nhưng ưu tiên Signature hơn MAC để đảm bảo tính toàn vẹn của JWT.	- Không dùng những JWT không bảo mật. VD: {"alg":"none"} - Không lưu trữ dữ liệu nhạy cảm trong các JWT payload, dữ liệu có thể được giải mã một cách dễ dàng. - Không trích xuất thuật toán (algorithm) từ tiêu đề, mà để thuật toán ở phần backend (HS256 / RS256).
Các Endpoint liên quan đến Quản lý	Hạn chế quyền truy cập vào các điểm cuối này bằng tường lửa hoặc sử dụng danh sách kiểm soát truy cập.	Không để lộ các điểm cuối quản lý qua Internet. Nếu các Endpoint quản lý được truy cập qua Internet, hãy đảm bảo rằng người dùng phải sử dụng các cơ chế xác thực mạnh. (VD: multi-factor)
API Key	- Bắt buộc dùng API key cho mọi request đến các điểm cuối. - Trả về mã phản hồi “429 Too Many Requests” nếu các request đến quá nhanh. - Thu hồi API key nếu người dùng vi phạm thỏa thuận sử dụng.	Không chỉ dựa vào API key để bảo vệ các tài nguyên nhạy cảm, quan trọng hoặc có giá trị cao.
Xử lý Lỗi	Phản hồi bằng các thông báo lỗi chung chung - tránh tiết lộ chi tiết về lỗi một cách không cần thiết.	Không chuyển giao chi tiết về mặt kỹ thuật cho khách hàng.
Ghi Log	- Ghi lại log trước và sau các sự kiện liên quan đến bảo mật. - Ghi lại log các lỗi xác thực liên quan đến mã token để phát hiện các cuộc tấn công. - Cẩn thận với các cuộc tấn công chèn log bằng cách dọn sạch các dữ liệu liên quan đến log trước.

Dành cho nhà kiểm thử bảo mật

Kiểm tra API Input Fuzzing
Kiểm tra các loại tấn công API Injection (SQLi, Command)
Kiểm tra tấn công Giả mạo Thông số (Parameter Tampering)
Kiểm tra các phương thức HTTP chưa được xử lý (Unhandled HTTP Method)
Kiểm tra các cuộc tấn công dựa trên xác thực (Authentication)
Kiểm tra lỗ hổng tấn công từ chối dịch vụ (DoS)
Kiểm tra lỗ hổng tải lên tập tin (File Upload)
Kiểm tra các cuộc tấn công Replay
Kiểm tra phiên làm việc (Session)
Kiểm tra các lỗ hổng loại IDOR
Kiểm tra lỗ hổng XSS
Kiểm tra loại nội dung (Content-Type) bằng cách thay đổi thành 1 content-type khác
Kiểm tra các tính năng quản trị có thể được truy cập thông qua người dùng bị hạn chế hay không.
Kiểm tra với nhiều cấp độ truy cập khác nhau của người dùng. VD: quản trị viên, người điều hành, người dùng bình thường.
Kiểm tra các tham chiếu liên quan đến XML. VD: thay đổi nội dung Application/JSON thành Application/XML và chèn các payload XML để tìm lỗi XML entity injection.
Kiểm tra xem API có bất kỳ token ủy quyền (authorization) nào hay không. Nếu có, hãy xóa token ủy quyền đó và xem phản hồi của ứng dụng. Trong một số trường hợp, nếu việc ủy quyền không được triển khai chính xác thì API có thể cấp cho kẻ tấn công quyền truy cập vào các nội dung bị cấm của ứng dụng.

Kết Luận

Kiểm thử bảo mật API là việc rất quan trọng để bảo vệ tính toàn vẹn, tính khả dụng và tính bảo mật của dữ liệu được trao đổi thông qua API. Các tổ chức và doanh nghiệp có thể xác định và xử lý các lỗ hổng trong API của mình bằng cách lên kế hoạch chi tiết cho việc phát triển và tiến hành các bước kiểm thử một cách toàn diện. Khi công nghệ phát triển, việc luôn cập nhật và điều chỉnh các biện pháp bảo mật là điều cần thiết để đảm bảo API hoạt động trơn tru và ổn định.

Tài Liệu Tham Khảo

[1] SQL injection

[2] XML External Entity Prevention - OWASP Cheat Sheet Series