Java – Java開發中的安全編碼問題
- 2020 年 4 月 1 日
- 筆記
1 – 輸入校驗
編碼原則：針對各種語言本身的保留字元，做到數據與程式碼相分離。
1.1 SQL 注入防範
嚴重性高，可能性低。
(1) 參數校驗，攔截非法參數（推薦白名單）：
public String sanitizeUser(String username) { return Pattern.matches("[A-Za-z0-9_]+", username) ? username : "unauthorized user"; } (2) 使用預編譯：
String sql = "UPDATE EMPLOYEES SET SALARY = ? WHERE ID = ?"; PreparedStatement statement = conn.prepareStatement(sql); statement.setBigDecimal(1, 285500.00); statement.setInt(2, 30015800); 1.2 XSS防範
嚴重性中，可能性高。防範方法有：
(1) 輸入輸出校驗（推薦白名單）；
(2) org.apache.commons.lang 工具包處理；
(3) 富文本可用 owasp antisamp 或 java html sanitizer 處理；
(4) ESAPI 處理：
// HTML 實體 ESAPI.encoder().encodeForHTML(data); // HTML 屬性 ESAPI.encoder().encodeForHTMLAttribute(data); // JavaScript ESAPI.encoder().encodeForJavaSceipt(data); // CSS ESAPI.encoder().encodeForCSS(data); // URL ESAPI.encoder().encodeForURL(data); 1.3 程式碼注入/命令執行防範
嚴重性高，可能性低。
(1) 參數校驗，攔截非法參數（推薦白名單）；
(2) 不直接執行用戶傳入參數：
if("open".equals(request.getParameter("choice"))) { Runtime.getRuntime().exec("your command..."); } (3) 及時更新升級第三方組件：
比如Struts、Spring、ImageMagick等。
1.4 日誌偽造防範
嚴重性低，可能性高。
(1) 不要log用戶可控的資訊；
(2) 輸入參數校驗（推薦白名單）：
// 處理回車、換行符 Pattern p = Pattern.compile("%0a|%0d0a|n|rn"); Matcher m = p.matcher(data); dest = m.replaceAll(""); (3) 使用 Log4j2。
1.5 XML 外部實體攻擊
嚴重性中，可能性中。
(1) 關閉內聯 DTD 解析，使用白名單來控制允許使用的協議；
(2) 禁用外部實體：
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setExpandEntityReferences(false); (3) 過濾用戶提交的 XML 數據：
比如 !DOCTYPE、<!ENTITY、SYSTEM、PUBLIC 等。
1.6 XML 注入防範
嚴重性中，可能性低。
(1) 教研用戶輸入（推薦白名單）：
OutputFormat format = OutputFormat.createPrettyPrint(); (2) 使用安全的 XML 庫（比如 dom4j）。
1.7 URL 重定向防範
嚴重性中，可能性低。
(1) 設置嚴格白名單幾網路邊界：
String url = request.getParameter("url"); String host = getHostFromUrl(url); if(!validateHost(host)) { return; } (2) 加入有效性驗證的 Token；
(3) referer 適用於檢測監控 URL 重定向、CSRF 等，多數場景下也可用作防範措施。
2 – 異常處理
編碼原則：不要泄露詳細異常資訊。
2.1 敏感資訊泄露防範
嚴重性低，可能性中。
屏蔽敏感資訊示例：
catch(IOException e) { System.out.println("Invalid file"); // System.out.println("Error code: 0001"); return; } 2.2 保持對象一致性
嚴重性中，可能性低。
(1) 重排邏輯，使得產生異常的程式碼在改變對象狀態的程式碼之前執行；
catch(Exception e) { // revert money -= PADDING; return -1; } (2) 在出現異常導致操作失敗的情況下，使用事務回滾機制；
(3) 在對象的臨時拷貝上執行操作，成功後再提交給正式的對象；
(4) 迴避修改對象的需求，盡量不去修改對象。
3 – I/O 操作
編碼規則：可寫的文件不可執行，可執行的文件不可寫。
3.1 資源釋放
嚴重性低，可能性高。
Java 垃圾回收器回自動釋放記憶體資源，非記憶體資源需要開發人員手動釋放，比如 DataBase，Files，Sockets，Streams，Synchronization 等資源的釋放。
try { Connection conn = getConnection(); Statement statement = conn.createStatement(); ResultSet resultSet = statement.executeQuery(sqlQuery); processResults(resultSet); } catch(SQLException e) { // forward to handler } finally { if (null != conn) { conn.close(); } } 3.2 清除臨時文件
嚴重性中，可能性中。
(1) 自動清除：
File tempFile = Files.createTempFile("tempname", ".tmp"); try { BufferedWriter writer = Files.newBufferedWriter(tempFile.toPath(), StandardCharsets.UTF_8, StandardOpenOption.DELETE_ON_CLOSE) // operate the file writer.newLine(); } catch (IOException e) { e.printStackTrace(); } (2) 手動清除。
3.3 避免將 bufer 暴露給不可信程式碼
嚴重性中，可能性中。
wrap、duplicate 創建的 buffer 應該以只讀或拷貝的方式返回：
Charbuffer buffer； public Duplicator() { buffer = CharBuffer.allocate(10); } /** 獲取只讀的 Buffer */ public CharBuffer getBufferCopy() { return buffer.asReadOnlyBuffer(); } 3.4 任意文件下載/路徑遍歷防範
嚴重性中，可能性高。
(1) 校驗用戶可控的參數（推薦白名單）；
(2) 文件路徑保存到資料庫，讓用戶提交文件對應的 ID 去下載文件：
<% String filePath = getFilePath(request.getParameter("id")); download(filePath); %> (3) 判斷目錄和文件名：
if(!"/somedir/".equals(filePath) || !"jpg".equals(fileType)) { ... return -1; } (4) 下載文件前做許可權判斷。
補充：禁止將敏感文件（如日誌文件、配置文件、資料庫文件等）存放在 web 內容目錄下。
3.5 非法文件上傳防範
嚴重性高，可能性中。
在伺服器端用白名單方式過濾文件類型，使用隨機數改寫文件名和文件路徑。
if(!ESAPI.validator().isValidFileName( "upload", filename, allowedExtensions, false)) { throw new ValidationUploadException("upload error"); } 補充：如果使用第三方編輯器，請及時更新版本。
4 – 序列化/反序列化操作
編碼原則：不信任原則。
4.1 敏感數據禁止序列化
嚴重性高，可能性低。
使用 transient、serialPersistentFields 標註敏感數據：
private static final ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("name", String.class), new ObjectStreamField("age", Integer.TYPE) } 當然，正確加密的敏感數據可以序列化。
4.2 正確使用安全管理器
嚴重性高，可能性低。
如果一個類的構造方法中含有各種安全管理器的檢查，在反序列化時也要進行檢查：
private void writeObject(ObjectOutputStream out) throws IOException { performSecurityManagerChek(); out.writeObject(xxx); } 補充：第三方組件造成的反序列化漏洞可通過更新升級組件解決；
禁止 JVM 執行外部命令，可減小序列化漏洞造成的危害。
5 – 運行環境
編碼原則：攻擊面最小化原則。
5.1 不要禁用位元組碼驗證
嚴重性中，可能性低。
啟用 Java 位元組碼驗證：Java -Xverify:all ApplicationName
5.2 不要遠程調試/監控生產環境的應用
嚴重性高，可能性低。
(1) 生產環境中安裝默認的安全管理器，並且不要使用 -agentlib，-Xrunjdwp 和 -Xdebug 命令行參數：
${JAVA_HOME}/bin/java -Djava.security.manager ApplicationName (2) iptables 中關閉相應 jdwp 對外訪問的埠。
5.3 生產應用只能有一個入口
嚴重性中，可能性中。
移除項目中多餘的 main 方法。
6 – 業務邏輯
編碼原則：安全設計 API。
6.1 用戶體系
過程如下：
(1) identification <– 宣稱用戶身份（鑒定提供唯一性）
|
|–> (2) authentication <– 驗證用戶身份（驗證提供有效性）
|
|–> (3) authorization <– 授權訪問相關資源（授權提供訪問控制）
|
|–> RESOURCE
|
|–> (4) accountability <– 日誌追溯
(1) 身份驗證：
嚴重性高，可能性中。
多因素認證；
暴力破解防範：驗證碼、簡訊驗證碼、密碼複雜度校驗、鎖定帳號、鎖定終端等；
敏感數據保護：存儲、傳輸、展示（API 介面、HTML 頁面掩碼）；
禁止本地驗證：重要操作均在伺服器端進行驗證。
(2) 訪問控制：
嚴重性高，可能性中。
從 Session 中獲取身份資訊；
禁用默認帳號、匿名帳號，限制超級帳號的使用；
重要操作做到職責分離；
用戶、角色、資源、許可權做好相互校驗；
許可權驗證要在伺服器端進行；
數據傳輸階段做好加密防篡改。
補充：oauth 授權時授權方和應用方都要做好安全控制。
(3) 會話管理：
嚴重性高，可能性中。
| 漏洞名稱 | 防禦方法 |
|---|---|
| 會話 ID 中嵌入 URL | 會話 ID 保存在 Cookie 中 |
| 無 Session 驗證 | 所有的訪問操作都應基於 Session |
| Session 未清除 | 註銷、超時、關閉瀏覽器時，都要清除 Session |
| Session 固定攻擊 | 認證通過後更改 Session ID |
| Session ID 可猜測 | 使用開發工具中提供的會話管理機制 |
| 重放攻擊 | 設置一次失效的隨機數，或設置合理的時間窗 |
補充：設置認證 Cookie 時，需加入 secure 和 httponly 屬性。
(3) 日誌追溯：
嚴重性中，可能性中。
- 記錄每一個訪問敏感數據的請求，或執行敏感操作的事件；
- 防範日誌偽造攻擊（輸入校驗）；
- 任何對日誌文件的訪問（讀、寫、下載、刪除）嘗試都必須被記錄。
6.2 在線支付
嚴重性高，可能性中。
支付數據做簽名，並確保簽名演算法的可靠；
重要參數進行校驗，並做有效性驗證；
驗證訂單的唯一性，防止重放攻擊。
6.3 順序執行
嚴重性高，可能性中。
對每一步的請求都要嚴格驗證，並且要以上一步的執行結果為依據；
給請求參數加入隨機 key，貫穿驗證的始終。
參考資料
安全編碼指南Secure Coding Guidelines for Java SE
安全編碼示例SEI CERT Oracle Coding Standard for Java
版權聲明
出處: 部落格園 瘦風的部落格(https://www.cnblogs.com/shoufeng)
感謝閱讀, 右側導航欄有「瘦風的南牆」公眾號二維碼，輸出更及時、更體系，歡迎掃碼關注?
本文版權歸部落客所有, 歡迎轉載, 但 [必須在頁面明顯位置標明原文鏈接], 否則部落客保留追究相關人士法律責任的權利.
