上一篇介紹了我們安裝BWAPP來完成我們的漏洞測試
在BWAPP中，將HTML Injection和XSS做了非常詳細的分類，那麼爲什麼要將兩個一起講呢？歸根結底，我覺得這兩個分明是一個玩意，充其量是攻擊的方式不一樣。
我們先來介紹一下這兩種漏洞的原理，簡單說：當用戶在輸入框輸入內容，後臺對輸入內容不做處理直接添加入頁面的時候，用戶就可以刻意填寫HTML、JavaScript腳本來作爲文本輸入，這樣這個頁面就會出現一些用戶加入的東西了。這是一種腳本注入（和CSDN發佈文章時候的填寫源碼應該是類似的，CSDN填寫源碼時候可以搞些鏈接，假設這些鏈接鏈到惡意網站，甚至不寫鏈接直接Script腳本？這樣是不是很恐怖？）
看這個例子，下一行文字會把輸入的xs打出來，那麼假如我填寫的是一個連接？
點擊這個Click Me就跳到百度去了。
再假如我填寫的是一個script標籤下的東西，是不是更加恐怖？我們知道瀏覽器是不對cookie做過多防護的，如果這種手段配合CSRF攻擊（不好意思先讓這玩意提前出場一下），細思極恐啊。
當然有些稍微有點腦子的網站會屏蔽script標籤的輸入，但是我們大可以利用類似於
<img src=1 onerror=alert(1) />
這樣的語句
說了那麼多，我們發覺沒有，好像原理並不複雜，爲什麼BWAPP上可以分出那麼多種類呢。其實吧這款軟件在於展示各類漏洞，有些漏洞原理雖然一樣，但是伴隨着不同的攻擊和防護也是有着截然不同的效果的。
比如HTML注入和XSS攻擊就是對注入的是html還是js做了分類（這個分類略蠢），然後對於用的是get請求還是post請求、json還是xml、ajax還是表單做了分類（比前一個略好點不過感覺也挺蠢）。其實衆多分類中較爲有點用處的是反射型和存儲型。
其實這種分類也沒太高明的地方，甚至不需要舉例，就是一個結果直接呈現，一個是存到數據庫裏面。我們前面那個例子就是反射型的，但是顯然這種攻擊沒有太大效果，因爲攻擊方和效果呈現在同一臺機子同一個瀏覽器同一次瀏覽；而存儲型就不同了，用於存入數據庫，因此這些攻擊腳本是長時間存在的，比如微博朋友圈等等。
其實相比起這些可有可無的分類，對於xss的防護措施纔是比較重要的，我們之前說過很多後臺會過濾<script>標籤，但是可以用img標籤來完成一些特殊的處理，還有些過濾不夠完善的，可以用類似<scr<script>ipt>這樣的標籤來過濾，就是當吧script標籤過濾掉了以後，原本無意義的語句變爲了script標籤。
所以相比起過濾script標籤，我們可以採用更加高明的過濾'<''>''&'等符號。
這裏有一個問題啊，我們都知道瀏覽器會解釋上述幾個符號，那假如我想在瀏覽器中顯示一條html代碼該怎麼辦？
事實上html是定義了幾個特定符號專門用來表示這幾個符號的，比如用&來代替&符號，比如我們這篇文章標題中的&符號，在文章列表中就會顯示出&
瀏覽器給特定符號一些特定的文本表示，那我們就可以用這種手段去過濾，我們將BWAPP的等級跳到medium，選擇HTML Injection - Reflected (GET)進行hack：
我們在輸入框填入<a href=http://www.baidu.com>Click Me</a>，發覺代碼並沒有像我們想象中這樣呈現出來，而是完整地被顯示在了下面，我們打開BWAPP的源碼，通過主目錄下的bugs.txt找到bug對應的源碼文件，發覺medium調用了xss_check_1方法：
我們發覺這裏將輸入的內容中的<>符號給替換成了<和>，很明顯在這種情況下標籤就變得沒用了。
但是我們也看到了，在註釋中充分詮釋了這種方案的破解之法，這種方案必須要進行urldecode，所以我們只需要一開始就把<>符號encode之後的內容輸入即可：
輸入如下
在這種情況下，我們將防護措施跳到high，發覺最高的防護措施完美解決了這個問題。
function xss_check_3($data, $encoding = "UTF-8")
{
// htmlspecialchars - converts special characters to HTML entities
// '&' (ampersand) becomes '&'
// '"' (double quote) becomes '"' when ENT_NOQUOTES is not set
// "'" (single quote) becomes ''' (or ') only when ENT_QUOTES is set
// '<' (less than) becomes '<'
// '>' (greater than) becomes '>'
return htmlspecialchars($data, ENT_QUOTES, $encoding);
}那麼我們提出了兩個問題：1）非php（如java）中是否有類似函數；2）這個函數防護下的後臺是否可以攻擊。
首先第一點，答案是肯定的，原理都知道了，只是實現一下誰不行？
隨便舉個實現的第三方庫：org.apache.commons.lang這個包：
StringEscapeUtils.escapeHtml方法即可。
然後第二個問題，這個問題其實很難說怎麼回答，應該分爲兩個方面：
1）htmlspcialchars這個函數本身對xss的限制目前爲止似乎是沒有辦法破解的，因爲他完全利用了轉義，換句話說直接攻破了xss的原理
2）雖然說這個函數基本上完克了xss，但是攻擊防護本來就是相生相剋的，看誰棋高一着，雖然我們沒法用xss直接打破htmlspcialchars，但是我們既可以使用別的攻擊方式去解決，也可以利用程序員對於htmlspcialchars的使用不當去可以繞開甚至利用這個函數，我們可以看看知乎對這個問題的回答https://www.zhihu.com/question/27646993
在這個回答中，我們發覺如果開發人員把htmlspcialchars用在不當地方（如script標籤中間），那這層防護和沒有一樣（本來是用來防止script標籤的，結果自己把它放在script標籤裏面，賊蠢）
所以我們需要明白，不存在什麼防護都能破解的攻擊，也不存在什麼攻擊都能防禦的防護，攻擊和防護本來就是程序員和惡意用戶鬥智鬥勇的一場博弈，誰棋高一着誰就勝利。作爲一名開發人員，我們不能用這些攻擊手段去做違法的事情，但是我們可以研究這些攻擊去完善我們的防護，就比如這裏，我們知道了如何解決xss攻擊，但是如何講解決方案用在恰當的地方，這需要我們日積月累去積累經驗的。
注意：本博客只爲學習和防護所用，嚴禁用於違法途徑，否則後果自負