從某網站的支付洩漏看安全實踐

ThoughtWorks發表於2017-03-31
網站

安全事故

2014年烏雲網釋出了某旅行網站（以下簡稱X網站）的安全支付漏洞，X網站因長時間開啟支付服務除錯介面，導致使用者信用卡資訊面臨洩露風險；在針對其進行進一步的掃描後，烏雲發現X網站的分站原始碼可打包下載，其資料庫配置和支付介面因此被直接洩露。

（圖片來自：http://t.cn/Rt7siGq）

在X網站所洩漏的資料中，最引人關注的當屬信用卡的CVV碼。由於大量國外網站可以直接通過CVV碼進行支付驗證，使用者直接面臨盜刷的風險；X網站的行為也公然違反了《銀聯卡收單機構賬戶資訊保安管理標準》：

各收單機構系統只能儲存用於交易清分、差錯處理所必需的最基本的賬戶資訊，不得儲存銀行卡磁軌資訊、卡片驗證碼、個人標識程式碼(PIN)及卡片有效期。

混用測試環境與產品環境、明文記錄使用者敏感資料、違反相關技術標準、公網暴露資料庫密碼。X網站的安全事故對很多企業的IT部門都是警示，它提醒我們，隨著網際網路的發展，軟體安全和資訊保安不再是安裝防火牆所能保障的，它需要企業從軟體開發的第一分鐘就開始關注安全並積極採取行動，把軟體安全內建到研發過程中。

技術雷達的安全概念

技術雷達是ThoughtWorks的定期發表物，它包含了ThoughtWorks對於前沿技術和實踐的觀察與理解，是軟體工程實踐的風向標之一，在2016年4月期技術雷達中，與安全相關的技術與實踐有13項，佔到總數的13%（採用2項，實驗5項，評估6項），從軟體開發生命週期的角度去觀察這十三項安全實踐：

  • 分析階段：1項
  • 開發階段：8項
  • 測試階段：2項
  • 運維階段：2項

通過這個趨勢我們可以觀察到，軟體的安全問題已經不僅僅存在於開發結束後，對於安全的管理已經開始貫穿軟體開發的全生命週期，內建安全正在成為一種趨勢。

如何理解安全實踐

僅僅在專案啟動的時候提出安全的要求，在專案結束前做滲透測試和審查，在現有的技術環境中已經不夠了，X網站就是很好的反例。那麼是不是越安全越好？

（圖片來自：http://t.cn/R6Kkcag）

安全措施應該被看作是“必要的浪費”，關鍵是與商業目標做好平衡，我們認為其中的關鍵是安全問題從出現在程式碼/配置裡到被發現之間的時間，即MTTD時間（Mean-Time-to-Detect），IT所追求的目標是將MTTD降到一個比較合理的水平， 且達到這一目標的成本是能夠被開發團隊所接受的。

基於這一理念，我們可以在軟體開發流程的各個階段內，在MTTD目標的牽引下，充分引入各種實踐、工具、流程制度等等，不管表現形式是什麼， 核心的目標都是在成本的限制下降低MTTD時間，我們看看從需求分析、開發、測試、運維幾個階段的角度入手，有哪些關於安全的工具、實踐可以採用。

需求分析階段

威脅建模，其主要目標是分析系統可能遭受的潛在攻擊、識別出風險並制定應對措施。威脅建模提供了一系列技術，可以幫助團隊在開發階段就能夠對潛在威脅進行識別和分類，其主要分為三步：

  • 解構應用：庖丁解牛般的解構軟體，比如網路、使用者資料儲存、其它資料、應用層等，分析攻擊者可能對哪些資訊感興趣以及他們最可能的侵入方式。
  • 分析風險：對於上述風險，在參考了攻擊的可能性、損失和成本因素後，進行優先順序排序。
  • 決定對策：對於高優先順序的風險在軟體開發的不同階段採取不同的措施進行防範。

當然威脅建模只是安全戰略的一部分，當它和其他技術（如建立跨團隊的安全專家，採取自動化安全掃描器）結合使用時，威脅建模才可以真正減輕企業面臨的安全風險。

開發階段

Let’s Encrypt，早些年SSL Labs公佈的2010年網際網路SSL調查報告（PDF）指出超過半數的Web伺服器沒能正確使用證照，主要的問題有證照不被瀏覽器信任、證照和域名不匹配、證照過期、證照信任鏈沒有正確配置、使用已知有缺陷的協議和演算法等。而且證照過期後的續簽和洩漏後的吊銷仍需進行繁瑣的人工操作。Let’s Encrypt就是為了解決這個痛點而誕生。它基於自動證照管理環境（Automated Certificate Management Environment），至少做到了兩件事：免費發放證照、自動化更新證照。

（圖片來自：http://t.cn/R6CoUXB）

