Apakah string kueri HTTPS aman?


351

Saya membuat API berbasis web yang aman yang menggunakan HTTPS; namun, jika saya mengizinkan pengguna untuk mengkonfigurasinya (termasuk mengirim kata sandi) menggunakan string kueri apakah ini juga akan aman atau haruskah saya memaksanya dilakukan melalui POST?

Jawaban:


453

Ya itu. Tetapi menggunakan GET untuk data sensitif adalah ide yang buruk karena beberapa alasan:

  • Sebagian besar kebocoran pengarah HTTP (gambar eksternal di halaman target mungkin bocor kata sandi [1])
  • Kata sandi akan disimpan dalam log server (yang jelas-jelas buruk)
  • Tembolok riwayat di peramban

Oleh karena itu, meskipun Querystring diamankan, tidak disarankan untuk mentransfer data sensitif melalui querystring.

[1] Meskipun saya perlu mencatat bahwa RFC menyatakan bahwa browser tidak boleh mengirim referer dari HTTPS ke HTTP. Tapi itu tidak berarti toolbar browser pihak ke-3 yang buruk atau gambar / flash eksternal dari situs HTTPS tidak akan bocor.


4
Bagaimana dengan https ke https referer? Jika saya mendapatkan gambar dari situs pihak ke-3 menggunakan https? Apakah browser akan mengirim seluruh string permintaan dari permintaan saya sebelumnya ke server pihak ke-3?
Jus12

4
@ Jus12 ya itu akan, itu tidak masuk akal tapi begitulah dirancang.
dr. evil

2
Lalu mengapa spesifikasi OAuth2 tidak disarankan untuk mengirim data sensitif dalam parameter kueri (di URL)? Meskipun disarankan untuk menggunakan TLS (HTTPS) selalu. Merujuk pada poin terakhir di tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 CC @volka
gihanchanuka

@ dr.evil Bisakah Anda jelaskan apa masalahnya History caches in browsersatau tambahkan beberapa referensi untuk ir?
LCJ

1
Untuk melengkapi jawaban itu dengan info terkini: securitynewspaper.com/2016/08/01/... (Proxy PAC hack memungkinkan untuk mencegat URL HTTPS)
Tom

78

Dari sudut pandang "mengendus paket jaringan" permintaan GET aman, karena browser pertama-tama akan membuat koneksi aman dan kemudian mengirim permintaan yang berisi parameter GET. Tetapi url GET akan disimpan dalam riwayat browser / autocomplete pengguna, yang bukan tempat yang baik untuk menyimpan misalnya data kata sandi. Tentu saja ini hanya berlaku jika Anda mengambil definisi "layanan Web" yang lebih luas yang mungkin mengakses layanan dari browser, jika Anda mengaksesnya hanya dari aplikasi khusus Anda ini seharusnya tidak menjadi masalah.

Jadi menggunakan posting setidaknya untuk dialog kata sandi harus lebih disukai. Juga seperti yang ditunjukkan pada tautan littlegeek yang diposting URL GET lebih mungkin ditulis ke log server Anda.


48

Ya , string kueri Anda akan dienkripsi.

Alasan di belakang adalah bahwa string kueri adalah bagian dari protokol HTTP yang merupakan protokol lapisan aplikasi, sedangkan bagian keamanan (SSL / TLS) berasal dari lapisan transport. Sambungan SSL dibuat terlebih dahulu dan kemudian parameter kueri (yang termasuk dalam protokol HTTP) dikirim ke server.

Saat membuat koneksi SSL, klien Anda akan melakukan langkah-langkah berikut secara berurutan. Misalkan Anda mencoba masuk ke situs bernama example.com dan ingin mengirim kredensial Anda menggunakan parameter kueri. URL lengkap Anda mungkin terlihat seperti berikut:

https://example.com/login?username=alice&password=12345)
  1. Klien Anda (mis., Browser / aplikasi seluler) pertama-tama akan menyelesaikan nama domain Anda example.comke alamat IP (124.21.12.31)menggunakan permintaan DNS. Saat menanyakan informasi itu, hanya informasi spesifik domain yang digunakan, yaitu hanya example.comakan digunakan.
  2. Sekarang, klien Anda akan mencoba untuk terhubung ke server dengan alamat IP 124.21.12.31dan akan berusaha untuk terhubung ke port 443 (port layanan SSL bukan port HTTP default 80).
  3. Sekarang, server di example.comakan mengirimkan sertifikatnya ke klien Anda.
  4. Klien Anda akan memverifikasi sertifikat dan mulai bertukar kunci rahasia bersama untuk sesi Anda.
  5. Setelah berhasil membangun koneksi yang aman, hanya parameter permintaan Anda akan dikirim melalui koneksi yang aman.

Karenanya, Anda tidak akan mengekspos data sensitif. Namun, mengirimkan kredensial Anda melalui sesi HTTPS menggunakan metode ini bukan cara terbaik. Anda harus menggunakan pendekatan yang berbeda.


2
Tetapi lihat jawabannya oleh @dr. jahat, string tambang mungkin berakhir di file log dan cache sehingga tidak aman di server.
zaph

3
Hai zaph, dalam hal keamanan HTTPS, tujuannya adalah untuk mengirim data dengan aman ke server tanpa ada orang di tengah yang bisa mengendus data. Walaupun itu mungkin, dan menjawab pertanyaan, sangat sulit untuk mengontrol apa yang dilakukan server setelahnya. Itu sebabnya saya juga menyebutkan ini bukan cara yang benar. Selain itu, Anda tidak boleh mengirim kata sandi Anda dari klien. Anda harus selalu mengaitkannya di perangkat dan mengirim nilai hash ke server.
Ruchira Randana

