Kursus MIT "Keamanan Sistem Komputer". Kuliah 8: Model Keamanan Jaringan, Bagian 2

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

Jadi apa yang terjadi jika browser tidak memproses objek dengan benar dan tidak dapat mengidentifikasi tipenya? Dalam hal ini, Anda mungkin memiliki masalah keamanan. Salah satunya disebut serangan MIME.

Anda mungkin akrab dengan MIME - ini adalah jenis tajuk yang tidak terenkripsi seperti teks / html, image.jpeg dan sebagainya. Jadi, versi lama dari browser IE menggunakan ini karena mereka pikir itu akan membantu pengguna. Tetapi kadang-kadang terjadi bahwa server web memberikan ekstensi yang salah ke file objek.

Server web yang dikonfigurasi secara tidak benar dapat melampirkan akhiran .html ke ekstensi yang sebenarnya .jpeg, atau sebaliknya, misalnya, buat foo.jpg alih-alih foo.html.



Jadi, di masa lalu, IE berusaha membantu Anda. Artinya, dia pergi untuk mengambil beberapa jenis sumber daya, sambil berpikir: "Oke, sumber daya ini mengklaim jenis ini, sesuai dengan ekstensi nama file-nya." Tapi kemudian dia hanya akan melihat 256 byte pertama yang tersedia di objek ini. Dan jika dia menemukan makna magis tertentu di sana yang menunjukkan bahwa ada jenis ekstensi yang berbeda untuk objek ini, dia hanya akan mengatakan: "Hei, aku menemukan sesuatu yang keren di sini! "Saya pikir server web salah mendefinisikan objek ini, jadi izinkan saya memperlakukan objek ini sebagai tipe yang saya temukan dalam 256 byte pertama ini."
Dan kemudian semua orang menjadi pemenang, karena browser seperti membantu pengembang server web, karena sekarang situs mereka akan ditampilkan dengan benar. Dan pengguna akan menyukainya, karena mereka akan dapat membuka konten ini, yang dulunya hanya sampah.

Tetapi ini adalah kerentanan yang jelas! Misalkan halaman berisi beberapa konten pasif, misalnya, gambar dari domain yang dikendalikan oleh penyerang. Namun, halaman korban berpikir: "meskipun itu adalah konten situs peretas jahat, itu hanya konten pasif. Dia tidak bisa melakukan apa pun padaku! " Dalam kasus ekstrim, gambar yang gagal akan ditampilkan, tetapi tidak akan dapat membuka kode apa pun, karena konten pasif tidak memiliki hak istimewa.



Tetapi kenyataannya adalah bahwa IE pertama dapat "mengendus" gambar ini, 256 byte pertama. Dan seorang penyerang dapat dengan sengaja meletakkan kode HTML dan JavaScript di sana. Kemudian ternyata situs korban akan membawa apa yang dianggapnya gambar, dan IE akan mengeksekusi kode berbahaya dalam konteks halaman yang disematkan.

Ini adalah semacam contoh bagaimana browser yang kompleks dan bagaimana menambahkan niat yang sangat baik dapat menyebabkan kesalahan keamanan yang sangat halus. Jadi mari kita lihat lebih dekat bagaimana browser melindungi berbagai sumber daya.

Mari kita lihat frame dan objek jendela (objek yang merupakan jendela yang berisi dokumen DOM). Frame mewakili alam semesta JavaScript independen yang kita bicarakan di sini. Maksud saya, JavaScript adalah turunan dari simpul DOM, seperti yang ditunjukkan pada gambar pohon DOM.

Dengan begitu, frame akan ada sebagai objek simpul DOM di suatu tempat dalam hierarki ini yang terlihat oleh JavaScript.

Dalam JavaScript, objek jendela sebenarnya adalah alias untuk namespace global. Kedengarannya seperti ide yang bodoh. Artinya, jika Anda menemukan nama variabel global x, Anda juga akan dapat mengaksesnya melalui nama window.x.

Dengan demikian, bingkai dan objek jendela adalah referensi yang sangat kuat untuk memberi Anda aksesibilitas. Dan mereka mengandung pointer satu sama lain. Bingkai dapat berisi pointer ke objek jendela yang ditautkan dan sebaliknya. Padahal, kedua hal ini setara.
Baik frame dan objek window menerima sumber asal dari frame URL, atau karena mereka selalu berada di bagian aman dari jaringan, mereka bisa mendapatkan akhiran dari nama domain asli, yaitu asal aslinya.

