支付寶——開放平臺第三方應用安全開發指南
《開放平臺第三方應用安全開發指南》給出常見開發場景下，幫助開發人員完善應用安全性的開發建議，同時也對常見的安全漏洞進行描述，並提供對應的修復方案。
1. 常見開發場景安全開發指南
1.1. 敏感資訊使用場景
敏感資訊指使用者的 身份證號、銀行卡號、手機號 等身份資訊。重要敏感資訊的脫敏規範如下。
| 敏感資訊型別 | 展示規範 |
|---|---|
| 身份證 | 顯示前 1 位 + *(實際位數) + 後 1 位，如： 3****************3 |
| 銀行卡 | 顯示前 6 位 + *(實際位數) + 後 4 位，如：622575******1496 |
| 手機號 | 顯示前 3 位 + **** + 後 2 位，如：137******50 |
1.1.1. 敏感資訊用於展示的場景
- 原則：敏感資訊的展示請嚴格按照脫敏規範進行脫敏
- 說明：脫敏的邏輯必須在服務端完成，不能使用 Javascript 在客戶端進行脫敏，包括程式碼註釋、隱藏域、url 引數、cookies 等處的資料也必須脫敏。
- 說明：不能使用可逆的編碼/加密方式，如 base64 編碼等代替脫敏規範。
- 說明：若敏感資訊明文展示在應用中，沒有按照脫敏規範完成脫敏。支付寶開放平臺將有權暫停敏感資料相關介面的開放。
1.1.2. 敏感資訊用於身份校驗的場景
- 原則：不要直接將敏感資訊的明文資訊在客戶端與服務端之間傳遞
- 說明：可以將敏感資訊在服務端關聯到使用者標識 ID，在客戶端儲存使用者標識 ID 並提交到服務端，服務端根據 ID 取出對應資訊後進行校驗。
1.2. HTML 頁面渲染
- 原則：所有在頁面渲染的敏感資料 (身份證、銀行卡號、手機號) 必須進行脫敏
- 原則：禁止向 HTML 頁面輸出未經安全過濾或未正確轉義的使用者資料
- 說明：使用者資料不僅僅包括使用者正常資料，同時包括攻擊者可修改，偽造的其他資料。
- 原則：HTML 頁面動態輸出 JSON、JavaScript 必須對其中的字串值做 XSS 防禦處理
- 原則：預設設定 HTTP Header 中的
HttpOnly屬性為 true- 說明：設定
HttpOnly為 true，將可以禁止 JavaScript 讀取頁面 Cookie 資訊，一定程度上防範 XSS 攻擊。
- 說明：設定
- 原則：如果網站使用 HTTPS 協議，預設設定 HTTP Header 中的
secure屬性為 true- 說明：設定
secure為 true，Cookie 資訊將不會在 HTTP 連線中傳輸，一定程度上防範 XSS 攻擊。
- 說明：設定
- 原則：伺服器向響應 HTTP Header 寫入使用者輸入資料時必須做 CRLF 過濾或者轉義
1.3. 介面呼叫操作
- 原則：AJAX 介面必須執行 CSRF 過濾
- 原則：AJAX 介面輸出 JSON 字串禁止通過字串拼接構造，且輸出的 JSON 需要經過安全過濾
- 原則：AJAX 介面返回頭必須設定
Content-Type為application/json;charset=utf-8
1.4. 表單提交操作
- 原則：統一使用
POST方式提交表單- 說明：Get 請求可以通過構造 img 等標籤發起，造成 CSRF
- 原則：Form 表單提交必須執行 CSRF 過濾
- 原則：使用者輸入的富文字瀏覽器展示之前必須由伺服器端做安全過濾
1.5. 資料庫操作
- 原則：使用者密碼儲存須加鹽儲存，各使用者鹽值不同
- 原則：若涉及證件號等敏感資訊的儲存，須使用 AES-128 演算法加密儲存
- 原則：編寫的 SQL 必須預編譯，不允許通過字串拼接的方式合成
- 說明：部分特殊場景，必須通過拼接合成，則拼接的變數必須經過處理，只允許
[a-zA-Z0-9_-.]＋字元。
- 說明：部分特殊場景，必須通過拼接合成，則拼接的變數必須經過處理，只允許
1.6. URL 重定向
- 原則：URL 重定向的目標地址必須執行白名單過濾
1.7. 跨域操作
1.7.1. JSONP 跨域
- 原則：JSONP 介面 Callback 必須驗證有效性
- 原則：JSONP 介面輸出 JSON 字串禁止通過字串拼接構造，且輸出的 JSON 需要經過安全過濾
- 原則：JSONP 介面必須對 REFERER 進行白名單校驗，或執行 CSRF 檢查
- 原則：JSONP 介面返回頭必須正確設定
Content-Type為application/javascript;charset=utf-8
1.7.2. CORS 跨域
- 原則：支援 CORS 跨域的介面，返回頭
Access-Control-Allow-Origin必須使用白名單驗證，禁止直接返回*
1.8. 檔案上傳與下載
- 原則：限制可下載檔案所在的目錄為預期範圍，並通過指定檔案編號的方式來定位待下載檔案
- 原則：儲存上傳檔案的目錄不提供直接訪問
- 原則：對上傳檔案的大小和型別進行校驗，定義上傳檔案型別白名單
1.9. 加密與簽名
不同場景使用的加密演算法請參考下表。
| 場景 | 演算法 |
|---|---|
| 加密場景 | AES128 |
| 摘要場景 | SHA256 |
| 簽名場景 | RSA2048 |
2. 常見安全漏洞及修復方案
2.1 跨站指令碼（XSS）漏洞
漏洞描述
跨站指令碼攻擊(Cross Site Scripting, XSS)發生在客戶端，可被用於進行竊取隱私、釣魚欺騙、偷取密碼、傳播惡意程式碼等攻擊行為。 惡意的攻擊者將對客戶端有危害的程式碼放到伺服器上作為一個網頁內容， 使得其他網站使用者在觀看此網頁時，這些程式碼注入到了使用者的瀏覽器中執行，使使用者受到攻擊。一般而言，利用跨站指令碼攻擊，攻擊者可竊會話 Cookie 從而竊取網站使用者的隱私。
漏洞危害
- 釣魚欺騙：最典型的就是利用目標網站的反射型跨站指令碼漏洞將目標網站重定向到釣魚網站，或者注入釣魚 JavaScript 以監控目標網站的表單輸入。
- 網站掛馬：跨站時利用 IFrame 嵌入隱藏的惡意網站或者將被攻擊者定向到惡意網站上，或者彈出惡意網站視窗等方式都可以進行掛馬攻擊。
- 身份盜用：Cookie 是使用者對於特定網站的身份驗證標誌，XSS 可以盜取到使用者的 Cookie，從而利用該 Cookie 盜取使用者對該網站的操作許可權。如果一個網站管理員使用者 Cookie 被竊取，將會對網站引發巨大的危害。
- 盜取網站使用者資訊：當能夠竊取到使用者 Cookie 從而獲取到使用者身份時，攻擊者可以獲取到使用者對網站的操作許可權，從而檢視使用者隱私資訊。
- 垃圾資訊傳送：比如在 SNS 社群中，利用 XSS 漏洞借用被攻擊者的身份傳送大量的垃圾資訊給特定的目標群。
- 劫持使用者 Web 行為：一些高階的 XSS 攻擊甚至可以劫持使用者的 Web 行為，監視使用者的瀏覽歷史，傳送與接收的資料等等。
- XSS 蠕蟲：XSS 蠕蟲可以用來打廣告、刷流量、掛馬、惡作劇、破壞網上資料、實施 DDoS 攻擊等。
解決方案
- 對引數做 html 轉義過濾，要過濾的字元包括：單引號、雙引號、大於號、小於號，& 符號，防止指令碼執行。
- 在變數輸出時進行 HTML ENCODE 處理。
2.2 CSRF 漏洞
漏洞描述
跨站請求偽造(Cross-Site Request Forgery, CSRF)，惡意網站通過指令碼向當前使用者瀏覽器開啟的其它頁面的 URL 發起惡意請求，由於同一瀏覽器程序下 Cookie 可見性，導致使用者身份被盜用，完成惡意網站指令碼中指定的操作。
漏洞危害
- 資訊洩露：如登入ID，隱私資訊等。
- 惡意操作：如加好友，加購物車，刪除資料等。
解決方案
CSRF漏洞修復方案主要思路有兩類：
- 驗證請求是信任頁面發起，這類修復方案有：
- 在表單中填充一次性隨機的 csrf token 防止攻擊者偽造 form 表單進行 CSRF。同時將此串 token 置入 session，在後端再進行一次一致性校驗。
- referer 驗證。
- 驗證請求是合法使用者發起，這類修復方案有：
- 驗證碼
- 密碼驗證
- OTP 驗證
2.3 HTTP Header 注入漏洞
漏洞描述
Web 程式程式碼中把使用者提交的引數未做過濾就直接輸出到 HTTP 響應頭中，導致攻擊者可以利用該漏洞來注入到 HTTP 響應頭中實現攻擊。
解決方案
- 對引數做合法性校驗以及長度限制，謹慎的根據使用者所傳入引數做 HTTP 響應的 Header 設定。
- 在設定 HTTP 響應頭時，過濾回車換行
%0d%0a、%0D%0A字元。
2.4 目錄遍歷漏洞
漏洞描述
目錄遍歷是由於 Web 伺服器或 Web 應用程式對使用者輸入檔名稱的安全性驗證不足而導致的一種安全漏洞，使得攻擊者通過 HTTP 請求和利用一些特殊字元就可以繞過伺服器的安全限制，訪問任意受限的檔案(可以是 Web 根目錄以外的檔案)，甚至執行系統命令。
解決方案
- 嚴格檢查檔案路徑引數，限制在指定的範圍。
- 嚴格限制檔案路徑引數，不允許使用者控制檔案路徑相關的引數，限定檔案路徑範圍。
2.5 SQL 注入漏洞
漏洞描述
SQL 注入攻擊(SQL Injection)，被廣泛用於非法獲取網站控制權，是發生在應用程式的資料庫層上的安全漏洞。 在設計不良的程式當中，忽略了對輸入字串中夾帶的 SQL 指令的檢查，那麼這些夾帶進去的指令就會被資料庫誤認為是正常的 SQL 指令而執行，從而使資料庫受到攻擊，可能導致資料被竊取、更改、刪除，以及進一步導致網站被嵌入惡意程式碼、被植入後門程式等危害。
漏洞危害
- 機密資料被竊取
- 核心業務資料被篡改
- 網頁被篡改
- 資料庫所在伺服器被攻擊變為傀儡主機，甚至企業網被入侵
解決方案
- 所有的查詢語句都使用資料庫提供的引數化查詢介面，引數化的語句使用引數而不是將使用者輸入變數嵌入到 SQL 語句中。
- 對進入資料庫的特殊字元
'"\<>&*;等進行轉義處理，或編碼轉換。 - 確認每種資料的型別，比如數字型的資料就必須是數字，資料庫中的儲存欄位必須對應為 int 型。
- 資料長度應該嚴格規定，能在一定程度上防止比較長的 SQL 注入語句無法正確執行。
- 網站每個資料層的編碼統一，建議全部使用 UTF-8 編碼，上下層編碼不一致有可能導致一些過濾模型被繞過。
- 嚴格限制網站所用資料庫賬號的許可權，給此使用者僅提供能夠滿足其工作的許可權，從而最大限度的減少注入攻擊對資料庫的危害。
- 避免網站顯示 SQL 錯誤資訊，比如型別錯誤、欄位不匹配等，防止攻擊者利用這些錯誤資訊進行一些判斷。
2.6 檔案下載漏洞
漏洞描述
Web 應用程式在處理檔案下載時，接受使用者指定的路徑和檔名進行下載，攻擊者利用此漏洞來下載伺服器的其它檔案甚至任意檔案（原始碼、資料庫甚至 passwd 等）。
解決方案
- 限制可下載檔案所在的目錄為預期範圍。
- 通過指定檔案編號的方式來定位待下載檔案。
2.7 檔案上傳漏洞
漏洞描述
檔案上傳的 Web 程式未對檔案型別和格式做合法性校驗，導致攻擊者可以上傳 Webshell 或者非期望格式的檔案。
解決方案
- 對上傳檔案的大小和型別進行校驗，定義上傳檔案型別白名單。
- 儲存上傳檔案的目錄不提供直接訪問。
- 原則：敏感資訊的展示請嚴格按照脫敏規範進行脫敏
- 說明：脫敏的邏輯必須在服務端完成，不能使用 Javascript 在客戶端進行脫敏，包括程式碼註釋、隱藏域、url 引數、cookies 等處的資料也必須脫敏。
- 說明：不能使用可逆的編碼/加密方式，如 base64 編碼等代替脫敏規範。
- 說明：若敏感資訊明文展示在應用中，沒有按照脫敏規範完成脫敏。支付寶開放平臺將有權暫停敏感資料相關介面的開放。
1.1.2. 敏感資訊用於身份校驗的場景
- 原則：不要直接將敏感資訊的明文資訊在客戶端與服務端之間傳遞
- 說明：可以將敏感資訊在服務端關聯到使用者標識 ID，在客戶端儲存使用者標識 ID 並提交到服務端，服務端根據 ID 取出對應資訊後進行校驗。
1.2. HTML 頁面渲染
- 原則：所有在頁面渲染的敏感資料 (身份證、銀行卡號、手機號) 必須進行脫敏
- 原則：禁止向 HTML 頁面輸出未經安全過濾或未正確轉義的使用者資料
- 說明：使用者資料不僅僅包括使用者正常資料，同時包括攻擊者可修改，偽造的其他資料。
- 原則：HTML 頁面動態輸出 JSON、JavaScript 必須對其中的字串值做 XSS 防禦處理
- 原則：預設設定 HTTP Header 中的
HttpOnly屬性為 true- 說明：設定
HttpOnly為 true，將可以禁止 JavaScript 讀取頁面 Cookie 資訊，一定程度上防範 XSS 攻擊。
- 說明：設定
- 原則：如果網站使用 HTTPS 協議，預設設定 HTTP Header 中的
secure屬性為 true- 說明：設定
secure為 true，Cookie 資訊將不會在 HTTP 連線中傳輸，一定程度上防範 XSS 攻擊。
- 說明：設定
- 原則：伺服器向響應 HTTP Header 寫入使用者輸入資料時必須做 CRLF 過濾或者轉義
1.3. 介面呼叫操作
- 原則：AJAX 介面必須執行 CSRF 過濾
- 原則：AJAX 介面輸出 JSON 字串禁止通過字串拼接構造，且輸出的 JSON 需要經過安全過濾
- 原則：AJAX 介面返回頭必須設定
Content-Type為application/json;charset=utf-8
1.4. 表單提交操作
- 原則：統一使用
POST方式提交表單- 說明：Get 請求可以通過構造 img 等標籤發起，造成 CSRF
- 原則：Form 表單提交必須執行 CSRF 過濾
- 原則：使用者輸入的富文字瀏覽器展示之前必須由伺服器端做安全過濾
1.5. 資料庫操作
- 原則：使用者密碼儲存須加鹽儲存，各使用者鹽值不同
- 原則：若涉及證件號等敏感資訊的儲存，須使用 AES-128 演算法加密儲存
- 原則：編寫的 SQL 必須預編譯，不允許通過字串拼接的方式合成
- 說明：部分特殊場景，必須通過拼接合成，則拼接的變數必須經過處理，只允許
[a-zA-Z0-9_-.]＋字元。
- 說明：部分特殊場景，必須通過拼接合成，則拼接的變數必須經過處理，只允許
1.6. URL 重定向
- 原則：URL 重定向的目標地址必須執行白名單過濾
1.7. 跨域操作
1.7.1. JSONP 跨域
- 原則：JSONP 介面 Callback 必須驗證有效性
- 原則：JSONP 介面輸出 JSON 字串禁止通過字串拼接構造，且輸出的 JSON 需要經過安全過濾
- 原則：JSONP 介面必須對 REFERER 進行白名單校驗，或執行 CSRF 檢查
- 原則：JSONP 介面返回頭必須正確設定
Content-Type為application/javascript;charset=utf-8
1.7.2. CORS 跨域
- 原則：支援 CORS 跨域的介面，返回頭
Access-Control-Allow-Origin必須使用白名單驗證，禁止直接返回*
1.8. 檔案上傳與下載
- 原則：限制可下載檔案所在的目錄為預期範圍，並通過指定檔案編號的方式來定位待下載檔案
- 原則：儲存上傳檔案的目錄不提供直接訪問
- 原則：對上傳檔案的大小和型別進行校驗，定義上傳檔案型別白名單
1.9. 加密與簽名
不同場景使用的加密演算法請參考下表。
| 場景 | 演算法 |
|---|---|
| 加密場景 | AES128 |
| 摘要場景 | SHA256 |
| 簽名場景 | RSA2048 |
2. 常見安全漏洞及修復方案
2.1 跨站指令碼（XSS）漏洞
漏洞描述
跨站指令碼攻擊(Cross Site Scripting, XSS)發生在客戶端，可被用於進行竊取隱私、釣魚欺騙、偷取密碼、傳播惡意程式碼等攻擊行為。 惡意的攻擊者將對客戶端有危害的程式碼放到伺服器上作為一個網頁內容， 使得其他網站使用者在觀看此網頁時，這些程式碼注入到了使用者的瀏覽器中執行，使使用者受到攻擊。一般而言，利用跨站指令碼攻擊，攻擊者可竊會話 Cookie 從而竊取網站使用者的隱私。
漏洞危害
- 釣魚欺騙：最典型的就是利用目標網站的反射型跨站指令碼漏洞將目標網站重定向到釣魚網站，或者注入釣魚 JavaScript 以監控目標網站的表單輸入。
- 網站掛馬：跨站時利用 IFrame 嵌入隱藏的惡意網站或者將被攻擊者定向到惡意網站上，或者彈出惡意網站視窗等方式都可以進行掛馬攻擊。
- 身份盜用：Cookie 是使用者對於特定網站的身份驗證標誌，XSS 可以盜取到使用者的 Cookie，從而利用該 Cookie 盜取使用者對該網站的操作許可權。如果一個網站管理員使用者 Cookie 被竊取，將會對網站引發巨大的危害。
- 盜取網站使用者資訊：當能夠竊取到使用者 Cookie 從而獲取到使用者身份時，攻擊者可以獲取到使用者對網站的操作許可權，從而檢視使用者隱私資訊。
- 垃圾資訊傳送：比如在 SNS 社群中，利用 XSS 漏洞借用被攻擊者的身份傳送大量的垃圾資訊給特定的目標群。
- 劫持使用者 Web 行為：一些高階的 XSS 攻擊甚至可以劫持使用者的 Web 行為，監視使用者的瀏覽歷史，傳送與接收的資料等等。
- XSS 蠕蟲：XSS 蠕蟲可以用來打廣告、刷流量、掛馬、惡作劇、破壞網上資料、實施 DDoS 攻擊等。
解決方案
- 對引數做 html 轉義過濾，要過濾的字元包括：單引號、雙引號、大於號、小於號，& 符號，防止指令碼執行。
- 在變數輸出時進行 HTML ENCODE 處理。
2.2 CSRF 漏洞
漏洞描述
跨站請求偽造(Cross-Site Request Forgery, CSRF)，惡意網站通過指令碼向當前使用者瀏覽器開啟的其它頁面的 URL 發起惡意請求，由於同一瀏覽器程序下 Cookie 可見性，導致使用者身份被盜用，完成惡意網站指令碼中指定的操作。
漏洞危害
- 資訊洩露：如登入ID，隱私資訊等。
- 惡意操作：如加好友，加購物車，刪除資料等。
解決方案
CSRF漏洞修復方案主要思路有兩類：
- 驗證請求是信任頁面發起，這類修復方案有：
- 在表單中填充一次性隨機的 csrf token 防止攻擊者偽造 form 表單進行 CSRF。同時將此串 token 置入 session，在後端再進行一次一致性校驗。
- referer 驗證。
- 驗證請求是合法使用者發起，這類修復方案有：
- 驗證碼
- 密碼驗證
- OTP 驗證
2.3 HTTP Header 注入漏洞
漏洞描述
Web 程式程式碼中把使用者提交的引數未做過濾就直接輸出到 HTTP 響應頭中，導致攻擊者可以利用該漏洞來注入到 HTTP 響應頭中實現攻擊。
解決方案
- 對引數做合法性校驗以及長度限制，謹慎的根據使用者所傳入引數做 HTTP 響應的 Header 設定。
- 在設定 HTTP 響應頭時，過濾回車換行
%0d%0a、%0D%0A字元。
2.4 目錄遍歷漏洞
漏洞描述
目錄遍歷是由於 Web 伺服器或 Web 應用程式對使用者輸入檔名稱的安全性驗證不足而導致的一種安全漏洞，使得攻擊者通過 HTTP 請求和利用一些特殊字元就可以繞過伺服器的安全限制，訪問任意受限的檔案(可以是 Web 根目錄以外的檔案)，甚至執行系統命令。
解決方案
- 嚴格檢查檔案路徑引數，限制在指定的範圍。
- 嚴格限制檔案路徑引數，不允許使用者控制檔案路徑相關的引數，限定檔案路徑範圍。
2.5 SQL 注入漏洞
漏洞描述
SQL 注入攻擊(SQL Injection)，被廣泛用於非法獲取網站控制權，是發生在應用程式的資料庫層上的安全漏洞。 在設計不良的程式當中，忽略了對輸入字串中夾帶的 SQL 指令的檢查，那麼這些夾帶進去的指令就會被資料庫誤認為是正常的 SQL 指令而執行，從而使資料庫受到攻擊，可能導致資料被竊取、更改、刪除，以及進一步導致網站被嵌入惡意程式碼、被植入後門程式等危害。
漏洞危害
- 機密資料被竊取
- 核心業務資料被篡改
- 網頁被篡改
- 資料庫所在伺服器被攻擊變為傀儡主機，甚至企業網被入侵
解決方案
- 所有的查詢語句都使用資料庫提供的引數化查詢介面，引數化的語句使用引數而不是將使用者輸入變數嵌入到 SQL 語句中。
- 對進入資料庫的特殊字元
'"\<>&*;等進行轉義處理，或編碼轉換。 - 確認每種資料的型別，比如數字型的資料就必須是數字，資料庫中的儲存欄位必須對應為 int 型。
- 資料長度應該嚴格規定，能在一定程度上防止比較長的 SQL 注入語句無法正確執行。
- 網站每個資料層的編碼統一，建議全部使用 UTF-8 編碼，上下層編碼不一致有可能導致一些過濾模型被繞過。
- 嚴格限制網站所用資料庫賬號的許可權，給此使用者僅提供能夠滿足其工作的許可權，從而最大限度的減少注入攻擊對資料庫的危害。
- 避免網站顯示 SQL 錯誤資訊，比如型別錯誤、欄位不匹配等，防止攻擊者利用這些錯誤資訊進行一些判斷。
2.6 檔案下載漏洞
漏洞描述
Web 應用程式在處理檔案下載時，接受使用者指定的路徑和檔名進行下載，攻擊者利用此漏洞來下載伺服器的其它檔案甚至任意檔案（原始碼、資料庫甚至 passwd 等）。
解決方案
- 限制可下載檔案所在的目錄為預期範圍。
- 通過指定檔案編號的方式來定位待下載檔案。
2.7 檔案上傳漏洞
漏洞描述
檔案上傳的 Web 程式未對檔案型別和格式做合法性校驗，導致攻擊者可以上傳 Webshell 或者非期望格式的檔案。
解決方案
- 對上傳檔案的大小和型別進行校驗，定義上傳檔案型別白名單。