Cookie là một khái niệm hết sức cơ bản mà ta được học khi mới lập trình web. Tuy nhiên, nếu sử dụng không đúng cách, nó sẽ thành “mồi ngon” cho vô số hacker.
Bài viết này sẽ đề cập đến những cách hacker mà có thể lợi dụng cookie để chiếm quyền người dùng, tấn công hệ thống, cùng với phương pháp sử dụng cookie đúng cách để ngăn chặn những lỗ hổng này nhé.
Cookie – Chiếc “bánh qui” vô hại?
Server và client giao tiếp với nhau thông qua giao thức HTTP. Đặc điểm của giao thức này là stateless. Server không thể biết được 2 request có tới từ cùng 1 client hay không.
Vì đặt điểm này, cookie ra đời. Về bản chất, cookie là một file text nhỏ được server gửi về client, sau đó browser lưu vào máy người dùng. Khi client gửi request tới server, nó sẽ gửi kèm cookie. Server dựa vào cookie này để nhận ra người dùng.
Cookie thường có name, value, domain và expiration:
- Name, đi kèm với value: Tên cookie và giá trị của cookie đó
- Domain: Domain mà cookie được gửi lên. Như ở hình dưới, cookies chỉ được gửi khi client truy cập wordpress.com.
- Expiration: Thời gian cookie tồn tại ở máy client. Quá thời gian này, cookie sẽ bị xoá.
Bánh qui nho nhỏ, đầy những lỗ to to
Sau khi tìm hiểu cơ bản về cookie, ta sẽ tìm hiểu những lỗi bảo mật mà cookie có thể gây ra nhé.
Như mình đã nói, cookie được gửi kèm theo mỗi request lên server. Server dựa theo cookie để nhận dạng người dùng. Do đó, nếu có thể “chôm cookie” của người khác, ta có thể mạo danh người đó.
Cookie có thể bị chôm theo các con đường sau:
- Sniff cookie qua mạng: Sử dụng 1 số tool đơn giản để sniff như Fiddler, Wireshark, ta có thể chôm cookie của người dùng ở cùng mạng. Sau đó, sử dụng EditThisCookie để dump cookie này vào trình duyệt để mạo danh người dùng. (Xem demo bài HTTP).
- Chôm cookie (Cookie thief) bằng XSS: Với lỗ hỗng XSS, hacker có thể chạy mã độc (JavaScript) ở phía người dùng. JS có thể đọc giá trị từ cookie với hàm document.cookie. Hacker có thể gửi cookie này tới server của mình. Cookie này sẽ được dùng để mạo danh người dùng.
- Thực hiện tấn công kiểu CRSF (Cross-site request forgery). Hacker có thể post một link ảnh như sau:
- Trình duyệt sẽ tự động load link trong ảnh, dĩ nhiên là có kèm theo cookie. Đường link trong ảnh sẽ đọc cookie từ request, xác nhận người dùng, rút sạch tiền mà người dùng không hề hay biết. Cách tấn công này có rất nhiều biến thể, mình sẽ nói rõ ở bài viết sau.
Cách phòng chống
Xin nhắc lại lần thứ n, các bạn học cách tấn công Website để biết mà phòng chống chứ không nên dùng để đi hack phá làng phá xóm nhé. Nếu gặp lỗ hổng bảo mật ở trang web nào khác, vui lòng gửi mail thông báo cho admin để họ sửa chữa chứ đừng hack rồi khoe Facebook nhé.
Phần này của bài viết sẽ hướng dẫn các bạn cách sử dụng cookie đúng cách để tránh những lỗi bảo mật không đáng có.
- Nhớ set Expired và Max-Age: Để giảm thiểu thiệt hại khi cookie bị trộm, ta không nên để cookie sống quá lâu. Nên set thời gian sống của cookie trong khoảng 1 ngày tới 3 tháng, tuỳ theo yêu cầu của application.
- Sử dụng Flag HTTP Only: Cookie có flag này sẽ không thể truy cập thông qua hàm document.cookie. Do đó, dù web có bị lỗi XSS thì hacker không thể đánh cắp được nó.
- Sử dụng Flag Secure: Cookie có flag này chỉ được gửi qua giao thức HTTPS, hacker sẽ không thể sniff được.
- Vì cookie dễ bị tấn công, tuyệt đối không chứa những thông tin quan trọng trong cookie (Mật khẩu, số tài khoản, …). Nếu bắt buộc phải lưu thì cần mã hoá cẩn thận.
Note thêm: Nếu website của bạn sử dụng RESTful API, đừng sử dụng cookie để authorize người dùng mà hãy dùng OAuth hoặc WebToken. Token này được vào Header của mỗi request nên sẽ không bị dính lỗi CRSF nhé.
Các bạn có thể tìm hiểu thêm về cookie và các lỗi bảo mật liên quan ở đây:
- https://resources.infosecinstitute.com/securing-cookies-httponly-secure-flags/
- https://www.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/concepts/csesmsession_mgmt.htm
- https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/
- https://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly
- https://programmers.stackexchange.com/questions/298973/rest-api-security-stored-token-vs-jwt-vs-oauth
