Tấn công ứng dụng web an ninh mạng
Ngày nay, các ứng dụng web có ở khắp mọi nơi và chúng được sử dụng để kiểm soát mọi thứ bạn có thể tưởng tượng. Trong phần này chúng ta sẽ xem xét các cuộc tấn công và bảo mật ứng dụng web.
IDOR ("Tham chiếu đối tượng trực tiếp không an toàn")
Lỗ hổng IDOR xảy ra khi nhà phát triển chưa thực hiện các yêu cầu ủy quyền để truy cập tài nguyên.
Eve, chỉ cần thay đổi một mã định danh, ví dụ như tham số Rest của tài liệu, cô ấy có thể truy cập các tài liệu của Alice.
Điều này xảy ra khi ứng dụng web không thực thi ủy quyền giữa các đối tượng, cho phép kẻ tấn công liệt kê các giá trị và kiểm tra quyền truy cập vào các điểm dữ liệu khác.
Ví dụ: chúng ta có thể có mã giả sau không có dấu hiệu ủy quyền:
$id = getInputFromUser();
$doc = getDocument($id);
return $doc;
Đoạn mã trên yêu cầu người dùng nhập thông tin đầu vào, không thực hiện xác thực hoặc dọn dẹp, sau đó thực hiện tra cứu trực tiếp bằng hàm getDocument và trả về tài liệu được đề cập.
Việc triển khai tốt hơn sẽ là kiểm tra các đặc quyền:
$id = getInputFromUser();
$user = findUsername();
$doc = "";
if (hasAccessToDocument($user, $id)) {
$doc = getDocument($id);
} else {
$doc = "Not authorized for this document";
}
return $doc;
Những lỗ hổng như thế này rất dễ tìm thấy vì bạn chỉ cần thay đổi một con số đơn giản và xem liệu bạn có quyền truy cập vào dữ liệu của người khác hay không. Việc kiểm tra xem người dùng có được ủy quyền hay không trước tiên sẽ ngăn chặn lỗ hổng này.
Tránh “Những con số kỳ diệu”
Một ứng dụng muốn tránh sử dụng dãy số khi tham chiếu dữ liệu. Trong ví dụ về IDOR, tài liệu có số nhận dạng từ 1000 đến 1002. Đôi khi những con số này được gọi là "Số ma thuật" vì chúng trỏ trực tiếp đến tài nguyên trên máy chủ, ví dụ: thông qua cơ sở dữ liệu và tất cả các giá trị có thể dễ dàng được liệt kê. Ví dụ: kẻ tấn công có thể kiểm tra tất cả các số nhận dạng tài liệu từ 0 đến 10000 và ghi lại mọi kết quả cung cấp quyền truy cập vào dữ liệu.
Mặc dù việc ủy quyền phải được triển khai đúng cách nhưng cũng hữu ích khi sử dụng GUID ("Mã định danh duy nhất toàn cầu") hoặc UUID ("Mã định danh duy nhất toàn cầu") khi tham chiếu dữ liệu. Các mã định danh này được thiết kế để có tính duy nhất trên toàn cầu và không thể liệt kê được do entropy tích hợp trong quá trình tạo số.
GUID có thể trông như thế này:
- 3377d5a6-236e-4d68-be9c-e91b22afd216
Tiêm SQL
Nhiều ứng dụng web được kết nối với cơ sở dữ liệu. Cơ sở dữ liệu chứa tất cả thông tin mà ứng dụng web muốn lưu trữ và sử dụng.
SQL Tiêm là một kỹ thuật cho phép kẻ tấn công thao túng SQL ("Ngôn ngữ truy vấn có cấu trúc") mà nhà phát triển ứng dụng web đang sử dụng. Điều này thường xảy ra do thiếu vệ sinh dữ liệu. SQL được các nhà phát triển sử dụng thường xuyên để truy cập tài nguyên cơ sở dữ liệu.
Trong yêu cầu mà Eve đưa ra trong hình trên, chúng ta thấy cô ấy nhập giá trị: 1000' OR '1'='1
Điều này khiến cho Truy vấn SQL thu được trả về tất cả các hàng của bảng vì cơ sở dữ liệu đánh giá câu lệnh là luôn đúng. Hãy suy nghĩ về điều này: cơ sở dữ liệu nhận được yêu cầu trong đó giá trị có thể là 1000 HOẶC 1 bằng 1; nó sẽ trả về một giá trị mỗi lần! Có nhiều hàm và thao tác SQL khác nhau mà chúng ta có thể sử dụng để thao tác cú pháp và ví dụ này chỉ là một trong số rất nhiều ví dụ.
Dưới đây là một ví dụ về mã giả có chứa lỗ hổng SQL Insert.
$username = getUserName();
$pw = getPassword();
$user = mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}
Để kẻ tấn công khai thác điều này, chúng có thể chỉ cần tạo một URL chống lại miền mục tiêu có chứa cuộc tấn công như thế này:
/login?username=admin&password=password' OR '1'='1
Biến mật khẩu được đặt để chứa các ký tự SQL, khiến chuỗi SQL kết quả trả về một hàng, ngay cả khi chúng tôi không xác định được mật khẩu. Truy vấn SQL kết quả sẽ là:
SELECT * FROM userTable WHERE username = 'admin' AND password = 'password' OR '1'='1'
Truy vấn được tham số hóa là giải pháp được đề xuất để đánh bại việc tiêm SQL. Trong truy vấn được tham số hóa, nhà phát triển phải đảm bảo cẩn thận mỗi đầu vào của truy vấn được xác định là một giá trị và loại cụ thể. Đây là một ví dụ từ đoạn mã trên được coi là cách triển khai an toàn:
$username = getUserName();
$pw = getPassword();
$parameterizedQuery = prepare_query("SELECT * FROM userTable where username = ? and password = ?");
$parameterizedQuery.setString(1, $username)
$parameterizedQuery.setString(2, $password)
$user = parameterizedQuery.execute();
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}Trong ví dụ trên, nhà phát triển đã cẩn thận nói rằng tham số 1 phải là một chuỗi và chứa tên người dùng cũng như mật khẩu trong tham số thứ hai.
XSS ("Kịch bản chéo trang")
XSS sử dụng máy chủ để tấn công khách truy cập máy chủ. Cuộc tấn công không nhắm vào chính máy chủ mà thay vào đó là người dùng.
Máy chủ chỉ được sử dụng để phản ánh các giá trị của kẻ tấn công, thường là JavaScript, chống lại những khách truy cập sau đó chạy dữ liệu của kẻ tấn công trong trình duyệt của riêng họ. Kẻ tấn công phải tạo đầu vào mà máy chủ không dọn dẹp và vệ sinh, theo cách đó khi khách truy cập nhấp vào liên kết chứa các giá trị của kẻ tấn công hoặc truy cập tài nguyên trên trang web mà kẻ tấn công đã sử dụng trong cuộc tấn công của chúng, người dùng sẽ chạy mã. kẻ tấn công đã cung cấp.
Đây là một ví dụ đồ họa về việc Eve gửi một liên kết tới Alice có chứa cuộc tấn công XSS:
Cuộc tấn công này được gọi là XSS phản ánh và yêu cầu Eve tìm ra lỗ hổng, sau đó gửi liên kết chứa cuộc tấn công đến người dùng không nghi ngờ và yêu cầu họ nhấp vào liên kết. Liên kết chứa cuộc tấn công và khiến máy chủ web trả lại cuộc tấn công cho nạn nhân nhấp vào liên kết.
Mã đằng sau điều này có thể đơn giản như ví dụ về mã giả này:
$nickname = etNickName();
echo "Greeting $nickname, nice to meet you!";
Một loại XSS khác được gọi là tấn công Stored XSS. Trong các cuộc tấn công Stored XSS, kẻ tấn công có khả năng lưu nội dung trên trang web, nội dung này được phản ánh mỗi khi ai đó truy cập trang web. Nó không nhất thiết phải yêu cầu ai đó nhấp vào một liên kết.
Đồ họa này mô tả cách Eve có thể lưu trữ JavaScript độc hại để thực thi trong trình duyệt của bất kỳ ai khi truy cập tài nguyên:
Các cuộc tấn công XSS có thể thực hiện được nhiều việc, ví dụ:
- Ăn cắp cookie có thể được sử dụng để xác thực
- Làm biến dạng trang web, hiển thị nội dung mà máy chủ web không có ý định làm
- Lừa đảo người dùng để lại thông tin xác thực trong các biểu mẫu đăng nhập giả mạo
Để bảo vệ chống lại XSS, có một số phương pháp hay nhất cần tuân theo:
- Cho phép máy chủ web trả về các tiêu đề CSP ("Chính sách bảo mật nội dung") quyết định nghiêm ngặt vị trí và cách thức thực thi JavaScript từ đó
- Mã hóa an toàn đầu ra mà máy chủ web trả về cho người dùng, biến các ký tự HTML thành các ký tự an toàn được mã hóa một cách hiệu quả
Mã hóa HTML
Mã hóa HTML cho phép ứng dụng web trả về các ký tự không an toàn thông thường một cách an toàn. Ví dụ: các ký tự đặc biệt sau có thể được mã hóa thành bản sao tương ứng của chúng:
| Special Character | HTML Entity |
|---|---|
| < | < |
| > | > |
| " | " |
| & | & |
| ' | ' |
Điều này tạo ra đầu ra có thể được hiển thị một cách an toàn. Sau đó, chúng tôi có thể sử dụng JavaScript ở phía máy khách để biến các thực thể HTML thành giá trị một cách an toàn.
CSP ("Chính sách bảo mật nội dung")
Máy chủ web có thể kiểm soát loại JavaScript nào được phép chạy trên trang web. Điều này không loại bỏ các lỗ hổng nhưng bổ sung thêm khả năng bảo vệ chuyên sâu khi có một lỗ hổng chưa xác định.
Một CSP phổ biến và nghiêm ngặt là cung cấp cho người dùng ứng dụng web danh sách tất cả các tệp nguồn JavaScript được chấp nhận.
Ngoài ra, thông thường CSP sẽ ngăn chặn việc thực thi JavaScript nội tuyến.
Để cho phép triển khai và phát hiện các cuộc tấn công đang diễn ra dễ dàng hơn, CSP cho phép khách hàng báo cáo các vi phạm CSP tới một URL do máy chủ cung cấp
Quét ứng dụng web
Có rất nhiều máy quét ứng dụng web trên mạng. Điều này cho phép các ứng dụng được quét để tìm các lỗ hổng như SQL Tiêm và XSS. Trái ngược với trình quét lỗ hổng mạng, trình quét ứng dụng web thường được xây dựng dựa trên phương pháp phỏng đoán thay vì chữ ký và danh sách các lỗ hổng đã biết.
Trình quét ứng dụng web rất hữu ích, đặc biệt khi được tích hợp vào các quy trình phát triển như CI ("Tích hợp liên tục") và CD ("Phân phối liên tục")
