Keamanan Web: Pengantar HTTP

HTTP adalah hal yang indah: protokol yang telah ada selama lebih dari 20 tahun tanpa banyak perubahan.



Ini adalah bagian kedua dari seri keamanan web: bagian satu adalah Bagaimana browser bekerja .

Seperti yang kita lihat di artikel sebelumnya, browser berinteraksi dengan aplikasi web menggunakan protokol HTTP, dan ini adalah alasan utama kami mempelajari topik ini. Jika pengguna memasukkan informasi kartu kredit mereka di situs web, dan penyerang dapat mencegat data sebelum mereka mencapai server, kami mungkin akan mengalami masalah.

Memahami cara kerja HTTP, bagaimana kami dapat mengamankan komunikasi antara klien dan server, dan fitur-fitur terkait keamanan apa yang ditawarkan protokol adalah langkah pertama menuju peningkatan keamanan kami.

Namun, ketika membahas HTTP, kita harus selalu membedakan antara semantik dan implementasi teknis, karena ini adalah dua aspek HTTP yang sama sekali berbeda.

Perbedaan utama di antara mereka dapat dijelaskan dengan analogi yang sangat sederhana: 20 tahun yang lalu, orang-orang menjaga kerabat mereka dengan cara yang sama seperti yang mereka lakukan sekarang, meskipun cara mereka berinteraksi telah berubah secara signifikan. Orang tua kita cenderung membawa mobil mereka dan pergi ke saudara perempuan mereka untuk mengejar ketinggalan dan menghabiskan waktu bersama keluarga mereka.

Sebaliknya, akhir-akhir ini, mereka paling sering mengirim pesan ke WhatsApp, melakukan panggilan telepon atau menggunakan grup di Facebook, yang sebelumnya tidak mungkin dilakukan. Ini tidak berarti bahwa orang berkomunikasi atau peduli kurang lebih, tetapi hanya karena interaksi mereka telah berubah.

HTTP tidak berbeda: semantik protokol tidak banyak berubah, sementara implementasi teknis dari interaksi klien dan server telah dioptimalkan selama bertahun-tahun. Jika Anda melihat permintaan HTTP 1996, itu akan sangat mirip dengan yang kita lihat di artikel sebelumnya, meskipun cara paket-paket ini melewati jaringan sangat berbeda.

Ulasan

Seperti yang telah kita lihat, HTTP mengikuti model permintaan / respons ketika klien yang terhubung ke server mengirim permintaan dan server meresponsnya.

Pesan HTTP (permintaan atau respons) terdiri dari beberapa bagian:

• "Baris pertama" (baris pertama)
• tajuk (tajuk permintaan)
• tubuh (tubuh permintaan)

Dalam permintaan, baris pertama menunjukkan metode yang digunakan oleh klien, jalur ke sumber daya yang ia inginkan, serta versi protokol yang akan ia gunakan:

GET /players/lebron-james HTTP/1.1

Dalam hal ini, klien mencoba untuk mendapatkan sumber daya ( GET ) di /Players/Lebron-James melalui protokol versi 1.1 - tidak ada yang rumit untuk dipahami.

Setelah baris pertama, HTTP memungkinkan kita untuk menambahkan metadata ke pesan melalui header yang mengambil bentuk nilai kunci, dipisahkan oleh tanda titik dua:

GET /players/lebron-james HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Misalnya, dalam permintaan ini, klien menambahkan 3 header tambahan ke permintaan: Host , Accept , dan Coolness .

Tunggu, Coolness ?!?!

Header tidak boleh menggunakan nama khusus yang dicadangkan, tetapi biasanya disarankan untuk mengandalkan yang standar dalam spesifikasi HTTP: semakin Anda menyimpang dari standar, semakin sedikit Anda akan dipahami oleh peserta pertukaran lainnya.