Let’s Encrypt由ISRG（Internet Security Research Group，網際網路安全研究小組）提供服務並得到了Mozilla、Cisco、Akamai、Electronic Frontier Foundation和Chrome等眾多公司和機構的支援。從2015年12月開始，Let’s Encrypt專案從封閉測試階段轉向公開測試階段，也就是說使用者不再需要收到邀請才能使用它了，這促使安全和隱私向前進了一大步。

OWASP Dependency Check，堡壘最容易從內部攻破，現代軟體開發少不了用到第三方的庫和外掛，這些庫是否安全呢？OWASP Dependency-check就是一款自動識別Java和.Net專案中所使用的第三方庫中是否有已知安全問題的軟體，通過第三方外掛，它也支援Ruby, Node.js, Python和C/C++。

HSTS，新的HTTP頭，可以用於強制要求瀏覽器與系統之間採取HTTPS通訊，目前新版瀏覽器都支援這一標頭檔案，Internet Explorer從Windows10技術預覽版開始支援。

iFrames for sandboxing，HTML5標準的一部分，在標籤中插入了sandbox屬性，開發團隊可以建立一種新的開發實踐。通過將第三方的元件放到iframe裡，並且使用iframe的sandbox屬性，只給iframe開放最小的許可權，避免第三方的元件訪問主頁面的資訊（比如DOM）。

Content Security Policies，新的HTTP頭，CSP的目的是減少跨站指令碼攻擊。比如通過指定Content-Security-Policy的default-src屬性為‘self’，強制要求只能使用本站資源，避免惡意指令碼在payload中加入惡意程式碼，下載和上傳資訊。CSP需要瀏覽器的支援。

（圖片來自：http://t.cn/R69APfE）

Gitrob，用於檢測是否有員工不小心把某些敏感資訊放到了Github公開庫裡。目前Gitrob只支援Github的組織級帳號，並只能掃描最近一次提交。

HashiCorp Vault，微服務架構需要管理大量伺服器和各種金鑰（祕鑰、API key、證照），“如何安全管理這些資訊”逐漸成為專案的一大挑戰。之前通過檔案或者環境變數儲存機密資訊的方式已經變得難以控制。HashiCorp Vault就是用於解決這一問題的，它可以作為開發的一個最佳實踐採用。

Repsheet，一個類似於防火牆的工具，下一代安全防護產品（作為第三方庫，在應用的原始碼裡使用）。可以分析和視覺化來自黑客的攻擊流量，使之只對正常流量放行。

測試階段

OWASP Application Security Verification Standard Project，ASVS是一個針對應用程式安全性的檢查清單，目前包括了22篇實踐，比如《不要在敏捷開發中忘記黑客使用者》，官方認為它可以作為：

  • 清單：用於開發人員自查。
  • 原則：作為安全人員和開發人員的橋樑。
  • 採購標準：用於企業採購軟體時進行技術打分的標準。

Sleepy Puppy，Netflix出品的一個用於追蹤、分析、 管理跨站指令碼攻擊的工具， 測試人員也可以利用這個工具進行跨站指令碼攻擊的測試。

運維階段

Linux security modules，一個框架，可以支援多種不同的安全框架

Deflect，對抗分散式、拒絕服務攻擊的服務

2017技術雷達

網際網路企業所採用業務模式往往是“以隱私換服務”，這間接促成了龐大的隱私黑產、傷害了個人的權益。2017年的技術雷達也體現了業界在隱私問題上的思考。本期雷達上，身份資料歐洲託管從“評估”進階為了“嘗試”，差分隱私開始進入雷達。

差分隱私，從源頭抓起

在2016年的WWDC大會上，蘋果宣佈自己加入了AI大戰，同時宣佈了不會走Facebook和谷歌的道路，在對於使用者資料的收集上採取了差分隱私技術，簡單來說，差分隱私是通過演算法對個體使用者資料新增噪音，讓任何人都不能憑此追蹤到具體的某一名使用者，但又可以允許機構成批分析資料以獲得大規模的整體趨勢。其目標是在保護使用者身份和資料詳情的同時，仍能提煉出一些基本資訊用於機器學習。

差分隱私的實施也將影響軟體架構，比如（部分）計算將重新回到本地（而非雲端），（夜間）批量處理可能成為移動端的最佳實踐。

身份資料託管，減少干預

由於網際網路企業擁有的資料越來越多，政府也在通過各種渠道滲透網際網路公司，試圖獲取資料的控制權，稜鏡門所暴露的政府檔案讓全球都意識到了這個問題。而歐洲是對於PII資料管控最為嚴格、立法最為完善的區域。比如：

在這樣的監管下，Amazon這樣的巨頭也不得不推出相關服務，以響應這樣的監管措施。

在可行的情況下，儘量考慮通過歐洲的資料中心進行託管是進一步減少干擾、增強隱私的方法。

相關文章