Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

HTTP Ringkas: Status dan Keamanan HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Web Architecture

Indonesian (Bahasa Indonesia) translation by Uady (you can also view the original English article)

Dalam bab terakhir ini kita akan melihat aspek keamanan HTTP, termasuk cara mengidentifikasi pengguna, cara kerja otentikasi HTTP, dan mengapa beberapa skenario memerlukan HTTPS (HTTP aman). Sepanjang jalan, kita juga akan belajar sedikit tentang cara mengelola negara dengan HTTP.


The Stateless (Juga Stateful) Web

HTTP adalah stateless protocol, yang berarti setiap transaksi permintaan-respons tidak bergantung pada transaksi sebelumnya atau yang akan datang. Tidak ada dalam protokol HTTP yang membutuhkan server untuk menyimpan informasi tentang permintaan HTTP. Yang perlu dilakukan oleh server adalah menghasilkan respons untuk setiap permintaan. Setiap permintaan akan membawa semua informasi yang dibutuhkan server untuk membuat respons.

Sifat stateless HTTP adalah salah satu faktor pendorong dalam keberhasilan web. Layanan berlapis yang kita amati di bab sebelumnya, layanan seperti caching, semuanya memungkinkan (atau setidaknya lebih mudah) karena setiap pesan berisi semua informasi yang diperlukan untuk memproses pesan. Server proxy dan server web dapat memeriksa, mengubah, dan pesan cache. Tanpa cache, web tidak dapat menskala untuk memenuhi tuntutan Internet.

Namun, sebagian besar aplikasi web dan layanan yang kita bangun di atas HTTP sangat jelas.

Aplikasi perbankan akan meminta pengguna untuk masuk sebelum mengizinkan pengguna untuk melihat sumber terkait akunnya. Karena setiap permintaan stateless tiba untuk sumber daya pribadi, aplikasi ingin memastikan bahwa pengguna telah diautentikasi. Contoh lain adalah ketika pengguna ingin membuka akun dan mengisi formulir dalam wizard tiga halaman. Aplikasi akan memastikan halaman pertama dari wizard selesai sebelum memungkinkan pengguna untuk mengirimkan halaman kedua.

Untungnya, ada banyak pilihan untuk menyimpan status dalam aplikasi web. Salah satu pendekatan adalah menanamkan status dalam sumber daya yang ditransfer ke klien, sehingga semua negara yang diperlukan oleh aplikasi akan melakukan perjalanan kembali pada permintaan berikutnya. Pendekatan ini biasanya membutuhkan beberapa bidang masukan tersembunyi dan berfungsi paling baik untuk keadaan singkat (seperti keadaan yang diperlukan untuk bergerak melalui wizard tiga halaman). Menyematkan status dalam sumber daya membuat semua bagian state di dalam pesan HTTP, jadi ini adalah pendekatan yang sangat skalabel, tetapi dapat mempersulit pemrograman aplikasi.

Pilihan lainnya adalah menyimpan status pada server (atau di belakang server). Opsi ini diperlukan untuk state yang harus sekitar waktu yang lama. Katakanlah pengguna mengirimkan formulir untuk mengubah alamat emailnya. Alamat email harus selalu dikaitkan dengan pengguna, sehingga aplikasi dapat mengambil alamat baru, memvalidasi alamat, dan menyimpan alamat dalam basis data, file, atau memanggil layanan web untuk membiarkan orang lain berhati-hati dalam menyimpan alamat .

Untuk penyimpanan sisi server, banyak kerangka pengembangan web seperti ASP.NET juga menyediakan akses ke "sesi pengguna". Sesi mungkin hidup dalam memori, atau dalam database, tetapi pengembang dapat menyimpan informasi dalam sesi dan mengambil informasi pada setiap permintaan berikutnya. Data yang tersimpan dalam suatu sesi disesuaikan dengan pengguna individu (sebenarnya, untuk sesi penelusuran pengguna), dan tidak dibagi di antara banyak pengguna.

