Dosa mematikan keamanan situs: apa yang kami pelajari dari statistik pemindai kerentanan untuk tahun ini

Sekitar setahun yang lalu, kami di DataLine meluncurkannya layanan untuk mencari dan menganalisis kerentanan dalam aplikasi TI. Layanan ini didasarkan pada solusi cloud Qualys, yang pengoperasiannya kami sudah memberi tahu. Selama satu tahun bekerja dengan solusi ini, kami melakukan 291 pemindaian untuk berbagai situs dan mengumpulkan statistik tentang kerentanan umum dalam aplikasi web. 

Pada artikel di bawah ini saya akan menunjukkan dengan tepat lubang keamanan situs web apa yang tersembunyi di balik berbagai tingkat kekritisan. Mari kita lihat kerentanan apa yang sering ditemukan pemindai, mengapa hal itu bisa terjadi, dan bagaimana melindungi diri Anda sendiri. 

Dosa mematikan keamanan situs: apa yang kami pelajari dari statistik pemindai kerentanan untuk tahun ini

Qualys membagi semua kerentanan aplikasi web menjadi tiga tingkat kekritisan: rendah, sedang, dan tinggi. Jika Anda melihat distribusi berdasarkan “keparahan”, tampaknya semuanya tidak terlalu buruk. Ada beberapa kerentanan dengan tingkat kekritisan tinggi, sebagian besar tidak kritis: 

Dosa mematikan keamanan situs: apa yang kami pelajari dari statistik pemindai kerentanan untuk tahun ini

Namun tidak kritis bukan berarti tidak berbahaya. Bahan-bahan tersebut juga dapat menyebabkan kerusakan serius. 

