Kursus MIT "Keamanan Sistem Komputer". Kuliah 9: "Keamanan Aplikasi Web," 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
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3

Misalnya, Django akan mengambil kurung sudut ini, menerjemahkannya ke dalam bentuk HTML, dan mengulangi sisa karakter. Artinya, jika nilai nama khusus berisi tanda kurung sudut, tanda kutip ganda, dan sejenisnya, semua karakter ini akan dikecualikan. Itu akan membuat konten tidak ditafsirkan sebagai kode HTML di sisi browser klien.



Jadi sekarang kita tahu bahwa ini bukan pertahanan yang sangat andal terhadap beberapa serangan skrip lintas situs. Alasannya, seperti yang kami tunjukkan dalam contoh, adalah bahwa tata bahasa untuk HTML, dan CSS dan JavaScript ini sangat rumit sehingga mereka dapat dengan mudah membingungkan pengurai peramban.

Sebagai contoh, kami memiliki hal yang sangat umum dilakukan dalam kerangka kerja Django. Jadi, Anda memiliki beberapa fungsi div, dan kami ingin menetapkan kelas dinamis untuknya. Kami memberikan kelas nilai var, dan sebagainya dan sebagainya. Idenya adalah bahwa ketika Django memproses ini, ia perlu mencari tahu apa gaya saat ini dan kemudian menempelkannya di sini.

Dalam hal ini, penyerang dapat membuat string yang mendefinisikan kelas ini, misalnya, menulis "kelas 1". Semuanya berjalan dengan baik hingga titik ini, karena sepertinya ekspresi CSS yang valid.

Tetapi kemudian penyerang menempatkan operator onclick di sini, yang sama dengan kode JavaScript yang membuat panggilan sistem.



Karena ini salah, browser harus berhenti di sini. Tetapi masalahnya adalah jika Anda pernah melihat HTML dari halaman web asli, semuanya rusak dan bingung, bahkan untuk situs yang "ramah". Jadi, jika browser berhenti sebelum setiap ekspresi HTML yang salah, tidak satu situs pun yang Anda sukai tidak akan pernah berfungsi. Jika Anda ingin kecewa di dunia, dan saya belum cukup membantu Anda, cukup buka konsol JavaScript di browser Anda saat melihat situs untuk melihat berapa banyak kesalahan yang akan Anda berikan.

Misalnya, Anda dapat membuka CNN dan melihat berapa banyak kesalahan yang Anda dapatkan. Ya, pada dasarnya CNN berfungsi, tetapi sangat tidak merata. Misalnya, untuk membuka Acrobat reader, Anda harus terus-menerus membuang pengecualian null pointer, dan pada saat yang sama Anda akan merasa sedikit tertipu oleh kehidupan. Tetapi di Internet, kami telah belajar untuk menerima ini tanpa banyak kemarahan.
Karena itu, karena browser harus sangat toleran terhadap hal-hal seperti itu, mereka akan mencoba mengubah kode berbahaya menjadi sesuatu yang tampaknya masuk akal bagi mereka. Dan itu adalah kerentanan keamanan.

Begitulah cara desinfeksi konten bekerja, dan itu masih lebih baik daripada tidak sama sekali. Dia bisa menangkap banyak hal berbahaya, tetapi tidak bisa membela diri dari segalanya.

Ada satu hal lagi yang perlu dipikirkan - penggunaan bahasa markup yang kurang ekspresif. Mari kita lihat apa yang dimaksud.

Pemirsa: apa yang harus saya lakukan jika pembersihan konten tidak berfungsi?

Profesor: ya, ini mungkin, misalnya, dalam hal ini Django tidak akan dapat secara statis menentukan bahwa itu buruk. Misalnya, dalam kasus khusus ini. Tetapi dalam kasus ketika saya memasukkan tag gambar berbahaya ...

Hadirin: dalam kasus khusus ini, saya berharap tugas kelas berada dalam tanda kutip dan dalam hal ini seharusnya tidak memiliki efek apa pun ...