Sebagai contoh, sebuah frame dapat dimulai seperti ini: .xyzcom, di sini Anda dapat mengabaikan skema dan protokol untuk sesaat.

Dalam hal ini, kita dapat mengasumsikan bahwa sumber asal untuk (document.domain) adalah sufiks yzcom. Demikian pula, sumber asal dokumen ini adalah ungkapan z.com. Ini dimungkinkan karena z.com adalah akhiran dari yzcom.



Satu-satunya hal yang tidak dapat berfungsi sebagai sumber seperti itu adalah ekspresi .ayzcom, karena itu adalah sufiks yang salah untuk sumber asal. Juga, akhiran sumber yang benar dari sumber asal tidak dapat dianggap hanya .com, karena dalam hal ini situs akan dapat mempengaruhi cookie atau sesuatu yang serupa di situs seperti .com, yang dapat memiliki konsekuensi yang agak merusak.

Motivasi mengapa hal-hal semacam ini dapat diterima adalah bahwa hal itu terkait dengan beberapa jenis hubungan saling percaya yang ada. Jadi sepertinya dengan tiga parameter teratas semuanya beres, dan gangguan hanya di .com.

Hadirin: Ternyata mungkin untuk membuat perpecahan seperti itu di titik mana pun atau di titik akhir? Misalnya, dapatkah xyzcom Anda diubah menjadi z.com?

Profesor: tidak, ini hanya berlaku untuk setiap poin.



Hadirin: apakah ada alasan mengapa hal itu tidak dilakukan sehingga Anda dapat menunjukkan super atau subdomain, tetapi pada saat yang sama mereka harus entah bagaimana sepakat dari mana informasi itu berasal? Katakanlah saya ingin menerima hanya yang memiliki asal yang sama dengan saya, sehingga semua sumber daya ini dapat menyerang saya. Selain itu, kami akan membuat interaksi ini simetris, sehingga saya juga bisa mempengaruhinya. Lagi pula, akhiran sumber .com berarti bahwa apa pun yang memiliki akhiran .com yang sama dapat mempengaruhi saya.

Profesor: ya, ini sulit, jadi ada beberapa jawaban untuk pertanyaan ini. Pertama, orang-orang sangat khawatir tentang kemungkinan serangan dengan .com. Oleh karena itu, mereka ingin membuat bahasa manipulasi domain mudah dimengerti. Dengan demikian, mereka tidak mengizinkan merusak pengaturan.

Sebentar lagi saya akan berbicara tentang satu hal yang memungkinkan Anda melakukan apa yang Anda bicarakan, tetapi hanya menyangkut sufiks domain. Untuk saat ini, saya ingin mencatat bahwa antarmuka Posting Pesan memungkinkan domain untuk berkomunikasi satu sama lain jika mereka menyetujui hal ini. Jadi dalam praktiknya, orang menggunakan Pesan Pos untuk menerapkan komunikasi lintas domain jika mereka tidak dapat menemukan sumber asal yang sama menggunakan trik yang dijelaskan di atas. Dengan cara ini, browser dapat membatasi domain sesuai dengan akhiran dari domain sumber ini. Dan di sini ada juga sedikit nuansa menarik - browser mengerti kapan (document.domain) dapat ditulis, dan kapan tidak bisa.

Ada alasan untuk ini, yang akan kita pertimbangkan sebentar lagi. Dengan demikian, dua frame dapat saling mengakses jika setidaknya satu dari dua kondisi berikut ini benar:

• kedua set frame mengatur (document.domain) nilai yang sama;
• tak satu pun dari frame ini dapat berubah (document.domain), terlepas dari kenyataan bahwa nilai dokumen ini di kedua frame adalah sama.

Gagasan utama dari aturan ini adalah mereka melindungi domain dari serangan yang disebabkan oleh kesalahan mereka sendiri atau bahaya dari salah satu subdomain.

Bayangkan Anda memiliki domain xyzcom yang mencoba menyerang domain yzcom karena domain pertama berisi kesalahan atau berbahaya. Dia akan mencoba memperpendek domain yzcom ke tampilan .com, dan kemudian mulai "membersihkan" dengan status JavaScript, atau cookie, atau hal-hal lain.



Jadi, kedua aturan ini berarti bahwa jika yzcom tidak ingin mengizinkan siapa pun berinteraksi dengannya, maka itu tidak akan pernah mengubah nilai (document.domain). Jadi ketika frame xyzcom ingin memendekkannya, browser akan mengatakan: "Ya, Anda ingin memendekkannya, tetapi Anda tidak punya hak untuk melakukannya!" Ada kebetulan nilai, tetapi domain yzcom belum mengindikasikan bahwa ia ingin berpartisipasi dalam hal ini. Apakah itu jelas? Dalam hal ini, dapat dilihat bahwa sebagian besar frame bekerja dengan kebijakan asal yang sama.

