如何防範XSS和CSRF？

距離上一次介紹XSS與CSRF已通過去了漫長了兩個月，工做較忙，文章姍姍來遲。
小小回顧一下究竟什麼是XSS和CSRF：https://segmentfault.com/a/11... 《用大白話談談XSS與CSRF》。

那麼，咱們來談談如何防範它。
CSRF依賴於XSS，防住XSS基本也就防住了CSRF讓咱們明確咱們的目的，其實就是不讓用戶踏入XSS的坑，那咱們有兩個方法防止用戶入坑，一個是對外部輸入進行不折不扣的敏感字符過濾，一個是在顯示的時候作一些特殊處理不讓敏感代碼順利執行。
前者主要由前端與後端協力完成，後者的話一般就是由前端單獨去完成的。

理論上只要有輸入數據入口的地方，XSS漏洞就會存在，js代碼能夠由各類各樣的模式注入到數據庫中（明文或者編碼），因此在中小項目中咱們先明確一個意識便可，咱們開發人員要有安全處理的意識，不求百分百的過濾掉非法字符，可是基本的，常見的過濾掉便可，剩下的就交給安全工程師去作吧。

中心思想：一切的一切外部來源數據，畢竟通過咱們服務端代碼的過濾，才能讓他展現到頁面上，也就是說，一切外部數據都是非法的，必定要作好過濾，尤爲是WEB端。（畢竟各類js防不勝防）。
因此像如下這種直接把頁面掌控權交給了用戶的代碼，是絕對不能寫的：

<?php
$name = $_GET["name"];
$name = htmlspecialchars($name);
?>
<input type='text' value='<?php echo $name?>'>

下面的案例用世界上最好的語言來演示：

非法字符有兩類，明文：<script>alert('我是xss，你有麻煩了')</script>，這樣的明文傳到服務端，若是讓他就這麼入庫的話，咱們的數據庫就被XSS注入了，因此咱們須要對明文的很好過濾，htmlspecialchars後便可把script標籤過濾成安全字符 <script> ，那麼明文的能夠簡單的就過濾掉了。

明文易檔，編碼難防，

編碼：u0026u006cu0074u003bu0073u0063u0072u0069u0070u0074u0026u0067u0074u003bu0061u006cu0065u0072u0074u0028u0026u0023u0033u0039u003bu6211u662fu0078u0073u0073uff0cu4f60u6709u9ebbu70e6u4e86u0026u0023u0033u0039u003bu0029u0026u006cu0074u003bu002fu0073u0063u0072u0069u0070u0074u0026u0067u0074u003b

若是不懷好意的人不用明文，卻用這種unicode方式，那麼垂手可得就能夠越過htmlspecialchars的防守，而後入庫，而後展現的時候html編碼會將這種unicode自動轉回明文（也就是變成真實的注入代碼），危害就來了！

同比類推，既然unicode能夠充當注入的工具，那麼其餘編碼我相信也是能夠的。因此在這裏也強調一下儘可能將頁面的字符編碼設置爲unicode（utf-8），而後咱們統一處理unicode編碼注入和明文注入的狀況就好
以上注入代碼只是簡單的注入並不會有實質危害，可是若是是相似於document.cookie這類獲取隱私cookie，而後把這段cookie發送到外部服務器存儲起來，那麼在這段cookie的有效期內，我能夠直接拿這份cookie去登陸帳號了！

如何防範以上這些恐怖的事情呢？回來開頭我說的，輸入過濾，輸出過濾：
看到了在 @月之領主LM 在他的問題中已經總結了，那我就直接站在巨人的肩膀上吧！

PHP直接輸出html的，能夠採用如下的方法進行過濾：

1.htmlspecialchars函數
2.htmlentities函數
3.HTMLPurifier.auto.php插件
4.RemoveXss函數（百度能夠查到）

PHP輸出到JS代碼中，或者開發Json API的，則須要前端在JS中進行過濾：

1.儘可能使用innerText(IE)和textContent(Firefox),也就是jQuery的text()來輸出文本內容
2.必需要用innerHTML等等函數，則須要作相似php的htmlspecialchars的過濾（參照@eechen的答案）

其它的通用的補充性防護手段

1.在輸出html時，加上Content Security Policy的Http Header
（做用：能夠防止頁面被XSS攻擊時，嵌入第三方的腳本文件等）
（缺陷：IE或低版本的瀏覽器可能不支持）
2.在設置Cookie時，加上HttpOnly參數
（做用：能夠防止頁面被XSS攻擊時，Cookie信息被盜取，可兼容至IE6）
（缺陷：網站自己的JS代碼也沒法操做Cookie，並且做用有限，只能保證Cookie的安全）
3.在開發API時，檢驗請求的Referer參數
（做用：能夠在必定程度上防止CSRF攻擊）
（缺陷：IE或低版本的瀏覽器中，Referer參數能夠被僞造）

固然，這一塊的安全處理也只能處理冰山一角，我相信仍是有其餘方式能夠進行xss注入攻擊的，可是實際上做爲開發人員我認爲，咱們只要攔截了大部分常見攻擊便可了。

平常開發中須要帶有安全意識，WEB端或者APP服務端都不信任外部的任何輸入，任何！

參考文章 ：

https://www.owasp.org/index.p...《XSS (Cross Site Scripting) Prevention Cheat Sheet 》

http://www.cnblogs.com/yangxi...《【前端安全】JavaScript防http劫持與XSS》
https://segmentfault.com/q/10...《PHP的防護XSS注入的終極解決方案【信息安全】【Hack】》