Web Security : Sebuah Perkenalan Pada HTTP

HTTP ialah hal yang menakjubkan: prosedur yang sudah bertahan lebih dari 20 tahun tanpa banyak peralihan.

Sama seperti yang sudah kita lihat di artikel awalnya, browser berhubungan dengan program situs lewat prosedur HTTP, dan berikut argumen khusus kami mencari subyek ini. Bila pemakai masukkan detil kartu credit mereka di website dan striker bisa mencegat data saat sebelum capai server, kami pasti mendapatkan permasalahan.

Pahami langkah kerja HTTP, langkah kami bisa amankan komunikasi di antara client dan server, dan feature berkaitan keamanan apa yang dijajakan prosedur ialah langkah awal untuk tingkatkan keadaan keamanan kami.

Tetapi, saat mengulas HTTP, kita selalu harus membandingkan di antara semantik dan implikasi tehnis, karena ke-2 nya sebagai faktor yang paling berlainan mengenai langkah kerja HTTP.

Ketidaksamaan khusus di antara ke-2 nya bisa diterangkan dengan analogi yang paling simpel: 20 tahun lalu beberapa orang mempedulikan familinya seperti saat ini, walau langkah mereka berhubungan sudah berbeda secara signifikan. Orangtua kami kemungkinan bawa mobil mereka dan ke rumah saudara wanita mereka untuk memburu dan habiskan waktu dengan keluarga.

Bukannya, belakangan ini umum untuk mengirimi pesan di WhatsApp, lakukan panggilan telephone, atau memakai group Facebook, beberapa hal yang awalnya mustahil dilaksanakan. Ini bukanlah untuk menjelaskan jika orang berbicara atau perduli lebih atau mungkin kurang, tapi cuma langkah mereka berhubungan berbeda.

HTTP tidak berlainan: semantik dibalik prosedur sedikit berbeda, sementara implikasi tehnis mengenai bagaimana client dan server bicara keduanya sudah dimaksimalkan sepanjang tahun. Bila Anda menyaksikan keinginan HTTP dari tahun 1996, itu akan kelihatan benar-benar serupa sama yang kita lihat di artikel awalnya, walau langkah beberapa paket itu terbang lewat jaringan benar-benar berlainan.

Deskripsi

Sama seperti yang sudah kita lihat awalnya, HTTP ikuti mode keinginan/tanggapan, di mana client yang tersambung ke server keluarkan keinginan, dan server membalas kembali.

Pesan HTTP (baik keinginan atau respon) berisi bagian-bagian:

“first line”
headers
body

Dalam keinginan, baris pertama memperlihatkan kata kerja yang dipakai oleh client, lajur sumber daya yang diharapkan, dan versus prosedur yang hendak dipakai:

GET /players/lebron-james HTTP/1.1

Dalam hal ini, klien mencobam GET sumber daya di /players/lebron-jamesmelalui versi 1.1 protokol - tidak ada yang sulit untuk dipahami.

Setelah baris pertama, HTTP memungkinkan kita untuk menambahkan metadata ke pesan melalui header, yang berbentuk key-value pair, dipisahkan dengan tanda titik dua:

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

Dalam permintaan ini, misalnya, klien telah melampirkan 3 header tambahan ke permintaan:Host, Accept dan Coolness.

Tunggu, Coolness?!?!

Header tidak harus menggunakan nama khusus yang dicadangkan, tetapi umumnya disarankan untuk mengandalkan nama yang dibakukan oleh spesifikasi HTTP: semakin Anda menyimpang dari standar, semakin sedikit pihak lain dalam pertukaran akan memahami Anda.

Cache-Controladalah, misalnya, header yang digunakan untuk menentukan apakah (dan bagaimana) respons dapat di-cache: kebanyakan proxy dan reverse proxy memahaminya karena mereka mengikuti spesifikasi HTTP ke surat itu. Jika Anda mengganti nama AndaCache-Controltajuk keAwesome-Cache-Control, proxy tidak akan mengetahui kembali langkah meng-cache tanggapan, karena mereka tidak dibikin untuk ikuti detail yang barusan Anda bikin.

