Khi một developer được hỏi “Website của bạn có bảo mật không?”, câu trả lời phổ biến nhất là: “Có, mình đã dùng mã hóa HTTPS rồi.” Câu trả lời đó không sai nhưng chưa đủ và nó không đồng nghĩa với việc website của bạn đã an toàn.
Mã hóa HTTPS giải quyết vấn đề: bảo vệ dữ liệu trên đường truyền giữa trình duyệt và server. Nhưng hầu hết các cuộc tấn công thực tế không xảy ra trên đường truyền lại thường xảy ra ở lớp ứng dụng, cấu hình server sai, cookie không được thiết lập đúng, ở dữ liệu lưu trong database mà không được mã hóa.
Bài viết này, dựa trực tiếp vào nội dung của khóa học “Thiết kế ứng dụng Web an toàn” do CO-WELL tổ chức triển khai. Khóa học được nhận chuyển giao bản quyền từ GSX (Global Security Expert – Nhật Bản) đơn vị phát triển chương trình chuẩn cho chứng chỉ SecuriST. Bài viết chỉ ra từng lớp bảo mật mà developer hay bỏ qua, và cách xử lý cụ thể từng lớp đó.
Hiểu Đúng Về Cách Mã Hóa HTTPS Bảo Vệ Website Của Bạn?
Để biết mã hóa HTTPS bảo vệ được gì, trước tiên cần hiểu vấn đề mà nó được thiết kế để giải quyết.
TCP/IP là nền tảng của mọi kết nối internet, là giao thức có thể bị:
- Nghe lén (Eavesdropping): Kẻ tấn công đọc được nội dung trao đổi giữa trình duyệt và server
- Giả mạo nội dung (Tampering): Dữ liệu bị chỉnh sửa trong quá trình truyền mà không ai biết
- Mạo danh server (Impersonation): Kẻ tấn công giả làm server để đánh cắp thông tin
HTTPS = HTTP + SSL/TLS giải quyết đúng ba vấn đề này bằng tổ hợp công nghệ mã hóa:
Những vấn đề HTTPS không bảo vệ:
- Logic lỗi bên trong ứng dụng (SQL Injection, XSS, CSRF)
- Dữ liệu sau khi đã đến server trong quá trình xử lý và lưu trữ
- Cấu hình sai server hoặc header thiếu
- Cookie không có thuộc tính bảo mật
- Phiên bản TLS cũ có lỗ hổng đã biết
Nói dễ hiểu hơn: HTTPS bảo vệ phần đường ống không bảo vệ những gì bên trong đường ống.
Chứng Chỉ Bảo Mật SSL/TLS Hoạt Động Như Thế Nào?
Khi trình duyệt kết nối đến https://example.com, làm sao nó biết đang nói chuyện với server thật chứ không phải kẻ tấn công?
Câu trả lời là CA (Certificate Authority) tổ chức phát hành chứng chỉ bên thứ ba đáng tin cậy.
Cơ chế hoạt động
- Server (Bob) đăng ký public key với CA (Trent)
- CA dùng private key của mình để ký chữ ký số lên public key của server → tạo ra chứng chỉ
- Trình duyệt (Alice) nhận chứng chỉ, xác minh chữ ký số bằng public key của CA (đã được tích hợp sẵn trong trình duyệt)
- Nếu hợp lệ → trình duyệt tin tưởng kết nối là chính chủ → tiến hành mã hóaVai trò của CA.
Vai trò của CA
- Xác nhận danh tính người điều hành server khi đăng ký
- Quản lý thu hồi chứng chỉ khi cần qua CRL (Certificate Revocation List)
- Hỗ trợ kiểm tra trạng thái chứng chỉ trực tuyến qua OCSP (Online Certificate Status Protocol)
3 Loại Chứng Chỉ SSL/TLS
Lưu ý quan trọng từ giáo trình Thiết kế web bảo mật Khóa học Secure Web Application Design: Độ mạnh mã hóa của cả 3 loại là hoàn toàn như nhau khả năng ngăn chặn tấn công trung gian tương đương. Người dùng thông thường không phân biệt được sự khác nhau giữa DV, OV và EV. Không nên nhầm lẫn loại chứng chỉ với mức độ bảo mật tổng thể của website.
Các Cuộc Tấn Công Nhắm Vào Chứng Chỉ
Chứng chỉ không phải bất khả xâm phạm. Thực tế đã ghi nhận các hướng tấn công như sau:
- Đăng ký tên miền tương tự để phishing: Kẻ tấn công lấy chứng chỉ DV hợp lệ cho
paypa1.comvà tạo trang giả mạo hoàn hảo - Khai thác lỗ hổng cập nhật CRL: Tận dụng độ trễ giữa lúc chứng chỉ bị thu hồi và lúc trình duyệt biết
- Đánh cắp private key của CA: Năm 2011, CA DigiNotar của Hà Lan bị xâm nhập hơn 500 chứng chỉ giả được cấp cho các domain như
google.com,twitter.com - Kẻ tấn công tự trở thành CA: Có thể thực hiện ở một số quốc gia nếu có sự tham gia của cơ quan chính phủ
6 lớp bảo mật mà developer hay bỏ qua
Điểm chung của tất cả các cuộc tấn công trên: chúng xảy ra ở tầng CA và hạ tầng chứng chỉ, nằm ngoài tầm kiểm soát của developer. Bạn không thể ngăn DigiNotar bị hack, không thể kiểm soát tốc độ cập nhật CRL của trình duyệt.
Nhưng có những lỗ hổng khác hoàn toàn nằm trong tay bạn. Đây mới là nơi phần lớn sự cố thực tế xảy ra: cấu hình server sai, cookie thiếu thuộc tính bảo mật, header không được thiết lập, dữ liệu lưu trữ không mã hóa. Đây là 6 lớp bảo mật mà developer hay bỏ qua và có thể sửa ngay hôm nay.
Lớp 1: Dùng Đúng Phiên Bản TLS - Không Phải Cứ Có HTTPS Là Đủ
Đây là lỗi cấu hình phổ biến nhất mà developer không để ý: server vẫn đang hỗ trợ các phiên bản SSL/TLS cũ những phiên bản đã được chứng minh là có lỗ hổng nghiêm trọng.
Lịch sử phiên bản và trạng thái hiện tại
Lớp 2: Thuộc Tính Secure Cho Cookie - Lỗ Hổng Nhỏ, Hậu Quả Lớn
Đây là lỗi developer hay bỏ qua nhất khi triển khai HTTPS.
Vấn đề: Khi website chuyển sang HTTPS, nhiều developer nghĩ rằng cookie đương nhiên được bảo vệ. Sai. Nếu cookie không có thuộc tính Secure, trình duyệt vẫn gửi cookie qua HTTP khi có redirect hoặc request HTTP kể cả khi website chủ yếu dùng HTTPS.
Hậu quả: SessionID có thể bị lộ qua kết nối HTTP không mã hóa, cho phép kẻ tấn công đánh cắp phiên đăng nhập.
Theo kinh nghiệm của anh Trần Hữu Tài – BrSE của CO-WELL Asia, giảng viên khóa học: “Ngay cả khi cổng 80/tcp đã đóng thì vẫn cần thiết lập thuộc tính Secure.”
Lớp 3: HSTS - Buộc Trình Duyệt Luôn Dùng HTTPS
Ngay cả khi server đã cấu hình HTTPS hoàn hảo, vẫn còn một kẽ hở: lần truy cập đầu tiên của người dùng có thể là HTTP.
Nếu người dùng gõ example.com mà không có https://, trình duyệt thử HTTP trước tạo ra khoảnh khắc dễ bị SSL stripping attack: kẻ tấn công can thiệp trước khi redirect HTTPS diễn ra, giữ kết nối HTTP với nạn nhân trong khi tự kết nối HTTPS với server.
HSTS (HTTP Strict Transport Security)
HSTS là response header báo trình duyệt: “Từ nay, domain này chỉ truy cập bằng HTTPS. Không thử HTTP nữa.”
Strict-Transport-Security: max-age=31536000max-age=31536000: trình duyệt nhớ chính sách 1 năm (31.536.000 giây)- Thêm
includeSubDomainsđể áp dụng cho toàn bộ subdomain - Thêm
preloadđể đăng ký vào danh sách HSTS preload của Chrome/Firefox – bảo vệ ngay từ lần truy cập đầu tiên
Lớp 4: Security Headers: Những Dòng Config Bị Bỏ Quên
Ngoài HSTS, các HTTP response header quan trọng mà phần lớn developer không thiết lập:
Content-Security-Policy (CSP)
Kiểm soát nguồn tài nguyên được phép load, ngăn XSS và Clickjacking.
Chặn Clickjacking:
Content-Security-Policy: frame-ancestors 'none';Chỉ cho phép trang chính tự nhúng:
Content-Security-Policy: frame-ancestors 'self' https://www.example.com;Header cũ (vẫn dùng cho trình duyệt cũ, nhưng không còn được khuyến nghị chính thức):
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGINCache-Control: no-store
Header hay bị bỏ qua nhất trong số security headers.
Vấn đề: Trang chứa thông tin cá nhân trang tài khoản, lịch sử giao dịch, hóa đơn, có thể bị lưu trong cache của CDN, load balancer, proxy, hoặc trình duyệt. Người dùng không có quyền vẫn có thể xem nội dung đó sau.
Cache-Control: no-storeContent-Type với charset
Content-Type: text/html; charset=UTF-8
Luôn khai báo charset để ngăn MIME sniffing attack trình duyệt tự đoán content type và thực thi file theo cách không mong muốn. Không cho phép ký tự CR+LF (\r\n) trong HTTP Response Header để ngăn CRLF Injection
Access-Control-Allow-Origin
Access-Control-Allow-Origin: https://www.example.com
Chỉ cần thiết khi dùng XMLHttpRequest (XHR) cross-origin. Chỉ rõ domain cụ thể không dùng *. Dùng giá trị cố định thay vì tự động tạo từ request header Origin cách tạo động dễ bị bypass.
Lớp 5: Mã Hóa HTTPS Dữ Liệu Lưu Trữ: Sau Khi Đến Server Rồi Thì Sao?
HTTPS bảo vệ dữ liệu trên đường truyền. Nhưng khi dữ liệu đã đến server và lưu vào database hay file system ai bảo vệ nó?
Câu trả lời là mã hóa lưu trữ và chọn đúng thuật toán là điều không thể thỏa hiệp.
Danh Sách Mã Hóa CRYPTREC
Giáo trình GSX dùng Danh sách mã hóa CRYPTREC do Chính phủ Điện tử Nhật Bản đề xuất, làm tài liệu tham chiếu cho các thuật toán được phép dùng. Nguồn: https://www.cryptrec.go.jp/list.html
Các thuật toán được khuyến nghị:
Lớp 6: Trình Tạo Số Ngẫu Nhiên: Sai Ở Đây Có Thể Làm Mọi Thứ Sụp Đổ
Đây là lớp ít được nhắc đến nhất nhưng lại là nền tảng của mọi cơ chế bảo mật khác: SessionID, CSRF token, API key, salt mật khẩu, IV mã hóa… Tất cả đều phụ thuộc vào chất lượng số ngẫu nhiên.
Nếu kẻ tấn công có thể đoán hoặc tái tạo được số “ngẫu nhiên”, họ có thể đoán SessionID, giả mạo token, phá mã hóa. Mọi lớp bảo mật bên trên đều vô nghĩa.
Ba cấp độ số ngẫu nhiên
Chỉ số giả ngẫu nhiên mạnh về mặt mật mã trở lên mới được dùng cho SessionID, security token và key mã hóa.
Ba cấp độ số ngẫu nhiên
| Loại | Ngẫu nhiên |
Không đoán được |
Không lặp lại |
Dùng cho mã hóa? |
|---|---|---|---|---|
| Số giả ngẫu nhiên yếu | ✅ | ❌ | ❌ | Không |
| Số giả ngẫu nhiên mạnh | ✅ | ✅ | ❌ | Có |
| Số ngẫu nhiên thực sự | ✅ | ✅ | ✅ | Có (cần hardware) |
Bảng Tổng Hợp: 6 Lớp Bảo Mật Website Cần Kiểm Tra
Xem bài liên quan: Session Hijacking & Quản Lý Session – Lỗ Hổng Ẩn Trong Mọi Web App
Xem bài liên quan: Thiết Kế Bảo Mật Website – Hướng Dẫn Toàn Diện cho Web Developer
Từ Hiểu Biết Đến Triển Khai Có Hệ Thống
Biết 6 lớp bảo mật trên là bước đầu. Triển khai đúng tất cả trong một dự án thực tế với nhiều loại server, framework, CDN khác nhau, là kỹ năng cần thực hành có hướng dẫn.
Khóa học GSX – Thiết Kế Ứng Dụng Web An Toàn tại CO-WELL Tech Academy đào tạo toàn bộ lộ trình này theo hệ thống:
- Cấu hình mã hóa HTTPS đúng chuẩn: TLS version, cipher suite, certificate management
- Security headers: CSP, HSTS, Cache-Control, Content-Type
- Mã hóa dữ liệu lưu trữ theo danh sách CRYPTREC
- Số ngẫu nhiên mạnh: cách dùng và cách kiểm tra
Tại khóa học Thiết Kế Ứng Dụng Web An Toàn tại CO-WELL Tech Academy bạn sẽ học Giáo trình chuẩn từ GSX. Giáo trình được phát triển bởi ông Ueno Sen — Đại diện OWASP Japan.
Nhận Chứng chỉ từ Global Security Expert (GSX) sau khi hoàn thành
Đăng ký ngay khóa học GSX – Thiết Kế Ứng Dụng Web An Toàn tại CO-WELL Tech Academy
Bạn đang có băn khoăn nào cần được giải đáp?
HTTPS là cơ chế bảo vệ dữ liệu truyền giữa trình duyệt và server bằng giao thức SSL/TLS. HTTPS ngăn nghe lén, giả mạo nội dung và mạo danh server nhưng không bảo vệ logic ứng dụng, cấu hình server hay dữ liệu lưu trữ phía sau.
Chứng chỉ SSL/TLS là tài liệu kỹ thuật số do CA (Certificate Authority) cấp, xác nhận danh tính server và chứa public key để mã hóa. Có 3 loại DV, OV, EV nhưng độ mạnh mã hóa của cả 3 là như nhau; người dùng thông thường không phân biệt được sự khác nhau.
Không. TLS 1.0 và TLS 1.1 bị đánh dấu "không khuyến nghị" từ tháng 3/2021 theo RFC 8996 do có nhiều lỗ hổng đã biết. Server vẫn hỗ trợ các phiên bản này tạo ra rủi ro downgrade attack. Chỉ dùng TLS 1.2 trở lên kiểm tra bằng SSL Labs Server Test.
Không. no-cache vẫn cho phép lưu cache nhưng yêu cầu xác nhận lại với server dữ liệu vẫn tồn tại trong bộ đệm của CDN, load balancer hoặc trình duyệt. Phải dùng no-store để ngăn lưu cache hoàn toàn cho các trang chứa thông tin cá nhân hoặc nhạy cảm.
mt_rand() dùng thuật toán Mersenne Twister nhanh nhưng có thể dự đoán được. uniqid() tạo ID dựa trên thời gian hệ thống không đủ ngẫu nhiên. Cả hai là số giả ngẫu nhiên yếu, không đạt tiêu chuẩn mật mã. Dùng openssl_random_pseudo_bytes() với $strong=true cho SessionID và token bảo mật.
HSTS (HTTP Strict Transport Security) là HTTP response header báo trình duyệt chỉ kết nối bằng HTTPS với domain đó, không bao giờ dùng HTTP nữa. Thiết lập sau khi toàn bộ trang đã chuyển sang HTTPS nếu còn trang HTTP sẽ khiến người dùng không truy cập được. Giá trị max-age=31536000 (1 năm) là mức thông thường.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
