API 客戶端認證那些事.

簽名認證機制

1.設置key密鑰。
2.假設參數 appid:wx930ea5d5a258f4f much_id:10000100 device_info:1000 body:test nonce_str:iabuaiVckJ按照參數名ASCII字典排序。
StringA="appid=wx930ea5d5a258f4f&body=test&device_info=1000&much_id=10000010&nonce_str=iabuaiVckJ";
3.拼接API密鑰。
stringSignTemp="stringA&key=192006250b4c09247ec02edce69f6a2d";sign=MD5(stringSignTemp).toUpperCase()="9A0A8659F005D6984697E2CA0A9CF3B7";api

HTTP證書認證


HTTPS由HTTP+SSL組成,公鑰私鑰至關於鑰匙和鎖頭,你能夠把鎖頭給別人,別人能夠用這個鎖頭把重要的東西鎖起來,發給你,只有你有鑰匙去打開鎖看到裏面的東西。安全

  1. 客戶端發起HTTPS請求。服務器

  2. 服務端配置。微信

  3. 傳送公鑰。cookie

  4. 客戶端解析證書,若是有異常,則彈出一個警告框,提示證書有問題,若是沒有問題,則生成一個隨機值(對稱密鑰),用證書對隨機值加密。數據結構

  5. 傳送加密信息,其實就是讓服務器端獲得這個隨機值。app

  6. 服務器端用私鑰解密,獲得隨機值,而後私鑰對稱加密。xss

  7. 傳輸加密後的信息。網站

  8. 客戶端解密信息。客戶端用私鑰還原內容。ui

總結:
服務器 用RSA生成公鑰和私鑰,把公鑰放在證書裏發送給客戶端,私鑰本身保存。
客戶端首先向一個權威的服務器檢查證書的合法性,若是證書合法,客戶端產生一段隨機數,這個隨機數就做爲通訊的密鑰,咱們稱之爲對稱密鑰,用公鑰加密這段隨機數,而後發送到服務器,服務器用密鑰解密獲取對稱密鑰,而後,雙方就已對稱密鑰進行加密解密通訊了。

Oauth 2.0 認證

用戶登陸第三方網站,該網站又想得到另一個服務商的信息(圖片,文件),可是服務商又不想提供用戶名密碼給第三方網站。

  1. 第三方網站向服務商請求一個未受權的臨時令牌code。

  2. 服務商驗證第三方網站的身份後,授予一個未受權的臨時的令牌(大概10分鐘)。

  3. 第三方網站得到未受權的臨時令牌後,將用戶導向服務商的受權頁面請求用戶受權,將未受權的臨時令牌和第三方網站的返回地址發給服務商。

  4. 用戶在服務商的受權頁面輸入本身的用戶名和密碼。

  5. 受權成功後,服務商將用戶導向第三方網站,而且返回已受權的臨時令牌。

  6. 第三方網站根據已受權的臨時令牌從服務商那裏得到具備訪問權限的令牌accessToken。

  7. 第三方網站使用獲取到的訪問令牌accseeToken能夠訪問服務商的用戶資源。

受權模式

  • 受權碼模式

  • 簡化模式

  • 密碼模式

  • 客戶端模式

API接口頻率限制

例子:
系統API接口日均調用次數預計1億,提供5臺服務器
單IP,單應用每小時調用次數不超過10000次
單應用,單用戶,單接口每小時調用次數不超過1000次

系統吞吐量(系統每秒能處理的請求數)

80% 1億 / (24小時 60 分鐘 60秒 40% * 5) = 4630tps
80%,40% 是指一天中有80%的請求發生在40%的時間裏

簡單設計

數據結構
k(app_id,ip) => v(count,startTime,lastTime)
k(app_id,uid,interface_id) => v(count,startTime,lastTime)

startTime是第一次調用發生的時刻,lastTime是最近一次調用發生的時刻,精確到秒級。

假設應用也有1萬個,平均每一個應用的用戶數爲10萬個 ,接口數爲50,獨立訪問IP地址爲100萬,那麼數據項總和爲:

1萬100萬 +1萬10萬*50 = 600億

接口安全

  • 注入攻擊

  • 失效的身份和會話管理

  • XSS

  • 不安全的直接對象引用
    暴露一個文件,目錄,數據密鑰

  • 安全配置錯誤

<security-constraint>  <http-method>

http-method裏的方法是要進行安全限制的,若是隻寫了POST,GET,那麼黑客能夠利用HEAD和PUT等其餘方法進行攻擊。

  • 敏感信息泄露
    攜程安全支付日誌可遍歷下載

  • SQL注入
    蝦米網2013年

  • 功能級訪問控制缺失

  • 跨站請求僞造(CSRF)
    支付寶flash xss rookit攻擊

  • 未受權訪問/權限繞過
    2014年搜狗後臺管理系統

  • 帳戶體系控制不嚴/越權操做
    樂視網 修改uid登陸任意用戶

  • 使用含有已知漏洞的組件

  • 未驗證的重定向和轉發

  • 引用不安全的第三方應用
    結果:獲取服務器敏感信息

淘寶網主站2014年4月,針對opnessl heartbeat,發送攻擊數據包,不須要任何身份驗證或者受權,能夠從服務器內存讀到最多64kb數據,這些數據包括用戶登陸的cookie,密碼明文,可能泄露私鑰。
方法:升級最新版本。

  • 系統錯誤/邏輯缺陷帶來的暴力猜測
    2013年京東商城,重置任意用戶密碼

弱口令猜測

  • 內部重要資料/文檔外泄
    淘寶往上傳到百度網盤


感謝您的耐心閱讀,若是您發現文章中有一些沒表述清楚的,或者是不對的地方,請給我留言,您的鼓勵是做者寫做最大的動力,
若是您認爲本文質量不錯,讀後以爲收穫很大,不妨請我喝杯咖啡,讓我更有動力繼續寫出高質量的文章。

  • 支付寶

  • 微信

做 者 : @mousycoder

原文出處 : http://mousycoder.com/2016/02/22/api-authentication/

創做時間:2016-2-22

更新時間:2016-2-22

相關文章
相關標籤/搜索