Dosa maut keselamatan laman web: perkara yang kami pelajari daripada statistik pengimbas kerentanan untuk tahun ini

Kira-kira setahun yang lalu, kami di DataLine melancarkan perkhidmatan untuk mencari dan menganalisis kelemahan dalam aplikasi IT. Perkhidmatan ini berdasarkan penyelesaian awan Qualys, mengenai operasinya kami sudah beritahu. Sepanjang setahun bekerja dengan penyelesaian itu, kami menjalankan 291 imbasan untuk tapak yang berbeza dan statistik terkumpul tentang kelemahan biasa dalam aplikasi web. 

Dalam artikel di bawah saya akan menunjukkan kepada anda dengan tepat apa lubang dalam keselamatan laman web yang tersembunyi di sebalik tahap kritikal yang berbeza. Mari lihat apakah kelemahan yang sering ditemui oleh pengimbas, sebab ia mungkin berlaku, dan cara melindungi diri anda. 

Qualys membahagikan semua kelemahan aplikasi web kepada tiga tahap kritikal: rendah, sederhana dan tinggi. Jika anda melihat pengedaran mengikut "keterukan", nampaknya semuanya tidak begitu buruk. Terdapat sedikit kelemahan dengan tahap kritikal yang tinggi, kebanyakannya semuanya tidak kritikal: 

Tetapi tidak kritis tidak bermakna tidak berbahaya. Mereka juga boleh menyebabkan kerosakan yang serius. 

Kelemahan "tidak kritikal" teratas

1. Kerentanan kandungan campuran.

   Piawaian untuk keselamatan laman web ialah pemindahan data antara klien dan pelayan melalui protokol HTTPS, yang menyokong penyulitan dan melindungi maklumat daripada pemintasan. 

   Sesetengah tapak menggunakan kandungan bercampur: Sesetengah data dipindahkan melalui protokol HTTP yang tidak selamat. Ini adalah cara ia paling kerap disampaikan kandungan pasif – maklumat yang hanya mempengaruhi paparan tapak: gambar, gaya css. Tetapi kadang-kadang ini adalah bagaimana ia dihantar kandungan aktif: skrip yang mengawal tingkah laku tapak. Dalam kes ini, menggunakan perisian khas, anda boleh menganalisis maklumat dengan kandungan aktif yang datang dari pelayan, mengubah suai respons anda dengan cepat dan membuat mesin berfungsi dengan cara yang tidak dimaksudkan oleh penciptanya. 

   Versi penyemak imbas yang lebih baharu memberi amaran kepada pengguna bahawa tapak dengan kandungan bercampur adalah tidak selamat dan menyekat kandungan tersebut. Pembangun laman web juga menerima amaran penyemak imbas dalam konsol. Sebagai contoh, ini adalah bagaimana ia kelihatan dalam Firefox: 

   
   
   Apa yang bahaya: Penyerang menggunakan protokol tidak selamat untuk memintas maklumat pengguna, menggantikan skrip dan menghantar permintaan ke tapak bagi pihaknya. Walaupun pelawat tapak tidak memasukkan data, ini tidak melindunginya daripadanya pancingan data – mendapatkan maklumat sulit menggunakan kaedah penipuan. Contohnya, menggunakan skrip, anda boleh mengubah hala pengguna ke tapak yang tidak selamat yang menyamar sebagai laman biasa kepada pengguna. Dalam sesetengah kes, tapak berniat jahat kelihatan lebih baik daripada yang asal, dan pengguna boleh mengisi borang itu sendiri dan menyerahkan data sulit. 

   Perkara yang harus diingat oleh pembangun web: Walaupun pentadbir tapak telah memasang dan mengkonfigurasikan sijil SSL/TLS, kelemahan mungkin timbul disebabkan oleh ralat manusia. Sebagai contoh, jika pada salah satu halaman anda tidak meletakkan pautan relatif, tetapi pautan mutlak dari http, dan sebagai tambahan anda tidak menyediakan ubah hala dari http ke https. 

   Anda boleh mengesan kandungan bercampur pada tapak menggunakan penyemak imbas: cari kod sumber halaman, baca pemberitahuan dalam konsol pembangun. Walau bagaimanapun, pemaju perlu mengutak-atik kod untuk masa yang lama dan membosankan. Anda boleh mempercepatkan proses dengan alat analisis automatik, contohnya: Semak SSL, perisian Lighthouse percuma atau perisian berbayar Screaming Frog SEO Spider.

   Selain itu, kerentanan mungkin timbul disebabkan masalah dengan kod warisan - kod yang diwarisi. Contohnya, jika sesetengah halaman dijana menggunakan templat lama, yang tidak mengambil kira peralihan tapak kepada https.    