Tetapi, kadang logis untuk mengikutkan judul "khusus" ke pesan, karena Anda kemungkinan ingin menambah metadata yang sebetulnya bukan sisi dari detail HTTP: server bisa memilih untuk mengikutkan info tehnis dalam responnya, hingga client bisa, di saat yang serupa, menyelesaikan keinginan dan memperoleh info penting berkenaan status server yang membalasnya:

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

Saat memakai judul khusus, selalu lebih dicintai untuk memulainya dengan kunci hingga tidak berlawanan dengan judul yang lain kemungkinan jadi standard di periode kedepan: secara bersejarah, ini berperan secara baik sampai semuanya orang mulai memakai awalan X "non-standar" yang, pada gilirannya, jadi etika. Itu X-Forwarded-For dan X-Forwarded-Protoheader adalah contoh header khusus yang banyak digunakan dan dipahami oleh load balancer dan proxy, meskipun bukan bagian dari standar HTTP.

Bila Anda perlu menambah judul khusus Anda sendiri, sekarang ini biasanya lebih bagus memakai awalan supplier, sepertiAcme-Custom-Headeratau A-Custom-Header.

Sesudah header, keinginan kemungkinan berisi tubuh, yang dipisah dari header dengan baris kosong:

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

Keinginan kami usai: baris pertama (info lokasi dan prosedur), header dan isi. Lihat jika bodi seutuhnya opsional dan, dalam beberapa kasus, ini cuma dipakai saat kita ingin mengirimi data ke server — tersebut penyebabnya contoh di atas memakai kata kerja POST.

Jawabnya hampir sama:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}

Info pertama kali yang diiklankan oleh tanggapan ialah versus prosedur yang dipakainya, bersama dengan status tanggapan ini. Judul ikuti dan, bila dibutuhkan, interval baris dituruti oleh tubuh.

Seperti disebut, prosedur sudah alami banyak koreksi dan sudah menambah feature dari hari ke hari (header baru, code status, dll), tapi susunan dasarnya sedikit berbeda (baris pertama, header, dan isi). Apa yang betul-betul berbeda ialah bagaimana client dan server tukar pesan itu — silahkan kita saksikan lebih dekat.

HTTP vs HTTPS vs H2

HTTP sudah melihat 2 perubahan semantik yang lumayan besar: HTTP/1.0 dan HTTP/1.1.

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

HTTPS dan HTTP2 (dipersingkat H2) lebih sebagai peralihan tehnis, karena mereka mengenalkan langkah baru untuk menyampaikan pesan lewat internet, tanpa terlampau mempengaruhi semantik prosedur.

HTTPS ialah perpanjangan "aman" untuk HTTP dan mengikutsertakan pembikinan rahasia di antara client dan server, pastikan kami berbicara dengan faksi yang pas dan mengenkripsi pesan yang dipertukarkan dengan rahasia (selanjutnya mengenai ini kelak). Sementara HTTPS diperuntukkan untuk tingkatkan keamanan prosedur HTTP, H2 ditujukan untuk bawa kecepatan sinar ke dalamnya.

H2 menggunakan biner dibanding pesan teks biasa, memberikan dukungan multiplexing, memakai algoritma HPACK untuk mengompres header… …singkat narasi, H2 ialah kenaikan performa ke HTTP/1.1.

Pemilik website malas untuk berpindah ke HTTPS karena mengikutsertakan perjalanan bolak-balik tambahan di antara client dan server (sama seperti yang disebut, rahasia perlu dibikin di antara 2 pihak), hingga perlambat pengalaman pemakai: dengan H2, yang dienkripsi oleh standar, tidak ada argumen, karena feature seperti multiplexing dan server push membuat bekerja lebih bagus dibanding HTTP/1.1 biasa.

HTTPS

