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

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

Hadirin: jadi apa yang mencegah penyerang menemukan kunci? Di mana kunci rahasia ini berada?



Profesor: ya, itu pertanyaan yang bagus. Dalam kebanyakan kasus, klien untuk AWS bukanlah browser, tetapi beberapa mesin virtual yang berjalan di cloud. Dengan demikian, Anda hanya melihat komunikasi antara mesin virtual. Anda juga dapat membayangkan bahwa pengguna dapat memberikan tautan ini atau menanamkannya dalam HTML. Jika Anda memiliki sesuatu seperti yang ditunjukkan pada papan di dalam HTML atau kode sumber JavaScript, Anda akan memiliki kode untuk membuat permintaan seperti itu. Karena itu, jika saya memberi Anda salah satu dari hal-hal ini, Anda dapat mengajukan permintaan atas nama saya.

Audiens: Apakah mungkin menggunakan MAC untuk klien normal?

Profesor: untuk yang normal - maksud Anda browser?

Pemirsa: untuk pengguna biasa.

Profesor: faktanya adalah pertanyaan tentang di mana kuncinya benar-benar tinggal adalah yang krusial. Karena jika kunci dapat dicuri semudah cookie, maka kami tidak memenangkan apa pun. Oleh karena itu, dalam banyak kasus, semua hal ini disimpan di suatu tempat di cloud dan berfungsi untuk bertukar data antara mesin virtual dan ditransmisikan dari server ke server juga di cloud. Dengan demikian, pengembang aplikasi meluncurkan VM, yang menggunakan outsourcing banyak hal yang tersimpan di AWS.

Pemirsa: Apakah ada masalah keterlambatan jaringan di sini, sehingga penyerang dapat mengirim permintaan yang sama segera setelah pengguna dan juga mendapatkan akses?

Profesor: ya, sudah cukup untuk mengatakan bahwa beberapa orang membela disertasi tentang topik keamanan cap waktu. Tetapi Anda benar sekali, karena kami telah mempertimbangkan contoh yang agak kasar.



Bayangkan di sini, dalam contoh String To Sign ini, pada baris DATE, kita akan memiliki nilai "Senin, 4 Juni". Kemudian, jika entah bagaimana penyerang bisa mendapatkan akses ke semua ini, ia akan dapat mengulangi permintaan pengguna. Faktanya adalah AWS memungkinkan Anda untuk menggunakan tanggal kedaluwarsa dari hal-hal ini. Dengan demikian, satu hal yang dapat Anda lakukan adalah menambahkan bidang Kedaluwarsa di sini, dan kami akan menganggap bahwa tanggal kedaluwarsa telah ditetapkan.



Lalu saya bisa memberikan tautan ini ke sekelompok orang yang berbeda, dan server akan memeriksa apakah permintaan mereka telah kedaluwarsa.

Hadirin: bahkan jika tanggal kedaluwarsa hanya 200 milidetik, tetapi penyerang sedang memantau jaringan, ia akan dapat mengirim untuk berjaga-jaga jika beberapa salinan permintaan bukan satu.

Profesor: benar - benar benar bahwa jika penyerang menyerang jaringan dan melihat bagaimana hal-hal ini ditransmisikan melalui kabel, dan ada cukup ruang untuk bermanuver pada tanggal kedaluwarsa, maka ia pasti dapat melakukan serangan ini.

Jadi ini adalah ikhtisar tentang cara kerja cookie stateless. Ini menimbulkan satu pertanyaan menarik: apa artinya keluar dengan cookie jenis ini? Jawabannya adalah Anda tidak benar-benar pacaran. Maksud saya, Anda memiliki kunci ini dan kapan pun Anda ingin mengirim permintaan, Anda hanya mengirimnya. Tetapi server dapat mencabut kunci Anda.

Misalkan server membatalkan kunci. Tetapi Anda dapat membuat salah satu dari hal-hal ini MENDAPATKAN, dan ketika Anda mengirim pesan ke server, itu akan mengatakan: "Ya, saya sudah tahu ID Pengguna Anda, kuncinya telah dicabut, jadi saya tidak akan memenuhi permintaan Anda." Namun, ada nuansa, dan jika kita berbicara tentang hal-hal seperti SSL, memberdayakan seseorang jauh lebih mudah daripada mengingatnya.

