1、背景
團隊最近頻繁遭受網絡攻擊,引發了部門技術負責人的重視,筆者在團隊中相對來講更懂安全,所以花了點時間編輯了一份安全開發自檢清單,以爲應該也有很多讀者有須要,因此將其分享出來。web
2、編碼安全
2.1 輸入驗證
說明 |
檢查項 |
概述 |
任何來自客戶端的數據,如URL和參數、HTTP頭部、 Javascript戓其餘嵌入代碼提交的信息,都屬於不可信數據。在應用外部邊界或內部每一個組件或功能邊界,都將其當作潛在的惡意輸入來校驗 |
白名單 |
不可信數據能夠設定白名單校驗的,應接受全部和白名單匹配的數據,並阻止其餘數據 |
黑名單 |
不可信數據中包含不良輸入字符時,如空字節(%00)、換行符(%0d,%0a,\r, \n)、路徑字符(../ 或 ..)等,建議直接阻止該數據,若須要接受該數據,則應作不一樣方式的淨化處理 |
規範化 |
不可信數據的淨化和校驗前翯進行規範化,如將目錄遍歷(./或)等相對路徑轉化成絕對路徑URL解碼等。 |
淨化 |
不可信數據需實施各類淨化處理時,應完全刪除惡意字符,只留下已知安全的字符,或者在處理前對它們進行適當編碼或"轉義",如數據輸出到應用頁面時對其進行HTML編碼可防止腳本攻擊 |
合法性校驗 |
不可信數據的合法性校驗包括:數據類型如字符.數字、日期等特徵;數據範國;數據長度等 |
防範SQL注入 |
不可信數據進入後端數據庫操做前,建議使用正角的參數化查詢來處理,避免出現SQL注入 |
文件校驗 |
不可信數據爲解壓縮的文件時,若是文件位於服務目錄外或文件大小超過限制,應拒絕處理 |
訪問控制 |
不可信數據經過上述校驗後,還應確認所提交的內容是否與用戶的身份匹配,避免越權訪問 |
2.2 輸出驗證
說明 |
檢查項 |
概述 |
考慮目標編譯器的安全性,對全部輸出字符進行正確編碼 |
編碼場景 |
不可信數據輸出到先後端頁面時,根據輸出場景對其進行相關編碼,如HTML實體編碼、UR編碼 |
淨化場景 |
針對操做系統命令、SQL和LDAP查詢,淨化全部輸出的敏感信息,如銀行卡、手機號、系統信息等 |
2.3 SQL注入
說明 |
檢查項 |
概述 |
用戶的輸入進入應用程序的SQL操做前,對輸入進行合法性校驗。 |
參數化處理 |
用參數化查詢(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter)方法對敏感字符如"進行轉義,而後再進行SQL操做。 |
最小化受權 |
爲每一個應用配置最小化數據庫操做權限,禁止用管理員權限進行數據庫操做,限制操做鏈接數。 |
敏感數據加密 |
敏感信息都採用了加密、哈希或混淆等方式進行保密存儲,下降可能漏洞帶來的數據泄露風險. |
禁止錯誤回顯 |
禁止系統開啓 Debug模式或異常時返回包含敏感信息的提示,建議使用自定義的錯誤信息模板異常信息應存放在日誌中用於安全審計 |
2.4 XSS跨站
說明 |
檢查項 |
輸入校驗 |
對輸入的數據進行過濾和轉義,包含但不限於<>"9%0&+\V"等危險特殊字符 |
輸出編碼 |
輸入數據輸出到不一樣場景中進行不一樣形式的編碼,如輸出到HTML標籤中則進行HTML編碼輸出到URL中則進行URL編碼,輸出到JS中則行 Script編碼,輸出到 Stylet中則進行CSs編碼 |
2.5 XML注入
說明 |
檢查項 |
輸入校驗 |
在XML文檔內部或外部引用數據時,過濾用戶提交的參數,如<、>&等特殊字符。禁止加載外部實體,禁止報錯 |
輸出編碼 |
建議對XML元素屬性或者內容進行輸出轉義 |
2.6 CSRF跨站請求僞造
說明 |
檢查項 |
Token使用 |
在重要操做的表單中增長會話生成的 Token字段次一用,提交後在服務端校驗該字段 |
二次驗證 |
在關鍵表單提交時,要求用戶進行二次身份驗證如密碼、圖片驗證碼、短信驗證碼等 |
Referer驗證 |
檢驗用戶請求中 Referer:字段是否存在跨域提交的狀況 |
3、邏輯安全
3.1 身份驗證
說明 |
檢查項 |
概述 |
全部對非公開的網頁和資源的訪問,必須在後端服務上執行標準的、通用的身份驗證過程 |
提交憑證 |
用戶憑據必須通過加密且以POST方式提交,建議用HTPS協議來加密通道、認證服務端 |
錯誤提示 |
安全地處理失敗的身份校驗,如使用"用戶名或密碼錯誤"來提示失敗,防止泄露過多信息 |
異常處理 |
登陸入口應具備防止暴力或撞庫猜解(利用已泄露的密碼字典進行批量登陸嘗試)的措施,超過1次驗證失敗自動啓用圖靈測試,超過屢次驗證失敗自動啓用帳戶鎖定機制限制其訪問 |
二次驗證 |
在執行關鍵操做(如帳戶密碼修改、資料更新、交易支付等)時,先啓動圖靈測試,再對用戶身份進行二次驗證。交易支付過程還應該造成完整的證據鏈,待交易數據應通過發起方數字簽名 |
多因子驗證 |
高度敏感或核心的業務系統,建議使用多因子身份驗證機制,如短信驗證碼、軟硬件 Token等。 |
3.2 短信驗證
說明 |
檢查項 |
驗證碼生成 |
複雜度至少6位數字或字母,一次一用,建議有效期不超過180秒。 |
驗證碼限制 |
先後端設置用戶獲取頻率爲60秒一次,建議每一個用戶天天獲取的短信最多10條 |
安全提示 |
增長安全提示:至少含本次操做的功能、驗證碼發送編號、是不是我的本身操做的風險等信息。 |
憑證校驗 |
禁止在響應中返回驗證碼,服務器端同時校驗密碼、短信驗證碼等憑證信息,防止出現多階段認證繞過的漏洞。 |
3.3 圖靈測試
說明 |
檢查項 |
驗證碼生成 |
複雜度至少4位數字或字母,或者採用拼圖等驗證方式,一次一用,建議有效期不超過180秒 |
驗證碼使用 |
建議從用戶體驗和安全角度出發,可設計爲當用戶輸錯1次密碼後自動彈出驗證碼輸入框驗證 |
驗證碼校驗 |
禁止在響應中返回驗證碼,驗證碼校驗應在服務端進行 |
3.4 密碼管理
說明 |
檢查項 |
密碼設置 |
密碼設置時,應該知足8位及以上長度,含大小寫字母、數字及特殊字符等的要求。用戶密碼設置必須通過後端驗,不容許設置不滿定複雜度要求的感密碼。 |
密碼存儲 |
用戶密碼存儲時,應採用哈希算法(如SHA1)計算用戶密碼和惟一隨機鹽值(Salt)的摘要值保存其摘要和Sat值,建議分開存儲這兩個值 |
密碼修改 |
用戶修改密碼時,修改操做須要經過手機號或者郵箱地均進行一次身份驗證。密碼變動時,應短信或者郵件通知如用戶是不是本人操做,告知其安全風險 |
密碼找回 |
用戶密碼找回時,後端須要對註冊手機號或郵箱進行二次驗證,驗證碼和驗證連接應發送至預先註冊的地址,並設置有效期以防止暴力破解。密保問題,應當支持儘量隨機的問題提問。在多個驗證操做中,要對各驗證機制進行排序,以防出現跳過前面驗證機制直接到最後步認證的安全風險 |
密碼使用 |
應用開發中禁止設置萬能密碼、硬編碼明文的密 碼、使用數據庫管理員帳戶操做、不一樣用戶公用帳 戶操做或者將密碼輸出到日誌文件或者控制檯. |
3.5 會話安全
說明 |
檢查項 |
防止會話劫持 |
在應用程序進行身份驗證時,建議持續使用HTTPS鏈接,認證站點使用HTTPS協議。若是鏈接是從防止會話劫持HTTP跳轉到HTTPS,須要從新生成會話標識符。禁止在HTTP和HTTPS之間來回轉換,這可能會致使會話被劫持 |
會話標識符安全 |
設置會話 Cookie時,正確設置" Httponly'屬性(禁止程序加5腳本等讀取 Cookie信息)" Secure'屬性(禁Cookie安全設置止Cookie經過HTTP鏈接傳遞到服務器端進行驗證);" Domain"屬性(跨域訪問時可指定的受權訪問域名),"Path"屬性(受權可訪問的目錄路徑)。 |
Cookie安全設置 |
會話標識符應放置在HTP或HTPS協議的頭信息安全中,禁止以GET參數進行傳遞、在錯誤信息和日誌中記錄會話標識符 |
防止CSRF攻擊 |
服務器端執行了完整的會話管理機制,保證每一個會防止CSRF話請求都執行了合法的身份驗證和權限控制,防止攻擊發生跨站點請求僞造(CSRF)漏洞。 |
會話有效期 |
會話應在平衡風險和功能需求的基礎上設置有效期。按期生成一個新的會話標識符並使上一個會話會話有效期標識符失效,這能夠緩解那些因原會活標識符被盜而產生的會話劫持風險。 |
會話註銷 |
註銷功能應用於全部受身份驗證保護的網頁,用戶會話註銷登出後應當即清理會話相關信息,終止相關的會話鏈接 |
3.6 訪問控制
說明 |
檢查項 |
控制方法 |
將訪問控制的邏輯代碼與應用程序其餘代碼分開服務端根據會話標識來進行訪問控制管理。 |
控制管理 |
限制只有受權的用戶才能訪問受保護的URL、文件、服務、應用數據、配置、直接對象引用等 |
接口管理 |
限制只有受權的外部應用程序或接口才能訪問受保護的本地程序或資源等 |
權限變動 |
當權限發生變動時,應記錄日誌,並通知用戶是不是本人操做,告知存在的安全風險 |
3.7 文件上傳安全
說明 |
檢查項 |
身份校驗 |
進行文件上傳時,在服務端對用戶的身份進行合法性校驗 |
合法性校驗 |
進行文件上傳時,在服務端對文件屬性進行合法性校驗,白名單形式檢查文檔類型(如文件的後緩名、文件頭信息校驗等)和大小(圖片校驗長、寬和像素等)。 |
存儲環境設置 |
進行文件保存時,保存在與應用環境獨立的文檔服務器中(配置獨立域名),保存的目錄權限應設置爲不可執行 |
隱藏文件路徑 |
進行文件保存時,成功上傳的文件須要進行隨機化重命名,禁止給客戶端返回保存的路徑信息。 |
文件訪問設置 |
進行文件下載時,應以二進制形式下載,建議不提供直接訪問(防止木馬文件直接執行) |
3.8 接口安全
說明 |
檢查項 |
網絡限制 |
調用方網絡限制,好比經過防火牆、主機host和Nginx deny等技術措施進行校驗。 |
身份認證 |
調用方身份認證,好比key、 secret、證書等技術措施進行校驗,禁止共享憑證 |
完整性校驗 |
調用的數據安全,對所有參數使用SHA1等摘要運算進行數字簽名,識別數據被篡改 |
合法性校驗 |
調用的參數檢查,如參數是否完整,時間戳和Token是否有效,調用權限是否合法等 |
可用性要求 |
調用的服務要求,調用知足等冪性即保持數據一致性,對調用頻率和有效期進行限制 |
異常處理 |
調用的異常處理,調用行爲實時檢測,發現異常及時阻攔 |
4、數據安全
4.1 敏感信息
說明 |
檢查項 |
敏感信息傳輸 |
敏感信息傳輸時,禁止在GET請求參數中包含敏感信息,如用戶名、密碼、卡號等。建議爲全部敏感信息採用TSL加密傳輸。 |
客戶端保存 |
客戶端保存敏感信息時,禁止其表單中的自動填充功能、以明文形式保存敏感信息 |
服務端保存 |
服務端保存敏感信息時,禁止在程序中硬編碼敏感信息,明文存儲用戶密碼、身份證號、銀行卡號、持卡人姓名等敏感信息,臨時寫入內存或文件中的敏感數據,應及時清除和釋放 |
敏感信息維護 |
敏感信息維護時,禁止將源碼或SQL庫上傳到開源平臺或社區,如 Github、開源中國等。 |
敏感信息展現 |
敏感信息展現時,若是是展現在web頁面上,應在後端服務器上進行敏感字段的脫敏處理。 |
4.2 日誌規範
說明 |
檢查項 |
記錄原則 |
確保日誌記錄包含了重要的應用事件,但禁止保存敏感信息,如會話標識,帳戶密碼、證件等 |
事件類型 |
記錄全部的身份驗證、訪問操做、數據變動、關鍵操做、管理功能、登出記錄等事件。 |
事件要求 |
日誌通常會記錄每一個事件的發生時間、發出請求的IP地址和用戶帳戶(若是已經過驗證)。 |
日誌保護 |
日誌受到嚴格保護,避免未受權的讀取或寫入訪問。 |
4.3 異常處理
說明 |
檢查項 |
容錯機制 |
在應用實現時應包含完整的功能異常捕獲機制如try-catch塊,典型位置:文件、網絡、數據庫、命令操做等。一旦出現異常,應該在日誌中完整記錄異常的發生時間、代碼位置、報錯詳情、觸發錯誤的可能用戶等,重要系統的嚴重異常應該有報警的機制,及時通知系統運營者及時排查並修復題 |
自定義錯誤信息 |
在生產環境下,應用程序不該在其響應中返回任何系統生成的消息或其餘調試信息,配置應用服務器使其以自定義的方式處理沒法處理的應用程序錯誤,返回自定義錯誤信息 |
隱藏用戶信息 |
禁止在系統異常時泄露用戶的隱私信息,典型的有:身份信息、我的住址、電話號碼、銀行帳號、通信記錄、定位信息等 |
隱藏系統信息 |
禁止在系統異常時泄露系統的敏感信息(用戶帳戶和密碼、系統開發密鑰、系統源代碼、應用架構、系統帳戶和密碼、網絡拓撲等)。 |
異常狀態恢復 |
方法發生異常時要恢復到以前的對象狀態,如業務操做失敗時的回滾操做等,對象修改失敗時要恢復對象原來的狀態,維持對象狀態的一致性 |
5、主機安全
5.1 I/O操做
說明 |
檢查項 |
共享環境文件安全 |
在多用戶系統中建立文件時應指定合適的訪問許可,以防止未受權的文件訪問,共享目錄中文件的讀/寫/可執行權限應該使用白名單機制,實現最小化受權。 |
數據訪問檢查 |
防止封裝好的數據對象被未受權使用,設置合理的據緩存區大小以防止耗盡系統資源, |
應用文件處理 |
應用程序運行過程當中建立的文件,需設置問權限(讀、寫、可執行),臨時文件使及時刪除 |
5.2 運行環境
說明 |
檢查項 |
最小化開放端口 |
關閉操做系統不須要的端口和服務 |
後臺服務管理 |
後臺(如數據緩存和存儲、監控、業務管理等)務限內部網絡訪問,開放在公網的必須設置身份驗證和訪問控制。 |
環境配置 |
使用安全穩定的操做系統版本、Web股務器軟件各類應用框架、數據庫組件等 |
敏感代碼處理 |
將客戶端敏感代碼(如軟件包簽名、用戶名密碼校驗等)都放在o等軟件包中防止篡改。 |
關閉調試通道 |
生產代碼不包含任何調試代碼或接口 |
通訊安全 |
配置網站的HTTPS證書或其它加密傳輸措施。 |
6、圖書推薦
若是對筆者的文章較爲感興趣,能夠關注筆者新書《PHP Web安全開發實戰》,現已在各大平臺上架銷售,封面以下圖所示算法
做者:湯青松數據庫
日期:2018-11-13後端
微信:songboy8888跨域