Profesor: Anda tahu, ada trik-trik kecil. Dengan asumsi bahwa tata bahasa HTML dan CSS didefinisikan dengan hati-hati, Anda dapat membayangkan sebuah dunia di mana pengurai ideal dapat menangkap masalah ini atau mengubahnya menjadi hal-hal normal. Tetapi pada kenyataannya, tata bahasa HTML dan tata bahasa CSS menderita ketidakakuratan. Selain itu, browser tidak menerapkan spesifikasi. Karena itu, jika Anda menggunakan tata bahasa yang kurang ekspresif, akan jauh lebih mudah bagi kami untuk membersihkan konten.

Di sini istilah Markdown digunakan - "markup mudah dibaca" bukan istilah Markup - markup biasa. Gagasan utama Markdown adalah bahwa itu dirancang sebagai bahasa yang, misalnya, memungkinkan pengguna untuk mengirim komentar, tetapi tidak mengandung kemampuan untuk menggunakan tag kosong, dukungan applet, dan sejenisnya. Oleh karena itu, dalam Markdown sebenarnya jauh lebih mudah untuk mengidentifikasi tata bahasa secara unik dan kemudian hanya menerapkannya.



Disinfeksi jauh lebih mudah dalam bahasa sederhana daripada HTML, CSS, dan JavaScript lengkap. Dan sedikit banyak, ini seperti perbedaan antara memahami kode C dan kode Python. Benar-benar ada perbedaan besar dalam memahami bahasa yang lebih ekspresif. Karena itu, dengan membatasi ekspresivitas, Anda sering meningkatkan keselamatan.

Untuk melindungi dari serangan skrip lintas situs, CSP, Kebijakan Keamanan Konten, juga digunakan. Gagasan CSP adalah memungkinkan server web ...
Hadirin: Saya hanya ingin tahu tentang bahasa Markdown ini. Apakah semua browser dapat melakukan parsing bahasa?

Profesor: tidak, tidak, tidak. Anda cukup mengonversi berbagai jenis bahasa ke dalam HTML, tetapi browser tidak memahaminya dalam bentuk aslinya. Dengan kata lain, Anda memiliki sistem komentar, dan menggunakan Markdown. Yaitu, komentar, sebelum ditampilkan pada halaman, pergi ke kompiler Markdown, yang menerjemahkannya ke dalam format HTML.

Hadirin: jadi mengapa tidak selalu menggunakan Markdown?

Profesor: Penurunan harga memungkinkan Anda untuk menggunakan HTML yang disematkan, dan sejauh yang saya tahu, ada cara untuk menonaktifkannya di kompiler. Tapi saya bisa salah tentang itu. Faktanya adalah bahwa tidak selalu mungkin untuk menggunakan bahasa yang terbatas, dan tidak semua orang ingin melakukan itu.

Jadi, mari kita lanjutkan diskusi tentang cara meningkatkan keamanan dengan bantuan Kebijakan Keamanan Konten. Kebijakan ini memungkinkan server untuk memberi tahu peramban web jenis konten apa yang dapat dimuat pada halaman yang dikirimkannya kembali, serta dari mana konten ini berasal.

Misalnya, dalam respons HTTP, server dapat menggunakan sesuatu seperti ini: termasuk header Content - Security - Policy, sumber default adalah self dan akan menerima data dari * .mydomain.com.



Dengan operator sendiri, server menunjukkan bahwa konten dari situs ini hanya berasal dari domain halaman tertentu atau subdomain dari mydomain.com. Ini berarti bahwa jika kami memiliki ikatan sendiri ke foo.com, server akan mengirim halaman ini kembali ke browser.

Misalkan serangan skrip lintas situs mencoba membuat tautan ke bar.com. Dalam hal ini, browser akan melihat bahwa bar.com bukan milik sendiri dan bukan domain dari mydomain.com, dan tidak akan melewatkan permintaan ini lebih lanjut. Ini adalah mekanisme yang sangat kuat di mana Anda dapat menentukan kontrol yang lebih detail. Anda menetapkan parameter yang menunjukkan bahwa gambar Anda harus berasal dari sumber ini dan itu, skrip dari ini dan itu dan seterusnya. Ini sebenarnya nyaman.

Selain itu, kebijakan ini sebenarnya mencegah JavaScript yang disematkan, jadi Anda tidak dapat membuka tag, menulis semacam skrip, dan menutup tag, karena semua yang dapat masuk ke browser harus berasal hanya dari sumber bersyarat. CSP mencegah hal-hal berbahaya seperti menggunakan argumen ke fungsi eval (), yang memungkinkan halaman web untuk mengeksekusi kode JavaScript yang dihasilkan secara dinamis. Jadi jika header CSP diatur, browser tidak akan menjalankan eval ().

