不是所有 Web 開發(fā)者都有安全的概念，甚至可能某些安全漏洞從來都沒聽說過。這就是這篇科普文章的存在意義，希望 Web 開發(fā)者在開發(fā)時能依此逐條檢查代碼中的安全問題。

注：服務(wù)器運(yùn)維相關(guān)的安全注意事項(xiàng)不在本文之列

這篇文章主要包含以下內(nèi)容：

• 前端安全

  • XSS 漏洞
  • CSRF 漏洞

• 后端安全

  • SQL 注入漏洞
  • 權(quán)限控制漏洞
  • SESSION 與 COOKIE
  • IP 地址
  • 驗(yàn)證碼

前言

水桶底部只要有一個洞，水就能全部流光。Web 安全同理。

前端安全

前端安全主要表現(xiàn)為通過瀏覽器間接影響到用戶數(shù)據(jù)的安全問題。

1. XSS 漏洞

   XSS (Cross-Site Scripting)，是一個我覺得耳熟能詳?shù)那岸税踩珕栴}。通過構(gòu)造特殊數(shù)據(jù)，在用戶瀏覽器上執(zhí)行特定腳本，從而造成危害（如以用戶身份發(fā)帖、轉(zhuǎn)賬等）。

   由于頁面內(nèi) JavaScript 幾乎可以完成各種事情，因此一旦網(wǎng)站上有 XSS 漏洞，那些沒有驗(yàn)證碼等確認(rèn)措施的操作大多都能不知情地完成，其危害甚大。

   來看看幾個存在 XSS 漏洞的例子吧：

   1. Case A: HTML DOM

      <a href="/user/1">{{ user_name }}</a>

      Exploit:

      <script>alert(1)</script>
      

      Result:

      <a href="/user/1"><script>alert(1)</script></a>

      最基本的例子，如果此處不對 user_name 中的特殊符號進(jìn)行 escape，就會造成 XSS。

   2. Case B: HTML Attribute

      <img src="{{ image_url }}">

      Exploit:

      ">Result:
       
      <img src="" onerror="alert(1)">
       
      這個例子表明，如果只對尖括號進(jìn)行 escape 是不夠的，很多時候引號也需要被 escape。簡單來說，對不同輸出場景，需要使用不同的 escape 規(guī)則。
       

   3. Case C: JavaScript

      <script>var user_data = {{ user_data|json_encode }};</script>

      Exploit:

      {"exploit": "</script><script>alert(1);//"}
      

      Result:

      <script>var user_data = {"exploit": "</script><script>alert(1);//"};</script>

      這是一個特別的例子，大多數(shù)人覺得，對于輸出在 <script> 中的內(nèi)容，json_encode 一下就安全了，其實(shí)不然。在這個例子中，XSS 仍然發(fā)生了。

      更可怕的是，不少編輯器的代碼高亮方案中甚至無法看出上面的 Result 中存在 XSS 漏洞。如 Sublime Text 下，代碼高亮結(jié)果是這樣的，看上去沒有任何問題：

      

      但是瀏覽器解析出來的結(jié)果是這樣的：

      

   解決方法：

   1. 在不同上下文中，使用合適的 escape 方式

   2. 不要相信 任何 來自用戶的輸入（不僅限于 POST Body，還包括 QueryString，甚至是 Headers）

2. CSRF 漏洞

   CSRF (Cross-site request forgery)，是一個知名度不如 XSS 但是卻同樣具有很大殺傷力的安全漏洞。它的殺傷力大正是因?yàn)楹芏嚅_發(fā)者不知道這個漏洞。

   舉個栗子，如果你網(wǎng)站 A 上的「登出」功能是這樣實(shí)現(xiàn)的：

   <a href="http://a.com/logout.php">登出</a>

   則存在 CSRF 漏洞。假設(shè)網(wǎng)站 B（當(dāng)然也可以是網(wǎng)站 A 本身）中有這么一段代碼：

   <img src="http://a.com/logout.php">

   那么當(dāng)用戶訪問的時候，就會導(dǎo)致網(wǎng)站 A 上的會話被登出。

   需要注意的是，不只是 GET 類請求，POST 類請求同樣會存在 CSRF 漏洞，例如網(wǎng)站 B 中：

   <form action="http://a.com/transaction" method="POST" id="hack">
      <input type="hidden" name="to" value="hacker_account">
      <input type="hidden" name="value" value="100000">
   </form>
   <script>document.getElementById("hack").submit();</script>

   那么用戶訪問網(wǎng)站 B 的時候，便會自動攜帶 A 的 SESSION 信息，成功 POST /transaction 到網(wǎng)站 A。

   這個漏洞危害很大，例如以前某些 BTC 交易所就存在這個漏洞，一旦用戶被誘騙訪問了黑客精心布置的網(wǎng)站就會造成資金損失；又例如，以前某中國著名社交網(wǎng)站也存在這個漏洞，更糟糕的是該網(wǎng)站還允許用戶遞交自己的 <img> 顯示在所有人的信息流中，且某些傳播性操作可以用 GET 方式達(dá)成，這就導(dǎo)致黑客可以進(jìn)行病毒式擴(kuò)散，當(dāng)然，僅僅是把 <img src="logout.do"> 嵌入信息流也是有足夠大殺傷力的 :)

   解決方法：

   1. 給所有請求加上 token 檢查。token 一般是隨機(jī)字符串，只需確保其不可預(yù)測性即可。token 可以在 QueryString、POST body 甚至是 Custom Header 里，但千萬不能在 Cookies 里。

   2. 檢查 referer （請注意，這往往不能防御來自網(wǎng)站自身的 CSRF 攻擊，如用戶評論中的 <img> 就是一個常見觸發(fā)點(diǎn)）

