5.3　HackerOne非預期HTML包含補丁繞過漏洞

難度：中

URL：https://hackerone.com/reports/<report_id>/

報告位置：https://hackerone.com/reports/112935/

報告日期：2016年1月26日

支付獎金：500美元

當一個組織創(chuàng)建了修復程序并解決了報告中的問題后，并不總代表就免于漏洞困擾了。在讀完Ceukelaire的漏洞報告后，我決定測試一下HackerOne的漏洞修復程序，看一看Markdown編輯器是怎樣呈現(xiàn)非預期輸入的。為此，我提交了如下代碼：

回想一下，為了用Markdown創(chuàng)建一個錨標簽，你通常需要提供一個URL和一個由雙引號括起來的title屬性。為了解析title屬性，Markdown需要先找到左雙引號，然后是隨后的內(nèi)容，最后是右雙引號。

我好奇的是，是否可以通過增加附加的隨機雙引號和屬性來讓Markdown在解析過程中發(fā)生錯亂，Markdown會不會在額外增加的雙引號處重新錯誤地開始解析屬性內(nèi)容。這就是我在上面的代碼中加入ismap=（一個有效的HTML屬性）、yyy=（一個無效的HTML屬性）和額外的雙引號的原因。當提交該輸入后，Markdown編輯器解析該代碼為如下的HTML：

可見，來自Ceukelaire報告的修復程序造成的結果是更為不可預測的漏洞，它會使Markdown解析器生成任意HTML。盡管我沒有立即利用該漏洞，但是已經(jīng)包含了未轉義的HTML就足以作為漏洞驗證程序（POC）了，從而讓HackerOne不得不撤銷之前的修復程序并使用不同的解決方案來糾正以上問題。可以注入任意HTML標簽的事實可能會導致漏洞，因此，HackerOne向我支付了500美元的獎金。

要點

僅僅更新代碼，并不能說明所有的漏洞都被修復了。要確保對變化后的代碼進行滲透測試，而且要持續(xù)地進行測試。部署補丁程序，意味著這是新的代碼，就有可能包含漏洞。