Kerentanan “tidak kritis” teratas

  1. Kerentanan konten campuran.

    Standar keamanan situs web adalah transfer data antara klien dan server melalui protokol HTTPS, yang mendukung enkripsi dan melindungi informasi dari intersepsi. 

    Beberapa situs menggunakan konten campuran: Beberapa data ditransfer melalui protokol HTTP yang tidak aman. Ini adalah cara yang paling sering disampaikan konten pasif – informasi yang hanya mempengaruhi tampilan situs: gambar, gaya css. Namun terkadang hal ini ditularkan dengan cara seperti ini konten aktif: skrip yang mengontrol perilaku situs. Dalam hal ini, dengan menggunakan perangkat lunak khusus, Anda dapat menganalisis informasi dengan konten aktif yang berasal dari server, mengubah respons Anda dengan cepat, dan membuat mesin bekerja dengan cara yang tidak dimaksudkan oleh pembuatnya. 

    Versi browser yang lebih baru memperingatkan pengguna bahwa situs dengan konten campuran tidak aman dan memblokir konten tersebut. Pengembang situs web juga menerima peringatan browser di konsol. Misalnya saja seperti ini tampilannya Firefox

    Dosa mematikan keamanan situs: apa yang kami pelajari dari statistik pemindai kerentanan untuk tahun ini

    Apa itu berbahaya?: Penyerang menggunakan protokol tidak aman untuk mencegat informasi pengguna, mengganti skrip, dan mengirim permintaan ke situs atas namanya. Sekalipun pengunjung situs tidak memasukkan data, hal ini tidak melindunginya pengelabuan – memperoleh informasi rahasia menggunakan metode penipuan. Misalnya, dengan menggunakan skrip, Anda dapat mengarahkan pengguna ke situs tidak aman yang menyamar sebagai situs yang familier bagi pengguna. Dalam beberapa kasus, situs jahat terlihat lebih bagus daripada aslinya, dan pengguna dapat mengisi formulir sendiri dan mengirimkan data rahasia. 

    Apa yang harus diingat oleh pengembang web: Meskipun administrator situs telah menginstal dan mengonfigurasi sertifikat SSL/TLS, kerentanan mungkin timbul karena kesalahan manusia. Misalnya, jika di salah satu halaman Anda tidak memasang tautan relatif, tetapi tautan absolut dari http, dan selain itu Anda tidak mengatur pengalihan dari http ke https. 

    Anda dapat mendeteksi konten campuran di situs menggunakan browser: cari kode sumber halaman, baca notifikasi di konsol pengembang. Namun, pengembang harus mengutak-atik kode tersebut untuk waktu yang lama dan membosankan. Anda dapat mempercepat proses dengan alat analisis otomatis, misalnya: periksa SSL, software Lighthouse gratis atau software berbayar Screaming Frog SEO Spider.

    Selain itu, kerentanan mungkin timbul karena masalah dengan kode lama – kode yang diwariskan. Misalnya, jika beberapa halaman dibuat menggunakan template lama yang tidak memperhitungkan transisi situs ke https.    

  2. Cookie tanpa tanda "HTTPOnly" dan "secure".

    Atribut "HTTPOnly" melindungi cookie agar tidak diproses oleh skrip yang digunakan penyerang untuk mencuri data pengguna. Tanda "aman" tidak mengizinkan cookie dikirim dalam bentuk teks biasa. Komunikasi hanya akan diperbolehkan jika protokol HTTPS aman digunakan untuk mengirim cookie. 

    Kedua atribut tersebut ditentukan dalam properti cookie:

    Set-Cookie: Secure; HttpOnly

    Apa itu berbahaya?: Jika pengembang situs tidak menentukan atribut ini, penyerang dapat mencegat informasi pengguna dari cookie dan mengeksploitasinya. Jika cookie digunakan untuk otentikasi dan otorisasi, ia akan dapat membajak sesi pengguna dan melakukan tindakan di situs atas namanya. 

    Apa yang harus diingat oleh pengembang web: Biasanya, dalam kerangka populer, atribut ini disetel secara otomatis. Tapi tetap periksa konfigurasi server web dan atur flagnya: Set-Cookie HttpOnly; Aman.

    Dalam hal ini, atribut “HTTPOnly” akan membuat cookie tidak terlihat oleh JavaScript Anda.  

  3. Kerentanan Berbasis Jalur.

    Pemindai melaporkan kerentanan tersebut jika menemukan file atau direktori situs web yang dapat diakses publik dengan informasi yang mungkin bersifat rahasia. Misalnya, mendeteksi file konfigurasi sistem individual atau akses ke seluruh sistem file. Situasi ini mungkin terjadi jika hak akses tidak diatur dengan benar di situs.

    Apa itu berbahaya?: Jika sistem file “menonjol”, penyerang dapat masuk ke antarmuka sistem operasi dan mencoba menemukan folder dengan kata sandi jika disimpan dalam teks biasa (jangan lakukan itu!). Atau Anda dapat mencuri hash kata sandi dan memaksa kata sandi secara kasar, dan juga mencoba meningkatkan hak istimewa dalam sistem dan masuk lebih dalam ke infrastruktur.  

    Apa yang harus diingat oleh pengembang web: Jangan lupa tentang hak akses dan konfigurasikan platform, server web, aplikasi web sehingga tidak mungkin untuk “keluar” dari direktori web.

  4. Formulir untuk memasukkan data sensitif dengan pengisian otomatis diaktifkan.

    Jika pengguna sering mengisi formulir di situs web, browser mereka menyimpan informasi ini menggunakan fitur isi otomatis. 

    Formulir di situs web mungkin menyertakan kolom dengan informasi sensitif, seperti kata sandi atau nomor kartu kredit. Untuk bidang seperti itu, sebaiknya nonaktifkan fungsi pengisian otomatis formulir di situs itu sendiri. 

    Apa itu berbahaya?: Jika browser pengguna menyimpan informasi sensitif, penyerang dapat mencegatnya nanti, misalnya melalui phishing. Intinya, seorang pengembang web yang telah melupakan nuansa ini sedang menyiapkan penggunanya. 

    Apa yang harus diingat oleh pengembang web: Dalam hal ini, kita menghadapi konflik klasik: kenyamanan vs keamanan. Jika seorang pengembang web memikirkan pengalaman pengguna, dia dapat secara sadar memilih pelengkapan otomatis. Misalnya saja kalau itu penting untuk diikuti Pedoman Aksesibilitas Konten Web – rekomendasi aksesibilitas konten bagi pengguna penyandang disabilitas. 

    Untuk sebagian besar browser, Anda dapat menonaktifkan pelengkapan otomatis dengan atribut autocompete="off", misalnya:

     <body>
        <form action="/id/form/submit" method="get" autocomplete="off">
          <div>
            <input type="text" placeholder="First Name">
          </div>
          <div>
            <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
          </div>
          <div>
            <input type="number" placeholder="Credit card number">
          </div>
          <input type="submit">
        </form>
      </body>

    Tapi itu tidak akan berfungsi untuk Chrome. Ini diatasi dengan menggunakan JavaScript, varian resepnya dapat ditemukan di sini

  5. Header X-Frame-Options tidak disetel dalam kode situs. 

    Header ini memengaruhi tag bingkai, iframe, semat, atau objek. Dengan bantuannya, Anda dapat sepenuhnya melarang penyematan situs Anda di dalam bingkai. Untuk melakukan ini, Anda perlu menentukan nilai X-Frame-Options: reject. Atau Anda dapat menentukan X-Frame-Options: sameorigin, lalu penyematan di iframe hanya akan tersedia di domain Anda.

    Apa itu berbahaya?: Tidak adanya header seperti itu dapat digunakan pada situs jahat untuk pembajakan klik. Untuk serangan ini, penyerang membuat bingkai transparan di atas tombol dan menipu pengguna. Misalnya: penipu membingkai halaman jejaring sosial di sebuah situs web. Pengguna mengira dia sedang mengklik tombol di situs ini. Sebaliknya, klik dicegat dan permintaan pengguna dikirim ke jejaring sosial tempat ada sesi aktif. Beginilah cara penyerang mengirim spam atas nama pengguna atau mendapatkan pelanggan dan suka. 

    Jika Anda tidak menonaktifkan fitur ini, penyerang dapat menempatkan tombol aplikasi Anda di situs jahat. Dia mungkin tertarik dengan program rujukan Anda atau pengguna Anda.  

    Apa yang harus diingat oleh pengembang web: Kerentanan dapat terjadi jika X-Frame-Options dengan nilai yang bertentangan diatur di server web atau penyeimbang beban. Dalam hal ini, server dan penyeimbang hanya akan menulis ulang header, karena mereka memiliki prioritas lebih tinggi dibandingkan dengan kode backend.  

    Nilai penolakan dan asal yang sama dari header X-Frame-Options akan mengganggu pengoperasian penampil web Yandex. Untuk mengizinkan penggunaan iframe untuk penampil web, Anda perlu menulis aturan terpisah di pengaturan. Misalnya untuk nginx Anda dapat mengkonfigurasinya seperti ini:

    http{
    ...
     map $http_referer $frame_options {
     "~webvisor.com" "ALLOW-FROM http://webvisor.com";
     default "SAMEORIGIN";
     }
     add_header X-Frame-Options $frame_options;
    ...
    }
    
    

  6. Kerentanan PRSSI (Impor stylesheet jalur-relatif).  

    Ini adalah kerentanan dalam gaya situs. Ini terjadi jika tautan relatif seperti href="/id/somefolder/styles.css/" digunakan untuk mengakses file gaya. Penyerang akan memanfaatkan hal ini jika mereka menemukan cara untuk mengarahkan pengguna ke halaman berbahaya. Halaman tersebut akan memasukkan tautan relatif ke dalam urlnya dan mensimulasikan panggilan gaya. Anda akan mendapatkan permintaan seperti badsite.ru/…/somefolder/styles.css/, yang dapat melakukan tindakan jahat dengan menyamar sebagai gaya. 

    Apa itu berbahaya?: Penipu dapat mengeksploitasi kerentanan ini jika mereka menemukan celah keamanan lain. Akibatnya, data pengguna dapat dicuri dari cookie atau token.

    Apa yang harus diingat oleh pengembang web: Setel tajuk X-Content-Type-Options ke: nosniff. Dalam hal ini, browser akan memeriksa tipe konten untuk gayanya. Jika tipenya selain text/css, browser akan memblokir permintaan tersebut.

