為了獲得一個想法,在Sonar分析期間,您的項目會被許多工具掃描,以確保源代碼符合您在質量配置文件中創建的規則。 每當違反規則時…就會引發違反。 使用Sonar,您可以通過違規深入視圖或在源代碼編輯器中跟蹤這些違規。 有數百條規則,根據其重要性進行分類。 在以后的文章中,我會盡我所能覆蓋盡可能多的內容,但現在讓我們來看一些常見的安全規則/違規行為。 我們現在要檢查兩對規則(在Sonar中它們都被列為關鍵)。
1.數組直接存儲( PMD ),方法返回內部數組( PMD )
當內部數組存儲或直接從方法返回時,會出現這些沖突。 以下示例說明了違反這些規則的簡單類。
public class CalendarYear {private String[] months;public String[] getMonths() {return months; }public void setMonths(String[] months) {this.months = months;}
}
要消除它們,您必須在存儲/返回它之前克隆Array,如以下類實現所示,因此沒有人可以修改或獲取您類的原始數據,而只能修改它們的副本。
public class CalendarYear {private String[] months;public String[] getMonths() {return months.clone(); }public void setMonths(String[] months) {this.months = months.clone();}
}
2.傳遞給SQL語句( findbugs )上的execute方法的非恒定字符串,并從非恒定String (findbugs )生成準備好的語句
使用JDBC庫時,這兩個規則都與數據庫訪問有關。 通常,有兩種方法可以通過JDBC連接執行SQL Commants:Statement和PreparedStatement。 關于優缺點,有很多討論,但這超出了本文的范圍。 讓我們看看如何根據以下源代碼片段引發第一次違規。
Statement stmt = conn.createStatement();
String sqlCommand = 'Select * FROM customers WHERE name = '' + custName + ''';
stmt.execute(sqlCommand);
您已經注意到傳遞給execute方法的sqlcommand參數是在運行時動態創建的,此規則不接受。 類似情況會導致第二次違規。
String sqlCommand = 'insert into customers (id, name) values (?, ?)';
Statement stmt = conn.prepareStatement(sqlCommand);
您可以通過三種不同的方法來克服此問題。 您可以使用StringBuilder或String.format方法來創建字符串變量的值。 如果適用,可以在類聲明中將SQL Commands定義為Constant,但這僅適用于不需要在運行時更改SQL Command的情況。 讓我們使用StringBuilder重新編寫第一個代碼段
Statement stmt = conn.createStatement();
stmt.execute(new StringBuilder('Select FROM customers WHERE name = '').append(custName).append(''').toString());
并使用String.format
Statement stmt = conn.createStatement();
String sqlCommand = String.format('Select * from customers where name = '%s'', custName);
stmt.execute(sqlCommand);
對于第二個示例,您可以僅聲明sqlCommand,如下所示
private static final SQLCOMMAND = insert into customers (id, name) values (?, ?)';
還有更多安全規則,例如阻止程序Hardcoded常量數據庫密碼,但是我認為沒有人仍然在源代碼文件中對密碼進行硬編碼…
在接下來的文章中,我將向您展示如何遵守性能和不良實踐規則。 在此之前,我一直在等待您的意見或建議。
祝您編程愉快,別忘了分享!
參考:在Only Only軟件問題博客上,從我們的JCG合作伙伴 Papapetrou P. Patroklos 修復了Sonar中常見的Java安全代碼沖突 。
翻譯自: https://www.javacodegeeks.com/2012/09/fixing-common-java-security-code.html