2. Kuki tanpa bendera "HTTPonly" dan "secure".

   Atribut "HTTPonly" melindungi kuki daripada diproses oleh skrip yang digunakan oleh penyerang untuk mencuri data pengguna. Bendera "selamat" tidak membenarkan kuki dihantar dalam teks yang jelas. Komunikasi hanya akan dibenarkan jika protokol HTTPS selamat digunakan untuk menghantar kuki. 

   Kedua-dua atribut dinyatakan dalam sifat kuki:

   Set-Cookie: Secure; HttpOnly

   Apa yang bahaya: Jika pembangun tapak tidak menyatakan atribut ini, penyerang boleh memintas maklumat pengguna daripada kuki dan mengeksploitasinya. Jika kuki digunakan untuk pengesahan dan kebenaran, dia akan dapat merampas sesi pengguna dan melakukan tindakan di tapak bagi pihaknya. 

   Perkara yang harus diingat oleh pembangun web: Sebagai peraturan, dalam rangka kerja popular atribut ini ditetapkan secara automatik. Tetapi masih semak konfigurasi pelayan web dan tetapkan bendera: Set-Cookie HttpOnly; selamat.

   Dalam kes ini, atribut "HTTPonly" akan menjadikan kuki tidak kelihatan kepada JavaScript anda sendiri.  

3. Kerentanan Berasaskan Laluan.

   Pengimbas melaporkan kerentanan sedemikian jika ia menjumpai fail atau direktori tapak web yang boleh diakses secara umum dengan maklumat yang berpotensi sulit. Sebagai contoh, ia mengesan fail konfigurasi sistem individu atau akses kepada keseluruhan sistem fail. Keadaan ini mungkin berlaku jika hak akses ditetapkan secara tidak betul pada tapak.

   Apa yang bahaya: Jika sistem fail "terlekat", penyerang boleh jatuh ke dalam antara muka sistem pengendalian dan cuba mencari folder dengan kata laluan jika ia disimpan dalam teks yang jelas (jangan lakukan itu!). Atau anda boleh mencuri cincang kata laluan dan memaksa kata laluan secara kasar, dan juga cuba meningkatkan keistimewaan dalam sistem dan bergerak lebih dalam ke dalam infrastruktur.  

   Perkara yang harus diingat oleh pembangun web: Jangan lupa tentang hak akses dan konfigurasikan platform, pelayan web, aplikasi web supaya mustahil untuk "melarikan diri" daripada direktori web.

4. Borang untuk memasukkan data sensitif dengan autoisi didayakan.

   Jika pengguna kerap mengisi borang di tapak web, penyemak imbas mereka menyimpan maklumat ini menggunakan ciri autolengkap. 

   Borang di tapak web mungkin termasuk medan dengan maklumat sensitif, seperti kata laluan atau nombor kad kredit. Untuk medan sebegitu, fungsi autoisi borang pada tapak itu patut dilumpuhkan. 

   Apa yang bahaya: Jika penyemak imbas pengguna menyimpan maklumat sensitif, penyerang boleh memintasnya kemudian, contohnya melalui pancingan data. Pada dasarnya, pembangun web yang telah melupakan nuansa ini sedang menyediakan penggunanya. 

   Perkara yang harus diingat oleh pembangun web: Dalam kes ini, kita mempunyai konflik klasik: kemudahan vs keselamatan. Jika pembangun web memikirkan tentang pengalaman pengguna, dia boleh memilih autolengkap secara sedar. Sebagai contoh, jika penting untuk diikuti Garis Panduan Kebolehcapaian Kandungan Web – cadangan untuk kebolehcapaian kandungan untuk pengguna kurang upaya. 

   Untuk kebanyakan penyemak imbas, anda boleh melumpuhkan autolengkap dengan atribut autocompete="off", contohnya:

    <body>
       <form action="/ms/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>

   Tetapi ia tidak akan berfungsi untuk Chrome. Ini dielakkan menggunakan JavaScript, varian resipi boleh didapati di sini. 