Cache-Control , misalnya, adalah tajuk yang digunakan untuk menentukan apakah (dan bagaimana) suatu respons dapat disimpan dalam cache: sebagian besar proksi dan proksi balik memahaminya dengan mengikuti spesifikasi HTTP pada surat itu. Jika Anda harus mengganti nama header Cache-Control menjadi Awesome-Cache-Control , proksi tidak akan tahu bagaimana cara men-cache respons, karena mereka tidak dirancang untuk memenuhi spesifikasi yang baru saja Anda temukan.

Namun, terkadang masuk akal untuk menyertakan tajuk "khusus" dalam pesan, karena Anda dapat menambahkan metadata yang sebenarnya bukan bagian dari spesifikasi HTTP: server dapat memutuskan untuk memasukkan informasi teknis dalam responsnya sehingga klien dapat secara bersamaan menjalankan permintaan dan menerima informasi penting tentang status server yang mengembalikan respons:

...
X-Cpu-Usage: 40%
X-Memory-Available: 1%
...

Saat menggunakan tajuk khusus, selalu lebih baik untuk menempatkan awalan dengan kunci di depannya sehingga tidak bertentangan dengan tajuk lain yang mungkin menjadi standar di masa depan: secara historis ini berfungsi dengan baik hingga semua orang mulai menggunakan awalan X "non-standar", yang pada gilirannya menjadi norma. Header X-Forwarded-For dan X-Forwarded-Proto adalah contoh header kustom yang banyak digunakan dan dipahami oleh load balancers dan proxy , bahkan jika mereka bukan bagian dari standar HTTP .

Jika Anda perlu menambahkan tajuk khusus Anda sendiri, sekarang biasanya yang terbaik adalah menggunakan awalan berpemilik seperti Acme-Custom-Header atau A-Custom-Header .

Setelah tajuk, permintaan dapat berisi badan yang dipisahkan dari tajuk oleh baris kosong:

POST /players/lebron-james/comments HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Best Player Ever


Permintaan kami selesai: baris pertama (informasi lokasi dan protokol), tajuk dan badan. Harap dicatat bahwa body sepenuhnya opsional dan, dalam banyak kasus, hanya digunakan ketika kami ingin mengirim data ke server, sehingga metode POST digunakan dalam contoh di atas.

Jawabannya sangat tidak berbeda:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600

{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}

Informasi pertama yang dikirim dalam respons adalah versi protokol yang digunakannya, bersama dengan status respons ini. Berikut ini adalah tajuk dan, jika diperlukan, jeda baris diikuti oleh tubuh.

Seperti yang telah disebutkan, protokol telah mengalami banyak revisi dan seiring waktu ditambahkan fungsi baru (header baru, kode status, dll.), Tetapi struktur utama tidak banyak berubah (baris pertama, header dan badan). Apa yang benar-benar berubah adalah bagaimana klien dan server bertukar pesan ini - mari kita lihat lebih dekat.

HTTP vs HTTPS vs H2

Ada 2 perubahan semantik yang signifikan dalam HTTP / 1.0 : HTTP / 1.0 dan HTTP / 1.1.

"Di mana HTTPS dan HTTP2 ?", Anda bertanya.

HTTPS dan HTTP2 (disingkat H2) adalah perubahan yang lebih teknis karena mereka memperkenalkan cara-cara baru untuk mengirimkan pesan melalui Internet, tanpa secara signifikan mempengaruhi semantik protokol.

HTTPS adalah ekstensi HTTP "aman" dan mencakup pembuatan kunci rahasia bersama antara klien dan server, memastikan bahwa kami berkomunikasi dengan pihak yang tepat dan mengenkripsi pesan yang bertukar kunci rahasia bersama (lebih lanjut tentang ini nanti). Sementara HTTPS ditujukan untuk meningkatkan keamanan protokol HTTP, H2 ditujukan untuk memberikan kecepatan tinggi.

H2 menggunakan biner daripada pesan teks, mendukung multiplexing, menggunakan algoritma HPACK untuk mengompres header ... ... Singkatnya, H2 meningkatkan kinerja melalui HTTP / 1.1.

