(Tanpa) perbankan online berbahaya: studi tentang sumber daya web bank di Rusia dan dunia

Kami memutuskan untuk mengulangi pekerjaan penelitian berskala besar tahun 2015 dan menganalisis keamanan sumber daya web bank-bank terkemuka dunia. Sejak itu, perbankan online telah menjadi tidak hanya semakin meluas, tetapi bahkan meluas. Memang, itu cepat dan nyaman, tetapi seberapa aman? Apakah bank mengikuti praktik terbaik?



Seperti terakhir kali , dalam studi ini, kami mengirim permintaan HTTP dan DNS biasa tanpa mengganggu bank. Artinya, semua data dikumpulkan seperti yang biasa dilakukan pengguna dengan mengunjungi sumber daya. Untuk analisis, kami memilih 200 bank Rusia dan 400 bank asing. Di bawah potongan kutipan dari penelitian. Teks lengkap dapat ditemukan di situs web kami.


Kali ini kami memperluas bidang penelitian dengan menambahkan sumber daya online bank asing ke ruang lingkup. Ini memungkinkan Anda untuk membandingkan sikap terhadap keamanan web di Rusia dan negara-negara lain di dunia.


Ke depan, kami menyesal mencatat bahwa metode klasik untuk meningkatkan tingkat keamanan sering diabaikan oleh bank, meskipun mereka tidak memerlukan sumber daya keuangan dan teknis global. Melewatkan peluang adalah sukarela, tetapi sama sekali berbeda untuk menggunakannya secara salah. Misalnya, dalam hal Kebijakan Keamanan Konten, seperlima dari semua sumber daya yang dipertimbangkan memiliki pengaturan, dan hampir setiap dari mereka memiliki kesalahan konfigurasi. Sebagai bagian dari penelitian ini, kami mencoba mempertimbangkan secara rinci cara bekerja dengan pengaturan jenis ini dengan benar, dan kesalahan apa yang paling sering terjadi.


Tujuan penelitian


Tujuan utama dari penelitian ini adalah untuk menilai tingkat keamanan sumber daya perbankan yang tersedia untuk umum: situs web resmi dan RBS, sesuai dengan praktik terbaik untuk menyiapkan sumber daya web. Kami telah memilih sejumlah poin, yang kepatuhannya dapat diperiksa, tidak termasuk kerusakan teknis dan tanpa mengganggu pekerjaan bank. Penting untuk dicatat bahwa semua informasi yang kami kumpulkan berada dalam domain publik, dan memanipulasi data ini tidak memerlukan keterampilan mendalam: jika Anda mau, pengguna yang tertarik dapat memperoleh hasil seperti itu.


Obyek penelitian


Untuk pengujian, kami mengambil bank TOP-200 di Rusia. Daftar lengkap dapat ditemukan di: http://www.banki.ru/banks/ratings/ (data saat ini per Maret 2019).


Kami juga memilih 20 bank dari 30 negara lain (daftar)

Austria
Belarus
Belgia
Bulgaria
Bosnia dan Herzegovina
Brazil
Inggris
Hongaria
Jerman
Denmark
Israel
Irlandia
Spanyol
Italia
Kanada
Cina
Liechtenstein
Luksemburg
Malta
Belanda
Norwegia
UAE
Polandia
Portugal
Amerika Serikat
Finlandia
Prancis
Swiss
Swedia
Jepang


Langkah pertama kami mengidentifikasi semua situs web resmi dan sumber daya Internet BPR untuk individu dan badan hukum. Kemudian, untuk masing-masing bank, cek dilakukan menggunakan beberapa permintaan standar menggunakan protokol HTTP / HTTPS / DNS, mirip dengan permintaan biasa dari pelanggan bank. Daftar yang Dikelompokkan:


  1. Pengaturan SSL - memberikan peluang untuk menerapkan salah satu dari banyak serangan yang terkait dengan SSL;
  2. Pengaturan DNS - memungkinkan Anda untuk mendapatkan informasi tentang subdomain perusahaan.

Berikut ini adalah deskripsi dan hasil dari beberapa pemeriksaan. Kami memberikan perhatian khusus pada bagian yang dikhususkan untuk Kebijakan Keamanan Konten: di dalamnya kami mencoba menyoroti kesalahan utama dan memberi tahu bagaimana mereka dapat dihindari. Deskripsi lengkap dan hasil semua cek ada dalam penelitian ini .


