1.互聯(lián)網(wǎng)Api接口到底如何保證安全性問題？
創(chuàng)新新互聯(lián)，憑借10余年的網(wǎng)站設計、成都網(wǎng)站制作經(jīng)驗，本著真心·誠心服務的企業(yè)理念服務于成都中小企業(yè)設計網(wǎng)站有近千家案例。做網(wǎng)站建設，選創(chuàng)新互聯(lián)。
2.代碼落地實戰(zhàn)防御XSS、CSRF攻擊
3.代碼落地如何防御接口數(shù)據(jù)被黑客抓包篡改？
4.接口數(shù)據(jù)加密對稱還是非對稱加密好
XSS攻擊通常指的是通過利用 網(wǎng)頁 開發(fā)時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網(wǎng)頁，使用戶加載并執(zhí)行攻擊者惡意制造的網(wǎng)頁程序。這些惡意網(wǎng)頁程序通常是JavaScript，但實際上也可以包括 Java 、 VBScript 、 ActiveX 、 Flash 或者甚至是普通的HTML。攻擊成功后，攻擊者可能得到包括但不限于更高的權限（如執(zhí)行一些操作）、私密網(wǎng)頁內(nèi)容、會話和cookie等各種內(nèi)容。 [1]
腳本攻擊：利用JavaScript 注入 到后臺數(shù)據(jù)庫中，在通過展示數(shù)據(jù)加載該腳本 該腳本中（
1.使用js獲取cookie信息（jwt）
2.將該jwt數(shù)據(jù) 上傳黑客服務器（ajax）
）
獲取jwt---用戶會話信息 讓后模擬請求形式使用該jwt登錄。
xss攻擊典型網(wǎng)站：論壇、評論區(qū)
前端傳遞 js 腳本到服務器端
后端接口將該腳本存放數(shù)據(jù)庫中
前端html
將用戶前端所提交的參數(shù)進行過濾。
html 大于 小于號
該方式的缺陷：每個參數(shù)都需要像這樣寫 代碼非常冗余
接口接受參數(shù) ？傳遞參數(shù)形式---
傳遞參數(shù)都是json數(shù)據(jù)形式
spring mvc 接受 json數(shù)據(jù)提供 api回調(diào)
1.可以使用第三方抓包工具，對請求前后實現(xiàn)代理，可以修改參數(shù)請求內(nèi)容和參數(shù)響應內(nèi)容,抓包工具http調(diào)試工具
2.Fiddler4下載地址：
使用Fiddler4篡改請求之前：
使用MD5可以直接驗證簽名參數(shù) MD5 屬于單向加密，只能夠暴力破解。
MD5應用場景 在nacos分布式配置中心中，使用MD5 比對文件內(nèi)容是否發(fā)生改變
HasherPro比對文件內(nèi)容是否發(fā)生改變。
MD5在線暴力破解地址：
String userName= "123456" ;
System. out .println( DigestUtils. md5Hex (userName));
黑客如何破解？自己需要根據(jù)參數(shù)內(nèi)容 生成簽名
如果只是改了參數(shù)內(nèi)容---沒有用的 所以我們需要該簽名
{"password":"123456","phoneNumber":"phoneNumber","channel":"安卓","equipment":""}
{sign=325ab041d4889825a46d1e1e802ab5de, timestamp=1652537015771}
一般的處理是 訪問鏈接url是這樣子的 這樣的形式
然后后面get方式加上參數(shù)？hash= md5(url.time()) url和時間戳或者一個時間格式拼接起來，md5加密一下，傳到服務器，服務器判斷是這樣形式就可以的
你開放的接口真的就很安全嗎，看看有沒有做到如下幾點
1.請求身份驗證
2.請求參數(shù)校驗
3.請求是否唯一
4.請求次數(shù)限制
請求身份驗證
基于 AccessKey：為接口調(diào)用放分配AccessKey和SecretKey（不參與傳輸，只用于本地接口加密，不能泄露）
基于token身份驗證：
1.用戶登錄提供認證信息（如：賬號密碼）服務器驗證成功后將用戶信息保存到token內(nèi)并設置有效期，再返回token給調(diào)用方
2.調(diào)用方保存token，并在有效期內(nèi)重新?lián)Q取token，保證token是有效的
3.服務器驗證token有效性，無效則攔截請求返回錯誤信息，反之則從token內(nèi)獲取用戶信息進行后續(xù)操作
請求參數(shù)校驗
1.校驗參數(shù)合理性（如：參數(shù)類型，參數(shù)長度，參數(shù)值校驗）
2.防止XSS，SQL注入（解決方案：過濾敏感字符或直接返回錯誤信息）
3.校驗參數(shù)可靠性是否被篡改（可以將參數(shù)以特定格式排列+秘鑰組成字符串，在進行MD5或SHA簽名）
請求是否唯一
前面第3點解決了請求參數(shù)被篡改的隱患，但是還存在著重復使用請求參數(shù)偽造二次請求的隱患
timestamp+nonce方案
nonce指唯一的隨機字符串 ，用來標識每個被簽名的請求。通過為每個請求提供一個唯一的標識符，服務器能夠防止請求被多次使用（記錄所有用過的nonce以阻止它們被二次使用）。
然而，對服務器來說永久存儲所有接收到的nonce的代價是非常大的?？梢允褂胻imestamp來優(yōu)化nonce的存儲 。
假設允許客戶端和服務端最多能存在15分鐘的時間差，同時追蹤記錄在服務端的nonce集合。當有新的請求進入時，首先檢查攜帶的timestamp是否在15分鐘內(nèi)，如超出時間范圍，則拒絕，然后查詢攜帶的nonce，如存在已有集合，則拒絕。否則，記錄該nonce，并刪除集合內(nèi)時間戳大于15分鐘的nonce（可以使用redis的expire，新增nonce的同時設置它的超時失效時間為15分鐘）。
請求次數(shù)限制
某些資源我們需要限制用戶的請求次數(shù)，同時也為了防止非人為操作可能導致系統(tǒng)的崩潰
實現(xiàn)思路如下：
假如我們允許用戶每秒鐘最多10次請求，超過10次則返回“手速太快了，慢點把。?！?/p>
這里我們使用redis輔助我們實現(xiàn)：
以用戶IP為key，請求次數(shù)為value，有效時間為1秒
用戶在每秒的第一次訪問的時候，此時我們的redis是沒有key為用戶ip的數(shù)據(jù)的（因為失效了，或者第一次請求）所以我們要初始化當前請求用戶的ip為keyvalue為0到redis數(shù)據(jù)庫
當用戶在1s內(nèi)再次發(fā)起請求我們就將此ip的請求次數(shù)+1，并判斷請求次數(shù)是否已近=10
=10則返回給用戶手速太快了!請稍后重試..否則繼續(xù)執(zhí)行后續(xù)操作
具體實現(xiàn)代碼如下：
如有疑問可在下方留言，我會盡快答復，或者關注公眾號 程序員MuziDong 隨時了解新的動態(tài)
重慶分公司
重慶分公司
