Trong bảo mật máy tính, xác thực là quá trình cố gắng xác minh danh tính kỹ thuật số của người gửi giao tiếp. Một ví dụ phổ biến của quy trình như vậy là quy trình đăng nhập. Kiểm tra lược đồ xác thực có nghĩa là hiểu cách thức hoạt động của quá trình xác thực và sử dụng thông tin đó để phá vỡ cơ chế xác thực.
Mặc dù hầu hết các ứng dụng yêu cầu xác thực để có quyền truy cập vào thông tin cá nhân hoặc để thực thi các tác vụ, nhưng không phải mọi phương pháp xác thực đều có thể cung cấp bảo mật đầy đủ. Việc sơ suất, thiếu hiểu biết hoặc đơn giản nói rõ về các mối đe dọa bảo mật thường dẫn đến các kế hoạch xác thực có thể bị bỏ qua bằng cách chỉ cần bỏ qua trang đăng nhập và gọi trực tiếp một trang nội bộ được cho là chỉ được truy cập sau khi xác thực đã được thực hiện.
Ngoài ra, thường có thể bỏ qua các biện pháp xác thực bằng cách giả mạo các yêu cầu và lừa ứng dụng nghĩ rằng người dùng đã được xác thực. Điều này có thể được thực hiện bằng cách sửa đổi tham số URL đã cho, bằng cách thao tác với biểu mẫu hoặc bằng cách làm giả các phiên.
Các vấn đề liên quan đến lược đồ xác thực có thể được tìm thấy ở các giai đoạn khác nhau của vòng đời phát triển phần mềm (SDLC), như giai đoạn thiết kế, phát triển và triển khai:
Trong giai đoạn thiết kế, các lỗi có thể bao gồm định nghĩa sai về các phần ứng dụng cần được bảo vệ, việc lựa chọn không áp dụng các giao thức mã hóa mạnh để đảm bảo việc truyền thông tin đăng nhập, v.v.
Trong giai đoạn phát triển, các lỗi có thể bao gồm việc triển khai không chính xác chức năng xác thực đầu vào hoặc không tuân theo các phương pháp bảo mật tốt nhất cho ngôn ngữ cụ thể.
Trong giai đoạn triển khai ứng dụng, có thể có sự cố trong quá trình thiết lập ứng dụng (hoạt động cài đặt và cấu hình) do thiếu các kỹ năng kỹ thuật cần thiết hoặc do thiếu tài liệu tốt.
Mục tiêu kiểm tra Bypassing Authentication Schema
Đảm bảo rằng xác thực được áp dụng trên tất cả các dịch vụ yêu cầu nó.
Làm thế nào để kiểm tra Bypassing Authentication Schema
Kiểm tra hộp đen
Có một số phương pháp Bypassing Authentication Schema được ứng dụng web sử dụng:
- Yêu cầu trang trực tiếp (duyệt bắt buộc)
- Sửa đổi thông số
- Dự đoán ID phiên
- SQL injection
- Yêu cầu trang trực tiếp
Nếu một ứng dụng web chỉ triển khai kiểm soát truy cập trên trang đăng nhập, thì lược đồ xác thực có thể bị bỏ qua. Ví dụ: nếu người dùng trực tiếp yêu cầu một trang khác thông qua duyệt cưỡng bức, trang đó có thể không kiểm tra thông tin đăng nhập của người dùng trước khi cấp quyền truy cập. Cố gắng truy cập trực tiếp vào một trang được bảo vệ thông qua thanh địa chỉ trong trình duyệt của bạn để kiểm tra bằng phương pháp này.
- Sửa đổi thông số
Một vấn đề khác liên quan đến thiết kế xác thực là khi ứng dụng xác minh đăng nhập thành công trên cơ sở các tham số giá trị cố định. Người dùng có thể sửa đổi các thông số này để có quyền truy cập vào các khu vực được bảo vệ mà không cần cung cấp thông tin xác thực hợp lệ. Trong ví dụ dưới đây, tham số “đã xác thực” được thay đổi thành giá trị “có”, cho phép người dùng có quyền truy cập. Trong ví dụ này, tham số nằm trong URL, nhưng một proxy cũng có thể được sử dụng để sửa đổi tham số, đặc biệt khi các tham số được gửi dưới dạng phần tử biểu mẫu trong một yêu cầu POST hoặc khi các tham số được lưu trữ trong cookie.
- Dự đoán ID session
Nhiều ứng dụng web quản lý xác thực bằng cách sử dụng số nhận dạng phiên (session ID). Do đó, nếu việc tạo session ID có thể dự đoán được, thì một người dùng độc hại có thể tìm thấy một session ID hợp lệ và có quyền truy cập trái phép vào ứng dụng, mạo danh một người dùng đã được xác thực trước đó.
Trong hình sau, các giá trị bên trong cookie tăng tuyến tính, vì vậy kẻ tấn công có thể dễ dàng đoán được ID phiên hợp lệ.
Trong hình sau, các giá trị bên trong cookie chỉ thay đổi một phần, vì vậy có thể hạn chế một cuộc tấn công bạo lực đối với các trường xác định được hiển thị bên dưới.
- SQL Injection (Xác thực Mẫu HTML)
SQL Injection là một kỹ thuật tấn công được biết đến rộng rãi. Phần này sẽ không mô tả chi tiết kỹ thuật này vì có một số phần trong hướng dẫn này giải thích các kỹ thuật tiêm nằm ngoài phạm vi của phần này.
Hình sau đây cho thấy rằng với một cuộc tấn công SQL injection đơn giản, đôi khi có thể bỏ qua biểu mẫu xác thực.
Thử nghiệm hộp xám
Nếu kẻ tấn công có thể truy xuất mã nguồn ứng dụng bằng cách khai thác lỗ hổng đã phát hiện trước đó (ví dụ: truyền qua thư mục) hoặc từ kho lưu trữ web (Ứng dụng nguồn mở), thì có thể thực hiện các cuộc tấn công tinh chỉnh chống lại việc triển khai xác thực quy trình.
Trong ví dụ sau (PHPBB 2.0.13 – Lỗ hổng bỏ qua xác thực), tại dòng 5, hàm unserialize () phân tích cú pháp cookie do người dùng cung cấp và đặt các giá trị bên trong mảng $ row. Tại dòng 10, băm mật khẩu MD5 của người dùng được lưu trữ bên trong cơ sở dữ liệu phía sau được so sánh với mã được cung cấp.
if (isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) {
$sessiondata = isset($HTTP_COOKIE_VARS[$cookiename . '_data']) ? unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
$sessionmethod = SESSION_METHOD_COOKIE;
}
if(md5($password) == $row['user_password'] && $row['user_active']) {
$autologin = (isset($HTTP_POST_VARS['autologin'])) ? TRUE : 0;
}
Trong PHP, phép so sánh giữa giá trị chuỗi và giá trị boolean (1 và TRUE) luôn là TRUE, vì vậy bằng cách cung cấp chuỗi sau (phần quan trọng là b: 1) cho hàm unserialize (), bạn có thể bỏ qua kiểm soát xác thực:
a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
