OWASP API và mối nguy hiểm Injection

Dữ liệu người dùng không đáng tin cậy có thể là thông số yêu cầu giao thức lớp ứng dụng HTTP, tiêu đề HTTP và các cookie. Các dữ liệu này cũng có thể đến từ cơ sở dữ liệu hoặc tệp lưu trữ mà người dùng sử dụng để sửa đổi.

Nếu ứng dụng web không xử lý triệt để các dữ liệu nhận được từ tệp người dùng không đáng tin cậy từ trước, mà lại chèn vào các lệnh hoặc truy vấn, trình thông dịch. Từ đó, những kẻ tấn công có thể lợi dụng lỗ hổng này để gửi dữ liệu đến ứng dụng web của doanh nghiệp dựa trên lỗ hổng đó.

Trong một cuộc tấn công SQL Injection,kẻ tấn công đưa chèn mã độc vào để thao tác các lệnh SQL và trong một cuộc tấn công Command Injection, kẻ tấn công sẽ tiêm dữ liệu điều khiển logic của các lệnh hệ điều hành trên máy chủ lưu trữ.

Các lỗ hổng Injection cũng có thể ảnh hưởng đến hệ thống API khi mà API chỉ là một cách khác mà người dùng nhập liệu vào ứng dụng. Chúng ta hãy xem cách các lỗ hổng bảo mật xuất hiện trong API.

Ví dụ 1: Truy xuất các bài đăng trên blog API

Một API cho phép người dùng truy xuất các bài đăng trên blog bằng các gửi một lệnh yêu cầu request GET như sau:

GET /api/v1.1/posts?id=12358

Yêu cầu sẽ khiến API trả về bài đăng 12358. Máy chủ sẽ tự động truy xuất bài blog tương ứng từ cơ sở dữ liệu bằng việc truy vấn SQL, trong đó post_id đè cập đến id được người dùng chuyển qua URL.

SELECT * FROM posts WHERE post_id = 12358

Bây giờ, chuyện gì sẽ xảy ra nếu người dùng yêu cầu từ điểm cuối API?

GET /api/v1.1/posts?id=12358; DROP TABLE users

Máy chủ SQL sẽ phân tích phần id sau dấu chấm phẩy dưới dạng một lệnh SQL riêng. Từ đó, công cụ SQL đầu tiên sẽ thực hiện dòng lệnh để truy xuất bài đăng trên blog như bình thường:

SELECT * FROM posts WHERE post_id = 12358;

Cuối cùng, Injection sẽ thực hiện lệnh để xóa bảng người dùng gây ra tình trạng đánh mất dữ liệu lưu trong bảng đó

DROP TABLE users

Ví dụ 2: Đọc các tệp hệ thống

Nếu trang web cho phép người dùng đọc các tệp mà họ đã tải lên thông qua điểm cuối API:

GET /api/v1.1/files?id=1123581321

Khi nhận yêu cầu, máy chủ sẽ truy xuất lệnh mà người dùng đã nhập thông qua lệnh hệ thống:

cat /var/www/html/users/tmp/1123581321

Lúc này, người dùng có thể đưa các lệnh mới vào lệnh hệ điều hành bằng các bổ sung thêm lệnh sau dấu chấm phẩy:

GET /api/v1.1/files?id=1123581321; rm -rf /var/www/html/users

Lệnh này sẽ bắt buộc máy chủ xóa thư mục nằm tại var / www / html / users, đây là nơi ứng dụng lưu trữ thông tin của người dùng.

rm -rf /var/www/html/users

Các ví dụ trên sẽ giúp doanh nghiệp hiểu về các lỗ hổng Injection một các đơn giản hơn. Trong thực tế, các lỗ hổng Injection rất tinh vi và các cuộc tấn công của OWASP API có thể xảy ra bất cứ lúc nào khi mà dữ liệu đang được xử lý hoặc sử dụng. 

Khi dữ liệu người dùng nếu được đánh giá là độc hại, máy chủ sẽ không sử dụng mà sẽ kiểm tra và lùi về sau. Nhưng đối với các dữ liệu với trạng thái không đáng tin cậy lại có thể di chuyển trong cơ sở dữ liệu có thể đi bất cứ đâu, có thể truy cập tới mọi địa điểm và bị lợi dụng để tiêm nhiễm các mã độc.

Đây là lý do tại sao các mã tiêm nhiễm Injection rất khó phòng ngừa. Dữ liệu không đáng tin cậy có thể tấn công bất kỳ thành phần nào của ứng dụng. Và đối với mỗi phần dữ liệu không đáng tin cậy mà một ứng dụng nhận được, nó phải phát hiện và vô hiệu hóa các cuộc tấn công nhắm vào mọi phần của ứng dụng. Và ứng dụng có thể nghĩ rằng một  dữ liệu là an toàn vì nó không chứa bất kỳ ký tự đặc biệt nào được sử dụng cho XSS khi kẻ tấn công có ý định chèn SQL. Không phải lúc nào cũng dễ dàng xác định dữ liệu nào là an toàn và dữ liệu nào không, vì dữ liệu an toàn và không an toàn  rất khác nhau trong các phần khác nhau của ứng dụng.

