相關學習資料
https://www.owasp.org/index.php/Code_review https://www.owasp.org/images/8/8e/OWASP_Code_Review_Guide-V1_1.doc http://cwe.mitre.org/about/index.html
目錄
1. INTRODUCTION: 程式碼審計介紹 2. PREPARATION: 程式碼審計需要的準備 3. SECURITY CODE REVIEW IN THE SDLC: 系統生命週期中的程式碼安全審計 4. SECURITY CODE REVIEW COVERAGE: 程式碼安全審計範圍 5. CODE REVIEW METRICS: 程式碼審計指標 6. CRAWLING CODE: 漏洞挖掘技巧
1. INTRODUCTION: 程式碼審計介紹
我們知道，在Risk Threat Modeling(風險模型)中，攻擊者通過開原始碼或者逆向工程獲得目標系統的原始碼，從而發現系統潛在的漏洞利用方式是一個高危且常見的風險點，尤其在一些CMS的WEB漏洞中極為常見。因此，在整個IT系統的開發和維護週期中進行code review(程式碼審計)就成了一個重要且有意義的工作。
程式碼審計或許是一個最有效的發現安全漏洞的技術了。當配合上自動化的工具以及手工的滲透測試的時候，程式碼審計能顯著提高一個應用系統的安全測評工作的成本不能效益。
手工的程式碼安全審計工作能使我們探尋到那些真正的漏洞風險，安全人員在進行程式碼審計的時候，可以切實的瞭解到目標系統的上下文環境，並根據漏洞情況評估被攻擊的可能性(發現難度、可重現性、依賴條件)、以及攻擊一旦發生對商業帶來的破壞影響。
0x1: 為什麼程式碼存在漏洞
MITRE在它的CWE(Commom Weakness Enumeration)專案中對700多種不同的軟體漏洞進行了分類
http://cwe.mitre.org/about/index.html
從程式設計開發的角度來說，有非常多的方式會導致不安全的漏洞發生，其中有些是風險性很好的Bug型別的漏洞，而有些則是具有很大危害性的致命性漏洞。
而對於大多數開發者來說，它們當中很多人在學校、或者工作中並沒有接收過關於安全方面的培訓(當然這個情況正在快速改善)。
隨著資訊化的極速發展，越來越多的新業務、新技術、新系統被開發出來，它們具備越來越多的功能，並且互聯程度、依賴耦合也越來越高，但是，相應的安全技術以及針對這些新技術、新系統的安全審計工作卻沒有跟上步伐。
造成這一現象的原因有很多，而其中最重要的一點就是軟體的高度封裝性，即只向使用者呈現一個提供功能的黑盒子。從使用者的角度來說，使用者很難從外表對這個軟體的安全性做出準確判斷。顯性安全的問題直接導致了軟體開發商不願意投入過多的資金到安全審計中去，但這一情況在近幾年正在得到不斷改善，最大的變化就是:
1) 像烏雲、XSRC這樣的漏洞披露平臺的出現，讓更多的使用者瞭解到了安全漏洞的危害，同時也吸引了更多的安全工作著進入這個領域 2) 媒體對安全事件的危機宣傳提高了公民的安全意識 3) 不論是普通使用者、還是軟體開發團隊，對安全開發流程SDL的重視程度都越來越高
0x2: 什麼是程式碼安全審計
程式碼審計就是通過閱讀審計目標系統的原始碼，檢驗是否在關鍵的邏輯流位置設定了正確的安全控制。
程式碼審計的目的是保證開發人員遵循了安全的開發技術。一般來說，對目標系統進行了一次完整的程式碼安全審計之後，模擬滲透測試就不應該發現任何額外的應用程式程式碼漏洞。
安全研究員往往採用手工(直接閱讀原始碼)和自動化技術(靜態、動態程式碼分析工具)進行程式碼安全審計，誠然，自動化的工具能夠節省大量的時間，可以在短時間內掃描大量的原始碼，並按照設定的策略指出"可能"存在風險的程式碼位置。但是自動化工具不能理解上下文語境關係(程式碼層的漏洞和上下文的語境關係很密切)，在工具掃描結束之後，需要安全人員逐一確認工具指出的漏洞風險點，如果某個風險點經過驗證是真實漏洞，安全人員還需要評估這個風險的風險係數。
2. PREPARATION: 程式碼審計需要的準備
0x1: LAYING THE GROUND WORK: 基礎鋪墊工作
作為程式碼審計團隊人員，除了技術性的漏洞之外，應該更多地去關注應用系統的商業目的和主要的商業風險，這能幫助審計人員在識別不同的漏洞代理、它們的動機(攻擊者的動機)、漏洞爆發可能(發現率)時能更好的做出判斷，並做出正確的優先順序排序，優先解決高技術風險、高商業風險的漏洞。
作為風險模型中的一個重要的環節，程式碼安全審計的結果可以被彙編起來，成為風險模型的一環，詳細的展示出當前應用系統的細節安全問題。而我們知道，風險模型是一個迭代改進的過程，程式碼審計的最終目的也在如果，通過不斷地確保目前的最高危漏洞已經得到正確的控制、修復，讓應用系統以螺旋上升的方式不斷得到改進。
在SDL的範疇中，程式碼安全審計人員應該在應用系統的架構設計階段就參與到開發團隊中。對於程式碼安全審計人員來說，要將自己當成是一個建議者，和開發人員一起去改進程式碼，完善系統，而不要本著一個警察的態度去糾錯，那麼會適得其反。
0x2: BEFORE WE START: 程式碼審計需要的基礎知識
作為程式碼審計人員，需要熟悉以下內容
1. Code: 程式碼 審計人員需要熟悉目標系統所使用的開發語言、這個語言的特性、以及這個語言本身存在的漏洞。從安全的角度來看，不同的語言(例如PHP、ASP、Java)本身的一些特性和漏洞往往也會反映在代
碼漏洞上(雖然程式碼漏洞大多數時候是程式沒有遵循安全編碼規範導致的邏輯漏洞) 2. Context: 環境背景 在進行程式碼審計之前，瞭解目標應用系統的環境背景十分重要，我們需要了解: 1) 我們正在操作什麼型別的資料，即系統的輸入、輸出問題。我們知道，很很多漏洞和資料流的流動以及安全處理有關，所以，瞭解目標應用系統的資料流結構很重要 2) 當發生資料洩漏時對公司的損失有多大 3. Audience: 目標使用者 瞭解當前審計的應用系統的目標使用者是誰: 1) 相對可信任的企業內網使用者 2) 面向公網的普通使用者 3) 外部系統、外部服務 4. Importance: 穩定性 可用性對應用系統來說也是十分重要的，安全審計人員需要了解如果目標系統突然重啟、停機會對企業造成多大的危害。我們知道，不管是"雲機房建設標準"中對機房的伺服器每年允許的"停止服
務時間"作出最大上限的規定，還是"SLA(Service Level Aggrement)"中對使用者承諾的服務質量，應用系統保持穩定執行，並不受DDOS攻擊的影響都是十分重要的
0x3: DISCOVERY: GATHERING THE INFORMATION: 資訊收集
在開始審計攻擊之前，對目前資訊系統進行一些必要的資訊收集對審計工作的有效開展十分有意義，一般來說，資訊收集的手段有:
1) 檢視專案的設計文件 2) 和專案開發人員、首席架構師進行交談，瞭解應用系統的架構資訊 3) 親身體驗一下系統的UI、功能，獲取一個直觀的認識 4) 瞭解目標系統的程式碼結構、所使用的開源庫等等
0x4: CONTEXT, CONTEXT, CONTEXT: 明確你的目的
作為安全研究員，我們要明白安全程式碼審計並不僅僅是在使用工具或者人工對原始碼進行審計(閱讀)。程式碼審計的目的是保證程式碼對應用系統的機密資訊和企業財產進行了合理的保護。
對於一個應用系統來說，可能會存在很多的實際漏洞(可被攻擊)、和潛在的漏洞風險。
1) 對於實際存在的漏洞，毫無疑問是應該立即採取措施進行修補 2) 而對於潛在的漏洞風險，則應該根據企業自身的環境、商業目標來對風險進行評估，優先將資源、時間投入到那些相對高風險的漏洞修補中，以實現效益最大化
伴隨著程式碼安全審計的開展，一個高層次的風險威脅模型應該被建立，它包括
1) Threat Agents: 威脅代理 2) Attack Surface: 受攻擊面，即黑客可以從哪些角度對系統進行攻擊 2.1) public interfaces 2.2) backend interfaces 3) Possible Attacks: 可能的攻擊方式 4) Required Security Controls: 需要採取的安全控制機制 4.1) stop likely attacks: 組織可能發生的攻擊 4.2) meet corporate policy: 滿足企業、國家標準對系統安全的准入準則 5) Potential Technical Impacts: 發生攻擊後對企業產生的潛在的技術影響 6) Important Business Impacts: 發生攻擊後對企業產生的潛在的商業影響
在進行上下文環境資訊收集的時候，安全人員可以簡單地詢問開發團隊以下問題
1. 資訊系統包含了什麼型別的資料/資產 2. 敏感資料是怎麼進入資訊系統並被儲存的 3. 資訊系統是對內使用的還是對外使用的，使用者的可信度有多高 4. 資訊系統被部署的主機處於企業網路架構中的什麼位置 處於安全考慮，對於未經驗證的使用者不允許通過DMZ區域(往往是WEB服務區)進而訪問到LAN區域(後端資料庫)。即使是對於內部使用者，也需要通過驗證，沒有驗證也就意味著不可問責，導致失去
追溯審計能力。
0x5: THE CHECKLIST: 檢查清單
檢查清單(check list)規定的是程式碼審計團隊的審計目標，檢查清單的完善性、以及是否覆蓋了當前系統中的主要安全漏洞對應用系統的SDL安全開發具有重要意義。
1. Data Validation 2. Authentication(認證) 3. Session management 4. Authorization(授權) 5. Cryptography 6. Error handling 7. Logging 8. Security Configuration 9. Network Architecture
3. SECURITY CODE REVIEW IN THE SDLC: 系統生命週期中的程式碼安全審計
雖然對於程式碼安全審計這項工作而言，並沒有一個硬性的強制性標準規定審計過程需要的規範程度，但Karl Wiegers還是列出了一些列程式碼安全審計需要遵循的最基本步驟:
1. Ad hoc review 2. Passaround 3. Pair programming 4. Walkthrough 5. Team review 6. Inspection
SDLC的核心意義在於強調程式碼安全審計應該貫穿在整個專案開發過程中，在完成一個功能點後立刻進行安全方面的迴歸測試，這樣無論是從成本效益還是有效性方面都更加得體。
我們要明白的是，程式碼安全審計是一個整體的生命週期，包括開發者迴歸測試、以及後期審計(例如CMS漏洞挖掘)，它是縱深防禦中的重要一環。
SDLC的瀑布模型(Waterfall SDLC)
1. Requirements definition: 需求分析 1.1 Application Security Requirements: 應用系統安全需求分析 2. Architecture and Design: 架構設計 2.1 Application Security Architecture: 系統安全架構 2.2 Threat Model: 風險模型 3. Development: 開發 3.1 Secure Coding Practices: 程式碼開發最佳安全實踐 3.2 Security Testing: 安全測試 3.3 Security Code Review: 程式碼安全審計 4. Test: 測試 4.1 Penetration Testing: 滲透測試 5. Deployment: 部署 5.1 Secure Configuration Management: 安全配置 5.2 Secure Deployment: 安全部署 6. Maintenance: 後期維護
敏捷開發模型(Agile Security Methodology)
1. Planning 1.1 Identify Security Stakeholder Stories 1.2 Identify Security Controls 1.3 Identify Security Test Cases 2. Sprints 2.1 Secure Coding 2.2 Security Test Cases 2.3 Peer Review with Security 3. Deployment 3.1 Security Verification (with Penetration Testing and Security Code Review)
4. SECURITY CODE REVIEW COVERAGE: 程式碼安全審計範圍
0x1: UNDERSTANDING THE ATTACK SURFACE: 理解受攻擊面
程式碼安全審計的一個重要的一部分是進行"受攻擊面分析"。從本質上來理解應用系統，它就是一個接收指定引數，並根據不同的業務場景產生對飲的格式化輸出的系統，而攻擊者要做的就是針對應用系統的所有輸入點進行測試，找到存在處理漏洞的輸入點，例如:
1. Browser input: 瀏覽器輸入 2. Cookies: HTTP Cookie輸入 3. Property files: 屬性檔案 4. External processes: 外部程式傳輸的資料 5. Data feeds: 資料反饋 6. Service responses: 服務返回資料包(例如REST) 7. Flat files: 檔案IO 8. Command line parameters: 命令列引數 9. Environment variables: 環境變數(例如環境變數PATH劫持攻擊)
對"受攻擊面"的程式碼漏洞分析包括:
1. 動態資料流分析 2. 靜態資料流分析
具體包括以下應該思考的問題:
1. 資料從哪裡來 2. 變數被怎麼賦值 3. 變數在整個工作流中被如何使用 4. 變數到哪裡去 5. 物件屬性是怎樣影響到程式中的其他資料的
這些分析保證了程式中的引數、方法呼叫、資料交換都被進行了正確的安全控制。
0x2: UNDERSTAND WHAT YOU ARE REVIEWING: 理解你的審計物件
在進行程式碼安全審計的時候，全面地理解我們的目標系統的程式碼結構(即審計物件)是十分重要的，因為現代的應用系統開發中大量使用到了框架(framework)，例如ASP.NET Framework、Java SSH(struts+spring+hibernate)、PHP中的CMS整合框架等。在大量使用框架的背景下，應用系統中出現的函式呼叫、物件操作就和我們傳統認識的形式會大不一樣，取而代之的是一些框架API的呼叫，如果我們使用靜態、或者動態的掃描器對應用系統進行掃描，自然不會掃描出任何漏洞。
因此，我們必須充分了解、並識別目標應用系統所採用的開發框架，這樣，才能做到深度業務邏輯掃描。
Java:
在struts程式中，struts-config.xml 以及web.xml這兩個檔案是獲取整個應用系統函式結構的關鍵核心
struts-config.xml: 它包含了系統的所有HTTP訪問的URL對映關係
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd"> <struts-config> <form-beans> <form-bean name="login" type="test.struts.LoginForm" /> </form-beans> <global-forwards> </global-forwards> <action-mappings> <action path="/login" type="test.struts.LoginAction" > <forward name="valid" path="/jsp/MainMenu.jsp" /> <forward name="invalid" path="/jsp/LoginView.jsp" /> </action> </action-mappings> <plug-in className="org.apache.struts.validator.ValidatorPlugIn"> <set-property property="pathnames" value="/test/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/> </plug-in> </struts-config>
在structs framework框架中提供了一個"基於正規表示式的驗證引擎(validator engine)"，使用這種機制，程式設計師不需要在程式碼中編寫任何和表單驗證有關的程式碼，struct會自動幫我們完成。
在這種情況下，如果沒有對structs的一個先驗知識，而只是簡單的對java程式碼進行審計，會認為目標應用系統沒有采用任何規則和控制函式進行輸入驗證，從而造成誤報。
.NET:
ASP.NET/IIS應用程式使用web.config(XML檔案)來維護程式的配置資訊，包括:
1. 身份認證 2. 授權 3. 錯誤處理、錯誤頁面 4. HTTP設定 5. debug除錯設定 6. WEB服務設定 ..
web.config
<authentication mode="Forms"> <forms name="name" loginUrl="url" protection="Encryption" timeout="30" path="/" requireSSL="true|" slidingExpiration="false"> <credentials passwordFormat="Clear"> <user name="username" password="password"/> </credentials> </forms> <passport redirectUrl="internal"/> </authentication>
回顧這兩個例子的意義在於，程式碼安全審計人員需要認識到，這些基於框架開發的程式，將安全控制放在了配置檔案中，而不是硬編碼在程式碼中，在進行審計工作和審計工具的編寫的時候需要充分認識到這一點，對目標系統架構的理解越深刻，才能更好地進行深層次的程式碼審計。
5. CODE REVIEW METRICS: 程式碼審計指標
對於程式碼安全審計工作來說，意識到可以使用一些評測指標來對目標進行全面的客觀評估而不是僅僅依靠"挖出了多少漏洞"是很重要的。
SECURE DEVELOPMENT METRICS: 安全開發過程中的程式碼審計的評測指標
0x1: DEFECT DENSITY: 缺陷密度
所謂缺陷密度，簡單來說就是系統中平均每行程式碼的程式設計錯誤的比例，這能從一定程度上側面反映出目標系統的程式碼安全度
0x2: LINES OF CODE(LOC): 程式碼行數
一般來說，系統的程式碼量越多，產生漏洞的可能性就越大。
0x3: FUNCTION POINT: 函式功能點
統計系統中有多少函式宣告
0x4: RISK DENSITY: 漏洞密度
通過這個指標: [X Risk / LoC] 或 [Y Risk / Function Point] (X/Y Risk代表發現的漏洞數量)
0x5: 路徑複雜度
Thomas McCabe在20世紀70年代建立了路徑複雜度理論，這很容易理解: CC = Number of decisions +1 這裡的"decisions"可以簡單地理解為 If....else, Switch, Case, Catch, While, do, and so on..... 隨著條件判斷語句的增加，路徑複雜度也相應增加，而我們知道，很多時候，漏洞的產生就是因為鑽了複雜業務路徑的空子，過高的路徑複雜度削弱了系統的穩定性、可維護性、和安全性控制性 1. 0-10: Stable code. Acceptable complexity 2. 11-15: Medium Risk. More complex 3. 16-20: High Risk code. Too many decisions for a unit of code.
REVIEW PROCESS METRICS: 後期程式碼安全審計中的評測指標
0x1: CODE COVERAGE: 程式碼覆蓋率
程式碼覆蓋率指的對程式碼行數、函式功能點的檢查覆蓋率。對於手工審計來說，目標是100%，而對於自動化工具來說，一般是80-90%(因為對目標系統的理解程度的原因，自動化工具往往覆蓋到程式碼的每個路徑)
0x2: DEFECT CORRECTION RATE: 缺陷修復率
這個指標評估平均每個漏洞需要的修復時間、以及有多少已發現的漏洞已經被成功修復。
0x3: RE-INSPECTION DEFECT RATE: 漏洞重複發現率
這個評測指標往往針對這種情況，在發現了某個漏洞之後，只是針對當前的應用場景進行了修復，但沒有去總結當前系統中是否還有這一類漏洞，導致在另一個模組中又發現同一類漏洞，這在程式碼審計和安全開發中是應該極力避免的。
為了解決這個問題，一個好的做法是將這一類漏洞的原因抽象出來，封裝成一個統一的、高層的防禦策略模組，並對所有潛在存在這一問題的程式碼位置部署這個安全模組。
6. CRAWLING CODE: 漏洞挖掘技巧
我們知道，漏洞的挖掘過程就是一個"受攻擊面識別以及利用的過程"，而對應應用程式來說，受攻擊面就是使用者可以控制的部分，即接收資料的介面，包括:
1. 特定API呼叫 2. 檔案IO 3. 使用者配置、使用者管理介面
從本質上來說，漏洞的發生可能是因為使用了某些本身就不安全的API、函式(語言本身的漏洞)、或者是使用這些API或者組合的方式不對導致的。
安全人員在進行漏洞挖掘的時候，第一步常常是使用搜尋工具進行關鍵識別符號的搜尋並定位上下文。
0x1: .NET程式碼審計
對於.NET程式的程式碼審計，我們主要關注以下幾個方面
1. HTTP REQUEST STRINGS
從外部資料來源獲取使用者輸入絕對是程式碼安全審計的重點關注區域。對於使用者輸入，我們需要關注以下幾點:
1) 組成經過驗證 驗證輸入中是否為"規範"的資料，防止出現SQL隱碼攻擊、緩衝區溢位等攻擊payload 2) 輸入長度 使用者輸入的資料必須在一個[min,max]範圍內 3) 輸入引數型別 使用引數化防禦思路，保證使用者輸入的引數只在規定的白名單範圍中。
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
request.accepttypes
request.browser
request.files
request.headers
request.httpmethod
request.item
request.querystring
request.form
request.cookies
request.certificate
request.rawurl
request.servervariables
request.url
request.urlreferrer
request.useragent
request.userlanguages
request.IsSecureConnection
request.TotalBytes
request.BinaryRead
InputStream
HiddenField.Value
TextBox.Text
recordSet
2. HTML OUTPUT
對於HTML OUTPUT，我們關注的重點是系統向使用者返回的資料，大多數情況下，針對客戶端的攻擊都是由於沒有進行有效的輸出驗證導致的，例如XSS攻擊
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
response.write <% = HttpUtility HtmlEncode UrlEncode innerText innerHTML
3. SQL & DATABASE
對於SQL隱碼攻擊漏洞的識別和發現涉及到和資料庫操作相關的API，作為程式碼安全審計人員需要維護一份完整的SQL Database Relative API來對目標應用中的資料庫操作進行準確定位。
而相對的，要檢測應用系統是否針對SQL隱碼攻擊進行了必要的防禦，需要判斷在相應的資料流動路徑中是否採用了對應的引數化防禦函式
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
exec sp_executesql execute sp_executesql update delete from where delete exec sp_ execute sp_ exec xp_ execute sp_ exec @ execute @ executestatement executeSQL setfilter executeQuery GetQueryResultInXML adodb sqloledb sql server select from Insert driver Server.CreateObject .Provider .Open ADODB.recordset New OleDbConnection ExecuteReader DataSource SqlCommand Microsoft.Jet SqlDataReader ExecuteReader GetString SqlDataAdapter CommandType StoredProcedure System.Data.sql
4. COOKIES
Cookie汙染是導致系統漏洞的一大因素，例如session hijacking、session fixation、引數汙染(HPP攻擊)。
需要明白的是，COOKIE的安全問題同時會影響到SESSION的安全問題
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
System.Net.Cookie
HTTPOnly
document.cookie
5. HTML TAGS
對HTML標籤的關注主要是為了防禦針對客戶端的攻擊，例如XSS。
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
HtmlEncode URLEncode <applet> <frameset> <img> <style> <layer> <ilayer> <meta> <embed> <frame> <html> <iframe> <object> <body> <frame security <iframe security
6. INPUT CONTROLS
在.NET程式中，有很多服務端類庫負責生成接收使用者輸入的表單，對這些關鍵類進行定位和安全分析能夠評測應用系統接收資料的安全性
system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.hiddenfield
system.web.ui.webcontrols.hyperlink
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.label
system.web.ui.webcontrols.linkbutton
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist
7. WEB.CONFIG
對於.NET這類基於框架開發的程式來說，依靠.config檔案來管理應用程式的配置設定，主要包括:
requestEncoding
responseEncoding
trace
authorization
compilation
CustomErrors
httpCookies
httpHandlers
httpRuntime
sessionState
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
appSettings
connectionStrings
authentication mode
allow
deny
credentials
identity impersonate
timeout
remote
8. LOGGING
日誌模組的設計缺陷可能導致應用系統資料洩漏的發生。一個最常見的漏洞是系統對使用者的登入請求進行了日誌記錄(在日誌中包含明文的帳號、密碼)、或者對資料庫的操作進行的日誌記錄(資料庫帳號、密碼、使用者隱私資料直接明文記錄)。這些都屬於嚴重的安全漏洞。
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace
9. REFLECTION, SERIALIZATION
我們知道，除了靜態的編寫程式碼並編譯執行外，程式中還存在動態的代數輸入，即具體執行的程式碼在執行時中動態決定。我更傾向於把它歸類於程式碼注入，因為動態的程式碼注入，使原本的程式碼邏輯發生了更大的改變，同時也引入了安全漏洞，例如序列化、反序列化漏洞
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection
10. EXCEPTIONS & ERRORS
程式碼安全開發和程式碼安全審計的過程中需要確保程式進行了正確的"錯誤處理"，即:
1. 合理使用了try-catch塊保證隱私資訊不被洩漏
2. 合理使用finnally塊保證資源被正確釋放
3. 使用自定義錯誤頁面，即錯誤代理處理模式對錯誤資訊進行逐層封裝，保證底層的錯誤不被洩漏到表層UI
對於這些要求，我們在進行手工搜尋審計或者自動化工具搜尋的時候需要重點關注以下物件
catch{
Finally
trace enabled
customErrors mode
11. CRYPTO
如果目標系統包含"加密處理模組"，則作為安全審計人員需要重點關注以下幾個方面
1. 加密演算法是否強度足夠高
1) AES
2) 3DES
2. 金鑰長度是否足夠長
3. HASH演算法的強度
1) MD5
2) SHA1
4. 是否保證HASH不可逆儲存
5. 隨機演算法、隨機種子的安全性
1) PRNG
0x2: JAVASCRIPT / WEB 2.0程式碼審計
javascript和Ajax技術將函式功能的控制權帶到了客戶端，這在帶來WEB2.0的新特性的同時也引入了新的安全問題。
安全人員在審計程式碼的時候，需要額外關注這些將被返回到客戶端瀏覽器的.js檔案、或者javascript程式碼。
eval(
document.cookie
document.referrer
document.attachEvent
document.body
document.body.innerHtml
document.body.innerText
document.close
document.create
document.createElement
document.execCommand
document.forms[0].action
document.location
document.open
document.URL
document.URLUnencoded
document.write
document.writeln
location.hash
location.href
location.search
window.alert
window.attachEvent
window.createRequest
window.execScript
window.location
window.open
window.navigate
window.setInterval
window.setTimeout
XMLHTTP
Copyright (c) 2014 LittleHann All rights reserved