Code Review Engine Learning

相關學習資料

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