前言部分
shell語言編程規範安全篇是針對bash語言編程中的數據校驗、加密與解密、腳本執行、目錄&文件操作等方面，描述可能導致安全漏洞或風險的常見編碼錯誤。該規範基於業界最佳實踐，並總結了公司內部的編程實踐。該規範旨在減少SQL注入、敏感信息洩露、環境變量攻擊、臨時文件攻擊、社會工程學等方面的安全問題發生。
使用對象
本規範的讀者及使用對象主要為使用bash腳本的研發人員和測試人員等
適用範圍
該規範適用於基於bash腳本的產品開發
術語定義
規則：編程時必須遵守的約定
建議：編程時加以考慮的約定
說明：某個規則的具體解釋
錯誤示例：對此規則/建議從反面給出例子
推薦做法：對此規則/建議從正面給出例子或建議
例外情況：相應規則不使用的場景
信任邊界：位於信任邊界之內的所有組件都是被系統本身直接控制的，所有來自不受控的外部系統的連接與數據，包括客戶端與第三方系統，都應該被認為是不可信的，要先在邊界處對其校驗，才能允許進一步與本系統交互。
非信任代碼：非產品包中的代碼，如通過網絡下載到本地虛擬機中加載並執行的代碼。
通用原則
規則1：校驗跨信任邊界傳遞的不可信數據
說明：軟件最為普遍的缺陷就是沒有對來自外部環境（系統/程序信任域之外）的數據進行合法性校驗，校驗缺失可導致系統的各種缺陷，比如DOS、SQL注入等，所以對於來自外部環境的輸入，默認為不可信，需要執行合法性校驗，校驗必須在信任邊界以內進行（比如對於web應用，需要服務端做校驗）。不可信數據可能來自（包括但不侷限與）：用戶輸入、外部接口輸入、配置文件、網絡數據、環境變量。
數據校驗可以參考如下幾種策略（包括但不限於）：
1).接受已知好的數據：該策略被稱為白名單或者正向校驗，重點檢查數據是否屬於一個可接受的數據集合。如下代碼用於確保name參數只包含字母、數字以及下劃線且必須以字母開頭：
check
2).拒絕已知壞的數據：該策略被稱為黑名單或者負向校驗，相對於正向校驗，是一種較弱的校驗方式，這種策略存在缺陷，因為潛在的壞數據可能是一個無限集合，採用這種策略意味著必須維護一個系統不可接受的列表（如字符或模式），否則列表中的信息會很快過時，系統安全性會降低。
3).白名單方式淨化：刪除、編碼或者替換系統不能接受的字符/數據，就是系統只接受某個確定的數據列表，比如期望接收一個電話號碼，則可以剔除輸入數據中所有非數字字符。
4).黑名單方式淨化：為確保輸入數據安全，剔除某些字符或轉換某些字符，跟黑名單校驗類似，該策略需要持續維護，且黑名單通常也不全面，因為大部分輸入域有其特殊的業務或格式要求，對比對應於當前和未來所有攻擊方式而使用的一個複雜、遲鈍的校驗程序，針對正確輸入的正向校驗顯得更為簡單、高效。
錯誤示例1：環境變量容易被篡改，如果腳本中使用系統環境變量，建議優先使用系統命令取值，如下代碼中，直接使用環境變量USER判斷當前用戶是否為root用戶，如果該環境變量USER被人篡改，會得到非預期的結果。
check
推薦做法：使用id -un命令可以準確安全地判斷當前用戶，如下：
check
規則2 禁止直接使用不可信數據來拼接SQL語句
說明：SQL注入是指原始SQL操作被動態更改成一個與程序預期完全不同的操作，執行更改後SQL可能導致信息洩露或者數據被篡改。防止SQL注入主要需對不可信數據進行校驗，推薦對不可信數據做如下校驗以防SQL注入：
對於字符型字段，需要對數據做轉義
1).將單引號替換為兩個單引號
2).如果字符類型輸入數據作為SQL語句中like部分，需要參考後面的附錄A做轉義。
3).系統根據具體業務場景，確定需要校驗的特殊字符，特殊字符可以參考附錄A和附錄B
對於整型字段，需要對輸入數據進行類型校驗，拒絕傳入不合法數字。
錯誤示例1：該例子中直接使用輸入數據拼接SQL語句，沒有對輸入數據做校驗，存在SQL注入風險。當username輸入值為tom'OR '1' = '1'的時候，SQL語句變成了"SELECT * FROM db_user WHERE username = 'tom OR '1' = '1' AND password = '${pvalue}'" ，這樣就繞開了對口令的驗證。
get
推薦做法：
get
規則3 禁止在界面或日誌中輸出敏感信息
說明：敏感數據的範圍應該基於系統場景以及威脅分析的結果來確定，典型的銘感數據包括口令、銀行賬號、個人信息、通訊記錄、秘鑰等，如果shell腳本中往界面或日誌中輸出敏感信息，都可能會有助於攻擊者嘗試發起進一步的攻擊，因此shell腳本中禁止往界面或日誌中輸出敏感信息，避免被攻擊者所獲取並利用。敏感信息舉例（包括但不限於）：
1).口令與秘鑰：口令包括口令明文和口令密文。
2).環境變量：命令set、env、declear、export以及typeset會把操作系統的環境變量顯示出來，其中可能會存在關鍵信息。
3).產品相關信息：產品License、日誌中如password、passwd等關鍵字信息。
對敏感信息建議採取以下措施：
1).不輸出到界面或日誌中
2).若特殊原因必須要輸出到界面或日誌，則使用*號代替，並且不顯示敏感信息的長度。
錯誤示例1：該例子中，功能實現時為方便定位問題，在日誌和界面上輸出了詳細信息，其中包括了數據庫密碼，存在被利用的風險。
db
推薦做法：不將敏感信息輸出到界面以及日誌中，避免被利用。
db
錯誤示例2：如下示例中，如果環境變量plvaule為關鍵信息，如下
env
而腳本如下，會將環境變量輸出至日誌及界面，存在信息洩露風險。
env
推薦做法：禁止在shell腳本中把set、env、declare、export及typeset命令的回顯打印到日誌及界面上。
例外情況：可以將命令執行結果賦值給一個變量，但需要保證該變量不輸出到日誌和界面，如下所示：
env
規則4 禁止在shell腳本中保留敏感信息
說明：敏感數據的範圍應該基於應用場景以及產品威脅分析的結果來確定，shell腳本在產品發佈版本中以文本方式存在，如果腳本中包含敏感信息，可能會被惡意利用造成安全隱患，比如腳本中註釋中包含員工的個人信息，雖然不違反安全紅線，但是帶有員工個人信息的註釋可能會洩露具體的開發人員信息，從而引入社會工程學方面的風險，因此要從腳本註釋中刪除員工個人信息。
腳本中敏感信息包括（但不限於）：
1).用戶名、密鑰、密碼明文和密文：如果腳本中存在這類信息，一旦洩露，與其相關的數據的機密性將受到嚴重的影響，因此不能在腳本中體現出來。
2).公司內部信息：如代碼作者的工號、姓名、聯繫方式等
錯誤示例1：如下代碼中，硬編碼了默認的用戶名和密碼，在執行時會導致用戶名和密碼這類敏感信息很容易洩露出來。
input
推薦做法：shell腳本里面禁止硬編碼密碼等敏感信息，需要密碼時通過手工輸入，如下：
input
例外情況：在系統初始化安裝的shell腳本中可以使用默認的用戶名和密碼密文，但是需要在調測及管理員操作指南中提醒用戶及時修改缺省密碼。
錯誤示例2：該例子中，發佈版本中的shell腳本中包含了公司內部信息，可能導致社會工程學方面的風險。
info
推薦做法：把腳本中的開發人員個人信息清除掉。
規則5 禁止在PATH環境變量中使用相對路徑
說明：環境變量攻擊是用來操控腳本行為的最常見的方式，通過修改環境變量攻擊者可以改變一個依賴環境變量值的腳本的執行過程或執行結果。其中最常被修改的環境變量是PATH，該變量值的路徑集決定了用戶在執行不包含完整路徑的單獨命令時，查找該命令的路徑及路徑查找先後順序。
假設PATH變量的內容是：/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin,
正常情況下命令會順序在/usr/local/sbin、/usr/local/bin、/usr/sbin、/usr/bin中查找並執行，如果PATH環境變量內容設置不當，存在如"."這樣的相對路徑，攻擊者可以在當前目錄下創建與系統命令同名的惡意程序或者腳本，當用戶執行該命令是，就會觸發執行惡意程序，導致惡意攻擊。
防護措施：PATH環境變量中必須使用絕對路徑，或者直接使用絕對路徑命令進行操作。
May you share freely, never taking more than you give.
願你寬心與人分享，所取不多於你所施與。
閱讀更多 雲中牧歌 的文章