Sekarang kita bisa melihat bagaimana simpul DOM kami diproses. Ini sangat sederhana. Biasanya, simpul DOM mendapatkan asal dari bingkai sekitarnya. Dalam hal cookie, ini agak lebih rumit. Cookie memiliki domain dan mereka memiliki caranya sendiri. Misalnya, Anda dapat membayangkan bahwa cookie dapat dikaitkan dengan informasi berikut, misalnya * .mit.edu / 6.858. Dalam hal ini, cookie memiliki * .mit.edu / domain dan jalur 6.858.



Harap perhatikan bahwa domain ini mungkin suffix lengkap dari halaman di domain saat ini. Jadi Anda bisa melakukan trik yang sama dengannya seperti yang kita bicarakan sebelumnya. Perhatikan bahwa jalur ini 6.858 juga dapat direpresentasikan sebagai garis miring, diikuti oleh nol, yang menunjukkan bahwa semua jalur domain harus memiliki akses ke cookie yang terletak di sini.

Namun dalam kasus ini, kami memiliki alamat jalur tertentu. Jadi, siapa pun yang mengatur cookie ini, ia mendapat kesempatan untuk melihat seperti apa domain dan path itu. Dan nilai-nilai ini dapat diatur baik di sisi server dan di sisi klien. Di sisi klien, Anda akan memiliki objek JavaScript bernama document.cookie. Ini adalah format yang digunakan untuk menunjukkan semua jalur ke objek yang serupa.

Ada bendera keamanan bendera Aman yang dapat Anda atur pada cookie untuk menunjukkan bahwa itu adalah file HTTPS. Dalam hal ini, konten HTTP tidak boleh memiliki akses ke cookie ini. Ini adalah ide utama cookie.

Harap perhatikan bahwa setiap kali browser membuat permintaan ke server web tertentu, ia akan menyertakan semua cookie yang relevan dalam permintaan ini. Ada semacam garis korespondensi dan algoritma yang memungkinkan untuk mengetahui bahwa ini adalah cookie yang benar yang harus dikirim dalam menanggapi permintaan, karena mereka mungkin memiliki hal-hal aneh dengan akhiran domain, dan sebagainya.

Hadirin: jadi bisakah bingkai mengakses cookie satu sama lain jika mereka mematuhi aturan ini?

Profesor: ya, frame bisa melakukan ini. Tapi itu tergantung pada bagaimana document.domain diatur, cookie domain dan path. Jadi, frame dapat mengakses cookie satu sama lain, maka timbul pertanyaan: dapatkah ada masalah jika kita mengizinkan frame sewenang-wenang untuk menulis cookie sewenang-wenang kepada orang-orang? Cukuplah untuk mengatakan bahwa itu akan buruk. Alasan mengapa ini buruk adalah karena cookie ini memungkinkan sisi klien dari aplikasi untuk menyimpan data pengguna.

Jadi Anda dapat membayangkan bahwa jika seorang penyerang dapat mengontrol atau mendefinisikan kembali cookie pengguna, ia dapat, misalnya, mengubah cookie untuk Gmail sehingga pengguna masuk melalui akun Gmail milik penyerang ini. Dalam hal ini, setiap huruf pengguna dapat dibaca oleh penyerang. Anda dapat membayangkan bahwa seseorang akan dapat memperoleh cookie dari Amazon.com untuk memasukkan semua jenis pembelian konyol dan sejenisnya ke keranjang Anda.

Dengan demikian, cookie adalah sumber daya yang sangat penting untuk perlindungan. Dan banyak serangan keamanan jaringan dirancang untuk mencuri dan menggunakannya untuk membahayakan.
Ada pertanyaan menarik lainnya terkait cookie. Misalkan Anda memiliki situs foo.co.uk. Bagaimana jika situs dengan nama inang ini dapat mengatur cookie untuk co.uk?



Ada kehalusan di sini terkait dengan aturan yang kita bahas sebelumnya, karena situs pertama harus dapat mempersingkat domainnya dan mengatur cookie untuk yang kedua, semuanya tampak sah di sini. Tetapi dari sudut pandang manusia, kita melihatnya dengan curiga, karena kita mengerti bahwa co.uk adalah domain atom tunggal. Namun, ini setara dengan .com. Kita dapat mengatakan bahwa Inggris mengacau bahwa mereka seharusnya ada benarnya di sini. Tapi itu bukan kesalahan mereka. Dari sudut pandang moral, ini adalah satu domain tunggal yang tidak dapat dilanggar. Karena itu, kita harus memiliki beberapa infrastruktur khusus agar cookie dapat berfungsi dengan baik.