Pengujian


SSL / TLS


Salah satu poin paling penting adalah memeriksa pengaturan SSL / TLS, as Saat ini, protokol kriptografi ini adalah metode paling populer untuk menyediakan pertukaran data yang aman melalui Internet. Ancaman potensial utama adalah penggunaan serangan intersepsi lalu lintas.
Cek berikut dipilih:


Nama VerifikasiDeskripsi singkat
PeringkatPeringkat konfigurasi SSL keseluruhan, menurut Qualys SSL Labs . Itu tergantung pada banyak faktor, di antaranya: kebenaran sertifikat, pengaturan server dan algoritma yang didukung server. Wisuda dari F ke A +.
Dukungan kunci DH lemahParameter yang lemah dapat digunakan untuk bertukar kunci Diffie-Hellman, yang mengurangi keamanan sumber daya.
POODLE KerentananMemungkinkan Anda mendekripsi data pengguna. Untuk informasi lebih lanjut, lihat publikasi para peneliti.
KEBEBASAN FREAKTerdiri dari fakta bahwa penyerang dapat memaksa pengguna dan server untuk menggunakan kunci "ekspor", yang panjangnya sangat terbatas, ketika membuat koneksi dan bertukar data.
Logjam menyerang kerentananSeperti FREAK, Logjam didasarkan pada penurunan tingkat enkripsi ke tingkat "ekspor", di mana panjang kuncinya adalah 512 bit. Perbedaannya adalah bahwa Logjam menyerang algoritma Diffie-Hellman.
DROWN KerentananMemungkinkan Anda mendekripsi lalu lintas TLS klien jika SSL 2.0 tidak dinonaktifkan di sisi server di semua server yang beroperasi dengan kunci pribadi yang sama.
Kerentanan ROBOTBenar-benar melanggar privasi TLS saat menggunakan RSA.
Beast VulnerabilityPenyerang dapat mendekripsi data yang dipertukarkan antara dua pihak menggunakan TLS 1.0, SSL 3.0 dan di bawahnya.
Kerentanan CVE-2016-2107Penyerang jarak jauh dapat menggunakan kerentanan ini untuk mengekstrak teks dari paket terenkripsi menggunakan server TLS / SSL atau DTLS sebagai bantalan oracle.
Kerentanan HeartbleedMengakses data yang ada di memori klien atau server.
Kerentanan TiketPenyerang jarak jauh dapat mengeksploitasi kerentanan untuk mengekstrak ID sesi SSL, dimungkinkan untuk mengekstrak data lain dari area memori yang tidak diinisialisasi.
Renegosiasi SSLTanpa negosiasi ulang SSL yang aman, risiko serangan DoS atau MITM akan meningkat.
Dukungan RC4Peluang ditemukan dalam waktu singkat untuk mendekripsi data yang disembunyikan menggunakan cipher RC4.
Mendukung Kerahasiaan PenerusanIni adalah properti dari protokol negosiasi kunci tertentu yang menjamin bahwa kunci sesi tidak akan dikompromikan, bahkan jika kunci pribadi server dikompromikan.
Versi TLSProtokol TLS mengenkripsi semua jenis lalu lintas Internet, sehingga membuat komunikasi di Internet aman. Namun, versi sebelumnya dari TLS 1.0 dan 1.1 mengandalkan algoritma hash yang tidak dapat diandalkan MD5 dan SHA-1 dan direkomendasikan untuk menonaktifkan
Dukungan SSL 2.0 dan SSL 3.0Kedua protokol dianggap usang dan memiliki banyak kerentanan, oleh karena itu, mereka direkomendasikan untuk pemutusan pada sisi server.
Mendukung NPN dan ALPNMemungkinkan Anda menentukan protokol mana yang akan digunakan setelah membuat koneksi SSL / TLS yang aman antara klien dan server.

Peringkat


SSL / TLS memiliki sejumlah besar pengaturan dan fitur yang, sampai taraf tertentu, memengaruhi keamanan koneksi itu sendiri dan pesertanya secara keseluruhan. Untuk melakukan penilaian keseluruhan dari pengaturan ini, kami menggunakan fungsionalitas yang disediakan oleh Qualys (www.ssllabs.com). Ini memungkinkan atas dasar berbagai parameter untuk membuat peringkat umum dari A ke F, di mana "A +" adalah hasil terbaik yang dapat dicapai dalam hal keamanan. Sangat sedikit perusahaan, bahkan perusahaan Internet terbesar, yang memilikinya. Dengan demikian, "F" adalah hasil terburuk. Ini dapat diperoleh jika server terpapar pada kerentanan kritis, mendukung protokol yang ketinggalan zaman dan memiliki masalah lain. Seperti peringkat "A +", hasil terburuk jarang terjadi, dan terutama terkait dengan staf yang tidak profesional.


