一漂辐、 接口安全問題
- 請(qǐng)求身份是否合法疾宏？
- 請(qǐng)求參數(shù)是否被篡改宴凉？
- 請(qǐng)求是否唯一齐婴？
二捶码、 AccessKey&SecretKey （開放平臺(tái)）
2.1 請(qǐng)求身份
為開發(fā)者分配AccessKey（開發(fā)者標(biāo)識(shí)揉忘，確保唯一）和SecretKey（用于接口加密破停，確保不易被窮舉陷嘴，生成算法不易被猜測(cè)）骇扇。
2.2 防止篡改
參數(shù)簽名
- 按照請(qǐng)求參數(shù)名的字母升序排列非空請(qǐng)求參數(shù)（包含AccessKey）摔竿，使用URL鍵值對(duì)的格式（即key1=value1&key2=value2…）拼接成字符串stringA；
- 在stringA最后拼接上Secretkey得到字符串stringSignTemp少孝；
- 對(duì)stringSignTemp進(jìn)行MD5運(yùn)算继低，并將得到的字符串所有字符轉(zhuǎn)換為大寫，得到sign值稍走。
請(qǐng)求攜帶參數(shù)AccessKey和Sign袁翁，只有擁有合法的身份AccessKey和正確的簽名Sign才能放行柴底。這樣就解決了身份驗(yàn)證和參數(shù)篡改問題，即使請(qǐng)求參數(shù)被劫持粱胜，由于獲取不到SecretKey（僅作本地加密使用柄驻，不參與網(wǎng)絡(luò)傳輸），無法偽造合法的請(qǐng)求焙压。
2.3 重放攻擊
雖然解決了請(qǐng)求參數(shù)被篡改的隱患鸿脓，但是還存在著重復(fù)使用請(qǐng)求參數(shù)偽造二次請(qǐng)求的隱患。
timestamp+nonce方案
nonce指唯一的隨機(jī)字符串涯曲，用來標(biāo)識(shí)每個(gè)被簽名的請(qǐng)求野哭。通過為每個(gè)請(qǐng)求提供一個(gè)唯一的標(biāo)識(shí)符，服務(wù)器能夠防止請(qǐng)求被多次使用（記錄所有用過的nonce以阻止它們被二次使用）幻件。
然而拨黔，對(duì)服務(wù)器來說永久存儲(chǔ)所有接收到的nonce的代價(jià)是非常大的〈铝ぃ可以使用timestamp來優(yōu)化nonce的存儲(chǔ)蓉驹。
假設(shè)允許客戶端和服務(wù)端最多能存在15分鐘的時(shí)間差，同時(shí)追蹤記錄在服務(wù)端的nonce集合揪利。當(dāng)有新的請(qǐng)求進(jìn)入時(shí)态兴，首先檢查攜帶的timestamp是否在15分鐘內(nèi)，如超出時(shí)間范圍疟位，則拒絕瞻润，然后查詢攜帶的nonce，如存在已有集合甜刻，則拒絕绍撞。否則，記錄該nonce得院，并刪除集合內(nèi)時(shí)間戳大于15分鐘的nonce（可以使用redis的expire傻铣，新增nonce的同時(shí)設(shè)置它的超時(shí)失效時(shí)間為15分鐘）。
2.4 實(shí)現(xiàn)
請(qǐng)求接口：http://api.test.com/test?name=hello&home=world&work=java
-
客戶端
- 生成當(dāng)前時(shí)間戳timestamp=now和唯一隨機(jī)字符串nonce=random
- 按照請(qǐng)求參數(shù)名的字母升序排列非空請(qǐng)求參數(shù)（包含AccessKey)
stringA="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random"; - 拼接密鑰SecretKey
stringSignTemp="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random&SecretKey=secret"; - MD5并轉(zhuǎn)換為大寫
sign=MD5(stringSignTemp).toUpperCase(); - 最終請(qǐng)求
http://api.test.com/test?name=hello&home=world&work=java×tamp=now&nonce=nonce&sign=sign;
-
服務(wù)端
三祥绞、 Token&AppKey（APP）
在APP開放API接口的設(shè)計(jì)中非洲，由于大多數(shù)接口涉及到用戶的個(gè)人信息以及產(chǎn)品的敏感數(shù)據(jù)，所以要對(duì)這些接口進(jìn)行身份驗(yàn)證蜕径，為了安全起見讓用戶暴露的明文密碼次數(shù)越少越好两踏，然而客戶端與服務(wù)器的交互在請(qǐng)求之間是無狀態(tài)的，也就是說兜喻，當(dāng)涉及到用戶狀態(tài)時(shí)梦染，每次請(qǐng)求都要帶上身份驗(yàn)證信息。
3.1 Token身份驗(yàn)證
- 用戶登錄向服務(wù)器提供認(rèn)證信息（如賬號(hào)和密碼），服務(wù)器驗(yàn)證成功后返回Token給客戶端帕识；
- 客戶端將Token保存在本地泛粹，后續(xù)發(fā)起請(qǐng)求時(shí)，攜帶此Token肮疗；
- 服務(wù)器檢查Token的有效性戚扳，有效則放行，無效（Token錯(cuò)誤或過期）則拒絕族吻。
安全隱患：Token被劫持，偽造請(qǐng)求和篡改參數(shù)珠增。
3.2 Token+AppKey簽名驗(yàn)證
與上面開發(fā)平臺(tái)的驗(yàn)證方式類似超歌，為客戶端分配AppKey（密鑰，用于接口加密蒂教，不參與傳輸）巍举，將AppKey和所有請(qǐng)求參數(shù)組合成源串，根據(jù)簽名算法生成簽名值凝垛，發(fā)送請(qǐng)求時(shí)將簽名值一起發(fā)送給服務(wù)器驗(yàn)證懊悯。這樣，即使Token被劫持梦皮，對(duì)方不知道AppKey和簽名算法炭分，就無法偽造請(qǐng)求和篡改參數(shù)。再結(jié)合上述的重發(fā)攻擊解決方案剑肯，即使請(qǐng)求參數(shù)被劫持也無法偽造二次重復(fù)請(qǐng)求捧毛。
3.3 實(shí)現(xiàn)
3.3.1 登陸和登出請(qǐng)求
3.3.2 后續(xù)請(qǐng)求
客戶端
和上述開放平臺(tái)的客戶端行為類似，把AccessKey改為token即可让网。-
服務(wù)端
四呀忧、 源碼
請(qǐng)移步聚合支付平臺(tái)，博主正在開發(fā)的一款開源項(xiàng)目溃睹，其中接口驗(yàn)證采用的就是上文中開放平臺(tái)的驗(yàn)證方案而账，歡迎大家Star!
轉(zhuǎn)自：https://blog.csdn.net/qq_18495465/article/details/79248608