Biện pháp xác thực đầu vào

Để chống lại Injection, doanh nghiệp có thể xác thực tất các các dữ liệu không đáng tin cậy bằng các lập một danh sách cần chặn để triển khai từ chối bất kỳ đầu vào nào chứa các ký tự nguy hiểm. 

Bên cạnh đó, doanh nghiệp có thể triển khai danh sách chỉ cho các đầu vào vào có các ký tự cho phép an toàn. Ví dụ: Với chức năng đăng ký đang được triển khai. Các nhà quản trị web sẽ biết được những dữ liệu chèn vào một truy vấn SQL,  họ có thể từ chối bất kỳ đầu vào nào có chứa ký tự của SQL (như dấu hoặc ngoặc kép). 

Nhược điểm của biện pháp này chính là danh sách chặn rất khó thực hiện vì doanh nghiệp không phải lúc nào cũng biết được những kí tự nào là nguy hiểm hay kí tự nào là quan trọng cho các phần ứng dụng. Bên cạnh đó, biện pháp này còn hạn chế ở danh sách chặn k và đôi lúc các ký tự đặc biệt cũng phải được chấp nhận như tên Conan O’Brien khi người này đăng ký.

Biện pháp mã hóa ký tự đặc biệt

Bằng cách sử dụng các dấu đặc biệt và cú pháp để đánh dấu khi người dùng nhập liệu, cho phép trình thông dịch biết rằng dữ liệu nào sẽ không được thực thi.

Nhược điểm của phương pháp này là doanh nghiệp phải sử dụng cú pháp mã khóa chính xác cho mọi trình phân tích cú pháp hoặc nhà lập trình có thể quên đi một số ký tự, tạo ra cơ hội cho những kẻ tấn công vô hiệu hóa nỗ lực mã hóa.

Biện pháp tham số hóa

Tham số hóa liên quan đến phần biên dịch phần mã của lệnh trước khi chèn bất kỳ tham số nào do người dùng cung cấp. Thay vì ghép phần đầu các lệnh chương trình và gửi đến máy chủ để được biên dịch, các nhà quản trị phải xác định trước các tính logic, biên dịch và chèn.

Sau khi phần đầu đoạn mã được chèn vào lệnh cuối cùng, lệnh sẽ không được phân tích cú pháp và biên dịch lại. Vì vậy, phần logit của lệnh vẫn còn nguyên vẹn góp phần cho phép cơ sở dữ liệu phân biệt giữa phần mã và phần dữ liệu lệnh trong mọi trường hợp người dùng. 

Nhược điểm của biện pháp này là không thể sử dụng linh hoạt trong ngữ cảnh của đoạn mã.

Sử dụng một biện pháp bảo mật

Ngoài các biện pháp như tham số hóa, xác thực đầu vào và mã hóa ký tự được liệt kê bên trên. Việc sử dụng một biện phải bảo mật như tường lửa ứng dụng web trên nền tảng đám mây (Cloud WAF) đến từ giải pháp bảo mật hiện nay như VNIS (VNETWORK Internet Security) sẽ giúp doanh nghiệp an toàn trước các tiêm nhiễm Injection.

Tường lửa ứng dụng web thông minh của VNIS còn giúp doanh nghiệp giải quyết bài toán top 10 lỗ hổng OWASP mới nhất cùng Cloud WAF, với khả năng cho phép tùy chỉnh XSS, SQL của Cloud WAF và bộ quy tắc Generic Injection giúp cho doanh nghiệp ngăn ngừa tình trạng bị tấn công Injection của OWASP. Việc tích hợp WAF thông minh của VNIS giúp cho việc bảo vệ bot và quản lý các API được siết chặt hơn.

Cloud WAF của VNIS còn được đặt tại nhiều quốc gia, nâng cao khả năng bảo mật cho doanh nghiệp tại Layer 7 (tầng ứng dụng) khi mà các nhà cung cấp Internet thường bỏ qua (chỉ tập trung ở Layer 3 và Layer 4). Cloud WAF còn tăng cường khả năng phân tích và loại bỏ các lưu lượng độc hại như DDoS và các lỗ hổng được loại bỏ nhờ hệ thống Scrubbing Center.

Để giải đáp các thắc mắc liên quan tới bảo mật website hoặc phòng chống tấn công lỗ hổng Injection đến từ top 10 OWASP, hãy liên hệ ngay hotline (028) 7306 8789 hoặc điền thông tin đăng ký dưới đây, để chúng tôi có thể liên hệ và tư vấn cho bạn sớm nhất.