HTTPS (HTTP Secure) mempunyai tujuan supaya client dan server bicara dengan aman lewat TLS (Transport Layer Security), penerus SSL (Secure Soket Layer).

Permasalahan yang ditarget TLS cukuplah sederhana, dan bisa digambarkan dengan 1 metafora simpel: pasangan Anda yang lebih bagus menghubungi Anda di tengah-tengah hari, saat Anda sedang meeting, dan minta Anda memberitahu mereka password perbankan online Anda rekening, karena mereka perlu lakukan transfer bank untuk pastikan ongkos sekolah putra Anda dibayarkan on time. Penting untuk Anda untuk mengkomunikasikannya saat ini, bila tidak, Anda hadapi peluang anak Anda ditampik sekolah esok paginya.

Anda saat ini hadapi dengan 2 rintangan:

otentikasi: memastikan Anda benar-benar berbicara dengan pasangan Anda, karena bisa saja seseorang berpura-pura menjadi mereka
enkripsi: mengomunikasikan kata sandi tanpa rekan kerja Anda dapat memahaminya dan mencatatnya

Apa tugasmu? Berikut permasalahan yang mencoba diperpecahkan oleh HTTPS.

Untuk mengonfirmasi sama siapa Anda bicara, HTTPS memakai Sertifikat Kunci Khalayak, yang tidak lain ialah sertifikat yang mengatakan identitas dibalik server tertentu: saat Anda tersambung, lewat HTTPS, ke alamat IP, server ada di belakang alamat itu akan memberitahu Anda sertifikatnya untuk Anda untuk mengonfirmasi identitas mereka. Kembali lagi ke analogi kami, ini bisa saja Anda minta pasangan Anda untuk melafalkan nomor agunan sosial mereka. Sesudah Anda mengonfirmasi nomornya betul, Anda memperoleh tingkat keyakinan tambahan.

Tetapi, ini tidak menahan "striker" pelajari nomor agunan sosial korban, mengambil handphone pintar belahan jiwa Anda, dan menghubungi Anda. Bagaimana kami mengonfirmasi identitas penelepon?

Dibanding langsung minta setengah lebih bagus Anda untuk melafalkan nomor agunan sosial mereka, Anda justru menghubungi ibu Anda (yang kebenaran tinggal di samping) dan meminta untuk ke apartemen Anda dan pastikan setengah lebih bagus Anda melafalkan sosial mereka. nomor keamanan. Ini menambahkan tingkat keyakinan tambahan, karena Anda tidak memandang ibu Anda sebagai teror, dan memercayakannya untuk mengonfirmasi identitas penelepon.

Dalam istilah HTTPS, ibu Anda disebutkan CA, singkatan dari Certificate Authority: pekerjaan CA ialah mengonfirmasi identitas dibalik server tertentu, dan keluarkan sertifikat dengan tanda-tangan digitalnya sendiri: ini memiliki arti, saat saya tersambung ke domain tertentu, saya tidak dihidangkan sertifikat yang dibikin oleh pemilik domain (disebutkan sertifikat yang diberi tanda tangan sendiri), tetapi oleh CA.

Pekerjaan kewenangan yaitu memastikan mereka mengonfirmasi identitas dibalik domain dan keluarkan sertifikat yang sama sesuai: saat Anda "pesan" sertifikat (biasanya dikenali sebagai sertifikat SSL, walau sekarang ini TLS dipakai sebagai tukarnya - nama betul-betul menempel !), kewenangan kemungkinan memberikan Anda panggilan telephone atau minta Anda untuk mengganti penataan DNS untuk mengonfirmasi jika Anda menggenggam kendalian atas domain yang diartikan. Sesudah proses klarifikasi usai, itu akan keluarkan sertifikat yang selanjutnya bisa Anda instal di server situs Anda.

Client seperti browser selanjutnya akan tersambung ke server Anda dan diberi sertifikat ini, hingga mereka bisa mengonfirmasi jika itu kelihatan asli: browser mempunyai seperti "jalinan" dengan CA, dalam makna jika mereka mencari daftar CA tepercaya di untuk mengonfirmasi jika sertifikat itu betul-betul bisa dipercayai. Bila sertifikat tidak diberi tanda tangan oleh kewenangan tepercaya, browser akan tampilkan peringatan besar dan informatif ke pemakai:

