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