Kerentanan kritis

  1. Halaman dengan kolom kata sandi dikirimkan dari server melalui saluran tidak aman (formulir HTML yang berisi kolom kata sandi disajikan melalui HTTP).

    Respons dari server melalui saluran yang tidak terenkripsi rentan terhadap serangan “Man in the middle”. Penyerang dapat mencegat lalu lintas dan terjepit di antara klien dan server saat halaman berpindah dari server ke klien. 

    Apa itu berbahaya?: Penipu akan dapat mengganti halaman dan mengirimkan formulir data rahasia kepada pengguna, yang akan masuk ke server penyerang. 

    Apa yang harus diingat oleh pengembang web: Beberapa situs mengirimkan kode satu kali kepada pengguna melalui email/telepon, bukan kata sandi. Dalam hal ini, kerentanannya tidak begitu kritis, namun mekanismenya akan mempersulit kehidupan pengguna.

  2. Mengirim formulir dengan login dan kata sandi melalui saluran tidak aman (Formulir Login Tidak Dikirim Melalui HTTPS).

    Dalam hal ini, formulir dengan login dan kata sandi dikirim dari pengguna ke server melalui saluran tidak terenkripsi.

    Apa itu berbahaya?: Berbeda dengan kasus sebelumnya, kasus ini sudah menjadi kerentanan kritis. Lebih mudah untuk mencegat data sensitif karena Anda bahkan tidak perlu menulis kode untuk melakukannya. 

  3. Menggunakan perpustakaan JavaScript dengan kerentanan yang diketahui.

    Selama pemindaian, perpustakaan yang paling banyak digunakan adalah jQuery dengan sejumlah versi yang banyak. Setiap versi memiliki setidaknya satu, atau bahkan lebih, kerentanan yang diketahui. Dampaknya bisa sangat berbeda tergantung pada sifat kerentanannya.

    Apa itu berbahaya?: Ada eksploitasi untuk kerentanan yang diketahui, misalnya:

    Dosa mematikan keamanan situs: apa yang kami pelajari dari statistik pemindai kerentanan untuk tahun ini

    Apa yang harus diingat oleh pengembang web: Kembali ke siklus secara teratur: cari kerentanan yang diketahui - perbaiki - periksa. Jika Anda sengaja menggunakan perpustakaan lama, misalnya untuk mendukung browser lama atau untuk menghemat uang, carilah peluang untuk memperbaiki kerentanan yang diketahui. 

  4. Skrip lintas situs (XSS). 
    Cross-Site Scripting (XSS), atau skrip lintas situs, adalah serangan terhadap aplikasi web yang mengakibatkan masuknya malware ke dalam database. Jika Qualys menemukan kerentanan seperti itu, itu berarti calon penyerang dapat atau telah memasukkan skrip js miliknya ke dalam kode situs untuk melakukan tindakan jahat.

    XSS yang disimpan lebih berbahaya karena skrip tertanam di server dan dieksekusi setiap kali halaman yang diserang dibuka di browser.

    XSS yang dipantulkan lebih mudah dilakukan karena skrip berbahaya dapat dimasukkan ke dalam permintaan HTTP. Aplikasi akan menerima permintaan HTTP, tidak akan memvalidasi data, akan mengemasnya, dan segera mengirimkannya. Jika penyerang mencegat lalu lintas dan memasukkan skrip seperti

    <script>/*+что+то+плохое+*/</script> 

    maka permintaan jahat akan dikirim atas nama klien.

    Contoh mencolok dari XSS: js sniffer yang mensimulasikan halaman untuk memasukkan CVC, tanggal kedaluwarsa kartu, dan sebagainya. 

    Apa yang harus diingat oleh pengembang web: Di header Content-Security-Policy, gunakan atribut script-src untuk memaksa browser klien hanya mengunduh dan mengeksekusi kode dari sumber tepercaya. Misalnya, script-src 'self' memasukkan semua skrip dari situs kami ke daftar putih saja. 
    Praktik terbaiknya adalah kode Inline: hanya izinkan javascript inline menggunakan nilai inline yang tidak aman. Nilai ini mengizinkan penggunaan js/css sebaris, tetapi tidak melarang penyertaan file js. Dalam kombinasi dengan script-src 'self' kami menonaktifkan eksekusi skrip eksternal.

    Pastikan untuk mencatat semuanya menggunakan report-uri dan lihat upaya untuk menerapkannya ke dalam situs.

  5. Suntikan SQL.
    Kerentanan tersebut menunjukkan kemungkinan menyuntikkan kode SQL ke situs web yang mengakses database situs web secara langsung. Injeksi SQL dimungkinkan jika data dari pengguna tidak disaring: data tersebut tidak diperiksa kebenarannya dan segera digunakan dalam kueri. Misalnya, hal ini terjadi jika formulir di situs web tidak memeriksa apakah input cocok dengan tipe data. 

    Apa itu berbahaya?: Jika penyerang memasukkan kueri SQL ke dalam formulir ini, dia dapat membuat database crash atau mengungkapkan informasi rahasia. 

    Apa yang harus diingat oleh pengembang web: Jangan percaya apa yang datang dari browser. Anda perlu melindungi diri Anda sendiri di sisi klien dan sisi server. 

    Di sisi klien, tulis validasi bidang menggunakan JavaScript. 

    Fungsi bawaan dalam kerangka kerja populer juga membantu menghindari karakter mencurigakan di server. Disarankan juga untuk menggunakan kueri basis data berparameter di server.

    Tentukan di mana tepatnya interaksi dengan database terjadi pada aplikasi web. 

    Interaksi terjadi ketika kami menerima informasi apa pun: permintaan dengan id (perubahan id), pembuatan pengguna baru, komentar baru, atau entri baru dalam database. Di sinilah injeksi SQL dapat terjadi. Bahkan jika kita menghapus catatan dari database, injeksi SQL masih dimungkinkan.

