1 - 輸入校驗

編碼原則：針對各種語言本身的保留字符，做到數(shù)據(jù)與代碼相分離。

1.1 SQL 注入防范

嚴重性高，可能性低。

(1) 參數(shù)校驗，攔截非法參數(shù)（推薦白名單）：

public String sanitizeUser(String username) { return Pattern.matches('[A-Za-z0-9_]+', username) ? username : 'unauthorized user';}

(2) 使用預(yù)編譯：

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);// JavaScriptESAPI.encoder().encodeForJavaSceipt(data);// CSS ESAPI.encoder().encodeForCSS(data);// URLESAPI.encoder().encodeForURL(data);

1.3 代碼注入/命令執(zhí)行防范

嚴重性高，可能性低。

(1) 參數(shù)校驗，攔截非法參數(shù)（推薦白名單）；

(2) 不直接執(zhí)行用戶傳入?yún)?shù)：

if('open'.equals(request.getParameter('choice'))) { Runtime.getRuntime().exec('your command...');}

(3) 及時更新升級第三方組件：

比如Struts、Spring、ImageMagick等。

1.4 日志偽造防范

嚴重性低，可能性高。

(1) 不要log用戶可控的信息；

(2) 輸入?yún)?shù)校驗（推薦白名單）：

// 處理回車、換行符Pattern p = Pattern.compile('%0a|%0d0a|n|rn');Matcher m = p.matcher(data);dest = m.replaceAll('');

(3) 使用 Log4j2。

1.5 XML 外部實體攻擊

嚴重性中，可能性中。

(1) 關(guān)閉內(nèi)聯(lián) DTD 解析，使用白名單來控制允許使用的協(xié)議；

(2) 禁用外部實體：

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

factory.setExpandEntityReferences(false);

(3) 過濾用戶提交的 XML 數(shù)據(jù)：

比如 !DOCTYPE、<!ENTITY、SYSTEM、PUBLIC 等。

1.6 XML 注入防范

嚴重性中，可能性低。

(1) 教研用戶輸入（推薦白名單）：

OutputFormat format = OutputFormat.createPrettyPrint();

(2) 使用安全的 XML 庫（比如 dom4j）。

1.7 URL 重定向防范

嚴重性中，可能性低。

(1) 設(shè)置嚴格白名單幾網(wǎng)絡(luò)邊界：

String url = request.getParameter('url');String host = getHostFromUrl(url);if(!validateHost(host)) { return;}

(2) 加入有效性驗證的 Token；

(3) referer 適用于檢測監(jiān)控 URL 重定向、CSRF 等，多數(shù)場景下也可用作防范措施。

2 - 異常處理

編碼原則：不要泄露詳細異常信息。

2.1 敏感信息泄露防范

嚴重性低，可能性中。

屏蔽敏感信息示例：