Dengan demikian, ada beberapa hal lain yang dapat Anda gunakan jika Anda ingin menghindari cookie tradisional untuk mengimplementasikan otentikasi. Salah satunya adalah penggunaan penyimpanan DOM, yang berisi informasi tentang otentikasi sisi klien. Anda bisa menggunakan repositori DOM untuk menyimpan beberapa status sesi yang biasanya ditempatkan di dalam cookie.



Jika Anda ingat dari kuliah terakhir, repositori DOM adalah antarmuka kunci dari nilai-nilai yang disediakan browser untuk setiap sumber, yaitu, browser mengambilnya dari sana dan memasukkannya ke dalam string.

Hal yang baik adalah bahwa DOM tidak memiliki aturan bodoh mengenai kebijakan yang sama dari asal yang sama. Jadi, jika ini adalah cookie biasa, Anda bisa melakukan semua trik subdomain dan sejenisnya. Repositori DOM sebenarnya terikat dengan satu sumber, sehingga Anda tidak dapat memperluas subdomain apa pun. Oleh karena itu, kerangka kerja seperti Meteor menggunakan penyimpanan ini.

Tetapi perhatikan bahwa jika Anda ingin menyimpan informasi otentikasi dalam repositori DOM, Anda harus menulis kode JavaScript sendiri untuk mentransfer informasi ini ke server, mengenkripsi, dan sebagainya. Inilah yang perlu Anda lakukan dalam kasus ini.
Seseorang dapat menggunakan sertifikat sisi klien, misalnya, format x.509, yang berisi informasi tentang pemilik, kunci publik, informasi tentang otoritas sertifikasi dan tanda tangan digital elektronik. Hal yang baik tentang sertifikat ini adalah bahwa JavaScript tidak memiliki antarmuka eksplisit untuk mengakses hal-hal ini. Jadi tidak seperti cookie, di mana selalu ada "perlombaan senjata" untuk menemukan kesalahan kebijakan dari asal yang sama, sertifikat tidak memiliki antarmuka JavaScript eksplisit untuk ini. Jadi ini sangat bagus dari sudut pandang keamanan.

Salah satu masalah yang saya sebutkan secara singkat dan yang akan kita bahas secara rinci dalam kuliah berikutnya adalah pencabutan sertifikat. Jika pengguna meninggalkan organisasi Anda, bagaimana Anda bisa mengambil sertifikat darinya? Ini cukup rumit.



Selain itu, hal-hal ini sangat tidak nyaman untuk digunakan, karena tidak ada yang ingin menginstal banyak sertifikat untuk setiap situs yang Anda kunjungi. Oleh karena itu, sertifikat otentikasi tidak terlalu populer, dengan pengecualian perusahaan atau organisasi yang bertanggung jawab atas keamanan dengan tanggung jawab besar. Ini menyimpulkan diskusi kami tentang cookie.

Sekarang mari kita bicara tentang kerentanan protokol di tumpukan web. Salah satu jenis serangan yang menarik adalah menggunakan kesalahan dalam komponen peramban, misalnya, saat mem-parsing URL. Jadi, bagaimana penguraian URL dapat menyebabkan masalah bagi kami?

Misalkan kita memiliki URL sejenis di mana karakter aneh disematkan di bagian akhir karena beberapa alasan:

example.com : 80 @ foo.com.

Pertanyaannya adalah, apa asal usul URL ini? Flash akan mengira nama host adalah example.com. Tetapi ketika browser menganalisis alamat, ia akan berpikir bahwa asal dari host dalam hal ini adalah foo.com.



Ini sangat buruk, karena ketika kita memiliki dua entitas yang berbeda yang bingung tentang asal usul sumber daya yang sama, itu penuh dengan masalah yang tidak menyenangkan.
Misalnya, kode flash mungkin berbahaya dan mengunduh beberapa materi dari example.com. Jika exploit dibangun di halaman dengan foo.com, itu juga bisa melakukan beberapa hal jahat di sana. Dan kemudian dia mengambil beberapa kode dari example.com dan menjalankannya dengan kekuatan foo.com. Banyak aturan penguraian kompleks seperti ini membuat hidup sangat sulit. Itu terjadi setiap saat.

