企業(yè)安全建設指南（金融行業(yè)安全架構與技術實踐）第二部分

企業(yè)安全建設指南金融行業(yè)安全架構與技術實踐（第二部）目錄\h第二部分安全技術實戰(zhàn)\h\h\h第11章互聯(lián)網(wǎng)應用安全\h\h\h11.1端口管控\h\h\h11.2Web應用安全\h\h\h11.3系統(tǒng)安全\h\h\h11.4網(wǎng)絡安全\h\h\h11.5數(shù)據(jù)安全\h\h\h11.6業(yè)務安全\h\h\h11.7互聯(lián)網(wǎng)DMZ區(qū)安全管控標準\h\h\h11.8小結\h\h\h第12章移動應用安全\h\h\h12.1概述\h\h\h12.2APP開發(fā)安全\h\h\h12.2.1AndroidManifest配置安全\h\h\h12.2.2Activity組件安全\h\h\h12.2.3Service組件安全\h\h\h12.2.4Provider組件安全\h\h\h12.2.5BroadcastReceiver組件安全\h\h\h12.2.6WebView組件安全\h\h\h12.3APP業(yè)務安全\h\h\h12.3.1代碼安全\h\h\h12.3.2數(shù)據(jù)安全\h\h\h12.3.3其他話題\h\h\h12.4小結\h\h\h第13章企業(yè)內網(wǎng)安全\h\h\h13.1安全域\h\h\h13.2終端安全\h\h\h13.3網(wǎng)絡安全\h\h\h13.3.1網(wǎng)絡入侵檢測系統(tǒng)\h\h\h13.3.2異常訪問檢測系統(tǒng)\h\h\h13.3.3隱蔽信道檢測系統(tǒng)\h\h\h13.4服務器安全\h\h\h13.5重點應用安全\h\h\h13.6漏洞戰(zhàn)爭\h\h\h13.6.1弱口令\h\h\h13.6.2漏洞發(fā)現(xiàn)\h\h\h13.6.3SDL\h\h\h13.7蜜罐體系建設\h\h\h13.8小結\h\h\h第14章數(shù)據(jù)安全\h\h\h14.1數(shù)據(jù)安全治理\h\h\h14.2終端數(shù)據(jù)安全\h\h\h14.2.1加密類\h\h\h14.2.2權限控制類\h\h\h14.2.3終端DLP類\h\h\h14.2.4桌面虛擬化\h\h\h14.2.5安全桌面\h\h\h14.3網(wǎng)絡數(shù)據(jù)安全\h\h\h14.4存儲數(shù)據(jù)安全\h\h\h14.5應用數(shù)據(jù)安全\h\h\h14.6其他話題\h\h\h14.6.1數(shù)據(jù)脫敏\h\h\h14.6.2水印與溯源\h\h\h14.6.3UEBA\h\h\h14.6.4CASB\h\h\h14.7小結\h\h\h第15章業(yè)務安全\h\h\h15.1賬號安全\h\h\h15.1.1撞庫\h\h\h15.1.2賬戶盜用\h\h\h15.2爬蟲與反爬蟲\h\h\h15.2.1爬蟲\h\h\h15.2.2反爬蟲\h\h\h15.3API網(wǎng)關防護\h\h\h15.4釣魚與反制\h\h\h15.4.1釣魚發(fā)現(xiàn)\h\h\h15.4.2釣魚處置\h\h\h15.5大數(shù)據(jù)風控\h\h\h15.5.1基礎知識\h\h\h15.5.2風控介紹\h\h\h15.5.3企業(yè)落地\h\h\h15.6小結\h\h\h第16章郵件安全\h\h\h16.1背景\h\h\h16.2入站安全防護\h\h\h16.2.1郵箱賬號暴力破解\h\h\h16.2.2郵箱賬號密碼泄露\h\h\h16.2.3垃圾郵件\h\h\h16.2.4郵件釣魚\h\h\h16.2.5惡意附件攻擊\h\h\h16.2.6入站防護體系小結\h\h\h16.3出站安全防護\h\h\h16.4整體安全防護體系\h\h\h16.5小結\h\h\h第17章活動目錄安全\h\h\h17.1背景\h\h\h17.2常見攻擊方式\h\h\h17.2.1SYSVOL與GPP漏洞\h\h\h17.2.2MS14-068漏洞\h\h\h17.2.3Kerberoast攻擊\h\h\h17.2.4內網(wǎng)橫移抓取管理員憑證\h\h\h17.2.5內網(wǎng)釣魚與欺騙\h\h\h17.2.6用戶密碼猜解\h\h\h17.2.7獲取AD數(shù)據(jù)庫文件\h\h\h17.3維持權限的各種方式\h\h\h17.3.1krbtgt賬號與黃金票據(jù)\h\h\h17.3.2服務賬號與白銀票據(jù)\h\h\h17.3.3利用DSRM賬號\h\h\h17.3.4利用SIDHistory屬性\h\h\h17.3.5利用組策略\h\h\h17.3.6利用AdminSDHolder\h\h\h17.3.7利用SSP\h\h\h17.3.8利用SkeletonKey\h\h\h17.3.9利用PasswordChangeNofity\h\h\h17.4安全解決方案\h\h\h17.4.1活動目錄整體架構及相關規(guī)范\h\h\h17.4.2技術體系運營\h\h\h17.4.3外圍平臺安全\h\h\h17.4.4被滲透后的注意事項\h\h\h17.5小結\h\h\h第18章安全熱點解決方案\h\h\h18.1DDoS攻擊與對策\h\h\h18.1.1DDoS防御常規(guī)套路\h\h\h18.1.2一些經(jīng)驗\h\h\h18.2勒索軟件應對\h\h\h18.3補丁管理\h\h\h18.3.1Windows\h\h\h18.3.2Linux\h\h\h18.4堡壘機管理\h\h\h18.5加密機管理\h\h\h18.5.1選型\h\h\h18.5.2高可用架構與監(jiān)控\h\h\h18.5.3應用梳理\h\h\h18.5.4上下線與應急\h\h\h18.6情報利用\h\h\h18.7網(wǎng)絡攻防大賽與CTF\h\h\h18.8小結\h\h\h第19章安全檢測\h\h\h19.1安全檢測方法\h\h\h19.2檢測工具\h\h\h19.3安全檢測思路和流程\h\h\h19.4安全檢測案例\h\h\h19.4.1收集信息\h\h\h19.4.2暴力破解\h\h\h19.4.3XSS檢測\h\h\h19.4.4OS命令執(zhí)行檢測\h\h\h19.4.5SQL注入檢測\h\h\h19.4.6XML實體注入檢測\h\h\h19.4.7代碼注入\h\h\h19.4.8文件上傳漏洞檢測\h\h\h19.4.9支付漏洞檢測\h\h\h19.4.10密碼找回漏洞\h\h\h19.4.11文件包含漏洞\h\h\h19.5紅藍對抗\h\h\h19.6小結\h\h\h第20章安全運營\h\h\h20.1安全運營概述\h\h\h20.2架構\h\h\h20.3工具\h\h\h20.4所需資源\h\h\h20.5安全運營的思考\h\h\h20.6小結\h\h\h第21章安全運營中心\h\h\h21.1安全運營中心概述\h\h\h21.2ArcSight簡介\h\h\h21.3SOC實施規(guī)劃和架構設計\h\h\h21.3.1明確需求\h\h\h21.3.2架構環(huán)境\h\h\h21.3.3硬件規(guī)格\h\h\h21.3.4日志管理策略\h\h\h21.3.5應用的資產(chǎn)和架構信息\h\h\h21.3.6外部信息集成策略\h\h\h21.3.7開發(fā)方法及方式\h\h\h21.3.8工作流規(guī)劃\h\h\h21.3.9成果度量\h\h\h21.4ArcSight安裝配置\h\h\h21.4.1安裝前準備\h\h\h21.4.2初始化安裝\h\h\h21.4.3安裝后驗證\h\h\h21.4.4性能調優(yōu)\h\h\h21.4.5初始備份\h\h\h21.4.6壓力測試\h\h\h21.4.7其他參數(shù)調整\h\h\h21.5小結\h\h\h第22章安全資產(chǎn)管理和矩陣式監(jiān)控\h\h\h22.1安全資產(chǎn)管理\h\h\h22.1.1面臨的問題\h\h\h22.1.2解決思路和方案\h\h\h22.1.3幾點思考\h\h\h22.2矩陣式監(jiān)控\h\h\h22.2.1存在的問題\h\h\h22.2.2解決方案\h\h\h22.2.3收益和體會\h\h\h22.3小結\h\h\h第23章應急響應\h\h\h23.1概述\h\h\h23.2事件分類\h\h\h23.3事件分級\h\h\h23.4PDCERF模型\h\h\h23.5其他話題\h\h\h23.6小結\h\h\h第24章安全趨勢和安全從業(yè)者的未來\h\h\h24.1職業(yè)規(guī)劃方法論\h\h\h24.2安全環(huán)境趨勢和安全從業(yè)趨勢\h\h\h24.3安全從業(yè)指南\h\h\h24.4安全從業(yè)注意事項\h\h\h24.5小結\h\h第二部分安全技術實戰(zhàn)第11章互聯(lián)網(wǎng)應用安全第12章移動應用安全第13章企業(yè)內網(wǎng)安全第14章數(shù)據(jù)安全第15章業(yè)務安全第16章郵件安全第17章活動目錄安全第18章安全熱點解決方案第19章安全檢測第20章安全運營第21章安全運營中心第22章安全資產(chǎn)管理和矩陣式監(jiān)控第23章應急響應第24章安全趨勢和安全從業(yè)者的未來第11章互聯(lián)網(wǎng)應用安全Web2.0時代，企業(yè)會將越來越多的應用暴露在互聯(lián)網(wǎng)上，帶來的風險不容忽視。傳統(tǒng)企業(yè)會用防火墻進行隔離，將應用部署在隔離區(qū)（Demilitarizedzone，DMZ），圖11-1是一個簡單的示意圖。圖11-1傳統(tǒng)企業(yè)互聯(lián)網(wǎng)應用示意圖防火墻在這里的作用有兩點：一是將內網(wǎng)、DMZ區(qū)、互聯(lián)網(wǎng)進行隔離，二是將DMZ的私網(wǎng)地址映射到互聯(lián)網(wǎng)上供外部訪問。當然，實際企業(yè)可能做映射的不一定是防火墻，也有可能是負載均衡設備。當一個應用需要對互聯(lián)網(wǎng)訪問時，需要注意哪些事項，本章將從外到里逐一闡述。11.1端口管控首先要做的就是端口管控，即在防火墻上嚴格限制對外開放的端口。原則上DMZ服務器只允許對外開放80、443端口，而且DMZ服務器不允許主動訪問外部，訪問外部的業(yè)務需要一對一開通訪問。常見的端口管控誤區(qū)如下：·有些企業(yè)管理員為了方便維護，在防火墻上直接對外開放Telnet、SSH、RDP的端口，這是非常不明智的，只要知道密碼，黑客就可以通過這些端口獲得交換機/服務器的權限，即使不知道密碼，也可以通過暴力猜解密碼獲得登錄憑證。有經(jīng)驗的管理員都知道，只要將SSH對外開放，系統(tǒng)日志就會出現(xiàn)大量的登錄失敗日志。·還有一些FTP、MSSQL、MySQL、Redis、Rynsc、memcached、Elasticsearch、Mongodb等相關應用的端口，也不應該對互聯(lián)網(wǎng)開放，否則各種自動化的攻擊工具或蠕蟲也會很快通過這些端口得到相應的權限，甚至直接加密你的數(shù)據(jù)進行勒索。有興趣的讀者可以上網(wǎng)搜索“FTP本地提權”“Redis未授權訪問”“MongoDB勒索”“Elasticsearch勒索”等等。一般大型企業(yè)的互聯(lián)網(wǎng)出口或者業(yè)務系統(tǒng)會比較多，在日常防火墻維護過程中，難免會出現(xiàn)遺漏，所以需要有相應的機制來保障高危端口不對外開放，開放了要及時發(fā)現(xiàn)，這就需要端口掃描。說到端口掃描工具，必談Nmap，此外還有Zmap、Masscan也很受歡迎，下面簡單介紹Nmap和Masscan。Nmap功能非常強大，仔細看其幫助即可體會，如圖11-2所示。Nmap支持列表改入、各種主機發(fā)現(xiàn)、端口掃描技術、操作系統(tǒng)探測、掃描時間控制、各種格式輸出等，甚至還支持外部腳本針對性的檢測漏洞。端口掃描技術常用的有：半開放掃描（TCPSYN）、全連接掃描（TCPConnect）、ACK掃描、FIN掃描等。另外，Nmap掃描輸出的xml格式結果文件，用腳本解析起來很方便，和其他系統(tǒng)對接非常輕松。圖11-2Namp的使用Nmap功能雖然強大，但在大網(wǎng)段全端口掃描時會非常慢，這時候就需要Masscan了。Masscan號稱是“最快的互聯(lián)網(wǎng)端口掃描器”，最快可以在6分鐘內掃遍互聯(lián)網(wǎng)，每秒可以發(fā)送一百萬個數(shù)據(jù)包，適合于對大量地址進行快速掃描。Masscan提供較為豐富的選項。例如，用戶可以指定掃描的端口、路由器地址、發(fā)包速率和最大速率等。同時，它還支持多種文件格式用于保存掃描結果。對于大型企業(yè)，建議采用聯(lián)合方式，例如先用Masscan快速掃描一遍，然后再針對性地用Nmap掃描，以獲取更多信息，包括操作系統(tǒng)版本、端口對應的Banner信息等。當掃描程序發(fā)現(xiàn)高危端口后，可以實時輸出日志給SOC，以便一線人員實時跟進處理。在實際工作中，掃描還需要注意避開業(yè)務高峰、調整發(fā)包速率參數(shù)等，以免引起不必要的麻煩。11.2Web應用安全端口管控工作是基礎，做好端口管控工作后，需要將重點放在Web安全上。OWASP組織（OpenWebApplicationSecurityProject，開放式Web應用程序安全項目）每年都會有個Top10的風險列表，包括各種注入（SQL、NoSQL、OS、LDAP等注入）、XSS攻擊、CSRF，等等。在Web安全領域，吳翰清的《白帽子講Web安全》值得推薦，客戶端腳本安全、服務端應用安全都包括在內。作為企業(yè)安全從業(yè)人員，除了要知道黑客怎么攻擊外，還需要關注我們怎么防守，在哪些維度上進行防守。1.Web應用防火墻針對常規(guī)的Web掃描行為，Web應用防火墻（WebApplicationFirewall，WAF）基本上可以直接攔截或阻斷。Web應用防火墻是通過執(zhí)行一系列針對HTTP/HTTPS的安全策略來專門為Web應用提供保護的一款產(chǎn)品。與傳統(tǒng)防火墻不同，WAF工作在應用層，因此對Web應用防護具有先天的技術優(yōu)勢?；趯eb應用業(yè)務和邏輯的深刻理解，WAF對來自Web應用程序客戶端的各類請求進行內容檢測和驗證，確保其安全性與合法性，對非法的請求予以實時阻斷，從而對各類網(wǎng)站站點進行有效防護。WAF產(chǎn)品有基于硬件的，也有基于軟件的，還有基于云的：·硬件WAF一般支持透明橋接模式、旁路模式、反向代理模式等部署方式，而且性能好、支持ByPass等，所以是我們的首選。當然，有些防火墻的IPS模塊也具備一定的WAF功能，例如CheckPoint；有些負載均衡設備本身也支持SSL卸載和應用防護，例如F5。在實際的部署過程中，需要考慮在哪一層部署，或者結合各產(chǎn)品自身特性綜合性地部署?！ぴ谝恍┎恢匾膮^(qū)域或者基于成本考慮，也可以使用軟件WAF，比較著名的有ModSecurity。ModSecurity的規(guī)則包括基礎規(guī)則集、SLR規(guī)則集、可選規(guī)則集、實驗性規(guī)則集?；A規(guī)則集主要包括與HTTP協(xié)議規(guī)范相關的一些規(guī)則，一些SQL注入、XSS、目錄遍歷、Webshell等；SLR規(guī)則集則是針對特定應用（例如Joomla、PHPBB、WordPress等）的漏洞利用規(guī)則?？紤]到ModSecurity性能有所不足，還可以使用基于nginx的方案，如Naxsi，或者其他開源方案，如GitHub上的FreeWAF?？陀^來講，使用開源WAF對安全人員要求較高，也更靈活?！び行┢髽I(yè)考慮將業(yè)務上云，于是出現(xiàn)了基于云的WAF，其本質上也是軟件WAF，結合了一些日志分析、機器學習的技術。整體來講，可以考慮在前端有硬件WAF的情況下，在服務器上啟用軟件WAF，結合業(yè)務場景對特定請求進行重點防護，以做補充。2.入侵檢測/防御系統(tǒng)雖然市面上某些WAF有利用機器學習的功能，可以對各種請求的參數(shù)進行學習并判定是否合法，但WAF更多是基于規(guī)則的，有規(guī)則就會有繞過的可能。針對這些可能繞過WAF的請求，我們還需要借助入侵檢測系統(tǒng)/入侵防御系統(tǒng)（IntrusionDetectionSystem/IntrusionPreventionSystem，IDS/IPS）類產(chǎn)品對WAF后端的流量進行分析，發(fā)現(xiàn)惡意行為。IDS開源的有Snort，網(wǎng)上有較多的資料，不再贅述。商業(yè)的IDS產(chǎn)品相對來講更有保障，有新漏洞也可以得到新的規(guī)則庫，在發(fā)生告警后還可以保留一段時間的數(shù)據(jù)包供進一步分析。3.漏洞掃描和滲透測試針對暴露在互聯(lián)網(wǎng)上的應用，我們自己也要開展定期掃描、內外部滲透測試等工作。漏洞掃描工具常見的有AWS、IBMAppscan、HPWebInspect、Nikto等商業(yè)或開源掃描器，針對一些漏洞邏輯可能還會使用BurpSuite、Fiddler等工具進行輔助。筆者建議有條件的企業(yè)，對一些企業(yè)應用經(jīng)常出現(xiàn)的漏洞進行針對性的掃描，適當?shù)臅r候可以結合開源代碼定制自己的掃描器，這樣的好處是便于內部IPS和WAF識別或加白處理。滲透測試往往包含內部測試和外部測試，內部安全人員對業(yè)務理解更深，更容易發(fā)現(xiàn)問題?？紤]到內部人手、技能、經(jīng)驗等原因，企業(yè)一般會采購外部滲透服務，有一些是國家測評中心等國家單位，有些是綠盟、安恒、長亭科技這樣的企業(yè)。筆者建議是多找?guī)准遥詈脤崿F(xiàn)按漏洞付費，每個公司的滲透人員都有不同的經(jīng)驗和思路，多找?guī)准彝芨尤娴馗采w。關于漏洞掃描和滲透測試的內容，在第19章中有更詳細的描述。11.3系統(tǒng)安全未攔截的請求到了DMZ服務器，對應用或者系統(tǒng)有什么樣的影響，我們放到這一節(jié)來探討。常規(guī)的系統(tǒng)加固、WebServer加固、目錄權限設置等就不說了，惡意請求的目的可能是：想利用上傳功能直接上傳一個WebShell，利用文件包含功能直接引用一個遠程的WebShell，利用文件解析漏洞上傳惡意圖片或視頻，觸發(fā)特定漏洞執(zhí)行命令，或者是已經(jīng)拿到WebShell直接請求執(zhí)行命令。如何有效發(fā)現(xiàn)WebShell，是一個很大的話題，這里不詳細展開。一般來講，有以下幾個思路：·文件內容掃描，看是否有一些高危函數(shù)、黑客版權信息等，改進一點的是結合機器學習對網(wǎng)絡上的各種樣本進行收集提取?！そY合文件變化及屬性來判斷。·結合網(wǎng)絡流量特征來判斷?！そY合腳本底層執(zhí)行動作來判斷。在系統(tǒng)上，有沒有較好的方式發(fā)現(xiàn)異常呢？打個比方，有些黑客喜歡拿到WebShell后上來就執(zhí)行whoami之類的指令，我們是否可以利用基于主機型入侵檢測系統(tǒng)（Host-basedIntrusionDetectionSystem，HIDS）中的檢測模型發(fā)現(xiàn)其中的異常呢？操作系統(tǒng)本身就有一些審計日志功能，針對一些特定的攻防場景，需要針對性的研究，定制規(guī)則以發(fā)現(xiàn)異常。1.OSSEC開源的HIDS產(chǎn)品中，OSSEC比較出名。OSSEC是一款開源的基于主機的入侵檢測系統(tǒng)，包括日志分析、文件/注冊表完整性檢測、安全策略監(jiān)控、Rootkit檢測、實時報警、動態(tài)響應等功能。它的最大優(yōu)勢在于支持很多操作系統(tǒng)，包括Linux、MacOS、Solaris、HP-UX、AIX和Windows。OSSEC默認帶有一些規(guī)則，包括SSH破解、Windows登錄失敗、賬號添加修改等，安裝上簡單測試就可以看到效果，但要實際投產(chǎn)使用，還需要針對性地寫一些插件規(guī)則以滿足特定場景下的攻防策略需求。另外，OSSEC有些功能的實現(xiàn)方式不是非常完美，例如，Rookit檢測中的代碼居然是直接利用netstat命令的結果進行對比，如圖11-3所示。圖11-3Rookit檢測中的代碼直接利用netstat命令的結果進行對比在負載高的機器上，netstat的執(zhí)行會非常慢，還會因為時間原因產(chǎn)生誤報。2.Sysmon對于Windows系統(tǒng)，建議使用Sysmon。Sysmon是由WindowsSysinternals出品的Sysinternals系列中的工具，它以系統(tǒng)服務和設備驅動程序的方式安裝在系統(tǒng)上，并保持常駐性。Sysmon用來監(jiān)視和記錄系統(tǒng)活動，并記錄到Windows事件日志，可以提供有關進程創(chuàng)建、網(wǎng)絡連接和文件創(chuàng)建時間更改的詳細信息。Sysmon由微軟出品，兼容性有保障，功能強大，對Windows審計日志是一個非常棒的補充。在大量機器部署的情況下，結合Sysmon+Evtsys收集日志匯總到SOC，定制CASE，也是一個不錯的方案。11.4網(wǎng)絡安全假設某臺服務器因為有漏洞已經(jīng)被攻陷，黑客一般會在機器上進行各種翻找，甚至進一步探測其他網(wǎng)絡。WebShell通常為了方便都提供反彈shell的功能，即主動外連到特定端口，如果前面我們的防火墻在外連這塊控制得不好，就容易出問題。針對這個隱患，我們建議在網(wǎng)絡上針對主動出站的連接進行記錄，與學習到的基線或者自行維護的黑白名單進行對比，以發(fā)現(xiàn)問題，我們把它稱之為“異常流量檢測系統(tǒng)”，在DMZ環(huán)境下只需關注主動外連的情況，相對簡單。在DMZ內網(wǎng)活動的時候，流量不一定會被鏡像到，這時候我們需要借助蜜罐來發(fā)現(xiàn)異常。在每個DMZ網(wǎng)段內部署一到兩個蜜罐，可以有效發(fā)現(xiàn)針對內網(wǎng)的掃描和探測行為。提到蜜罐，大家都熟知honeyd，是一個非常優(yōu)秀的開源蜜罐框架，支持模擬多個IP主機和任意的網(wǎng)絡拓撲結構，還支持服務模擬腳本來模擬后端應用，如IIS、Telnet、POP3等。在實際環(huán)境中需要關注其可能帶來的運行風險，例如，其arpd的組件使用類似ARP欺騙的方式牽引流量到密灌，在錯誤的運行方式下，如果同一網(wǎng)段任意存活主機在某時刻短暫掉線后，可能會被蜜罐程序的ARP包刷新網(wǎng)關上的MAC地址表，導致原IP無法正常訪問。其實，蜜罐不一定要非常專業(yè)，在一些特定區(qū)域比如DMZ一些簡單的基于端口訪問的初級蜜罐也能發(fā)揮很大作用。11.5數(shù)據(jù)安全一個合法的Web請求最后可能會涉及后端各種業(yè)務邏輯，跟數(shù)據(jù)庫打交道，在頁面上展示相關內容等。這里需要關注兩個問題，一是到數(shù)據(jù)庫的請求是否真的合法；二是頁面上返回的輸出是否包含敏感信息，我們都放在這一節(jié)來講。一個SQL注入語法可能經(jīng)過各種變形，加之利用服務端和WAF特性進行了繞過，但到了數(shù)據(jù)庫這里，一切都是非常清晰的，數(shù)據(jù)庫審計類產(chǎn)品可以輕松發(fā)現(xiàn)一些注入行為。數(shù)據(jù)庫審計類產(chǎn)品有兩類，一種是基于proxy或插件模式的；一種是基于網(wǎng)絡流量的?；趐roxy好理解，應用先連接proxy，再由proxy連接后端真實數(shù)據(jù)庫，這樣所有的SQL請求都會被proxy記錄下來；而有些數(shù)據(jù)庫有一些審計插件，例如Mcafee開源的MySQL_Audit插件，只需將對應的so文件復制到plugin_dir目錄然后在配置文件里啟用即可。但這兩個方案都對應用有一定的侵入性，穩(wěn)妥起見，建議使用基于網(wǎng)絡流量的數(shù)據(jù)庫審計類產(chǎn)品，即將應用到DB的流量鏡像給設備，由設備再還原出SQL語句。商業(yè)的數(shù)據(jù)庫審計產(chǎn)品有imperva、安恒等。一個正常的頁面輸出，也可能會涉及銀行卡號、身份證、手機號等客戶資料信息，一般應用需要做一些脫敏處理。在一些特殊情況下可能處理得不夠好，這時候就需要有一定的監(jiān)測機制才能發(fā)現(xiàn)這種問題。常規(guī)的DLP方案在這里需要經(jīng)過一定的調整，重點不再是分析HTTP的Request，而是分析服務器的Response信息。在Response信息里不僅能發(fā)現(xiàn)一些客戶資料信息，還能發(fā)現(xiàn)一些異常的東西，諸如目錄遍歷、特定WebShell等的問題。當然有些功能也可以在WAF里實現(xiàn)，WAF也有針對Response的一些檢測規(guī)則。11.6業(yè)務安全還有一個場景需要提到，就是互聯(lián)網(wǎng)應用中與業(yè)務邏輯相關的安全問題，統(tǒng)稱“業(yè)務安全”。例如，一個簡單的登錄頁面，可能涉及人機識別、驗證碼、找回密碼功能等，而攻擊者可能會利用暴力破解、撞庫等方式進行嘗試請求；再例如，一個簡單的查看個人信息頁面，涉及Session或Cookie驗證，而攻擊者可能會通過修改URL中的ID或者修改本地Cookie來看其他人的信息。還有一些是關于接口的安全問題，例如，某分類信息網(wǎng)站的簡歷泄露事件，就是攻擊者組合了3個不同的接口獲取相應信息。這里的對抗方法，更多從風控角度出發(fā)，收集access日志、業(yè)務日志進行分析，再結合外部情報（黑白名單庫）、機器學習等，是一個非常細分的領域，我們將在第15章中詳細介紹。11.7互聯(lián)網(wǎng)DMZ區(qū)安全管控標準針對DMZ區(qū)的互聯(lián)網(wǎng)應用安全防護體系，我們將上面提到的各種管控技術方案進行抽象，并考慮實際落地運營情況，形成一個互聯(lián)網(wǎng)DMZ區(qū)安全管控標準，供大家參考，見表11-1。表11-1互聯(lián)網(wǎng)DMZ區(qū)安全管控標準當然，除了表11-1所提到的技術點之外，還涉及上線流程管控、防分布式拒絕服務攻擊（DDoS）等。常規(guī)的上線流程管控包括主機上線前掃描、應用上線前掃描、日志采集、安全防護軟件部署、堡壘機納管等各個環(huán)節(jié)，建議與ITIL流程結合在一起。而DDoS對抗也是一個很專業(yè)的細分領域，我們后面會在18.1節(jié)中介紹。最后，在互聯(lián)網(wǎng)DMZ區(qū)可能還會部署類似VPN、郵件等系統(tǒng)，考慮到這些更多的是為企業(yè)內部員工使用，所以我們將在第13章中進行闡述。11.8小結本章從外向內對互聯(lián)網(wǎng)應用安全防護做了一個基本的闡述，包括端口、Web應用、系統(tǒng)、網(wǎng)絡、業(yè)務、數(shù)據(jù)等，有些內容會在后面的章節(jié)中更為詳細地闡述。需要特別說明的是，金融行業(yè)作為一個強監(jiān)管行業(yè)，在做安全工作的時候更多是考慮效果（合規(guī)、風險控制與轉移、管理與運營落地等），所以在安全解決方案的選擇上更偏重成熟穩(wěn)定的商業(yè)產(chǎn)品，再結合企業(yè)實際需求使用開源方案做適當?shù)难a充和輔助，這一點和互聯(lián)網(wǎng)公司因成本、規(guī)模等原因而更多選擇開源或自研是有較大差別的。第12章移動應用安全隨著智能手機以及4G網(wǎng)絡的普及和金融科技的深入發(fā)展，人們的生活已經(jīng)被逐步改變，使用手機支付、辦公、購物、娛樂等成為主流方式。根據(jù)中國互聯(lián)網(wǎng)絡信息中心發(fā)布的第41次《中國互聯(lián)網(wǎng)絡發(fā)展狀況統(tǒng)計報告》截至2017年12月，我國手機網(wǎng)民規(guī)模達7.53億，網(wǎng)民中使用手機上網(wǎng)人群的占比由2016年的95.1%提升至97.5%。隨著移動終端在日常生活中承擔的數(shù)字金融業(yè)務越來越多，其安全性越來越受到重視。12.1概述早在2012年，央行就發(fā)布了金融行業(yè)移動支付標準，涵蓋了應用基礎、安全保障、設備、支付應用、聯(lián)網(wǎng)通用5大類35項標準，并從產(chǎn)品形態(tài)、業(yè)務模式、聯(lián)網(wǎng)通用、安全保障等方面明確了系統(tǒng)化的技術要求，覆蓋中國金融移動支付各個環(huán)節(jié)的基礎要素、安全要求和實現(xiàn)方案，確立了以“聯(lián)網(wǎng)通用、安全可信”為目標的技術體系架構。2017年，泰爾終端實驗室依據(jù)相關標準對多款基于Android操作系統(tǒng)的手機銀行APP進行了安全測評，其測評內容包括通信安全性、鍵盤輸入安全性、客戶端運行時安全性、客戶端安全防護、代碼安全性和客戶端業(yè)務邏輯安全性等6個方面的39項內容，分析評測結果不容樂觀，如圖12-1所示。圖12-1泰爾終端實驗室2017年對幾大金融APP測試在報告的最后，該實驗室建議相關銀行采取更加安全的APP加固解決方案，同時增加應用分發(fā)渠道監(jiān)控，第一時間監(jiān)測盜版、篡改應用發(fā)布上線；增加應用自身完整性校驗功能，檢測到應用被篡改后，及時提醒用戶卸載非法應用或者自動進行更新修復。我們把移動安全問題分兩個話題來闡述：APP開發(fā)安全，APP業(yè)務安全。12.2APP開發(fā)安全APP應用安全，除了我們所熟知的APP加殼外，還有一些是應用程序本身的安全問題，例如組件安全、端口安全、數(shù)據(jù)安全等，甚至還有一些跟業(yè)務場景相關的。這里我們說一下APP開發(fā)中經(jīng)常遇到的問題與相應對策。12.2.1AndroidManifest配置安全每個Android應用的根目錄中都必須包含一個AndroidManifest.xml文件。Manifest文件為Android系統(tǒng)提供有關應用的基本信息，系統(tǒng)必須獲得這些信息才能運行任意應用代碼。此外，Manifest文件還可執(zhí)行以下操作：·為應用的Java軟件包命名。軟件包名稱充當應用的唯一標識符。·描述應用的各個組件，包括構成應用的Activity、服務、廣播接收器和內容提供程序。為實現(xiàn)每個組件的類命名并發(fā)布其功能。根據(jù)這些聲明，Android系統(tǒng)可以了解這組件具體是什么，以及在什么條件下可以啟動它們?！ご_定將托管應用組件的進程?！ぢ暶鲬帽仨毦邆淠男嘞薏拍茉L問API中受保護的部分并與其他應用交互。·聲明其他應用與該應用組件交互所需具備的權限?！ち谐鯥nstrumentation類，這些類可在應用運行期間提供分析和其他信息。這些聲明只會在應用處在開發(fā)和測試階段時出現(xiàn)在清單文件中，在應用發(fā)布之前會被刪除?！ぢ暶鲬盟璧淖畹虯ndroidAPI級別?！ち谐鰬帽仨氭溄拥膸?。我們所熟知的導出組件，是Android上最常見也是門檻最低的攻擊入口，如Manifest中組件設置不當?shù)脑挘痛嬖诒蝗我庹{用的可能。此外，在Manifest配置文件中，還有一些可被調試的程序、可被導出的應用數(shù)據(jù)以及與Scheme相關的配置開關，一旦開啟就會存在一些風險，筆者將常見的風險與對策整理成表格供讀者參考，如表12-1所示。表12-1Manifest配置不當類風險與對策12.2.2Activity組件安全Activity組件是Android四大組件中用戶唯一能夠看見的組件，作為軟件所有功能的顯示及與用戶交互的載體，其安全性不言而喻。除了前面說的組件導出暴露問題外，主要是訪問權限控制和被劫持問題。當Activity組件需要被外部特定程序調用時，建議使用android:permission屬性來指定一個權限字符串。

在啟動Activity時，加入標志位FLAG_ACTIVITY_NEW_TASK，就能使該Activity置于棧頂立即呈現(xiàn)給用戶。惡意軟件可以監(jiān)控目標Activity，偵測到目標Activity啟動后，立即彈出一個與該應用界面相同的Activity，實現(xiàn)偽裝目標Activity，也就是我們所說的“被劫持”問題。針對Activity劫持目前沒有特別好的辦法徹底解決，一個思路是在APP一些關鍵界面（比如登錄界面）被覆蓋時彈出一些提示信息，進入后臺的時候判斷是不是用戶自己觸發(fā)，如果不是也彈出提示信息。12.2.3Service組件安全Service組件是Android系統(tǒng)中的后臺進程，主要的功能是在后臺進行一些耗時的操作。建議私有Service不定義intent-filter并且設置exported為false，需要被同公司不同APP訪問時，可以將protectionLevel設置為signature；如果是合作伙伴APP訪問，需要對其APP簽名做校驗。若存在Service返回數(shù)據(jù)的情況，則需要關注敏感信息泄露風險。12.2.4Provider組件安全ContentProvider組件是Android應用的重要組件之一，管理對數(shù)據(jù)的訪問，主要用于不同的應用程序之間實現(xiàn)數(shù)據(jù)共享。ContentProvider的數(shù)據(jù)源不止包括SQLite數(shù)據(jù)庫，還可以是文件數(shù)據(jù)。通過將數(shù)據(jù)儲存層和應用層分離，ContentProvider為各種數(shù)據(jù)源提供了一個通用的接口。參見表12-2，如果在AndroidManifest文件中將某個ContentProvider的exported屬性設置為true，就會產(chǎn)生一些越權訪問數(shù)據(jù)的風險。訪問對象的不同結合App實現(xiàn)不當，可能會產(chǎn)生數(shù)據(jù)任意訪問、SQL注入、目錄遍歷等風險。1.私有權限定義錯誤導致數(shù)據(jù)被任意訪問私有權限定義經(jīng)常發(fā)生的風險是：定義了私有權限，但是根本沒有定義私有權限的級別，或者定義的權限級別不夠，導致惡意應用只要聲明這個權限就能夠訪問相應的ContentProvider提供的數(shù)據(jù)，造成數(shù)據(jù)泄露。2.本地SQL注入漏洞當ContentProvider的數(shù)據(jù)源是SQLite數(shù)據(jù)庫時，如果實現(xiàn)不當，而Provider又是暴露的，則可能會引發(fā)本地SQL注入漏洞。具體來說，ContentProvider的query()如果使用拼接字符串組成的SQL語句去查詢底層的SQLite數(shù)據(jù)庫時，容易發(fā)生SQL注入。3.目錄遍歷漏洞對外暴露的ContentProvider實現(xiàn)了OpenFile()接口，因此其他有相應調用該ContentProvider權限的應用即可調用ContentProvider的OpenFile()接口進行文件數(shù)據(jù)訪問。但是如果沒有進行ContentProvider訪問權限控制和對訪問的目標文件的URI進行有效判斷，攻擊者利用“../”實現(xiàn)目錄遍歷便可訪問任意可讀文件。更有甚者，在Openfile()接口的實現(xiàn)中，如果要訪問的文件不存在，就會創(chuàng)建此文件，也就是說還有可能往手機設備可寫目錄中寫入任意數(shù)據(jù)。針對以上問題，最重要的是要在APP設計開發(fā)之前，就要清楚哪些Provider的數(shù)據(jù)是用戶隱私數(shù)據(jù)或者其他重要數(shù)據(jù)，考慮是否要提供給外部應用使用，如果不需要提供，則應直接在Manifest文件中設置為不導出。注意：由于APIlevel在17以下的所有應用的“android:exported”屬性默認值都為true，因此如果應用的ContentProvider不必導出，建議顯式設置注冊的ContentProvider組件的“android:exported”屬性為false。如果必須要有數(shù)據(jù)提供給外部應用，則需要做好權限控制，明確什么樣的外部應用可以使用，盡量不要提供用戶隱私敏感信息。一般來講，大部分開放的Provider，都是提供給本公司其他應用使用，一般打包簽名APP的簽名證書是一致的，這樣便可以將Provider的ProtectionLevel設置為signature。如果是合作方的APP來訪問，可以將合作方APP的簽名哈希值預埋在提供Provider的APP中，提供Provider的APP要檢查請求訪問此Provider的APP的簽名，匹配通過了才能訪問。為了避免SQL語句，不要使用拼接字符串的形式，可以使用SQLiteDatabase類中的參數(shù)化查詢query()方法。為了防止目錄遍歷，建議去除ContentProvider中的OpenFile()接口，過濾限制跨域訪問，對訪問的目標文件路徑進行有效判斷，過濾“../”等字符串。12.2.5BroadcastReceiver組件安全BroadcastReceiver中文被譯為廣播接收者，用于處理接收到的廣播，廣播接收者的安全分為接收安全與發(fā)送安全兩個方面。1.接收安全動態(tài)注冊廣播如果僅為應用內部使用，應當將exported設置為false，這樣外部應用不能隨便發(fā)送廣播到自身程序中。如果需要接收外部應用，則需要配置權限，和前面Provider的一樣，如果是本公司其他APP，將ProtectionLevel設置為signature；如果是其他合作伙伴的APP，則除了設置ProtectionLevel外還建議避免敏感信息的傳遞。2.發(fā)送安全Android系統(tǒng)提供了兩種廣播發(fā)送方法，即sendOrderedBroadcast和sendBroadcast。有序廣播通過Context.sendOrderedBroadcast()來發(fā)送，所有的廣播接收器優(yōu)先級依次執(zhí)行，廣播接收器的優(yōu)先級通過receiver的intent-filter中的android:priority屬性來設置，數(shù)值越大優(yōu)先級越高。當廣播接收器接收到廣播后，可以使用setResult()函數(shù)來將結果傳給下一個廣播接收器接收，然后通過getResult()函數(shù)取得上個廣播接收器接收返回的結果。當廣播接收器接收到廣播后，也可以用abortBroadcast()函數(shù)讓系統(tǒng)攔截下該廣播，并將該廣播丟棄，使該廣播不再傳送到別的廣播接收器接收。普通廣播是完全異步的，通過Context的sendBroadcast()方法來發(fā)送，消息傳遞效率比較高，但所有receivers（接收器）的執(zhí)行順序不確定。接收器不能將處理結果傳遞給下一個接收器，并且無法終止廣播Intent的傳播，直到?jīng)]有與之匹配的廣播接收器為止。Android官方在SDK文檔中說明了一些不安全的API，包括：sendStickyBroadcast、sendStickyOrderedBroadcast、sendStickyOrderedBroadcastAsUser、sendStickyBroadcastAsUser，建議不要在APP使用。12.2.6WebView組件安全WebView是一個基于Webkit引擎、展現(xiàn)Web頁面的組件，APP通過調用該組件就可以訪問網(wǎng)頁內容，所以有非常多的移動應用都內嵌了WebView組件。而在通付盾發(fā)布的《2017年度移動應用安全態(tài)勢報告》中，與WebView組件相關的漏洞是排名前三的，分別是：未移除有風險的WebView系統(tǒng)隱藏接口，WebView遠程代碼執(zhí)行安全，WebView組件忽略SSL證書驗證錯誤漏洞，如圖12-2所示。圖12-2Android移動應用高危漏洞類型分布WebView在Android應用開發(fā)中廣泛使用，除了具有一般View的屬性和設置外，還可對URL請求、頁面加載、渲染、頁面交互進行處理，可謂功能強大。對黑客而言，它是一個非常理想的攻擊面，點開一個鏈接或者掃描一個二維碼就會執(zhí)行惡意代碼。在使用WebView組件過程中，除了一些系統(tǒng)隱藏接口，還會有一些與本地交互、保存密碼、HTTPS通信認證相關的風險需要關注，為了節(jié)省篇幅，筆者整理了一個WebView組件常見風險與對策表格，見表12-2。表12-2WebView組件相關風險與對策值得注意的是，AndroidN中增加了一個開發(fā)者選項，就是在所有的應用中將Web-View的渲染進程運行在獨立的沙箱中。即使惡意網(wǎng)頁通過漏洞在渲染進程中執(zhí)行了代碼，還需要更多的漏洞繞過沙箱的限制。這一特性將在AndroidO中默認啟用。但在這一緩解措施正式部署到大部分設備之前，通過攻擊WebView獲得遠程代碼執(zhí)行進而直接攻擊應用仍然是可行的。12.3APP業(yè)務安全除了一些在開發(fā)過程中的安全問題外，還有一些是跟業(yè)務相關，比如反編譯、二次打包、釣魚APP等各種問題，這里涉及一些混淆、加殼、簽名驗證、運行時環(huán)境檢測等技術方案。除此之外，還有一些是在業(yè)務上想做更多安全控制，比如數(shù)據(jù)防泄露、防截屏、安全鍵盤等。12.3.1代碼安全相比iOS系統(tǒng)的封閉及嚴格的APP審核及簽名控制，Android系統(tǒng)的開源以及基于Java的特性，導致APP在Android上更容易被反編譯。目前常用的一些反編譯工具（比如APKTool、dex2jar等）能夠毫不費勁地還原Java里的明文信息，Native里的庫信息也可以通過objdump或IDA獲取。而心懷不軌的人可能會通過反編譯后加入惡意的代碼邏輯，重新打包一個APK文件去發(fā)布安裝，也就是我們常說的“二次打包”問題。針對這些問題，常見的解決方案是代碼混淆、加殼、反調試、簽名驗證等。1.代碼混淆APP的代碼混淆包括Java代碼的混淆以及一些資源文件的混淆。Java語言編寫的代碼本身就容易被反編譯，Google很早就意識到這一點，在Android2.3的SDK中正式加入了ProGuard代碼混淆工具，開發(fā)人員可以使用它對自己的代碼進行保護。ProGuard提供了壓縮、混淆、優(yōu)化代碼以及反混淆棧跟蹤的功能，網(wǎng)上資料較多，不再贅述。資源文件的混淆，一些互聯(lián)網(wǎng)公司也提供了一些方法供參考，比如微信提供的AndResGuard（\h\h/shwenzhang/AndResGuard\h）等。2.加殼Android加殼分為dex加殼和對native編譯（即so文件加殼），主流的加殼技術基本可以分為四代：·整體dex加殼。對classes.dex文件進行整體加殼加密，存放在APK的資源中，運行時將加密后的classes.dex文件在內存中解密，并讓Dalvik虛擬機動態(tài)加載執(zhí)行?！し勒{試防Dump。整體dex在內存中解密，黑客通過內存Dump的方式即可拿到明文，所以出現(xiàn)了防調試、防內存Dump的技術?！し椒w抽離。相比前面整體加殼加密，第三代開始嘗試只對classes.dex文件中的方法、函數(shù)進行抽取加密，在Java虛擬機執(zhí)行具體某個方法時才將其動態(tài)解密，并以不連續(xù)的方式存放到內存中。后面慢慢發(fā)展成將Java代碼內關鍵算法、業(yè)務邏輯等函數(shù)自動轉化成native的C++代碼進行防護?！MP加殼/so加殼。我們知道程序的執(zhí)行，是依靠CPU對于符合規(guī)范的指令集的解析處理。如果將原指令集通過自定義規(guī)范進行變形處理，生成新的指令集（稱之為虛擬指令集），CPU將無法識別虛擬指令。此時若配合能夠解析虛擬指令集的解釋器（稱之為虛擬機），就可以達到不直接通過CPU而是通過虛擬機來執(zhí)行虛擬指令。這就是很多公司各種VMP保護方案的基本原理。對于使用AndroidNDK編寫的Native代碼，逆向它原本就有一定的困難，如果再添加外殼保護（比如UPX）則更加困難了。不同的加殼方案有著不同的效果，表12-3是某廠商網(wǎng)站上的風險描述表。表12-3某官網(wǎng)提供的APP加固風險表目前市面上有很多APP加固平臺，像360、百度、騰訊、網(wǎng)易盾、阿里聚安全等為免費的，像愛加密、梆梆、幾維、頂象科技等為收費的。從事安全的讀者肯定會關注網(wǎng)上各類破解文章，比如圖12-3這個針對360加固的秒脫。圖12-3加固后的對抗其實筆者想說的是，APP加固的目的是提升對手的攻擊成本，如果通過加固能讓相當一部分人知難而退，就達到APP加固本身的效果了。在實際工作中，考慮到APP內部復雜的業(yè)務場景和升級機制，有一些加固方案可能會存在一定的兼容性問題，用戶體驗要求高的場景可能還會追求運行速度，因此需要慎重權衡。一般的思路是在APP上進行各種埋點，結合后端大數(shù)據(jù)風控來降低安全風險。3.反調試調試器檢測，一般是利用android.os.Debug.isDebuggerConnected()這個API來判斷，還有一些其他的思路，比如調用Android中flag屬性ApplicationInfo.FLAG_DEBUGGABLE判斷是否屬于debug模式，循環(huán)檢查android_server調試端口和進程信息，循環(huán)檢查自身status中的TracePid字段值等。此外，還有檢測模擬器，檢測設備是否已經(jīng)ROOT。模擬器檢測技術，一般是取一些模擬器特征，例如通過電話管理器攻取設備IMEI、IMSI，判斷設備配置信息與Android模擬器設備配置默認值是否相同，檢測設備是否有安裝藍牙設備硬件，判斷當前設備WIFIMAC地址，檢測是否具有QEMU虛擬機通道文件等。ROOT檢測一般的思路是，看ROOT后的手機會有哪些特征，比如，檢測su文件是否存在及可以執(zhí)行，檢測是否安裝Superuser.apk等。但實際情況是，Android碎片化非常嚴重，國產(chǎn)手機廠商特別喜歡修改原生ROM，這會導致一些檢測方法失效，需要關注。4.簽名驗證簽名驗證主要是為了防止二次打包，Android簽名驗證一般有三種方法：·Java層驗證，即在Java代碼中實現(xiàn)公鑰信息的比對，比對的樣本可以放在本地或者服務器側。但是Java代碼容易被反編譯，這個校驗邏輯可能被篡改?！DK層驗證，即在Native代碼實現(xiàn)公鑰信息的比對，比對的樣本進行加密存儲。我們知道so通過反匯編生成的ARM代碼，相對smali被篡改的難度更大，再結合so文件加固，可以進一步增強反編譯難度。·服務端驗證，即程序通過特定方法檢測獲取自身代碼校驗值，上送云端服務器進行比較，從而驗證合法性。這樣針對那些非法或偽造、篡改過的客戶端，服務端可以直接拒絕服務，進一步保障安全。12.3.2數(shù)據(jù)安全針對APP，我們通常說的敏感信息包含兩方面：一是用戶敏感信息，比如用戶名、密碼、手機號、郵箱、身份證、銀行卡、住址等；二是APP本身的一些敏感信息，包括產(chǎn)品核心算法、核心業(yè)務邏輯、私鑰、本地存儲的證書、加密算法等。這些敏感信息都需要在設計APP時考慮嚴格保護，在存儲、使用、傳輸過程中也要考慮保護方法。1.數(shù)據(jù)存儲安全Android有外部存儲和內部存儲之分，外部存儲安全隱患比較大，任何軟件只需要在AndroidManifest.xml中聲明如下一行權限就可以在外部存儲設備上讀寫。<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>筆者建議涉及用戶隱私哪怕是已經(jīng)加密過的也不要保存到外部存儲設備上，還有一些APP會動態(tài)加載一些外部資源，這些外部資源可能保存在外部存儲上，建議在加載時驗證文件完整性。在做代碼審計的時候，關注getExternalStorageState、getExternal-StorageDirectory等關鍵函數(shù)就能定位到APP使用外部存儲的代碼邏輯。內部存儲是所有軟件存放私有數(shù)據(jù)的地方，AndroidSDK中提供了openFileInput()與openFileOutput()方法來讀寫程序的私有數(shù)據(jù)目錄。openFileOutput()方法的第二個參數(shù)指定了文件創(chuàng)建模式，如果使用了MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE，就可能導致敏感信息泄露。除了File方式外，Android還提供了SharedPreference、SQLite、ContentProvider方式進行數(shù)據(jù)存儲。與openFileOutput()方法一樣，SharedPreference的getSharedPreferences方法打開文件時第二個參數(shù)如果設置為MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE都存在一樣的問題。相應的對策就是在使用openFileOutput()和getSharedPreferences()打開文件時，將第二個參數(shù)設置為MODE_PRIVATE，這樣就可以利用Linux的文件權限機制來確保數(shù)據(jù)不被其他進程訪問。注意：單單依靠MODE_PRIVATE模式是不夠的，因為可能我們的APP運行在一個已經(jīng)被Root的手機上，或者手機系統(tǒng)出現(xiàn)了一些漏洞導致進程可以提升權限，所以往往敏感數(shù)據(jù)會采取加密措施。敏感數(shù)據(jù)需要保護，基本上都是加密處理，當然有一些場合如日志打印包括logcat不允許出現(xiàn)敏感信息，這是常識，無需多言。AndroidSDK提供了一些API供加密使用，這些API和JAVA提供的基本相似，由JavaCryptographyArchitecture（JCA，Java加密體系結構）、JavaCryptographyExtension（JCE，Java加密擴展包）、JavaSecureSocketsExtension（JSSE，Java安全套接字擴展包）、JavaAuthenticationandAuthenticationService（JAAS，Java鑒別與安全服務）組成。JCA提供基本的加密框架，如證書、數(shù)字簽名、消息摘要和密鑰對產(chǎn)生器等；JCE擴展了JCA，提供了各種加密算法、摘要算法、密鑰管理等功能；JSSE提供了基于SSL（安全套接層）的加密功能，供HTTPS加密傳輸使用；JAAS提供了在Java平臺上進行用戶身份鑒別的功能，除此外，Android還提供了android.security和android.security.keystore來管理keychain和keystore。如果使用SQLite數(shù)據(jù)庫的時候需要加密，可以使用SQLCipher方案。SQLCipher是個獨立的SQLite數(shù)據(jù)庫實現(xiàn)，但它并沒有自己實現(xiàn)一套加密算法，而是使用了OpenSSL的libcrypto庫，兼容性更好。關于加密算法的選擇和使用，業(yè)界有如下安全建議：·base64只是一種編碼方式，并不是加密算法。·生成隨機數(shù)時，不要使用Random類，使用SecureRandom類的時候，不要調用setSeed方法，即不要設置種子?！な褂肏ASH算法時，不要使用MD2、MD4、MD5、SHA-1、RIPEMD算法來加密用戶密碼等敏感信息，因為網(wǎng)上有大量的庫可以用來破解，建議使用SHA-256、SHA-3算法。·使用消息認證算法時，建議使用HMAC-SHA256算法，避免使用CBC-MAC?！な褂脤ΨQ加密算法時，不建議使用DES，建議使用AES算法，同時需要注意加密模式要顯式指定為CBC或CFB模式，不要使用默認的ECB模式。·非對稱算法使用RSA時，建議密鑰長度不低于512，同時注意重放攻擊?！な褂没诳诹畹募用芩惴≒BE時，生成密鑰時要加鹽，鹽的取值最好來自SecureRandom，并指定迭代次數(shù)。關于密鑰保護，直接明文寫在配置里肯定是不行的；硬編碼在Java代碼中通過dex也容易逆向；將密鑰放在so文件里也還是面臨IDA破解。為了保護密鑰，各種千奇百怪的方法都有了，比如將一部分寫到文件中，一部分寫在Java代碼或C層代碼，這只是在一定程度上增加了逆向難度而已。有的利用so將密鑰再進行二次加密保護，那這一層的密鑰保護又是一個問題。針對這些問題，不得不提一下白盒加密技術。白盒加密屬于對稱加密，通過將算法和密鑰緊密捆綁在一起，由算法和密鑰生成一個加密表和一個解密表，然后可以獨立用查找加密表來加密，用解密表來解密，不再依賴于原來的加解密算法和密鑰。正是由于算法和密鑰的合并，所有可以有效隱藏密鑰，與此同時也混淆了加密邏輯。2.數(shù)據(jù)傳輸安全一般客戶端使用HTTPS與服務端進行通信，網(wǎng)站啟用SSLsitewide（useHTTPSonly）或HSTS(HTTPStrictTransportSecurity)，否則存在SSLStrip（HTTPS降級為HTTP）攻擊風險。由于前面在12.2.6節(jié)中講過相關的問題及對策，這里就不再過多重復。對于敏感信息，建議除了HTTPS傳輸加密外，還需要在應用中進行加密保護，多一層保障。12.3.3其他話題1.安全輸入鍵盤智能手機輸入需要依靠虛擬鍵盤，而虛擬鍵盤則由具體使用的輸入法控制。金融行業(yè)APP，密碼往往涉及金錢，為了確保輸入安全，一些企業(yè)會自行開發(fā)安全輸入鍵盤，圖12-4為某行APP的安全鍵盤效果圖。這樣當用戶輸入密碼的時候，處于自行開發(fā)的密碼鍵盤保護之下，確保用戶密碼安全。當然除了密碼，還有其他的輸入數(shù)據(jù)也需要保護，圖12-5是某行APP的安全鍵盤在輸入身份證時的效果圖。注意這上面的鍵盤數(shù)字布局，是隨機的，每次都會變化。什么時候隨機，什么時候不隨機，需要在用戶體驗和安全之間進行權衡。2.防截屏為了防止惡意軟件通過秘密截屏的方式得到一些APP上顯示的信息，就需要對截屏進行處理。Android系統(tǒng)沒有提供對截屏事件監(jiān)聽的接口，也沒有提供對應的廣播，現(xiàn)在主流的思路是，基于截屏中所做的動作針對性地進行檢測，比如，利用FileObserver監(jiān)聽某目錄資源變化，利用ContentObserver監(jiān)聽全部資源變化，利用Activity.onPause()機制等。當發(fā)現(xiàn)有截屏時做一些處理，比如用純黑色圖片對象進行覆蓋處理。圖12-4安全輸入鍵盤例1圖12-5安全輸入鍵盤例2除此之外，Android提供了一個對應的API，直接禁用截屏功能，只需要獲取到相應的Window對象，給其添加一個FLAG_SECURE的flag即可。注意這個FLAG_SECURE是應用在Window對象上的，如果Activity有一些彈窗或突出的UI元素可能不受它保護，需要再單獨設置。3.釣魚APP釣魚APP問題在早些年比較多，隨著惡意APP越來越多，為規(guī)范并促進AndroidAPP安全加固領域的健康發(fā)展，CNCERT牽頭制定了通信行業(yè)標準2015-0217T-YD《移動互聯(lián)網(wǎng)應用程序安全加固能力評估要求與測試方法》，這個標準對提供AndroidAPP加固服務的系統(tǒng)提出了以下要求：·禁止對惡意APP進行加固。·要求對APP加固提交者進行身份驗證。·要求具備對加固前APP進行追查的能力。通過對加固服務提供商進行規(guī)范來防止釣魚APP，是一個不錯的思路。12.4小結本章針對移動應用安全問題從開發(fā)安全、業(yè)務安全的視角進行了討論，希望讀者閱讀完能對移動應用安全有一個基本的認識，對技術細節(jié)感興趣的讀者可能還需要進一步閱讀更專業(yè)的書籍進行提升。第13章企業(yè)內網(wǎng)安全企業(yè)出于不同安全防護等級的考慮，一般都會將內網(wǎng)劃會為辦公網(wǎng)、生產(chǎn)網(wǎng)、測試網(wǎng)、互聯(lián)網(wǎng)、外聯(lián)網(wǎng)等不同的區(qū)域，之間通過防火墻進行隔離。本章會先從基礎的安全域開始討論，然后對終端、網(wǎng)絡、服務器和重點應用進行闡述，最后會針對漏洞、蜜罐這兩個話題單獨展開。13.1安全域網(wǎng)絡安全域是指同一系統(tǒng)內有相同的安全保護需求，相互信任，并具有相同的安全訪問控制和邊界控制策略的子網(wǎng)或網(wǎng)絡，相同的網(wǎng)絡安全域共享一樣的安全策略。廣義的安全域是指具有相同業(yè)務要求和安全要求的IT系統(tǒng)要素的集合。IT系統(tǒng)要素包括網(wǎng)絡區(qū)域、主機和系統(tǒng)、物理環(huán)境、人和組織、策略和流程，因此不能將安全域僅僅理解為網(wǎng)絡安全域。安全域的劃分使整體網(wǎng)絡有了清楚的規(guī)劃，具有以下實際的目標：·使整體網(wǎng)絡結構清晰?！な咕哂邢嗤踩雷o要求的網(wǎng)絡和系統(tǒng)處于同一安全子域中?！げ煌踩佑騼瓤煞奖愕夭渴鸩煌燃壍陌踩雷o策略。·同一安全域內可方便地部署相同等級的安全防護策略。·各區(qū)域防護重點明確，將有效的安全資源投入到最需要保護的資產(chǎn)上。·建立內部互連區(qū)和外部互連區(qū)的邊界接口，統(tǒng)一規(guī)劃網(wǎng)絡層接口，便于新增系統(tǒng)的接入，有利于網(wǎng)絡的有序擴展?！な箶?shù)據(jù)流簡潔規(guī)范，有利于區(qū)分不同種類數(shù)據(jù)流，便于實施安全訪問控制和QoS服務。安全域的理論和方法所遵循的根本原則如下：·業(yè)務保障原則。安全域方法的根本目標是能夠更好地保障網(wǎng)絡上承載的業(yè)務。在保證安全的同時，還要保障業(yè)務的正常運行和運行效率?！そY構簡化原則。安全域方法的直接目的和效果是要將整個網(wǎng)絡變得更加簡單，簡單的網(wǎng)絡結構便于設計防護體系?！さ燃壉Ｗo原則。安全域的劃分要做到每個安全域的信息資產(chǎn)價值相近，具有相同或相近的安全等級、安全環(huán)境、安全策略等。·立體協(xié)防原則。安全域的主要對象是網(wǎng)絡，但是圍繞安全域的防護需要考慮在各個層次上立體防守，包括物理、網(wǎng)絡、系統(tǒng)、應用、數(shù)據(jù)等層次；同時，在部署安全域防護體系的時候，要綜合運用身份鑒別、訪問控制、檢測審計、鏈路冗余、內容檢測等各種安全方法實現(xiàn)協(xié)防?！ど芷谠瓌t。對于安全域的劃分和布防不僅要考慮靜態(tài)環(huán)境，還要考慮不斷發(fā)生的變化；另外，在安全域的建設和調整過程中要考慮工程化管理?！べY源整合原則。在保障安全的前提下安全域的劃分要有利于實現(xiàn)IT資源整合，應充分實現(xiàn)IT資源的共享和復用。安全域的劃分是一個既非?；A又非常重要的工作，企業(yè)按自己的實際情況劃分不同的安全域，同時還需要制定各安全域的安全策略并加以實現(xiàn)。表13-1將辦公網(wǎng)和業(yè)務網(wǎng)進行了梳理，其他安全域也可以參照并建立類似的安全策略表。表13-1辦公網(wǎng)和業(yè)務網(wǎng)的安全策略表對不同安全域間的訪問，通過部署各類安全解決方案，實現(xiàn)阻斷、檢測和過濾等功能，為上層安全防護功能的實現(xiàn)提供保障。13.2終端安全內網(wǎng)終端是我們日常工作接觸最多的設備，也是企業(yè)內網(wǎng)安全防護需要重點關注的戰(zhàn)場之一。終端用什么樣的操作系統(tǒng)，允許安裝什么樣的軟件，系統(tǒng)和軟件補丁怎么打，用戶的權限是管理員還是普通用戶，必須滿足什么條件才允許接入內網(wǎng)，滿足什么條件才允許訪問互聯(lián)網(wǎng)，惡意軟件查殺，各種外設管控等等，都是終端安全領域不可回避的話題，也有很多基礎的工作要做。有些企業(yè)采用各種封堵的技術方案來控制，比如，終端電腦不允許上外網(wǎng)、不允許使用U盤、外發(fā)郵件需要審批等；還有的企業(yè)考慮到人力成本，往往將一些基礎工作外包出去，普通用戶沒有管理員權限，需要安裝軟件時會有專門的人提供支持。我們不去評判其好壞優(yōu)劣，畢竟鞋子合不合腳只有自己才知道。終端安全涉及資產(chǎn)管理、補丁管理、終端準入、防病毒、外設管控、上網(wǎng)行為管理等諸多內容，每一個話題又是一個細分的領域。對企業(yè)敏感數(shù)據(jù)保護有要求的企業(yè)，往往在終端上還會部署一些文檔加密、DLP類的程序。終端標準化做得不好的企業(yè)，可能終端上的環(huán)境非常復雜，尤其是安全軟件相互“打架”產(chǎn)生的兼容性問題。為了不陷入其中，我們以攻擊者的視角，來看終端安全需要關注的技術點。注意這里有一個假設的前提：終端資產(chǎn)的重要性（包括擁有的數(shù)據(jù)價值）遠不如后臺服務器，所以攻擊者往往都會以終端為跳板進行深入。我們以圖13-1所示的終端安全為例進行分析。圖13-1終端安全威脅終端在辦公網(wǎng)前臺區(qū)域，存在的風險主要包括以下幾個場景：場景一終端用戶私接U盤，U盤所帶的木馬病毒在辦公網(wǎng)中傳播，進一步感染辦公網(wǎng)后臺重要服務器。場景二終端用戶通過3G上網(wǎng)卡或隨身WiFi設備私接互聯(lián)網(wǎng)，無意感染病毒被黑客遠程控制，黑客以此為跳板進一步侵入企業(yè)內部。場景三終端用戶通過上網(wǎng)防火墻訪問互聯(lián)網(wǎng)，無意感染病毒被黑客遠程控制，黑客以此為跳板進一步侵入企業(yè)內部。針對場景一，我們的對策是：操作系統(tǒng)基線配置，不允許應用程序直接從U盤、光盤自動啟動，結合防病毒軟件進行查殺。針對場景二，我們的對策是：結合終端外設管理封禁無線、藍牙等功能，防止非法外連，同時在終端上部署外連探測程序，檢測網(wǎng)絡連通性以發(fā)現(xiàn)非法外連的可疑行為。針對場景三，我們的對策略是：上網(wǎng)通過沙盒虛擬桌面上網(wǎng)，結合上網(wǎng)行為、下一代防火墻對惡意域名、地址及惡意文件進行攔截。當然，用戶訪問的惡意URL可能來自于郵件系統(tǒng)，可以在郵件系統(tǒng)中提前干預，不讓這類URL來到終端。如果那個假設前提不成立，即終端上有比較重要的數(shù)據(jù)，除了上面提到的對策使之進不來、帶不走之外，最好還要對數(shù)據(jù)進行脫敏、加密處理，對敏感數(shù)據(jù)的外發(fā)進行攔截等，這樣，即使終端被控制了，重要數(shù)據(jù)也能得到保護。關于數(shù)據(jù)安全這個話題，我們將在第14章進行闡述。在企業(yè)中，有一些特殊終端電腦需要關注，往往其使用者身份較高，安全執(zhí)行不到位或者執(zhí)行困難的企業(yè)，往往對這類人采取比較寬松的管理方案，比如可以直接上網(wǎng)，不受限制等。而恰恰是這類終端電腦，其上面的資料可能比普通員工的重要很多，所以需要重點關注。為其設置特殊的網(wǎng)段使之與其他終端隔離，在該網(wǎng)段部署蜜罐，對進出該網(wǎng)段的流量進行重點監(jiān)控，對此類人員的入站郵件內容進行更多層的分析，同時在SOC里將此類資產(chǎn)重點標記，機器上所產(chǎn)生的安全事件風險等級提升一個級別，這些都是應對之策?，F(xiàn)在，針對終端安全有些廠商整合了各種功能，信譽庫、云查殺、情報、EDR等等，往往意味著終端要使用這些功能，還得在網(wǎng)絡上部署沙箱、內部情報庫等，企業(yè)在選擇的時候需要結合自己的實際情況考慮。13.3網(wǎng)絡安全網(wǎng)絡安全涉及面非常廣，有一些基礎的安全加固配置，比如交換機上啟用port-security、BPDU-Guard等防護機制，對未使用的接口默認全shutdown，使用AAA認證技術，防火墻上開啟默認anyanydrop策略等；也有一些專門的技術或解決方案，如NGFW、NIDS等。企業(yè)在劃分了安全域后，不同域之間需要通過VLAN、ACL、防火墻等技術進行隔離。而安全域控制僅能依照安全策略進行部署實施，但是即使符合安全策略的網(wǎng)絡訪問，仍可能存在惡意的網(wǎng)絡訪問行為。同時，安全策略在不斷運營調整過程中，也可能存在失效的情況，如何及時發(fā)現(xiàn)這種隔離失效也是一個問題。因此，針對上面這兩種情況，我們應能具備一定的檢測甚至阻斷的能力。常規(guī)思路是在實施網(wǎng)絡隔離（VLAN、NACL、防火墻等）外，還需要對其進行流量分析（基于特征的NIDS、基于黑白名單及模型的異常訪問檢測系統(tǒng)等），以便發(fā)現(xiàn)異常。除了被動檢測外，還可以主動掃描，以發(fā)現(xiàn)ACL失效的情況。另外，在網(wǎng)絡中適當?shù)夭渴鹈酃?，也能發(fā)現(xiàn)一些惡意行為，甚至包括同