應用開發(fā)安全指南

應用開發(fā)安全指南 1 概述概述 本指南的編制是在 CTG MBOSS IT 總體規(guī)范 V1 0 的總體框架體系指導下 參考了 中國電信CTG MBOSS IT 安全規(guī)范 V1 0 及近年來發(fā)布的其他安全政策和指導意見相 關內容 繼承和吸收了原有安全管理實踐的經驗成果 并充分考慮了各省電信公司的現(xiàn)狀 和行業(yè)最佳實踐與安全新技術的引入 本指南是IT 安全保障體系建設規(guī)范的一個組成部分 全面闡述了IT 系統(tǒng)應用開發(fā)整個軟件生命周期所必須遵照的設計 編碼 測試方面的安全 要求 闡述了不同開發(fā)環(huán)境和編碼語言條件下安全開發(fā)的相關規(guī)范要求 1 1 目的 本指南針對中國電信IT 應用系統(tǒng)應當遵循的應用開發(fā)安全標準進行了規(guī)范性說明 旨在指 導應用系統(tǒng)設計人員 代碼開發(fā)人員和安全檢查管理人員進行應用安全開發(fā)的安全配置 以提高應用系統(tǒng)的安全防護能力 1 2 適用范圍 本指南適用于中國電信IT 系統(tǒng)代碼開發(fā)項目 作為中國電信集團公司 各省公司在IT 系 統(tǒng)開發(fā) 設計環(huán)節(jié)中所遵照執(zhí)行的依據(jù) 1 3 適用對象 本配置指南的適用人員包括 中國電信IT 系統(tǒng)應用開發(fā)人員及安全檢查管理人員 1 4 規(guī)范文檔 應用開發(fā)安全指南 在中國電信集團公司IT 安全保障體系建設規(guī)范中 的位置如下圖所示 策略 規(guī)范 指南 管理分冊技術分冊 中國電信IT安全保障 體系建設規(guī)范 要求 規(guī)范 指南 規(guī)范總冊 2 應用系統(tǒng)設計安全應用系統(tǒng)設計安全 2 1 應用系統(tǒng)架構安全設計要求 在應用系統(tǒng)設計階段 應充分考慮該架構的安全性 包括B S C S 等形式的安全 主要體 現(xiàn)在應用數(shù)據(jù)和用戶會話的安全 還應當考慮應用系統(tǒng)自身體系架構內部的安全 以及與 外系統(tǒng)接口的安全 針對某些特殊應用 還需考慮恢復 抗攻擊等安全機制 2 1 1 應用系統(tǒng)自身架構安全 1 自身結構中各組件之間通訊過程的安全機制 組件之間的通訊包括命令級的和數(shù)據(jù)級的 應充分考慮 傳輸命令和數(shù)據(jù)所采用的協(xié)議的安全性 應根據(jù)組件之間通訊內容安全性要求程度的 不同選擇不同安全性要求的協(xié)議 考慮程序的模塊之間的安全通訊機制 不應使用標準的服務端口或者常見病毒 蠕蟲等使用的服務端口 2 認證與訪問控制機制 應考慮 組件之間的信任機制 用戶的身份認證機制 對于組件資源的訪問控制機制 3 組件內重要文件和數(shù)據(jù)的安全防護機制 存在于組件內部的重要數(shù)據(jù)資源應當考慮其相應的安全防護機制 這些重要的數(shù)據(jù)資 源包括 配置文件 用戶數(shù)據(jù) 包括文件數(shù)據(jù)及數(shù)據(jù)庫中的數(shù)據(jù) 臨時文件和數(shù)據(jù) 與外系統(tǒng)或者系統(tǒng)內部其他組件接口用的數(shù)據(jù)文件 對這些重要數(shù)據(jù)的存取安全性設計 包括 文件和數(shù)據(jù)存放是否加密及采用的加密方式 2 1 2 應用系統(tǒng)與外系統(tǒng)接口的安全 應用系統(tǒng)與外系統(tǒng)的接口安全設計 主要應考慮以下幾個要素 1 與外系統(tǒng)的之間通訊中的安全機制 應充分考慮 傳輸命令和數(shù)據(jù)所采用的協(xié)議的安全性 應根據(jù)系統(tǒng)之間通訊內容安全性要求程度的不 同選擇不同安全性要求的協(xié)議 建議不使用默認的服務端口或者常見病毒 蠕蟲等使用的服務端口 2 與外系統(tǒng)的認證與訪問控制機制 應考慮 系統(tǒng)之間的信任機制 對于系統(tǒng)之間資源的訪問控制機制 3 對外系統(tǒng)安全機制的符合性 應考慮 如果外系統(tǒng)采用的接口方式經評估認為是安全的 本系統(tǒng)應當沿用其接口規(guī)范進行設 計開發(fā) 如果外系統(tǒng)采用的接口方式經評估認為存在安全缺陷 應商定采用更加安全的接口方 式 在考慮接口安全性的同時 也應當注意接口方式對雙方系統(tǒng)性能 磁盤 連接數(shù)等各 種性能指標和資源的影響 2 1 3 應用系統(tǒng)其他的安全機制 除了上述基本的安全架構設計內容外 針對不同的應用 以及應用系統(tǒng)的重要程度 可以 補充考慮以下幾種安全機制 1 針對Web應用的頁面保護與恢復機制 利用專用的安全產品 或者系統(tǒng)自身設計時就 考慮到了對于Web 頁面進行靜態(tài)保護和監(jiān)控問題 當監(jiān)控到網頁被篡改時能夠實時恢復頁 面 2 針對特殊數(shù)據(jù)的完整性檢查和監(jiān)控機制 應用系統(tǒng)自身的審計機制 這一點也可算作是應用系統(tǒng)的安全功能設計的一部分 參見相 關章節(jié)的要求 3 應用系統(tǒng)安全性分析 任何系統(tǒng)都會存在一定的安全缺陷 關鍵在于風險和缺陷是否可以被容忍 因此 在應用 系統(tǒng)設計完成后 應當就其安全性問題進行自我分析和評價 2 2 應用系統(tǒng)軟件功能安全設計要求 除了在架構上考慮的安全機制外 這些安全機制及相關的安全功能也應當分配在應用系統(tǒng) 軟件的各部件中 應用系統(tǒng)在開發(fā)中應該考慮如下五個方面的安全功能 安全審計 通訊安全 此部分內容在架構中進行了設計 數(shù)據(jù)保護 認證與授權 資源保障 2 2 1 認證與授權功能的設計 1 應用軟件應包含用戶身份認證體系的強度設計 重要系統(tǒng) 例如2 2級別以上系統(tǒng) 應使用 雙因素認證措施 加強系統(tǒng)安全性 用戶名 口令認證 一次性口令 動態(tài)口令認證 證書認證 可選 生物特征的認證 簽名 聲音 指紋 虹膜 視網膜等 可選 2 應用軟件應包含認證失敗后的處理方式設計 連續(xù)失敗3次 將鎖定登錄賬號一個小時 賬號鎖定后可以由系統(tǒng)管理員解鎖 也可以 在一段時間后自動解鎖 通知用戶認證失敗 防止黑客暴力猜測 驗證碼的功能 賬號復雜度提醒功能 3 應用軟件應包含用戶權限分配和管理功能設計 系統(tǒng)編碼中要實現(xiàn)讀 寫 執(zhí)行三個權限的分離設計 系統(tǒng)查看 配置 修改 刪除 登錄 運行等權限設計 數(shù)據(jù)訪問范圍的權限設計 應用功能模塊使用權限的設計 4 應用軟件應包含接口設計 應明確系統(tǒng)的內部結構和外部接口 對于每 一個對外接口應詳細說明 需要通信的對方系統(tǒng)的安全狀況和可信程度 需傳送的數(shù)據(jù)的保密性和完整性要求 對傳送數(shù)據(jù)的合法性檢驗規(guī)則 對通信可靠性的要求 與外部系統(tǒng)的互相認證方面的需求 5 應用系統(tǒng)認證與授權功能除滿足上述要求外 具體要求請參考 IT安全管控平臺建設 規(guī)范 中安全支撐平臺建設對應用系統(tǒng)的集中認證授權改造要求 2 2 2 數(shù)據(jù)安全功能 1 應用系統(tǒng)的數(shù)據(jù)安全功能 應當根據(jù)安全需求進行功能設計 內容涉及 數(shù)據(jù)庫的安 全 數(shù)據(jù)采集 數(shù)據(jù)傳輸 數(shù)據(jù)處理 數(shù)據(jù)存儲 數(shù)據(jù)備份和恢復的安全 對重要的敏感 數(shù)據(jù)應進行加密和完整性保護 2 應用軟件應包含輸入的安全性設計 主要指對錯誤輸入 惡意輸入進行處理 3 應用軟件應包含輸出的安全性設計 2 2 3 安全審計功能 1 應用系統(tǒng)具備如下安全審計功能 審計功能的啟動和關閉 變更審計功能的配置信息 至少應進行審計的事件 進入和退出的時間 登錄 退出系統(tǒng) 異常的系統(tǒng)使用行為 失 敗登錄 系統(tǒng)維護行為 敏感行為和其它安全功能要求的審計內容 每個審計記錄中至少記錄如下信息 事件的日期和時間 事件的類型 主題標識 事件 的結果 成功 失敗 和事件相關信息 2 應用系統(tǒng)應支持數(shù)據(jù)查閱審計功能 按照主題 事件查閱 應用系統(tǒng)應明確用戶能夠 查閱審計數(shù)據(jù)用戶 3 在意外情況出現(xiàn)時 應有措施保證審計數(shù)據(jù)的可用性 當審計記錄溢出時采取保護行 動 2 2 4 容錯功能設計 1 應用軟件應包含各模塊的出錯處理設計 2 應用軟件應包含可能出現(xiàn)的各種異常情況的安全處理設計 3 應用軟件應包含抗網絡攻擊的能力的設計及系統(tǒng)脆弱性分析 4 對于應用軟件本身的資源及服務的優(yōu)先保障設計 2 3 應用系統(tǒng)存儲安全設計要求 在應用系統(tǒng)存儲安全設計時 應對系統(tǒng)的存儲容量 存儲介質 存儲備份內容 存儲備份方式 存儲設備功能要求及相關的存儲技術統(tǒng)籌進行考慮 2 3 1 應用系統(tǒng)的存儲容量設計 應依據(jù)對于應用數(shù)據(jù)的測算 估算應用系統(tǒng)的存儲容量 建議在存儲容量估算 時應考慮以下要求 在實際估算值上預留20 的存儲余量 并考慮未來的應用存儲量的增長需求 考慮到應用系統(tǒng)自身的審計數(shù)據(jù)的容量 保存期限以配置相應的存儲設備 對于應用系統(tǒng)中的臨時數(shù)據(jù)和過渡數(shù)據(jù) 應當設計其保存的時間 并以此考慮 這部分的存儲容量要求 2 3 2 應用系統(tǒng)的存儲介質選擇 應用系統(tǒng)的存儲介質主要包括但不限于 磁帶 紙帶 閃存 軟盤 光盤 磁盤和磁盤陣 列 具體存儲介質的選擇應依據(jù)應用系統(tǒng)的業(yè)務種類及存儲周期的要求 采用不同的介質 1 對于應用系統(tǒng)的交易數(shù)據(jù) 應采用高性能 高可靠的存儲介質 如磁盤 磁盤陣列等 進行存儲 2 對于應用系統(tǒng)的歷史數(shù)據(jù) 應采用可靠 穩(wěn)定的存儲介質 如磁帶 光盤等進行存儲 2 3 3 應用系統(tǒng)存儲備份對象 應用系統(tǒng)對于其儲存?zhèn)浞莸膶ο笤O計 應包括如下內容 1 系統(tǒng)數(shù)據(jù)的備份 應包括Web服務器的網站內容 Mail服務器的郵件實時備份 數(shù)據(jù) 庫 文件服務器中的文件以及其他數(shù)據(jù) 2 系統(tǒng)的完全備份 應包括關鍵的 需要快速恢復的設備 通過磁帶機的完全備份 應 實現(xiàn)快速的災難恢復 3 系統(tǒng)的冗余主機備份 對于關鍵并且不能停止的服務設備 如計費服務 Web Mail 服務器 應考慮使用多臺主機進行冗余備份 以保證當任何一臺主機發(fā)生故障時 服務 器仍可提供服務 4 系統(tǒng)配置的備份 應包括關鍵路由器的配置 防火墻的配置 各類服務器操作系統(tǒng)的 安全配置以及各類服務器 如Web Mail 文件服務器等 中服務器軟件 如 Apache Sendmail 的配置 2 3 4 應用系統(tǒng)存儲備份方式 應用系統(tǒng)應當根據(jù)不同的階段 系統(tǒng)數(shù)據(jù)不同的重要程度 對數(shù)據(jù)采取不同的備份方式 1 完全備份 使用備份介質對整個系統(tǒng)進行完全備份 包括系統(tǒng)和數(shù)據(jù) 這種備份方式的優(yōu)點是直觀 容易被人理解 而且當數(shù)據(jù)丟失時 可以快速恢復丟失的數(shù)據(jù) 它也有不足之處 即 定期對系統(tǒng)進行完全備份 因此在備份數(shù)據(jù)中有大量的重復信息 占用了大量的存貯空 間 增加了備份成本 需要備份的數(shù)據(jù)量大 因此備份所需要的時間較長 建議在關鍵性應用系統(tǒng)的實施前 實施后 變更以及升級等重要操作時 對操作系統(tǒng)進行 完全備份 針對信息較小的不斷變化的 且變化的內容大于50 的 定期進行完全備份 2 增量備份 每次備份的數(shù)據(jù)只是相當于上一次備份后增加和修改過的數(shù)據(jù) 沒有重復的備份數(shù)據(jù) 節(jié) 省備份介質的空間 縮短了備份時間 這種備份的優(yōu)點很明顯 同時也存在某些不足之處 即當發(fā)生災難時 恢復數(shù)據(jù)比較麻煩 建議在關鍵性應用系統(tǒng)正常運行維護階段 針對變 化的 不斷增加的信息 定期進行增量備份 3 差異備份 每次備份的數(shù)據(jù)只是相當于上一次完全備份后新增加和修改過的數(shù)據(jù) 即采用完全備份和 差異備份相結合備份策略 如每周日進行一次完全備份 而周一至周六進行差異備份 其 優(yōu)點為 沒有重復的備份數(shù)據(jù) 即節(jié)省備份介質的空間 縮短了備份時間 缺點為 當發(fā) 生災難時 恢復數(shù)據(jù)比較麻煩 建議應用系統(tǒng)的正常運行維護階段 針對不斷變化的 變 化的內容小于50 系統(tǒng) 定期進行差異備份 4 按需備份 按需備份是指在正常的備份安排之外 額外進行的備份操作 這種備份方式可以彌補冗余 管理以及長期轉存的日常備份的不足 因此它是一種非常靈活 重要的備份方式 在應用 系統(tǒng)的各個階段 如果備份的內容較少 可以采用按需備份 建議應用系統(tǒng)在下列情況下采取按需備份 只需要備份很少的幾個文件 目錄 數(shù)據(jù)庫或數(shù)據(jù)庫中的表 備份服務器上必要的配置文件 5 排除備份 排除備份是指排除不需要的文件后再進行備份 從本質上講 排除備份不是一種備份方法 只是減少備份冗余的一種方法 建議應用系統(tǒng)在下列情況下考慮排除備份 有些文件非常大 但并不重要 某些文件總是導致備份異?；虺鲥e 2 3 5 應用系統(tǒng)的存儲設備功能要求 應用系統(tǒng)存儲設備的功能要求應包括如下內容 1 存儲設備應保證數(shù)據(jù)的高可用性和完整性要求 2 存儲設備應具有在多主機環(huán)境下工作的能力 3 存儲設備應能方便地做到快速備份和恢復 重要系統(tǒng)應做到雙機備份 支持熱插拔 4 存儲設備應有簡便的 功能強大的管理工具 做到對整個存儲系統(tǒng)的監(jiān)視與控制 2 4 應用系統(tǒng)通訊安全設計要求 1 應采用安全通信協(xié)議對重要數(shù)據(jù)進行安全傳輸 尤其是賬號 口令信息 如使用 SSL TLS HTTPS SFTP和IPSec等安全協(xié)議進行通信 終端與服務器端之間的WWW 服務 建議使用HTTPS 安全通信協(xié)議 終端與服務器端之間的FTP 服務 建議使SFTP 安全通信協(xié)議 終端與服務器端之間的Telnet 服務 建議使SSH 安全通信協(xié)議 2 終端應用程序采用加密傳輸機制對重要信息進行傳輸 3 終端應用程序采用完整性檢查對業(yè)務的重要數(shù)據(jù)或敏感數(shù)據(jù)進行檢查 4 終端應用程序應采用抗抵賴攻擊技術對重要的交互信息進行保護 5 終端應用程序使用固定的通信端口 2 5 應用系統(tǒng)數(shù)據(jù)庫安全設計要求 1 應從以下方面進行數(shù)據(jù)庫的選型 數(shù)據(jù)庫 應用系統(tǒng)的運行環(huán)境 數(shù)據(jù)庫的穩(wěn)定性 安全性 多級安全 數(shù)據(jù)庫的容量 最多支持的庫的數(shù)目 表的數(shù)目 記錄數(shù)目 數(shù)據(jù)庫的存取速度 是否支持多種備份方式 是否支持數(shù)據(jù)庫的導入和導出 2 應明確數(shù)據(jù)庫相關的用戶管理 資源管理 特權管理和角色管理 明確各種用戶的資 源權限 并建立規(guī)范的權限文檔 3 數(shù)據(jù)庫原則上應及時更新重要補丁 在安裝補丁前應先在測試環(huán)境進行 提前進行數(shù) 據(jù)備份 充分準備回退方案和應急預案 4 數(shù)據(jù)庫的配置應符合相應的基線配置要求 5 應及時修改數(shù)據(jù)庫的默認密碼或將默認賬號鎖定 刪除 6 數(shù)據(jù)庫的賬號應根據(jù)業(yè)務和維護需要進行合理分配 避免賬號共用 2 6 應用系統(tǒng)數(shù)據(jù)安全設計要求 2 6 1 數(shù)據(jù)采集安全 應根據(jù)數(shù)據(jù)采集的內容 采集的頻率 數(shù)據(jù)精確度要求 時間特性等來進行數(shù)據(jù)采集的安 全要求設計 數(shù)據(jù)采集服務器和采集主機應考慮30 的系統(tǒng)開銷及冗余 2 6 2 數(shù)據(jù)傳輸安全 1 應按照數(shù)據(jù)的類型 數(shù)據(jù)的重要程度 網絡的安全狀況等綜合因素 對數(shù)據(jù)的傳輸采 取不同的安全保護 包括但不限于防火墻 IDS VPN 病毒防護等安全措施 2 應了解數(shù)據(jù)傳輸存在安全隱患的網絡或設備 對存在安全隱患的網絡采取必要的安全 技術 包括但不限于安全通信協(xié)議 加密算法 完整性檢查算法以及抗抵賴攻擊方法等 3 應制定數(shù)據(jù)傳輸安全的檢查方式 包括但不限于數(shù)據(jù)傳輸安全抗主動攻擊能力檢查 被動抗攻擊的能力檢查 4 應保障 數(shù)據(jù)傳輸安全 有關的重要配置參數(shù)安全 包括但不限于口令 加 解密算法 加 解密密鑰等 5 應采用安全通信協(xié)議對數(shù)據(jù)進行安全傳輸 如使用SSL TLS HTTPS SFTP和IPSec等 安全協(xié)議進行通信 6 對傳輸?shù)男畔⑦M行不同等級的加密保護 即根據(jù)網絡或設備的風險 傳輸內容安全要 求的不同 選擇不同安全強度的加密算法對信息進行加密傳輸 建議使用RSA等高強度的 密碼算法對非常重要的信息 如口令 加密密鑰 進行加密傳輸 對于普通數(shù)據(jù)的傳輸 可以采用DES 3DES等加密算法進行加密傳輸 7 應防止對所傳輸數(shù)據(jù)進行未經授權的任何形式的修改 即對業(yè)務的重要數(shù)據(jù)或敏感數(shù) 據(jù) 建議使用MD5 SHA等算法對數(shù)據(jù)完整性進行保護 8 對重要的交互信息 建議采取抗抵賴技術 包括但不限于數(shù)字簽名技術 9 為了配合網絡其它安全設備 建議采用基于用戶名 口令的認證技術 VLAN技術 MPLS技術等安全技術手段 2 6 3 數(shù)據(jù)處理安全 1 應根據(jù)數(shù)據(jù)的類型 數(shù)據(jù)的處理方式 數(shù)據(jù)的安全性要求 與其它接口有關的敏感等級 數(shù)據(jù)相關業(yè)務應用的重要性程度來進行數(shù)據(jù)處理過程的安全性設計 2 應對原始數(shù)據(jù)進行檢錯和校驗操作 保證原始數(shù)據(jù)的正確性和完整性 3 數(shù)據(jù)在轉換過程中 應采用通用的標準格式 應考慮相關的不同系統(tǒng)和不同應用的格式 需求 4 數(shù)據(jù)處理過程應提供處理數(shù)據(jù)的狀態(tài)信息和數(shù)據(jù)處理過程的動態(tài)信息 5 數(shù)據(jù)處理過程應具備異常處理功能 在任一環(huán)節(jié)發(fā)現(xiàn)問題 均應能及時回退 必要時可 以人工處理 6 數(shù)據(jù)處理的中間過程和中間結果不能暴露給第三方 3 應用系統(tǒng)編碼安全應用系統(tǒng)編碼安全 3 1 基本代碼安全要求 3 1 1 輸入驗證 對函數(shù)入口參數(shù)的合法性和準確性進行檢查 具體如下 在B S 環(huán)境下 應進行服務端的 驗證而不僅僅是客戶端的驗證 例如基于Javascript 的驗證 通過在客戶端和服務器之間 放置一個代理服務器 可以很容易繞過客戶端驗證 有了代理服務器 攻擊者可以在數(shù)據(jù) 被客戶端 驗證 后修改數(shù)據(jù) 與 man in the middle 攻擊類似 在實際的校驗中 輸入校 驗首先定義一個有效 可接受 的字符集 然后檢查每個數(shù)據(jù)的字符是否在有效范圍內 如果輸入中包含無效的字符 應用程序應該返回錯誤頁面并說明輸入中包含無效字符 這 樣進行驗證的原因是定義無效的字符集比較困難 并且一些不應該有效的字符通常不會被 指出 另外 邊界檢查 例如字符串的最大長度 應該在字符有效性檢查以前進行 邊界 分析可以防止大多數(shù)緩沖區(qū)溢出漏洞 從環(huán)境變量獲得的數(shù)據(jù)也需要進行驗證 同時避免 在環(huán)境變量中存放敏感數(shù)據(jù) 例如密碼 3 1 2 SQL 語句 如果應用程序需要連接后端數(shù)據(jù)庫 使用存儲過程而不能在代碼中使用SQL語句 使用程 序以外的嵌入在代碼中的SQL 語句調用特別危險 難以防止攻擊者使用輸入域或者配置文 件 由應用程序載入 來執(zhí)行嵌入式的SQL 攻擊 當然 輸入驗證有助于緩解這種風險 3 1 3 注釋代碼 當應用程序在實際環(huán)境中開始應用時 應該刪除所有的注釋代碼 注釋代碼是用來調試或 者測試的 它們不是最終應用程序的一部分 無論如何應該在實際的環(huán)境中刪除它們以避 免意外的執(zhí)行 一般注釋標識被刪除后就無法激活休眠的代碼 但還是存在可能性的 所 以強烈建議執(zhí)行這項工作 3 1 4 錯誤消息 所有為用戶顯示的錯誤信息都不應該暴露任何關于系統(tǒng) 網絡或應用程序的敏感信息 如 果可能 應使用包含編號的一般的錯誤信息 這種信息只有開發(fā)者和 或支持小組才能理解 如 發(fā)生了錯誤 代碼1234 請您與系統(tǒng)維護部門聯(lián)系 3 1 5 URL 內容 對于Web 應用 不能在URL 上暴露任何重要信息 例如密碼 服務器名稱 IP 地址或者 文件系統(tǒng)路徑 暴露了Web 服務器的目錄結構 這些信息可以在攻擊時被使用 3 1 6 設置PATH 變量 設置PATH 為一個已知的值 而不是僅僅使用啟動時的缺省值 攻擊者可以在攻擊應用程 序時使用PATH 變量 例如試圖執(zhí)行一個任意的程序 這些可以應用于大多數(shù)其他的語言 3 1 7 其他要求 1 禁止使用未經授權和驗證的代碼 2 使用第三方代碼 應對代碼安全性進行評估和測試 3 測試用的 后門 應在發(fā)布版中去除 4 規(guī)范代碼的格式 規(guī)范變量 函數(shù)的命名 規(guī)范程序的書寫格式 確保程序的易讀性 5 對代碼進行版本控制 確保代碼的可用性 6 防止程序員非授權修改代碼 對代碼的訪問權限進行嚴格的權限控制 禁止在程序中添加隱藏 惡意 的代碼 防止與應用系統(tǒng)相關的程序員 對系統(tǒng)的非授權修改 7 應用系統(tǒng)不應在程序或進程中固化賬號和口令 8 系統(tǒng)應具備對口令猜測的防范機制和監(jiān)控手段 9 避免應用程序以錯誤的順序運行 或者防止出現(xiàn)故障時 后續(xù)程序以不正常的流程運 行 10 采用正確的故障恢復程序 確保正確處理數(shù)據(jù) 11 采取會話控制或批次控制 確保更新前后數(shù)據(jù)文件的一致性 例如 檢查操作前后文 件打開和關閉的數(shù)目是否一致 12 檢查執(zhí)行操作前后對象的差額是否正常 如 句柄處理 堆棧等系統(tǒng)資源的占用與釋 放等 13 嚴格驗證系統(tǒng)生成的數(shù)據(jù) 14 在網絡傳輸過程中檢查下載 上傳的數(shù)據(jù)或軟件的完整性 15 檢查文件與記錄是否被篡改 例如通過計算哈希值 HASH 進行對比 3 2 Web 編程安全基本要求 3 2 1 輸入檢查安全 1 限制用戶輸入HTML 和Script JavaScript VBScript 代碼 即 輸入惡意HTML 或 Script JavaScript VBScript 代碼可能會對其他瀏覽者造成混淆 欺騙或惡意破壞的結果 2 檢查用戶輸入數(shù)據(jù)的長度 即輸入超出限定長度的數(shù)據(jù) 可能造成服務器端程序溢出 3 防止用戶輸入特殊字符改變SQL 語義 即 輸入含特殊字符的字串 篡改SQL 語句 的語義 可能造成SQL 查詢執(zhí)行不該執(zhí)行的操作 以此繞過身份認證獲取非法權限 甚至 對數(shù)據(jù)進行破壞 4 限制用戶能夠訪問的最頂層目錄 即 編寫對服務器端文件 目錄操作的程序時應該 注意限定此類程序能夠訪問的最頂層目錄 防止用戶構造輸入字串借助程序功能訪問服務 器關鍵文件導致泄漏服務器敏感信息 5 對所有類型的用戶輸入都要做檢查 并嚴格限定什么是合法的用戶輸入 限定一個合 法輸入的范圍 同時過濾有可能造成危險的特殊字符 6 對不可信任域發(fā)送到可信任域的數(shù)據(jù)一定要進行檢查 7 盡可能在服務器端完成用戶輸入檢查 不能輕易相信客戶端腳本的檢查結果 即 雖 然客戶端的Script 腳本能完成一部分的用戶輸入檢查功能 但這種檢查的結果是不可信任 的 攻擊者可以自己制作表單程序繞過客戶端腳本驗證 將非法數(shù)據(jù)提交到服務器 8 在輸入變?yōu)檩敵鰰r 也要對特殊字符做檢查和轉換 3 2 2 敏感數(shù)據(jù)的存放和傳遞安全 1 敏感數(shù)據(jù)不能存放在Web 頁中 2 不能把敏感的數(shù)據(jù)存儲在cookie 隱藏字段或者潛在地可能會被用戶修改的地方 3 客戶端向服務器端提交敏感數(shù)據(jù)應該經過加密 例如使用SSL 盡量不能明文傳輸 4 密碼等敏感信息存放在數(shù)據(jù)庫中應該加密 并采用健壯的加密算法 5 防止數(shù)據(jù)庫被攻破后泄漏用戶密碼 3 2 3 緩沖區(qū)溢出安全 1 所有的輸入都必須進行正確的有效性檢測 2 必須保證數(shù)組沒有越界 增加數(shù)組操作函數(shù)的邊界檢查 3 安全地使用字符串處理函數(shù) 慎用有安全隱患的字符串處理函數(shù) 4 使用Format 字符串的時候特別注意Unicode 和ANSI 的大小不一致的情況 5 注意字符串結束符的保護 6 仔細研究庫函數(shù)內部的緩沖區(qū)分配 明確其限制 不能使用realpath 等函數(shù) 如果功 能需要必須使用時 一定要檢查試圖規(guī)范化的路徑的長度 確保其不長于 MAXPATHLEN 7 時刻進行邊界檢查 建議使用一些檢查工具 Purify Stackguard 等檢查代碼 保證沒 有緩沖區(qū)溢出的問題 3 2 4 格式化字符串安全 1 使用固定的格式化字符串 或者來自可信源的格式化字符串 2 要檢查并限定locale 的請求為合法值 3 不能將用戶輸入直接作為格式化字符傳給格式化函數(shù) 3 2 5 整數(shù)溢出安全 1 對于涉及到內存分配大小的計算 要進行仔細檢查 確保計算不會產生溢出 2 對于涉及到數(shù)組索引的計算 要進行仔細檢查 確保計算不會產生溢出 3 要使用無符號整數(shù)表示數(shù)組偏移和內存分配大小 3 2 6 SQL 注入代碼安全 1 要檢查輸入的有效性和可信度 2 要使用參數(shù)化的查詢 占位符 或者參數(shù)綁定來構造SQL 語句 3 要在程序之外存儲數(shù)據(jù)庫的連接信息 比如經過保護的配置文件或者Windows 注冊表 4 即使使用的是存儲過程 也不能使用字符串連接來構造SQL 語句 5 不能在存儲過程內部使用字符串連接來構造SQL 語句 6 不能在存儲過程內部執(zhí)行不可信的參數(shù) 7 不能簡單地雙寫單引號或者雙引號 8 不能使用高權限賬號連接數(shù)據(jù)庫 比如sa 或者root 9 不能在程序或者連接字符串中存儲登錄口令 10 不能在Web 根目錄下存儲數(shù)據(jù)庫配置信息 11 應從數(shù)據(jù)庫中刪除對所有用戶自定義表的訪問權限 同時只對存儲過程授權 然后使 用存儲過程以及參數(shù)化的查詢來構造查詢字符串 3 2 7 命令注入代碼安全 1 在輸入命令傳遞給命令處理程序之前要進行驗證 2 如果輸入驗證失敗 要安全地處理失敗信息 3 不能向任何命令解釋器傳遞未驗證的輸入信息 即使這些輸入僅僅是數(shù)據(jù)信息 4 避免使用正則表達式來進行輸入驗證 應手工去寫一些簡單而又清晰的驗證代碼 3 2 8 異常處理代碼安全 1 要檢測每個安全相關函數(shù)的返回值 2 對于每一個更改用戶設定或者及其設定的函數(shù) 都要檢查其返回值 3 要有從錯誤條件中進行恢復的考慮 避免拒絕服務攻擊 4 不能一次性處理所有的異常 要將異常情況進行分類處理 避免在異常處理代碼中的 漏洞發(fā)生 3 2 9 跨站腳本代碼安全 1 要對所有基于Web 的輸入進行輸入驗證和可信度驗證 2 在沒有驗證合法性之前 不能對基于Web 的輸入進行回顯 3 不能在cookie 中存儲敏感數(shù)據(jù) 3 2 10 保護網絡流量的代碼安全 1 要使用強大的初始認證機制 2 對應用程序所產生的所有網絡流量都要執(zhí)行過程中消息認證 3 盡可能使用SSL TLS 進行網絡加密傳輸 3 2 11 應用中的弱口令代碼安全 1 確?？诹钤诰W絡上認證時不被竊聽 2 要在登錄失敗時給出錯誤提示 并記錄失敗口令嘗試 3 盡可能使用基于hash 強壯的單向加密函數(shù)進行口令存儲 4 為用戶更改口令提供安全的機制 5 不得使用默認賬號和默認口令 若使用 必須在首次登錄后進行修改 6 不得在程序 后臺存儲明文的口令 7 口令要有一定的強度 應當滿足系統(tǒng)的賬號口令策略要求 3 3 SOCKET 網絡編程安全基本要求 1 在socket 函數(shù)調用時 明確參數(shù)中綁定的端口 IP 地址和網卡接口 Windows 環(huán)境 下 在遇到多個網卡的情況時 需要通過注冊表來獲得網卡接口和IP 地址的信息 包括 Windows NT 和windows 2000 2 判斷連接的合法身份 即 為防止惡意的連接以及可能是無效的連接 建議在socket 連接期間 判斷連接的對端是否是合法的真正的連接 3 對于UDP 連接 可以獲得連接對方的IP 地址和端口 從而可以判斷對方的有效性和 合法性 對于TCP 連接 由于每次連接需要三次握手 而且還有超時機制 存在兩種方式 來控制 4 對于TCP 連接 需要盡量在三次握手完成前完成判斷 同時防止端口掃描的攻擊 5 盡可能確保socket 應用能通過合理設置的防火墻 6 在可能的情況下 盡量減少socket 連接數(shù)目 7 盡量不能使用回撥的技術 8 盡量采用有連接狀態(tài)的協(xié)議 例如TCP 協(xié)議 由于防火墻一般采取禁止一切的策略 對于UDP 協(xié)議比較難以設置 9 在一個應用程序中 盡量使用同一種協(xié)議 不能使用多種協(xié)議 10 盡量將客戶端和服務器端的端口做成可以配置 不能硬編碼在程序中 3 4 JAVA 安全開發(fā)要求 JAVA 語言安全規(guī)范參考OWASP TOP 10 要求 本指南列舉了常見的 JAVA 開發(fā)安全要求 3 4 1 防范跨站腳本 XSS 跨站腳本是最普遍的Web 應用安全漏洞 當應用程序在發(fā)送給瀏覽器的頁面中包含用戶提 供的數(shù)據(jù) 但沒有經過適當驗證或轉譯 就容易導致跨站腳本漏洞 攻擊者能在受害者瀏覽器中執(zhí)行腳本以劫持用戶會話 危害網站 插入惡意內容和重定向 用戶等 已知三種著名跨站漏洞是 1 存儲式 2 反射式 3 基于DOM 反射式跨站腳本通過測試或代碼分析很容易找到 防范措施 1 驗證輸入 檢查每個輸入的有效性 主要檢查輸入類型和數(shù)據(jù)的長度 2 編碼輸出 對驗證輸入的另一面就是編碼輸出 編碼輸出是指確保字符被視為數(shù)據(jù) 而不是作為 HTML 元字符被瀏覽器解析 這些技術定義一些特殊的 轉義 字符 沒有正確轉義的數(shù) 據(jù)它仍然會在瀏覽器中正確解析 編碼輸出只是讓瀏覽器知道數(shù)據(jù)是不是要被解析 達到 攻擊無法實現(xiàn)的目的 需要編碼的部分 HTML 實體 HTML 屬性 JavaScript CSS URL 3 4 2 防范SQL 注入 簡單來說 注入往往是應用程序缺少對輸入進行安全性檢查所引起的 攻擊者把一些包含 指令的數(shù)據(jù)發(fā)送給解釋器 解釋器把收到的數(shù)據(jù)轉換成指令執(zhí)行 注入漏洞十分普遍 通 常能在SQL 查詢 LDAP 查詢 Xpath 查詢 OS 命令 程序參數(shù)等中出現(xiàn) 注入能導致 數(shù)據(jù)丟失或數(shù)據(jù)破壞 缺乏可審計性或是拒絕服務 注入漏洞有時甚至能導致完全接管主 機 SQL 注入包含了SQL 注入 XPATH 注入 LDAP 注入 OS 命令注入等 3 4 3 防范惡意文件執(zhí)行 惡意文件執(zhí)行是一種能夠威脅任何網站形式的漏洞 只要攻擊者在具有引入 include 功 能程式的參數(shù)中修改參數(shù)內容 Web 服務器便會引入惡意程序從而受到惡意文件執(zhí)行漏洞 攻擊 攻擊者可利用惡意文件執(zhí)行漏洞進行攻擊取得Web 服務器控制權 進行不法利益或 獲取經濟利益 3 4 4 不安全的直接對象引用 所謂 不安全的對象直接引用 即Insecure direct object references 意指一個已經授權的用 戶 通過更改訪問時的一個參數(shù) 從而訪問到原本其并沒有得到授權的對象 Web 應用往 往在生成Web 頁面時會用它的真實名字 且并不會對所有的目標對象訪問時檢查用戶權限 所以這就造成了不安全的對象直接引用的漏洞 以下是不安全的對象直接引用示例 攻擊者發(fā)現(xiàn)他自己的參數(shù)是6065 即 acct 6065 他可以直接更改參數(shù)為6066 即 acct 6066 這樣他就可以直接看到6066 用戶的賬戶信息了 這種漏洞能損害參數(shù)所引用的所有數(shù)據(jù) 除非名字空間很稀疏 否則攻擊者很容易訪問該 類型的所有數(shù)據(jù) 3 4 5 防范跨站請求偽造 跨站請求偽造 也被稱成為 one click attack 或者session riding 通常縮寫為CSRF 或者 XSRF 是一種對網站的惡意利用 它與XSS 非常不同 并且攻擊方式幾乎相左 XSS 利 用站點內的信任用戶 而CSRF 則通過偽裝來自受信任用戶的請求來利用受信任的網站 與XSS 攻擊相比 CSRF 攻擊往往不太流行 因此對其進行防范的資源也相當稀少 和難 以防范 所以被認為比XSS 更具危險性 攻擊者能讓受害用戶修改可以修改的任何數(shù)據(jù) 或者是執(zhí)行允許使用的 任何功能 3 4 6 信息泄露和錯誤處理不當 應用程序常常產生錯誤信息并顯示給使用者 很多時候 這些錯誤信息非常有用 因為它 們揭示實施細則或有用的開發(fā)信息 泄露太多的細節(jié) 如錯誤堆棧跟蹤信息 SQL 語句等等 登錄失敗后 通知用戶是否用戶ID 或密碼出錯 登錄失敗可能是由于ID 或密碼錯誤 造成的 這為一個對關鍵資產發(fā)動蠻力攻擊的攻擊者提供重要信息 3 4 7 殘缺的認證和會話管理 與認證和會話管理相關的應用程序功能往往得不到正確實施 這就導致攻擊者破壞密碼 密鑰 會話令牌或利用實施漏洞冒充其他用戶身份 這些漏洞可能導致部分甚至全部賬號 遭受攻擊 一旦攻擊成功 攻擊者能執(zhí)行合法用戶的任何操作 因此特權賬號會造成更大 的破壞 編程要求 使用內置的會話管理功能 通過認證的問候 使用單一的入口點 確保在一開始登錄SSL 保護的網頁 獲取注銷的權利 添加超時 確保你使用的是安全相關的功能 使用強大的認證 不進行默認身份驗證 3 4 8 不安全的加密存儲 保護敏感數(shù)據(jù)已經成為網絡應用的最重要的組成部分 加密的敏感數(shù)據(jù)已是非常常見安全 保護手段 不加密的應用程序 設計不當或者使用不恰當?shù)拿艽a技術等可能導致披露敏感 數(shù)據(jù) 攻擊者能夠取得或是篡改機密的或是私有的信息 攻擊者通過機密秘密的竊取從而進行進一步的攻擊 造成企業(yè)形象破損 用戶滿意度下降 甚至面臨法律訴訟等 編程要求 驗證你的結構 識別所有的敏感數(shù)據(jù) 識別敏感數(shù)據(jù)存放的所有位置 確保所應用的威脅模型能夠應付這些攻擊 使用加密手段來應對威脅 使用一定的機制來進行保護 文件加密 數(shù)據(jù)庫加密 數(shù)據(jù)元素加密 正確的使用這些機制 使用標準的強算法 合理的生成 分發(fā)和保護密鑰 準備密鑰的變更 驗證實現(xiàn)方法 確保所有的證書 密鑰和密碼都得到了安全的存放 有一個安全的密鑰分發(fā)和應急處理的方案 3 4 9 不安全的通信 對于不加密的應用程序的網絡信息傳輸 需要保護敏感的通信 加密 通常SSL 必須用 于所有身份驗證的連接 特別是通過Internet 訪問的網頁 以及后端的連接 否則 應用 程序將暴露身份驗證或會話令牌 攻擊者能夠取得或是篡改機密的或是私有的信息 攻擊者通過這些秘密的竊取從而進行進一步的攻擊 造成企業(yè)形象破損 用戶滿意度下降 甚至面臨法律訴訟等 編程要求 提供合理的保護機制 對于敏感數(shù)據(jù)的傳輸 對所有連接都要使用TLS 在傳輸前對單個數(shù)據(jù)都要進行加密 如XML Encryption 在傳輸前對信息進行簽名 如XML Signature 正確的使用這些機制 使用標準的強算法 合理管理密鑰和證書 在使用前驗證SSL 證書 3 4 10 限制URL 訪問失效 這個漏洞事實上也是與認證相關的 與我們前面提到的不安全的直接對象引用也是類似的 不同在于這個漏洞是指系統(tǒng)已經對URL 的訪問做了限制 但這種限制卻實際并沒有生效 常見的錯誤是 我們在用戶認證只顯示給用戶認證過的頁面和菜單選項 而實際上這些僅 僅是表示層的訪問控制而不能真正生效 攻擊者能夠很容易偽造請求直接訪問未被授權的 頁面 編程要求 如果URL 不是公開的 那么必須限制能夠訪問的授權用戶 加強基于用戶或角色的訪問控制 完全禁止訪問未被授權的頁面類型 如配置文件 日志文件 源文件等 驗證你的構架 在每一個層次都使用簡單肯定的模型 確保每一層都有一個訪問機制 驗證你的實現(xiàn) 不能使用自動化的分析工具 確保每個URL 都被外部過濾器或其他機制保護 確保服務器的配置不允許對非授權頁面的訪問 3 5 PHP 安全開發(fā)要求 3 5 1 變量濫用 PHP 4 1 0 發(fā)布的時候建議關閉register globals 并提供了7 個特殊的數(shù)組變量來使用各種 變量 對于從GET POST COOKIE 等來的變量并不會直接注冊成變量 必需通過數(shù)組 變量來存取 PHP 4 2 0 發(fā)布的時候 php ini默認配置就是register globals Off 這使得程 序使用PHP 自身初始化的默認值 一般為0 避免了攻擊者控制判斷變量 通過以下解決方法實現(xiàn) 配置文件php ini 設置register globals Off 要求程序員對作為判斷的變量在程序最開始初始化一個值 3 5 2 文件打開 如非特殊需要 把php 的文件操作限制在Web 目錄里面 以下是修改apache 配置文件 httpd conf 的一個例子 php admin value open basedir usr local apache htdocs 重啟apache 后 usr local apache htdocs 目錄下的PHP 腳本就只能操作它自己目錄下的文 件了 否則PHP 就會報錯 Warning open basedir restriction in effect File is in wrong directory in xxx on line xx 使用safe mode 模式也能避免這種問題 前面已經討論過 3 5 3 文件包含 要求程序員包含文件里的參數(shù)盡量不能使用變量 如果使用變量 就一定要嚴格檢查要包 含的文件名 絕對不能由用戶任意指定 如前面文件打開中限制PHP 操作路徑是一個必要 的選項 另外 如非特殊需要 一定要關閉PHP 的遠程文件打開功能 修改php ini 文件 allow url fopen Off 重啟apache 3 5 4 文件上傳 PHP 4 0 3 以后提供了is uploaded file 和move uploaded file 函數(shù) 可以檢查操作的文件是 否是用戶上傳的文件 從而避免把系統(tǒng)文件拷貝到Web目錄 使用 HTTP POST FILES 或 FILES 數(shù)組來讀取用戶上傳的文件變量 嚴格檢查上傳變量 比如不允許是php 腳本文件 把PHP 腳本操作限制在Web 目錄可以避免程序員使用copy 函數(shù)把系統(tǒng)文件拷貝到Web 目錄 move uploaded file 不受open basedir 的限制 所以不必修改php ini 里 upload tmp dir 的值 把PHP 腳本用phpencode 進行加密 避免由于copy 操作泄漏源碼 嚴格配置文件和目錄的權限 只允許上傳的目錄能夠讓nobody 用戶可寫 對于上傳目錄去掉PHP 解釋功能 可以通過修改httpd conf 實現(xiàn) php flag engine off 如果是php3 換成php3 engine off 重啟apache upload 目錄的php 文件就不能被apache 解釋了 即使上傳了php 文件也沒有 問題 只能直接顯示源碼 3 5 5 命令執(zhí)行 解決方法 要求程序員使用escapeshellcmd 函數(shù)過濾用戶輸入的shell 命令 啟用safe mode 可以杜絕很多執(zhí)行命令的問題 不過要注意PHP 的版本一定要是最新的 小于PHP 4 2 2 的都可能繞過safe mode 的限制去執(zhí)行命令 變量類型缺陷 邏輯比較時注意變量類型 必要的時候使用 那么連變量類型一起比較 3 5 6 警告及錯誤信息 修改php ini 中關于Error handling and logging 部分內容 error reporting E ALL display errors Off log errors On error log usr local apache logs php error log 然后重啟apache 注意文件 usr local apache logs php error log 必需可以讓nobody 用戶可 寫 3 5 7 PHP 與MySQL 組合的SQL 注入 解決方法 要求程序員對所有用戶提交的要放到SQL 語句的變量進行過濾 即使是數(shù)字類型的字段 變量也要用單引號擴起來 MySQL 自己會把字串處理成數(shù)字 在MySQL 里不能給PHP 程序高級別權限的用戶 只允許對自己的庫進行操作 3 5 8 跨站腳本 解決方法 確認輸入 strip tags htmlspecialchars 清除危險的插入點 3 5 9 禁用無用的函數(shù) 如果覺得有些函數(shù)還有威脅 可以設置php ini 里的disable functions 這個選項不能在 httpd conf 里設置 比如 disable functions phpinfo get cfg var 可以指定多個函數(shù) 用逗號分開 重啟apache 后 phpinfo get cfg var 函數(shù)都被禁止了 建議關閉函數(shù)phpinfo get cfg var 這兩個函數(shù)容易泄漏服務器信息 而且沒有實際用處 3 5 10 禁用某些類 這個選項是從PHP 4 3 2 開始才有的 它可以禁用某些類 如果有多個用逗號分隔類名 disable classes 也不能在httpd conf 里設置 只能在php ini配置文件里修改 3 5 11 限制腳本操作路徑 前面分析例程的時候也多次提到用open basedir 對腳本操作路徑進行限制 這里再介紹一 下它的特性 用open basedir 指定的限制實際上是前綴 不是目錄名 也就是說 open basedir dir incl 也會允許訪問 dir include 和 dir incls 如果它們存在的話 如果要將訪問限制在僅為指定的目錄 用斜線結束路徑名 例如 open basedir dir incl 可以設置多個目錄 在Windows 中 用分號分隔目錄 在任何其它系統(tǒng)中用冒 號分隔目錄 作為Apache 模塊時 父目錄中的open basedir 路徑自動被繼承 3 5 12 其他安全配置 1 取消其它用戶對常用 重要系統(tǒng)命令的讀寫執(zhí)行權限 一般管理員維護只需一個普通用戶和管理用戶 除了這兩個用戶 給其它用戶能夠執(zhí)行 和訪問的東西應該越少越好 所以取消其它用戶對常用 重要系統(tǒng)命令的讀寫執(zhí)行權限能 在程序或者服務出現(xiàn)漏洞的時候給攻擊者帶來很大的迷惑 記住一定要連讀的權限也去掉 否則在linux 下可以用 lib ld linux so 2 bin ls 這種方式來執(zhí)行 如果要取消程序如果是在chroot 環(huán)境里 這個工作比較容易實現(xiàn) 否則 這項工作還是 有些挑戰(zhàn)的 因為取消一些程序的執(zhí)行權限會導致一些服務運行不正常 PHP 的mail 函 數(shù)需要 bin sh 去調用sendmail 發(fā)信 所以 bin bash 的執(zhí)行權限不能去掉 2 去掉apache 日志其它用戶的讀權限 apache 的access log 給一些出現(xiàn)本地包含漏洞的程序提供了方便之門 通過提交包含PHP 代碼的URL 可以使access log 包含PHP 代碼 那么把包含文件指向access log 就可以執(zhí) 行那些PHP 代碼 從而獲得本地訪問權限 如果有其它虛擬主機 也應該相應去掉該日志文件其它用戶的讀權限 當然 如果你按照前面介紹的配置PHP 那么一般已經是無法讀取日志文件了 3 保持運行環(huán)境干凈 4 不能在 Web 目錄放測試文件 3 6 C C 安全開發(fā)要求 C 本質上是不安全的編程語言 例如如果不謹慎使用的話 其大多數(shù)標準的字符串庫函數(shù) 有可能被用來進行緩沖區(qū)攻擊或者格式字符串攻擊 但是 由于其靈活性 快速和相對容 易掌握 它是一個廣泛使用的編程語言 下面是針對開發(fā)安全的C 語言程序的一些規(guī)范 3 6 1 緩沖區(qū)溢出 避免使用不執(zhí)行邊界檢查的字符串函數(shù) 因為它們可能被用來進行緩沖區(qū)溢出攻擊 下面 是應該避免使用的函數(shù) 同時 也列出了每個函數(shù)相應的比較安全的替換方式 不使用strcpy 使用strncpy 不使用strcat 使用strncat 不使用sprintf 使用snprintf 不使用gets 使用fgets 在上面的前三個中函數(shù)中 每個替代函數(shù)的 n 表示了使用的緩沖區(qū)的大小 最后一個函數(shù) 的 f 表示格式 它允許用戶指定期望的輸入的格式 這些替換方程強制程序員定義使用 的緩沖區(qū)的尺寸以及確定輸入的類型 3 6 2 格式化字符串攻擊 該類攻擊往往與緩沖區(qū)溢出相關 因為它們主要利用了某些函數(shù)的假設 例如sprintf 和 vsprintf 假設緩沖區(qū)的長度是無限的 然而即使使用snprintf 替換sprintf 也無法完全保護 程序不受格式化字符串的攻擊 這些攻擊通過直接將格式說明符 format specifiers d s n 等 傳遞到輸出函數(shù)接收緩沖區(qū)來進行 例如 以下的代碼就是不安全的 snprintf buffer sizeof buffer string 這種情況下 可以在字符串中插入格式說明符來操縱內存的棧 來寫入攻擊者的數(shù)據(jù) 這 些數(shù)據(jù)中包含小的程序代碼 并可由處理器接著執(zhí)行 對以上的例子建議使用下面的代 碼 snprintf buffer sizeof buffer s string 進行格式字符串攻擊不太容易 首先攻擊者 必須能獲得內存棧的內容情況 或者從應用導出或者使用調試器 然后必須知道如何精 確訪問特定的內存空間來操縱棧中的變量 執(zhí)行外部程序推薦使用exec 函數(shù)而不是system 函數(shù)來執(zhí)行外部程序 這是因為 system 接收整個命令行的隨機的緩沖區(qū)來執(zhí)行程序 snprintf buffer sizeof buffer emacs s filename system buffer 在以上的例子中 可以通過使用分號利用文件名變量在sehll 中插入額外的命令 例如文件 名可以是 etc hosts rm 這將在顯示 etc hosts 目錄文件的同時 刪除目錄中的所有文件 而exec 函數(shù)只保證第一個參數(shù)被執(zhí)行 execl usr bin emacs usr bin emacs filename NULL 上面的例子保證文件名僅僅作為一個參數(shù)輸入Emacs 工具 同樣它在Emacs 命令中使用完 全的路徑而不是使用可以被攻擊者利用的PATH 環(huán)境變量 3 6 3