it-swarm-tr.com

Bir isteğin URL'sine bir API anahtarı eklemek güvenli midir?

Son zamanlarda böyle tasarlanmış birçok API gördüm:

curl "https://api.somewebsite.com/v1/something&key=YOUR-API-KEY"

URL'nin bir parçası olarak bir sorgu dizesine API anahtarı geçirmenin en azından HTTP'de güvenli olması temel değildir.

117
アレックス

Özet:yetenek URL'leri, birçok kişinin kredi verdiğinden daha güvenlidir, ancak tüm uygulamalar için uygun değildir veiçin ekstra özen gerektirir.


Bu tür URL'ler genellikle yetenek/gizli URL'ler olarak bilinir.

Bir tehdit modeli belirlemeden güvenlik hakkında konuşmak anlamsızdır. İşte akla gelen bir çift:

  • 1: Ağdaki pasif bir saldırgan (kulak misafiri)
  • 2: Ağdaki etkin bir saldırgan (paketleri, istek, mitm vb.
  • 3: A omuz sörfçüsü
  • 4: Bilgisayarınıza fiziksel erişime sahip bir saldırgan/yükseltilmiş ayrıcalıklar
  • 5: bilgisayarınızın başka bir kullanıcısı (normal ayrıcalıklar/uzaktan erişim)
  • 6: kullanıcının kendisi (bir API anahtarını korumada olduğu gibi)

Ağ saldırılarına (1 ve 2) ilişkin olarak, HTTPS kullanmanız koşuluyla gizli URL'ler tamamen güvenlidir(2016, artık HTTP kullanmamalısınız!).

Bir sunucunun ana bilgisayar adı ağ üzerinden düz metin olarak gönderilirken, gerçek URL sunucuya gönderilmeden önce şifrelenir - GET isteğinin bir parçası olduğu için, yalnızca after TLS anlaşması.


Omuz sörfü (3) ile ilgili olarak, yeterli entropiye sahip gizli bir URL, sıradan bir saldırıya karşı oldukça güvenlidir· Örneğin, bir google doküman URL'si vereceğim:

https://docs.google.com/document/d/5BPuCpxGkVOxkjTG0QrS-JoaImEE-kNAi0Ma9DP1gy

Bir iş arkadaşının ekranından geçerken bunu hatırlamakta iyi şanslar!

Açıktır ki,saldırganınızın bir kamerası varsa ve fark edilmeden resim çekebiliyorsa, bu tamamen farklı bir konudur- bu durumda gizli bir URL kullanmamalısınız. Gizli URL'den uzakta bir HTTP yönlendirmesi yaparak saldırıyı hafifletebilirsiniz, böylece yalnızca birkaç saniye ekranda kalır


Bilgisayarınızda yükseltilmiş ayrıcalıklara sahip bir saldırganla ilgili olarak (4), gizli bir URL uzun bir parolaveya hatta istemci tarafı TLS sertifikasından daha az güvenli değildir - bunların hepsi tamamen güvensizdir ve bu konuda yapabileceğiniz çok şey yok.

Diğer yandan, düzenli ayrıcalıklara sahip bir saldırgan (5), OSiçin iyi güvenlik uygulamalarını izlediğiniz sürece gizli URL'yi de öğrenememelidir. Dosyalarınız (özellikle tarayıcı geçmişi) diğer kullanıcılar tarafından okunmamalıdır.


API anahtarlarını korumak için (bu sorunun asıl noktası olan 6), gizli bir URL de başka bir mekanizmadan (AJAX POST gibi) daha az güvenli değildir. Bir API anahtarı için kullanımı olan herkes, anahtarı almak için tarayıcı hata ayıklama modunun nasıl kullanılacağını bilir.

Birisine bir sır göndermek ve onlardan bakmamalarını beklemek mantıklı değil!


Bazı insanlar sunucu tarafındaki riskleri sordular.

Sunucu tarafı risklerini tehdit modellemesi ile tedavi etmek makul değildir; kullanıcı açısından bakıldığında, gerçekten güvenilir bir üçüncü taraf gibi davranmanız gerekir, rakiplerinizin sunucu tarafında dahili ağ erişimi varmış gibi, gerçekten yapabileceğiniz hiçbir şey yok ( istemcinin bilgisayarındaki ayrıcalıklı bir saldırgana benzer, yani yukarıdaki tehdit modeli 4).

Saldırıları modellemek yerine,kasıtsız gizli maruz kalmanın ortak riskleriniana hatlarıyla açıklayacağım.

Sunucu tarafında gizli URL kullanımıyla ilgili en yaygın endişe, hemHTTP sunucusunun hem de ters proxy'lerin günlük tutması ve URL'nin genellikleiçermesidir.

Başka bir olasılık dagizli URL'lerin tahmin edilebilir bir şekilde oluşturulabilmesidir- kusurlu bir uygulama, güvensiz [~ # ~] prng [~ # ~ ] ya da tohumladığında yetersiz entropi verilmesi .

Gizli URL'ler kullanan bir site tasarlanırken dikkate alınması gereken birçok uyarı da vardır. W3C TAG 'nın bu sayfası birçoğunu kapsar.

Uygulamada, dinamik içeriğe sahip siteler için her şeyin güvenli bir şekilde yapılması oldukça zordur - hem Google hem de Dropbox geçmiş, değerinde belirtildiği gibi bu cevap


Son olarak,gizli URL'lerin diğer kimlik doğrulama yöntemlerine göre birkaç avantajı vardır:

  • Kullanımı son derece kolaydır (e-posta ve şifrenizi girmek yerine bağlantıyı tıklamanız yeterlidir)
  • Sunucu/hizmetin hassas kullanıcı kimlik bilgilerini güvenli bir şekilde depolamasını gerektirmez
  • Parolanızı paylaşmanın aksine (diğer 50 site için yeniden kullanırsınız) risk almadan kolayca paylaşılabilirler.
153
goncalopp

Bu, API'nın nasıl kullanılması gerektiğine ve ne tür verilere eriştiğine bağlıdır. Google haritalarına erişen bir şey (örneğin), bankacılık verilerine erişen bir şeyden çok daha düşük risktir.

Açıkçası, istemci tarafı kodunda böyle bir çağrı güvensizdir, kullanıcı API anahtarınızı kolayca öğrenebilir.

API çağrısı sunucudan sunucuya yapılırsa, sorun daha azdır.

HTTP kullanmak bağlantıyı gizli dinlemeye açık bırakır, HTTPS bu sorunu ortadan kaldırır.

URL'deki anahtarlarla ilgili bir başka sorun, tam URL'nin günlük dosyalarına girmesidir. Bu, artık anahtar aramak için daha fazla yer olduğu için uygulama için saldırı yüzeyini genişletiyor.

Sorunuzu cevaplamak için, URL'deki anahtarları geçmek doğal olarak güvensiz değildir, alternatiflerden daha az güvenlidir ve en iyi uygulama değildir. API'nın hassas bir şeye erişmediği, bağlantı HTTPS üzerinden yapıldığı ve çağrının sunucudan sunucuya yapıldığı varsayıldığında, düşük riskli hizmetler için 'yeterince iyi' olmalıdır.

22
Jay

Sırları genel olarak GET parametreleri olarak iletmek iyi bir fikir değildir. Potansiyel güvenlik sorunları hakkında bir liste blogumda bir süre önce derledim:

Sırlar aşağıdaki gibi diğer taraflara sızabilir:

Bilgisayarınızdan/akıllı telefonunuzdan

sunucu tarafı

  • Web sunucusu günlükleri
  • SIEM, Elasticsearch, Splunk gibi log toplama hizmetleri
  • Arama motorları tarafından dizine eklenen günlük dosyaları (alakalı Google dork )
  • Ters proxy günlükleri

Üçüncü Taraflara

  • Proxy günlükleri (örneğin, kurumsal bir ortamda)
  • Rollbar veya Sentry gibi istisna raporlama hizmetleri
  • Referer başlığı üzerinden diğer web siteleri
  • URL'nin bir e-posta veya IM iletisinde paylaşılması durumunda bir arkadaş
  • Genel bulutta diğer kiracılar

Bazıları Ajax istekleri için geçerli değildir, ancak ymmv

10
Gabor

Neden kimse açıkça oturum fiksasyonu ve CSRF güvenlik açıkları riskinden bahsetmiyor. Tabii ki CSRF jetonları ekleyerek bunları azaltabilir ve güvenli oturum işleme uygulayabilirsiniz, ancak bu aslında ilgili kod üzerinde kontrolünüz olduğu anlamına gelir.

Bu soru A secret in a URL Bazı insanlar, kaçınılabilecek olası saldırı vektörü olarak görmek yerine, bazı hafifletici önlemler uygularlarsa yeterli olduğu sonucuna varabilirler.

0
Noir