Pemilik situs web enggan untuk beralih ke HTTPS, karena ini termasuk jalan memutar tambahan antara klien dan server (seperti yang telah disebutkan, perlu untuk membuat kunci rahasia bersama antara kedua pihak), sehingga memperlambat pengguna: dengan H2, yang secara default dienkripsi, tidak ada alasan lagi karena fitur seperti multiplexing dan server push membuatnya lebih baik daripada HTTP / 1.1 biasa .

Https

HTTPS (HTTP Secure) memungkinkan klien dan server untuk berkomunikasi dengan aman melalui TLS (Transport Layer Security), penerus SSL (Secure Socket Layer).

Masalah yang menjadi fokus TLS cukup sederhana dan dapat diilustrasikan dengan satu metafora sederhana: belahan jiwa Anda memanggil Anda di tengah hari ketika Anda sedang rapat dan meminta Anda untuk memberi tahu mereka kata sandi akun perbankan online Anda, karena harus menyelesaikan perbankan transfer untuk memastikan pembayaran tepat waktu untuk pendidikan putra Anda. Sangat penting bagi Anda untuk melaporkannya sekarang, jika tidak, Anda akan menghadapi risiko anak Anda dikeluarkan dari sekolah keesokan paginya.

Sekarang Anda dihadapkan pada dua masalah:

• membuktikan bahwa Anda benar-benar berbicara dengan belahan jiwa Anda, karena mungkin seseorang berpura-pura menjadi dirinya
• enkripsi : mengirimkan kata sandi Anda sehingga kolega Anda tidak dapat memahami dan menuliskannya

Apa yang akan kamu lakukan Inilah masalah yang coba dipecahkan oleh HTTPS.

Untuk memverifikasi dengan siapa Anda berbicara, HTTPS menggunakan Sertifikat Kunci Publik (sertifikat kunci publik), yang tidak lebih dari sertifikat yang menunjukkan identitas server tertentu: ketika Anda terhubung melalui HTTPS ke alamat IP, server di belakang alamat itu menyajikan kepada Anda Sertifikatnya untuk membuktikan identitas Anda. Kembali ke analogi kami, Anda bisa meminta belahan jiwa Anda untuk menyebutkan nomor jaminan sosial Anda. Segera setelah Anda memverifikasi bahwa nomor itu benar, Anda mendapatkan tingkat kepercayaan tambahan.

Namun, ini tidak mencegah "penyerang" menemukan nomor jaminan sosial korban, mencuri ponsel pintar belahan jiwa Anda dan memanggil Anda. Bagaimana kami memverifikasi identitas penelepon?

Alih-alih secara langsung meminta belahan jiwa Anda untuk menulis nomor jaminan sosial Anda, alih-alih Anda memanggil ibu Anda (yang tinggal di sebelah) dan memintanya untuk pergi ke apartemen Anda dan memastikan bahwa separuh lainnya mengatakan nomor jaminan sosial. Ini menambah tingkat kepercayaan tambahan, karena Anda tidak menganggap ibu Anda ancaman dan bergantung padanya untuk memverifikasi identitas penelepon.

Dalam hal HTTPS, ibumu disebut CA, kependekan dari Certificate Authority: pekerjaan CA adalah untuk memverifikasi identitas server tertentu dan mengeluarkan sertifikat dengan tanda tangan digital sendiri: ini berarti bahwa ketika saya terhubung ke domain tertentu saya tidak akan menerima sertifikat yang dihasilkan oleh pemilik domain (yang disebut sendiri ditandatangani) sertifikat ), dan CA.

Tugas CA adalah untuk memverifikasi keaslian domain dan mengeluarkan sertifikat sesuai: ketika Anda "memesan" sertifikat (biasanya disebut sertifikat SSL, meskipun TLS saat ini digunakan sebagai gantinya - nama-nama itu benar-benar melekat!), CA dapat menghubungi Anda atau Minta untuk mengubah pengaturan DNS untuk memastikan bahwa Anda mengontrol domain ini. Setelah proses verifikasi selesai, itu akan mengeluarkan sertifikat, yang kemudian dapat diinstal pada server web.

