Java - Java開發中的安全編碼問題

1 - 輸入校驗

編碼原則:針對各類語言自己的保留字符,作到數據與代碼相分離html

1.1 SQL 注入防範

嚴重性高,可能性低。java

(1) 參數校驗,攔截非法參數(推薦白名單):web

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防範

嚴重性中,可能性高。防範方法有:sql

(1) 輸入輸出校驗(推薦白名單);shell

(2) org.apache.commons.lang 工具包處理;數據庫

(3) 富文本可用 owasp antisampjava html sanitizer 處理;apache

(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<!ENTITYSYSTEMPUBLIC 等。

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 敏感數據禁止序列化

嚴重性高,可能性低。

使用 transientserialPersistentFields 標註敏感數據:

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://healchow.com)

出處: 博客園 瘦風的博客(https://www.cnblogs.com/shoufeng)

感謝閱讀, 右側導航欄有「瘦風的南牆」公衆號二維碼,輸出更及時、更體系,歡迎掃碼關注🤝

本文版權歸博主全部, 歡迎轉載, 但 [必須在頁面明顯位置標明原文連接], 不然博主保留追究相關人士法律責任的權利.

相關文章
相關標籤/搜索