Mozilla memiliki situs web yang disebut publicsuffix.org yang berisi daftar aturan tentang bagaimana cookie, asal dan domain harus dipersingkat, dengan mempertimbangkan bahwa mungkin ada titik-titik dalam beberapa hal, sementara pada kenyataannya mereka harus dianggap sebagai atom tunggal keseluruhan.

Jadi ketika browser Anda mengetahui bagaimana seharusnya memanipulasi cookie yang berbeda, maka ia harus memeriksa sisi masalah ini. Atau entah bagaimana memastikan bahwa foo.co.uk tidak dapat mempersingkat domain menjadi co.uk. Jadi ada masalah yang sangat sensitif di sini.

Ada banyak masalah keamanan web yang menarik yang kami temukan dalam proses ini, karena banyak infrastruktur asli dikembangkan khusus untuk bahasa Inggris. Misalnya, teks ASCII atau semacamnya. Awalnya tidak dirancang untuk digunakan oleh komunitas internasional.

Tetapi ketika Internet menjadi lebih populer, orang-orang mulai berkata: "hei, pada awalnya kami menciptakan desain solusi yang agak besar dan sekarang kami harus membuatnya cocok untuk orang-orang yang terpaksa menggunakan pemahaman sempit kami tentang apa arti bahasa." Karena itu, kita sekarang menghadapi semua masalah gila ini.

Pertimbangkan bagaimana respons HTTP XML ditangani oleh kebijakan sumber asal yang sama. Secara default, JavaScript hanya dapat membuat salah satunya jika dibangun di server asalnya. Namun, ada antarmuka baru yang disebut Cross Origin Request, atau CORS.

Jadi, ini adalah asal yang sama, kecuali server telah mengaktifkan alat CORS ini. Pada dasarnya, header respons HTTP baru ditambahkan yang disebut Access-Control-Allow-Origin.



Katakanlah JavaScript dari foo.com ingin membuat permintaan HTTP HTTP ke bar.com. Seperti yang dijelaskan dalam aturan, lintas asal terjadi di sini. Dan jika server bar.com ingin mengizinkan ini, ia akan mengembalikan respons HTTP-nya dengan tajuk utama: "ya, saya membiarkan foo.com mengirimi saya permintaan XML XML lintas-asal ini."

Sebenarnya, server bar.com dapat menjawab "tidak", artinya, ia dapat menolak permintaan tersebut. Dalam hal ini, browser tidak dapat menyelesaikan permintaan HTTP XML. Jadi ini adalah semacam hal baru, yang muncul sebagian besar karena aplikasi campuran. Ini diperlukan untuk aplikasi dari pengembang yang berbeda dan domain yang berbeda, sehingga mereka memiliki kesempatan untuk saling bertukar data.



Jadi, alih-alih foo.com, mungkin ada tanda bintang di sini jika seseorang ingin mendapatkan data lintas asal, dan sebagainya. Saya pikir ini cukup sederhana. Ada banyak sumber daya lain yang bisa kita lihat, seperti gambar. Berkat Access-Control-Allow-Origin, bingkai dapat memuat gambar dari sumber apa pun yang diinginkan. Tetapi dia tidak dapat memeriksa bit dari gambar ini, karena diyakini bahwa dengan kebijakan yang berbeda dari sumber asal tidak baik untuk memeriksa konten file masing-masing.

Meskipun bingkai tidak dapat memeriksa bit, masih dapat menyimpulkan ukuran gambar karena melihat bagaimana mereka ditempatkan pada halaman. Jadi ini adalah salah satu dari kasus aneh ini ketika sumber kebijakan asal yang sama diduga berusaha mencegah semua kebocoran informasi. Tetapi pada kenyataannya, itu tidak dapat mencegah semua ini, karena menanamkan warisan, pada kenyataannya, menunjukkan beberapa jenis informasi.

CSS mirip dengan gambar, sehingga bingkai dapat menanamkan CSS dari sumber apa pun. Namun, itu tidak dapat secara langsung memeriksa teks di dalam file CSS jika berasal dari sumber lain. Tapi dia bisa mengenali apa yang dilakukan CSS ini karena dia hanya menciptakan banyak node dan kemudian menyaksikan bagaimana gaya mereka berubah. Dan itu terlihat sedikit aneh.

