一年前互聯(lián)網(wǎng)貨代公司Flexport為了提高其客戶數(shù)據(jù)的安全性，與我們HackerOne平臺建立了合作關(guān)系。HackerOne作為全球知名的bug賞金平臺之一，允許所有安全愛好者或?qū)I(yè)的滲透測試人員，來提交他們的漏洞報告并給予相應(yīng)的獎勵。從與Flexport合作至今，我們已經(jīng)收到了近200份的漏洞報告，包括從nginx頭移除服務(wù)器令牌到XSS漏洞。以下是我們在這200份報告中挑選出的最有意思的6個漏洞。
1.刪除按鈕中的XSS
在啟動我們的這個bug賞金計劃時，我們并沒有想到會收到任何關(guān)于XSS的有效報告。畢竟，React有內(nèi)置的安全防護(hù)策略。但事實并非如此，我們收到的第一個報告就讓我們感到非常震驚，這是一個關(guān)于存儲型XSS的漏洞。
形成原因
當(dāng)時我們使用Bootbox來顯示錯誤消息并創(chuàng)建確認(rèn)對話框。而Bootbox獨立于React管理其DOM元素，并未受到React的XSS保護(hù)。因此，當(dāng)用戶直接將輸入放在確認(rèn)對話框中就會形成一個存儲型的XSS漏洞。
修復(fù)
短期修復(fù)：在將任何用戶輸入傳遞給Bootbox之前，先過濾所有可能的XSS標(biāo)簽（例如可以使用JSXSS模塊）。
長期修復(fù)：將Bootbox轉(zhuǎn)移到基于React的確認(rèn)模式。
吸取的教訓(xùn)
React雖然可以在一定程度上為我們防護(hù)XSS，但并不意味著所有的代碼都是安全的。我們不能輕易信任在React之外運行的庫文件，最好是減少或者避免使用那些未知的庫文件。
2. Markdown處理中的XSS
在修復(fù)Bootbox并對其它類似庫進(jìn)行檢查后不久，我們又收到了另一份關(guān)于XSS漏洞的報告。這次的問題是出在我們的Markdown渲染中。
形成原因
我們在文本框中支持Markdown，并使用了。回想起來，這顯然是一個不明智的做法。
修復(fù)
將所有傳入dangerouslySetInnerHtml的文本內(nèi)容，使用XSS過濾器進(jìn)行過濾，并創(chuàng)建一個Lint規(guī)則來規(guī)范和強(qiáng)制執(zhí)行該操作。
吸取的教訓(xùn)
在使用任何可能會帶來潛在安全問題的元素代碼時，一定要謹(jǐn)慎考慮。
3. Target=“_blank”
在我們從HackerOne收到的所有報告中，這是最令我們感到驚訝的一個問題。
形成原因
當(dāng)你在新窗口中打開一個鏈接（）時，帶有 target=”_blank” 跳轉(zhuǎn)的網(wǎng)頁則擁有了瀏覽器window.opener對象賦予的對原網(wǎng)頁的部分權(quán)限。然后，攻擊者就可以利用該權(quán)限將原始頁面設(shè)置為登錄頁面或其他任何內(nèi)容。而對于這個問題，我們只能通過在標(biāo)簽中添加rel=”noopener noreferrer”來解決。
修復(fù)
我們通過為target=”_blank” 加上 rel=”noopener noreferrer” 屬性，從而使新窗口無法更改原始內(nèi)容。此外，我們向ESLint提交了一個Lint規(guī)則，以防止我們和其他人在將來犯同樣的錯誤。
吸取的教訓(xùn)
在信任HTML標(biāo)簽的同時，也要保持時刻的警惕。
4. WordPress的煩惱
在修復(fù)上述漏洞后，我們并沒有再收到更多關(guān)于前端的相關(guān)漏洞報告。但關(guān)于我們的漏洞報告卻從未停止，我們運行在Wordpress的公司網(wǎng)站也相繼收到了許多漏洞報告。
形成原因
對于同樣使用WordPress程序的站點而言，最多的原因就是使用了一些過時的插件導(dǎo)致的。例如，JetPack是一款被廣泛使用（300萬次安裝）和推薦的插件，雖然它承諾可以為WordPress站點提供更好的安全性，并增加流量吸引讀者。但在過去的幾年間，已經(jīng)有許多的XSS及其它漏洞被曝出。
修復(fù)
及時的更新那些已安裝的Wordpress插件，對于一些不經(jīng)常使用的插件應(yīng)當(dāng)及時的清理。訂閱https://wpvulndb.com/跟進(jìn)Wordpress相關(guān)的最新漏洞報告。
5. 2FA爆破將目標(biāo)轉(zhuǎn)到我們的Ruby on Rails后端，我們收到了兩份關(guān)于雙因素身份驗證的漏洞報告。首先，我們收到的一份報告顯示攻擊者可以通過暴力攻擊的手段，獲取對非授權(quán)帳戶的訪問權(quán)限。
形成原因
我們選擇使用了Authy作為我們的2FA合作伙伴，但他們的rails gem并未對驗證速率做任何限制。
修復(fù)
我們在程序中添加了相應(yīng)的速率限制，一旦輸入頻率超過我們的限制，我們就會對賬戶進(jìn)行鎖定。
6. 2FA繞過
另外份報告顯示攻擊者可以繞過我們的2FA，使我們的第二個認(rèn)證因素完全失效。攻擊者只需忽略2FA頁面，直接在瀏覽器地址欄輸入需要導(dǎo)航的到頁面地址即可成功繞過2FA。
形成原因
這是本文所提及的漏洞中，最難以被追蹤的一個漏洞。Authy rails gem hook至Devise，并在登錄后使用以下代碼要求2FA：
def check_request_and_redirect_to_verify_token
...
id = warden.session(resource_name)[:id]
warden.logout
warden.reset_session!
session["#{resource_name}_id"] = id
...
redirect_to verify_authy_path_for(resource_name)
end
從理論上講，這串代碼在成功登錄后會將用戶重定向到第二個因素身份驗證頁面。然而事實并非如此，而是直接將用戶重定向到了其導(dǎo)航的頁面。
def authenticate?(*args)
result = !!authenticate(*args) # Try to log the user in
yield if result && block_given?
result
end
修復(fù)
將warden.logout行更改為sign_out即可。我們在本地修復(fù)了這個問題，并向Authy發(fā)起了一個pull request希望為更多的人修復(fù)這個問題。
吸取的教訓(xùn)
對于一個企業(yè)而言即使安全做的再好，也難免會出現(xiàn)一些疏忽。而解決這個問題的最好方法，就是與類似于HackerOne這類的漏洞眾測平臺建立合作，借助大家的力量來共同維護(hù)我們的企業(yè)安全。
| 
