以前就瞭解過這方面的知識,可是沒有系統地總結。今天在這總結一下,也讓本身在接下來的面試有個清晰的概念。html
XSS跨站腳本攻擊:java
xss 跨站腳本攻擊(Cross Site Scripting),爲了避免和層疊樣式表(Cascading Style Sheets,CSS)縮寫混淆,因此將跨站腳本攻擊縮寫爲xss。Xss是攻擊者在web頁面插入惡意的代碼。當用戶瀏覽該頁面的時候,代碼執行,從而實現攻擊目的。對受害用戶可能採起Cookie資料竊取、會話劫持、釣魚欺騙等各類攻擊。node
XSS跨站腳本攻擊分爲:git
- 反射型XSS
反射性XSS,也就是非持久性XSS。用戶點擊攻擊連接,服務器解析後響應,在返回的響應內容中出現攻擊者的XSS代碼,被瀏覽器執行。一來一去,XSS攻擊腳本被web server反射回來給瀏覽器執行,因此稱爲反射型XSS。
下面舉例子說明:github
http://xxx.com?username=yang
//頁面輸出
hello yang
//若是我把上面的url變成這樣,同時服務器沒有作過濾
http://xxx.com?username=<script>alert("xss")</script>
//頁面會出現彈框,顯示xss;
你也許會說,這樣的URL一看就有問題,怎麼會有人點擊?,是的,這類的URL會讓人懷疑,但若是使用短網址服務將之縮短,你還看得出來麼?golang
- 持久型XSS
指經過提交惡意數據到服務器的數據庫。應用程序從數據庫中查詢數據,在頁面中顯示出來,攻擊者在相關頁面輸入惡意的腳本數據後,用戶瀏覽此類頁面時就可能受到攻擊。這個流程簡單能夠描述爲:惡意用戶的Html輸入Web程序->進入數據庫->Web程序->用戶瀏覽器。
說一個很常見的微博評論:若是不作過濾的話,很容易形成持久性xss攻擊,當用戶訪問已經被插入惡意代碼的頁面,很容易被攻擊。web
- DOM-based XSS
基於DOM的XSS,也就是web server不參與,僅僅涉及到瀏覽器的XSS。好比根據用戶的輸入來動態構造一個DOM節點,若是沒有對用戶的輸入進行過濾,那麼也就致使XSS攻擊的產生。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<form action="#">
<label>please input your name:</label>
<input type="text" id="username">
<input id="sbm" type="submit" value="submit">
</form>
<div id="container">
</div>
<script> function getUserName(){ var btn=document.getElementById("sbm"); btn.addEventListener("click",function(e){ e.preventDefault(); document.getElementById("container").innerHTML=document.getElementById("username").value; },false) } getUserName(); </script>
</body>
</html>
若是我在輸入框中輸入<img src="1" onerror="alert('xss')">
會出現什麼狀況
這時候很容易被攻擊了。面試
xss的防護
如今的XSS如此流行,緣由何在。我想你們應該都知道,就是在輸入的時候沒有作嚴格的過濾,而在輸出的時候,也沒有進行檢查,轉義,替換等。chrome
下面說幾點防護的方法:
原則:不相信客戶輸入的數據
注意: 攻擊代碼不必定在<script></script>中
1.使用XSS Filter。
輸入過濾,對用戶提交的數據進行有效性驗證,僅接受指定長度範圍內並符合咱們指望格式的的內容提交,阻止或者忽略除此外的其餘任何數據。好比:電話號碼必須是數字和中劃線組成,並且要設定長度上限。過濾一些些常見的敏感字符,例如:< > ‘ 「 & # \ javascript expression "οnclick=" "onfocus";過濾或移除特殊的Html標籤, 例如: <script>, <iframe> , < for <, > for >, " for;過濾JavaScript 事件的標籤,例如 "οnclick=", "onfocus" 等等。
輸出編碼,當須要將一個字符串輸出到Web網頁時,同時又不肯定這個字符串中是否包括XSS特殊字符(如< > &‘」等),爲了確保輸出內容的完整性和正確性,可使用編碼(HTMLEncode)進行處理。
2.DOM型的XSS攻擊防護
把變量輸出到頁面時要作好相關的編碼轉義工做,如要輸出到 <script>中,能夠進行JS編碼;要輸出到HTML內容或屬性,則進行HTML編碼處理。根據不一樣的語境採用不一樣的編碼處理方式。
3.HttpOnly Cookie
將重要的cookie標記爲http only, 這樣的話當瀏覽器向Web服務器發起請求的時就會帶上cookie字段,可是在腳本中卻不能訪問這個cookie,這樣就避免了XSS攻擊利用JavaScript的document.cookie獲取cookie:
CSRF跨站請求僞造攻擊
CSRF(Cross-site request forgery),中文名稱:跨站請求僞造,也被稱爲:one click attack/session riding,縮寫爲:CSRF/XSRF。危害是攻擊者能夠盜用你的身份,以你的名義發送惡意請求。好比能夠盜取你的帳號,以你的身份發送郵件,購買商品等。
下面是借用別人的一張原理圖:來自:http://www.nodeclass.com/articles/27062
從上圖能夠看出,要完成一次CSRF攻擊,受害者必須依次完成兩個步驟 :
1.登陸受信任網站A,並在本地生成Cookie 。
2.在不退出A的狀況下,訪問危險網站B。
下面用具體的代碼說明:
//若是一個博客刪除文章是使用的是get方法,如
http://xxx.com?delete=2016063022222
//那麼網站serverB只要僞造一個get請求就能夠實現上面的目的
<img src="http://xxx.com?delete=2016063022222">
//若是是post方法的話,也能夠用javascript實現。
<form action="http://xxx.com" method="POST">
<input type="text" name="delete" value="2016063022222" />
</form>
<script> document.forms[0].submit(); </script>
//但這裏強調一點:如今遊覽器(chrome,firfox)爲了安全考慮,默認都作了必定的限制,form標籤發送到其餘網站的請求會被攔截,你們有興趣模擬這種狀況時須要注意這個問題。
既然CSRF攻擊危害那麼嚴重,咱們如何去防範呢?下面總結幾種防範的知識點;服務端的預防CSRF攻擊的方式方法有多種,但思想上都是差很少的,主要從如下2個方面入手:一、正確使用GET,POST和Cookie;二、在非GET請求中增長僞隨機數。
1.對於關鍵操做咱們應該採用post方法。
2.CSRF在攻擊的時候每每是在用戶不情的狀況下提交的,咱們可使用驗證碼來強制跟用戶交互,可是太多強制性的操做對用戶來講體驗感很差,因此要權衡利弊。
3.在重要的請求中添加Token,目前主流的作法是使用Token抵禦CSRF攻擊。CSRF攻擊成功的條件在於攻擊者可以預測全部的參數從而構造出合法的請求,因此咱們能夠加大這個預測的難度,加入一些黑客不能僞造的信息。咱們在提交表單時,保持原有參數不變,另外添加一個參數Token,該值能夠是隨機而且加密的,當提交表單時,客戶端也同時提交這個token,而後由服務端驗證,驗證經過纔是有效的請求。可是因爲用戶的Cookie很容易因爲網站的XSS漏洞而被盜取,因此這個方案必需要在沒有XSS的狀況下才安全。
4.檢測Referer.所謂Referer,就是在一個網絡請求頭中的鍵值對,標示着目前的請求是從哪一個頁面過來的。服務器經過檢查Referer的值,若是判斷出Referer並不是本站頁面,而是一個外部站點的頁面,那麼咱們就能夠判斷出這個請求是非法的。與此同時,咱們也就檢測到了一次csrf攻擊。可是,服務器有時候並不能接收Referer值,因此單純地只經過Referer來防護是不太合理的,它所以常常用於csrf的檢測。
參考資料連接:
http://www.cnblogs.com/wqhwe/p/5416976.html
https://github.com/astaxie/build-web-application-with-golang/blob/master/zh/09.3.md
http://www.nodeclass.com/articles/27062
https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/
https://github.com/astaxie/build-web-application-with-golang/blob/master/zh/09.1.md