Persentase peringkat di bawah "A" ditampilkan pada kartu. Semakin tinggi persentase ini, semakin buruk situasi dengan keamanan web di negara ini.


Tajuk HTTP


Header dalam respons server web memungkinkan Anda menentukan perilaku browser dalam situasi tertentu. Kehadiran mereka membantu menghindari beberapa serangan atau menyulitkan perilaku mereka, sementara menambahkan header tidak memerlukan tindakan atau pengaturan yang rumit. Namun, beberapa pengaturan, misalnya, CSP, dibedakan oleh terlalu banyak opsi, penggunaan yang salah dapat menciptakan ilusi keamanan atau bahkan merusak beberapa fungsionalitas situs. Kami meninjau judul berikut:


Berita utamaDeskripsi
Konten-Keamanan-KebijakanIni memungkinkan Anda untuk secara eksplisit menentukan dari mana konten ini atau itu dapat diambil.
X-XSS-PerlindunganFitur Internet Explorer, Chrome, dan Safari yang menghentikan pemuatan halaman saat serangan XSS terdeteksi.
Opsi-bingkai XMengaktifkan atau menonaktifkan tampilan situs dalam bingkai (iframe).
X-Content-Type-OptionsHeader ini akan memberi tahu IE / Chrome bahwa tidak perlu menentukan Tipe-Konten secara otomatis, tetapi Anda harus menggunakan Tipe-Konten yang sudah diberikan.
Ketat-transportasi-keamananMemungkinkan Anda mencegah pembentukan koneksi HTTP tidak aman pada waktu tertentu.
Tetapkan cookieTidak adanya bendera HttpOnly dan Secure di header respons HTTP akan memungkinkan Anda untuk mencuri atau memproses sesi aplikasi web dan cookie.
Kebijakan rujukanMengizinkan situs mengontrol nilai tajuk Referer untuk tautan dari halaman Anda.
Kebijakan fiturMemungkinkan Anda untuk mengontrol berbagai fungsi browser di halaman.
Pin kunci publikMengurangi risiko serangan MITM dengan sertifikat palsu.
Harapkan-CTMemungkinkan Anda untuk memastikan kepatuhan dengan persyaratan transparansi sertifikat, yang mencegah penggunaan yang tidak mencolok dari sertifikat yang belum dikonfirmasi untuk situs ini.
X-Powered-CMSMengindikasikan mesin CMS yang digunakan.
X-Didukung-OlehMenentukan platform aplikasi yang menjalankan server.
Header serverMenunjukkan perangkat lunak server (apache, nginx, IIS, dll.).

Jika sepuluh judul pertama bersifat "positif", dan diinginkan (dengan benar!) Untuk menggunakannya, maka tiga judul terakhir "memberi tahu" penyerang teknologi apa yang sedang digunakan. Secara alami, judul seperti itu harus dibuang.


Peringkat


Kombinasi header HTTP yang benar memungkinkan Anda memastikan keamanan situs, sementara mengaturnya sama sekali tidak sulit. Kami telah mengumpulkan data tentang penggunaan header HTTP dan berdasarkan itu kami telah menyusun peringkat keamanan untuk sumber daya web.
Untuk kepatuhan dengan parameter berikut, kami memberikan atau mencetak poin:


Berita utamaKondisi pengaturanPoin jika memenuhi persyaratanPoin jika tidak memenuhi syarat
X-XSS-Perlindunganhadir, bukan 0+1-1
Opsi-bingkai Xhadir+1-1
X-Content-Type-Optionshadir+1-1
X-Content-Security-Policy / Content-Security-Policysetidaknya ada satu+1-1
Ketat-transportasi-keamananhadir dan tidak kosong+1-1
Servertidak mengandung versi server+1-1
Tetapkan cookieKehadiran bendera Aman dan httponly+1 untuk masing-masing0
Kebijakan rujukanhadir,> 0+10
Kebijakan fiturhadir+10
Pin kunci publikhadir+10
Harapkan-CThadir+10
X-Powered-CMShilang+1-1
X-Didukung-Olehhilang+1-1