JavaScript adalah contoh favorit saya tentang bagaimana kebijakan asal yang sama ini mencoba untuk mendukung semua jenis urutan pintar. Idenya di sini adalah bahwa jika Anda mengambil lintas JavaScript, maka ini diizinkan. Anda dapat mengaktifkan eksekusi JavaScript eksternal dalam konteks halaman Anda sendiri, tetapi Anda tidak dapat melihat kode sumbernya.



Oleh karena itu, jika Anda memiliki sumber tag skrip yang setara dengan sesuatu di luar domain Anda, maka ketika sumber ini dijalankan, Anda dapat memulai fungsi di dalamnya. Tetapi Anda tidak akan dapat melihat kode sumber JavaScript di dalamnya.

Semua ini terlihat sangat bagus, tetapi memiliki banyak "lubang". Misalnya, JavaScript adalah bahasa skrip dinamis. Dan fungsi adalah objek kelas satu. Jadi, untuk fungsi apa pun f, Anda cukup menggunakan fungsi f.tostring (), dan ini akan memberi Anda kode sumber untuk fungsi f. Dan orang melakukan ini sepanjang waktu, mereka melakukan penulisan ulang yang dinamis dan sejenisnya.



Dengan demikian, meskipun kebijakan asal tidak memungkinkan Anda untuk langsung melihat konten tag skrip, Anda cukup melakukan operasi yang ditentukan dan mendapatkan kode sumber.

Demikian pula, Anda bisa mendapatkan server rumah Anda dari domain Anda, hanya untuk mendapatkan kode sumber di atasnya dan kemudian mengirimkannya kembali kepada Anda. Faktanya, Anda baru saja meminta server rumah Anda untuk menjalankan program Wget untuk mendapatkan kode sumber dengan cara ini. Jadi juga terlihat sedikit konyol, yaitu, kebijakan asal di sini agak aneh.

Pemirsa: Misalkan alasan mereka melakukan ini adalah untuk mencegah pengguna menerima JavaScript, karena cookie juga dapat dikirim. Artinya, pengguna akan dapat menyesuaikan JavaScript yang dihasilkan dengan kebutuhannya.

Profesor: ya, benar.

Pemirsa: jadi jika Anda membuat server Anda melakukan ini, itu tidak akan dapat memberi Anda cookie khusus.

Profesor: ini benar, meskipun dalam praktiknya kode sumber "mentah" tidak dimaksudkan untuk dikerjakan ulang oleh pengguna. Tetapi Anda benar bahwa ini akan mencegah beberapa serangan.

, , JavaScript, . , - , -, , . , , , . , , .

, . - - , - HTML JavaScript. , , . .

, JavaScript, , . Java, .



, HTML5 , , , , Java. , .

, HTTP, cookie. , URL, ?



, URL- bank.com. , - . , URL, , , $500 . , .

— , origin, bank.com - , , cookie . : «, , , $500 attacker! , ».
. , , , , . . , , , , - . , , CSRF.

, URL. , c .

, - . – , , :

<form action = “/transfer.cdi”…> 

Dan di dalam formulir ini, kita akan memiliki data input, yang biasanya digunakan untuk memasukkan teks, penekanan tombol, klik mouse, dan sejenisnya. Faktanya, kita dapat membuat input ini disembunyikan sehingga tidak muncul di halaman pengguna: tipe input = "tersembunyi", berikan nama atribut = "csrf" dan nilai nilai acak = "a72f ...". Formulir ini akan dibuat di server.



Jadi, ketika pengguna pergi ke halaman ini, di sisi server, server menghasilkan nilai keacakan ini = "a72f ..." dan menanamkannya dalam HTML yang diterima pengguna. Karena itu, ketika pengguna mengisi formulir ini, maka URL formulir ini:

bank.com/xfer?amount=500&to=attacker

Ini dilengkapi dengan token acak:

 http://bank.com/xfer?amount=500&to=attacker/&csrf=a72f... 

Ini berarti bahwa sekarang penyerang harus dapat menebak token spesifik yang dihasilkan server untuk pengguna setiap kali ia pergi ke halaman bank. Jadi jika kita memiliki nilai acak yang cukup, maka peretas tidak akan bisa memalsukan apa pun, karena jika dia menunjukkan token yang salah, maka aturan server akan menolak permintaannya.

58:00 mnt

Kelanjutan:

Kursus MIT "Keamanan Sistem Komputer". Kuliah 8: Model Keamanan Jaringan, Bagian 3


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?