淺談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,貫穿驗證的始終。
以上這篇淺談Java開發中的安全編碼問題就是小編分享給大家的全部內容了,希望能給大家一個參考,也希望大家多多支援我們。