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.
Ö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:
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:
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.
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.
Son olarak,gizli URL'lerin diğer kimlik doğrulama yöntemlerine göre birkaç avantajı vardır:
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.
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ı
Üçüncü Taraflara
Refererbaşlığı üzerinden diğer web siteleri
Bazıları Ajax istekleri için geçerli değildir, ancak ymmv
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.