Rekomendasi umum

Jangan menemukan kembali roda - gunakan kerangka kerja yang sudah terbukti. Biasanya, kerangka kerja populer lebih aman. Untuk .NET - ASP.NET MVC dan ASP.NET Core, untuk Python - Django atau Flask, untuk Ruby - Ruby on Rails, untuk PHP - Symfony, Laravel, Yii, untuk JavaScript - Node.JS-Express.js, untuk Java - MVC musim semi.

Ikuti pembaruan vendor dan perbarui secara berkala. Mereka akan menemukan kerentanannya, lalu menulis eksploitasinya, mempublikasikannya, dan semuanya akan terulang kembali. Berlangganan pembaruan ke versi stabil dari vendor perangkat lunak.

Periksa hak akses. Di sisi server, selalu perlakukan kode Anda seolah-olah, dari huruf pertama hingga terakhir, ditulis oleh musuh yang paling Anda benci, yang ingin merusak situs Anda, melanggar integritas data Anda. Terlebih lagi, terkadang hal ini benar.

Gunakan klon, uji situs, lalu gunakan untuk produksi. Hal ini akan membantu, pertama, untuk menghindari kesalahan dan kekeliruan dalam lingkungan produktif: lingkungan produktif menghasilkan uang, lingkungan produktif sederhana sangatlah penting. Saat menambahkan, memperbaiki, atau menutup masalah apa pun, ada baiknya bekerja di lingkungan pengujian, kemudian memeriksa fungsionalitas dan kerentanan yang ditemukan, dan kemudian merencanakan untuk bekerja dengan lingkungan produksi. 

Lindungi aplikasi web Anda dengan Firewall Aplikasi Web dan mengintegrasikan laporan dari pemindai kerentanan dengannya. Misalnya, DataLine menggunakan Qualys dan FortiWeb sebagai kumpulan layanan.

Sumber: www.habr.com

Tambah komentar