網絡安全

重放攻擊

• 攻擊者經過某種手段獲取到請求的報文，並將報文從新發送到瀏覽器

• 防範手段

  • 不管什麼時候，只容許提交一次報文，每次請求帶上一個隨機數，當服務器接收到請求時，判斷以前是否有收到相同的請求，有的話則認爲是重放，拒絕請求，但這種方法有個缺點，就是是數據庫須要記錄大量的歷史請求（隨機數）
  • 一段時間內，只容許處理一次請求，每一個報文帶上時間戳，通常請求的到達耗時約60s，因此服務器對比當前時間，若是間隔大於60s，則認爲是重放，這個方法的缺點是，客戶端和服務器系統時間須要保持同步，而且若是是1分鐘內到達的請求是沒法限制重放的
  • 請求添加連續的流水號，每次請求都會增長一，當接收到不連續的流水號時，對應的請求就有重放的嫌疑，這樣無需記錄大量的隨機數，但因爲流水號很容易被僞造，因此一遍不用這種方式
  • 通常採用隨機數和時間戳相結合的方式，60s內到達的請求，對比隨機數，若是一致就認爲是重放，60s外到達的請求直接認爲是重放，且能夠清除記錄的隨機數

• 除了重放攻擊，有可能客戶端的快速點擊也會重複發送請求，在服務端能夠用上面的方法處理，客戶端可使用節流和防抖限制

  • 防抖，連續重複多個動做，只對最後一個動做響應
  • 節流，一個時間間隔內，只容許一個動做生效

XSS（跨站腳本攻擊）

• XSS攻擊的原理就是，利用網頁自己的漏洞，例如會從網頁連接中讀取信息，並拼接到html文本中，經過這種方式，向網頁植入惡意腳本，泄露用戶信息，如能夠經過XSS獲取用戶cookie

• 攻擊形式一：

  • 網頁拼接，網頁接收輸入文本或從連接獲取參數後，直接展現在頁面上，則攻擊者可經過構造<script>標籤僞造輸入，讓頁面執行腳本
  • 防範方法，對獲取到的輸入進行轉義，瀏覽器不會執行轉義後的輸入

• 攻擊形式二：

  • 頁面上某a標籤，從連接中會獲取參數，拼接到href後面，攻擊者經過構造javascript:XXX，因爲轉義並不會處理"javascript"這種字符串，當點擊a標籤時，惡意代碼被執行
  • 防範方法，頁面內部保存一組黑名單，當獲取到的參數帶有某特定字符串時，拒絕使用這個參數

• xss攻擊分類：

  • 儲存型：構造的惡意代碼提交到數據庫，經過數據庫返回給瀏覽器執行
  • 反射型：訪問的時候就在url上帶有惡意代碼，服務器讀取url參數把他拼接到html上，返回瀏覽器被執行
  • DOM型：html自己會讀取輸入或url參數，拼接到html上時執行了惡意代碼

• 防範：

  • 輸入過濾，先後端都對接受的參數進行過濾以及轉義，但有個缺點，某些正常輸入的字符也會被轉義致使後續使用或展現時有誤
  • 經過dom操做進行前端的渲染，使用innerText（不要使用或謹慎使用innerHTML），setAttribute這種api，能夠防止惡意代碼被拼接，vue的模板機制和react的jsx就是利用的這個方法避免xss，但這種方式依然沒法避免onload事件的插入，以及利用href的xss
  • 針對href的xss輸入，須要注意避免使用.innerHTML、.outerHTML、document.write()以及vue和react的v-html/dangerouslySetInnerHTML

  • CSP（content security policy）

    • 啓用CSP能夠禁止加載外域代碼，或只容許執行受信任的域名下的代碼
    • 禁止提交請求到不受信的服務器
    • 禁止執行內聯腳本
    • 上報異常信息以供分析
  • HTTP-only Cookie：在cookie中設置httponly，則cookie沒法被js腳本獲取到
  • 驗證碼，針對敏感操做，須要驗證碼才能放行

CSRF（跨站請求僞造）

• Cross-site request forgery
• 攻擊者誘導用戶進入第三方網站，在第三方網址中，經過img或href等標籤的src屬性，向被攻擊網站發送跨站請求，若此時用戶已經獲取了被攻擊網站的登陸受權，跨站請求就有可能帶上用戶的cookie，從而繞事後臺的驗證，致使攻擊請求被後臺執行
• 正常來說，因爲瀏覽器自己帶有同源限制，js沒法直接對不一樣域名下的資源進行操做，但img或script標籤不受同源策略的限制，因此存在CSRF的可能

• 攻擊類型：

  • GET類型，經過src屬性發起請求
  • POST類型，須要構造form，進行提交，同時由於form提交會發生頁面跳轉，通常爲了避免讓用戶識別到提交，會有一個iframe裝着

  <form action="http://bank.example/withdraw" method=POST>
      <input type="hidden" name="account" value="xiaoming" />
      <input type="hidden" name="amount" value="10000" />
      <input type="hidden" name="for" value="hacker" />
  </form>
  <script> document.forms[0].submit(); </script>

  • 連接類型，請求寫在a標籤的href在中，誘使用戶點擊，從而發出請求

• 防範策略：

  • 同源檢測：利用請求頭的Origin和Referer，能夠在meta或csp中設置referer policy，控制請求是否帶referer

    • 但referer是有可能被修改的，並非徹底安全
    • 同時因爲SEO（搜索引擎優化）的需求，請求頁面（html）的請求是會須要被容許的，若是這個頁面自己會觸發某些get請求，就極可能被攻擊
    • 另外若是，頁面自己容許輸入評論等，也可能被髮起攻擊

  • CSRF Token：構造一個攻擊者沒法獲取的token，在請求時帶着這個token訪問服務器，不能放在cookie中，而是做爲報文body的一部分

    • 打開頁面時，訪問服務器，返回一個token，經過js遍歷，把token帶在a標籤和form標籤中，可是這種方法沒法處理由js發起的請求，或後續動態生成的dom元素，針對這兩種狀況，須要手動添加token，而後服務器接受請求時驗證token
    • 一般該token由客戶id，隨機數以及時間戳生成，並加密，服務器驗證時會對比有效性
    • 可是這種驗證須要額外儲存token，對服務器而言是額外的負擔

  • 雙重cookie驗證：利用沒法跨域獲取cookie的限制，在訪問頁面時往cookie添加一個csrfcookie的隨機數，後續發起請求時，頁面獲取該cookie，並設置到請求參數裏，後續驗證，服務器只須要驗證cookie中的值和請求裏的參數是否一致便可

    • 這種方法無需存儲額外的數據，直接對比cookie便可
    • 但前提是不存在xss漏洞，否則仍是有可能泄露cookie，或者被修改cookie，從而利用僞造的cookie發起請求，形成用戶損失

  • samesite cookie：新的提案

    • Set-Cookie: xxx; Samesite=Strict，則該cookie除了從自身網站下發起請求，其他包括新頁面打開，或不一樣域名下的異步請求，都不會帶上cookie
    • Set-Cookie: xxx; Samesite=Lax，當這個請求是從自身網站下發起的請求，或者打開了新頁面，如從百度打開某個頁面，同時他是個get請求，那麼容許帶上cookie
    • 但這種方案有個缺點，不支持子域，即啓用了samesite後，子域沒法使用父域的cookie