it-swarm-tr.com

API-Anahtar Mekanizması nasıl uygulanır?

her şeyden önce: sorunun başlığı hakkında oldukça emin değilim, bu yüzden daha iyi bir fikriniz varsa, lütfen çekinmeyin:

API'lar sunan ve bir geliştirici olarak sizden bazı API Anahtarlarını kullanmanızı isteyen hizmetlerin (Twitter veya co gibi) üçüncü tarafların bu anahtarı almasını engellediği en iyi uygulama örneklerini bilmek istiyorum.

Saygılarımı kötü örneklerle açıklayacağım:

Bildiğim kadarıyla Twitter ve FB, API istekleri için API Anahtarları kullanmanızı gerektiriyor. Bu, sunucu tarafı uygulamalar için iyidir, ancak anahtarınızı bir web uygulamasından veya masaüstü uygulamasından gönderdiğiniz anda anahtar başkaları tarafından görülebilir.

Bu anahtarı göndermeniz gerektiğinden, uygulamanızın içinde süper güvenli bir şekilde saklamak pek mantıklı değildir. Talep için sade olması gerekir.

Yapabileceğiniz bir şey, anahtar sunucu tarafını ekleyen ve daha sonra bu isteği hedef sunucuya yönlendiren kendi web hizmetinizi veya paketleyicinizi barındırmaktır.

Ancak Twitter/veya kullandığınız herhangi bir hizmet IP başına API isteklerini sınırlıyorsa veya IP tabanlı istatistikler oluşturmak istiyorsanız bu mümkün değildir.

Yani özetlemek gerekirse: Başkaları için bir API oluşturma pozisyonunda olsaydım ve SSL kullanmalarını istemiyorsam, anahtarlarının güvenli olduğundan ve kolayca çalınamayacağından emin olmak için ne gibi olasılıklar olurdu? ?

34
user510083

En iyi uygulama:

Temel fikir. Her ayrı kullanıcı hesabı için bir API anahtarı (128 bit simetrik anahtar) oluşturun. Bu anahtarın sunucuda güvenli bir şekilde saklanması ve ayrıca kullanıcının istemcisinde güvenli bir şekilde saklanması gerekir.

İstemci tarafından yapılan her istek için, tüm istekte "imzası" olan bir ek istek parametresi ekleyin. "İmza" S = MAC ( [~ # ~] k [~ # ~], [~ # ~] r [~ # ~]), burada [~ # ~] k [~ # ~] API anahtarıdır ve [~ # ~] r [~ # ~] = tüm istek parametreleri dahil olmak üzere tüm istektir. Burada MAC, AES-CMAC veya SHA1-HMAC gibi güvenli bir mesaj kimlik doğrulama kodu algoritması olmalıdır.

İmzayı hesaplamak ve talebe eklemek müşterinin sorumluluğundadır; imzayı doğrulamak ve geçersiz imzalı herhangi bir isteği yoksaymak sunucunun sorumluluğundadır. Ayrıca, isteği yapan kullanıcı hesabını tanımlayan isteğe ek bir parametre eklemeniz de gerekebilir.

Bu, isteğin kimlik doğrulamasını sağlar, ancak gizlilik veya yeniden yürütmeyi engellemez ve istemci, sunucudan kimliği doğrulanmış bir yanıt alır.

Tüm istekleri https üzerinden göndermenizi öneririm (http değil). Bu, bir dizi zor duruma karşı ek bir güvenlik seviyesi sağlayacaktır. Bunu yapmanın performans sonuçları düşündüğünüzden daha azdır - SSL çoğu insanın düşündüğünden daha az performansa sahiptir - yani bu fikri performans gerekçesiyle atmayın sürece aslında ölçülen performans yükü ve kabul edilemez olduğunu gördünüz.

Dikkat edilmesi gereken ek şeyler. Kimliği doğrulanmış isteklerin yeniden çalınmasını önlemek için tek kullanımlık bir nonce kullanmak isteyebilirsiniz. Kriptografik güçte rastgele bir değer kullanmanızı öneririm (en az 64 bit uzunluğunda). Https kullanıyorsanız bu gereksizdir.

Sunucunuzun Ana bilgisayar parametresi kirliliği (HPP) saldırılarına karşı savunmak için yazıldığından emin olun. Örneğin, aynı türden birden fazla istek parametresi olan herhangi bir isteği reddetmelidir (ör. http://example.com/foo.html?name=x&name=y). Ayrıca, sunucu kodu yazarken, aldığınız bir talebe göre yeni istekler oluştururken dikkatli olun. Örneğin, her isteği işlemeden önce, sunucu kodunuz, isteğin yalnızca beklenen parametre listesi ile geldiğini ve başka bir şey olmadığını doğrulayabilir; isteği işlemeden önce yinelenen parametreleri veya beklenmedik parametreleri atın.

İleti kimlik doğrulama koduyla birden çok değeri korumaya karar verirseniz birleştirme hataları dikkat edin.

37
D.W.