Apakah string kueri HTTPS aman?

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?

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.

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.

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.

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.

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.

Ya, selama tidak ada orang yang melihat monitor Anda.

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.

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

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