1. SQL 注入漏洞

   SQL 注入漏洞應(yīng)該也是一個大多數(shù)開發(fā)者都知道的漏洞。

   考察以下 PHP 代碼：

   <?php
   
   $user = mysql_query('SELECT * FROM USERS WHERE UserName="'.$_GET['user'].'"');

   那么當(dāng)請求中 user 參數(shù)為 ";DROP TABLE USERS;-- 時，合成的 SQL 語句是：

   SELECT * FROM USERS WHERE UserName="";DROP TABLE USERS;--"

   這里產(chǎn)生什么結(jié)果就不需要解釋了吧 :) 另外，通過 SQL 注入，往往還能拿到系統(tǒng)權(quán)限。

   解決方法：

   所有 SQL 語句都使用參數(shù)化查詢（推薦）或?qū)?shù)進(jìn)行 escape（不推薦）

2. 權(quán)限控制漏洞

   這個就不仔細(xì)展開了，未經(jīng)授權(quán)可以進(jìn)行的操作都是權(quán)限控制漏洞。

   例如，某些網(wǎng)站的后臺操作就仗著「以為用戶不知道入口地址」不進(jìn)行任何權(quán)限檢查，又例如，某些操作可能出現(xiàn)不允許更改的字段被用戶遞交更改（往往是那些網(wǎng)頁上標(biāo)記為 disabled 或者 hidden 的字段），再例如，允許通過 ../ 訪問到不應(yīng)該被訪問的文件等（一般存在于 include 中）。

   解決方法：

   所有地方都要進(jìn)行權(quán)限檢查（如是否已登錄、當(dāng)前用戶是否有足夠權(quán)限、該項(xiàng)是否可修改等），總之，不要相信任何來自用戶的數(shù)據(jù)，URL 當(dāng)然也是。

3. SESSION 與 COOKIE

   Session 和 Cookie 是兩種用于存儲用戶當(dāng)前狀態(tài)的工具。某些開發(fā)者不了解 Session 與 Cookie 的區(qū)別，誤用或者混用，導(dǎo)致敏感信息泄露或者信息篡改。

   Cookie 存儲在瀏覽器上，用戶可以查看和修改 Cookie。
   Session 是存儲在服務(wù)端的數(shù)據(jù)，一般來說安全可靠；大多數(shù) Session 都是基于 Cookie 實(shí)現(xiàn)的（在 Cookie 中存儲一串 SESSION_ID，在服務(wù)器上存儲該 SESSION_ID 對應(yīng)的內(nèi)容）。

4. IP 地址

   首先，用戶的 IP 地址一般存儲在 REMOTE_ADDR 中，這是唯一的可信的 IP 地址數(shù)據(jù)（視不同語言而定）。然后某些代理服務(wù)器，會將用戶的真實(shí) IP 地址附加在 header 的 VIA 或 X_FORWARDED_FOR 中（因?yàn)?code style="font-family:'Oxygen Mono','YaHei Consolas Hybrid',Consolas,'Lucida Console','Bitstream Vera Sans Mono','Courier New',Courier,monospace,宋體; font-size:0.8em; line-height:1.5; white-space:pre">REMOTE_ADDR 是代理服務(wù)器自身的 IP）。所以，要獲取用戶 IP 地址，一般做法是，判斷是否存在 VIA 或者 X_FORWARDED_FOR 頭，如果存在，則使用它們，如果不存在則使用 REMOTE_ADDR。這也是網(wǎng)上大多數(shù)所謂教程提供的方法。

   這就產(chǎn)生問題了，X_FORWARDED_FOR 或 VIA 是 HTTP Header，換句話說，它們是可以被偽造的。例如，在投票中，如果采信了 X_FORWARDED_FOR，往往意味著被刷票。

   解決方法：

   只使用 REMOTE_ADDR 作為獲取 IP 的手段。

5. 驗(yàn)證碼

   驗(yàn)證碼里常見的問題有：非一次性、容易被識別。

   非一次性指的是，同一個驗(yàn)證碼可以一直被用下去。一般來說，每進(jìn)行一次驗(yàn)證碼校對（無論正確與否），都應(yīng)該強(qiáng)制更換或清除 Session 中的驗(yàn)證碼。

   關(guān)于識別問題，在當(dāng)前科技水平下，不加噪點(diǎn)不加扭曲的驗(yàn)證碼幾乎是 100% 可識別的。所以大家自己看著辦吧…

后記

本文僅僅列舉了一些常見的 Web 開發(fā)安全問題，還有一些很少出現(xiàn)但確實(shí)有危害的安全問題沒有出現(xiàn)在這里（例如，點(diǎn)擊劫持），讀者可以自行了解。

總之，這是一篇科普文，希望開發(fā)者可以了解并重視 Web 開發(fā)安全問題。

另附篇講的比較好的文章

http://www.haomou.net/2015/10/30/2015_webxss/