Hadirin: Apakah semua CSP melindungi dari?

Profesor: tidak. Ada seluruh daftar sumber daya yang sebenarnya dilindungi, dan Anda dapat mengonfigurasi perlindungan terhadap banyak hal yang tidak diinginkan, misalnya, tentukan di mana ia diizinkan untuk menerima CSS keluar dan banyak hal lainnya.

Hadirin: Tetapi selain eval () ada hal lain yang mengancam keamanan?

Profesor: ya, mereka ada. Karena itu, pertanyaan selalu muncul dari kelengkapan perlindungan. Jadi, misalnya, tidak hanya eval yang dapat secara dinamis menghasilkan kode JavaScript. Ada juga konstruktor fungsi, ada cara tertentu untuk memanggil batas waktu yang diberikan, Anda pergi ke garis dan Anda dapat menganalisis kode dengan cara ini. CSP dapat menonaktifkan semua vektor serangan berbahaya ini. Tapi ini bukan obat mujarab untuk isolasi lengkap dari eksploitasi berbahaya.

Audiens: Benarkah CSP dapat dikonfigurasi untuk mencegah semua skrip internal diperiksa pada halaman?

Profesor: ya, ini membantu mencegah eksekusi kode yang dihasilkan secara dinamis, sementara kode yang disematkan harus diabaikan. Browser harus selalu mendapatkan kode dari atribut sumber. Sebenarnya, saya tidak tahu apakah semua browser melakukan ini. Pengalaman pribadi menunjukkan bahwa browser menunjukkan perilaku yang berbeda.

Secara umum, keamanan internet mirip dengan ilmu alam, sehingga orang hanya mengemukakan teori tentang cara kerja browser. Dan kemudian Anda melihat bagaimana ini sebenarnya terjadi. Dan gambaran yang sebenarnya mungkin mengecewakan, karena kita diajarkan bahwa ada algoritma, bukti, dan sejenisnya. Tetapi browser ini berperilaku sangat buruk sehingga hasil pekerjaan mereka tidak dapat diprediksi.

Pengembang peramban mencoba untuk menjadi selangkah lebih maju dari penyerang, dan lebih jauh dalam ceramah Anda akan melihat contohnya. Padahal, CSP adalah hal yang cukup keren.

Hal lain yang bermanfaat adalah bahwa server dapat mengatur header HTTP yang disebut X-Content-Type-Options, yang nilainya nosniff.



Header ini mencegah MIME dari membuang respon dari tipe konten yang diiklankan, karena header memberitahu browser untuk tidak mengesampingkan tipe konten respon. Dengan opsi nosniff, jika server mengatakan kontennya adalah teks / html, browser akan menampilkannya sebagai teks / html.
Sederhananya, tajuk ini mencegah browser dari "mengendus" respons dari tipe konten yang dideklarasikan sehingga situasi tidak terjadi ketika browser mengatakan: "yeah, saya mengendus ketidakcocokan antara ekstensi file dan konten yang sebenarnya, jadi saya akan mengubah konten ini menjadi beberapa yang bisa dimengerti lainnya saya sesuatu. " Ternyata Anda tiba-tiba memberi orang-orang barbar kunci-kunci kerajaan.

Karenanya, dengan mengatur tajuk ini, Anda memberi tahu peramban untuk tidak melakukan hal seperti ini. Ini dapat sangat mengurangi efek dari jenis serangan tertentu. Berikut ini adalah ikhtisar singkat dari beberapa kerentanan untuk serangan skrip lintas situs.

Sekarang mari kita lihat vektor serangan populer lainnya - SQL. Anda mungkin pernah mendengar tentang serangan yang disebut "injeksi SQL," atau serangan injeksi SQL. Inti dari serangan ini adalah menggunakan database situs web. Untuk secara dinamis membangun halaman yang ditunjukkan kepada pengguna, permintaan basis data dikeluarkan yang dikeluarkan ke server internal ini. Bayangkan Anda memiliki permintaan untuk memilih semua nilai dari tabel tertentu, di mana bidang ID Pengguna sama dengan apa yang ditentukan di Internet dari sumber yang berpotensi tidak dapat diandalkan.



