Halo semuanya!
Nama saya Andrey. Selama 10 tahun saya telah mencari kerentanan di berbagai layanan web. dan siap berbagi pengetahuan saya dengan Anda. Mei lalu, saya membuat laporan tentang ini di konferensi
Heisenbug , dan sekarang saya siap untuk membagikan pengetahuan saya di sini, di ruang terbuka Habr. Jadi mari kita mulai.
Suatu kali saya
menemukan kerentanan di server Facebook perusahaan terkenal. Orang-orang lupa untuk memperbarui ImageMagick (perpustakaan untuk pemrosesan gambar) dan membayarnya :) Dengan contoh ini saya ingin menunjukkan bahwa kita semua adalah orang dan kita semua dapat membuat kesalahan, tidak peduli di mana perusahaan dan di posisi apa kita bekerja. Satu-satunya masalah adalah bahwa kesalahan ini dapat menyebabkan segala macam risiko.
Semakin rumit aplikasi / situs web / alat Anda, semakin besar kemungkinan terjadi kesalahan.
Anda perlu memeriksa kerentanannya. Adalah bodoh untuk tidak melakukan ini sama sekali.
Item-item berikut mungkin merupakan tahap-tahap memeriksa aplikasi web:
- Persiapan:
- Tentukan titik masuk - pada kenyataannya, dari mana data dapat berasal dari dalam aplikasi;
- Identifikasi stok teknologi;
- Tentukan kerentanan apa yang masuk akal untuk diperiksa;
- Verifikasi Anda perlu memeriksa semua kerentanan yang berlaku pada ruang lingkup teknologi aplikasi web Anda;
- Analisis kode. Jangan malas, jangan lewatkan item ini. Dalam beberapa kasus, tanpa akses ke kode, sulit untuk menemukan kerentanan, dan ini juga memungkinkan Anda untuk melewati penyaringan yang mungkin tertanam dalam aplikasi Anda.
Saya akan membicarakan semua ini secara rinci.
Jadi, persiapan. Saya tidak akan fokus pada semua jenis kerentanan, jika tidak jumlah teks dalam artikel akan melebihi semua ukuran yang dapat dibayangkan dan tidak dapat dipahami. Saya menyarankan Anda untuk mulai belajar dari daftar
Sepuluh Proyek OWASP . Setiap beberapa tahun,
konsorsium OWASP membentuk daftar kerentanan paling relevan saat ini. Kami akan mempertimbangkan beberapa dari mereka secara detail.
Xss
XSS (skrip lintas situs) adalah serangan terhadap pengguna yang memungkinkan penyerang untuk mengeksekusi skrip sewenang-wenang dalam konteks browser korbannya. Paling sering, ini menyiratkan penerapan tag
HTML dan skrip
JS .
Contoh: pada suatu waktu ada layanan seperti itu
Yahoo! Ad Exchange Formulir pemulihan kata sandi memiliki parameter "
URL Kembali ". Ini dapat menunjukkan halaman mana yang akan kembali setelah proses pengaturan ulang kata sandi. Jika Anda memasukkan satu atau beberapa vektor lain di sana yang mengarah ke pelaksanaan kode
JS , Anda bisa mendapatkan semua
cookie pengguna. Kami akan menganalisis bagaimana ini terjadi dan mengapa.
Di sini adalah vektor itu sendiri. Sekaligus:
Untuk melakukan injeksi, Anda harus keluar dari konteks variabel di mana kami secara default (secara default - inilah yang diasumsikan programmer ketika ia menulis kode).
Di bawah ini adalah nilai aslinya. Ini adalah perilaku yang valid.
Kami melihat bahwa returnURL = / login.jsp
Ini termasuk dalam nilai
tag <input> .
Jika kita menambahkan tanda kutip setelah
jsp , kita akan melihat bahwa sintaks
HTML telah dituangkan. Untungnya, bahasa
HTML tidak ketat, pengurai akan melompati dan tidak akan ada masalah:
Tambahkan karakter lain. Di sini kita benar-benar keluar dari konteks
tag <input> :
Sekarang kami menambahkan pembukaan
tag <svg> , dan kami mendapatkan dua tag yang valid dalam hal sintaks:
Selanjutnya, tambahkan seluruh vektor serangan:
Dalam hal ini, gambar
svg diambil. Dengan menggunakan penangan
JavaScript "
onload ", kami menjalankan peringatan dengan
cookie pada dokumen. Itu saja! Penyerang menerima
cookie Anda.
Jika dalam buktinya kami hanya menampilkan peringatan itu sendiri, maka tidak akan sulit bagi penyerang untuk mengirim cookie ke server yang dikendalikan olehnya dan, dalam kasus terburuk, merebut akun Anda. Mari kita lihat tampilannya lagi:
Ada juga lebih banyak vektor serangan pada klien. Saya akan memberikan beberapa contoh dengan deskripsi singkat. Tetapi pertama-tama Anda perlu memahami bagaimana keluar dari konteks:
- Di luar konteks. 6 karakter ini akan membantu untuk keluar tidak hanya dari konteks nilai parameter HTML, tetapi juga dari banyak lainnya:
-> '">
Sebenarnya, dua vektor serangan paling sederhana:
- Sisipkan tautan khususnya. Tetapi dalam kasus umum - mengubah tampilan halaman. Misalnya, mereka dapat menyematkan kode html di halaman Anda dan menampilkan beberapa jendela palsu yang meminta data:
String " aaaa " menunjuk ke google.com . Anda dapat melihat bahwa tautan diberikan pada halaman, tetapi Anda mungkin tidak melihatnya, tetapi ini tidak membatalkan keberadaannya dalam kode. Dalam kedua kasus tersebut, kasing dapat dianggap selesai; - Eksekusi skrip, misalnya, mencegat cookie pengguna:
Di mana dan bagaimana mencari XSS?
Pertama, temukan fungsi informasi / data output pada halaman. Analisis data apa yang ada di sana? Di sinilah konsep
sumber yang tidak dipercaya . Dan semacamnya, pertama-tama, adalah
pengguna Anda . Vektor serangan dapat dimuat dalam sumber lain: umpan RSS, layanan lain, baik eksternal maupun internal.
Inilah contoh kehidupan nyata: Saya bekerja untuk SEMrush IT. Kami sedang mengembangkan platform online, yang merupakan alat universal untuk pemasar online. Jadi, satu layanan menyimpan data untuk kami, yang lain menyimpulkan, masing-masing tim mengandalkan satu sama lain, ternyata pada layanan kedua
XSS muncul karena kurangnya pemrosesan data output yang tepat, dan perintah pertama tidak menganggap perlu untuk menyaring data apa yang masuk. dengan cara apa pun dan menjaga mereka "
apa adanya ". Kesimpulan: jika Anda tidak tahu bagaimana data ini atau itu disimpan, mereka harus dianggap tidak dipercaya. Atau setuju sebelumnya tentang siapa yang menyimpan dan bagaimana, menyaring, menampilkan data.
Jika Anda sudah memiliki data dari sumber yang tidak terpercaya, maka saya sarankan:
- Untuk mempelajari pemfilteran data yang masuk;
- Periksa konteks output. Tidak dalam semua kasus XSS dapat dieksekusi, bahkan jika tidak ada penyaringan. Misalnya, jika tipe konten dari respons adalah: teks / polos;
- Jangan mengandalkan penyaringan kerangka kerja sistem keamanan tertanam.
Injeksi SQL
Implementasi kode-SQL (injeksi SQL bahasa Inggris) - pengantar ke database permintaan instruksi yang tidak tersirat di sana.
Contoh (bukan dari kehidupan, tetapi juga baik):
Kami melihat skrip yang menampilkan tabel pengguna. Dalam hal ini, ia dapat mencari berdasarkan nama pengguna.
Di sebelah kanan diperlihatkan bagaimana kueri ke database terlihat, dan di sebelah kiri adalah hasil dari skrip di browser.
Selanjutnya, untuk menguji dan mendapatkan setidaknya beberapa hasil utama, kami menyisipkan dua kutipan dalam nilai parameter nama. Tunggal dan ganda:
Kami melihat bahwa dari sudut pandang output, semuanya berantakan, tabel menghilang sepenuhnya. Permintaan juga mendapat 2 tanda kutip tambahan. Seluruh sintaks kueri
SQL dilanggar.
Jika kita mengambil dan menambahkan konstruksi seperti itu ke nilai parameter (
ed .: Lihat di kotak kuning ), kita mendapatkan permintaan yang benar-benar valid. Output halaman benar-benar identik dengan permintaan pertama, yang tidak termasuk injeksi:
Untuk memverifikasi sepenuhnya bahwa ada kerentanan, kami menambahkan deuce sebagai ganti kesatuan:
Ternyata permintaan itu menjadi salah, dari sudut pandang logika Boolean dan, sebagai hasilnya, tidak mengandung data. Namun, tidak seperti saat ketika kami memiliki kesalahan, kami memiliki output dari tabel itu sendiri.
Agar tidak mencantumkan semua yang mungkin ada di mesin basis data yang berbeda dan pertanyaan dari jenis yang berbeda, saya telah mengurangi semuanya menjadi satu baris:
Ini adalah sesuatu yang dapat Anda coba masukkan ke dalam parameter, dan kemudian, sesuai dengan perbedaan dalam jawaban, cobalah untuk memahami apa yang terjadi, apakah ada kerentanan atau tidak. Sekitar 80% kasus yang dapat Anda tutupi dengan manipulasi ini.
Masih ada 20% dari situasi sulit di mana ia tidak akan memberi Anda informasi apa pun, misalnya: kueri / pemfilteran bersarang dan sebagainya. Dalam latihan saya, saya bertemu dengan yang sama hanya sekali. Kemudian saya harus melewati pemfilteran di sisi layanan.
Apa bahayanya dalam SQL?
- Dari yang jelas - kebocoran informasi . Jika seorang penyerang dapat membuat query ke database Anda, ia dapat dengan satu atau lain cara mendapatkan nilai yang tidak seharusnya berupa output (hash kata sandi, alamat klien, dll.);
- Perubahan data . Sekarang banyak pengembang menggunakan database melalui sistem ORM . Sistem ini sendiri, secara default, memungkinkan Anda untuk membuat beberapa kueri sekaligus, sintaks SQL juga memungkinkan Anda untuk melakukan ini. Jika ada kerentanan, semuanya dapat berubah tidak hanya untuk pemilihan data, tetapi juga untuk perubahannya (hingga menghapus tabel, mengubah struktur database, dll.).
Dalam situasi yang sama, peningkatan hak pengguna mungkin terjadi. Ubah bidang dalam tabel tertentu (misalnya, masukkan is_admins = true dalam basis data pengguna ) dan dengan demikian meningkatkan hak Anda kepada administrator; - DoS . Dalam beberapa kasus, suntikan dapat menyebabkan penolakan layanan. Beberapa pertanyaan berat ke basis data dihasilkan, diluncurkan dalam beberapa utas, dan layanan Anda mungkin berhenti bekerja untuk beberapa waktu;
- Membaca file sistem adalah bencana lain yang dapat dibawa injeksi SQL. Terjadinya risiko ini tergantung pada sistem basis data yang Anda gunakan, serta di mana pengguna bekerja dengannya (diistimewakan atau tidak);
- RCE (Remote Code Execution) adalah eksekusi kode. Ini secara langsung tergantung pada jenis database yang digunakan (sebelumnya ini dimungkinkan secara default, dengan pengaturan database default, dalam MSSQL).
Tabel di bawah ini menunjukkan kerentanan dalam kueri
SQL . Tentu saja, Anda tidak perlu mengingatnya. Selain itu, ini tidak semua opsi yang mungkin, tetapi hanya contoh. Hanya memperhatikan fakta bahwa tempat-tempat injeksi ke query
SQL dapat terjadi jika data mentah tiba di sana disorot dengan warna merah. Penyerang yang berpengalaman dapat menemukan cara untuk mengeksploitasi ini. Berhati-hatilah dan penuh perhatian.
SSRF (Pemalsuan Permintaan Sisi Server)
Terjemahan literal - permintaan palsu di sisi server. Itu adalah serangan yang memungkinkan Anda untuk memanipulasi data yang Anda kirim ke aplikasi, memaksa Anda untuk membuat permintaan untuk tidak ke tempat logika bisnis awalnya direncanakan.
Pengoperasian
SSRF ditunjukkan pada gambar di bawah ini:
Ada penyerang, ada server Anda, yang ditutup oleh
Firewall , tetapi pada saat yang sama ada fungsi yang memungkinkan Anda untuk membuat permintaan atas nama server lebih lanjut.
Jika fungsi ini tidak dilindungi dengan benar dan / atau salah, seperti biasanya :), memproses data yang masuk, penyerang dapat beralih ke
Memcached ,
Redis atau mendapatkan akses ke sumber daya internal korban.
Untuk contoh yang lebih ilustratif, pertimbangkan pendirian yang digunakan SEMrush untuk pelatihan karyawan internal.
Penting untuk memperhatikan arti dari "
URL Avatar ":
Di sini kita memperhatikan 2 poin:
- URL Avatar itu sendiri
- dan kemampuan untuk mengunduhnya menggunakan file.
Harap perhatikan bahwa bidang "
URL Avatar " adalah bidang teks untuk input, yang berarti kami dapat memanipulasi nilai ini. Mari kita coba memakai avatar, mungkin, gambar paling terkenal di Internet - Googlebot dari halaman
kesalahan 404 .
Lakukan sekali:
Lakukan dua kali klik "
Simpan ." Kami mendapatkan robot alih-alih foto saya:
Di sini perlu memperhatikan fakta bahwa nilai "
URL avatar " telah berubah, ke beberapa jalur lokal - rupanya, aplikasi meminta gambar, menyimpannya ke server dan mengganti nilai baru.
Kami melanjutkan. Di bidang "
URL avatar ", masukkan
file nilai
: /// etc / passwd . Desain ini memungkinkan Anda untuk mengakses struktur file. Di beberapa perpustakaan yang digunakan untuk bekerja dengan
HTTP , secara default, bekerja dengan struktur file dihidupkan dan menerima data dari server di mana mereka mulai:
Apa yang terjadi setelah mengklik tombol "
Simpan "? ..
Pertama, gambar menjadi "
bat ", dan kedua, path ke file berubah.
Jika kami mencoba meminta gambar ini di browser, mereka tidak akan menunjukkan kepada kami apa-apa (file tersebut "
rusak "). Tapi kami bukan hari pertama dalam keamanan informasi, kami tahu apa yang harus dilakukan :) Dengan manipulasi sederhana, kami mendapatkan konten file di komputer kami:
Dengan demikian, dengan bantuan kerentanan ini, saya, sebagai penyerang, bisa mendapatkan semua kode sumber layanan Anda dan data lain yang tersedia untuk dibaca oleh pengguna yang menjalankan layanan web.
Mari kita lihat bahaya SSRF:
- Pemindaian port. Untuk jaringan eksternal, layanan Anda adalah satu titik masuk dan 2 port (http dan https). Dengan memindai port dari dalam infrastruktur Anda, penyerang dapat mendeteksi port terbuka;
- Abaikan otentikasi berbasis host. Apa gunanya Ada kemungkinan bahwa dalam struktur Anda ada layanan yang tersedia hanya untuk sumber daya tertentu (baca: daftar putih IP). Jadi, jika server Anda yang rentan ada dalam daftar putih, Anda mendapatkan akses ke layanan yang tersedia baginya, dan, sebagai hasilnya, Anda dapat memanipulasi mereka;
- Melanjutkan pengembangan serangan yang disebutkan di atas, Anda dapat terus mengeksploitasi program rentan yang berjalan di intranet atau di server lokal. Cukup sering ada situasi ketika infrastruktur internal, tidak dapat diakses dari luar, tidak dimonitor dengan baik (versi / patch keamanan, dll. Tidak selalu diperbarui). Ini juga dapat menyebabkan serangan dan pencurian data;
- Membaca data lokal. Saya menunjukkannya di atas dengan sebuah contoh. Konfigurasi Anda dapat dibaca dan diakses, token dan kata sandi.
Di mana mencari SSRF?
Ini bukan kerentanan standar. Itu dapat ditemukan di tempat yang berbeda, seringkali di tempat yang paling tidak terduga. Dalam situasi ini, teknik "lihat di sini, tetapi Anda mungkin tidak melihat di sini" tidak berfungsi.
Tanda-tanda kemungkinan
SSRF :
- Webhook . Jika mereka dikonfigurasi dengan buruk, jika Firewall tidak terkonfigurasi dengan benar pada server-server dari mana Webhooks membuat permintaan, kerentanan dapat diperoleh;
- Konversi HTML . Cobalah menyematkan susunan <iframe> , <img> , <base> , <script> atau CSS yang mengarah ke layanan internal;
- Unduh file yang dihapus . Ingat contoh avatar? Ketika pengguna memiliki kesempatan untuk mengunggah data dengan URL ke server, ini memerlukan masalah besar. Coba kirim URL dengan port dan lihat konten apa yang diunggah.
Bagaimana cara mencari SSRF?
XXE (Entitas Eksternal XML)
Saya akan memulai ceritanya, seperti biasa dengan contoh, sehingga lebih jelas:
Dalam layanan SEMrush yang disebutkan di atas ada alat yang berkaitan dengan analisis konten. Pengguna mendorong URL situsnya atau situs pesaing dan sebelum menganalisisnya, layanan mengunduh konten ini. Tonton bagaimana ini terjadi di video:
Untuk mengunduh, layanan mengakses situs yang ditentukan dan perayap mengunduh file
sitemap.xml . Dan ini adalah
XML yang sedang kita bicarakan di blok ini.
Dalam video, kita dapat mengamati bagaimana situs penyerang menambahkan definisi entitas eksternal
XXE ke
sitemap.xml , yang menunjuk ke "
file: /// etc / hosts ". Pada sistem Linux, ini adalah file yang menjelaskan IP mana yang sesuai dengan host jika tidak ada catatan
DNS untuk mereka.
Selanjutnya, penyerang menunjukkan dalam
tag <loc> perluasan variabel ini. Setelah itu, parser
XML , setelah memproses semua
XML di kompartemen, memasukkan nilai yang ada di "
file: /// etc / hosts " ke dalam variabel
lokasi (disorot dengan warna merah di video).
Penyerang memulai peluncuran parser kami, pergi ke log, dan di sini garis muncul, disorot dengan warna putih pada video. Ini adalah isi dari file "
file: /// etc / hosts " yang diperoleh dalam permintaan
GET dalam log server yang dikendalikan olehnya.
Apa selanjutnya Penyerang akan memverifikasi bahwa dia benar. Ini akan mengubah nama file menjadi "
file: /// etc / fstab ", jalankan parser lagi dan dapatkan statistik tentang proses yang sedang berjalan.
Dan akhirnya: "
file: /// etc / hostname ", mulai parser, buka log dan dapatkan
nama host dari mesin yang kita pakai.
Ini adalah bug nyata yang ditemukan oleh orang sungguhan yang tidak terkait dengan perusahaan kami. Saya harus menaburkan abu di kepala saya dan membayar uang :)
Contoh lain dari
XXE :
Misalkan kita memiliki
titik akhir tertentu, itu disebut -
example.com/xxe .
Kami mengirimkan struktur
XML kepadanya → dalam
XML kami mendeklarasikan entitas
→ entitas
merujuk ke file sistem
/ etc / passwd dan membuka lebih jauh di tubuh respons → kita mendapatkan konten file ini sebagai respons.
Perlu dicatat bahwa ini tidak terjadi sesering yang kita inginkan.
Mengapa ini berhasil?
Dokumen
XML adalah format data terstruktur yang, antara lain, memungkinkan Anda untuk menggambarkan tipe data yang mungkin dikandungnya menggunakan tag
DOCTYPE khusus.
Data Type Definition (DTD) - Definisi tipe data di dalam dokumen
XML ini. Ada tiga opsi untuk bagaimana hal ini dapat dilakukan:
- Jika dokumen mendukung DTD . Contoh di bawah ini menunjukkan beberapa XML di mana ada struktur pesanan, ada elemen produk dan elemen hitung (mungkin: nomor persediaan produk dan jumlah item dalam pesanan). Urutan adalah induk untuk dua elemen ini:
- DTD eksternal pada server lokal.
Kami melakukan hal yang sama seperti pada perwujudan pertama, tetapi kami membuat semua definisi dalam file terpisah, yang terletak di server lokal:
- DTD eksternal pada server pihak ketiga:
Jika Anda seorang pembaca yang penuh perhatian, Anda mungkin telah mengkorelasikan fakta bahwa kemampuan untuk membuat permintaan seperti itu pada layanan Anda dan permintaan skema
DTD eksternal adalah kerentanan itu sendiri, yang kita bicarakan di atas, yaitu kerentanan
SSRF .
Kejadian umum: pengembang memperbaiki kerentanan
XXE , tetapi lupa untuk melarang pemrosesan
DTD eksternal dan dapatkan
SSRF . Konsekuensi fatal tidak akan mengikuti dari ini, tetapi Anda tidak boleh melupakannya.
Apa itu Entitas dalam XML?
Entitas dalam
XML . Apa ini Ini adalah kesempatan untuk mendefinisikan nilai-nilai tertentu dan mengarahkannya ke dalam variabel. Entitas memiliki tiga jenis:
Pradefinisi - pradefinisi. Mirip dengan kode
HTML , memungkinkan untuk menggunakan karakter yang merupakan bagian dari sintaks bahasa, sebagai struktur teks. Di sini mereka diberikan sebagai contoh, sehingga Anda mengerti apa itu. Ya, dalam kebanyakan serangan mereka tidak digunakan, tetapi mungkin diperlukan dalam beberapa kasus luar biasa.
Umum dan
Parameter . Ini adalah satu dan sama, hanya sintaks deklarasi mereka yang berubah dan bagaimana mereka dapat dipanggil setelah deklarasi
Di mana mencari XXE ?
Beberapa pilihan:
- Pemrosesan XML dalam manifestasi apa pun:
- Konversi HTML ke format lain;
- Menangani docx , xlsx dan format serupa.
Bagaimana cara mencarinya?
Gambar hanya menunjukkan contoh untuk memulai. Ini bukan kunci universal. Itu perlu dioptimalkan untuk format yang Anda gunakan dalam layanan yang sedang dipelajari.
Hal pertama yang kita lakukan: mendeklarasikan entitas
Z tertentu, yang mengakses host yang dikendalikan oleh host yang menyerang, memperluasnya di dalam tubuh dokumen
XML .
Di sini opsi kedua dimungkinkan - hanya esensi
Parameter . Berbeda dari iklan pertama (tanda
% ). Dan untuk beralih ke esensi ini, isi dokumen tidak lagi diperlukan. Kami dapat mengaksesnya langsung dalam struktur
DOCTYPE dan mengekspos entitas ini:
Skenario ketiga adalah untuk melihat apakah kemampuan untuk meminta
DOCTYPE dari layanan eksternal dihidupkan atau dimatikan:
Selanjutnya, kita melihat output dari server yang dikendalikan oleh kami. Jika kita melihat panggilan ke
URL / periksa dari berbagai alamat
IP , itu berarti bahwa dengan tingkat probabilitas yang tinggi kerentanan telah berlalu, dan kemudian kita hanya perlu mencari cara untuk mendapatkan data yang lebih menarik bagi kita.
Apa bahaya dari
XXE ? Saya akan menulis secara singkat dan poin demi poin:
- Membaca file lokal;
- Akses ke sumber daya lokal;
- Pemindaian Port / Host
- Pembungkus teks biasa . Ini adalah kesempatan untuk mengakses layanan Anda yang beroperasi pada protokol teks biasa;
- Eksekusi Kode Jarak Jauh (tidak sering). Ini mati secara default;
- DoS . Karena fakta bahwa entitas dapat digabungkan, dimungkinkan untuk dengan mudah mendapatkan peningkatan eksponensial dalam jumlah memori yang ditempati oleh parameter ini. Hasilnya adalah serangan tertawa Billion . Dengan kata lain, Anda hanya membebani memori server yang diserang.
Sebagai kesimpulan, saya akan mengatakan bahwa semua ini (artikel, dan pengetahuan apa pun yang Anda peroleh) tidak masuk akal tanpa aplikasi praktis. Karenanya, saya akan bertanya kepada Anda tentang hal yang sepele: pikirkan tentang aplikasi yang Anda tulis / uji kemarin dan coba periksa kerentanannya. Apakah ada formulir input atau pemrosesan
XML ? Apakah aplikasi ini dilindungi? Apakah penyaringan ditambahkan dan
DTD dinonaktifkan?
Buka manual
SQLmap dan cari tahu cara memeriksa aplikasi Anda dengannya. Jika dia tidak menemukan apa-apa, ambil alat lain dan memeriksanya, lalu uji aplikasi Anda untuk kerentanan lain. Seperti yang saya katakan di awal, artikel ini hanya meneliti beberapa kerentanan, tetapi
ribuan .
Saya tidak percaya bahwa Anda dapat menulis kode yang benar-benar aman. Selalu ada kerentanan, Anda
belum menemukannya .