Quét bên ngoài thụ động. Mỗi phát hiện đều kèm theo quan sát thô từ công cụ quét
và một lệnh bạn có thể tự chạy để tái hiện lại - không có nội dung nào do mô hình viết.
14 các nhóm kiểm tra:
Đang phân giải DNS và kiểm tra CAA · Đang kiểm tra SPF và DMARC · Đang kiểm tra chứng chỉ TLS và phiên bản giao thức · Đang kiểm tra chuyển hướng HTTP sang HTTPS · Đang đọc tiêu đề bảo mật của phản hồi · Đang kiểm tra thuộc tính cookie · Đang kiểm tra chính sách CORS · Đang tìm banner phiên bản · Đang kiểm tra các phương thức HTTP được phép · Đang quét trang chủ để tìm nội dung hỗn hợp và biểu mẫu không an toàn · Đang tìm tệp cấu hình và kiểm soát phiên bản bị lộ · Đang kiểm tra danh sách thư mục · Đang đọc robots.txt và security.txt · Đang kiểm tra các cổng dịch vụ bị lộ
Đang bắt đầu…
0%
Giới thiệu Quét bảo mật website
Nhiều công cụ quét đưa cho bạn một điểm chữ và một danh sách từ ngữ đáng sợ. Công cụ này cũng chấm điểm, nhưng mỗi điểm bị trừ đều gắn với một phát hiện cho thấy phản hồi thực sự nhận được và lệnh một dòng để bạn nhận lại đúng phản hồi đó, nên một phát hiện là thứ bạn có thể kiểm chứng chứ không phải thứ phải tin.
Chức năng
Kiểm tra DNS và CAA, SPF và DMARC, chứng chỉ TLS và TLS 1.0/1.1, chuyển hướng sang HTTPS, header bảo mật, thuộc tính cookie, CORS, banner phiên bản, phương thức HTTP, nội dung hỗn hợp, 23 đường dẫn nhạy cảm, liệt kê thư mục, robots.txt, security.txt và 12 cổng dịch vụ.
Mỗi phát hiện đi kèm quan sát thô và một lệnh shell để tái tạo nó.
Các kiểm tra không thể chạy được báo cáo là "chưa kiểm tra" - không bao giờ âm thầm coi là đạt.
Báo cáo được tải xuống dưới dạng Markdown hoặc JSON.
Cách thức hoạt động
1Nhập một tên miền mà bạn chịu trách nhiệm.
2Quá trình quét thực hiện các thăm dò bị động - các yêu cầu thông thường, không khai thác.
3Đọc các phát hiện, mỗi phát hiện có bằng chứng riêng, và xác minh những phát hiện quan trọng.
Không có phát hiện nào bị bịa đặt
Công cụ quét không chứa mô hình ngôn ngữ nào. Mức độ nghiêm trọng, tác động và cách khắc phục được cố định cho từng kiểm tra, và mỗi phát hiện được tạo từ một quan sát thực tế. Báo cáo trên màn hình và các bản tải về Markdown, JSON được dựng từ cùng các phát hiện đó, không có mô hình nào tham gia.
Điểm được tính thế nào
Điểm bắt đầu từ 100 và mất 34 điểm cho mỗi phát hiện nghiêm trọng, 13 cho mỗi mức cao, 5 cho mức trung bình và 1,5 cho mức thấp, với mức trần cho từng cấp (cao 45, trung bình 22, thấp 9). Kết quả thông tin và kết quả đạt không bị trừ. Từ 90 trở lên là A, từ 75 là B, từ 60 là C, từ 40 là D, thấp hơn là F. Chỉ một tệp .env bị lộ hoặc một cổng cơ sở dữ liệu truy cập được đã kéo một trang sạch từ 100 xuống 66, tức C; hai phát hiện như vậy cho 32, tức F.
Tránh báo động giả
Trước khi thử các đường dẫn như /.git/HEAD hay /backup.sql, công cụ quét yêu cầu một địa chỉ ngẫu nhiên không thể tồn tại và ghi lại cách trang phản hồi. Một đường dẫn chỉ bị báo là lộ khi trả về HTTP 200, khác với phản hồi mẫu không-tìm-thấy đó và khớp với chữ ký riêng của tệp, nên một trang trả trang chủ cho mọi URL sẽ không bị phủ kín phát hiện nghiêm trọng.
Một báo cáo sạch không phải là chứng chỉ
Đây là các kiểm tra bị động đối với một trang web đang hoạt động. Chúng không bao gồm logic ứng dụng, xác thực, kiểm soát truy cập, hoặc bất cứ thứ gì phía sau một đăng nhập - những nơi các vi phạm thực sự thường bắt đầu. Các kiểm tra không thể hoàn thành được liệt kê là chưa kiểm tra chính vì lý do này: một kết quả đạt bắt nguồn từ một kết nối thất bại là một sự trấn an giả, và một lượt quét không có phát hiện nào có nghĩa là không tìm thấy gì, không có nghĩa là không có gì ở đó.
Chỉ quét những gì thuộc về bạn
Quét các tên miền mà bạn sở hữu hoặc có quyền bằng văn bản để thử nghiệm. Công cụ này từ chối các máy chủ phân giải thành địa chỉ riêng tư hoặc nội bộ, và bị giới hạn tốc độ theo từng IP, nhưng việc cấp phép vẫn là trách nhiệm của bạn.
Câu hỏi
Đây có phải là một cuộc tấn công chủ động không?
Không. Công cụ gửi các yêu cầu GET, HEAD và OPTIONS thông thường, bắt tay TLS (gồm cả thử TLS 1.0 và 1.1), tra cứu DNS qua DNS-over-HTTPS của Cloudflare và kết nối TCP đơn giản tới 12 cổng. Không khai thác gì, không gửi biểu mẫu nào và không thay đổi gì.
Tôi có thể quét bất kỳ trang web nào không?
Chỉ những trang mà bạn sở hữu hoặc được phép thử nghiệm. Quét hạ tầng của bên thứ ba mà không có sự cho phép có thể là bất hợp pháp ở nơi bạn sinh sống.
Tại sao một kiểm tra lại ghi "chưa kiểm tra"?
Vì nó không thể hoàn thành được - thường là vì không có gì phản hồi từ nguồn đó. Điều này được báo cáo một cách trung thực thay vì được ghi nhận là đạt.
Tôi có thể xuất báo cáo không?
Có, dạng Markdown hoặc JSON, trong một giờ: báo cáo được giữ trong bộ nhớ đệm máy chủ suốt thời gian đó để việc tải về hoạt động, sau đó hết hạn. Không bản xuất nào dùng mô hình. Bản ghi sử dụng giữ số phát hiện và điểm, không giữ tên miền.
Công cụ kiểm tra những tệp và cổng nào?
Tệp: 23 đường dẫn cố định, trong đó có /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env; mỗi đường dẫn chỉ bị báo khi phản hồi khớp với chữ ký riêng của tệp đó. /.well-known/security.txt được tính có lợi cho bạn nếu đã công bố. Cổng: một kết nối TCP đơn thuần, không bao giờ thử đăng nhập, tới 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Cổng cơ sở dữ liệu truy cập được (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) hoặc Telnet bị xếp mức nghiêm trọng.
Kiểm tra SPF và DMARC báo những gì?
Cả hai bản ghi được đọc từ DNS công khai, kể cả với trang không gửi email, vì thiếu chúng thì ai cũng có thể gửi email giả danh tên miền của bạn. Không có bản ghi SPF là mức trung bình; bản ghi SPF chứa +all, cho phép mọi máy chủ trên internet, là mức cao. Không có bản ghi DMARC tại _dmarc là mức trung bình; p=none (hoặc không có thẻ p=) chỉ giám sát và là mức thấp; p=quarantine hoặc p=reject thì đạt. Tên miền không gửi email nào có thể công bố v=spf1 -all.
Công cụ kiểm tra những header bảo mật nào, và giá trị nào thì đạt?
Sáu header trong phản hồi trang chủ của bạn. Nếu thiếu, HSTS và Content-Security-Policy là mức cao, X-Content-Type-Options và X-Frame-Options mức trung bình, Referrer-Policy và Permissions-Policy mức thấp. Strict-Transport-Security cần max-age ít nhất 15552000 (180 ngày): ngắn hơn là mức thấp, max-age=0 là mức trung bình. Content-Security-Policy bị đánh dấu là bị làm yếu (trung bình) nếu script-src cho phép 'unsafe-inline', chính sách cho phép 'unsafe-eval', hoặc default-src hay script-src có ký tự đại diện * đứng riêng. X-Content-Type-Options phải đúng là nosniff. X-Frame-Options phải là DENY hoặc SAMEORIGIN, và không cần nếu CSP đã đặt frame-ancestors. Referrer-Policy chỉ bị báo khi là unsafe-url hoặc no-referrer-when-downgrade. Permissions-Policy chỉ cần có mặt. Mỗi header thiếu hoặc yếu đều kèm một lệnh curl -sI để bạn tự kiểm tra.
Công cụ kiểm tra các thuộc tính cookie (Secure, HttpOnly, SameSite) như thế nào?
Công cụ đọc mọi header Set-Cookie trong phản hồi trang chủ của bạn (tối đa 12 cookie) và kiểm tra Secure, HttpOnly và SameSite ở từng cookie. Thiếu Secure hoặc HttpOnly là mức trung bình; chỉ thiếu SameSite là mức thấp, còn SameSite=None mà không có Secure được nêu riêng vì trình duyệt từ chối cookie đó. Cookie có đủ cả ba thì đạt. Cách sửa thường dùng là Secure; HttpOnly; SameSite=Lax (trong Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY và SESSION_COOKIE_SAMESITE). Lần quét không đăng nhập, nên cookie chỉ được đặt sau khi đăng nhập sẽ không được thấy. Tự kiểm tra bằng curl -sI https://your-site/ | grep -i set-cookie
Kiểm tra CORS hoạt động thế nào, và khi nào là nghiêm trọng?
Công cụ gửi một yêu cầu GET đến trang chủ của bạn với Origin: https://scanner-probe.example và đọc Access-Control-Allow-Origin cùng Access-Control-Allow-Credentials trong phản hồi. Không có header Access-Control-Allow-Origin, hoặc có một origin cố định không phản hồi lại origin thử nghiệm, thì đạt. Phản hồi lại origin thử nghiệm kèm Access-Control-Allow-Credentials: true là nghiêm trọng, vì bất kỳ trang nào người dùng đã đăng nhập truy cập đều có thể đọc phản hồi của họ. Phản hồi lại origin mà không có thông tin xác thực là mức trung bình. Ký tự đại diện * là mức thấp, hoặc trung bình nếu thông tin xác thực cũng được cho phép (trình duyệt từ chối tổ hợp này). Chỉ trang chủ được thử và không gửi yêu cầu preflight OPTIONS, nên hãy kiểm tra riêng các route API bằng curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
Kiểm tra TLS kiểm tra những gì (hạn chứng chỉ, TLS 1.0 và 1.1)?
Công cụ kết nối tới cổng 443 và xác thực chuỗi chứng chỉ cùng tên máy chủ. Chứng chỉ không xác thực được ở mức cao, chứng chỉ đã hết hạn còn bị đánh dấu nghiêm trọng, và chứng chỉ còn dưới 15 ngày ở mức trung bình; nếu không, chủ thể, bên cấp, ngày hết hạn và các tên SAN được hiển thị là đạt. Giao thức thương lượng phải là TLS 1.2 hoặc TLS 1.3, phiên bản cũ hơn ở mức cao. Sau đó công cụ thử riêng một lần bắt tay TLS 1.0 và một lần TLS 1.1: máy chủ chấp nhận bất kỳ phiên bản nào trong hai sẽ nhận phát hiện mức trung bình, vì cả hai đã bị RFC 8996 loại bỏ. Nếu chính OpenSSL của trình quét không thể đề xuất phiên bản cũ, sẽ không báo gì thay vì đoán. Cách sửa trong nginx là ssl_protocols TLSv1.2 TLSv1.3; Tự kiểm tra ngày bằng lệnh echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Công cụ có kiểm tra HTTP chuyển hướng sang HTTPS không?
Có. Công cụ yêu cầu http://your-site/ mà không đi theo chuyển hướng. 301 hoặc 308 tới một địa chỉ https:// là đạt. 302, 303 hoặc 307 tới HTTPS ở mức thấp, vì trình duyệt không ghi nhớ chuyển hướng tạm thời nên mỗi lượt truy cập mới bắt đầu bằng một yêu cầu không mã hóa. Trang được phục vụ qua HTTP không mã hóa (phản hồi 2xx) ở mức cao. Nếu cổng 80 hoàn toàn không phản hồi, đó chỉ là thông tin, không phải lỗi. Cách sửa trong nginx là server { listen 80; return 301 https://$host$request_uri; }, sau đó thêm Strict-Transport-Security. Tự kiểm tra bằng lệnh curl -I http://your-site/
Công cụ cảnh báo những phương thức HTTP nào (TRACE, PUT, DELETE)?
Công cụ gửi một yêu cầu OPTIONS tới trang chủ và đọc header Allow, hoặc Access-Control-Allow-Methods nếu không có Allow. Nếu TRACE, TRACK, PUT hoặc DELETE được công bố thì ở mức trung bình; chỉ PATCH hoặc CONNECT thì ở mức thấp; chỉ có các phương thức đọc tiêu chuẩn là đạt. Nếu máy chủ không gửi header nào trong hai header này thì không có gì được báo cáo. Một phương thức được công bố chưa chắc đã hoạt động, vì vậy hãy xác nhận trước khi thay đổi gì. TRACE có thể phản hồi lại cho bên gọi các header của yêu cầu, kể cả cookie (Cross-Site Tracing). nginx mặc định từ chối TRACE; trên Apache hãy đặt TraceEnable Off. Chỉ để PUT và DELETE cho các route API cần đến chúng, sau lớp xác thực. Tự kiểm tra bằng lệnh curl -X OPTIONS -i https://your-site/
Công cụ phát hiện liệt kê thư mục ("Index of /") như thế nào?
Công cụ yêu cầu 7 đường dẫn: /, /static/, /assets/, /uploads/, /images/, /files/ và /backup/. Đường dẫn nào trả về HTTP 200 với trang có tiêu đề hoặc heading chính bắt đầu bằng "Index of /" sẽ được báo ở mức trung bình (CWE-548), vì danh sách để lộ các tệp không được liên kết ở đâu cả, như bản sao lưu, tệp xuất và phiên bản cũ. Nếu không đường dẫn nào như vậy thì kiểm tra đạt; nếu không truy cập được trang thì báo là chưa thực hiện. Cách sửa trong nginx là autoindex off; (đây là mặc định, nên hãy tìm dòng autoindex on được ghi rõ), trên Apache là Options -Indexes, sau đó chuyển mọi thứ nhạy cảm ra khỏi thư mục gốc web. Tự kiểm tra bằng lệnh curl -s https://your-site/uploads/ | head -20
Công cụ có phát hiện nội dung hỗn hợp và biểu mẫu gửi qua HTTP không?
Có, trên trang chủ. Công cụ đọc HTML đúng như máy chủ trả về (không chạy JavaScript) và liệt kê mọi thẻ script, link, iframe hoặc img có src hoặc href bắt đầu bằng http://. Nếu trong đó có tệp .js hoặc .css, phát hiện ở mức trung bình, vì một script hoặc stylesheet bị thay trên đường truyền sẽ chạy bên trong trang HTTPS của bạn; chỉ có ảnh và khung là mức thấp; không có cái nào là đạt (CWE-311). Biểu mẫu có action bắt đầu bằng http:// bị báo mức cao (CWE-319), vì mọi thứ gõ vào đó, kể cả mật khẩu, được gửi đi không mã hóa. Cách sửa: đổi các URL đó sang https:// hoặc dùng đường dẫn tương đối, và thêm header Content-Security-Policy: upgrade-insecure-requests làm lưới an toàn. Tự kiểm tra bằng curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
Công cụ kiểm tra gì trong robots.txt và security.txt?
robots.txt: công cụ tải /robots.txt và, nếu nhận HTTP 200 dưới dạng tệp văn bản, đọc các dòng Disallow trong 8000 ký tự đầu. Đường dẫn Disallow chứa admin, internal, private, backup, config, staging, test, api, secret, dev bị báo mức thấp (CWE-200): robots.txt là công khai và chỉ yêu cầu các trình thu thập tuân thủ tránh xa, nên liệt kê các đường dẫn đó là đang quảng cáo chúng. Hãy bảo vệ chúng bằng đăng nhập và dùng noindex để giữ trang ngoài kết quả tìm kiếm. security.txt: công cụ yêu cầu /.well-known/security.txt, vị trí do RFC 9116 quy định, và tính có lợi cho bạn khi tệp có dòng Contact:. Thiếu tệp không bị trừ điểm. RFC 9116 còn bắt buộc trường Expires:, mà lần quét không kiểm tra, vì vậy hãy công bố cả hai, ví dụ Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Tự kiểm tra bằng curl -s https://your-site/.well-known/security.txt
Kiểm tra CAA tìm gì và làm sao để thêm bản ghi CAA?
Công cụ tra cứu bản ghi CAA (RFC 8659) của tên máy chủ bạn nhập qua DNS-over-HTTPS của Cloudflare. Nếu tìm thấy, kiểm tra đạt và bằng chứng hiển thị tối đa 5 bản ghi; nếu không có bản ghi nào, công cụ báo "No CAA record" ở mức thấp, vì khi đó bất kỳ tổ chức cấp chứng chỉ công khai nào cũng có thể cấp chứng chỉ cho tên này. Bản ghi CAA liệt kê các CA bạn thực sự dùng, ví dụ your-site. IN CAA 0 issue "letsencrypt.org", cùng với 0 iodef "mailto:security@your-site" để nhận báo cáo. Thêm một dòng issue cho mỗi CA bạn dùng, và một dòng issuewild nếu chứng chỉ wildcard phải do CA khác cấp. Tự kiểm tra bằng dig CAA your-site
Vì sao quét www hoặc tên miền phụ lại báo không có CAA, SPF hoặc DMARC?
Mỗi kiểm tra DNS chạy trên đúng tên bạn nhập, nên www.example.com được tra cứu là www.example.com chứ không phải example.com, và ba bản ghi được kế thừa theo cách khác nhau. CAA: tổ chức cấp chứng chỉ không thấy bản ghi CAA trên www.example.com sẽ đi lên example.com và dùng bản ghi ở đó (RFC 8659, mục 3), nên "No CAA record" trên tên miền phụ có thể là cảnh báo sai. DMARC: bên nhận quay về chính sách của tên miền tổ chức, vốn có thể đặt chính sách riêng cho tên miền phụ bằng sp= (RFC 9989, thay thế RFC 7489), nên việc thiếu bản ghi tại _dmarc.www.example.com thường đã được _dmarc.example.com bao phủ. SPF: không có kế thừa (RFC 7208), nên "No SPF record" là đúng cho tên đó; tên máy chủ không gửi thư có thể công bố v=spf1 -all. Một truy vấn DNS thất bại cũng hiển thị là không có bản ghi. Hãy quét cả tên miền gốc, hoặc xác nhận bằng dig CAA example.com và dig TXT _dmarc.example.com