Penyimpanan sesi memiliki model pemrograman yang mudah dan hanya baik untuk keadaan berumur pendek, karena pada akhirnya server harus menganggap pengguna telah meninggalkan situs atau menutup browser dan server akan membuang sesi. Penyimpanan sesi, jika disimpan dalam memori, dapat berdampak negatif skalabilitas karena permintaan berikutnya harus pergi ke server yang sama di mana data sesi berada. Beberapa load balancer membantu mendukung skenario ini dengan menerapkan "sticky sessions".

Anda mungkin bertanya-tanya bagaimana server dapat melacak pengguna untuk mengimplementasikan status sesi. Jika dua permintaan tiba di server, bagaimana server mengetahui apakah ini dua permintaan dari pengguna yang sama, atau jika ada dua pengguna berbeda yang masing-masing membuat satu permintaan?

Pada masa awal web, perangkat lunak server mungkin membedakan pengguna dengan melihat alamat IP dari pesan permintaan. Hari-hari ini, bagaimanapun, banyak pengguna tinggal di belakang perangkat menggunakan Network Address Translation, dan untuk alasan ini dan lainnya Anda dapat memiliki beberapa pengguna secara efektif pada alamat IP yang sama. Alamat IP bukan teknik yang dapat diandalkan untuk membedakan pengguna.

Untungnya, ada teknik yang lebih andal.


Identifikasi dan Cookie

