【轉】全面的告訴你專案的安全性控制需要考慮的方面
一、背景
團隊最近頻繁遭受網路攻擊,引起了技術負責人的重視,筆者在團隊中相對來說更懂安全,因此花了點時間編輯了一份安全開發自檢清單,覺得應該也有不少讀者有需要,所以將其分享出來。
二、編碼安全
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.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.1 敏感資訊
說明 |
檢查項 |
敏感資訊傳輸 |
敏感資訊傳輸時,禁止在GET請求引數中包含敏感資訊,如使用者名稱、密碼、卡號等。建議為所有敏感資訊採用TSL加密傳輸。 |
客戶端儲存 |
客戶端儲存敏感資訊時,禁止其表單中的自動填充功能、以明文形式儲存敏感資訊 |
服務端儲存 |
服務端儲存敏感資訊時,禁止在程式中硬編碼敏感資訊,明文儲存使用者密碼、身份證號、銀行卡號、持卡人姓名等敏感資訊,臨時寫入記憶體或檔案中的敏感資料,應及時清除和釋放 |
敏感資訊維護 |
敏感資訊維護時,禁止將原始碼或SQL庫上傳到開源平臺或社群,如 Github、開源中國等。 |
敏感資訊展示 |
敏感資訊展示時,如果是展示在web頁面上,應在後端伺服器上進行敏感欄位的脫敏處理。 |
4.2 日誌規範
說明 |
檢查項 |
記錄原則 |
確保日誌記錄包含了重要的應用事件,但禁止儲存敏感資訊,如會話標識,賬戶密碼、證件等 |
事件型別 |
記錄所有的身份驗證、訪問操作、資料變更、關鍵操作、管理功能、登出記錄等事件。 |
事件要求 |
日誌一般會記錄每個事件的發生時間、發出請求的IP地址和使用者賬戶(如果已通過驗證)。 |
日誌保護 |
日誌受到嚴格保護,避免未授權的讀取或寫入訪問。 |
4.3 異常處理
說明 |
檢查項 |
容錯機制 |
在應用實現時應包含完整的功能異常捕獲機制如try-catch塊,典型位置:檔案、網路、資料庫、命令操作等。一旦出現異常,應該在日誌中完整記錄異常的發生時間、程式碼位置、報錯詳情、觸發錯誤的可能使用者等,重要系統的嚴重異常應該有報警的機制,及時通知系統運營者及時排查並修復題 |
自定義錯誤資訊 |
在生產環境下,應用程式不應在其響應中返回任何系統生成的訊息或其他除錯資訊,配置應用伺服器使其以自定義的方式處理無法處理的應用程式錯誤,返回自定義錯誤資訊 |
隱藏使用者資訊 |
禁止在系統異常時洩露使用者的隱私資訊,典型的有:身份資訊、個人住址、電話號碼、銀行賬號、通訊記錄、定位資訊等 |
隱藏系統資訊 |
禁止在系統異常時洩露系統的敏感資訊(使用者賬戶和密碼、系統開發金鑰、系統原始碼、應用架構、系統賬戶和密碼、網路拓撲等)。 |
異常狀態恢復 |
方法發生異常時要恢復到之前的物件狀態,如業務操作失敗時的回滾操作等,物件修改失敗時要恢復物件原來的狀態,維持物件狀態的一致性 |
五、主機安全
5.1 I/O操作
說明 |
檢查項 |
共享環境檔案安全 |
在多使用者系統中建立檔案時應指定合適的訪問許可,以防止未授權的檔案訪問,共享目錄中檔案的讀/寫/可執行許可權應該使用白名單機制,實現最小化授權。 |
資料訪問檢查 |
防止封裝好的資料物件被未授權使用,設定合理的據快取區大小以防止耗盡系統資源, |
應用檔案處理 |
應用程式執行過程中建立的檔案,需設定問許可權(讀、寫、可執行),臨時檔案使及時刪除 |
5.2 執行環境
說明 |
檢查項 |
最小化開放埠 |
關閉作業系統不需要的埠和服務 |
後臺服務管理 |
後臺(如資料快取和儲存、監控、業務管理等)務限內部網路訪問,開放在公網的必須設定身份驗證和訪問控制。 |
環境配置 |
使用安全穩定的作業系統版本、Web股務器軟體各種應用框架、資料庫元件等 |
敏感程式碼處理 |
將客戶端敏感程式碼(如軟體包簽名、使用者名稱密碼校驗等)都放在o等軟體包中防止篡改。 |
關閉除錯通道 |
生產程式碼不包含任何除錯程式碼或介面 |
通訊安全 |
配置網站的HTTPS證照或其它加密傳輸措施。 |
form : 安全大佬部落格:https://segmentfault.com/a/1190000017090860
相關文章
- 管理專案風險:考慮你的專案可能出現的問題
- 建設智慧城市,需要從哪幾方面考慮?
- 農耕博物館設計需要考慮那些方面?
- 大資料安全保護,需要考慮哪幾方面?大資料
- CODING 告訴你矽谷專案經理的專案管理之道(2)專案管理
- 《街霸:對決》的陣容搭配方面,你要考慮這些
- 你的專案剛剛啟動?是時候考慮Globalization了!
- PHP的垃圾回收機制-效能方面考慮的因素PHP
- 讓你手寫一個reset的檔案,你應該怎麼寫?要考慮哪些方面呢?
- 在IT專案中運用FMEA,是否需要考慮客戶的需求和反饋?
- CODING 告訴你矽谷的研發專案管理之道(4)專案管理
- CODING 告訴你矽谷的研發專案管理之道(3)專案管理
- 開發高品質的數字貨幣交易所需要考慮哪些方面?
- 成功的專案管理需要做好哪些方面?專案管理
- 我考慮的是來看考慮考慮勞福德
- 在日本考慮投放電視廣告之前,你需要了解一下當地的情況
- 分散式檔案系統設計,該從哪些方面考慮?分散式
- 2.5.11.2 FORCE LOGGING 模式需要考慮的效能問題模式
- 我來告訴你,ChatGPT 該怎麼對接到自己的專案中!ChatGPT
- 要你做一個國外的web頁面,你需要考慮哪些問題?Web
- 偷偷告訴你,HR更喜歡這樣的專案經理的簡歷!
- 專案中對外暴露的http介面的安全性如何保證HTTP
- 碼教授告訴你SEM最佳化師需要掌握的技巧
- 在技術上你有獨當一面的能力,還需要哪些方面的能力
- JVM筆記--如果你寫JVM,最需要考慮的重要結構是什麼?JVM筆記
- 替代 VMware ,為什麼需要重新考慮您的儲存?
- 遊戲開服導量,需要考慮的三大需求遊戲
- 選型招聘系統需要考慮的幾個要點
- 如果你的系統需要在一張很大的表上建立一個索引,你會考慮哪些因素?索引
- 一個澳洲大學IT類碩士專業的,有關資料庫方面的考試題資料庫
- 挑選合適的電話機器人要從哪些方面考慮?機器人
- 【轉】kafka-告訴你什麼是kafkaKafka
- 選擇 NoSQL 資料庫需要考慮的 10 個問題SQL資料庫
- 2023 年 MQTT Broker 選型時需要考慮的 7 個因素MQQT
- 好的精益工廠佈局需要考慮哪些問題?
- 【知識分享】多ip伺服器的租用需要考慮哪些伺服器
- 公交地鐵出行的場景,需要考慮那些測試點
- 2年經驗總結,告訴你如何做好專案管理專案管理