Kemudian, klien, seperti browser, akan terhubung ke server Anda dan menerima sertifikat ini sehingga mereka dapat memverifikasi keasliannya: browser memiliki semacam "hubungan" dengan CA, dalam arti mereka melacak daftar domain tepercaya di CA untuk memastikan Sertifikat itu benar-benar dapat dipercaya. Jika sertifikat tidak ditandatangani oleh otoritas tepercaya, browser akan menampilkan peringatan informasi besar untuk pengguna:



Kami setengah memastikan komunikasi antara Anda dan separuh lainnya: sekarang setelah kami melewati otentikasi (verifikasi identitas penelepon), kami perlu memastikan bahwa kami dapat berkomunikasi dengan aman tanpa campur tangan orang lain dalam proses. Seperti yang saya sebutkan, Anda tepat di tengah-tengah pertemuan dan Anda perlu menuliskan kata sandi Anda untuk perbankan online. Anda perlu menemukan cara untuk mengenkripsi komunikasi Anda sehingga hanya Anda dan jodoh Anda yang dapat memahami percakapan Anda.

Anda dapat melakukan ini dengan menetapkan kunci rahasia umum antara Anda berdua dan mengenkripsi pesan dengan kunci ini: misalnya, Anda dapat menggunakan opsi cipher Caesar berdasarkan tanggal pernikahan Anda.



Ini akan bekerja dengan baik jika kedua belah pihak telah membangun hubungan, seperti Anda dan belahan jiwa Anda, karena mereka dapat membuat kunci berdasarkan memori bersama yang tidak ada yang tahu. Browser dan server, bagaimanapun, tidak dapat menggunakan mekanisme yang sama, karena mereka tidak mengenal satu sama lain sebelumnya.

Sebagai gantinya, variasi dari protokol pertukaran kunci Diffie-Hellman digunakan, yang memastikan bahwa pihak-pihak tanpa pengetahuan sebelumnya membuat kunci rahasia bersama dan tidak ada orang lain yang dapat "mencuri" itu. Ini termasuk penggunaan matematika .



Setelah kunci rahasia dipasang, klien dan server dapat berkomunikasi tanpa takut bahwa seseorang mungkin akan mencegat pesan mereka. Bahkan jika penyerang melakukan ini, mereka tidak akan memiliki kunci rahasia bersama yang diperlukan untuk mendekripsi pesan.

Untuk informasi lebih lanjut tentang HTTPS dan Diffie-Hellman, saya akan merekomendasikan membaca " Bagaimana HTTPS Melindungi Koneksi " oleh Hartley Brody dan " Bagaimana HTTPS Benar-Benar Bekerja?" »Robert Heaton. Selain itu, Sembilan Algoritma yang Mengubah Masa Depan memiliki bab yang luar biasa menjelaskan enkripsi kunci publik, dan saya dengan hangat merekomendasikannya kepada para penggemar ilmu komputer yang tertarik pada algoritma asli.

Https di mana-mana

Masih memutuskan apakah Anda harus mendukung HTTPS di situs Anda? Saya punya berita buruk untuk Anda: browser telah mulai melindungi pengguna dari situs web yang tidak mendukung HTTPS untuk “memaksa” pengembang web untuk menyediakan kemampuan penelusuran yang sepenuhnya dienkripsi.

Mengikuti moto " HTTPS di mana-mana, " browser mulai menentang koneksi yang tidak terenkripsi - Google adalah penyedia browser pertama yang memberikan batas waktu kepada pengembang web dengan mengumumkan bahwa mulai dengan Chrome 68 (Juli 2018), itu akan menandai situs web HTTP sebagai "tidak aman" :



Yang lebih meresahkan bagi situs web yang tidak memanfaatkan HTTPS adalah kenyataan bahwa begitu pengguna mengetik sesuatu di halaman web, label "Tidak Aman" berubah merah - langkah ini harus mendorong pengguna untuk berpikir dua kali sebelum bertukar data. dengan situs web yang tidak mendukung HTTPS.



Bandingkan ini dengan seperti apa situs HTTPS dengan sertifikat yang valid:



