摘要：前者主要由前端與后端合力完成，后者的話通常就是由前端多帶帶去完成的。畢竟各種防不勝防。日常開發(fā)中需要帶有安全意識，端或者服務端都不信任外部的任何輸入，任何參考文章前端安全防劫持與的防御注入的終極解決方案信息安全

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

那么，我們來談談如何防范它。
CSRF依賴于XSS，防住XSS基本也就防住了CSRF讓我們明確我們的目的，其實就是不讓用戶踏入XSS的坑，那我們有兩個方法防止用戶入坑，一個是對外部輸入進行徹徹底底的敏感字符過濾，一個是在顯示的時候做一些特殊處理不讓敏感代碼順利執(zhí)行。
前者主要由前端與后端合力完成，后者的話通常就是由前端多帶帶去完成的。

理論上只要有輸入數(shù)據(jù)入口的地方，XSS漏洞就會存在，js代碼可以由各種各樣的模式注入到數(shù)據(jù)庫中（明文或者編碼），所以在中小項目中我們先明確一個意識即可，我們開發(fā)人員要有安全處理的意識，不求百分百的過濾掉非法字符，但是基本的，常見的過濾掉即可，剩下的就交給安全工程師去做吧。

中心思想：一切的一切外部來源數(shù)據(jù)，畢竟經(jīng)過我們服務端代碼的過濾，才能讓他展示到頁面上，也就是說，一切外部數(shù)據(jù)都是非法的，一定要做好過濾，尤其是WEB端。（畢竟各種js防不勝防）。
所以像以下這種直接把頁面掌控權交給了用戶的代碼，是絕對不能寫的：

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

非法字符有兩類，明文：，這樣的明文傳到服務端，如果讓他就這么入庫的話，我們的數(shù)據(jù)庫就被XSS注入了，所以我們需要對明文的很好過濾，htmlspecialchars后即可把script標簽過濾成安全字符