Một trong những thành phần cốt lõi của bất kỳ ứng dụng dựa trên web nào là cơ chế mà nó kiểm soát và duy trì trạng thái cho người dùng tương tác với nó. Để tránh xác thực liên tục cho mỗi trang của trang web hoặc dịch vụ, các ứng dụng web triển khai các cơ chế khác nhau để lưu trữ và xác thực thông tin xác thực trong một khoảng thời gian được xác định trước. Các cơ chế này được gọi là Quản lý phiên.
Trong thử nghiệm này, người thử nghiệm muốn kiểm tra xem cookie và các mã thông báo phiên khác có được tạo theo cách an toàn và không thể đoán trước hay không. Kẻ tấn công có khả năng dự đoán và giả mạo một cookie yếu có thể dễ dàng chiếm đoạt các phiên của người dùng hợp pháp.
Các bài viết liên quan:
Cookie được sử dụng để triển khai quản lý phiên và được mô tả chi tiết trong RFC 2965. Tóm lại, khi người dùng truy cập vào một ứng dụng cần theo dõi các hành động và danh tính của người dùng đó qua nhiều yêu cầu, cookie (hoặc cookie) sẽ được tạo bởi máy chủ và gửi đến máy khách. Sau đó máy khách sẽ gửi cookie trở lại máy chủ trong tất cả các kết nối sau cho đến khi cookie hết hạn hoặc bị phá hủy. Dữ liệu được lưu trữ trong cookie có thể cung cấp cho máy chủ một lượng lớn thông tin về người dùng là ai, hành động mà anh ta đã thực hiện cho đến nay, sở thích của anh ta là gì, v.v. do đó cung cấp trạng thái cho một giao thức không trạng thái như HTTP.
Một ví dụ điển hình được cung cấp bởi một giỏ hàng trực tuyến. Trong suốt phiên của người dùng, ứng dụng phải theo dõi danh tính của anh ta, hồ sơ của anh ta, các sản phẩm mà anh ta đã chọn mua, số lượng, giá cá nhân, giảm giá, v.v. Cookie là một cách hiệu quả để lưu trữ và vượt qua điều này thông tin qua lại (các phương pháp khác là tham số URL và trường ẩn).
Do tầm quan trọng của dữ liệu mà chúng lưu trữ, cookie do đó rất quan trọng trong bảo mật tổng thể của ứng dụng. Việc có thể giả mạo cookie có thể dẫn đến việc chiếm quyền điều khiển phiên của người dùng hợp pháp, có được đặc quyền cao hơn trong phiên hoạt động và nói chung ảnh hưởng đến hoạt động của ứng dụng theo cách trái phép.
Trong thử nghiệm này, người thử nghiệm phải kiểm tra xem liệu các cookie được cấp cho máy khách có thể chống lại một loạt các cuộc tấn công nhằm can thiệp vào các phiên của người dùng hợp pháp và với chính ứng dụng hay không. Mục tiêu chung là có thể giả mạo một cookie sẽ được ứng dụng coi là hợp lệ và sẽ cung cấp một số loại truy cập trái phép (chiếm quyền điều khiển phiên, leo thang đặc quyền,…).
Thông thường các bước chính của mô hình tấn công là như sau:
- cookie collection: bộ sưu tập đủ số lượng mẫu cookie;
- cookie reverse engineering: phân tích thuật toán tạo cookie;
- cookie manipulation: giả mạo một cookie hợp lệ để thực hiện cuộc tấn công. Bước cuối cùng này có thể yêu cầu một số lượng lớn lần thử, tùy thuộc vào cách cookie được tạo (cookie brute-force attack).
Một kiểu tấn công khác bao gồm làm tràn một cookie. Nói một cách chính xác, cuộc tấn công này có một bản chất khác, vì ở đây người kiểm tra không cố gắng tạo lại một cookie hoàn toàn hợp lệ. Thay vào đó, mục đích là làm tràn một vùng bộ nhớ, do đó can thiệp vào hoạt động chính xác của ứng dụng và có thể tiêm (và thực thi từ xa) mã độc hại.
Mục tiêu kiểm tra Session Management Schema
Thu thập mã thông báo phiên, cho cùng một người dùng và cho những người dùng khác nhau nếu có thể.
Phân tích và đảm bảo rằng có đủ ngẫu nhiên để ngăn chặn các cuộc tấn công giả mạo phiên.
Sửa đổi các cookie không có chữ ký và chứa thông tin có thể bị thao túng.
Làm thế nào để kiểm tra Session Management Schema
Black Box testing và các ví dụ
Tất cả các tương tác giữa máy khách và ứng dụng ít nhất phải được kiểm tra theo các tiêu chí sau:
- Tất cả các chỉ thị Set-Cookie có được gắn thẻ là An toàn không?
- Có bất kỳ hoạt động Cookie nào diễn ra trên quá trình truyền tải không được mã hóa không?
- Cookie có thể bị buộc qua quá trình truyền tải không được mã hóa không?
- Nếu vậy, ứng dụng duy trì bảo mật như thế nào?
- Có cookie nào bền không?
- Thời gian Hết hạn nào được sử dụng trên cookie liên tục và chúng có hợp lý không?
- Các cookie dự kiến sẽ được định cấu hình tạm thời như vậy có đúng không?
- Cài đặt HTTP / 1.1 Cache-Control nào được sử dụng để bảo vệ Cookie?
- Cài đặt HTTP / 1.0 Cache-Control nào được sử dụng để bảo vệ Cookie?
- cookie collection
Bước đầu tiên cần thiết để thao tác với cookie là hiểu cách ứng dụng tạo và quản lý cookie. Đối với nhiệm vụ này, người kiểm tra phải cố gắng trả lời các câu hỏi sau:
Ứng dụng sử dụng bao nhiêu cookie?
Lướt ứng dụng. Lưu ý khi cookie được tạo. Lập danh sách các cookie đã nhận, trang đặt chúng (với chỉ thị set-cookie), miền mà chúng hợp lệ, giá trị và đặc điểm của chúng.
Phần nào của ứng dụng tạo ra hoặc sửa đổi cookie?
Lướt ứng dụng, tìm cookie nào không đổi và cookie nào được sửa đổi. Sự kiện nào sửa đổi cookie?
Những phần nào của ứng dụng yêu cầu cookie này để được truy cập và sử dụng?
Tìm hiểu những phần nào của ứng dụng cần cookie. Truy cập một trang, sau đó thử lại mà không có cookie hoặc thông báo một giá trị đã sửa đổi của nó. Cố gắng lập bản đồ cookie nào được sử dụng ở đâu.
Một bảng tính ánh xạ từng cookie đến các phần ứng dụng tương ứng và thông tin liên quan có thể là đầu ra có giá trị của giai đoạn này.
- cookie reverse engineering
Bản thân các mã thông báo phiên (Cookie, SessionID hoặc Trường ẩn) cần được kiểm tra để đảm bảo chất lượng của chúng từ góc độ bảo mật. Chúng phải được kiểm tra dựa trên các tiêu chí như tính ngẫu nhiên, tính duy nhất, khả năng chống lại phân tích thống kê và mật mã và rò rỉ thông tin.
Cấu trúc mã thông báo & Rò rỉ thông tin
Giai đoạn đầu tiên là kiểm tra cấu trúc và nội dung của ID phiên do ứng dụng cung cấp. Một sai lầm phổ biến là đưa dữ liệu cụ thể vào Mã thông báo thay vì đưa ra giá trị chung và tham chiếu dữ liệu thực từ phía máy chủ.
Nếu ID phiên là văn bản rõ ràng, cấu trúc và dữ liệu thích hợp có thể rõ ràng ngay lập tức, chẳng hạn như 192.168.100.1:owaspuser:password:15:58.
Nếu một phần hoặc toàn bộ mã thông báo dường như được mã hóa hoặc băm, nó nên được so sánh với các kỹ thuật khác nhau để kiểm tra xem có bị xáo trộn rõ ràng hay không. Ví dụ: chuỗi 192.168.100.1:owaspuser:password:15:58 được biểu diễn bằng Hex, Base64 và dưới dạng băm MD5:
Hệ lục: 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64: MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg =
MD5: 01c2fc4f0a817afd8366689bd29dd40a
Sau khi xác định được loại xáo trộn, có thể giải mã trở lại dữ liệu ban đầu. Tuy nhiên, trong hầu hết các trường hợp, điều này khó xảy ra. Mặc dù vậy, có thể hữu ích nếu liệt kê mã hóa tại chỗ từ định dạng của thư. Hơn nữa, nếu cả định dạng và kỹ thuật obfuscation có thể được suy luận, các cuộc tấn công brute-force tự động có thể được nghĩ ra.
Mã thông báo kết hợp có thể bao gồm thông tin như địa chỉ IP hoặc ID người dùng cùng với một phần được mã hóa, chẳng hạn như owaspuser: 192.168.100.1: a7656fafe94dae72b1e1487670148412.
Sau khi phân tích một mã thông báo phiên duy nhất, mẫu đại diện cần được kiểm tra. Một phân tích đơn giản về các mã thông báo sẽ ngay lập tức tiết lộ bất kỳ mẫu rõ ràng nào. Ví dụ: mã thông báo 32 bit có thể bao gồm 16 bit dữ liệu tĩnh và 16 bit dữ liệu biến. Điều này có thể chỉ ra rằng 16 bit đầu tiên đại diện cho một thuộc tính cố định của người dùng – ví dụ: tên người dùng hoặc địa chỉ IP. Nếu đoạn 16 bit thứ hai đang tăng với tốc độ đều đặn, nó có thể chỉ ra một phần tử theo thời gian tuần tự hoặc thậm chí cho quá trình tạo mã thông báo. Xem các ví dụ.
Nếu các phần tử tĩnh của Mã thông báo được xác định, các mẫu tiếp theo sẽ được thu thập, thay đổi một phần tử đầu vào tiềm năng tại một thời điểm. Ví dụ: các nỗ lực đăng nhập thông qua một tài khoản người dùng khác hoặc từ một địa chỉ IP khác có thể dẫn đến một sự khác biệt trong phần tĩnh trước đó của mã thông báo phiên.
Các khu vực sau đây cần được giải quyết trong quá trình kiểm tra cấu trúc ID phiên một và nhiều phiên:
- Những phần nào của ID phiên là tĩnh?
- Thông tin bí mật dạng văn bản rõ ràng nào được lưu trữ trong ID phiên? Ví dụ. tên người dùng / UID, địa chỉ IP
- Những thông tin bí mật dễ dàng giải mã được lưu trữ?
- Thông tin nào có thể được suy ra từ cấu trúc của ID phiên?
- Những phần nào của ID phiên là tĩnh cho cùng một điều kiện đăng nhập?
- Những mẫu rõ ràng nào hiện diện trong ID phiên nói chung hoặc các phần riêng lẻ?
- Khả năng dự đoán và tính ngẫu nhiên của ID phiên
Cần tiến hành phân tích các vùng biến đổi (nếu có) của ID phiên để thiết lập sự tồn tại của bất kỳ mẫu nào có thể nhận biết hoặc dự đoán được. Các phân tích này có thể được thực hiện theo cách thủ công và với các công cụ thống kê hoặc phân tích mật mã riêng hoặc OTS để suy ra bất kỳ mẫu nào trong nội dung ID phiên. Kiểm tra thủ công phải bao gồm so sánh các ID phiên được cấp cho cùng một điều kiện đăng nhập – ví dụ: cùng tên người dùng, mật khẩu và địa chỉ IP.
Thời gian là một yếu tố quan trọng và cũng phải được kiểm soát. Số lượng kết nối đồng thời cao nên được thực hiện để thu thập các mẫu trong cùng một khoảng thời gian và giữ cho biến đó không đổi. Ngay cả lượng tử hóa từ 50ms trở xuống cũng có thể quá thô và mẫu được lấy theo cách này có thể tiết lộ các thành phần dựa trên thời gian mà nếu không sẽ bị bỏ sót.
Các yếu tố biến đổi cần được phân tích theo thời gian để xác định xem chúng có tính chất gia tăng hay không. Khi chúng tăng dần, các mẫu liên quan đến thời gian tuyệt đối hoặc thời gian đã trôi qua cần được nghiên cứu. Nhiều hệ thống sử dụng thời gian như một mầm mống cho các yếu tố giả ngẫu nhiên của chúng. Trong trường hợp các mẫu dường như ngẫu nhiên, các hàm băm một chiều của thời gian hoặc các biến thể môi trường khác nên được coi là một khả năng. Thông thường, kết quả của một băm mật mã là một số thập phân hoặc thập lục phân nên có thể nhận dạng được.
Trong việc phân tích trình tự, mẫu hoặc chu trình Session ID, tất cả các phần tử tĩnh và phần phụ thuộc ứng dụng khách nên được coi là các phần tử đóng góp có thể vào cấu trúc và chức năng của ứng dụng.
Các ID phiên có tính chất ngẫu nhiên không? Các giá trị kết quả có thể được tái tạo không?
Các điều kiện đầu vào giống nhau có tạo ra cùng một ID trong lần chạy tiếp theo không?
Các ID phiên có được cung cấp không
có khả năng chống lại phân tích thống kê hoặc mật mã không?
Phần tử nào của ID phiên được liên kết theo thời gian?
Những phần nào của ID phiên có thể dự đoán được?
ID tiếp theo có thể được suy luận, cung cấp kiến thức đầy đủ về thuật toán tạo và các ID trước đó không?
cookie reverse engineering
Bây giờ người thử nghiệm đã liệt kê các cookie và có ý tưởng chung về việc sử dụng chúng, đã đến lúc cần có một cái nhìn sâu hơn về các cookie có vẻ thú vị. Người thử nghiệm quan tâm đến cookie nào? Một cookie, để cung cấp một phương pháp quản lý phiên an toàn, phải kết hợp một số đặc điểm, mỗi đặc điểm nhằm mục đích bảo vệ cookie khỏi một loại tấn công khác nhau.
Những đặc điểm này được tóm tắt dưới đây:
- Tính không thể đoán trước: một cookie phải chứa một số lượng dữ liệu khó đoán. Càng khó tạo ra một cookie hợp lệ, thì càng khó xâm nhập vào phiên của người dùng hợp pháp. Nếu kẻ tấn công có thể đoán được cookie được sử dụng trong một phiên hoạt động của một người dùng hợp pháp, chúng sẽ có thể hoàn toàn mạo danh người dùng đó (chiếm quyền điều khiển phiên). Để làm cho cookie không thể đoán trước được, có thể sử dụng các giá trị ngẫu nhiên hoặc mật mã.
- Chống giả mạo: cookie phải chống lại các nỗ lực sửa đổi có hại. Nếu người thử nghiệm nhận được một cookie như IsAdmin = Không, việc sửa đổi nó để có quyền quản trị là điều nhỏ, trừ khi ứng dụng thực hiện kiểm tra kỹ lưỡng (ví dụ: thêm vào cookie một hàm băm được mã hóa có giá trị của nó)
- Hết hạn: cookie quan trọng phải chỉ có hiệu lực trong một khoảng thời gian thích hợp và phải được xóa khỏi đĩa hoặc bộ nhớ sau đó để tránh nguy cơ bị phát lại. Điều này không áp dụng cho các cookie lưu trữ dữ liệu không quan trọng cần được ghi nhớ trong các phiên (ví dụ: giao diện trang web).
- Cờ an toàn: một cookie có giá trị quan trọng đối với tính toàn vẹn của phiên phải bật cờ này để chỉ cho phép truyền trong một kênh được mã hóa để ngăn chặn việc nghe trộm.
- Cách tiếp cận ở đây là thu thập đủ số lượng các trường hợp của cookie và bắt đầu tìm kiếm các mẫu về giá trị của chúng. Ý nghĩa chính xác của “đủ” có thể thay đổi từ một số ít mẫu, nếu phương pháp tạo cookie rất dễ bị hỏng, cho đến vài nghìn, nếu người thử nghiệm cần tiến hành một số phân tích toán học (ví dụ: chi-square, chất thu hút. Xem sau để biết thêm thông tin).
Điều quan trọng là phải đặc biệt chú ý đến quy trình làm việc của ứng dụng, vì trạng thái của một phiên có thể có tác động nặng nề đến các cookie được thu thập. Cookie được thu thập trước khi được xác thực có thể rất khác với cookie thu được sau khi xác thực.
Một khía cạnh khác cần lưu ý là thời gian. Luôn ghi lại thời gian chính xác khi cookie được lấy, khi có khả năng thời gian đóng một vai trò trong giá trị của cookie (máy chủ có thể sử dụng dấu thời gian như một phần của giá trị cookie). Thời gian được ghi lại có thể là giờ địa phương hoặc dấu timestamp của máy chủ được bao gồm trong phản hồi HTTP (hoặc cả hai).
Khi phân tích các giá trị đã thu thập, người thử nghiệm nên cố gắng tìm ra tất cả các biến có thể đã ảnh hưởng đến giá trị cookie và cố gắng thay đổi chúng tại một thời điểm. Việc chuyển đến máy chủ các phiên bản đã sửa đổi của cùng một cookie có thể rất hữu ích trong việc hiểu cách ứng dụng đọc và xử lý cookie.
Ví dụ về các kiểm tra được thực hiện ở giai đoạn này bao gồm:
Bộ ký tự nào được sử dụng trong cookie? Cookie có giá trị số không? chữ và số? hệ thập lục phân? Điều gì xảy ra nếu người thử nghiệm chèn các ký tự cookie không thuộc bộ ký tự mong đợi?
Cookie có bao gồm các phần phụ khác nhau mang các phần thông tin khác nhau không? Các phần khác nhau được tách ra như thế nào? Với những dấu phân cách nào? Một số phần của cookie có thể có phương sai cao hơn, những phần khác có thể không đổi, những phần khác có thể chỉ giả định một bộ giá trị giới hạn. Chia nhỏ cookie thành các thành phần cơ bản của nó là bước đầu tiên và cơ bản.
Ví dụ về cookie có cấu trúc dễ phát hiện như sau:
ID = 5a0acfc7ffeb919: CR = 1: TM = 1120514521: LM = 1120514521: S = j3am5KzC4v01ba3q
Ví dụ này cho thấy 5 trường khác nhau, chứa các loại dữ liệu khác nhau:
- ID – hệ thập lục phân
- CR – số nguyên nhỏ
- TM và LM – số nguyên lớn. (Và thật kỳ lạ là chúng có cùng giá trị. Đáng xem điều gì sẽ xảy ra khi sửa đổi một trong số chúng)
- S – chữ và số
Ngay cả khi không sử dụng dấu phân cách, việc có đủ mẫu có thể giúp hiểu cấu trúc.
Brute Force Attacks
Các cuộc tấn công bạo lực chắc chắn dẫn đến từ các câu hỏi liên quan đến khả năng dự đoán và tính ngẫu nhiên. Sự khác biệt trong ID phiên phải được xem xét cùng với thời lượng và thời gian chờ của phiên ứng dụng. Nếu sự thay đổi trong các ID phiên là tương đối nhỏ và hiệu lực của ID phiên dài, thì khả năng xảy ra một cuộc tấn công brute-force thành công sẽ cao hơn nhiều.
ID phiên dài (hay đúng hơn là một ID có nhiều phương sai) và thời gian hiệu lực ngắn hơn sẽ khiến việc thành công trong một cuộc tấn công brute force khó hơn rất nhiều.
- Một cuộc tấn công brute-force vào tất cả các ID phiên có thể mất bao lâu?
- Là phiên
- Không gian ID đủ lớn để ngăn chặn hành vi cưỡng bức? Ví dụ: độ dài của khóa có đủ khi so sánh với tuổi thọ hợp lệ không?
- Sự chậm trễ giữa các lần kết nối với các ID phiên khác nhau có giảm thiểu nguy cơ bị tấn công này không?
Ví dụ và thử nghiệm hộp xám
Nếu người kiểm tra có quyền truy cập vào việc triển khai lược đồ quản lý phiên, họ có thể kiểm tra những điều sau:
- Mã phiên ngẫu nhiên
ID phiên hoặc Cookie được cấp cho máy khách không được dễ dàng dự đoán (không sử dụng thuật toán tuyến tính dựa trên các biến có thể dự đoán được như địa chỉ IP của máy khách). Việc sử dụng các thuật toán mật mã với độ dài khóa 256 bit được khuyến khích (như AES).
- Độ dài mã thông báo
ID phiên sẽ có độ dài ít nhất 50 ký tự.
- Hết thời gian phiên
Mã thông báo phiên phải có thời gian chờ xác định (nó phụ thuộc vào mức độ quan trọng của dữ liệu được quản lý ứng dụng)
- Cấu hình cookie:
non-persistent: chỉ bộ nhớ RAM
secure (set only on HTTPS channel): Set-Cookie: cookie=data; path=/; domain=.aaa.it; secure
HTTPOnly (not readable by a script): Set-Cookie: cookie=data; path=/; domain=.aaa.it; HttpOnly
