近年來,網路安全越來越受到開發者的重視。關註安全編碼能很大程度上避免安全漏洞的產生,也能有效保護用戶的利益不被輕易侵犯。本文從6個方面簡述了Java安全編碼的問題,歡迎交流指正。 ...
目錄
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|\r\n");
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)
感謝閱讀, 右側導航欄有「瘦風的南牆」公眾號二維碼,輸出更及時、更體系,歡迎掃碼關註