一尿背、背景
團隊最近頻繁遭受網絡攻擊弟疆，引起了部門技術負責人的重視，筆者在團隊中相對來說更懂安全批钠，因此花了點時間編輯了一份安全開發(fā)自檢清單宇植，覺得應該也有不少讀者有需要，所以將其分享出來埋心。
二指郁、自檢清單
| 檢查類型 | 說明 | 檢查項 |
|---|---|---|
| 輸入驗證 | 概述 | 任何來自客戶端的數(shù)據(jù),如URL和參數(shù)、HTTP頭部拷呆、 Javascript戓其他嵌入代碼提交的信息,都屬于不可信數(shù)據(jù)闲坎。在應用外部邊界或內部每個組件或功能邊界,都將其當做潛在的惡意輸入來校驗 |
| 白名單 | 不可信數(shù)據(jù)可以設定白名單校驗的,應接受所有和白名單匹配的數(shù)據(jù),并阻止其他數(shù)據(jù) | |
| 黑名單 | 不可信數(shù)據(jù)中包含不良輸入字符時,如空字節(jié)(%00)、換行符(%0d,%0a,\r, \n)茬斧、路徑字符(../ 或 ..)等,建議直接阻止該數(shù)據(jù),若需要接受該數(shù)據(jù),則應做不同方式的凈化處理 | |
| 規(guī)范化 | 不可信數(shù)據(jù)的凈化和校驗前翯進行規(guī)范化,如將目錄遍歷(./或)等相對路徑轉化成絕對路徑URL解碼等腰懂。 | |
| 凈化 | 不可信數(shù)據(jù)需實施各種凈化處理時,應徹底刪除惡意字符,只留下已知安全的字符,或者在處理前對它們進行適當編碼或"轉義",如數(shù)據(jù)輸出到應用頁面時對其進行HTML編碼可防止腳本攻擊 | |
| 合法性校驗 | 不可信數(shù)據(jù)的合法性校驗包括:數(shù)據(jù)類型如字符.數(shù)字、日期等特征;數(shù)據(jù)范國;數(shù)據(jù)長度等 | |
| 防范SQL注入 | 不可信數(shù)據(jù)進入后端數(shù)據(jù)庫操作前,建議使用正角的參數(shù)化查詢來處理,避免出現(xiàn)SQL注入 | |
| 文件校驗 | 不可信數(shù)據(jù)為解壓縮的文件時,如果文件位于服務目錄外或文件大小超過限制,應拒絕處理 | |
| 訪問控制 | 不可信數(shù)據(jù)通過上述校驗后,還應確認所提交的內容是否與用戶的身份匹配,避免越權訪問 | |
| 輸出驗證 | 概述 | 考慮目標編譯器的安全性项秉，對所有輸出字符進行正確編碼 |
| 編碼場景 | 不可信數(shù)據(jù)輸出到前后端頁面時,根據(jù)輸出場景對其進行相關編碼,如HTML實體編碼绣溜、UR編碼 | |
| 凈化場景 | 針對操作系統(tǒng)命令、SQL和LDAP查詢,凈化所有輸出的敏感信息,如銀行卡伙狐、手機號涮毫、系統(tǒng)信息等 | |
| 身份驗證 | 概述 | 所有對非公開的網頁和資源的訪問,必須在后端服務上執(zhí)行標準的瞬欧、通用的身份驗證過程 |
| 提交憑證 | 用戶憑據(jù)必須經過加密且以POST方式提交,建議用HTPS協(xié)議來加密通道贷屎、認證服務端 | |
| 錯誤提示 | 安全地處理失敗的身份校驗,如使用"用戶名或密碼錯誤"來提示失敗,防止泄露過多信息 | |
| 異常處理 | 登錄入口應具有防止暴力或撞庫猜解(利用已泄露的密碼字典進行批量登錄嘗試)的措施,超過1次驗證失敗自動啟用圖靈測試,超過多次驗證失敗自動啟用賬戶鎖定機制限制其訪問 | |
| 二次驗證 | 在執(zhí)行關鍵操作(如賬戶密碼修改罢防、資料更新、交易支付等)時,先啟動圖靈測試,再對用戶身份進行二次驗證唉侄。交易支付過程還應該形成完整的證據(jù)鏈,待交易數(shù)據(jù)應經過發(fā)起方數(shù)字簽名 | |
| 多因子驗證 | 高度敏感或核心的業(yè)務系統(tǒng),建議使用多因子身份驗證機制,如短信驗證碼咒吐、軟硬件 Token等。 | |
| 短信驗證 | 驗證碼生成 | 復雜度至少6位數(shù)字或字母,一次一用,建議有效期不超過180秒属划。 |
| 驗證碼限制 | 前后端設置用戶獲取頻率為60秒一次,建議每個用戶每天獲取的短信最多10條 | |
| 安全提示 | 增加安全提示:至少含本次操作的功能恬叹、驗證碼發(fā)送編號、是否是個人自己操作的風險等信息同眯。 | |
| 憑證校驗 | 禁止在響應中返回驗證碼,服務器端同時校驗密碼绽昼、短信驗證碼等憑證信息,防止出現(xiàn)多階段認證繞過的漏洞。 | |
| 圖靈測試 | 驗證碼生成 | 復雜度至少4位數(shù)字或字母,或者采用拼圖等驗證方式,一次一用,建議有效期不超過180秒 |
| 驗證碼使用 | 建議從用戶體驗和安全角度出發(fā),可設計為當用戶輸錯1次密碼后自動彈出驗證碼輸入框驗證 | |
| 驗證碼校驗 | 禁止在響應中返回驗證碼,驗證碼校驗應在服務端進行 | |
| 密碼管理 | 密碼設置 | 密碼設置時,應該滿足8位及以上長度,含大小寫字母须蜗、數(shù)字及特殊字符等的要求硅确。用戶密碼設置必須經過后端驗,不允許設置不滿定復雜度要求的感密碼。 |
| 密碼存儲 | 用戶密碼存儲時,應采用哈希算法(如SHA1)計算用戶密碼和唯一隨機鹽值(Salt)的摘要值保存其摘要和Sat值,建議分開存儲這兩個值 | |
| 密碼修改 | 用戶修改密碼時,修改操作需要通過手機號或者郵箱地均進行一次身份驗證明肮。密碼變更時,應短信或者郵件通知如用戶是否是本人操作,告知其安全風險 | |
| 密碼找回 | 用戶密碼找回時,后端需要對注冊手機號或郵箱進行二次驗證,驗證碼和驗證鏈接應發(fā)送至預先注冊的地址,并設置有效期以防止暴力破解菱农。密保問題,應當支持盡可能隨機的問題提問。在多個驗證操作中,要對各驗證機制進行排序,以防出現(xiàn)跳過前面驗證機制直接到最后步認證的安全風險 | |
| 密碼使用 | 應用開發(fā)中禁止設置萬能密碼柿估、硬編碼明文的密 碼循未、使用數(shù)據(jù)庫管理員賬戶操作、不同用戶公用賬 戶操作或者將密碼輸出到日志文件或者控制臺. | |
| 會話安全 | 防止會話劫持 | 在應用程序進行身份驗證時,建議持續(xù)使用HTTPS連接,認證站點使用HTTPS協(xié)議秫舌。如果連接是從防止會話劫持HTTP跳轉到HTTPS,需要重新生成會話標識符的妖。禁止在HTTP和HTTPS之間來回轉換,這可能會導致會話被劫持 |
| 會話標識符安全 | 設置會話 Cookie時,正確設置" Httponly'屬性(禁止程序加5腳本等讀取 Cookie信息)" Secure'屬性(禁Cookie安全設置止Cookie通過HTTP連接傳遞到服務器端進行驗證);" Domain"屬性(跨域訪問時可指定的授權訪問域名),"Path"屬性(授權可訪問的目錄路徑)。 | |
| Cookie安全設置 | 會話標識符應放置在HTP或HTPS協(xié)議的頭信息安全中,禁止以GET參數(shù)進行傳遞足陨、在錯誤信息和日志中記錄會話標識符 | |
| 防止CSRF攻擊 | 服務器端執(zhí)行了完整的會話管理機制,保證每個會防止CSRF話請求都執(zhí)行了合法的身份驗證和權限控制,防止攻擊發(fā)生跨站點請求偽造(CSRF)漏洞嫂粟。 | |
| 會話有效期 | 會話應在平衡風險和功能需求的基礎上設置有效期。定期生成一個新的會話標識符并使上一個會話會話有效期標識符失效,這可以緩解那些因原會活標識符被盜而產生的會話劫持風險钠右。 | |
| 會話注銷 | 注銷功能應用于所有受身份驗證保護的網頁,用戶會話注銷登出后應立即清理會話相關信息,終止相關的會話連接 | |
| 訪問控制 | 控制方法 | 將訪問控制的邏輯代碼與應用程序其他代碼分開服務端根據(jù)會話標識來進行訪問控制管理赋元。 |
| 控制管理 | 限制只有授權的用戶才能訪問受保護的URL、文件飒房、服務搁凸、應用數(shù)據(jù)、配置狠毯、直接對象引用等 | |
| 接口管理 | 限制只有授權的外部應用程序或接口才能訪問受保護的本地程序或資源等 | |
| 權限變更 | 當權限發(fā)生變更時,應記錄日志,并通知用戶是否是本人操作,告知存在的安全風險 | |
| SQL注入 | 概述 | 用戶的輸入進入應用程序的SQL操作前,對輸入進行合法性校驗护糖。 |
| 參數(shù)化處理 | 用參數(shù)化查詢(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter)方法對敏感字符如"進行轉義,然后再進行SQL操作。 | |
| 最小化授權 | 為每個應用配置最小化數(shù)據(jù)庫操作權限,禁止用管理員權限進行數(shù)據(jù)庫操作,限制操作連接數(shù)嚼松。 | |
| 敏感數(shù)據(jù)加密 | 敏感信息都采用了加密嫡良、哈厦谭觯或混淆等方式進行保密存儲,降低可能漏洞帶來的數(shù)據(jù)泄露風險. | |
| 禁止錯誤回顯 | 禁止系統(tǒng)開啟 Debug模式或異常時返回包含敏感信息的提示,建議使用自定義的錯誤信息模板異常信息應存放在日志中用于安全審計 | |
| XSS注入 | 輸入校驗 | 對輸入的數(shù)據(jù)進行過濾和轉義,包含但不限于<>"9%0&+\V"等危險特殊字符 |
| 輸出編碼 | 輸入數(shù)據(jù)輸出到不同場景中進行不同形式的編碼,如輸出到HTML標簽中則進行HTML編碼輸出到URL中則進行URL編碼,輸出到JS中則行 Script編碼,輸出到 Stylet中則進行CSs編碼 | |
| XML注入 | 輸入校驗 | 在XML文檔內部或外部引用數(shù)據(jù)時,過濾用戶提交的參數(shù),如<、>&等特殊字符寝受。禁止加載外部實體,禁止報錯 |
| 輸出編碼 | 建議對XML元素屬性或者內容進行輸出轉義 | |
| 敏感信息 | 敏感信息傳輸 | 敏感信息傳輸時,禁止在GET請求參數(shù)中包含敏感信息,如用戶名坷牛、密碼、卡號等很澄。建議為所有敏感信息采用TSL加密傳輸京闰。 |
| 客戶端保存 | 客戶端保存敏感信息時,禁止其表單中的自動填充功能、以明文形式保存敏感信息 | |
| 服務端保存 | 服務端保存敏感信息時,禁止在程序中硬編碼敏感信息,明文存儲用戶密碼甩苛、身份證號蹂楣、銀行卡號、持卡人姓名等敏感信息,臨時寫入內存或文件中的敏感數(shù)據(jù),應及時清除和釋放 | |
| 敏感信息維護 | 敏感信息維護時,禁止將源碼或SQL庫上傳到開源平臺或社區(qū),如 Github讯蒲、開源中國等痊土。 | |
| 敏感信息展示 | 敏感信息展示時,如果是展示在web頁面上,應在后端服務器上進行敏感字段的脫敏處理。 | |
| CSRF跨站請求偽造 | Token使用 | 在重要操作的表單中增加會話生成的 Token字段次一用,提交后在服務端校驗該字段 |
| 二次驗證 | 在關鍵表單提交時,要求用戶進行二次身份驗證如密碼墨林、圖片驗證碼赁酝、短信驗證碼等 | |
| Referer驗證 | 檢驗用戶請求中 Referer:字段是否存在跨域提交的情況 | |
| 文件上傳安全 | 身份校驗 | 進行文件上傳時,在服務端對用戶的身份進行合法性校驗 |
| 合法性校驗 | 進行文件上傳時,在服務端對文件屬性進行合法性校驗,白名單形式檢查文檔類型(如文件的后緩名、文件頭信息校驗等)和大小(圖片校驗長萌丈、寬和像素等)赞哗。 | |
| 存儲環(huán)境設置 | 進行文件保存時,保存在與應用環(huán)境獨立的文檔服務器中(配置獨立域名),保存的目錄權限應設置為不可執(zhí)行 | |
| 隱藏文件路徑 | 進行文件保存時,成功上傳的文件需要進行隨機化重命名,禁止給客戶端返回保存的路徑信息。 | |
| 文件訪問設置 | 進行文件下載時,應以二進制形式下載,建議不提供直接訪問(防止木馬文件直接執(zhí)行) | |
| 接口安全 | 網絡限制 | 調用方網絡限制,比如通過防火墻辆雾、主機host和Nginx deny等技術措施進行校驗肪笋。 |
| 身份認證 | 調用方身份認證,比如key、 secret度迂、證書等技術措施進行校驗,禁止共享憑證 | |
| 完整性校驗 | 調用的數(shù)據(jù)安全,對全部參數(shù)使用SHA1等摘要運算進行數(shù)字簽名,識別數(shù)據(jù)被篡改 | |
| 合法性校驗 | 調用的參數(shù)檢查,如參數(shù)是否完整,時間戳和Token是否有效,調用權限是否合法等 | |
| 可用性要求 | 調用的服務要求,調用滿足等冪性即保持數(shù)據(jù)一致性,對調用頻率和有效期進行限制 | |
| 異常處理 | 調用的異常處理,調用行為實時檢測,發(fā)現(xiàn)異常及時阻攔 | |
| I/O操作 | 共享環(huán)境文件安全 | 在多用戶系統(tǒng)中創(chuàng)建文件時應指定合適的訪問許可,以防止未授權的文件訪問,共享目錄中文件的讀/寫/可執(zhí)行權限應該使用白名單機制,實現(xiàn)最小化授權藤乙。 |
| 數(shù)據(jù)訪問檢查 | 防止封裝好的數(shù)據(jù)對象被未授權使用,設置合理的據(jù)緩存區(qū)大小以防止耗盡系統(tǒng)資源, | |
| 應用文件處理 | 應用程序運行過程中創(chuàng)建的文件,需設置問權限(讀、寫惭墓、可執(zhí)行),臨時文件使及時刪除 | |
| 運行環(huán)境 | 最小化開放端口 | 關閉操作系統(tǒng)不需要的端口和服務 |
| 后臺服務管理 | 后臺(如數(shù)據(jù)緩存和存儲坛梁、監(jiān)控、業(yè)務管理等)務限內部網絡訪問,開放在公網的必須設置身份驗證和訪問控制腊凶。 | |
| 環(huán)境配置 | 使用安全穩(wěn)定的操作系統(tǒng)版本划咐、Web股務器軟件各種應用框架、數(shù)據(jù)庫組件等 | |
| 敏感代碼處理 | 將客戶端敏感代碼(如軟件包簽名钧萍、用戶名密碼校驗等)都放在o等軟件包中防止篡改褐缠。 | |
| 關閉調試通道 | 生產代碼不包含任何調試代碼或接口 | |
| 通信安全 | 配置網站的HTTPS證書或其它加密傳輸措施。 | |
| 異常處理 | 容錯機制 | 在應用實現(xiàn)時應包含完整的功能異常捕獲機制如try-catch塊,典型位置:文件风瘦、網絡队魏、數(shù)據(jù)庫、命令操作等万搔。一旦出現(xiàn)異常,應該在日志中完整記錄異常的發(fā)生時間胡桨、代碼位置官帘、報錯詳情、觸發(fā)錯誤的可能用戶等,重要系統(tǒng)的嚴重異常應該有報警的機制,及時通知系統(tǒng)運營者及時排查并修復題 |
| 自定義錯誤信息 | 在生產環(huán)境下,應用程序不應在其響應中返回任何系統(tǒng)生成的消息或其他調試信息,配置應用服務器使其以自定義的方式處理無法處理的應用程序錯誤,返回自定義錯誤信息 | |
| 隱藏用戶信息 | 禁止在系統(tǒng)異常時泄露用戶的隱私信息,典型的有:身份信息昧谊、個人住址刽虹、電話號碼、銀行賬號、通訊記錄砍鸠、定位信息等 | |
| 隱藏系統(tǒng)信息 | 禁止在系統(tǒng)異常時泄露系統(tǒng)的敏感信息(用戶賬戶和密碼、系統(tǒng)開發(fā)密鑰、系統(tǒng)源代碼知押、應用架構、系統(tǒng)賬戶和密碼溪椎、網絡拓撲等)氛改。 | |
| 異常狀態(tài)恢復 | 方法發(fā)生異常時要恢復到之前的對象狀態(tài),如業(yè)務操作失敗時的回滾操作等,對象修改失敗時要恢復對象原來的狀態(tài),維持對象狀態(tài)的一致性 | |
| 日志規(guī)范 | 記錄原則 | 確保日志記錄包含了重要的應用事件,但禁止保存敏感信息,如會話標識,賬戶密碼、證件等 |
| 事件類型 | 記錄所有的身份驗證撩独、訪問操作敞曹、數(shù)據(jù)變更、關鍵操作综膀、管理功能澳迫、登出記錄等事件。 | |
| 事件要求 | 日志一般會記錄每個事件的發(fā)生時間剧劝、發(fā)出請求的IP地址和用戶賬戶(如果已通過驗證)橄登。 | |
| 日志保護 | 日志受到嚴格保護,避免未授權的讀取或寫入訪問。 |
三讥此、圖書推薦
如果對筆者的文章較為感興趣拢锹，可以關注筆者新書《PHP Web安全開發(fā)實戰(zhàn)》，現(xiàn)已在各大平臺上架銷售萄喳，封面如下圖所示
19.png
作者：湯青松
日期：2018-11-13
微信：songboy8888
