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:
- Pengaturan SSL - memberikan peluang untuk menerapkan salah satu dari banyak serangan yang terkait dengan SSL;
- 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:
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:
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:
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:
- Konfigurasi salah
- Arahan Hilang (script-src | objek-src | default-src | base-uri)
- Opsi redundan (tidak aman-inline | tidak aman-eval | https: | data: | *)
- Kelemahan host dan daftar putih
- Kemampuan untuk memuat file JS sewenang-wenang
- Telepon balik
- Gawai skrip di mesin template Sudut dan sejenisnya
- 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

Tetapkan cookie
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 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.