假設我們有一個WCF Web服務。其鏈接如下;如何確保服務的循環以找出其api密鑰
http://www.example.com/service/?api=62383581
62383581這裏是API密鑰。我們如何確保服務的循環以找出其API密鑰?
假設我們有一個WCF Web服務。其鏈接如下;如何確保服務的循環以找出其api密鑰
http://www.example.com/service/?api=62383581
62383581這裏是API密鑰。我們如何確保服務的循環以找出其API密鑰?
我想檢查一下主叫方的IP地址,並且防止同一個IP地址每小時發出超過n個呼叫將毫無意義,因爲攻擊者會使用欺騙手段來拋棄這種努力。
我能想到的唯一方法是使用可檢測此類攻擊的強大可配置防火牆或Winsnort等入侵防禦系統(IPS)。另請參見http://www.winsnort.com/index.php?module=News&func=display&sid=41
我認爲第一個也是如此。你是對的。但不知道如何處理第一個第二選項。 – tugberk
我認爲討論應該是「如何讓它變得困難」而不是阻止它,因爲如果你打算將你的服務暴露給公衆,你很容易受到攻擊。
的可能性,以使其難以可能是:
,如果你正在爲一個緊密的客戶羣訪問您的服務的話,你可以在你的服務器,以防止任何其他服務的調用上應用IP限制,這將阻止來自客戶端腳本(例如JavaScript)的任何呼叫,並且將打開IP欺騙
您也可以在您的服務中放置IP限制。在Message Inspector中,您可以驗證IP,如果它不在您的範圍內,則拋出異常以防止進一步訪問。
與包含特殊字符使用字母數字API密鑰,使之非常複雜的,並通過(強力)難以循環
你可以給你的客戶(我可以考慮爲您的方案的最佳配合)一個公鑰(對每個客戶端都不相同)要求他們在關鍵字後附加一些標識符,例如API & CustomerID和你的密鑰來加密它,因爲在服務器端,您必須爲特定的客戶端,反之亦然私鑰..(這包含加密解密的開銷)
,如果你有man in middle那麼這可以妥協以上。 這些都是爲了讓事情變得困難,並且可能需要重新思考,具體取決於您的具體情況。
使用GUID而不是Int來使其更難以強制它。
從哪裏獲得API密鑰? – abatishchev
@abatishchev在這裏有重要嗎? – tugberk
你的問題很缺乏。您不會描述攻擊者是誰,可能泄露api密鑰的程序在哪裏運行,誰可以訪問該服務,驗證api密鑰,首先找到該API密鑰的目的是什麼,您的意思是循環,... – CodesInChaos