Secara teoritis, sebuah situs web seharusnya tidak aman, tetapi dalam praktiknya itu membuat pengguna takut - dan memang demikian. Pada hari-hari ketika H2 bukan kenyataan, masuk akal untuk tetap dengan lalu lintas HTTP sederhana yang tidak terenkripsi. Sebenarnya tidak ada alasan untuk ini saat ini. Bergabunglah dengan HTTPS Everywhere movement dan bantu jadikan Internet tempat yang lebih aman untuk berselancar .

DAPATKAN vs POST

Seperti yang kita lihat sebelumnya, permintaan HTTP dimulai dengan semacam "baris pertama":

Pertama-tama, klien memberi tahu server metode mana yang digunakan untuk mengeksekusi permintaan: metode HTTP dasar termasuk GET, POST, PUT DELETE, tetapi daftar dapat dilanjutkan dengan metode yang kurang umum (tapi masih standar) seperti TRACE, OPTIONS , atau HEAD

Secara teoritis, tidak ada metode yang lebih aman daripada yang lain; dalam praktiknya, semuanya tidak begitu sederhana.

Permintaan GET biasanya tidak mengandung badan, sehingga parameter dimasukkan dalam URL (misalnya, www.example.com/articles?article_id=1 ), sedangkan permintaan POST biasanya digunakan untuk mengirim ("menerbitkan") data yang disertakan dalam badan. Perbedaan lainnya adalah efek samping yang dimiliki metode ini: GET adalah metode idempoten, artinya berapa pun banyaknya permintaan yang Anda kirim, Anda tidak akan mengubah status server web. Sebaliknya, POST bukan idempoten: untuk setiap permintaan yang Anda kirim, Anda dapat mengubah status server (pikirkan, misalnya, tentang menempatkan pembayaran baru - sekarang Anda mungkin mengerti mengapa situs meminta Anda untuk tidak me-refresh halaman saat menyelesaikan transaksi).

Untuk menggambarkan perbedaan penting antara metode-metode ini, kita perlu melihat log server web yang mungkin sudah Anda kenal:

192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] "GET /?token=1234 HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] "GET / HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] "PUT /users HTTP/1.1" 201 23 "http://example.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201

Seperti yang Anda lihat, server web mencatat jalur permintaan: ini berarti bahwa jika Anda memasukkan data sensitif dalam URL Anda, mereka akan dilewati oleh server web dan disimpan di suatu tempat di log Anda - data sensitif Anda akan berada di suatu tempat di teks biasa, yang harus kita hindari sepenuhnya. Bayangkan bahwa seorang penyerang bisa mendapatkan akses ke salah satu file log lama Anda , yang mungkin berisi informasi kartu kredit, token akses untuk layanan pribadi Anda, dll., Ini akan menjadi bencana total.

Server web tidak mencatat tajuk dan badan HTTP, karena data yang disimpan akan terlalu banyak - itulah sebabnya mengirim informasi melalui badan permintaan daripada URL umumnya lebih aman. Dari sini kita dapat menyimpulkan bahwa POST (dan metode non-idempoten serupa) lebih aman daripada GET , bahkan jika itu lebih tergantung pada bagaimana data dikirim ketika menggunakan metode tertentu, dan bukan pada kenyataan bahwa metode tertentu pada dasarnya lebih aman daripada yang lain: jika Anda memasukkan informasi rahasia dalam badan permintaan GET , maka Anda tidak akan memiliki lebih banyak masalah daripada menggunakan POST , bahkan jika pendekatan seperti itu akan dianggap tidak biasa.

Kami percaya pada tajuk HTTP

Pada artikel ini, kami melihat HTTP, evolusinya, dan bagaimana ekstensi amannya menggabungkan otentikasi dan enkripsi untuk memungkinkan klien dan server berkomunikasi melalui saluran aman: ini tidak semua yang ditawarkan HTTP dalam hal keamanan.

---

Terjemahan didukung oleh EDISON Software , sebuah perusahaan keamanan profesional, dan juga mengembangkan sistem verifikasi medis elektronik .