目前已轉(zhuǎn)至個(gè)人博客，本系列地址：Lam's Blog - Knowledge as Action
DMI_CONSTANT_DB_PASSWORD
Hardcoded constant database password
代碼中創(chuàng)建DB的密碼時(shí)采用了寫死的密碼点额。
DMI_EMPTY_DB_PASSWORD
Empty database password
創(chuàng)建數(shù)據(jù)庫連接時(shí)沒有為數(shù)據(jù)庫設(shè)置密碼念逞，這會(huì)使數(shù)據(jù)庫失去必要的保護(hù)狭魂。
HRS_REQUEST_PARAMETER_TO_COOKIE
HTTP cookie formed from untrusted input
此代碼使用不受信任的HTTP參數(shù)構(gòu)造一個(gè)HTTP Cookie窘哈。
HRS_REQUEST_PARAMETER_TO_HTTP_HEADER
HTTP Response splitting vulnerability
在代碼中直接把一個(gè)HTTP的參數(shù)寫入一個(gè)HTTP頭文件中，它為HTTP的響應(yīng)暴露了漏洞暖哨。
SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE
Nonconstant string passed to execute method on an SQL statement
該方法以字符串的形式來調(diào)用SQLstatement的execute方法，它似乎是動(dòng)態(tài)生成SQL語句的方法凰狞。這會(huì)更容易受到SQL注入攻擊篇裁。
XSS_REQUEST_PARAMETER_TO_JSP_WRITER
JSP reflected cross site scripting vulnerability
在代碼中在JSP輸出中直接寫入一個(gè)HTTP參數(shù)，這會(huì)造成一個(gè)跨站點(diǎn)的腳本漏洞赡若。
LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE
Potential lost logger changes due to weak reference in OpenJDK
OpenJDK的引入了一種潛在的不兼容問題达布，特別是，java.util.logging.Logger的行為改變時(shí)逾冬。它現(xiàn)在使用內(nèi)部弱引用黍聂，而不是強(qiáng)引用。–logger配置改變身腻，它就是丟失對(duì)logger的引用产还，這本是一個(gè)合理的變化，但不幸的是一些代碼對(duì)舊的行為有依賴關(guān)系嘀趟。這意味著脐区，當(dāng)進(jìn)行垃圾收集時(shí)對(duì)logger配置將會(huì)丟失。例如：
public static void initLogging() throws Exception { Logger logger = Logger.getLogger("edu.umd.cs"); logger.addHandler(new FileHandler()); // call to change logger configuration logger.setUseParentHandlers(false); // another call to change logger configuration }
該方法結(jié)束時(shí)logger的引用就丟失了她按，如果你剛剛結(jié)束調(diào)用initLogging方法后進(jìn)行垃圾回收牛隅，logger的配置將會(huì)丟失（因?yàn)橹挥斜３钟涗浧魅跻茫?br>
public static void main(String[] args) throws Exception { initLogging(); // adds a file handler to the logger System.gc(); // logger configuration lost Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected }
OBL_UNSATISFIED_OBLIGATION
Method may fail to clean up stream or resource
這種方法可能無法清除（關(guān)閉，處置）一個(gè)流尤溜，數(shù)據(jù)庫對(duì)象倔叼，或其他資源需要一個(gè)明確的清理行動(dòng)。
一般來說宫莱，如果一個(gè)方法打開一個(gè)流或其他資源丈攒，該方法應(yīng)該使用try / finally塊來確保在方法返回之前流或資源已經(jīng)被清除了。這種錯(cuò)誤模式基本上和OS_OPEN_STREAM和ODR_OPEN_DATABASE_RESOURCE錯(cuò)誤模式相同，但是是在不同在靜態(tài)分析技術(shù)巡验。我們正為這個(gè)錯(cuò)誤模式的效用收集反饋意見际插。
其他文章（持續(xù)更新）
FindBugs：簡(jiǎn)介與使用
FindBugs 規(guī)則整理：CORRECTNESS
FindBugs 規(guī)則整理：Bad Practice
FindBugs 規(guī)則整理：Style & Dodgy
FindBugs 規(guī)則整理：Malicious Code Vulnerability
FindBugs 規(guī)則整理：Multithreaded Correctness
FindBugs 規(guī)則整理：Performance
FindBugs 規(guī)則整理：Internationalization
引用
整合以下文章過程中發(fā)現(xiàn)部分存在翻譯錯(cuò)誤，已做修正显设，同時(shí)感謝以下文章作者
FindBugs規(guī)則整理