Dari sudut pandang keamanan mengirim informasi rahasia dalam string tambang tidak aman, yang terbaik adalah mengirimkannya dalam POST. Kata sandi pada umumnya di-hash di server, bukan oleh klien. Pernyataan "Anda tidak harus mengirimkan ur password dari klien" bertentangan dengan jawaban: (e.g http://example.com/login?username=alice&password=12345).
zaph

@RuchiraRandana hashing pada klien tidak ada gunanya karena kunci pribadi kemudian dengan mudah diambil dari ujung depan.
James W

@ JamesW " kunci pribadi kemudian dengan mudah diambil dari ujung depan " Kunci apa?
curiousguy

28

Iya. Seluruh teks dari sesi HTTPS diamankan oleh SSL. Itu termasuk kueri dan header. Dalam hal itu, POST dan GET akan sama persis.

Adapun keamanan metode Anda, tidak ada cara nyata untuk mengatakan tanpa inspeksi yang tepat.


27
Ada lebih banyak keamanan daripada sekadar komunikasi antara browser & server
JoeBloggs

26

SSL pertama-tama terhubung ke host, sehingga nama host dan nomor port ditransfer sebagai teks yang jelas. Ketika tuan rumah merespons dan tantangan berhasil, klien akan mengenkripsi permintaan HTTP dengan URL yang sebenarnya (yaitu apa pun setelah garis miring ketiga) dan dan mengirimkannya ke server.

Ada beberapa cara untuk memecah keamanan ini.

Dimungkinkan untuk mengkonfigurasi proxy untuk bertindak sebagai "man in the middle". Pada dasarnya, browser mengirimkan permintaan untuk terhubung ke server sebenarnya ke proxy. Jika proxy dikonfigurasi dengan cara ini, itu akan terhubung melalui SSL ke server sebenarnya tetapi browser masih akan berbicara dengan proxy. Jadi, jika penyerang bisa mendapatkan akses proxy, ia bisa melihat semua data yang mengalir melalui itu dalam teks yang jelas.

Permintaan Anda juga akan terlihat dalam riwayat browser. Pengguna mungkin tergoda untuk mem-bookmark situs tersebut. Beberapa pengguna menginstal alat sinkronisasi bookmark, sehingga kata sandi bisa berakhir di deli.ci.us atau tempat lain.

Terakhir, seseorang mungkin telah meretas komputer Anda dan menginstal logger keyboard atau scraper layar (dan banyak jenis virus Trojan Horse lakukan). Karena kata sandi terlihat langsung di layar (bukan "*" dalam dialog kata sandi), ini adalah lubang keamanan lain.

Kesimpulan: Ketika datang ke keamanan, selalu mengandalkan jalur yang dipukuli. Ada terlalu banyak yang tidak Anda ketahui, tidak akan dipikirkan dan yang akan mematahkan leher Anda.


3
"peramban masih akan berbicara dengan proksi" tidak sepenuhnya benar, peramban harus memberikan sertifikat yang valid yang hanya dapat dihasilkan oleh peramban jika memiliki kendali atas CA yang dipercayai peramban.
Pieter


10

Saya tidak setuju dengan pernyataan tentang [...] Kebocoran pengarah HTTP (gambar eksternal di halaman target mungkin bocor kata sandi) dalam respons Slough .

HTTP 1.1 RFC secara eksplisit menyatakan :

Klien TIDAK HARUS menyertakan bidang header Perujuk dalam permintaan HTTP (tidak aman) jika halaman referensi ditransfer dengan protokol aman.

Bagaimanapun, log server dan riwayat browser adalah lebih dari cukup alasan untuk tidak memasukkan data sensitif ke string kueri.


2
Ada kata 'harus' lagi. Apakah Anda mempercayai setiap versi setiap browser dengan kata sandi Anda?
JoeBloggs

1
Bagaimana tepatnya ini terkait dengan GET vs POST? Apakah "setiap versi setiap browser" aman jika Anda menggunakan POST melalui HTTPS?
Arnout

2
Selain itu, halaman web HTTPS mungkin mengambil kembali gambar eksternal melalui HTTPS - dalam hal ini, browser HARUS menyertakan header referer, dan dengan demikian memaparkan kata sandi Anda ...
AviD

3
@ Peringatan: Silakan baca RFC ini yang memberi tahu Anda apa yang TIDAK HARUS artinya: ietf.org/rfc/rfc2119.txt BUKAN sama dengan HARUS TIDAK, jadi bagian yang Anda kutip tidak benar-benar relevan dan agen peramban mungkin masih menyertakan referensi. ke HTTP.
Andy

8

Ya, sejak saat Anda membuat koneksi HTTPS semuanya aman. String kueri (GET) sebagai POST dikirim melalui SSL.


-4

Anda dapat mengirim kata sandi sebagai parameter hash MD5 dengan sedikit garam. Bandingkan di sisi server untuk auth.


11
MD5 tidak sesuai fungsi hash untuk kata sandi.
slawek

1
Apakah hash atau dalam teks-jelas, itu praktik yang buruk untuk mengirim kata sandi dalam parameter GET. Silakan merujuk ke jawaban terpilih untuk penjelasan. Aaaand ... MD5 tidak boleh digunakan di mana pun lagi ...
Thomas

" fungsi hash tidak cocok untuk kata sandi " Masih lebih baik daripada mengirim kata sandi dalam teks yang jelas ke server, lol
curiousguy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.