5. Pengepala X-Frame-Options tidak ditetapkan dalam kod tapak. 

   Pengepala ini mempengaruhi teg bingkai, iframe, benam atau objek. Dengan bantuannya, anda boleh melarang sepenuhnya membenamkan tapak anda di dalam bingkai. Untuk melakukan ini, anda perlu menentukan nilai X-Frame-Options: deny. Atau anda boleh menentukan X-Frame-Options: sameorigin, kemudian membenamkan dalam iframe hanya akan tersedia pada domain anda.

   Apa yang bahaya: Ketiadaan pengepala sedemikian boleh digunakan pada tapak berniat jahat untuk clickjacking. Untuk serangan ini, penyerang mencipta bingkai lutsinar di atas butang dan menipu pengguna. Contohnya: penipu membingkai halaman rangkaian sosial di tapak web. Pengguna fikir dia sedang mengklik butang di tapak ini. Sebaliknya, klik dipintas dan permintaan pengguna dihantar ke rangkaian sosial di mana terdapat sesi aktif. Beginilah cara penyerang menghantar spam bagi pihak pengguna atau mendapatkan pelanggan dan suka. 

   Jika anda tidak melumpuhkan ciri ini, penyerang boleh meletakkan butang aplikasi anda pada tapak berniat jahat. Dia mungkin berminat dengan program rujukan anda atau pengguna anda.  

   Perkara yang harus diingat oleh pembangun web: Kerentanan mungkin berlaku jika X-Frame-Options dengan nilai bercanggah ditetapkan pada pelayan web atau pengimbang beban. Dalam kes ini, pelayan dan pengimbang hanya akan menulis semula pengepala, kerana mereka mempunyai keutamaan yang lebih tinggi berbanding dengan kod bahagian belakang.  

   Penafian dan nilai asal yang sama bagi pengepala X-Frame-Options akan mengganggu operasi pemapar web Yandex. Untuk membenarkan penggunaan iframe untuk pemapar web, anda perlu menulis peraturan berasingan dalam tetapan. Sebagai contoh, untuk nginx anda boleh 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. PRSSI (Path-relative stylesheet import) kerentanan.  

   Ini adalah kelemahan dalam penggayaan tapak. Ia berlaku jika pautan relatif seperti href="/ms/somefolder/styles.css/" digunakan untuk mengakses fail gaya. Penyerang akan mengambil kesempatan daripada ini jika mereka mencari cara untuk mengubah hala pengguna ke halaman berniat jahat. Halaman tersebut akan memasukkan pautan relatif ke dalam urlnya dan mensimulasikan panggilan gaya. Anda akan mendapat permintaan seperti badsite.ru/…/somefolder/styles.css/, yang boleh melakukan tindakan berniat jahat di bawah samaran gaya. 

   Apa yang bahaya: Penipu boleh mengeksploitasi kelemahan ini jika mereka menemui lubang keselamatan yang lain. Akibatnya, adalah mungkin untuk mencuri data pengguna daripada kuki atau token.

   Perkara yang harus diingat oleh pembangun web: Tetapkan pengepala X-Content-Type-Options kepada: nosniff. Dalam kes ini, penyemak imbas akan menyemak jenis kandungan untuk gaya. Jika jenisnya selain daripada teks/css, penyemak imbas akan menyekat permintaan tersebut.

