http請求是短連線 每次有請求接入 伺服器都要重新核實一遍 請求裡面使用者的身份資訊，而這個往往是通過瀏覽器的cookie來實現的 目前好像這個是 各種五花八門 登入，實現b/s會話的基礎 什麼單點登入 ，oauth2.0都是圍繞這個在做事 只是元件數量和 過濾器多少 過濾條件 多少的問題。
重發攻擊 說的簡單點 就是把你這個請求的資料報 給抓下來 然後 在次提交一遍 （當然 這裡面 肯定還會做手腳）這個比什麼crsf以及xss攻擊要厲害的多，另外還有一點 因為在瀏覽器裡可以看到 前段所有的東西 所以 不管你怎麼 加時間戳 加頭什麼的 只要可以拿到你的前端提交請求的** （這部分一般是會做加密的）任你怎麼玩 別人 都可以看的一清二楚，這就是很多資料驗證 要放在s端的原因。
因此要解決這個重放攻擊 重點 應該放在後端 而不是在前端
s端 每次有請求進來 都會接受 當然重放攻擊的請求 也會接受，要解決重放攻擊 需要解決兩件事：
1. s端需要知道 這個瀏覽器是由使用者發出的
2. 再次傳送這個請求 s端可以識別 並且丟棄（這個上面 不應該有時間限制 什麼60秒什麼的 其實並不好）
這裡學過struts2.0的 都會想到乙個表單令牌環的解決方法 這個可以防止重複提交 當然也可以阻止重放攻擊 但這個需要使用struts的標籤 以及服務 不過 現在貌似是springboot的天下了 這東西用的怕是少了 不是一種普遍的解決方案
但是他的機制 我們可以借鑑
每次提交資料攜帶這個令牌 作為s端識別的標誌 如果令牌是相同的 就將這個令牌銷毀 並處理資料 同時生成乙個新的令牌 放在上下文中 在呼叫 表單外掛程式的時候 解析struts標籤 將其放入
不過現在前後端分離 後端** 現在一般都不會再去解析jsp或者ftl了 用的什麼node vue 後端只負責返回資料所以 解決方案還要調整
以下是我想到的一種：
後端需要有乙個*** 或者過濾器 對每個請求進行處理 如果是 get直接放行 如果是post 需要判斷某個token，這個token如果和s端 如果不一致 直接拒絕 如果一致 那麼放行 並重新生成乙個新的token 覆蓋掉當前值，並做返回值 一起返回個前端 之後提交的時候 在把這個值帶上。
第一次這個值 當然是登入成功才返回的 因此那個過濾器 對這個登入的請求要放行
這個值只有在使用post方式的時候 或者你認為有改寫資料的可能的時候才拿出來驗證 其他的不用 切每個只用一次 用了就更新
至於這個token的儲存問題 感覺直接塞進 記憶體就好了 或者用個快取 redis什麼的 只存鍵值對 而且都是字串 應該佔不了多少記憶體
這個裡面 只能傳圖 不能畫圖 實在是煩 圖之後再補上
Web服務的重放攻擊的一點想法
下午在談交易類服務的時候，除了證書做數字簽名以外，也談到了重放攻擊的問題。對於重放攻擊可以通過序列號的方式來判斷。序列號從頒發角度分成 1.服務呼叫者自身頒發。2.服務提供者頒發。序列號生成方式分成兩類 1.不重複，隨機頒發。2.遞增。3.時間戳。頒發者如果選擇是服務提供者，那麼就會使得原本一次的會...
Web服務的重放攻擊的一點想法
下午在談交易類服務的時候，除了證書做數字簽名以外，也談到了重放攻擊的問題。對於重放攻擊可以通過序列號的方式來判斷。序列號從頒發角度分成 1.服務呼叫者自身頒發。2.服務提供者頒發。序列號生成方式分成兩類 1.不重複，隨機頒發。2.遞增。3.時間戳。頒發者如果選擇是服務提供者，那麼就會使得原本一次的會...
最近一點想法
本來計畫每天11點半之前睡覺，事實證明不太可能每天那麼規律。一是，每週任務不會順利按計畫進行。二是，我本人有時候凌晨睡，五點半起ok，有時候夜幕降臨就要困得昏過去。這樣的話，就爭取精神狀態好的時候多做點事，狀態不好就多休息，不去刻意按時睡了。只是有一點，臉上從不長痘的我，也開始長痘了。不知道是春天有...