Kami baru saja memeriksa desinfeksi konten, ide utamanya adalah bahwa seringkali jauh lebih baik ketika ada aturan penguraian yang lebih sederhana untuk hal semacam ini. Namun, secara retrospektif hal ini sulit dilakukan, karena HTML sudah ada.
Sekarang mari kita bicara tentang kerentanan keamanan favorit saya - file dengan ekstensi .jar, yang merupakan arsip ZIP dengan bagian dari program Java. File browser JAR menjadi target serangan, terutama applet Java. Sekitar 2007, satu situs luar biasa bernama lifehacker.com menjelaskan cara menyematkan file zip di dalam gambar. Tidak jelas siapa yang Anda coba sembunyikan dengan melakukan ini, tetapi lifehacker.com memastikan bahwa Anda bisa melakukannya.

Mereka terutama menggunakan fakta bahwa jika Anda melihat format gambar, seperti GIF, maka, sebagai aturan, pengurai bekerja dari atas ke bawah. Pertama dia menemukan informasi di header, dan kemudian melihat bit yang tersisa yang terletak di bagian bawah.



Ternyata, program yang biasanya memanipulasi file ZIP bekerja dari bawah ke atas, yaitu kebalikan dari arah penguraian gambar. Pertama, mereka menemukan informasi di bagian bawah file dan membongkar apa yang ada di dalam arsip. Jadi, jika Anda menempatkan file gambar yang berisi arsip ZIP, itu akan melewati semua pemeriksaan, bahkan pemeriksaan Flickr, seperti gambar lainnya, dan bahkan akan muncul sebagai gambar di browser Anda.

Tetapi hanya Anda yang akan tahu kebenaran yang tersembunyi. Hanya Anda yang akan mengetahui bahwa jika Anda mengambil file ini, Anda dapat mengekstraknya dan menggunakan informasi yang ada di sana. Sepertinya trik yang murah, tetapi peretas tidak pernah tidur, mereka terus-menerus ingin menghancurkan hidup kita. Jadi bagaimana mereka menerapkan ide ini?

Mereka mengerti bahwa file JAR berasal dari format .zip. Ini berarti bahwa Anda dapat membuat animasi GIF atau gambar statis yang akan memiliki file JAR, yaitu, kode yang dapat dieksekusi JavaScript, di bagian paling bawah.

Kemudian, orang-orang menyebut metode serangan ini GIFAR, setengah GIF, setengah JAR, dan kedua bagiannya jahat. Itu luar biasa. Ketika orang pertama kali menemukan kesempatan seperti itu, mereka menemukan itu luar biasa, tetapi tidak mengerti sama sekali bagaimana menggunakannya. Tetapi ternyata, atas dasar hal-hal berikut dapat dilakukan.



Jadi bagaimana Anda bisa melakukan ini? Anda hanya menggunakan CAD. Ambil .gif, ambil .jar, gunakan arsip self-extracting - boom, dan GIFAR menyerang Anda!

Jadi, begitu Anda memilikinya, apa yang bisa Anda lakukan? Ada beberapa situs sensitif yang memungkinkan pengguna untuk memberikan data, tetapi bukan tipe data yang sewenang-wenang. Jadi Flickr atau sesuatu seperti itu mungkin tidak memungkinkan Anda untuk mengirim ActiveX sewenang-wenang atau HTML sewenang-wenang lainnya. Tetapi Anda akan diizinkan mengirim gambar. Jadi, Anda dapat membangun salah satu dari hal-hal ini dan mengirimkannya ke salah satu situs rahasia yang memungkinkan Anda mengirim gambar. Apa yang perlu Anda lakukan untuk melakukan serangan yang berhasil dalam kasus ini?