Situs web yang ingin melacak pengguna sering kali akan beralih ke cookie. Cookie didefinisikan oleh RFC6265 (http://tools.ietf.org/html/rfc6265), dan RFC ini tepat berjudul "Mekanisme Manajemen Negara HTTP". Ketika pengguna pertama kali mengunjungi situs web, situs tersebut dapat memberikan cookie pada browser pengguna menggunakan header HTTP. Browser kemudian tahu untuk mengirim cookie di header setiap permintaan tambahan yang dikirimkan ke situs. Dengan asumsi situs web telah menempatkan semacam pengidentifikasi unik ke dalam cookie, maka situs sekarang dapat melacak pengguna saat dia membuat permintaan, dan membedakan satu pengguna dari yang lain.

Sebelum kita masuk ke rincian lebih lanjut tentang apa yang terlihat seperti kue dan bagaimana mereka berperilaku, ada baiknya memperhatikan beberapa keterbatasan. Pertama, cookie dapat mengidentifikasi pengguna dalam arti bahwa cookie Anda berbeda dari cookie saya, tetapi cookie tidak mengotentikasi pengguna. Pengguna terotentikasi telah membuktikan identitasnya biasanya dengan memberikan kredensial seperti nama pengguna dan kata sandi. Cookie yang kita bicarakan sejauh ini hanya memberi kita beberapa pengenal unik untuk membedakan satu pengguna dari yang lain, dan melacak pengguna saat permintaan dibuat ke situs.

Kedua, karena cookie dapat melacak apa yang dilakukan pengguna, mereka meningkatkan kekhawatiran privasi di beberapa kalangan. Beberapa pengguna akan menonaktifkan cookie di browser mereka, yang berarti browser akan menolak cookie yang dikirim oleh server sebagai respons. Cookie yang dinonaktifkan menyajikan masalah untuk situs yang perlu melacak pengguna, tentu saja, dan alternatifnya berantakan. Misalnya, satu pendekatan untuk "cookieless sessions" adalah menempatkan pengenal pengguna ke URL. Sesi tanpa cookie mengharuskan setiap URL yang diberikan situs kepada pengguna berisi pengenal yang tepat, dan URL menjadi jauh lebih besar (itulah sebabnya teknik ini sering disebut teknik "fat URL").


Pengaturan Cookie

Ketika sebuah situs web ingin memberikan cookie kepada pengguna, ia menggunakan header Set-Cookie dalam respons HTTP.

Ada tiga area informasi dalam cookie yang ditunjukkan dalam contoh ini. Ketiga area tersebut dibatasi oleh titik koma (;). Pertama, ada satu atau lebih pasangan nama-nilai. Pasangan nama-nilai ini dibatasi oleh tanda dolar ($), dan terlihat sangat mirip dengan bagaimana parameter kueri diformat ke dalam URL. Dalam contoh cookie, server ingin menyimpan nama depan dan nama belakang pengguna di cookie. Area kedua dan ketiga adalah domain dan jalur, masing-masing. Kita akan kembali lagi nanti untuk membicarakan tentang domain dan jalur.

Situs web dapat memasukkan informasi apa pun yang disukai ke cookie, meskipun ada batasan ukuran 4 KB. Namun, banyak situs web hanya memasukkan pengenal unik untuk pengguna, mungkin GUID. Server tidak pernah dapat mempercayai apa pun yang disimpan di klien kecuali jika dijamin secara kriptografi. Ya, adalah mungkin untuk menyimpan data terenkripsi dalam cookie, tetapi biasanya lebih mudah untuk menyimpan ID.

Dengan asumsi browser dikonfigurasi untuk menerima cookie, browser akan mengirimkan cookie ke server dalam setiap permintaan HTTP berikutnya.

Ketika ID tiba, perangkat lunak server dapat dengan cepat mencari data pengguna terkait dari struktur data di dalam memori, basis data, atau cache terdistribusi. Anda dapat mengonfigurasi sebagian besar kerangka kerja aplikasi web untuk memanipulasi cookie dan secara otomatis mencari status sesi. Misalnya, di ASP.NET, objek Session mengekspos API yang mudah untuk membaca dan menulis status sesi pengguna. Sebagai pengembang, kita tidak perlu khawatir tentang mengirim header Set-Cookie, atau membaca cookie yang masuk untuk menemukan status sesi yang terkait. Di belakang layar, ASP.NET akan mengelola session cookie.

Sekali lagi, perlu ditunjukkan bahwa data firstName dan lastName yang disimpan dalam objek sesi tidak masuk ke cookie. Cookie hanya berisi pengidentifikasi sesi. Nilai yang terkait dengan pengidentifikasi sesi aman di server. Secara default, data sesi masuk ke struktur data di memori dan tetap hidup selama 20 menit. Ketika cookie sesi tiba dalam permintaan, ASP.NET akan mengaitkan data sesi yang benar dengan objek Session setelah menemukan data pengguna menggunakan ID yang disimpan dalam cookie. Jika tidak ada cookie yang masuk dengan ID sesi, ASP.NET akan membuatnya dengan header Set-Cookie.

Satu masalah keamanan di sekitar pengidentifikasi sesi adalah bagaimana mereka dapat membuka kemungkinan seseorang membajak sesi pengguna lain. Misalnya, jika saya menggunakan alat seperti Fiddler untuk melacak lalu lintas HTTP, saya mungkin melihat header Set-Cookie berasal dari server dengan SessionID=12 di dalam. Saya mungkin menduga bahwa beberapa pengguna lain sudah memiliki SessionID 11, dan membuat permintaan HTTP dengan ID tersebut hanya untuk melihat apakah saya dapat mencuri atau melihat HTML yang ditujukan untuk beberapa pengguna lain. Untuk mengatasi masalah ini, sebagian besar aplikasi web akan menggunakan angka acak besar sebagai pengidentifikasi (ASP.NET menggunakan 120 bit keacakan). Pengidentifikasi sesi ASP.NET tampak seperti yang berikut, yang membuatnya lebih sulit untuk menebak seperti apa ID sesi orang lain.


HttpOnly Cookie

Kekhawatiran keamanan lainnya seputar cookie adalah seberapa rentan mereka terhadap serangan scripting lintas situs (XSS). Dalam serangan XSS, pengguna jahat menyuntikkan kode JavaScript jahat ke situs web orang lain. Jika situs web lain mengirim skrip berbahaya kepada penggunanya, skrip berbahaya dapat memodifikasi, atau memeriksa dan mencuri informasi cookie (yang dapat menyebabkan pembajakan sesi, atau lebih buruk).

Untuk mengatasi kerentanan ini, Microsoft memperkenalkan flag HttpOnly (terlihat pada contoh Set-Cookie terakhir). Bendera HttpOnly memberitahu agen pengguna untuk tidak mengizinkan kode skrip untuk mengakses cookie. Cookie ada untuk "hanya HTTP" -i.e. untuk melakukan perjalanan di header setiap pesan permintaan HTTP. Browser yang mengimplementasikan HttpOnly tidak akan mengizinkan JavaScript untuk membaca atau menulis cookie pada klien.


Jenis Cookie

Cookie yang telah kita lihat sejauh ini adalah session cookies. Session cookies ada untuk satu sesi pengguna dan dihancurkan ketika pengguna menutup browser. Persistent cookies dapat hidup lebih lama dari satu sesi penelusuran dan agen pengguna akan menyimpan cookie ke disk. Anda dapat mematikan komputer dan kembali satu minggu kemudian, masuk ke situs web favorit Anda, dan cookie tetap akan tetap ada untuk permintaan pertama.

Satu-satunya perbedaan antara keduanya adalah bahwa cookie tetap membutuhkan nilai Expires.

Cookie sesi dapat secara eksplisit menambahkan atribut Discard ke cookie, tetapi tanpa nilai Expires, agen pengguna harus membuang cookie dalam keadaan apa pun.


Jalur Cookie dan Domain

Sejauh ini kita telah mengatakan bahwa setelah cookie ditetapkan oleh situs web, cookie akan melakukan perjalanan ke situs web dengan setiap permintaan berikutnya (dengan asumsi cookie belum kedaluwarsa). Namun, tidak semua cookie melakukan perjalanan ke setiap situs web. Satu-satunya cookie yang harus dikirim oleh agen pengguna ke situs adalah cookie yang diberikan kepada agen pengguna oleh situs yang sama. Tidak masuk akal bagi cookie dari amazon.com untuk berada dalam permintaan HTTP ke google.com. Jenis perilaku ini hanya dapat membuka masalah keamanan dan privasi tambahan. Jika Anda menetapkan cookie sebagai tanggapan atas permintaan ke www.server.com, cookie yang dihasilkan hanya akan melakukan perjalanan dalam permintaan ke www.server.com.

Aplikasi web juga dapat mengubah lingkup cookie untuk membatasi cookie ke host atau domain tertentu, dan bahkan ke jalur sumber daya tertentu. Aplikasi web mengontrol ruang lingkup menggunakan atribut domain dan path.

Atribut domain memungkinkan cookie untuk menjangkau sub-domain. Dengan kata lain, jika Anda mengatur cookie dari www.server.com, agen pengguna hanya akan mengirimkan cookie ke www.server.com. Domain dalam contoh sebelumnya juga memungkinkan cookie untuk melakukan perjalanan ke URL apa pun di domain server.com, termasuk images.server.com, help.server.com, dan hanya server.com biasa. Anda tidak dapat menggunakan atribut domain untuk menjangkau domain, jadi pengaturan domain menjadi .microsoft.com sebagai respons terhadap .server.com tidak sah dan agen pengguna harus menolak cookie.

Atribut path dapat membatasi cookie ke jalur sumber daya tertentu. Dalam contoh sebelumnya, cookie hanya akan melakukan perjalanan ke situs server.com ketika URL permintaan menunjuk ke /stuff, atau lokasi di bawahnya /stuff, seperti /stuff/images. Pengaturan jalur dapat membantu mengatur cookie ketika beberapa tim sedang membangun aplikasi web di jalur yang berbeda.


Cookie Downsides

Cookie memungkinkan situs web menyimpan informasi di klien dan informasi akan kembali ke situs dalam permintaan berikutnya. Manfaat untuk pengembangan web luar biasa, karena cookie memungkinkan kita untuk melacak permintaan yang dimiliki oleh pengguna mana. Namun, cookie memang memiliki beberapa masalah yang sudah kita bahas.

Cookie telah rentan terhadap serangan XSS seperti yang telah kita sebutkan sebelumnya, dan juga menerima publisitas buruk ketika situs (terutama situs periklanan) menggunakan third-party cookies untuk melacak pengguna di Internet. Cookie pihak ketiga adalah cookie yang ditetapkan dari domain yang berbeda dari domain di bilah alamat browser. Cookie pihak ketiga memiliki peluang ini karena banyak situs web, saat mengirim sumber daya halaman kembali ke klien, akan menyertakan tautan ke skrip atau gambar dari URL lain. Permintaan yang masuk ke URL lain memungkinkan situs lain mengatur cookie.

Sebagai contoh, laman Beranda di server.com dapat mencakup<script></script> Ini memungkinkan bigadvertising.com mengirimkan cookie saat pengguna melihat konten dari server.com. Cookie hanya dapat kembali ke bigadvertising.com, tetapi jika cukup banyak situs web menggunakan bigadvertising.com, maka Iklan Besar dapat mulai mem-profil pengguna individual dan situs yang mereka kunjungi. Sebagian besar browser web memungkinkan Anda menonaktifkan cookie pihak ketiga (tetapi diaktifkan secara default).

Namun, dua kelemahan terbesar pada cookie adalah bagaimana mereka mengganggu cache dan bagaimana mereka mengirimkan data dengan setiap permintaan. Setiap respons dengan header Set-Cookie tidak boleh di-cache, setidaknya bukan header, karena ini dapat mengganggu identifikasi pengguna dan menciptakan masalah keamanan. Juga, perlu diingat bahwa apa pun yang disimpan di cookie terlihat saat berjalan melintasi jaringan (dan dalam kasus cookie tetap, saat berada di sistem file). Karena kita tahu ada banyak perangkat yang dapat mendengarkan dan menafsirkan lalu lintas HTTP, cookie tidak boleh menyimpan informasi sensitif. Bahkan pengidentifikasi sesi berisiko, karena jika seseorang dapat mencegat ID pengguna lain, dia dapat mencuri data sesi dari server.

Bahkan dengan semua kerugian ini, cookie tidak akan hilang. Terkadang kita perlu negara untuk melakukan perjalanan melalui HTTP, dan cookie menawarkan kemampuan ini dengan cara yang mudah, sebagian besar transparan. Kemampuan lain yang kadang-kadang kita butuhkan adalah kemampuan untuk mengotentikasi pengguna. Kami akan membahas fitur otentikasi berikutnya.


Otentikasi

Proses otentikasi memaksa pengguna untuk membuktikan identitasnya dengan memasukkan nama pengguna dan kata sandi, atau email dan PIN, atau beberapa jenis kredensial lainnya.

Di tingkat jaringan, otentikasi biasanya mengikuti format tantangan/tanggapan. Klien akan meminta sumber daya yang aman, dan server akan menantang klien untuk mengotentikasi. Klien kemudian perlu mengirim permintaan lain dan menyertakan kredensial otentikasi untuk server untuk memvalidasi. Jika kredensial bagus, permintaan akan berhasil.

Perpanjangan HTTP memungkinkan HTTP untuk mendukung berbagai protokol otentikasi. Pada bagian ini kita akan melihat secara singkat 5 teratas: dasar, ringkasan, Windows, formulir, dan OpenID. Dari kelima ini, hanya dua yang "resmi" dalam spesifikasi HTTP - protokol otentikasi dasar dan cerna. Kita akan melihat kedua ini terlebih dahulu.


Otentikasi Dasar

Dengan otentikasi dasar, klien akan terlebih dahulu meminta sumber daya dengan pesan HTTP normal.

Server web akan memungkinkan Anda mengkonfigurasi akses ke file dan direktori tertentu. Anda dapat mengizinkan akses ke semua pengguna anonim, atau membatasi akses sehingga hanya pengguna atau grup tertentu yang dapat mengakses file atau direktori. Untuk permintaan sebelumnya, mari bayangkan server dikonfigurasi untuk hanya mengizinkan pengguna tertentu untuk melihat /html5/ sumber daya. Dalam hal ini, server akan mengeluarkan tantangan otentikasi.

Kode status 401 memberi tahu klien bahwa permintaan itu tidak sah. Header WWW-Authenticate memberi tahu klien untuk mengumpulkan kredensial pengguna dan mencoba lagi. Atribut realm memberi agen pengguna string yang dapat digunakan sebagai deskripsi untuk kawasan lindung. Apa yang terjadi selanjutnya tergantung pada agen pengguna, tetapi sebagian besar browser dapat menampilkan UI bagi pengguna untuk memasukkan kredensial.

Figure 8: Authentication dialog
Dialog otentikasi

Dengan kredensial di tangan, browser dapat mengirim permintaan lain ke server. Permintaan ini akan menyertakan header Authorization.

Nilai header otorisasi adalah nama pengguna dan kata sandi klien dalam enkode 64 dasar. Basic authentication is insecure by default, karena siapa pun dengan basis 64 dekoder yang dapat melihat pesan dapat mencuri kata sandi pengguna. Untuk alasan ini, otentikasi dasar jarang digunakan tanpa menggunakan HTTP aman, yang akan kita lihat nanti.

Terserah server untuk memecahkan kode header otorisasi dan memverifikasi nama pengguna dan kata sandi dengan sistem operasi, atau sistem manajemen kredensial apa pun yang ada di server. Jika kredensial cocok, server dapat membuat balasan normal. Jika kredensial tidak cocok, server akan merespons dengan status 401 lagi.


Otentikasi Digest

Otentikasi digest adalah perbaikan atas otentikasi dasar karena tidak mengirimkan kata sandi pengguna menggunakan enkode 64 dasar (yang pada dasarnya mentransmisikan kata sandi dalam teks biasa). Sebaliknya, klien harus mengirim digest kata sandi. Klien menghitung intisari menggunakan algoritma hashing MD5 dengan nonce server menyediakan selama tantangan otentikasi (Nonce adalah nomor kriptografi yang digunakan untuk membantu mencegah serangan replay).

Respon tantangan mencerna serupa ke respon tantangan otentikasi dasar, tetapi dengan tambahan nilai-nilai yang berasal dari server di header WWW-otentikasi untuk digunakan dalam fungsi kriptografi.

Otentikasi digest lebih baik daripada otentikasi dasar ketika HTTP aman tidak tersedia, tetapi masih jauh dari sempurna. Otentikasi digest masih rentan terhadap serangan man-in-the-middle di mana seseorang mengendus lalu lintas jaringan.


Otentikasi Windows

Windows Integrated Authentication bukan protokol otentikasi standar tetapi sangat populer di antara produk dan server Microsoft. Meskipun Windows Authentication didukung oleh banyak peramban modern (bukan hanya Internet Explorer), Windows tidak dapat berfungsi dengan baik di Internet atau di mana server proxy berada. Anda akan menemukannya di situs web internal dan intranet tempat server Microsoft Active Directory ada.

Otentikasi Windows tergantung pada protokol otentikasi yang didukung oleh Windows, termasuk NTLM dan Kerberos. Langkah-langkah tantangan/tanggapan Autentikasi Windows sangat mirip dengan apa yang telah kita lihat, tetapi server akan menentukan NTLM atau Negotiate dalam header WWW-Authenticate (Negotiate adalah protokol yang memungkinkan klien untuk memilih Kerberos atau HTML).

Otentikasi Windows memiliki keuntungan menjadi aman bahkan tanpa menggunakan HTTP aman, dan menjadi tidak mengganggu bagi pengguna Internet Explorer. IE akan secara otomatis mengotentikasi pengguna ketika ditantang oleh server, dan akan melakukannya dengan menggunakan kredensial pengguna yang ia gunakan untuk masuk ke sistem operasi Windows.


Otentikasi Berbasis Formulir

Bentuk otentikasi adalah pendekatan yang paling populer untuk otentikasi pengguna melalui Internet. Autentikasi berbasis bentuk bukanlah protokol otentikasi standar dan tidak menggunakan header WWW-Authenticate atau Authorization. Namun, banyak kerangka kerja aplikasi web menyediakan beberapa dukungan kotak untuk otentikasi berbasis form.

Dengan otentikasi berbasis form, aplikasi akan menanggapi permintaan untuk sumber daya yang aman oleh pengguna anonim dengan mengarahkan pengguna ke halaman login. Pengalihan adalah pengalihan sementara HTTP 302. Secara umum, URL yang diminta pengguna mungkin dimasukkan dalam string kueri lokasi pengarahan ulang sehingga setelah pengguna menyelesaikan proses masuk, aplikasi dapat mengalihkan pengguna ke sumber daya aman yang ingin dia jangkau.

Halaman login untuk otentikasi berbasis form adalah bentuk HTML dengan masukan bagi pengguna untuk memasukkan kredensial. Ketika pengguna mengklik mengirimkan, nilai-nilai bentuk akan POST ke tujuan di mana aplikasi perlu mengambil kredensial dan memvalidasi mereka terhadap catatan database atau sistem operasi.

Perhatikan bahwa otentikasi berbasis form akan mengirimkan kredensial pengguna dalam teks biasa, jadi seperti otentikasi dasar, otentikasi berbasis form tidak aman kecuali Anda menggunakan HTTP aman. Sebagai tanggapan terhadap pesan POST dengan kredensial (dengan asumsi kredensial yang baik), aplikasi biasanya akan mengarahkan pengguna kembali ke sumber daya aman dan juga mengatur cookie yang menunjukkan pengguna sekarang diotentikasi.

Untuk ASP.NET, tiket otentikasi (nilai cookie .ASPXAUTH) dienkripsi dan di-hash untuk mencegah gangguan. Namun, tanpa HTTP aman, cookie rentan disadap, jadi pembajakan sesi masih merupakan masalah potensial. Namun, bentuk otentikasi tetap populer karena memungkinkan aplikasi kontrol penuh atas pengalaman masuk dan validasi kredensial.


OpenID

Sementara otentikasi berbasis form memberikan aplikasi kontrol total atas otentikasi pengguna, banyak aplikasi yang tidak menginginkan level kontrol ini. Secara khusus, aplikasi tidak ingin mengelola dan memverifikasi nama pengguna dan kata sandi (dan pengguna tidak ingin memiliki nama pengguna dan kata sandi yang berbeda untuk setiap situs web). OpenID adalah standar terbuka untuk otentikasi terdesentralisasi. Dengan OpenID, pengguna mendaftar dengan penyedia identitas OpenID, dan penyedia identitas adalah satu-satunya situs yang perlu menyimpan dan memvalidasi kredensial pengguna. Ada banyak penyedia OpenID di sekitar, termasuk Google, Yahoo, dan Verisign.

Ketika suatu aplikasi perlu mengotentikasi pengguna, aplikasi itu bekerja dengan pengguna dan penyedia identitas pengguna. Pengguna akhirnya harus memverifikasi nama pengguna dan kata sandinya dengan penyedia identitas, tetapi aplikasi akan tahu apakah otentikasi berhasil berkat kehadiran token dan rahasia kriptografi. Google memiliki ikhtisar proses pada laman web "Pengguna Masuk Federasi untuk Pengguna Akun Google" (https://developers.google.com/accounts/docs/OpenID).

Sementara OpenID menawarkan banyak manfaat potensial dibandingkan dengan bentuk otentikasi, OpenID telah menghadapi kurangnya adopsi karena kompleksitas dalam mengimplementasikan, debugging, dan mempertahankan tari login OpenID. Kita harus berharap toolkit dan kerangka kerja terus berevolusi agar pendekatan OpenID lebih mudah untuk otentikasi.


HTTP Aman

Sebelumnya kita telah menyebutkan bagaimana pesan HTTP tekstual yang menggambarkan diri sendiri adalah salah satu kekuatan web. Siapa pun dapat membaca pesan dan memahami isi yang ada di dalamnya. Namun, ada banyak pesan yang kita kirim melalui web yang tidak ingin dilihat orang lain. Kita telah membahas beberapa skenario tersebut dalam buku ini. Kita tidak ingin orang lain di jaringan untuk melihat kata sandi Anda, misalnya, tetapi juga tidak ingin mereka melihat nomor kartu kredit atau nomor rekening bank. Secure HTTP memecahkan masalah ini dengan mengenkripsi pesan sebelum pesan mulai melakukan perjalanan di seluruh jaringan.

Secure HTTP juga dikenal sebagai https (karena menggunakan skema https di URL, bukan skema http biasa). Port default untuk HTTP adalah port 80, dan port default untuk HTTPS adalah port 443. Browser akan terhubung ke port yang tepat tergantung pada skema (kecuali harus menggunakan port eksplisit yang ada di URL). HTTPS bekerja dengan menggunakan layer keamanan tambahan di tumpukan protokol jaringan. Layer keamanan ada antara layer HTTP dan TCP, dan fitur penggunaan protokol Transport Layer Security (TLS) atau pendahulunya TLS yang dikenal sebagai Secure Sockets Layer (SSL).

Figure 9: Secure HTTP protocol layers
Lapisan protokol HTTP aman

HTTPS memerlukan server untuk memiliki sertifikat kriptografi. Sertifikat dikirim ke klien saat pengaturan komunikasi HTTPS. Sertifikat termasuk nama host server, dan agen pengguna dapat menggunakan sertifikat untuk memvalidasi bahwa itu benar-benar berbicara dengan server yang dianggapnya sedang berbicara. Validasi semua dimungkinkan dengan menggunakan kriptografi kunci publik dan keberadaan otoritas sertifikat, seperti Verisign, yang akan menandatangani dan menjamin integritas sertifikat. Administrator harus membeli dan memasang sertifikat dari otoritas sertifikat.

Ada banyak detail kriptografi yang dapat diliput, tetapi dari perspektif pengembang, hal yang paling penting untuk diketahui tentang HTTPS adalah:

  • Semua lalu lintas melalui HTTPS dienkripsi dalam permintaan dan respons, termasuk header HTTP dan badan pesan, dan juga semuanya setelah nama host di URL. Ini berarti jalur dan data string kueri dienkripsi, serta semua cookie. HTTPS mencegah pembajakan sesi karena tidak ada penyadap dapat memeriksa pesan dan mencuri cookie.
  • Server diautentikasi ke klien berkat sertifikat server. Jika Anda berbicara dengan mybigbank.com melalui HTTPS, Anda dapat yakin pesan Anda benar-benar akan ke mybigbank.com dan bukan seseorang yang memasang server proxy di jaringan untuk mencegat permintaan dan lalu lintas respon spoof dari mybigbank.com
  • HTTPS tidak mengotentikasi klien. Aplikasi masih perlu mengimplementasikan otentikasi bentuk atau salah satu dari protokol otentikasi lain yang disebutkan sebelumnya jika mereka perlu mengetahui identitas pengguna. HTTPS tidak membuat otentikasi berbasis-formasi dan otentikasi dasar lebih aman karena semua data dienkripsi. Ada kemungkinan menggunakan sertifikat sisi klien dengan HTTPS, dan sertifikat sisi klien akan mengautentikasi klien dengan cara yang paling aman. Namun, sertifikat sisi klien umumnya tidak digunakan di Internet terbuka karena tidak banyak pengguna yang akan membeli dan memasang sertifikat pribadi. Korporasi mungkin memerlukan sertifikat klien bagi karyawan untuk mengakses server perusahaan, tetapi dalam hal ini perusahaan dapat bertindak sebagai otoritas sertifikat dan mengeluarkan sertifikat karyawan yang dibuat dan dikelolanya.

HTTPS memang memiliki beberapa kelemahan dan sebagian besar terkait dengan kinerja. HTTPS adalah komputasi mahal, dan situs besar sering menggunakan perangkat keras khusus (akselerator SSL) untuk mengambil beban komputasi kriptografi dari server web. Lalu lintas HTTPS juga tidak dapat disimpan dalam cache publik, tetapi agen pengguna mungkin menyimpan tanggapan HTTPS di cache pribadi mereka. Akhirnya, koneksi HTTPS mahal untuk diatur dan memerlukan jabat tangan tambahan antara klien dan server untuk bertukar kunci kriptografi dan memastikan semua orang berkomunikasi dengan protokol aman yang tepat. Koneksi yang persisten dapat membantu mengamortisasi biaya ini.

Pada akhirnya, jika Anda membutuhkan komunikasi yang aman, Anda dengan senang hati akan membayar denda kinerja.


Di mana kita?

Dalam artikel ini kita telah melihat cookie, otentikasi, dan HTTP aman. Jika Anda telah menyelesaikan seluruh sesi ini, saya harap Anda telah menemukan beberapa informasi berharga yang akan membantu Anda ketika Anda menulis, memelihara, dan men-debug aplikasi web.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.