一年前互聯(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)置的安全防護策略。但事實并非如此，我們收到的第一個報告就讓我們感到非常震驚，這是一個關(guān)于存儲型XSS的漏洞。
形成原因
當時我們使用Bootbox來顯示錯誤消息并創(chuàng)建確認對話框。而Bootbox獨立于React管理其DOM元素，并未受到React的XSS保護。因此，當用戶直接將輸入放在確認對話框中就會形成一個存儲型的XSS漏洞。
修復(fù)
短期修復(fù)：在將任何用戶輸入傳遞給Bootbox之前，先過濾所有可能的XSS標簽（例如可以使用JSXSS模塊）。
長期修復(fù)：將Bootbox轉(zhuǎn)移到基于React的確認模式。
吸取的教訓(xùn)
React雖然可以在一定程度上為我們防護XSS，但并不意味著所有的代碼都是安全的。我們不能輕易信任在React之外運行的庫文件，最好是減少或者避免使用那些未知的庫文件。
2. Markdown處理中的XSS
在修復(fù)Bootbox并對其它類似庫進行檢查后不久，我們又收到了另一份關(guān)于XSS漏洞的報告。這次的問題是出在我們的Markdown渲染中。
形成原因
我們在文本框中支持Markdown，并使用了
修復(fù)
將所有傳入dangerouslySetInnerHtml的文本內(nèi)容，使用XSS過濾器進行過濾，并創(chuàng)建一個Lint規(guī)則來規(guī)范和強制執(zhí)行該操作。
吸取的教訓(xùn)
在使用任何可能會帶來潛在安全問題的元素代碼時，一定要謹慎考慮。
3. Target=“_blank”
在我們從HackerOne收到的所有報告中，這是最令我們感到驚訝的一個問題。
形成原因
當你在新窗口中打開一個鏈接（）時，帶有 target=”_blank” 跳轉(zhuǎn)的網(wǎng)頁則擁有了瀏覽器window.opener對象賦予的對原網(wǎng)頁的部分權(quán)限。然后，攻擊者就可以利用該權(quán)限將原始頁面設(shè)置為登錄頁面或其他任何內(nèi)容。而對于這個問題，我們只能通過在標簽中添加rel=”noopener noreferrer”來解決。
我們選擇使用了Authy作為我們的2FA合作伙伴，但他們的rails gem并未對驗證速率做任何限制。
我們在程序中添加了相應(yīng)的速率限制，一旦輸入頻率超過我們的限制，我們就會對賬戶進行鎖定。
另外份報告顯示攻擊者可以繞過我們的2FA，使我們的第二個認證因素完全失效。攻擊者只需忽略2FA頁面，直接在瀏覽器地址欄輸入需要導(dǎo)航的到頁面地址即可成功繞過2FA。
這是本文所提及的漏洞中，最難以被追蹤的一個漏洞。Authy rails gem hook至Devise，并在登錄后使用以下代碼要求2FA：
def check_request_and_redirect_to_verify_token
id = warden.session(resource_name)[:id]
session["#{resource_name}_id"] = id
redirect_to verify_authy_path_for(resource_name)
從理論上講，這串代碼在成功登錄后會將用戶重定向到第二個因素身份驗證頁面。然而事實并非如此，而是直接將用戶重定向到了其導(dǎo)航的頁面。
result = !!authenticate(*args) # Try to log the user in
yield if result &&block_given?
將warden.logout行更改為sign_out即可。我們在本地修復(fù)了這個問題，并向Authy發(fā)起了一個pull request希望為更多的人修復(fù)這個問題。
*參考來源：flexport，F(xiàn)B小編 secist 編譯，轉(zhuǎn)載請注明來自FreeBuf.COM
京公網(wǎng)安備 11010502049343號