Pertama, kirim gambar "boneka" ini ke salah satu situs ini. Kedua, gunakan metode serangan skrip lintas situs XSS, menggunakan kerentanan yang ada. Untuk melakukan ini, Anda harus memasukkan applet, menulis dalam JavaScript ungkapan seperti:

Kode ini mengeksploitasi kerentanan skrip lintas situs, oleh karena itu akan diluncurkan dalam konten situs. GIFAR akan lulus pemeriksaan asal, karena berasal dari situs dengan sumber asal yang sama, terlepas dari kenyataan bahwa kode ini dimasukkan oleh penyerang.

Jadi, sekarang penyerang mendapat kesempatan untuk menjalankan applet Java ini dalam konteks situs korban dengan semua izin asal. Dan salah satu dari hal-hal ini akan benar-benar diidentifikasi sebagai gambar GIF. Tetapi ada kode tersembunyi di sini. Biarkan saya mengingatkan Anda bahwa pada awalnya browser membongkar file yang diarsipkan, oleh karena itu, pertama-tama, itu akan meluncurkan bagian JAR, abaikan bagian atas GIF. Jadi ini sebenarnya sangat menakjubkan.

Ada beberapa cara yang cukup sederhana untuk memperbaikinya. Misalnya, Anda dapat menggunakan loader applet, yang memahami bahwa tidak boleh ada sampah acak. Dalam banyak kasus, informasi metadata digunakan yang menunjukkan panjangnya sumber daya ini. Dalam hal ini, loader akan mulai, seperti yang diharapkan, dari atas, menganalisis panjangnya, melihat bahwa applet berakhir di atas, dan berhenti. Dia tidak peduli tentang bagian bawah, mungkin bahkan 0. Dalam kasus kami, pemuat seperti itu tidak akan membantu, karena ia akan mulai memproses permintaan dari bagian bawah yang diarsipkan, dan berhenti di depan bagian atas, mengabaikannya.

Apa yang saya suka tentang ini adalah bahwa itu benar-benar menunjukkan seberapa lebar tumpukan perangkat lunak Internet. Mengambil hanya dua format ini, GIF dan JAR, Anda dapat membuat serangan yang benar-benar jahat.

Anda dapat melakukan hal yang sama dengan file PDF. Anda dapat meletakkan PDF sebagai ganti GIF dan menyebut serangan ini sesuatu dari bahaya PDFAR. Tetapi pada akhirnya, orang menemukan masalah ini, dan kerentanan seperti ini sekarang dihilangkan.

Audiens: Apa yang dapat Anda lakukan dengan serangan seperti ini, yang tidak dapat dilakukan dengan serangan skrip lintas situs XSS biasa?

Profesor: Ini pertanyaan yang bagus. Jadi apa yang baik tentang ini adalah bahwa Java seringkali dapat menjadi alat yang lebih kuat daripada JavaScript biasa, karena menggunakan aturan yang sedikit berbeda, kebijakan asal yang sama, dan sejenisnya. Tetapi Anda benar bahwa jika Anda dapat menjalankan skrip lintas situs, menjalankan JavaScript sendiri bisa sangat merusak. Tetapi keuntungan utama dari metode ini adalah bahwa teknologi serangan ini bekerja di dalam applet dan dapat melakukan apa yang tidak dapat dilakukan dengan kode skrip berbahaya yang biasa.

Jadi, seperti yang saya katakan, ini adalah serangan favorit saya sepanjang masa, terutama karena membuat orang-orang keamanan komputer yang memiliki reputasi memikirkan kata seperti GIFAR.

Hal lain yang menarik adalah penggunaan serangan berbasis waktu. Biasanya orang tidak menganggap waktu sebagai sumber daya, yang bisa menjadi vektor serangan. Tetapi seperti yang saya catat beberapa menit yang lalu, waktu itu sebenarnya bisa menjadi sarana untuk memperkenalkan exploit ke dalam sistem.

Serangan spesifik yang akan saya bicarakan dengan Anda adalah serangan saluran rahasia. Gagasan serangan ini adalah bahwa penyerang menemukan cara untuk bertukar informasi antara dua aplikasi, dan operasi pertukaran ini tidak diotorisasi. Penyerang entah bagaimana menggunakan beberapa bagian dari sistem untuk mentransfer bit informasi antara dua sumber daya yang berbeda.