Kami 1/2 jalan untuk amankan komunikasi di antara Anda dan pasangan Anda yang lebih bagus: saat ini sesudah kami pecahkan otentikasi (mengonfirmasi identitas penelepon), kami perlu pastikan jika kami bisa berbicara dengan aman, tanpa seseorang menguping pada proses. Sama seperti yang saya sebut, Anda ada pas di tengah-tengah rapat dan perlu melafalkan password perbankan online Anda. Anda perlu mendapati langkah untuk mengenkripsi komunikasi Anda, hingga cuma Anda dan belahan jiwa Anda yang bisa pahami pembicaraan Anda.

Anda bisa lakukan ini dengan membuat rahasia bersama antara Anda berdua, dan mengenkripsi pesan lewat rahasia itu: Anda bisa, misalkan, memilih untuk memakai macam kode Caesar berdasar tanggal pernikahan Anda.

Ini akan bekerja dengan baik bila kedua pihak mempunyai jalinan yang mapan, seperti Anda dan belahan jiwa Anda, karena mereka bisa membuat rahasia berdasar daya ingat bersama yang tidak dikenali seseorang. Browser dan server, bagaimana juga, tidak bisa memakai proses yang serupa karena mereka tidak mempunyai pengetahuan awalnya keduanya.

Macam dari prosedur transisi kunci Diffie-Hellman dipakai sebagai tukarnya, yang pastikan beberapa pihak tanpa setahu awalnya membuat rahasia bersama tanpa orang yang lain bisa "mengendusi" itu. Ini mengikutsertakan pemakaian sedikit matematika, latihan yang diberikan ke pembaca.

Sesudah rahasia dibikin, client dan server bisa berbicara tak perlu takut seorang akan mencegat pesan mereka. Bahkan juga bila striker melakukan, mereka tidak mempunyai rahasia yang dibutuhkan untuk mendekripsi pesan.

Untuk info selanjutnya mengenai HTTPS dan Diffie-Hellman, saya akan mereferensikan membaca "Bagaimana HTTPS amankan jaringan" oleh Hartley Brody dan "Bagaimana sebetulnya HTTPS bekerja?" oleh Robert Heaton. Disamping itu, "Sembilan Algoritme yang Mengganti Periode Depan" mempunyai bab hebat yang menerangkan enkripsi kunci Khalayak, dan saya dengan hangat merekomendasikannya ke pakar Pengetahuan Computer yang tertarik sama algoritma yang cerdas.

HTTPS ada dimana - mana

Masih memperdebatkan apa Anda harus memberikan dukungan HTTPS di website Anda? Saya tidak memiliki berita baik untuk Anda: browser sudah mulai menggerakkan pemakai menjauhi website yang tidak memberikan dukungan HTTPS untuk "memaksakan" pengembang situs untuk memberi pengalaman pencarian yang dienkripsi seutuhnya.

Dibalik moto "HTTPS di mana saja", browser mulai ambil sikap pada jaringan yang tidak terenkripsi - Google ialah supplier browser pertama kali yang memberikan tenggat waktu ke pengembang situs dengan umumkan jika diawali dengan Krom 68 (Juli 2018) itu akan mengidentifikasi website HTTP sebagai "tidak aman ":

Bahkan juga yang lebih mencemaskan untuk website yang tidak manfaatkan HTTPS ialah bukti jika, selekasnya sesudah pemakai masukkan apa saja di halaman situs, cap "Tidak aman" beralih menjadi merah - sebuah cara yang semestinya menggerakkan pemakai untuk berpikiran 2x saat sebelum tukar data dengan situs web yang tidak memberikan dukungan HTTPS.

Bandingkan ini dengan tampilan situs web yang berjalan di HTTPS dan dilengkapi dengan sertifikat yang valid:

