hudson.plugins.findbugs.find-sec-bugs-messages.xml Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of findbugs Show documentation
Show all versions of findbugs Show documentation
This plug-in generates the trend report for FindBugs,
an open source program which uses static analysis to look for bugs
in Java code.
<?xml version="1.0" encoding="UTF-8"?>
<MessageCollection xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="https://findbugs.googlecode.com/svn-history/r13419/trunk/findbugs/etc/messagecollection.xsd">
<Plugin>
<ShortDescription>Find Security Bugs</ShortDescription>
<Details>Highlight part of the source code that should be analyze in a security audit.
</Details>
</Plugin>
<!-- Predictable Pseudo Random Generator (PRG) -->
<Detector class="com.h3xstream.findsecbugs.PredictableRandomDetector">
<Details>Detect the use of predictable Pseudo Random Generator (PRG).
</Details>
</Detector>
<BugPattern type="PREDICTABLE_RANDOM">
<ShortDescription>Predictable Pseudo Random Generator (PRG)</ShortDescription>
<LongDescription>Use of {3} is predictable.</LongDescription>
<Details>
<![CDATA[
<p>The use of a predictable random value can lead to vulnerability in those contexts:</p>
<ul>
<li>CSRF token</li>
<li>password reset token (sent by email)</li>
<li>or any other secret value</li>
</ul>
<p>A quick fix would be to replace the instanciation of <b>java.util.Random</b> by <b>java.security.SecureRandom</b>.
<p>
<b>References</b><br/>
<a href="http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html">Cracking Random Number Generators - Part 1 (http://jazzy.id.au)</a><br/>
<a href="https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers">CERT: MSC02-J. Generate strong random numbers</a><br/>
<a href="http://cwe.mitre.org/data/definitions/330.html">CWE-330: Use of Insufficiently Random Values</a>
</p>
]]>
</Details>
</BugPattern>
<!-- Servlet parameter -->
<Detector class="com.h3xstream.findsecbugs.endpoint.ServletEndpointDetector">
<Details>Identify the unfilter value coming from ServletRequest and HttpServletRequest.
</Details>
</Detector>
<BugPattern type="SERVLET_PARAMETER">
<ShortDescription>Servlet parameter</ShortDescription>
<LongDescription>The method {3} return a String value that is control by the client.</LongDescription>
<Details>
<![CDATA[
<p>The Servlet can read GET and POST parameters from various method. The value obtain should be consider unsafe.
In may be needed to sanitize those values when calling sensitive api such as:</p>
<ul>
<li>SQL query (May lead to SQL injection)</li>
<li>File opening (May lead to path traversal)</li>
<li>Command execution (Potential Command injection)</li>
<li>HTML construction (Potential XSS)</li>
<li>etc...</li>
</ul>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSP">Request parameter</BugCode>
<BugPattern type="SERVLET_CONTENT_TYPE">
<ShortDescription>Request Content-Type</ShortDescription>
<LongDescription>The HTTP header Content-Type can be control by the client.</LongDescription>
<Details>
<![CDATA[
The HTTP header Content-Type can be control by the client.
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSCT">Request Content-Type</BugCode>
<BugPattern type="SERVLET_SERVER_NAME">
<ShortDescription>Request Hostname (ServerName/Host)</ShortDescription>
<LongDescription>The hostname received can often be control by the client.</LongDescription>
<Details>
<![CDATA[
<p>The hostname can often be control by the client. Both <code>ServletRequest.getServerName()</code> and
<code>HttpServletRequest.getHeader("Host")</code> have the same behavior which is to extract the <code>Host</code> header.</p>
<pre>
GET /testpage HTTP/1.1
Host: www.example.com
[...]
</pre>
<p>
The web container serving your application may redirect requests to your application by default. This would allow
a malicious user to place any value. It is recommended to have no assumption on the value and therefor to do proper
escaping and validation if needed.
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSSN">Request Server Name (Hostname)</BugCode>
<BugPattern type="SERVLET_SESSION_ID">
<ShortDescription>Request Session Id</ShortDescription>
<LongDescription>Request Session Id</LongDescription>
<Details>
<![CDATA[
<p>
The method <a href="http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getRequestedSessionId()"><code>HttpServletRequest.getRequestedSessionId()</code></a>
typically return the value of the cookie <code>JSESSIONID</code>.
</p>
<p>
The value pass to the client is generally an alphanumeric value (ie: <code>JSESSIONID=jp6q31lq2myn</code>). However the value can be altered by the client. The following HTTP request illustrate the potential deviation.
<pre>
GET /somePage HTTP/1.1
Host: yourwebsite.com
User-Agent: Mozilla/5.0
Cookie: JSESSIONID=Get ready to received any value!!??'''"e;>
</pre>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSSID">Request Session Id</BugCode>
<BugPattern type="SERVLET_QUERY_STRING">
<ShortDescription>Request Query String</ShortDescription>
<LongDescription>The query string can be any value.</LongDescription>
<Details>
<![CDATA[
<p>The query string is the concatenation of the GET parameters and values. Parameter others that those intended can
be passed.</p>
<p>For the url request <code>/app/servlet.htm?a=1&b=2</code>, the query string extract will be <code>a=1&b=2</code></p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSSQ">Request Query String</BugCode>
<BugPattern type="SERVLET_HEADER">
<ShortDescription>Request Header</ShortDescription>
<LongDescription>Request header can easily be alter by the client</LongDescription>
<Details>
<![CDATA[
<p>Request headers can easily be alter by the client. No assumption should be make that the request come from a regular browser.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSSH">Request Header</BugCode>
<BugPattern type="SERVLET_HEADER_REFERER">
<ShortDescription>Request Header "Referer"</ShortDescription>
<LongDescription>The header "Referer" can be easily spoofed by the client.</LongDescription>
<Details>
<![CDATA[
<p>
Behavior:
<ul>
<li>Any value can be assigned to this header (request coming from malicious user)</li>
<li>The "Referer" will not be present if the request was initiated from another origin that is secure (https).</li>
</ul>
</p>
<p>
Recommendations:
<ul>
<li>No access control should be base on this header.</li>
<li>No CSRF protection should be based only on this value (<a href="http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z14">Because it is optional</a>).</li>
</ul>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSSHR">Request Header "Referer"</BugCode>
<BugPattern type="SERVLET_HEADER_USER_AGENT">
<ShortDescription>Request Header "User-Agent"</ShortDescription>
<LongDescription>The header "User-Agent" can be easily spoofed by the client.</LongDescription>
<Details>
<![CDATA[
<p>The header "User-Agent" can be easily spoofed by the client. Adopting different behavior base on the User-Agent (for
crawler UA) is not recommended.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSSHUA">>Request Header "User-Agent"</BugCode>
<!-- Cookie usage -->
<Detector class="com.h3xstream.findsecbugs.endpoint.CookieDetector">
<Details>Identy direct cookie usage</Details>
</Detector>
<BugPattern type="COOKIE_USAGE">
<ShortDescription>Cookie usage</ShortDescription>
<LongDescription>Cookie value can be change by the client.</LongDescription>
<Details>
<![CDATA[
<p>The information store in the cookie should not be sensitive or related to the session. In most case, session
variables should be used. see HttpSession (HttpServletRequest.getSession())</p>
<p>Cookies can be use for information that need live longer than the session.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECCU">Cookie usage</BugCode>
<!-- Path traversal -->
<Detector class="com.h3xstream.findsecbugs.PathTraversalDetector">
<Details>Identify the different access to the filesystem that takes a path as parameter.</Details>
</Detector>
<BugPattern type="PATH_TRAVERSAL_IN">
<ShortDescription>Potential Path traversal (read file)</ShortDescription>
<LongDescription>An instance of {3} is created to read a file.</LongDescription>
<Details>
<![CDATA[
<p>A file is open to read its content. The path given is a <b>dynamic</b> parameter.</p>
<p>If unfiltered parameter is pass to this file API, content from an arbitrary path could be read.</p>
<p>This detector identify <b>potential</b> path transversal. In many case, the construct file path is not control
by the user. If it is the case, this bug instance can be ignored.</p>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC : Path Traversal</a><br/>
<a href="https://www.owasp.org/index.php/Path_Traversal">OWASP : Path Traversal</a><br/>
<a href="http://capec.mitre.org/data/definitions/126.html">CAPEC-126: Path Traversal</a><br/>
<a href="http://cwe.mitre.org/data/definitions/99.html">CWE-99: Improper Control of Resource Identifiers ('Resource Injection')</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECPTI">Path traversal to read file</BugCode>
<BugPattern type="PATH_TRAVERSAL_OUT">
<ShortDescription>Potential Path traversal (write file)</ShortDescription>
<LongDescription>An instance of {3} is created to write a file.</LongDescription>
<Details>
<![CDATA[
<p>The class selected is use to open a file handle using a <b>dynamic</b> parameter.</p>
<p>If unfiltered input is pass to this function, content could be writen to an arbitrary path.</p>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC-33 : Path Traversal</a><br/>
<a href="https://www.owasp.org/index.php/Path_Traversal">OWASP : Path Traversal</a><br/>
<a href="http://capec.mitre.org/data/definitions/126.html">CAPEC-126: Path Traversal</a><br/>
<a href="http://cwe.mitre.org/data/definitions/99.html">CWE-99: Improper Control of Resource Identifiers ('Resource Injection')</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECPTO">Path traversal to write file</BugCode>
<!-- Command injection -->
<Detector class="com.h3xstream.findsecbugs.CommandInjectionDetector">
<Details>Identify source of command injection</Details>
</Detector>
<BugPattern type="COMMAND_INJECTION">
<ShortDescription>Command Injection</ShortDescription>
<LongDescription>{3} is used to executed system command.</LongDescription>
<Details>
<![CDATA[
<p>The api highlight is used to executed system command. If unfiltered input is passed to this api, it can lead arbitrary command execution.</p>
<p>
<b>Reference</b><br/>
<a href="https://www.owasp.org/index.php/Command_Injection">OWASP : Command Injection</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECCI">Command Injection</BugCode>
<!-- Weak FilenameUtils method -->
<Detector class="com.h3xstream.findsecbugs.WeakFilenameUtilsMethodDetector">
<Details>Identify the usage of some FilenameUtils methods</Details>
</Detector>
<BugPattern type="WEAK_FILENAMEUTILS">
<ShortDescription>FilenameUtils partial filtering</ShortDescription>
<LongDescription>FilenameUtils.{3} doesn't filter NULL byte.</LongDescription>
<Details>
<![CDATA[
<p>Some FilenameUtils' methods doesn't filter nullbyte.</p>
<p>The risk come from the removal of characters following the NULL byte.
This removal can occurs with many system API (ie. usage of the File object).</p>
<p>
<b>Reference</b><br/>
<a href="http://projects.webappsec.org/w/page/13246949/Null%20Byte%20Injection">WASC-28: Null Byte Injection</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECWF">FilenameUtils partial filtering</BugCode>
<!-- Weak TrustManager -->
<Detector class="com.h3xstream.findsecbugs.crypto.WeakTrustManagerDetector">
<Details>Identify weak TrustManager implementation</Details>
</Detector>
<BugPattern type="WEAK_TRUST_MANAGER">
<ShortDescription>Weak TrustManager implementation</ShortDescription>
<LongDescription>The implementation of TrustManager is vulnerable to MITM attack.</LongDescription>
<Details>
<![CDATA[
<p>Empty TrustManager implementation are often used to connected easily to a host that is not signed by a root
<a href="http://en.wikipedia.org/wiki/Certificate_authority">certificate authority</a>. As a consequence, a
<a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">Man-in-the-middle attack</a>
can occurs since the client will be trusting any given certificate.
</p>
<p>
A TrustManager allowing specific certificates (based on a truststore for example) should be built.
Detail information for a proper implementation :
<a href="http://stackoverflow.com/a/6378872/89769">[1]</a> <a href="http://stackoverflow.com/a/5493452/89769">[2]</a>
</p>
<p>
<b>Reference</b><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04: Insufficient Transport Layer Protection</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECWTM">Identify weak TrustManager implementation</BugCode>
<!-- JAXWS -->
<Detector class="com.h3xstream.findsecbugs.endpoint.JaxWsEndpointDetector">
<Details>Identify web services endpoint that implements JAX-WS API</Details>
</Detector>
<BugPattern type="JAXWS_ENDPOINT">
<ShortDescription>JAX-WS (JSR224) endpoint</ShortDescription>
<LongDescription>{0}.{1} is SOAP Web Service endpoint</LongDescription>
<Details>
<![CDATA[
<p>This method is part of a SOAP Web Service.</p>
<p>
<b>Analysis needed</b>
<ul>
<li>The inputs should be track for potential vulnerability.</li>
<li>The authentification (if inforce) should be tested using a web client.</li>
<li>The communication should ideally be over SSL.</li>
</ul>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECJWS">JAX-WS (JSR224) endpoint</BugCode>
<!-- JAXRS -->
<Detector class="com.h3xstream.findsecbugs.endpoint.JaxRsEndpointDetector">
<Details>Identify web services endpoint that implements JAX-RS API</Details>
</Detector>
<BugPattern type="JAXRS_ENDPOINT">
<ShortDescription>JAX-RS (JSR311) endpoint</ShortDescription>
<LongDescription>{0}.{1} is REST Web Service endpoint</LongDescription>
<Details>
<![CDATA[
<p>This method is part of a REST Web Service.</p>
<p>
<b>Analysis needed</b>
<ul>
<li>The input should be track for potential vulnerability.</li>
<li>The authentification (if inforce) should be tested using a web client.</li>
<li>The communication should ideally be over SSL.</li>
<li>If the method allow include GET/POST, CSRF vulnerability should investigate.<sup>[1]</sup></li>
</ul>
</p>
<p>
1. <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)">OWASP - Cross-Site Request Forgery</a>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECJRS">JAX-RS (JSR311) endpoint</BugCode>
<!-- Tapestry -->
<Detector class="com.h3xstream.findsecbugs.endpoint.TapestryEndpointDetector">
<Details>Identify Tapestry "Pages" that serve as input</Details>
</Detector>
<BugPattern type="TAPESTRY_ENDPOINT">
<ShortDescription>Tapestry Page</ShortDescription>
<LongDescription>{0} is a Tapestry Page</LongDescription>
<Details>
<![CDATA[
<p>Tapestry endpoint are discover at the application startup and are requires to be in <code>[base.package.name].pages</code>.
When a request is received, the GET/POST parameters are mapped to field. The mapping is either done with fieldName:</p>
<pre><code>
[...]
protected String input;
[...]
</code></pre>
<p>or
the definition of an explicit annotation:
</p>
<pre><code>
[...]
@org.apache.tapestry5.annotations.Parameter
protected String parameter1;
@org.apache.tapestry5.annotations.Component(id = "password")
private PasswordField passwordField;
[...]
</code></pre>
<p>The page is mapped to the view <code>[/package/PageName].tml.</code></p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECTE">Tapestry Page</BugCode>
<!-- Wicket -->
<Detector class="com.h3xstream.findsecbugs.endpoint.WicketEndpointDetector">
<Details>Identify Wicket "WebPages" that serve as input</Details>
</Detector>
<BugPattern type="WICKET_ENDPOINT">
<ShortDescription>Wicket WebPage</ShortDescription>
<LongDescription>{0} is a Wicket WebPage</LongDescription>
<Details>
<![CDATA[
<p>This class represent a Wicket WebPage.</p>
<p>The input are read from a PageParameters instance passed to the constructor.</p>
<p>The current page is mapped to the view [/package/WebPageName].html.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECWE">Wicket WebPage</BugCode>
<!-- Weak Message Digest -->
<Detector class="com.h3xstream.findsecbugs.crypto.WeakMessageDigestDetector">
<Details>Identify the use of weak MessageDigest that could be replace recommended standards.</Details>
</Detector>
<BugPattern type="WEAK_MESSAGE_DIGEST">
<ShortDescription>Weak MessageDigest</ShortDescription>
<LongDescription>{3} is not a recommended MessageDigest</LongDescription>
<Details>
<![CDATA[
<p>The algorithm used is not a recommended MessageDigest.</p>
<p>The <a href="http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html">NIST</a> recommended to use either SHA-1, SHA-224*, SHA-256, SHA-384 or SHA-512.</p>
<p><small>* SHA-224 algorithm is not provided by <a href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SUNProvider"> SUN provider.</a></small></p>
<p>
<b>Reference</b><br/>
<a href="http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html">NIST Approved Algorithms</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECWMD">Weak MessageDigest</BugCode>
<!-- Custom Message Digest -->
<Detector class="com.h3xstream.findsecbugs.crypto.CustomMessageDigestDetector">
<Details>Identify the implementation of custom MessageDigest</Details>
</Detector>
<BugPattern type="CUSTOM_MESSAGE_DIGEST">
<ShortDescription>Custom MessageDigest</ShortDescription>
<LongDescription>{0} is a custom MessageDigest</LongDescription>
<Details>
<![CDATA[
<p>Implementing custom MessageDigest is error-prone.</p>
<p>The <a href="http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html">NIST</a> recommended to use either SHA-1, SHA-224*, SHA-256, SHA-384 or SHA-512.</p>
<p><small>* SHA-224 algorithm is not provided by <a href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SUNProvider"> SUN provider.</a></small></p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECCMD">Custom MessageDigest</BugCode>
<!-- FileUpload Filename -->
<Detector class="com.h3xstream.findsecbugs.FileUploadFilenameDetector">
<Details>The filename given by FileUpload api can be tampered by the client.</Details>
</Detector>
<BugPattern type="FILE_UPLOAD_FILENAME">
<ShortDescription>Tainted filename read</ShortDescription>
<LongDescription>The filename read can be tampered by the client</LongDescription>
<Details>
<![CDATA[
<p>The filename given by FileUpload api can be tampered by the client.</p>
<p>It can take value such as:</p>
<ul>
<li><code>"../../../config/overide_file"</code></li>
<li><code>"shell.jsp\u0000expected.gif"</code></li>
</ul>
<p>Therefore it should not be passed directly to filesystem api. If acceptable, a new filename should be picked.
Otherwise, the original filename should be properly escaped.</p>
<p>
<b>Reference</b><br/>
<a href="http://blogs.securiteam.com/index.php/archives/1268">Securiteam: File upload security recommendations</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECFUN">Tainted filename read</BugCode>
<!-- ReDOS -->
<Detector class="com.h3xstream.findsecbugs.ReDosDetector">
<Details>The regular expression can grow exponentially with some input.</Details>
</Detector>
<BugPattern type="REDOS">
<ShortDescription>ReDOS</ShortDescription>
<LongDescription>The regular expression "{0}" is vulnerable to ReDOS</LongDescription>
<Details>
<![CDATA[
<p>
ReDOS stands for Regular expression Denial of Service. The regular expression (RegEx) identify may take a large amount of time
when analysing certain strings.
</a>
<p>
For example the following RegEx, the input "<code>aaaaaaaaaaaaaaaaX</code>" will cause the RegEx engine to analyse 65536 different paths.<sup>[1] Example taken from OWASP referecen</sup>
<pre>^(a+)+$</pre>
Therefore, it is possible that a single request cause a large amount of computation on the server side.
</p>
<p>
<b>References</b><br/>
<a href="http://www.jroller.com/sebastianKuebeck/entry/detecting_and_preventing_redos_vulnerabilities">Sebastian Kubeck's Weblog: Detecting and Preventing ReDoS Vulnerabilities</a><br/>
<sup>[1]</sup> <a href="https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS">OWASP : Regular expression Denial of Service</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECRD">ReDOS</BugCode>
<!-- SAXParser XXE -->
<Detector class="com.h3xstream.findsecbugs.xxe.SaxParserXxeDetector">
<Details>Identify SAXParser usage vulnerable to XXE</Details>
</Detector>
<BugPattern type="XXE">
<ShortDescription>XML parsing vulnerable to XXE attacks</ShortDescription>
<LongDescription>The usage of {3} is vulnerable to Xml External Entity attacks</LongDescription>
<Details>
<![CDATA[
<p>Xml External Entity attacks can occurs when the XML parsers support XML entities and received
user input as XML content.</p>
<b>Risk 1: Expose local file content</b>
<p>
<pre>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>
</pre>
</p>
<b>Risk 2: Denial of service</b>
<p>
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE s [
<!ENTITY x "OVERLONG_CONTENT_HERE_WITH_MORE_THAN_10^5_CHARACTERS">
]>
<foo>
&x;
&x;
[...]
</foo>
</pre>
</p>
<p>
<b>References</b><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61702260">CERT: IDS10-J. Prevent XML external entity attacks</a><br/>
<a href="https://www.owasp.org/index.php/Testing_for_XML_Injection_(OWASP-DV-008)">OWASP : Testing for XML Injection</a><br/>
<a href="http://clawslab.nds.rub.de/wiki/index.php/XML_Generic_Entity_Expansion">WS-Attacks.org: XML Generic Entity Expansion</a><br/>
<a href="http://clawslab.nds.rub.de/wiki/index.php/XML_External_Entity_DOS">WS-Attacks.org: XML External Entity DOS</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECXXE">XML parsing vulnerable to XXE attacks</BugCode>
<!-- XPath Injection for Javax -->
<Detector class="com.h3xstream.findsecbugs.xpath.XPathInjectionJavaxDetector">
<Details>Find XPath query that use tainted input (javax.xml api)</Details>
</Detector>
<Detector class="com.h3xstream.findsecbugs.xpath.XPathInjectionApacheXPathApiDetector">
<Details>Find XPath query that use tainted input (org.apache.xpath api)</Details>
</Detector>
<BugPattern type="XPATH_INJECTION">
<ShortDescription>Potential XPath Injection</ShortDescription>
<LongDescription>The use of {3} is vulnerable to XPath injection</LongDescription>
<Details>
<![CDATA[
<p>
XPath injection risks are simlar to SQL injection. If the XPath query contain unfilter user input, the complete datasource
could be expose.
</p>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-39: XPath Injection</a><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61407250">CERT: IDS09-J. Prevent XPath Injection (archive)</a><br/>
<a href="http://media.blackhat.com/bh-eu-12/Siddharth/bh-eu-12-Siddharth-Xpath-WP.pdf">Black Hat Europe 2012: Hacking XPath 2.0</a><br/>
<a href="http://www.balisage.net/Proceedings/vol7/html/Vlist02/BalisageVol7-Vlist02.html">Balisage: XQuery Injection</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECXPI">XPath Injection</BugCode>
<!-- Struts1 -->
<Detector class="com.h3xstream.findsecbugs.endpoint.Struts1EndpointDetector">
<Details>Identify Struts 1 endpoint (also called Action)</Details>
</Detector>
<BugPattern type="STRUTS1_ENDPOINT">
<ShortDescription>Struts 1 Action</ShortDescription>
<LongDescription>{0} is a Struts 1 endpoint</LongDescription>
<Details>
<![CDATA[
<p>This class is a Struts Action.</p>
<p>Once a request is route to this controller, a Form object will be builded that constains
the HTTP parameters.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSTR1">Struts 1 Action</BugCode>
<!-- Struts2 -->
<Detector class="com.h3xstream.findsecbugs.endpoint.Struts2EndpointDetector">
<Details>Identify Struts 2 endpoint</Details>
</Detector>
<BugPattern type="STRUTS2_ENDPOINT">
<ShortDescription>Struts 2 endpoint</ShortDescription>
<LongDescription>{0} is a Struts 2 endpoint</LongDescription>
<Details>
<![CDATA[
<p>In struts 2, the endpoint are Plain Old Java Object (POJO) which means no Interface/Class are implements/extends.</p>
<p>When a request is route to its controller (like the selected class). The different HTTP parameters are mapped to setter of
the class. Therefor all setter of this class should be consider as input even if the form expected to be used doesn't include
all of them.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSTR2">Struts 2 endpoint</BugCode>
<!-- Spring Controller -->
<Detector class="com.h3xstream.findsecbugs.endpoint.SpringMvcEndpointDetector">
<Details>Identify Spring Controller (also called Controller)</Details>
</Detector>
<BugPattern type="SPRING_ENDPOINT">
<ShortDescription>Spring endpoint</ShortDescription>
<LongDescription>{0} is a Spring controller</LongDescription>
<Details>
<![CDATA[
<p>This class is a Spring Controller. All method annotated with <code>RequestMapping</code> are reachable remotely.</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSC">Spring Controller</BugCode>
<!-- Sql Injection -->
<Detector class="com.h3xstream.findsecbugs.injection.sql.SqlInjectionDetector">
<Details>Identify various kind of SQL Injection in API that accepts strings.</Details>
</Detector>
<BugPattern type="SQL_INJECTION">
<ShortDescription>Potential SQL Injection</ShortDescription>
<LongDescription>The query is vulnerable SQL injection</LongDescription>
<Details>
<![CDATA[
<p>
The input values associated to the SQL queries should be escape properly. Prepare statement can be use to easily mitigate the risk
(Available for all major API : JDO, JPA and Hibernate). Alternatively, typed API such as Hibernate Criteria and Querydsl
can be used.
</p>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSQLI">SQL Injection</BugCode>
<!-- LDAP Injection -->
<Detector class="com.h3xstream.findsecbugs.injection.ldap.LdapDetector">
<Details>Identify various kind of LDAP Injection in JNDI and UnboundId API.</Details>
</Detector>
<BugPattern type="LDAP_INJECTION">
<ShortDescription>Potential LDAP Injection</ShortDescription>
<LongDescription>The query could be vulnerable LDAP injection</LongDescription>
<Details>
<![CDATA[
<p>
Just like SQL query, all inputs place inside LDAP query should be escape properly.
</p>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246947/LDAP%20Injection">WASC-29: LDAP Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/90.html">CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')</a><br/>
<a href="http://www.veracode.com/security/ldap-injection">LDAP Injection Guide: Learn How to Detect LDAP Injections and Improve LDAP Security</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECLDAPI">LDAP Injection</BugCode>
<!-- Bad Hexa -->
<Detector class="com.h3xstream.findsecbugs.crypto.BadHexadecimalConversionDetector">
<Details>Identify Bad hexadecimal concatenation</Details>
</Detector>
<BugPattern type="BAD_HEXA_CONVERSION">
<ShortDescription>Bad hexadecimal concatenation</ShortDescription>
<LongDescription>Identify bad hexadecimal concatenation</LongDescription>
<Details>
<![CDATA[
<p>When converting a byte array to a string, a conversion mistake can be made if the array is read byte by byte.
The following sample illustrate the use of Integer.toHexString() which will trim the trailling "0".
<pre>
MessageDigest md = MessageDigest.getInstance("SHA-1");
byte[] resultBytes = md.digest(password.getBytes("UTF-8"));
StringBuilder stringBuilder = new StringBuilder();
for(byte b :resultBytes) {
stringBuilder.append( Integer.toHexString( b & 0xFF ) );
}
return stringBuilder.toString();
</pre>
</p>
<p>
This mistake can weaken the hashing function use since more collisions are introduce.<br/>
The values "0x0679" "0x6709" would become "679".
</p>
<p>
In this situation, the use of toHexString() should be replace by a String.format() as follow.
<pre>
stringBuilder.append( String.format( "%02X", b ) );
</pre>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECBHC">Bad hexadecimal concatenation</BugCode>
<!-- ECB Mode -->
<Detector class="com.h3xstream.findsecbugs.crypto.EcbModeDetector">
<Details>ECB mode used</Details>
</Detector>
<BugPattern type="ECB_MODE">
<ShortDescription>ECB mode used</ShortDescription>
<LongDescription>The cipher chosen use ECB mode</LongDescription>
<Details>
<![CDATA[
<p>A CBC mode cipher should be used instead of ECB mode.</p>
<p>
<b>References</b><br/>
<a href="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29">Wikipedia: Block cipher modes of operation</a><br/>
<a href="http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf">NIST: Recommendation for Block Cipher Modes of Operation</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECECB">Bad hexadecimal concatenation</BugCode>
<!-- Hazelcast Symmetric encryption -->
<Detector class="com.h3xstream.findsecbugs.crypto.HazelcastSymmetricEncryptionDetector">
<Details>Hazelcast Symmetric encryption</Details>
</Detector>
<BugPattern type="HAZELCAST_SYMMETRIC_ENCRYPTION">
<ShortDescription>Hazelcast Symmetric encryption</ShortDescription>
<LongDescription>The network communication for Hazelcast are configure to symmetric cipher</LongDescription>
<Details>
<![CDATA[
<p>The network communication for Hazelcast is configure to a symmetric cipher (probably DES or blowfish).</p>
<p>Those ciphers alone do not provide integrity or secure authentification.</a>.
The use of assymetric encryption should be privilege.</p>
<p>
<b>Reference</b><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04 : Insufficient Transport Layer Protection</a><br/>
<a href="http://www.hazelcast.com/documentation.jsp#Encryption">Hazelcast Documentation : Encryption (see second part)</a><br/>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECHAZ">Hazelcast Symmetric encryption</BugCode>
<!-- NullCipher's use -->
<Detector class="com.h3xstream.findsecbugs.crypto.NullCipherDetector">
<Details>Identify the use of NullCipher</Details>
</Detector>
<BugPattern type="NULL_CIPHER">
<ShortDescription>The use of NullCipher might be unwanted</ShortDescription>
<LongDescription>The use of NullCipher might be unwanted</LongDescription>
<Details>
<![CDATA[
<p>
The NullCipher is rarelly use. It implement the Cipher interface by returning a ciphertext identical to the plaintext.
In few context including testing, NullCipher can be appropriate.
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECNC">Bad hexadecimal concatenation</BugCode>
<!-- Unencrypted Socket encryption -->
<Detector class="com.h3xstream.findsecbugs.crypto.UnencryptedSocketDetector">
<Details>Unencrypted socket</Details>
</Detector>
<BugPattern type="UNENCRYPTED_SOCKET">
<ShortDescription>Unencrypted socket</ShortDescription>
<LongDescription>Unencrypted socket to {0} (instead of SSLSocket)</LongDescription>
<Details>
<![CDATA[
<p>
The communication started will not be encrypted. The traffic could be red by an attacker intercepting the communication.
</p>
<p>
Plain socket (Clear text communication):
<pre>Socket soc = new Socket("www.google.com",80);</pre>
</p>
<p>
SSL Socket (Secure communication):
<pre>Socket soc = SSLSocketFactory.getDefault().createSocket("www.google.com", 443);</pre>
</p>
<p>
<b>Reference</b><br/>
<a href="https://www.owasp.org/index.php/Top_10_2010-A9">OWASP : Insufficient Transport Layer Protection</a><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04 : Insufficient Transport Layer Protection</a><br/>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECUS">Unencrypted socket</BugCode>
<!-- Static Initialization vector -->
<!-- Not implemented yet..
<Detector class="com.h3xstream.findsecbugs.crypto.StaticIvDetector">
<Details></Details>
</Detector>
<BugPattern type="STATIC_IV">
<ShortDescription>Static IV</ShortDescription>
<LongDescription>Static IV use to encrypt messages</LongDescription>
<Details>
<![CDATA[
<p>
The purpose of the <b>Initialization Vector</b> is to avoid generating the same cipher-text for the same message.
The IV value should be random and different for every message sent.
</p>
<p>
Also, the IV should not be consider as a secret because it can be sent with the message.
</p>
<p>
<b>Reference</b><br/>
<a href="http://en.wikipedia.org/wiki/Initialization_vector">Wikipedia: Initialization vector</a><br/>
<a href="https://defuse.ca/cbcmodeiv.htm">Defuse.ca: Encryption - CBC Mode IV: Secret or Not?</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSIV"></BugCode>
-->
<!-- DES usage -->
<Detector class="com.h3xstream.findsecbugs.crypto.DesUsageDetector">
<Details>DES / DESede should be replace by AES</Details>
</Detector>
<BugPattern type="DES_USAGE">
<ShortDescription>DES / DESede usage</ShortDescription>
<LongDescription>DES / DESede should be replace by AES</LongDescription>
<Details>
<![CDATA[
<p>
DES and DESede (3DES), previously recommended, are not consider strong ciphers for modern applications. DESede should
only be use because of hardware limitation. Currently, the NIST recommend the usage of AES block cipher.
</p>
<p>
<b>References</b><br/>
<a href="http://www.nist.gov/itl/fips/060205_des.cfm">NIST Withdraws Outdated Data Encryption Standard</a><br/>
<a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327: Use of a Broken or Risky Cryptographic Algorithm</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECDU">DES / DESede usage</BugCode>
<!-- RSA NoPadding -->
<Detector class="com.h3xstream.findsecbugs.crypto.RsaNoPaddingDetector">
<Details>RSA cipher without proper padding</Details>
</Detector>
<BugPattern type="RSA_NO_PADDING">
<ShortDescription>RSA NoPadding</ShortDescription>
<LongDescription>RSA cipher without proper padding</LongDescription>
<Details>
<![CDATA[
<p>
The software uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
</p>
<p>
Weak example:<br/>
<pre>Cipher.getInstance("RSA/NONE/NoPadding")</pre>
</p>
<p>
It should be replace by:<br/>
<pre>Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")</pre>
</p>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/780.html">CWE-780: Use of RSA Algorithm without OAEP</a><br/>
<a href="http://rdist.root.org/2009/10/06/why-rsa-encryption-padding-is-critical/">Root Labs: Why RSA encryption padding is critical</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECRNP">RSA NoPadding</BugCode>
<!-- Hard code password -->
<Detector class="com.h3xstream.findsecbugs.password.GoogleApiKeyDetector">
<Details>Identify hardcode Google API key</Details>
</Detector>
<BugPattern type="HARD_CODE_PASSWORD">
<ShortDescription>Hard code password</ShortDescription>
<LongDescription>Hard code password</LongDescription>
<Details>
<![CDATA[
<p>
Password should not be kept in the source code. The source code are widely share in the entreprise environement.
Passwords and secret keys can be managed more easily when being separated in configuration files or keystores.
</p>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/321.html">CWE-321: Use of Hard-coded Cryptographic Key</a><br/>
<a href="http://cwe.mitre.org/data/definitions/259.html">CWE-259: Use of Hard-coded Password</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECHCP">Hard code password</BugCode>
<!-- Struts Form Validation -->
<Detector class="com.h3xstream.findsecbugs.StrutsValidatorFormDetector">
<Details>Identify Struts Form with no input validation</Details>
</Detector>
<BugPattern type="STRUTS_FORM_VALIDATION">
<ShortDescription>Struts Form with no input validation</ShortDescription>
<LongDescription>Struts Form with no input validation</LongDescription>
<Details>
<![CDATA[
<p>
Form inputs should have minimal input validation. Preventive validation can possibly mitigate unknown risk.
</p>
<p>
Validation can be introduce by implementing a <code>validate</code> method.
<pre>
public class RegistrationForm extends ValidatorForm {
private String name;
private String email;
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
//Validate the properties
}
[...]
}
</pre>
</p>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/106.html">CWE-106: Struts: Plug-in Framework not in Use</a>
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECSFV">Struts Form with no input validation</BugCode>
<!-- XSS Filter -->
<Detector class="com.h3xstream.findsecbugs.xss.XSSRequestWrapperDetector">
<Details>Identify XSSRequestWrapper (weak XSS protection)</Details>
</Detector>
<BugPattern type="XSS_REQUEST_WRAPPER">
<ShortDescription>XSSRequestWrapper is a weak XSS protection</ShortDescription>
<LongDescription>XSSRequestWrapper is a weak XSS protection</LongDescription>
<Details>
<![CDATA[
<p>
A implementation of <code>HttpServletRequestWrapper</code> called <code>XSSRequestWrapper</code> was publish through
various blog sites. <sup><a href="http://java.dzone.com/articles/stronger-anti-cross-site">[1]</a></sup>
<sup><a href="http://www.javacodegeeks.com/2012/07/anti-cross-site-scripting-xss-filter.html">[2]</a></sup>
</p>
<p>
The filtering is weak for few reasons:
<ul>
<li>It covers only parameters not headers and side-channel inputs</li>
<li>The replace chain can be bypass easly (see example below)</li>
<li>It's a black list of very specific patterns</li>
</ul>
</p>
<p>
<b>Example of bypass</b><br/>
</p>
<pre><scrivbscript:pt>alert(1)</scrivbscript:pt></pre>
<p>
The previous input will be transform to <b><code>"<script>alert(1)</script>"</code></b>.
The removal of <code>"vbscript:"</code> is after the replacement of <code>"<script>.*</script>"</code>.
</p>
<p>
For an indepth protection, choose solution that filter characters automatically in the <b><u>view</u></b> (template, jsp, ...).
</p>
]]>
</Details>
</BugPattern>
<BugCode abbrev="SECXRW">Hard code password</BugCode>
</MessageCollection> © 2015 - 2025 Weber Informatics LLC | Privacy Policy