Pemindaian eksternal pasif. Setiap temuan menyertakan observasi mentah yang dibuat oleh pemindai
dan perintah yang dapat Anda jalankan sendiri untuk mereproduksinya - tidak ada yang ditulis oleh model di sini.
14 kelompok pemeriksaan:
Menyelesaikan DNS dan memeriksa CAA · Memeriksa SPF dan DMARC · Memeriksa sertifikat TLS dan versi protokol · Menguji pengalihan HTTP ke HTTPS · Membaca header keamanan respons · Memeriksa atribut cookie · Memeriksa kebijakan CORS · Mencari banner versi · Memeriksa metode HTTP yang diizinkan · Memindai beranda untuk konten campuran dan formulir yang tidak aman · Mencari file konfigurasi dan kontrol versi yang terekspos · Memeriksa daftar direktori · Membaca robots.txt dan security.txt · Memeriksa port layanan yang terekspos
Memulai…
0%
Tentang Pemindaian Keamanan Situs Web
Banyak pemindai memberi Anda nilai huruf dan daftar kata yang menakutkan. Pemindai ini juga memberi nilai, tetapi setiap poin yang dikurangi terikat pada temuan yang menunjukkan respons yang benar-benar diterima dan perintah satu baris untuk mendapatkan respons yang sama, sehingga temuan adalah sesuatu yang bisa Anda pastikan, bukan sesuatu yang harus Anda percayai.
Fungsinya
Memeriksa DNS dan CAA, SPF dan DMARC, sertifikat TLS dan TLS 1.0/1.1, pengalihan ke HTTPS, header keamanan, atribut cookie, CORS, banner versi, metode HTTP, konten campuran, 23 jalur sensitif, daftar direktori, robots.txt, security.txt, dan 12 port layanan.
Setiap temuan membawa observasi mentah dan perintah shell untuk mereproduksinya.
Pemeriksaan yang tidak dapat dijalankan dilaporkan sebagai "tidak diperiksa" - tidak pernah diam-diam sebagai lolos.
Laporan diunduh sebagai Markdown atau JSON.
Cara kerja
1Masukkan domain yang menjadi tanggung jawab Anda.
2Pemindaian menjalankan probe pasif - permintaan biasa, tanpa eksploitasi.
3Baca temuan-temuan, masing-masing dengan buktinya, dan verifikasi yang penting.
Tidak ada temuan yang dikarang
Pemindai ini tidak berisi model bahasa. Tingkat keparahan, dampak, dan perbaikan sudah ditetapkan untuk setiap pemeriksaan, dan setiap temuan dibuat dari pengamatan nyata. Laporan di layar serta unduhan Markdown dan JSON disusun dari temuan yang sama, tanpa model sama sekali.
Cara nilai dihitung
Skor dimulai dari 100 dan berkurang 34 poin per temuan kritis, 13 per tinggi, 5 per sedang, dan 1,5 per rendah, dengan batas total per tingkat (tinggi 45, sedang 22, rendah 9). Hasil informasi dan yang lolos tidak mengurangi apa pun. 90 ke atas adalah A, 75 B, 60 C, 40 D, di bawahnya F. Satu file .env yang terbuka atau port database yang bisa dijangkau menurunkan situs yang bersih dari 100 ke 66, yaitu C; dua temuan seperti itu memberi 32, yaitu F.
Menghindari alarm palsu
Sebelum menguji jalur seperti /.git/HEAD atau /backup.sql, pemindai meminta alamat acak yang tidak mungkin ada dan mencatat cara situs menjawab. Sebuah jalur hanya dilaporkan terbuka jika mengembalikan HTTP 200, berbeda dari respons acuan tidak-ditemukan itu, dan cocok dengan tanda tangan file tersebut, sehingga situs yang menjawab setiap URL dengan beranda tidak dipenuhi temuan kritis.
Laporan bersih bukan sertifikat
Ini adalah pemeriksaan pasif terhadap situs yang berjalan. Pemeriksaan ini tidak mencakup logika aplikasi, autentikasi, kontrol akses, atau apa pun di belakang login - tempat pelanggaran nyata biasanya dimulai. Pemeriksaan yang tidak dapat diselesaikan dicantumkan sebagai tidak diperiksa justru karena alasan ini: hasil lolos yang berasal dari koneksi yang gagal adalah jaminan palsu, dan pemindaian tanpa temuan berarti tidak ada yang ditemukan, bukan berarti tidak ada apa-apa.
Pindai hanya yang menjadi milik Anda
Pindai domain yang Anda miliki atau yang izin tertulis untuk mengujinya Anda miliki. Alat ini menolak host yang diresolusi ke alamat privat atau internal, dan dibatasi tarifnya per IP, tetapi otorisasi tetap menjadi tanggung jawab Anda.
Pertanyaan
Apakah ini serangan aktif?
Tidak. Pemindai mengirim permintaan GET, HEAD, dan OPTIONS biasa, jabat tangan TLS (termasuk percobaan TLS 1.0 dan 1.1), pencarian DNS melalui DNS-over-HTTPS Cloudflare, dan koneksi TCP biasa ke 12 port. Tidak ada yang dieksploitasi, tidak ada formulir yang dikirim, dan tidak ada yang diubah.
Bisakah saya memindai situs web apa pun?
Hanya yang Anda miliki atau yang diizinkan untuk Anda uji. Memindai infrastruktur pihak ketiga tanpa izin bisa jadi melanggar hukum di tempat Anda.
Mengapa sebuah pemeriksaan mengatakan "tidak diperiksa"?
Karena tidak dapat diselesaikan - biasanya karena tidak ada yang merespons dari asal tersebut. Ini dilaporkan secara jujur daripada dicatat sebagai lolos.
Bisakah saya mengekspor laporan?
Ya, sebagai Markdown atau JSON, selama satu jam: laporan disimpan di cache server selama itu agar unduhan berfungsi, lalu kedaluwarsa. Tidak ada ekspor yang memakai model. Catatan penggunaan menyimpan jumlah temuan dan nilai, bukan domainnya.
File dan port apa saja yang diuji?
File: 23 path tetap, di antaranya /.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; masing-masing hanya dilaporkan jika responsnya cocok dengan tanda khas file itu sendiri. /.well-known/security.txt dihitung menguntungkan Anda jika dipublikasikan. Port: koneksi TCP biasa, tidak pernah percobaan login, ke 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Port database yang bisa dijangkau (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) atau Telnet dinilai kritis.
Apa yang ditandai oleh pemeriksaan SPF dan DMARC?
Kedua record dibaca dari DNS publik, bahkan untuk situs yang tidak mengirim email, karena tanpa keduanya siapa pun bisa mengirim email yang mengaku berasal dari domain Anda. Tidak ada record SPF bernilai sedang; record SPF yang berisi +all, yang mengizinkan setiap server di internet, bernilai tinggi. Tidak ada record DMARC di _dmarc bernilai sedang; p=none (atau tanpa tag p=) hanya memantau dan bernilai rendah; p=quarantine atau p=reject lolos. Domain yang sama sekali tidak mengirim email bisa memublikasikan v=spf1 -all.
Header keamanan apa saja yang diperiksa, dan nilai apa yang lolos?
Enam header pada respons halaman beranda Anda. Jika tidak ada, HSTS dan Content-Security-Policy bernilai tinggi, X-Content-Type-Options dan X-Frame-Options sedang, Referrer-Policy dan Permissions-Policy rendah. Strict-Transport-Security perlu max-age minimal 15552000 (180 hari): lebih pendek bernilai rendah, max-age=0 sedang. Content-Security-Policy ditandai melemah (sedang) jika script-src mengizinkan 'unsafe-inline', kebijakan mengizinkan 'unsafe-eval', atau default-src atau script-src berisi wildcard * tunggal. X-Content-Type-Options harus persis nosniff. X-Frame-Options harus DENY atau SAMEORIGIN, dan tidak diperlukan jika CSP menetapkan frame-ancestors. Referrer-Policy hanya ditandai untuk unsafe-url atau no-referrer-when-downgrade. Permissions-Policy cukup ada saja. Setiap header yang tidak ada atau lemah disertai perintah curl -sI agar Anda bisa memeriksanya sendiri.
Bagaimana alat ini memeriksa atribut cookie (Secure, HttpOnly, SameSite)?
Alat ini membaca setiap header Set-Cookie pada respons halaman beranda Anda (hingga 12 cookie) dan memeriksa Secure, HttpOnly, dan SameSite pada masing-masing. Tanpa Secure atau HttpOnly bernilai sedang; hanya tanpa SameSite bernilai rendah, dan SameSite=None tanpa Secure disebut khusus karena browser menolak cookie itu. Cookie yang memiliki ketiganya lolos. Perbaikan biasanya Secure; HttpOnly; SameSite=Lax (di Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY, dan SESSION_COOKIE_SAMESITE). Pemindaian tidak login, jadi cookie yang baru dibuat setelah login tidak terlihat. Periksa sendiri dengan curl -sI https://your-site/ | grep -i set-cookie
Bagaimana pemeriksaan CORS bekerja, dan kapan bernilai kritis?
Alat ini mengirim satu permintaan GET ke halaman beranda Anda dengan Origin: https://scanner-probe.example dan membaca Access-Control-Allow-Origin serta Access-Control-Allow-Credentials pada balasannya. Tanpa header Access-Control-Allow-Origin, atau dengan origin tetap yang tidak memantulkan origin uji, lolos. Memantulkan origin uji bersama Access-Control-Allow-Credentials: true bernilai kritis, karena situs mana pun yang dikunjungi pengguna yang sedang login bisa membaca responsnya. Memantulkan origin tanpa kredensial bernilai sedang. Wildcard * bernilai rendah, atau sedang jika kredensial juga diizinkan (browser menolak kombinasi itu). Hanya halaman beranda yang diuji dan tidak ada preflight OPTIONS yang dikirim, jadi uji rute API Anda secara terpisah dengan curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
Apa yang diuji pemeriksaan TLS (masa berlaku sertifikat, TLS 1.0 dan 1.1)?
Alat ini terhubung ke port 443 dan memvalidasi rantai sertifikat serta nama host. Sertifikat yang tidak valid bertingkat tinggi, sertifikat kedaluwarsa juga ditandai kritis, dan sertifikat yang tersisa kurang dari 15 hari bertingkat sedang; selain itu subjek, penerbit, tanggal kedaluwarsa, dan nama SAN ditampilkan sebagai lulus. Protokol yang dinegosiasikan harus TLS 1.2 atau TLS 1.3, versi yang lebih lama bertingkat tinggi. Lalu alat ini mencoba handshake TLS 1.0 dan TLS 1.1 secara terpisah: server yang menerima salah satunya mendapat temuan sedang, karena keduanya sudah dinyatakan usang oleh RFC 8996. Jika OpenSSL milik pemindai sendiri tidak bisa menawarkan versi lama itu, tidak ada yang dilaporkan alih-alih menebak. Perbaikan di nginx adalah ssl_protocols TLSv1.2 TLSv1.3; Periksa tanggalnya sendiri dengan echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Apakah alat ini memeriksa bahwa HTTP dialihkan ke HTTPS?
Ya. Alat ini meminta http://your-site/ tanpa mengikuti pengalihan. 301 atau 308 ke alamat https:// dinyatakan lulus. 302, 303, atau 307 ke HTTPS bertingkat rendah, karena browser tidak mengingat pengalihan sementara, sehingga setiap kunjungan baru dimulai dengan satu permintaan tanpa enkripsi. Halaman yang disajikan lewat HTTP tanpa enkripsi (jawaban 2xx) bertingkat tinggi. Jika port 80 sama sekali tidak menjawab, itu informatif, bukan kegagalan. Perbaikan di nginx adalah server { listen 80; return 301 https://$host$request_uri; }, lalu tambahkan Strict-Transport-Security. Periksa sendiri dengan curl -I http://your-site/
Metode HTTP apa saja yang ditandai (TRACE, PUT, DELETE)?
Alat ini mengirim satu permintaan OPTIONS ke halaman beranda Anda dan membaca header Allow, atau Access-Control-Allow-Methods jika Allow tidak ada. TRACE, TRACK, PUT, atau DELETE yang diumumkan bertingkat sedang; PATCH atau CONNECT saja bertingkat rendah; hanya metode baca standar dinyatakan lulus. Jika server tidak mengirim kedua header itu, tidak ada yang dilaporkan. Metode yang diumumkan belum tentu berfungsi, jadi pastikan dulu sebelum mengubah apa pun. TRACE dapat memantulkan header permintaan, termasuk cookie, kembali ke pemanggil (Cross-Site Tracing). nginx menolak TRACE secara bawaan; di Apache atur TraceEnable Off. Batasi PUT dan DELETE pada rute API yang membutuhkannya, di balik autentikasi. Periksa sendiri dengan curl -X OPTIONS -i https://your-site/
Bagaimana alat ini mendeteksi directory listing ("Index of /")?
Alat ini meminta 7 path: /, /static/, /assets/, /uploads/, /images/, /files/ dan /backup/. Path yang menjawab HTTP 200 dengan halaman yang judul atau heading utamanya diawali "Index of /" dilaporkan bertingkat sedang (CWE-548), karena daftar itu menampilkan file yang tidak ditautkan di mana pun, seperti cadangan, ekspor, dan versi lama. Jika tidak ada yang begitu, pemeriksaan lulus; jika situs tidak bisa dijangkau, dilaporkan sebagai tidak dilakukan. Perbaikan di nginx adalah autoindex off; (ini bawaannya, jadi cari autoindex on yang ditulis eksplisit), di Apache Options -Indexes, lalu pindahkan apa pun yang sensitif keluar dari web root. Periksa sendiri dengan curl -s https://your-site/uploads/ | head -20
Apakah alat ini menemukan konten campuran dan formulir yang mengirim lewat HTTP?
Ya, di beranda. Alat ini membaca HTML sebagaimana dikirim server (JavaScript tidak dijalankan) dan mencantumkan setiap tag script, link, iframe, atau img yang src atau href-nya diawali http://. Jika salah satunya file .js atau .css, temuannya sedang, karena skrip atau stylesheet yang diganti di perjalanan berjalan di dalam halaman HTTPS Anda; hanya gambar dan frame berarti rendah; tidak ada sama sekali berarti lulus (CWE-311). Formulir yang action-nya diawali http:// dilaporkan tinggi (CWE-319), karena semua yang diketik di dalamnya, termasuk kata sandi, dikirim tanpa enkripsi. Perbaikannya: ubah URL itu menjadi https:// atau jadikan relatif, dan tambahkan header Content-Security-Policy: upgrade-insecure-requests sebagai jaring pengaman. Periksa sendiri dengan curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
Apa yang diperiksa di robots.txt dan security.txt?
robots.txt: alat ini mengambil /robots.txt dan, jika jawabannya HTTP 200 berupa file teks, membaca baris Disallow dalam 8000 karakter pertama. Path Disallow yang mengandung admin, internal, private, backup, config, staging, test, api, secret, dev dilaporkan rendah (CWE-200): robots.txt bersifat publik dan hanya meminta crawler yang patuh untuk menjauh, jadi mencantumkan path tersebut justru mengiklankannya. Lindungi dengan login, dan gunakan noindex agar halaman tidak muncul di pencarian. security.txt: alat ini meminta /.well-known/security.txt, lokasi yang ditetapkan RFC 9116, dan menghitungnya sebagai nilai plus jika file memiliki baris Contact:. File yang tidak ada tidak mengurangi nilai. RFC 9116 juga mewajibkan kolom Expires:, yang tidak diperiksa pemindaian, jadi terbitkan keduanya, misalnya Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Periksa sendiri dengan curl -s https://your-site/.well-known/security.txt
Apa yang dicari pemeriksaan CAA dan bagaimana cara menambahkan record CAA?
Pemeriksaan ini mencari record CAA (RFC 8659) untuk nama host yang Anda masukkan, melalui DNS-over-HTTPS Cloudflare. Jika ada, pemeriksaan lulus dan bukti menampilkan paling banyak 5; jika tidak ada sama sekali, hasilnya "No CAA record" dengan tingkat rendah, karena tanpa itu otoritas sertifikat publik mana pun boleh menerbitkan sertifikat untuk nama tersebut. Record CAA mencantumkan CA yang benar-benar Anda pakai, misalnya your-site. IN CAA 0 issue "letsencrypt.org", ditambah 0 iodef "mailto:security@your-site" untuk menerima laporan. Tambahkan satu baris issue untuk setiap CA yang Anda pakai, dan baris issuewild jika sertifikat wildcard harus berasal dari CA lain. Periksa sendiri dengan dig CAA your-site
Mengapa pemindaian www atau subdomain melaporkan tidak ada CAA, SPF, atau DMARC?
Setiap pemeriksaan DNS berjalan pada nama persis yang Anda masukkan, jadi www.example.com dicari sebagai www.example.com, bukan example.com, dan ketiga record diwariskan dengan cara berbeda. CAA: otoritas sertifikat yang tidak menemukan record CAA di www.example.com naik ke example.com dan memakai record di sana (RFC 8659 bagian 3), jadi "No CAA record" pada subdomain bisa jadi alarm palsu. DMARC: penerima beralih ke kebijakan domain organisasi, yang dapat menetapkan kebijakan terpisah untuk subdomain dengan sp= (RFC 9989, yang menggantikan RFC 7489), jadi record yang tidak ada di _dmarc.www.example.com biasanya tercakup oleh _dmarc.example.com. SPF: tidak ada pewarisan (RFC 7208), jadi "No SPF record" akurat untuk nama itu; nama host yang tidak mengirim email dapat memublikasikan v=spf1 -all. Pencarian DNS yang gagal juga tampil sebagai record tidak ada. Pindai juga domain utamanya, atau pastikan dengan dig CAA example.com dan dig TXT _dmarc.example.com