Kita semua tahu bagaimana cerita ini akan berakhir - itu akan berakhir dengan sangat buruk, tidak akan ada yang selamat. Karena apa yang berasal dari sumber yang tidak diverifikasi dapat melakukan banyak masalah. Atau, Anda dapat memberikan string id pengguna nilai berikut: id pengguna = “0; HAPUS TABEL “.

Jadi apa yang akan terjadi di sini? Pada dasarnya, database server akan mengatakan: "OK, saya akan mengatur ID pengguna ke nol, dan kemudian saya akan menjalankan perintah" delete table "." Dan itu saja, Anda sudah selesai!

Mereka mengatakan bahwa beberapa tahun yang lalu gambar virus tertentu muncul. Beberapa orang di Jerman memasang plat nomor pada mobil, di mana 0 ditulis; HAPUS TABEL. Idenya adalah bahwa kamera jalan menggunakan OCR untuk mengenali nomor Anda, dan kemudian memasukkan nomor itu ke dalam basis data. Secara umum, orang-orang Volkswagen memutuskan untuk mengeksploitasi kerentanan ini dengan menempatkan kode berbahaya pada jumlah mereka.

Saya tidak tahu apakah ini berhasil karena kedengarannya lucu. Tetapi saya ingin percaya bahwa ini benar. Jadi saya ulangi lagi - ide desinfeksi adalah untuk mencegah pelaksanaan konten dari sumber yang tidak terpercaya di situs Anda.



Karena itu, perhatikan fakta bahwa mungkin ada beberapa hal sederhana yang tidak berfungsi sebagaimana mestinya. Jadi, Anda mungkin berpikir: "baik, mengapa saya tidak bisa memberikan kutipan lain di awal baris dan satu lagi di akhir untuk mengecualikan eksekusi kode jahat dari penyerang yang terlampir di antara tiga tanda kutip"?

user id = '“+ user id +'“

Tapi ini tidak akan berhasil, karena penyerang selalu dapat dengan mudah meletakkan tanda kutip di dalam string yang menyerang. Jadi dalam kebanyakan kasus, "setengah peretasan" seperti itu tidak akan memberi Anda keamanan sebanyak yang Anda harapkan.

Solusinya di sini adalah Anda perlu mengenkripsi data dengan hati-hati. Dan sekali lagi saya ulangi bahwa ketika Anda menerima informasi dari sumber yang tidak dapat diandalkan, jangan masukkan ke dalam sistem di mana itu. Pastikan itu tidak dapat melompat keluar dari kotak pasir jika Anda menaruhnya di sana untuk melakukan exploit berbahaya.

Misalnya, Anda ingin menyisipkan fungsi pelarian untuk mencegah penggunaan operator koma mentah. Untuk melakukan ini, banyak kerangka kerja web, seperti Django, memiliki pustaka built-in yang memungkinkan Anda untuk menghindari permintaan SQL untuk mencegah hal-hal seperti itu terjadi. Kerangka kerja ini mendorong pengembang untuk tidak pernah berinteraksi langsung dengan database. Misalnya, Django sendiri menyediakan antarmuka tingkat tinggi yang mendisinfeksi Anda.

Tetapi orang-orang selalu peduli dengan kinerja, dan kadang-kadang orang berpikir bahwa kerangka kerja web ini terlalu lambat. Jadi, seperti yang akan Anda lihat segera, orang masih akan membuat query SQL mentah, yang dapat menyebabkan masalah.

Masalah dapat terjadi jika server web menerima nama jalur dari gambar yang tidak dipercaya. Bayangkan di suatu tempat di server Anda Anda melakukan sesuatu yang serupa: buka dengan "www / images /" + nama file, di mana nama file diwakili oleh sesuatu seperti ... / ... / ... / ... / dll / kata sandi.



Artinya, Anda memberi perintah untuk membuka gambar di alamat ini dari file pengguna yang tidak dipercaya, yang pada kenyataannya dapat membahayakan Anda. Jadi, jika Anda ingin menggunakan server web atau kerangka kerja web, Anda harus dapat mendeteksi karakter berbahaya ini dan menghindarinya untuk mencegah eksekusi perintah-perintah yang tidak ditangani ini.