catch(IOException e) { System.out.println('Invalid file'); // System.out.println('Error code: 0001'); return;}

2.2 保持對象一致性

嚴重性中，可能性低。

(1) 重排邏輯，使得產(chǎn)生異常的代碼在改變對象狀態(tài)的代碼之前執(zhí)行；

catch(Exception e) { // revert money -= PADDING; return -1;}

(2) 在出現(xiàn)異常導(dǎo)致操作失敗的情況下，使用事務(wù)回滾機制；

(3) 在對象的臨時拷貝上執(zhí)行操作，成功后再提交給正式的對象；

(4) 回避修改對象的需求，盡量不去修改對象。

3 - I/O 操作

編碼規(guī)則：可寫的文件不可執(zhí)行，可執(zhí)行的文件不可寫。

3.1 資源釋放

嚴重性低，可能性高。

Java 垃圾回收器回自動釋放內(nèi)存資源，非內(nèi)存資源需要開發(fā)人員手動釋放，比如 DataBase，F(xiàn)iles，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 創(chuàng)建的 buffer 應(yīng)該以只讀或拷貝的方式返回：

Charbuffer buffer；public Duplicator() { buffer = CharBuffer.allocate(10);}/** 獲取只讀的 Buffer */public CharBuffer getBufferCopy() { return buffer.asReadOnlyBuffer();}

3.4 任意文件下載/路徑遍歷防范

嚴重性中，可能性高。

(1) 校驗用戶可控的參數(shù)（推薦白名單）；

(2) 文件路徑保存到數(shù)據(jù)庫，讓用戶提交文件對應(yīng)的 ID 去下載文件：

<%String filePath = getFilePath(request.getParameter('id'));download(filePath);%>

(3) 判斷目錄和文件名：

if(!'/somedir/'.equals(filePath) || !'jpg'.equals(fileType)) { ... return -1;}

(4) 下載文件前做權(quán)限判斷。

補充：禁止將敏感文件（如日志文件、配置文件、數(shù)據(jù)庫文件等）存放在 web 內(nèi)容目錄下。

3.5 非法文件上傳防范

嚴重性高，可能性中。

在服務(wù)器端用白名單方式過濾文件類型，使用隨機數(shù)改寫文件名和文件路徑。

if(!ESAPI.validator().isValidFileName( 'upload', filename, allowedExtensions, false)) { throw new ValidationUploadException('upload error');}

補充：如果使用第三方編輯器，請及時更新版本。

4 - 序列化/反序列化操作

編碼原則：不信任原則。

4.1 敏感數(shù)據(jù)禁止序列化

嚴重性高，可能性低。

使用 transient、serialPersistentFields 標注敏感數(shù)據(jù)：

private static final ObjectStreamField[] serialPersistentFields = { new ObjectStreamField('name', String.class), new ObjectStreamField('age', Integer.TYPE)}

當然，正確加密的敏感數(shù)據(jù)可以序列化。

4.2 正確使用安全管理器

嚴重性高，可能性低。

如果一個類的構(gòu)造方法中含有各種安全管理器的檢查，在反序列化時也要進行檢查：

private void writeObject(ObjectOutputStream out) throws IOException { performSecurityManagerChek(); out.writeObject(xxx);}

補充：第三方組件造成的反序列化漏洞可通過更新升級組件解決；

禁止 JVM 執(zhí)行外部命令，可減小序列化漏洞造成的危害。

5 - 運行環(huán)境

編碼原則：攻擊面最小化原則。

5.1 不要禁用字節(jié)碼驗證

嚴重性中，可能性低。

啟用 Java 字節(jié)碼驗證：Java -Xverify:all ApplicationName

5.2 不要遠程調(diào)試/監(jiān)控生產(chǎn)環(huán)境的應(yīng)用

嚴重性高，可能性低。

(1) 生產(chǎn)環(huán)境中安裝默認的安全管理器，并且不要使用 -agentlib，-Xrunjdwp 和 -Xdebug 命令行參數(shù)：

${JAVA_HOME}/bin/java -Djava.security.manager ApplicationName

(2) iptables 中關(guān)閉相應(yīng) jdwp 對外訪問的端口。

5.3 生產(chǎn)應(yīng)用只能有一個入口

嚴重性中，可能性中。

移除項目中多余的 main 方法。

6 - 業(yè)務(wù)邏輯

編碼原則：安全設(shè)計 API。

6.1 用戶體系

過程如下：

(1) identification <-- 宣稱用戶身份（鑒定提供唯一性）||--> (2) authentication <-- 驗證用戶身份（驗證提供有效性）||--> (3) authorization <-- 授權(quán)訪問相關(guān)資源（授權(quán)提供訪問控制）||--> RESOURCE||--> (4) accountability <-- 日志追溯

(1) 身份驗證：

嚴重性高，可能性中。

多因素認證；

暴力破解防范：驗證碼、短信驗證碼、密碼復(fù)雜度校驗、鎖定賬號、鎖定終端等；

敏感數(shù)據(jù)保護：存儲、傳輸、展示（API 接口、HTML 頁面掩碼）；

禁止本地驗證：重要操作均在服務(wù)器端進行驗證。

(2) 訪問控制：

嚴重性高，可能性中。

從 Session 中獲取身份信息；

禁用默認賬號、匿名賬號，限制超級賬號的使用；

重要操作做到職責分離；

用戶、角色、資源、權(quán)限做好相互校驗；

權(quán)限驗證要在服務(wù)器端進行；

數(shù)據(jù)傳輸階段做好加密防篡改。

補充：oauth 授權(quán)時授權(quán)方和應(yīng)用方都要做好安全控制。

(3) 會話管理：

嚴重性高，可能性中。

漏洞名稱 防御方法 會話 ID 中嵌入 URL 會話 ID 保存在 Cookie 中 無 Session 驗證 所有的訪問操作都應(yīng)基于 Session Session 未清除 注銷、超時、關(guān)閉瀏覽器時，都要清除 Session Session 固定攻擊 認證通過后更改 Session ID Session ID 可猜測 使用開發(fā)工具中提供的會話管理機制 重放攻擊 設(shè)置一次失效的隨機數(shù)，或設(shè)置合理的時間窗

補充：設(shè)置認證 Cookie 時，需加入 secure 和 httponly 屬性。

(3) 日志追溯：

嚴重性中，可能性中。

記錄每一個訪問敏感數(shù)據(jù)的請求，或執(zhí)行敏感操作的事件；

防范日志偽造攻擊（輸入校驗）；

任何對日志文件的訪問（讀、寫、下載、刪除）嘗試都必須被記錄。

6.2 在線支付

嚴重性高，可能性中。

支付數(shù)據(jù)做簽名，并確保簽名算法的可靠；

重要參數(shù)進行校驗，并做有效性驗證；

驗證訂單的唯一性，防止重放攻擊。

6.3 順序執(zhí)行

嚴重性高，可能性中。

對每一步的請求都要嚴格驗證，并且要以上一步的執(zhí)行結(jié)果為依據(jù)；

給請求參數(shù)加入隨機 key，貫穿驗證的始終。

以上這篇淺談Java開發(fā)中的安全編碼問題就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持好吧啦網(wǎng)。