HTTPS sorgu dizesi güvenli midir?

HTTPS kullanan güvenli bir web tabanlı API oluşturuyorum; Ancak, kullanıcıların bir sorgu dizesi kullanarak yapılandırmasına izin verirseniz (şifre gönderme dahil) bu da güvenli olacak mı yoksa bir POST yoluyla yapılmasını zorlamalı mıyım?

Evet öyle. Ancak hassas veriler için GET kullanmak birkaç nedenden dolayı kötü bir fikirdir :

• Çoğunlukla HTTP yönlendiren sızıntısı (hedef sayfadaki harici bir resim şifre sızdırıyor olabilir [1])
• Şifre sunucu kayıtlarında saklanacaktır (ki bu kesinlikle kötüdür)
• Tarayıcılarda geçmiş önbellekleri

Bu nedenle, Querystring güvenli olmasına rağmen, hassas verilerin sorgu dizesi üzerinden aktarılması önerilmez.

[1] RFC'nin tarayıcının HTTPS'den HTTP'ye yönlendirmeleri göndermemesi gerektiğini belirtmesine rağmen. Ancak bu, kötü bir 3. taraf tarayıcı araç çubuğunun veya HTTPS sitesindeki harici bir görüntünün / flaşın sızdırmayacağı anlamına gelmez.

"Ağ paketini kokla" bakış açısından, GET isteği güvenlidir, çünkü tarayıcı önce güvenli bağlantıyı kuracak ve daha sonra GET parametrelerini içeren isteği gönderecektir. Ancak GET URL'leri, kullanıcıların şifre geçmişinde / otomatik tamamlamada saklanır; bu, örneğin şifre verilerini depolamak için iyi bir yer değildir. Tabii ki bu, yalnızca bir tarayıcıdan hizmete erişebilecek daha geniş "Web Hizmeti" tanımını alırsanız, yalnızca özel uygulamanızdan erişiyorsanız bu bir sorun olmamalıdır.

Bu yüzden en azından şifre iletişim kutuları için yazı kullanmak tercih edilmelidir. Ayrıca bağlantıda belirtildiği gibi littlegeek bir GET URL yayınlanan sunucu günlüklerine yazma olasılığı daha yüksektir.

Evet , sorgu dizeleriniz şifrelenecek.

Bunun nedeni sorgu dizelerinin bir uygulama katmanı protokolü olan HTTP protokolünün bir parçası olması, güvenlik (SSL / TLS) kısmının ise aktarım katmanından gelmesidir. Önce SSL bağlantısı kurulur ve daha sonra sorgu parametreleri (HTTP protokolüne ait olan) sunucuya gönderilir.

Bir SSL bağlantısı kurarken, müşteriniz aşağıdaki adımları sırayla gerçekleştirecektir. Adlı bir siteye giriş yapmaya çalışıyoruz varsayalım example.com ve sorgu parametreleri kullanarak kimlik bilgilerinizi göndermek istiyorum. Tam URL'niz aşağıdaki gibi görünebilir:

https://example.com/login?username=alice&password=12345)

1. İstemciniz (örn. Tarayıcı / mobil uygulama) ilk önce alan adınızı bir DNS isteği kullanarak bir example.comIP adresine çözümler (124.21.12.31). Bu bilgi sorgulanırken yalnızca alana özel bilgiler kullanılır, yani yalnızca example.comkullanılır.
2. Şimdi, istemciniz sunucuya IP adresi 124.21.12.31ile bağlanmaya çalışacak ve 443 numaralı bağlantı noktasına (varsayılan HTTP bağlantı noktası 80 değil SSL hizmet bağlantı noktası) bağlanmaya çalışacaktır.
3. Şimdi, adresindeki sunucu example.comsertifikalarını istemcinize gönderecek.
4. Müşteriniz sertifikaları doğrulayacak ve oturumunuz için paylaşılan bir gizli anahtar değiştirmeye başlayacaktır.
5. Güvenli bağlantı başarıyla kurulduktan sonra, sorgu parametreleriniz güvenli bağlantı üzerinden gönderilir.

Bu nedenle, hassas verileri göstermezsiniz. Ancak, kimlik bilgilerinizi bu yöntemi kullanarak bir HTTPS oturumu üzerinden göndermek en iyi yol değildir. Farklı bir yaklaşım benimsemelisiniz.

Evet. Bir HTTPS oturumunun tüm metni SSL ile korunmaktadır. Buna sorgu ve başlıklar da dahildir. Bu açıdan, bir POST ve bir GET tamamen aynı olacaktır.

Metodunuzun güvenliğine gelince, uygun bir inceleme yapmadan söylemenin gerçek bir yolu yoktur.

SSL önce ana bilgisayara bağlanır, bu nedenle ana makine adı ve bağlantı noktası numarası açık metin olarak aktarılır. Ana bilgisayar yanıt verdiğinde ve sorun başarılı olduğunda, istemci HTTP isteğini gerçek URL ile (yani üçüncü eğik çizgiden sonraki herhangi bir şey) şifreleyecek ve sunucuya gönderecektir.

Bu güvenliği kırmanın birkaç yolu vardır.

Bir proxy'yi "ortadaki adam" olarak davranacak şekilde yapılandırmak mümkündür. Temel olarak, tarayıcı gerçek sunucuya proxy'ye bağlanma isteğini gönderir. Proxy bu şekilde yapılandırılırsa, SSL aracılığıyla gerçek sunucuya bağlanır, ancak tarayıcı yine de proxy ile konuşur. Dolayısıyla, bir saldırgan proxy'ye erişebiliyorsa, içinden akan tüm verileri açık metin olarak görebilir.

İstekleriniz tarayıcı geçmişinde de görünecektir. Kullanıcılar siteye yer işareti koymaya cazip gelebilir. Bazı kullanıcılar yüklü yer imi senkronizasyon araçlarına sahiptir, bu nedenle şifre deli.ci.us veya başka bir yerde bulunabilir.

Son olarak, birisi bilgisayarınızı hacklemiş ve bir klavye kaydedici veya bir ekran kazıyıcı kurmuş olabilir (ve bir çok Truva Atı türü virüs bunu yapar). Parola doğrudan ekranda görülebildiğinden (parola iletişim kutusundaki "*" yerine), bu başka bir güvenlik açığıdır.

Sonuç: Güvenlik söz konusu olduğunda, daima dayak yoluna güvenin. Bilmediğiniz, düşünmeyeceğiniz ve boynunuzu kıracak çok fazla şey var.

Evet, kimse ekranda omzunun üzerinden bakmadığı sürece.

Ben yaklaşık deyimi ile aynı fikirde değilim [...] HTTP yönlendirmesi kaçağı (hedef sayfasında harici görüntü parolası sızabilir) içinde Slough tepki .

HTTP 1.1 RFC açıkça şunları belirtir :

İstemciler, yönlendiren sayfa güvenli bir protokolle aktarıldıysa (güvenli olmayan) bir HTTP isteğine bir Yönlendirme başlığı alanı İÇERMEMELİDİR.

Her neyse, sunucu günlükleri ve tarayıcı geçmişi, hassas verileri sorgu dizesine koymamak için yeterli nedenlerdir.

Evet, bir HTTPS bağlantısı kurduğunuz andan itibaren her şey güvende. POST olarak sorgu dizesi (GET) SSL üzerinden gönderilir.

Biraz tuz eklenmiş olarak şifreyi MD5 karma parametresi olarak gönderebilirsiniz. Kimlik doğrulaması için sunucu tarafında karşılaştırın.