Peringkat dari "D" ke "A +", di mana "A +" adalah hasil terbaik yang dapat dicapai dalam hal keamanan. Namun, hasil terburuk cukup langka, seperti yang terbaik.


Distribusi peringkat


Persentase peringkat di bawah "A" ditampilkan pada kartu. Semakin tinggi persentase ini, semakin buruk situasi dengan keamanan web di negara ini.


Kebijakan Keamanan Konten


"Kebijakan Perlindungan Konten" atau CSP adalah salah satu cara utama untuk mengurangi risiko yang terkait dengan eksploitasi serangan XSS. Alat ini memungkinkan administrator situs untuk menentukan sumber daya web mana yang diizinkan untuk digunakan pada halaman - font, gaya, gambar, skrip JS, SWF dan sebagainya. Cari tahu browser mana yang mendukung CSP di sini .


Berkat CSP, Anda dapat sepenuhnya mencegah browser memuat, misalnya, objek flash, atau menyesuaikan daftar putih domain - dalam hal ini, browser hanya akan menampilkan SWF yang terletak di domain yang diizinkan. Keuntungan lain yang disediakan oleh kebijakan CSP adalah kemampuan untuk dengan cepat belajar tentang penampilan XSS baru dalam luasnya sumber daya yang terkontrol. Dengan menggunakan opsi "report-uri", browser penyerang atau pengguna korban mengirimkan laporan ke URL yang ditentukan segera setelah CSP dipicu.


Di antara kesalahan utama terkait dengan kebijakan CSP, kategori berikut dapat dibedakan:


  1. Konfigurasi salah
    • Arahan Hilang (script-src | objek-src | default-src | base-uri)
    • Opsi redundan (tidak aman-inline | tidak aman-eval | https: | data: | *)
  2. Kelemahan host dan daftar putih
    • Kemampuan untuk memuat file JS sewenang-wenang
    • Telepon balik
    • Gawai skrip di mesin template Sudut dan sejenisnya
  3. Serangan bebas JS ("skrip")
    • Kebocoran melalui tag yang tidak tertutup
    • Terapkan Formulir Phishing

Informasi yang lebih terperinci, contoh spesifik kesalahan dan cara untuk menghindarinya dapat ditemukan dalam teks lengkap penelitian ini .


Tujuan utama CSP adalah untuk mengurangi kemungkinan mengeksploitasi serangan XSS, tetapi, seperti yang ditunjukkan penelitian, hanya sedikit yang dapat mengkonfigurasi kebijakan ini dengan benar: hanya 3% yang menggunakan CSP.
Grafik menunjukkan kesalahan paling umum di situs CSP yang ditinjau.


Ketat-transportasi-keamanan


Kebijakan keamanan HSTS (HTTP Strict Transport Security) memungkinkan Anda membuat koneksi yang aman alih-alih menggunakan protokol HTTP. Untuk melakukan ini, gunakan header Strict-Transport-Security, yang memaksa browser untuk memaksa penggunaan HTTPS. Ini mencegah beberapa serangan MITM, khususnya, serangan dengan tingkat perlindungan dan pencurian cookie yang lebih rendah. Prinsip mekanisme adalah sebagai berikut: pertama kali Anda mengunjungi situs menggunakan protokol HTTP (S), browser menerima header Strict-Transport-Security dan ingat bahwa untuk upaya lebih lanjut untuk terhubung ke situs ini, hanya HTTPS yang harus digunakan.
Ini akan mencegah skenario di mana penyerang, mencegat permintaan HTTP, mengarahkan pengguna ke halaman klon untuk mendapatkan datanya.


Persentase bank yang menggunakan tajuk HTTP Ketat-Transport-Keamanan



Setelah menerima permintaan HTTP, server dapat mengirim tajuk Set-Cookie beserta responsnya.
Cookie dengan bendera Aman dikirim ke server hanya jika permintaan dilakukan melalui SSL dan HTTPS. Namun, data penting tidak boleh dikirim atau disimpan dalam cookie, karena mekanismenya sangat rentan, dan bendera Aman tidak menyediakan enkripsi tambahan atau langkah-langkah keamanan. Cookie dengan flag HTTPlyly tidak dapat diakses dari JavaScript melalui properti API Document.cookie, yang membantu menghindari pencurian cookie dari klien jika terjadi serangan XSS. Bendera ini harus ditetapkan untuk cookie yang tidak perlu diakses melalui JavaScript. Khususnya, jika cookie hanya digunakan untuk mendukung sesi, maka dalam JavaScript tidak diperlukan dan Anda dapat menggunakan flag HTTPOnly. Tanpa tanda HTTPOnly dan Secure di tajuk respons HTTP, Anda dapat mencuri atau memproses sesi aplikasi web dan cookie.


