Cookie Web (ở đây được gọi là cookie) thường là vectơ tấn công chính đối với người dùng độc hại (thường nhắm mục tiêu người dùng khác) và ứng dụng phải luôn có trách nhiệm giải trình để bảo vệ cookie.
HTTP là một giao thức không trạng thái, có nghĩa là nó không có bất kỳ tham chiếu nào đến các yêu cầu được gửi bởi cùng một người dùng. Để khắc phục sự cố này, các phiên đã được tạo và thêm vào các yêu cầu HTTP. Các trình duyệt, như đã thảo luận trong phần thử nghiệm lưu trữ của trình duyệt, chứa vô số cơ chế lưu trữ. Trong phần đó của hướng dẫn, mỗi thứ đều được thảo luận kỹ lưỡng.
Các bài viết liên quan:
Cơ chế lưu trữ phiên được sử dụng nhiều nhất trong các trình duyệt là lưu trữ cookie. Máy chủ có thể đặt cookie bằng cách bao gồm tiêu đề Set-Cookie trong phản hồi HTTP hoặc qua JavaScript. Cookie có thể được sử dụng vì nhiều lý do, chẳng hạn như:
- session management
- personalization
- tracking
Để bảo mật dữ liệu cookie, ngành công nghiệp đã phát triển các phương tiện giúp khóa các cookie này và hạn chế bề mặt tấn công của chúng. Theo thời gian, cookie đã trở thành một cơ chế lưu trữ ưa thích cho các ứng dụng web, vì chúng cho phép sử dụng và bảo vệ một cách linh hoạt.
Các phương tiện để bảo vệ cookie là:
Mục tiêu kiểm tra Cookies Attributes
Đảm bảo rằng cấu hình bảo mật thích hợp được đặt cho cookie.
Làm thế nào để kiểm tra Cookies Attributes
Dưới đây, mô tả về mọi thuộc tính và tiền tố sẽ được thảo luận. Người kiểm tra phải xác nhận rằng chúng đang được ứng dụng sử dụng đúng cách. Cookie có thể được xem xét bằng cách sử dụng proxy chặn hoặc bằng cách xem xét kho chứa cookie của trình duyệt.
Thuộc tính cookie
Secure Attribute
Thuộc tính Secure yêu cầu trình duyệt chỉ gửi cookie nếu yêu cầu được gửi qua một kênh bảo mật như HTTPS. Điều này sẽ giúp bảo vệ cookie không bị chuyển qua các yêu cầu không được mã hóa. Nếu ứng dụng có thể được truy cập qua cả HTTP và HTTPS, kẻ tấn công có thể chuyển hướng người dùng gửi cookie của họ như một phần của các yêu cầu không được bảo vệ.
HttpOnly Attribute
Thuộc tính HttpOnly được sử dụng để giúp ngăn chặn các cuộc tấn công như rò rỉ phiên, vì nó không cho phép truy cập cookie thông qua tập lệnh phía máy khách như JavaScript.
Điều này không giới hạn toàn bộ bề mặt tấn công của các cuộc tấn công XSS, vì kẻ tấn công vẫn có thể gửi yêu cầu thay cho người dùng, nhưng hạn chế rất nhiều phạm vi tiếp cận của các vectơ tấn công XSS.
Domain Attribute
Thuộc tính Domain được sử dụng để so sánh miền của cookie với miền của máy chủ mà yêu cầu HTTP đang được thực hiện. Nếu tên miền khớp hoặc nếu nó là một tên miền phụ, thì thuộc tính đường dẫn sẽ được kiểm tra tiếp theo.
Lưu ý rằng chỉ các máy chủ thuộc miền được chỉ định mới có thể đặt cookie cho miền đó. Ngoài ra, thuộc tính miền không được là miền cấp cao nhất (chẳng hạn như .gov hoặc .com) để ngăn máy chủ đặt cookie tùy ý cho miền khác (chẳng hạn như đặt cookie cho owasp.org). Nếu thuộc tính miền không được đặt, thì tên máy chủ của máy chủ đã tạo cookie được sử dụng làm giá trị mặc định của miền.
Ví dụ: nếu cookie được đặt bởi một ứng dụng tại app.mydomain.com mà không có thuộc tính miền nào được đặt, thì cookie sẽ được gửi lại cho tất cả các yêu cầu tiếp theo cho app.mydomain.com và các miền phụ của nó (chẳng hạn như hacker.app.mydomain .com), nhưng không phải otherapp.mydomain.com. Nếu nhà phát triển muốn nới lỏng hạn chế này, thì họ có thể đặt thuộc tính miền thành mydomain.com. Trong trường hợp này, cookie sẽ được gửi đến tất cả các yêu cầu đối với tên miền phụ app.mydomain.com và mydomain.com, chẳng hạn như hacker.app.mydomain.com và thậm chí cả bank.mydomain.com. Nếu có một máy chủ dễ bị tấn công trên một miền phụ (ví dụ: otherapp.mydomain.com) và thuộc tính miền được đặt quá lỏng lẻo (ví dụ: mydomain.com), thì máy chủ dễ bị tấn công có thể được sử dụng để thu thập cookie (chẳng hạn như mã thông báo phiên) trên toàn bộ phạm vi của mydomain.com.
Path Attribute
Thuộc tính Path đóng một vai trò quan trọng trong việc thiết lập phạm vi của cookie cùng với miền. Ngoài miền, có thể chỉ định đường dẫn URL mà cookie hợp lệ. Nếu miền và đường dẫn khớp, thì cookie sẽ được gửi trong yêu cầu. Cũng giống như thuộc tính miền, nếu thuộc tính đường dẫn được đặt quá lỏng lẻo, thì nó có thể khiến ứng dụng dễ bị tấn công bởi các ứng dụng khác trên cùng một máy chủ. Ví dụ: nếu thuộc tính đường dẫn được đặt thành root của máy chủ web /, thì cookie của ứng dụng sẽ được gửi đến mọi ứng dụng trong cùng một miền (nếu nhiều ứng dụng nằm trong cùng một máy chủ). Một vài ví dụ cho nhiều ứng dụng trong cùng một máy chủ:
- path=/bank
- path=/private
- path=/docs
- path=/docs/admin
Expires Attribute
Thuộc tính Expires được sử dụng để:
- đặt cookie liên tục
- giới hạn tuổi thọ nếu một phiên hoạt động quá lâu
- loại bỏ một cách cưỡng bức một cookie bằng cách đặt nó thành một ngày trong quá khứ
Không giống như cookie phiên, cookie liên tục sẽ được trình duyệt sử dụng cho đến khi cookie hết hạn. Khi ngày hết hạn đã vượt quá thời gian đã đặt, trình duyệt sẽ xóa cookie.
SameSite Attribute
Sự phân bổ của SameSite được sử dụng để khẳng định rằng một cookie không nên được gửi cùng với các yêu cầu trên nhiều trang web. Tính năng này cho phép máy chủ giảm thiểu rủi ro rò rỉ thông tin biên giới chéo. Trong một số trường hợp, nó cũng được sử dụng như một chiến lược giảm thiểu rủi ro (hoặc cơ chế phòng thủ theo chiều sâu) để ngăn chặn các cuộc tấn công giả mạo yêu cầu chéo trang web. Thuộc tính này có thể được định cấu hình ở ba chế độ khác nhau:
- Strict
- Lax
- None
Strict
Giá trị Nghiêm ngặt là mức sử dụng hạn chế nhất của SameSite, cho phép trình duyệt chỉ gửi cookie đến ngữ cảnh của bên thứ nhất mà không cần điều hướng cấp cao nhất. Nói cách khác, dữ liệu được liên kết với cookie sẽ chỉ được gửi theo các yêu cầu khớp với trang web hiện tại được hiển thị trên thanh URL của trình duyệt. Cookie sẽ không được gửi theo yêu cầu do các trang web của bên thứ ba tạo ra. Giá trị này đặc biệt được khuyến nghị cho các hành động được thực hiện trên cùng một miền. Tuy nhiên, nó có thể có một số hạn chế với một số hệ thống quản lý phiên ảnh hưởng tiêu cực đến trải nghiệm điều hướng của người dùng. Vì trình duyệt sẽ không gửi cookie theo bất kỳ yêu cầu nào được tạo từ miền hoặc email của bên thứ ba, người dùng sẽ được yêu cầu đăng nhập lại ngay cả khi họ đã có phiên xác thực.
Lax
Giá trị Lax ít hạn chế hơn so với Nghiêm ngặt. Cookie sẽ được gửi nếu URL bằng miền của cookie (bên thứ nhất) ngay cả khi liên kết đến từ miền của bên thứ ba. Giá trị này được hầu hết các trình duyệt coi là hành vi mặc định vì nó cung cấp trải nghiệm người dùng tốt hơn giá trị Nghiêm ngặt. Nó không kích hoạt các nội dung, chẳng hạn như hình ảnh, nơi có thể không cần cookie để truy cập chúng.
None
Giá trị Không có chỉ định rằng trình duyệt sẽ gửi cookie theo các yêu cầu trên nhiều trang web (hành vi bình thường trước khi triển khai SamseSite) chỉ khi thuộc tính Bảo mật cũng được sử dụng, ví dụ: SameSite = Không có; Chắc chắn. Đây là giá trị được đề xuất, thay vì không chỉ định bất kỳ giá trị SameSite nào, vì nó buộc sử dụng thuộc tính an toàn.
Cookie Prefixes
Theo thiết kế, cookie không có khả năng đảm bảo tính toàn vẹn và bí mật của thông tin được lưu trữ trong đó. Những hạn chế đó khiến máy chủ không thể tin tưởng về cách các thuộc tính của cookie nhất định được thiết lập khi tạo. Để cung cấp cho các máy chủ các tính năng như vậy theo cách tương thích ngược, ngành công nghiệp đã đưa ra khái niệm Tiền tố tên cookie để tạo điều kiện thuận lợi cho việc chuyển các chi tiết như vậy được nhúng như một phần của tên cookie.
Host Prefix
Tiền tố __Host- yêu cầu cookie đáp ứng các điều kiện sau:
- Cookie phải được đặt bằng thuộc tính Secure.
- Cookie phải được đặt từ một URI được tác nhân người dùng coi là an toàn.
- Chỉ được gửi tới máy chủ đặt cookie và KHÔNG ĐƯỢC đưa vào bất kỳ thuộc tính Miền nào.
- Cookie phải được đặt bằng Pathattribute với giá trị là / để nó sẽ được gửi theo mọi yêu cầu đến máy chủ.
Vì lý do này, Set-Cookie: __Host-SID=12345; Secure; Path=/ sẽ được chấp nhận trong khi bất kỳ đường nào sau đây sẽ luôn bị từ chối:
Set-Cookie: __Host-SID=12345 Set-Cookie: __Host-SID=12345; Secure Set-Cookie: __Host-SID=12345; Domain=site.example Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/ Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/
Secure Prefix
Secure Prefix– ít hạn chế hơn và có thể được đưa vào bằng cách thêm chuỗi phân biệt chữ hoa chữ thường __Secure- vào tên cookie. Bất kỳ cookie nào khớp với tiền tố __Secure- sẽ phải đáp ứng các điều kiện sau:
- Cookie phải được đặt bằng thuộc tính Secure.
- Cookie phải được đặt từ một URI được tác nhân người dùng coi là an toàn.
Strong Practices
Dựa trên nhu cầu của ứng dụng và cách hoạt động của cookie, các thuộc tính và tiền tố phải được áp dụng. Cookie càng bị khóa càng tốt.
Kết hợp tất cả những điều này lại với nhau, chúng ta có thể xác định cấu hình thuộc tính cookie an toàn nhất là:
Set-Cookie: __Host-SID=<session token>; path=/; Secure; HttpOnly; SameSite=Strict