Secara teori, situs web tidak harus aman, tetapi dalam praktiknya, ini membuat pengguna takut - dan memang seharusnya begitu. Dulu, ketika H2 bukan kenyataan, masuk akal untuk tetap menggunakan lalu lintas HTTP biasa yang tidak terenkripsi. Saat ini hampir tidak ada alasan untuk melakukannya. Bergabunglah dengan gerakan HTTPS di mana saja dan bantu jadikan web sebagai tempat yang lebih aman bagi peselancar.

GET vs POST

Seperti yang telah kita lihat sebelumnya, permintaan HTTP dimulai dengan baris pertama yang aneh:

Pertama dan terpenting, klien memberi tahu server kata kerja apa yang digunakannya untuk melakukan permintaan: termasuk kata kerja HTTP umum GET, POST, PUT dan DELETE,tetapi daftarnya bisa berlanjut dengan kata kerja yang kurang umum (namun masih standar) seperti TRACE, OPTIONS, atau HEAD.

Secara teori, tidak ada metode yang lebih aman dari yang lain; dalam praktiknya, tidak sesederhana itu.

GETpermintaan biasanya tidak membawa badan, jadi parameter disertakan dalam URL(yaitu. www.example.com/articles?article_id=1)sedangkanPOST permintaan umumnya digunakan untuk mengirim ("posting") data yang termasuk dalam tubuh. Perbedaan lainnya adalah efek samping yang dibawa oleh kata kerja ini:GETadalah kata kerja idempoten, artinya tidak peduli berapa banyak permintaan yang akan Anda kirim, Anda tidak akan mengubah status server web.POST, sebaliknya, bukan idempoten: untuk setiap permintaan yang Anda kirimkan, Anda mungkin mengubah status server (pikirkan, misalnya, MEMASANG pembayaran baru — sekarang Anda mungkin mengerti mengapa situs meminta Anda untuk tidak menyegarkan halaman saat melakukan transaksi ).

Untuk mengilustrasikan perbedaan penting antara metode ini, kami 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

Sama seperti yang Anda saksikan, server situs menulis lajur keinginan: ini memiliki arti jika, bila Anda mengikutkan data peka di URL Anda, itu akan dibocorkan oleh server situs dan diletakkan pada sebuah tempat di log Anda - rahasia Anda akan ada di satu tempat dalam text biasa, suatu hal yang kami perlukan untuk betul-betul menghindar. Pikirkan seorang striker bisa mendapat akses ke salah satunya file log lama Anda, yang bisa berisi info kartu credit, token akses untuk service individu Anda, dan lain-lain: itu bisa menjadi musibah keseluruhan.

Server situs tidak menulis header atau tubuh HTTP, karena data yang hendak diletakkan akan terlampau besar - berikut kenapa mengirim info lewat tubuh keinginan, dibanding URL, biasanya semakin aman. Disini kita bisa mendapat jika POST (dan sama, sistem non-idempoten) semakin aman dibanding GET, walau ini lebih sebagai permasalahan bagaimana data dikirimkan saat memakai kata kerja tertentu dibanding kata kerja tertentu yang intrinsik semakin aman dibanding lainnya: bila Anda ialah masukkan info peka ke isi keinginan GET, karena itu Anda tidak hadapi permasalahan semakin banyak dibanding saat memakai POST, walau pendekatan itu akan dipandang tidak biasa. Di header HTTP kami yakin

Dalam artikel ini kita menyaksikan HTTP, evolusinya, dan bagaimana perpanjangan amannya memadukan autentikasi dan enkripsi supaya client dan server bisa berbicara lewat aliran (r) aman: ini tidak seluruhnya yang dijajakan HTTP dalam soal keamanan.

Seperti yang hendak kita saksikan di artikel selanjutnya, header keamanan HTTP tawarkan langkah untuk tingkatkan bentuk keamanan program kita, dan posting selanjutnya diperuntukkan untuk pahami langkah memakainya.