- 保護代碼這件事挺重要的
當像Equifax這樣的重要公司的敏感數據洩露成為頭條新聞時，數百萬的消費者立即意識到他們現在是受害者。 故事總是關於竊取的數據以及公司試圖掩蓋漏洞的戲劇性事件。 但是數據洩露是安全失敗的結果。
如此嚴重的安全漏洞的真正原因是什麼？
通常，敏感數據會通過不安全的源代碼來洩露。 這就是故事中的故事，這個引人入勝的故事很少講。 即使在最大和最熟悉的公司（如Uber）內，此類故障也經常發生。 安全性故障甚至發生在OneLogin等專門從事安全性的公司內部，但是我們很少聽到為什麼會發生這些故障。
通常，敏感數據會通過不安全的源代碼來洩露。 這就是故事中的故事，這個引人入勝的故事很少講。
之所以如此，部分是因為源代碼漏洞是高度技術性的。 正如我們將看到的，這是我們無法避免的一個問題，因為它是“技術性成分太多”。
但是，我們沒有聽到有關安全失敗原因的更為惡毒的原因：如果公司透露其軟件缺乏重要的安全功能，那麼他們很快就會失去客戶的信心。 因此，雅虎和其他公司多年來一直故意隱瞞安全漏洞。
我們將發現這些安全漏洞的根源是源代碼本身。 在本文中，我們將探討源代碼存儲庫（如Git和Apache Subversion）的安全漏洞。 我們還將討論包括源代碼掃描在內的各種解決方案。 讓我們從一些最近的安全性故障開始，並找出共同點。
- 新聞事件
這個故事太普遍了。 把相同發生在“ Uber”上轉換到任何組織或公司，會看到相同的故事。這樣的故事不斷提醒我們增加基於Web的自身安全預防措施。
公司尋求通過加強強大的密碼創建來增強信心；有些甚至使用強大的密碼生成器。 更嚴厲的措施包括使用兩因素甚至多因素身份驗證。 除了傳統的硬件令牌或密鑰卡以外，這可能還涉及通過SMS發送到您的電子郵件地址的動態PIN碼。 鑑於這種增強的安全性，為什麼我們繼續聽到Uber和其他公司的數百萬消費者的隱私受到損害？
荒謬而又真實的答案是，壞演員常常不做任何事情。 最具破壞力的“黑客”僅比意外發現未加密文件中的密碼要聰明得多，該文件位於可索引的Web目錄或Amazon S3 Bucket中！ 這就是Uber發生的情況，我們將更深入地研究攻擊者如何通過版本控制平台和Git和Subversion等代碼存儲庫中的漏洞來訪問登錄憑據。
以另一個影響超過1.48億消費者的重大違規事件為例：對消費者信貸報告機構Equifax的違規行為。
對Equifax的大規模攻擊利用了另一種流行的針對分佈式計算應用程序的開發工具Apache Struts。 Apache以生產高質量且廣受歡迎的開源開發人員工具而聞名。 但是，Apache Struts有很多已知的安全問題。 當前，一個開發人員論壇維護著72個已知的安全問題的帖子(issue)！ 這些安全漏洞的範圍遠非中等，它涵蓋了拒絕服務和遠程代碼執行攻擊，這些攻擊可能削弱企業電子商務平台。
這提示了一個最明顯的問題：如果Apache Struts已知安全問題，為什麼Equifax使用它？ 人們普遍說，Equifax在利用這些安全問題之前就已經知道了這些安全問題，但是Equifax並未採取任何有意採取的行動來解決這些問題。 為什麼？ 要了解在此類常用軟件中處理已知錯誤和攻擊媒介的問題，我們必須探索問題的技術方面。
即使僅關注數據安全性的公司也不例外。 例如，一家以網絡安全為中心的公司OneLogin遭到了攻擊。 這個特定的故事與我們此處的預期目的最接近：盜竊API密鑰和OAuth令牌。
儘管OneLogin沒有透露攻擊的詳細信息，但是他們向客戶提出的關於保護進一步入侵的建議間接揭示了潛在的入侵點。
開發人員用於自動登錄的登錄憑據（API密鑰和OAuth令牌）通常未加密存儲在Shell腳本5中，甚至可能顯示在日誌文件中。
但是公司在解決這個特定問題時面臨著巨大的挑戰：開發人員和敏捷團隊渴望精簡的連續部署管道在必須完全確保身份驗證憑據安全的情況下很難自動進行。 可以完全做到這一點，但是需要全神貫注並不斷進行審查。 讓我們從如何以及為什麼存在這些安全漏洞開始。
一切從代碼開始
在最近的一項研究中，美國國土安全部指出90％的安全漏洞是由於代碼中的漏洞而發生的。這個簡單而有影響力的統計數據應該足以促使從開發人員到CISO的每個人都開始考慮評估自己與代碼有關的安全性實踐。要查找的第一個也是最重要的地方是代碼存儲庫內。
隨著採用和使用量的增加，源代碼存儲庫（“ repos”）逐漸被人們所理解，但是從歷史上看，它們僅主要由從事大型企業級軟件應用程序的開發人員所佔用。
這些是共享的開發人員資源。因為只有開發人員每天都在回購中工作，所以提交的源代碼不受對其他開發，測試和QA領域施加的審查。但這正是安全漏洞開始出現的地方。
另一個地方是整個版本控制。在一個複雜的Web應用程序中，多個開發人員可以在一個模塊上工作，領導者需要能夠快速測試和回滾新興代碼的便利。此功能由Apache Subversion等版本控制應用程序提供。回購和版本控制應用程序都容易出現漏洞。
普通的安全問題，例如SQL注入或跨站點腳本（XSS），是二維的，非技術人員可以通過簡單的測試方法甚至最基本的漏洞掃描工具來識別。 測試人員可以運行在Cucumber上編寫的回歸測試套件，然後報告問題，而無需了解從倉庫中觸發測試的自動生成腳本的內容，其中某些腳本實際上包含秘密訪問密鑰和令牌。
在腳本化CI管道中使用此類憑據的各種方式僅受開發人員的創造力限制。 通常，持續集成和部署（CI / CD）涉及到盡可能簡化和自動化的過程，但是掃描代碼，集成和部署過程本身並不是凡人的直接任務。
相反，必須對腳本生成的漏洞進行掃描，而不是由人員而是由機器進行漏洞掃描。 並且它們必須足夠智能才能在第一個CI觸發之前啟動。 Jenkins是一種流行的開發人員工具，它可以檢測編碼員何時向應用程序提交（“提交”）更改。 然後，Jenkins觸發一個測試套件，如果成功，它將繼續自動部署該應用程序的成功版本。 這些是CI / CD中的一些步驟，CI / CD現在是一種流行的向用戶分發新軟件的方式。
但是...
為什麼CI和CD是安全失敗的深淵？
為了實現真正的自動化開發流程，開發人員必須編寫腳本，編寫從代碼更改到應用程序部署的一系列事件。 這意味著對Web應用程序所做的任何更改都會觸發一組新的測試套件，以驗證代碼更改不會破壞應用程序的另一部分。 可以想像，要自動化Web應用程序測試，必須要有一個虛擬用戶，登錄一個帳戶，然後執行普通用戶會做的事情-可能使用新的帳戶和地址購買電視。 當我們具有前面描述的所有安全功能（例如動態PIN身份驗證）時，機器人如何登錄帳戶？ 這通常就像將明文憑證粘貼到文件中一樣簡單，甚至可能使最老練的系統管理員和開發工程師都感到恐懼。
當開發人員（通常是QA工程師）編寫自動CI管道的腳本時，他們實際上是在腳本中輸入虛擬用戶的登錄憑據。 這些腳本未經編譯或加密； 它們是在瀏覽器和服務器上執行的純文本腳本。 自動化腳本通常保存到Apache Subversion和Git之類的存儲庫中，或者在頑皮的情況下，保存在開放式Web服務器或公共GitHub本身上的可索引存儲庫中。 它們在回滾期間觸發，並通過部署管道釋放。 在提交觸發新的構建之前，必須由源代碼掃描程序檢測到這些安全漏洞。 只有這樣才能防止黑客將注意力集中在這些腳本的內容上。 經常訪問的協議，組件和庫的流程鬆懈會導致源代碼漏洞。
還記得我們的Uber示例嗎？ 他們和其他公司一樣，“經常不小心將憑據保存在上載到GitHub的源代碼中。”但這並不是偶然的，有時出於方便或開發速度的考慮，這是慣例。 擺脫不良習慣或魯ck自動化的唯一方法是自動對其進行自動掃描。
- 人為因素
令人驚訝的是，分佈式計算平台中出現的安全故障不是錯誤。 他們是疏忽大意的疏忽，提供了與未知方的聯繫。 開發人員在此失敗過程中的錯誤是一種預期。
傳統上，開發人員認為錯誤是在運行的應用程序中發生的，而不是回購中的腳本。 不安全的編碼實踐源於開發過程中的行為和習慣，這可能導致代碼中的漏洞。
如前所述，回購和版本控制平台嚴格來說是編碼人員的領域。
同樣，測試人員和質量檢查工程師通常不會將構建腳本視為正在開發的網絡應用程序的一部分。 這種觀念必須改變，但是還必須有一個增強安全性的改進平台。
- 兩位英雄之戰：安全與效率
Devops和敏捷方法非常重視極速的速度和效率，以至於開發人員承受著將快捷方式編寫腳本到軟件構建中的壓力。 當然，這會導致無法預料的後果。
如果兩個或兩個以上的開發人員在代碼的一個分支上工作，他們通常會傾向於共享憑據以簡化可見性。 儘管降低交付速度的壓力是不切實際的，但很有可能實現實施開發人員代碼安全性實踐的回購和版本控制系統。
不幸的是，不存在安全的開發人員工具。 如今，安全已被“強化”，而不是集成在其中。 由於開發人員希望快速發展，並且不希望通過附加的安全步驟來減慢速度，因此他們固有地發現在快速創新和高需求的環境中保持對安全性意識不佳的想法。
毫無疑問，公司的實質是其源代碼。新的自動傳遞管道現在暴露了一種新形式的安全漏洞。隨著任何新技術的出現，出現了一系列新的威脅。通過Web應用程序交付核心產品的企業必須將源代碼安全性視為最高優先事項。對源代碼的靜態分析可以在將應用程序部署到生產之前或在打包和交付構建之前，識別專有和開放源代碼中的漏洞。然後，檢測漏洞的基於安全的版本控制和存儲庫平台可能會中斷新版本的自動部署，直到問題得到糾正或權威團隊負責人對發行版進行身份驗證和批准為止。預防那些導致災難性的Equifax和Uber破壞的安全故障，在交付到生產中時值得一時。基於安全的開發人員工具必須在下一代編碼標準中發揮作用。
預防那些導致災難性的Equifax和Uber破壞的安全故障，暫時停產交付是非常值得的。
基於安全的開發人員工具必須在下一代編碼標準中發揮作用。
基於安全的開發人員工具必須在下一代編碼標準中發揮作用。
僅此一步就可以阻止幾乎所有惡意的更改源代碼的企圖，並且可以在未經授權的訪問發生之前減輕未經授權的訪問。 最佳的基本安全實踐之一是不斷監視構建腳本是否存在潛在的安全漏洞。 自動化的源代碼清單可以完成此任務。 需要具有源代碼掃描程序的功能，該功能可以跟踪版本控制系統中的所有新分支，並在輸入密鑰和令牌時顯示警報。 如今，一些公司對公開掃描這些密鑰，然後禁用它們或通知用戶感興趣。 甚至有些人甚至為用戶提供了執行此操作的工具，例如Amazon Web Services的AWSLabs GitHub帳戶。
- 解決安全難題
1.代碼掃描
確實，當今Git回購中還需要的一項關鍵安全功能是能夠智能掃描所有源代碼並識別開發人員添加的訪問密鑰和密碼的功能。 當開發人員將秘密訪問密鑰和密碼編碼為源代碼時，估計會啟用75％的安全漏洞。
我們需要一個自動系統，該系統可以檢測腳本中的密鑰和密碼輸入並提醒團隊負責人進行審查。
** 代碼掃描器很重要
安全功能。 它可以檢測腳本中的密鑰和密碼輸入，並提醒團隊負責人進行審查。
開發人員當前使用的一種增強安全性的方法是將登錄憑據分離到“包含”文件中，以便從登錄腳本中刪除Oauth的密碼以及其他秘密密鑰和令牌。但是，這種方法取決於個人開發人員的習慣，並且破壞了協作問責制的概念。我們已經表明，鼓勵速度的devop做法也激發了編碼人員使用快捷方式的安全性。實現自動漏洞掃描和分析的平台是下一代標准開發人員安全工具，將包含在改進的存儲庫和版本控制平台中。自動化漏洞掃描使整個開發人員或敏捷團隊中的代碼安全性民主化。
基於安全的分佈式應用程序開發平台必須自動實施策略實施。換句話說，與Jenkins檢測到代碼更改的方式相同，源代碼安全系統應檢測敏感憑證或私有數據的輸入。這樣的系統將嚴格控制和審核誰有權訪問和更新源代碼。該系統將向團隊負責人提供受保護的分支機構和用戶報告，以進行緊急響應。
該系統應該具有關鍵字陷阱，並且像防病毒程序一樣工作，以在提交之前和任何觸發生成的提交之前捕獲憑據條目。
2.合規
與安全的開發人員做法並行的是採用企業級標準。 符合標準的認證對於當今Web應用程序開發的成功至關重要。 提供存儲庫和版本控制的基於雲的分佈式軟件開發平台應嚴格遵守安全服務組織控制（SOC）2審核。 此類合規性可以進一步確保健壯的源代碼安全性。 理想情況下，具有版本控制的基於安全的開發人員平台的安全協議應符合全面的審核和認證標準，以驗證合規性是質量保證和客戶隱私保護的重要層。
隱私保護框架(The Privacy Shield Framework)是由美國商務部和歐盟委員會設計的，旨在為公司提供一種在將個人數據從歐盟轉移到美國以支持跨大西洋商業時遵守數據保護要求的方式。
遵守SOC 2審核可確保客戶和合作夥伴充分利用公司的信息安全措施，並維持當今特定的雲安全要求。 源代碼安全性和數據保密性是SOC 2審核合規性不可或缺的部分。
與SOC 2認證並存的是確保隱私的幾個其他合規性標準，所有這些都應視為對源代碼安全性和總體雲數據隱私性進行驗證所必需的。 在基於雲的電子商務支付和數據安全網絡中，用於隱私實踐的PCI Level 3和Privacy Shield最重要。
雲安全聯盟STAR自我評估同樣向所有分支機構和客戶保證，基於Web的企業將維持最高標準的隱私和源代碼安全性。
數據本地化在許多轄區中也很重要，因為它可以使數據保持最接近組織的性能和控制力。 由於合規性法規（特別是GDPR）的興起，歐盟雲將特別有利於關注數據隱私，數據保護和數據本地化偏好的國際客戶。
3.使用軟件包管理保護開源軟件包
程序包是代碼和腳本的集合，這些代碼和腳本以編程方式在特定應用程序的構建中相互包含。 最終，這就是構建現代Web應用程序的方式。 它是包裝的組裝。 軟件包通常由客戶下載並集成到新的軟件產品中。 這樣的代碼包通常包含安全問題。 企業無法手動掃描其開發人員使用的每個程序包中的所有代碼，因此必須從自動漏洞掃描和審核系統中獲得巨大收益。 這樣的掃描器將充當哨兵，以保護企業免受各種創新但危險的創新的攻擊：身份驗證憑據的腳本編寫。
安全軟件包管理器對於識別源代碼中的安全漏洞至關重要。 借助MyGet等通用安全軟件包管理器，領導者可以在devops生命週期中連續控制和審核所有軟件包。 可以使用已知代碼漏洞的行業標準數據庫對所有主要語言的軟件包進行掃描，以檢查是否存在安全漏洞和漏洞。 由於開發人員工具和平台的複雜性，這種任務並非微不足道。
例如，當今使用的常見編碼語言列表很多，包括Java，.NET Framework語言（如C＃），客戶端語言（包括JavaScript）以及令人困惑的JS庫（如React，Vue，AngularJS和jQuery）。 服務器端語言包括Node.js，Ruby，Python，Perl，當然還有PHP。
基於安全性的開發人員版本控制和存儲庫平台必須具有識別和提供所有這些語言的安全漏洞警報的功能。 對於每一個，還有無數競爭的開發人員IDE和工作室。 這些現在已經發展成為低代碼平台和自動編程客戶端，這將不可避免地使該領域變得更加複雜。 代碼分析和靜態掃描是第一道防線。
- 以安全為中心的開發人員工具的新領域
如今，開發人員仍在編寫Selenium腳本，以自動進行身份驗證，以便在具有虛擬用戶的Docker容器和VM上測試新版本的應用程序。在最簡單的情況下，將密碼直接寫入未加密的文件中，以進行新的測試和發布版本。 這構成了一個頻繁且重要的安全漏洞。我們剛剛了解到，一個不安全的Docker映像註冊表公開了Aeroflot核心Web應用程序的全部源代碼。 正如我們所看到的，諸如容器化之類的完全由開發人員居住的領域現在正強烈要求進行審查，以避免災難性的數據丟失。
自動化漏洞源代碼掃描等功能現在必須成為企業應用程序開發中的標準功能。
處於壓力之下的開發人員可能會忘記：可能有40個腳本批量運行，從而構成了一個構建。例如，該批處理可以一次全部上傳到由詹金斯觸發的存儲庫。有權訪問該存儲庫的任何人都可以獲取包含身份驗證憑據的腳本！這曾經是僅限開發人員的區域。
開發人員分享帖子，以了解如何在不熟悉的情況下執行某些操作（通常會尋找捷徑）。一篇文章說明了一種使用Selenium為測試案例編寫登錄腳本的簡單方法。另一篇文章告誡開發人員這樣做！這是一個人人享有的免費區域，充滿風險。這是幾乎沒有安全保障的邊界。
持續集成交付的自動化流水線的瘋狂新領域迅速發展，並著重於速度和創新。在這種富有創造力的氛圍中，需要更加強調版本管理和存儲庫中的安全性。現在存在著以安全為中心的開發人員平台，該平台可實現所有版本控制和存儲庫工具，但具有至關重要的安全性。自動化漏洞源代碼掃描等功能現在必須成為企業應用程序開發中的標準功能。
參考文件
https://medium.com/@MentorMate/svn-git-out-of-here-how-to-choose-your-version-control-system10b44750a75c
https://www.csoonline.com/article/2610857/security/protect-your-source-code-before-it-s-too-late.html
https://techbeacon.com/5-ways-security-testing-teams-can-tackle-new-source-code-attacks
https://qxf2.com/blog/dont-hardcode-usernames-and-passwords-in-your-test-scripts/
沒有留言:
張貼留言