Contoh yang bagus dari hal itu adalah serangan CSS mengendus. Serangan seperti apa itu?

Misalkan penyerang memiliki situs web yang dapat dikunjungi pengguna. Membuat pengguna mengunjungi situs web sebenarnya cukup sederhana. Anda membuat iklan atau mengirim email phishing.

Dengan demikian, penyerang memiliki situs web yang dikunjungi pengguna. Dan tujuan penyerang adalah untuk mengetahui situs apa yang telah dikunjungi pengguna. Seorang penyerang mungkin ingin mengetahui hal ini karena beberapa alasan. Mungkin dia tertarik pada permintaan pencarian pengguna, atau dia mencoba mencari tahu di mana orang ini bekerja, atau mungkin dia ingin tahu apakah orang ini mengunjungi beberapa situs "memalukan" dan sebagainya.



Bagaimana penyerang akan melakukan ini jika satu-satunya hal yang dia kontrol adalah situs web yang dia ingin meyakinkan pengguna untuk mengunjungi? Cara yang mungkin adalah dengan menggunakan warna tautan. Seperti yang Anda ketahui, jika Anda mengikuti satu tautan sekali, maka di lain waktu tautan itu muncul di peramban Anda dengan warna berbeda, yang menunjukkan bahwa Anda telah melakukan transisi ke tautan ini. Ini sebenarnya adalah kerentanan keamanan.

Karena ini berarti bahwa di situs Anda, penyerang dapat menghasilkan daftar besar kemungkinan URL yang dapat Anda kunjungi, dan kemudian menggunakan JavaScript untuk melihat warna apa yang diperoleh URL ini. Dan jika warna tautan URL berwarna ungu, itu berarti Anda mengunjungi situs ini. Jadi ini adalah trik yang cukup halus.

Yang menarik adalah bahwa dalam banyak kasus Anda bahkan tidak perlu menampilkan URL. Anda dapat mengatur tautan dalam bentuk judul di layar sesuai dengan jenis domino, dan header ini akan berubah warna jika pengguna menggunakan tautan ini. Mungkin Anda akan berpikir terlalu membosankan untuk menjelajah semua URL situs yang dikunjungi oleh pengguna ini? Tetapi proses ini dapat dioptimalkan dengan menggunakan beberapa bagian yang disaring melalui daftar alamat. Misalnya, Anda dapat melihat terlebih dahulu apakah pengguna telah mengunjungi URL tingkat atas - cnn.com, Facebook.com, dan seterusnya dan seterusnya. Jika jawabannya ya, Anda dapat memilih halaman tingkat atas yang paling banyak dikunjungi. Dengan begitu Anda benar-benar dapat membatasi pencarian Anda.

Jadi fungsi tidak berbahaya yang didukung browser untuk membantu pengguna, mengatakan: "Hei, sobat, ini adalah tujuan Anda!" Dapat digunakan oleh penyerang sebagai bukti kompromi pada Anda.



Bagaimana saya bisa mencegah serangan saluran Terselubung? Dalam praktiknya, hal ini dilakukan agar browser cukup membodohi JavaScript tentang warna tautan yang benar. JavaScript , , . , . , , JavaScript , . , , ? , .

, , — . – , .

, , . , , .



, — , , , , , . , , , , . ?

, . . , .

, Google Map Tiles. , «» Google Map, , , , . .

? , . , , , . , .

, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .



: JavaScript .

: , !

: , , , , ?

: , . , — - , , , - URL. , API– , .

: - , , ?
: . , API — . , ? , DNS , .

, , IP — ? ! , JavaScript . . , , ! .

, URL-, .

       <iframe>,    , ,   , , , ,    ,        <iframe>.     <iframe> ,   ,   <iframe>      .       ,    origin,        . 

Dengan demikian, penyerang tidak dapat lagi menyentuh apa pun dan menyimpulkan bahwa ia dapat menentukan situs yang Anda kunjungi sebelumnya.

Sampai jumpa di kuliah berikutnya!


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?