Kelemahan kritikal

1. Halaman dengan medan kata laluan dihantar dari pelayan melalui saluran yang tidak selamat (borang HTML yang mengandungi medan kata laluan disampaikan melalui HTTP).

   Respons daripada pelayan melalui saluran yang tidak disulitkan terdedah kepada serangan "Man in the middle". Penyerang boleh memintas lalu lintas dan menjepit dirinya antara klien dan pelayan semasa halaman bergerak dari pelayan ke klien. 

   Apa yang bahaya: Penipu akan dapat menggantikan halaman dan menghantar kepada pengguna borang untuk data sulit, yang akan pergi ke pelayan penyerang. 

   Perkara yang harus diingat oleh pembangun web: Sesetengah tapak menghantar pengguna kod sekali sahaja melalui e-mel/telefon dan bukannya kata laluan. Dalam kes ini, kelemahan tidak begitu kritikal, tetapi mekanisme itu akan merumitkan kehidupan pengguna.

2. Menghantar borang dengan log masuk dan kata laluan melalui saluran yang tidak selamat (Borang Log Masuk Tidak Dihantar Melalui HTTPS).

   Dalam kes ini, borang dengan log masuk dan kata laluan dihantar daripada pengguna ke pelayan melalui saluran yang tidak disulitkan.

   Apa yang bahaya: Tidak seperti kes sebelumnya, ini sudah menjadi kelemahan kritikal. Lebih mudah untuk memintas data sensitif kerana anda tidak perlu menulis kod untuk melakukannya. 

3. Menggunakan perpustakaan JavaScript dengan kelemahan yang diketahui.

   Semasa imbasan, perpustakaan yang paling banyak digunakan ialah jQuery dengan bilangan versi yang banyak. Setiap versi mempunyai sekurang-kurangnya satu, atau lebih, kelemahan yang diketahui. Kesannya boleh sangat berbeza bergantung pada sifat kelemahan.

   Apa yang bahaya: Terdapat eksploitasi untuk kelemahan yang diketahui, contohnya:

   
   
   Perkara yang harus diingat oleh pembangun web: Kembali ke kitaran secara kerap: cari kelemahan yang diketahui - betulkan - semak. Jika anda menggunakan perpustakaan warisan dengan sengaja, contohnya untuk menyokong penyemak imbas lama atau untuk menjimatkan wang, cari peluang untuk membetulkan kelemahan yang diketahui. 

4. Skrip silang tapak (XSS). 
   Skrip Silang Tapak (XSS), atau skrip silang tapak, ialah serangan ke atas aplikasi web yang mengakibatkan perisian hasad diperkenalkan ke dalam pangkalan data. Jika Qualys menjumpai kerentanan sedemikian, ini bermakna bakal penyerang boleh atau telah pun memperkenalkan skrip jsnya sendiri ke dalam kod tapak untuk melakukan tindakan berniat jahat.

   XSS disimpan lebih berbahaya, kerana skrip dibenamkan pada pelayan dan dilaksanakan setiap kali halaman yang diserang dibuka dalam penyemak imbas.

   XSS dicerminkan lebih mudah untuk dijalankan kerana skrip berniat jahat boleh disuntik ke dalam permintaan HTTP. Aplikasi akan menerima permintaan HTTP, tidak akan mengesahkan data, akan membungkusnya dan menghantarnya serta-merta. Jika penyerang memintas lalu lintas dan memasukkan skrip seperti

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

   maka permintaan jahat akan dihantar bagi pihak pelanggan.

   Contoh menarik bagi XSS: js sniffers yang mensimulasikan halaman untuk memasukkan CVC, tarikh tamat tempoh kad dan sebagainya. 

   Perkara yang harus diingat oleh pembangun web: Dalam pengepala Content-Security-Policy, gunakan atribut script-src untuk memaksa penyemak imbas klien hanya memuat turun dan melaksanakan kod daripada sumber yang dipercayai. Contohnya, script-src 'self' menyenarai putih semua skrip dari tapak kami sahaja. 
   Amalan terbaik ialah kod Sebaris: hanya benarkan javaskrip sebaris menggunakan nilai sebaris tidak selamat. Nilai ini membenarkan penggunaan js/css sebaris, tetapi tidak melarang kemasukan fail js. Dalam kombinasi dengan skrip-src 'diri' kami melumpuhkan skrip luaran daripada dilaksanakan.

   Pastikan anda log semua menggunakan report-uri dan lihat percubaan untuk melaksanakannya ke dalam tapak.

