Khi thông tin được gửi giữa máy khách và máy chủ, thông tin đó phải được mã hóa và bảo vệ để ngăn kẻ tấn công có thể đọc hoặc sửa đổi thông tin đó. Điều này thường được thực hiện nhất bằng cách sử dụng HTTPS, sử dụng giao thức Bảo mật lớp truyền tải (TLS), một sự thay thế cho giao thức Lớp cổng bảo mật (SSL) cũ hơn. TLS cũng cung cấp một cách để máy chủ chứng minh với máy khách rằng họ đã kết nối với đúng máy chủ, bằng cách xuất trình chứng chỉ số đáng tin cậy.
Các bài viết liên quan:
Trong những năm qua, đã có một số lượng lớn các điểm yếu về mật mã được xác định trong các giao thức SSL và TLS, cũng như trong các mật mã mà chúng sử dụng. Ngoài ra, nhiều triển khai của các giao thức này cũng có lỗ hổng nghiêm trọng. Do đó, điều quan trọng là phải kiểm tra xem các trang web không chỉ đang triển khai TLS mà còn đang làm như vậy một cách an toàn.
Mục tiêu kiểm tra WTLS
Xác thực cấu hình dịch vụ.
Xem lại độ mạnh và hiệu lực mật mã của chứng chỉ kỹ thuật số.
Đảm bảo rằng bảo mật TLS không thể bỏ qua và được triển khai đúng cách trên ứng dụng.
Làm thế nào để kiểm tra WTLS
Các vấn đề liên quan đến bảo mật lớp truyền tải có thể được chia thành các lĩnh vực sau:
Cấu hình máy chủ
Có một số lượng lớn các phiên bản giao thức, mật mã và tiện ích mở rộng được TLS hỗ trợ. Nhiều trong số này được coi là di sản và có những điểm yếu về mật mã, chẳng hạn như những điểm được liệt kê dưới đây. Lưu ý rằng những điểm yếu mới có khả năng được xác định theo thời gian, vì vậy danh sách này có thể không đầy đủ.
- SSLv2 (DROWN)
- SSLv3 (POODLE)
- TLSv1.0 (BEAST)
- EXPORT ciphers suites (FREAK)
- NULL ciphers (they only provide authentication).
- Anonymous ciphers (these may be supported on SMTP servers, as discussed in RFC 7672)
- RC4 ciphers (NOMORE)
- CBC mode ciphers (BEAST, Lucky 13)
- TLS compression (CRIME)
- Weak DHE keys (LOGJAM)
Hướng dẫn TLS phía máy chủ Mozilla nêu chi tiết các giao thức và mật mã hiện được khuyến nghị.
Khả năng khai thác
Cần nhấn mạnh rằng mặc dù nhiều cuộc tấn công trong số này đã được chứng minh trong môi trường phòng thí nghiệm, nhưng chúng thường không được coi là thực tế để khai thác trong thế giới thực, vì chúng yêu cầu một cuộc tấn công MitM (thường hoạt động) và tài nguyên đáng kể. Như vậy, chúng không có khả năng bị lợi dụng bởi bất kỳ ai khác ngoài các quốc gia.
Chứng chỉ kỹ thuật số
Điểm yếu về mật mã
Từ góc độ mật mã, có hai lĩnh vực chính cần được xem xét trên chứng chỉ kỹ thuật số:
- Độ mạnh chính ít nhất phải là 2048 bit.
- Thuật toán chữ ký ít nhất phải là SHA-256. Không nên sử dụng các thuật toán kế thừa như MD5 và SHA-1.
Validity
Cũng như được bảo mật bằng mật mã, chứng chỉ cũng phải được coi là hợp lệ (hoặc đáng tin cậy). Điều này có nghĩa là nó phải:
- Trong khoảng thời gian hiệu lực đã xác định.
- Bất kỳ chứng chỉ nào được cấp sau ngày 1 tháng 9 năm 2020 không được có thời hạn sử dụng tối đa quá 398 ngày.
- Được ký bởi tổ chức phát hành chứng chỉ đáng tin cậy (CA).
- Đây phải là CA công cộng đáng tin cậy cho các ứng dụng bên ngoài hoặc CA nội bộ cho các ứng dụng nội bộ.
- Đừng gắn cờ các ứng dụng nội bộ là có chứng chỉ không đáng tin cậy chỉ vì hệ thống của bạn không tin cậy CA.
- Có Tên Thay thế Chủ đề (SAN) phù hợp với tên máy chủ của hệ thống.
- Trường Tên chung (CN) bị bỏ qua bởi các trình duyệt hiện đại, mà chỉ xem xét SAN.
- Đảm bảo rằng bạn đang truy cập vào hệ thống với tên chính xác (ví dụ: nếu bạn truy cập máy chủ lưu trữ bằng IP thì bất kỳ chứng chỉ nào sẽ xuất hiện không đáng tin cậy).
- Một số chứng chỉ có thể được cấp cho các miền ký tự đại diện (chẳng hạn như * .example.org), nghĩa là chúng có thể hợp lệ cho nhiều miền phụ. Mặc dù thuận tiện, có một số lo ngại về bảo mật xung quanh điều này cần được xem xét. Những điều này được thảo luận trong Bảng lừa đảo bảo mật tầng truyền tải OWASP.
Chứng chỉ cũng có thể làm rò rỉ thông tin về hệ thống nội bộ hoặc tên miền trong trường Issuer và SAN, có thể hữu ích khi cố gắng xây dựng hình ảnh của mạng nội bộ hoặc tiến hành các hoạt động kỹ thuật xã hội.
Các lỗ hổng triển khai
Trong những năm qua, đã có những lỗ hổng trong các triển khai TLS khác nhau. Có quá nhiều để liệt kê ở đây, nhưng một số ví dụ chính là:
- Trình tạo số ngẫu nhiên có thể đoán trước được Debian OpenSSL (CVE-2008-0166)
- Thương lượng Gia hạn Bảo mật OpenSSL (CVE-2009-3555)
- OpenSSL Heartbleed (CVE-2014-0160)
- F5 TLS POODLE (CVE-2014-8730)
- Microsoft Schannel từ chối dịch vụ (MS14-066 / CVE CVE-2014-6321)
Các lỗ hổng ứng dụng
Cũng như cấu hình TLS bên dưới được định cấu hình an toàn, ứng dụng cũng cần sử dụng nó một cách an toàn. Một số điểm trong số này được đề cập ở những nơi khác trong hướng dẫn này:
- Không gửi dữ liệu nhạy cảm qua các kênh không được mã hóa (WSTG-CRYP-03)
- Đặt tiêu đề HTTP Nghiêm ngặt-Truyền tải-Bảo mật (WSTG-CONF-07)
- Đặt cờ Bảo mật trên cookie (WSTG-SESS-02)
Nội dung hoạt động hỗn hợp
Nội dung hoạt động hỗn hợp là khi các tài nguyên đang hoạt động (chẳng hạn như tập lệnh tới CSS) được tải qua HTTP không được mã hóa và được đưa vào trang bảo mật (HTTPS). Đây nguy hiểm vì nó sẽ cho phép kẻ tấn công sửa đổi các tệp này (vì chúng được gửi đi không được mã hóa), điều này có thể cho phép chúng thực thi mã tùy ý (JavaScript hoặc CSS) trong trang. Nội dung thụ động (chẳng hạn như hình ảnh) được tải qua một kết nối không an toàn cũng có thể làm rò rỉ thông tin hoặc cho phép kẻ tấn công phá hoại trang, mặc dù nó ít có khả năng dẫn đến thỏa hiệp hoàn toàn.
Lưu ý: các trình duyệt hiện đại sẽ chặn nội dung đang hoạt động được tải từ các nguồn không an toàn vào các trang an toàn.
Chuyển hướng từ HTTP sang HTTPS
Nhiều trang web sẽ chấp nhận các kết nối qua HTTP không được mã hóa và sau đó chuyển hướng người dùng ngay lập tức đến phiên bản bảo mật (HTTPS) của trang web với chuyển hướng 301 Moved Permanently. Phiên bản HTTPS của trang web sau đó sẽ đặt tiêu đề Nghiêm ngặt-Vận chuyển-Bảo mật để hướng dẫn trình duyệt luôn sử dụng HTTPS trong tương lai.
Tuy nhiên, nếu kẻ tấn công có thể chặn yêu cầu ban đầu này, chúng có thể chuyển hướng người dùng đến một trang web độc hại hoặc sử dụng một công cụ như sslstrip để chặn các yêu cầu tiếp theo.
Để bảo vệ chống lại kiểu tấn công này, trang web sử dụng phải được thêm vào danh sách tải trước.
Kiểm tra tự động WTLS
Có một số lượng lớn các công cụ quét có thể được sử dụng để xác định các điểm yếu trong cấu hình SSL / TLS của một dịch vụ, bao gồm cả các công cụ chuyên dụng và trình quét lỗ hổng mục đích chung. Một số trong số những cái phổ biến hơn là:
- Nmap (various scripts)
- OWASP O-Saft
- sslscan
- sslyze
- SSL Labs
- testssl.sh
Kiểm tra bằng tay WTLS
Cũng có thể thực hiện hầu hết các kiểm tra theo cách thủ công, sử dụng các giao diện dòng lệnh như openssl s_client hoặc gnutls-cli để kết nối với các giao thức, mật mã hoặc tùy chọn cụ thể.
Khi kiểm tra như vậy, hãy lưu ý rằng phiên bản OpenSSL hoặc GnuTLS đi kèm với hầu hết các hệ thống hiện đại có thể sẽ không hỗ trợ một số giao thức lỗi thời và không an toàn như mật mã SSLv2 hoặc EXPORT. Đảm bảo rằng phiên bản của bạn hỗ trợ các phiên bản lỗi thời trước khi sử dụng nó để thử nghiệm, nếu không bạn sẽ nhận được các phủ định sai.
Cũng có thể thực hiện thử nghiệm giới hạn bằng trình duyệt web, vì các trình duyệt hiện đại sẽ cung cấp thông tin chi tiết về các giao thức và mật mã đang được sử dụng trong các công cụ dành cho nhà phát triển của họ. Họ cũng cung cấp một cách dễ dàng để kiểm tra xem chứng chỉ có được coi là đáng tin cậy hay không, bằng cách duyệt đến dịch vụ và xem liệu bạn có được đưa ra cảnh báo về chứng chỉ hay không.