Bendera aman dan HTTPhanya di tajuk ini tidak ditemukan lebih sering daripada di setiap situs web resmi kedua bank di Bosnia dan Herzegovina, Jepang, Cina, Brasil, Bulgaria, Luksemburg, Finlandia, Israel, Prancis, Inggris Raya, dan Spanyol.
Diantaranya DBO untuk fisik. orang - Cina, Irlandia, Israel dan Jepang.
Di antara RBS untuk jur. orang - Bosnia dan Herzegovina, Brasil dan Cina.


Di antara bank-bank Rusia, statistiknya adalah sebagai berikut:
Situs web resmi bank - 42%;
RBS untuk fisik. orang - 37%;
RBS untuk legal orang - 67%.


Header server


Header ini memberi tahu Anda perangkat lunak mana yang dijalankan oleh server web, dan mungkin memiliki makna berikut, misalnya:


Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l 

Pengungkapan informasi ini tidak menimbulkan ancaman langsung, tetapi dapat mengurangi waktu serangan. Alih-alih memeriksa kerentanan tertentu, Anda dapat segera mulai mencari data pada versi perangkat lunak tertentu. Misalnya, selama penelitian, data berikut ditemukan:

Studi ini menunjukkan bahwa 64% situs bank melaporkan versi server, sementara 24% dari server ini rentan.


Kesimpulan


Setelah menerima gagasan umum tentang keamanan sumber daya web bank, kami sampai pada kesimpulan utama: banyak bank mengabaikan bahkan tip yang paling umum dan mudah diterapkan untuk meningkatkan keamanan sumber daya web mereka.


Kerentanan dan kesalahan yang kami temukan memungkinkan penyerang menerapkan serangan pada sumber daya tanpa menghabiskan banyak usaha. Tetapi konsekuensi dari serangan ini cukup serius: kerugian tunai pelanggan, kerugian finansial dan reputasi bank, termasuk dalam jangka panjang. Sedikit yang mempercayai uang mereka kepada bank yang reputasinya ternoda oleh insiden keamanan.


Tentu saja, mengikuti praktik standar meningkatkan tingkat keamanan - mencari dan menutup kerentanan - terbayar dan meminimalkan risiko. Namun, sebagian besar pengembang aplikasi web perbankan lupa tentang rekomendasi dan metode paling sederhana yang dapat secara signifikan mengurangi risiko atau mempersulit eksploitasi kerentanan (seperti, misalnya, bersembunyi dari header server dengan informasi tentang perangkat lunak yang digunakan atau menginstal CSP). Manfaat menggunakan teknologi tersebut tidak segera terlihat, tetapi mungkin tidak jelas sama sekali: setelah menjumpai mereka, seorang penyerang tidak akan dapat melakukan serangan, dan tindakannya akan tetap tidak terlihat oleh mereka yang bertanggung jawab untuk keamanan.


Setelah memeriksa sumber daya web bank-bank Rusia dari berbagai sudut, kami menemukan bahwa kerentanan dan masalah keamanan yang cukup terkenal masih ada di dalamnya. Hal ini memungkinkan penyerang untuk menghitung keberhasilan implementasi serangan terhadap lembaga-lembaga keuangan ini. Dan semakin banyak masalah, semakin tinggi risiko keuangan dan reputasi bank.
Situasi di dunia secara keseluruhan tidak terlalu berbeda. Di antara yang jelas tertinggal dalam hal keamanan dapat diidentifikasi sumber daya perbankan online dari negara-negara berikut: Cina, Jepang, Brasil, Israel, Spanyol. Paradoksnya, dalam banyak kasus, bank asing lebih memperhatikan keamanan halaman utama mereka daripada pada sistem perbankan. Perlu dicatat bahwa bagian analisis bank asing dalam penelitian ini tidak begitu luas dan, lebih tepatnya, pengenalan.

Source: https://habr.com/ru/post/id474582/


All Articles