5. Suntikan SQL.
   Kerentanan menunjukkan kemungkinan menyuntik kod SQL ke dalam laman web yang mengakses pangkalan data tapak web secara langsung. Suntikan SQL boleh dilakukan jika data daripada pengguna tidak disaring: ia tidak disemak untuk ketepatannya dan segera digunakan dalam pertanyaan. Sebagai contoh, ini berlaku jika borang di tapak web tidak menyemak sama ada input sepadan dengan jenis data. 

   Apa yang bahaya: Jika penyerang memasukkan pertanyaan SQL ke dalam borang ini, dia boleh ranap pangkalan data atau mendedahkan maklumat sulit. 

   Perkara yang harus diingat oleh pembangun web: Jangan percaya apa yang datang daripada penyemak imbas. Anda perlu melindungi diri anda di kedua-dua bahagian pelanggan dan bahagian pelayan. 

   Di sisi pelanggan, tulis pengesahan medan menggunakan JavaScript. 

   Fungsi terbina dalam dalam rangka kerja popular juga membantu untuk melepaskan watak yang mencurigakan pada pelayan. Ia juga disyorkan untuk menggunakan pertanyaan pangkalan data berparameter pada pelayan.

   Tentukan di mana tepatnya interaksi dengan pangkalan data berlaku pada aplikasi web. 

   Interaksi berlaku apabila kami menerima sebarang maklumat: permintaan dengan id (perubahan id), penciptaan pengguna baharu, ulasan baharu atau entri baharu dalam pangkalan data. Di sinilah suntikan SQL boleh berlaku. Walaupun kami memadamkan rekod daripada pangkalan data, suntikan SQL adalah mungkin.

Cadangan am

Jangan cipta semula roda - gunakan rangka kerja yang terbukti. Sebagai peraturan, rangka kerja yang popular adalah lebih selamat. 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 bunga.

Ikuti kemas kini vendor dan kemas kini dengan kerap. Mereka akan menemui kelemahan, kemudian menulis eksploitasi, menjadikannya tersedia secara terbuka, dan semuanya akan berlaku lagi. Langgan kemas kini kepada versi stabil daripada vendor perisian.

Semak hak akses. Di sisi pelayan, sentiasa layan kod anda seolah-olah ia, dari huruf pertama hingga terakhir, ditulis oleh musuh yang paling dibenci anda, yang mahu memecahkan tapak anda, melanggar integriti data anda. Lebih-lebih lagi, kadang-kadang ini benar.

Gunakan klon, tapak ujian, dan kemudian gunakannya untuk pengeluaran. Ini akan membantu, pertama, untuk mengelakkan kesilapan dan kesilapan dalam persekitaran yang produktif: persekitaran yang produktif membawa wang, persekitaran produktif yang mudah adalah kritikal. Apabila menambah, membetulkan atau menutup sebarang masalah, ia patut bekerja dalam persekitaran ujian, kemudian menyemak kefungsian dan kelemahan yang ditemui, dan kemudian merancang untuk bekerja dengan persekitaran pengeluaran. 

Lindungi aplikasi web anda dengan Firewall Aplikasi Web dan menyepadukan laporan daripada pengimbas kerentanan dengannya. Sebagai contoh, DataLine menggunakan Qualys dan FortiWeb sebagai himpunan perkhidmatan.

Sumber: www.habr.com