Mari kita berhenti sejenak dari mendiskusikan desinfeksi konten dan berbicara sedikit tentang cookie. Cookie adalah cara yang sangat populer untuk mengelola sesi untuk mengikat pengguna ke kumpulan sumber daya tertentu yang ada di sisi server. Banyak kerangka kerja seperti Django atau Zoobar, yang akan Anda temui nanti, sebenarnya memasukkan pengidentifikasi sesi acak di dalam cookie. Idenya adalah bahwa id sesi ini adalah indeks dalam beberapa jenis tabel sisi-server:

tabel [ID sesi] = info pengguna.

Artinya, pengidentifikasi sesi sama dengan beberapa informasi pengguna. Akibatnya, ID sesi dan cookie ini adalah bagian yang sangat sensitif dalam ekstensi mereka. Banyak serangan termasuk pencurian cookie untuk mendapatkan ID sesi ini. Seperti yang telah kita bahas dalam kuliah terakhir kami, kebijakan yang sama dari sumber asal yang sama dapat membantu Anda, sampai batas tertentu, terhadap beberapa serangan pencurian cookie ini. Karena ada aturan berdasarkan kebijakan asal yang sama yang mencegah modifikasi cookie sewenang-wenang.

Kehalusannya adalah Anda tidak boleh berbagi domain atau subdomain dengan seseorang yang tidak Anda percayai. Karena, seperti yang kami katakan di kuliah terakhir, ada aturan yang memungkinkan dua domain atau subdomain dari asal yang sama untuk mengakses cookie masing-masing. Dan karena itu, jika Anda memercayai domain yang tidak seharusnya Anda percayai, itu mungkin dapat secara langsung mengatur pengidentifikasi sesi di cookie ini, yang Anda berdua memiliki aksesnya. Ini akan memungkinkan penyerang untuk memaksa pengguna untuk menggunakan pengidentifikasi sesi pilihan penyerang.



Misalkan penyerang membuat cookie pengguna Gmail. Seorang pengguna login ke Gmail dan mengetik beberapa huruf. Seorang penyerang kemudian dapat menggunakan cookie ini, khususnya, menggunakan pengidentifikasi sesi ini, mengunduh Gmail, dan kemudian mengakses Gmail seolah-olah ia akan menjadi pengguna korban. Dengan demikian, ada banyak seluk-beluk yang dapat Anda lakukan dengan cookie ini untuk mengelola sesi Anda. Kami akan membahas beberapa dari mereka hari ini dan dalam kuliah berikutnya.

Mungkin Anda pikir Anda bisa menyingkirkan cookie? Bagaimanapun, mereka membawa lebih banyak masalah daripada manfaat. Mengapa mereka tidak bisa ditinggalkan?

stateless cookie, « », - , , , .

, , , . , . , , . , , , , .

— MA — Message Authentication Codes, . , . HCK - m. , , K. , , . , , .



, . , stateless cookie, Amazon, , x3. - Amazon, AWS, . – K, – AWS, .



, AWS HTTP, .

, , , :

GET /photos/ cat; .jpg HTTP/1.1, - AWS:

HOST: — - — - — , , :

DATE: Mon, June 4, , , . , ID , , , .



? , 3- .

, String To Sign :

— HTTP, GET;
— MDS;
— , html jpg;
— ;
— , , .



, , HCK MAC. , . , . , . ?

, , , - . Amazon , stateless cookie, MD5 .

, , , cookie, . – , , .

, . , , “HCK, m”.



Di dunia biasa, cookie akan digunakan alih-alih otorisasi di sini. Tapi sekarang kita menyingkirkan mereka dan menyisipkan pesan teks yang jelas ini GET / foto / kucing ke dalam permintaan; .jpg HTTP / 1.1 dan enkripsi, yang memungkinkan server untuk mencari tahu dari siapa benda ini berasal. Dengan cara ini server tahu siapa pengguna itu karena itu tertanam dalam permintaan. Ini bukan rahasia, kan? Tetapi ini memungkinkan server untuk mengatakan: "Ya, saya tahu kunci rahasia apa yang seharusnya digunakan oleh pengguna ini untuk membuat permintaan ini, jika ini adalah pengguna yang sebenarnya."

56:15

Kursus MIT "Keamanan Sistem Komputer". Kuliah 9: Keamanan Aplikasi Web, 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?