Severity | Number of Issues | |
---|---|---|
BLOCKER | 4 | |
CRITICAL | 0 | |
MAJOR | 0 | |
MINOR | 0 |
Rule | Severity | Component | Line | Description | Message |
---|---|---|---|---|---|
squid:S2068 | BLOCKER | xxe/src/main/java/org/owasp/webgoat/plugin/User.java | 38 | Credentials should not be hard-coded | 'password' detected in this expression, review this potentially hardcoded credential. |
squid:S2068 | BLOCKER | challenge/src/main/java/org/owasp/webgoat/plugin/SolutionConstants.java | 12 | Credentials should not be hard-coded | 'PASSWORD' detected in this expression, review this potentially hardcoded credential. |
squid:S2068 | BLOCKER | challenge/src/main/java/org/owasp/webgoat/plugin/SolutionConstants.java | 13 | Credentials should not be hard-coded | 'PASSWORD' detected in this expression, review this potentially hardcoded credential. |
squid:S2068 | BLOCKER | challenge/src/main/java/org/owasp/webgoat/plugin/SolutionConstants.java | 14 | Credentials should not be hard-coded | 'PASSWORD' detected in this expression, review this potentially hardcoded credential. |
Rule | Description |
---|---|
squid:S3318 |
Data in a web session is considered inside the "trust boundary". That is, it is assumed to be trustworthy. But storing unvetted data from an unauthenticated user violates the trust boundary, and may lead to that data being used inappropriately. This rule raises an issue when data from Noncompliant Code Examplelogin = request.getParameter("login"); session.setAttribute("login", login); // Noncompliant See
|
squid:S1148 |
Loggers should be used instead to print
This rule raises an issue when Noncompliant Code Exampletry { /* ... */ } catch(Exception e) { e.printStackTrace(); // Noncompliant } Compliant Solutiontry { /* ... */ } catch(Exception e) { LOGGER.log("context", e); } |
squid:S2386 |
There is no good reason to have a mutable object as the Similarly, mutable Note that making a mutable field, such as an array, This rule raises issues for Noncompliant Code Examplepublic interface MyInterface { public static String [] strings; // Noncompliant } public class A { public static String [] strings1 = {"first","second"}; // Noncompliant public static String [] strings2 = {"first","second"}; // Noncompliant public static List<String> strings3 = new ArrayList<>(); // Noncompliant // ... } See
|
squid:S3355 |
Every filter defined in Noncompliant Code Example<filter> <filter-name>DefinedNotUsed</filter-name> <filter-class>com.myco.servlet.ValidationFilter</filter-class> </filter> Compliant Solution<filter> <filter-name>ValidationFilter</filter-name> <filter-class>com.myco.servlet.ValidationFilter</filter-class> </filter> <filter-mapping> <filter-name>ValidationFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> See
|
squid:S2384 |
Mutable objects are those whose state can be changed. For instance, an array is mutable, but a String is not. Mutable class members should never be returned to a caller or accepted and stored directly. Doing so leaves you vulnerable to unexpected changes in your class state. Instead use an unmodifiable This rule checks that arrays, collections and Dates are not stored or returned directly. Noncompliant Code Exampleclass A { private String [] strings; public A () { strings = new String[]{"first", "second"}; } public String [] getStrings() { return strings; // Noncompliant } public void setStrings(String [] strings) { this.strings = strings; // Noncompliant } } public class B { private A a = new A(); // At this point a.strings = {"first", "second"}; public void wreakHavoc() { a.getStrings()[0] = "yellow"; // a.strings = {"yellow", "second"}; } } Compliant Solutionclass A { private String [] strings; public A () { strings = new String[]{"first", "second"}; } public String [] getStrings() { return strings.clone(); } public void setStrings(String [] strings) { this.strings = strings.clone(); } } public class B { private A a = new A(); // At this point a.strings = {"first", "second"}; public void wreakHavoc() { a.getStrings()[0] = "yellow"; // a.strings = {"first", "second"}; } } See
|
squid:S3369 |
Websphere, Tomcat, and JBoss web servers allow the definition of role-based access to servlets. It may not be granular enough for your purposes, but it's a start, and should be used at least as a base. This rule raises an issue when a web.xml file has no See
|
squid:S2039 |
Failing to explicitly declare the visibility of a member variable could result it in having a visibility you don't expect, and potentially leave it open to unexpected modification by other classes. Noncompliant Code Exampleclass Ball { String color="red"; // Noncompliant } enum A { B; int a; } Compliant Solutionclass Ball { private String color="red"; // Compliant } enum A { B; private int a; } ExceptionsMembers annotated with Guava's class Cone { @VisibleForTesting Logger logger; // Compliant } |
squid:S2278 |
According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:
For similar reasons, RC2 should also be avoided. Noncompliant Code ExampleCipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding"); Compliant SolutionCipher c = Cipher.getInstance("AES/GCM/NoPadding"); See
|
squid:S2277 |
Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an
issue as soon as a literal value starts with Noncompliant Code ExampleCipher rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding"); Compliant SolutionCipher rsa = javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING"); See
|
squid:S2245 |
When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the Noncompliant Code ExampleRandom random = new Random(); byte bytes[] = new byte[20]; random.nextBytes(bytes); Compliant SolutionSecureRandom random = new SecureRandom(); byte bytes[] = new byte[20]; random.nextBytes(bytes); See
|
squid:S2258 |
By contract, the Noncompliant Code ExampleNullCipher nc=new NullCipher(); See
|
squid:S2257 |
The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has
been protected. Standard algorithms like This rule tracks creation of Noncompliant Code ExampleMyCryptographicAlgorithm extends MessageDigest { ... } See
|
squid:S2254 |
According to the Oracle Java API, the
The session ID it returns is either transmitted in a cookie or a URL parameter so by definition, nothing prevents the end-user from manually updating the value of this session ID in the HTTP request. Here is an example of a updated HTTP header: GET /pageSomeWhere HTTP/1.1 Host: webSite.com User-Agent: Mozilla/5.0 Cookie: JSESSIONID=Hacked_Session_Value'''"> Due to the ability of the end-user to manually change the value, the session ID in the request should only be used by a servlet container (E.G. Tomcat or Jetty) to see if the value matches the ID of an an existing session. If it does not, the user should be considered unauthenticated. Moreover, this session ID should never be logged to prevent hijacking of active sessions. Noncompliant Code Exampleif(isActiveSession(request.getRequestedSessionId()) ){ ... } See
|
squid:S2976 |
Using This rule raises an issue when the following steps are taken in immediate sequence:
Note that this rule is automatically disabled when the project's Noncompliant Code ExampleFile tempDir; tempDir = File.createTempFile("", "."); tempDir.delete(); tempDir.mkdir(); // Noncompliant Compliant SolutionPath tempPath = Files.createTempDirectory(""); File tempDir = tempPath.toFile(); See
|
squid:S3751 |
A So marking a sensitive method Noncompliant Code Example@RequestMapping("/greet", method = GET) private String greet(String greetee) { // Noncompliant Compliant Solution@RequestMapping("/greet", method = GET) public String greet(String greetee) { |
squid:S1313 |
Hardcoding an IP address into source code is a bad idea for several reasons:
Noncompliant Code ExampleString ip = "127.0.0.1"; Socket socket = new Socket(ip, 6667); Compliant SolutionString ip = System.getProperty("myapplication.ip"); Socket socket = new Socket(ip, 6667); See
|
squid:S1444 |
There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a
state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to
Noncompliant Code Examplepublic class Greeter { public static Foo foo = new Foo(); ... } Compliant Solutionpublic class Greeter { public static final Foo FOO = new Foo(); ... } See
|
squid:S2653 |
There is no reason to have a This rule raises an issue when a Noncompliant Code Examplepublic class MyServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { if (userIsAuthorized(req)) { updatePrices(req); } } public static void main(String[] args) { // Noncompliant updatePrices(req); } } See
|
squid:S3749 |
Spring Having non-injected members in one of these classes could indicate an attempt to manage state. Because they are singletons, such an attempt is almost guaranteed to eventually expose data from User1's session to User2. This rule raises an issue when a singleton
Noncompliant Code Example@Controller public class HelloWorld { private String name = null; @RequestMapping("/greet", method = GET) public String greet(String greetee) { if (greetee != null) { this.name = greetee; } return "Hello " + this.name; // if greetee is null, you see the previous user's data } } |
squid:S2658 |
Dynamically loaded classes could contain malicious code executed by a static class initializer. I.E. you wouldn't even have to instantiate or explicitly invoke methods on such classes to be vulnerable to an attack. This rule raises an issue for each use of dynamic class loading. Noncompliant Code ExampleString className = System.getProperty("messageClassName"); Class clazz = Class.forName(className); // Noncompliant See
|
squid:S1989 |
Even though the signatures for methods in a servlet include This rule checks all exceptions in methods named "do*" are explicitly handled in servlet classes. Noncompliant Code Examplepublic void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String ip = request.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); // Noncompliant; getByName(String) throws UnknownHostException //... } Compliant Solutionpublic void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { try { String ip = request.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); //... } catch (UnknownHostException uhex) { //... } } See
|
squid:S2068 |
Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to end up in the hands of an attacker. This is particularly true for applications that are distributed. Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database. Noncompliant Code ExampleConnection conn = null; try { conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" + "user=steve&password=blue"); // Noncompliant String uname = "steve"; String password = "blue"; conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" + "user=" + uname + "&password=" + password); // Noncompliant java.net.PasswordAuthentication pa = new java.net.PasswordAuthentication("userName", "1234".toCharArray()); // Noncompliant Compliant SolutionConnection conn = null; try { String uname = getEncryptedUser(); String password = getEncryptedPass(); conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" + "user=" + uname + "&password=" + password); See
|
squid:S2078 |
Applications that execute LDAP queries should neutralize any externally-provided values in those commands. Failure to do so could allow an attacker to include input that changes the query so that unintended commands are executed, or sensitive data is exposed. Unhappily LDAP doesn't provide any prepared statement interfaces like SQL to easily remove this risk. So each time a LDAP query is built dynamically this rule logs an issue. Noncompliant Code Examplepublic User lookupUser(String username, String base, String [] requestedAttrs) { // ... DirContext dctx = new InitialDirContext(env); SearchControls sc = new SearchControls(); sc.setReturningAttributes(requestedAttrs); // Noncompliant sc.setSearchScope(SearchControls.SUBTREE_SCOPE); String filter = "(&(objectClass=user)(sAMAccountName=" + username + "))"; NamingEnumeration results = dctx.search(base, // Noncompliant filter, // Noncompliant; parameter concatenated directly into string sc); Compliant Solutionpublic User lookupUser(String username, String base, String [] requestedAttrs) { // ... DirContext dctx = new InitialDirContext(env); SearchControls sc = new SearchControls(); sc.setReturningAttributes(buildAttrFilter(requestedAttrs)); // Compliant; method presumably scrubs input sc.setSearchScope(SearchControls.SUBTREE_SCOPE); String useBase = "ou=People"; if (! base.startsWith(useBase)) { useBase = base; } String filter = "(&(objectClass=user)(sAMAccountName=" + username.replaceAll("[()| ]","") + "))"; NamingEnumeration results = dctx.search(useBase, // Compliant; originally value used conditionally filter, // Compliant; parameter NOT concatenated directly into string sc); See
|
squid:S2076 |
Applications that execute operating system commands or execute commands that interact with the underlying system should neutralize any externally-provided values used in those commands. Failure to do so could allow an attacker to include input that executes unintended commands, or exposes sensitive data. This rule logs issues for dynamically-built commands, and when parameter values are used to influence how a command is run. it's then up to the auditor to figure out if the command execution is secure or not. Noncompliant Code Examplepublic void listContent(String input) { Runtime rt = Runtime.getRuntime(); rt.exec("ls " + input); // Noncompliant; input could easily contain extra commands ... } public void execute(String command, String argument) { ProcessBuilder pb = new ProcessBuilder(command, argument); // Noncompliant ... } public void doTheThing(String path) { ProcessBuilder pb = new ProcessBuilder("ls"); // command hard coded. So far, so good pb.redirectOutput(path); // Noncompliant } See
|
squid:S2077 |
Applications that execute SQL commands should neutralize any externally-provided values used in those commands. Failure to do so could allow an attacker to include input that changes the query so that unintended commands are executed, or sensitive data is exposed. This rule checks a variety of methods from different frameworks which are susceptible to SQL injection if not used properly. Frameworks which are covered are Java JDBC, JPA, JDO, Hibernate and Spring. The following specific method signatures are tested.
If a method is defined in an interface, implementations are also tested. For example this is the case for
Noncompliant Code Examplepublic User getUser(Connection con, String user) throws SQLException { Statement stmt1 = null; Statement stmt2 = null; PreparedStatement pstmt; try { stmt1 = con.createStatement(); ResultSet rs1 = stmt1.executeQuery("GETDATE()"); // Compliant; parameters not used here stmt2 = con.createStatement(); ResultSet rs2 = stmt2.executeQuery("select FNAME, LNAME, SSN " + "from USERS where UNAME=" + user); // Noncompliant; parameter concatenated directly into query pstmt = con.prepareStatement("select FNAME, LNAME, SSN " + "from USERS where UNAME=" + user); // Noncompliant; parameter concatenated directly into query ResultSet rs3 = pstmt.executeQuery(); //... } public User getUserHibernate(org.hibernate.Session session, String userInput) { org.hibernate.Query query = session.createQuery( // Compliant "FROM students where fname = " + userInput); // Noncompliant; parameter binding should be used instead // ... } Compliant Solutionpublic User getUser(Connection con, String user) throws SQLException { Statement stmt1 = null; PreparedStatement pstmt = null; String query = "select FNAME, LNAME, SSN " + "from USERS where UNAME=?" try { stmt1 = con.createStatement(); ResultSet rs1 = stmt1.executeQuery("GETDATE()"); pstmt = con.prepareStatement(query); pstmt.setString(1, user); // Compliant; PreparedStatements escape their inputs. ResultSet rs2 = pstmt.executeQuery(); //... } } public User getUserHibernate(org.hibernate.Session session, String userInput) { org.hibernate.Query query = session.createQuery("FROM students where fname = ?"); query = query.setParameter(0,userInput); // Parameter binding escapes all input // ... See
|
squid:S2070 |
The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2, MD4, MD6, RIPEMD160. The following APIs are tracked for use of obsolete crypto algorithms: * * * * * * * * * * Noncompliant Code ExampleMessageDigest md = MessageDigest.getInstance("SHA1"); // Noncompliant Compliant SolutionMessageDigest md = MessageDigest.getInstance("SHA-256"); See
|
squid:S3281 |
Default interceptors, such as application security interceptors, must be listed in the This rule applies to projects that contain JEE Beans (any one of Noncompliant Code Example// file: ejb-interceptors.xml <assembly-descriptor> <interceptor-binding> <ejb-name>*</ejb-name> <interceptor-class>com.myco.ImportantInterceptor</interceptor-class><!-- Noncompliant; will not be treated as default --> </interceptor-binding> </assembly-descriptor> Compliant Solution// file: ejb-jar.xml <assembly-descriptor> <interceptor-binding> <ejb-name>*</ejb-name> <interceptor-class>com.myco.ImportantInterceptor</interceptor-class> </interceptor-binding> </assembly-descriptor> |
squid:S3374 |
According to the Common Weakness Enumeration, If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations... In such a case, it is likely that the two forms should be combined. At the very least, one should be removed. Noncompliant Code Example<form-validation> <formset> <form name="BookForm"> ... </form> <form name="BookForm"> ... </form> <!-- Noncompliant --> </formset> </form-validation> Compliant Solution<form-validation> <formset> <form name="BookForm"> ... </form> </formset> </form-validation> See
|
squid:ClassVariableVisibilityCheck |
Public class variable fields do not respect the encapsulation principle and has three main disadvantages:
By using private attributes and accessor methods (set and get), unauthorized modifications are prevented. Noncompliant Code Examplepublic class MyClass { public static final int SOME_CONSTANT = 0; // Compliant - constants are not checked public String firstName; // Noncompliant } Compliant Solutionpublic class MyClass { public static final int SOME_CONSTANT = 0; // Compliant - constants are not checked private String firstName; // Compliant public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } } ExceptionsBecause they are not modifiable, this rule ignores See
|
squid:S2089 |
The fields in an HTTP request are putty in the hands of an attacker, and you cannot rely on them to tell you the truth about anything. While it may be safe to store such values after they have been neutralized, decisions should never be made based on their contents. This rule flags uses of the referer header field. Noncompliant Code Examplepublic class MyServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String referer = request.getHeader("referer"); // Noncompliant if(isTrustedReferer(referer)){ //.. } //... } } See
|
squid:S3066 |
Noncompliant Code Examplepublic enum Continent { NORTH_AMERICA (23, 24709000), // ... EUROPE (50, 39310000); public int countryCount; // Noncompliant private int landMass; Continent(int countryCount, int landMass) { // ... } public void setLandMass(int landMass) { // Noncompliant this.landMass = landMass; } Compliant Solutionpublic enum Continent { NORTH_AMERICA (23, 24709000), // ... EUROPE (50, 39310000); private int countryCount; private int landMass; Continent(int countryCount, int landMass) { // ... } |
squid:S899 |
When the return value of a function call contain the operation status code, this value should be tested to make sure the operation completed successfully. This rule raises an issue when the return values of the following are ignored:
Noncompliant Code Examplepublic void doSomething(File file, Lock lock) { file.delete(); // Noncompliant // ... lock.tryLock(); // Noncompliant } Compliant Solutionpublic void doSomething(File file, Lock lock) { if (!lock.tryLock()) { // lock failed; take appropriate action } if (!file.delete()) { // file delete failed; take appropriate action } } See
|
squid:S2092 |
The "secure" attribute prevents cookies from being sent over plaintext connections such as HTTP, where they would be easily eavesdropped upon. Instead, cookies with the secure attribute are only sent over encrypted HTTPS connections. Noncompliant Code ExampleCookie c = new Cookie(SECRET, secret); // Noncompliant; cookie is not secure response.addCookie(c); Compliant SolutionCookie c = new Cookie(SECRET, secret); c.setSecure(true); response.addCookie(c); See
|
findsecbugs:SPRING_FILE_DISCLOSURE |
Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories.
Vulnerable Code: ... String returnURL = request.getParameter("returnURL"); return new ModelAndView(returnURL); ...
Solution:
References |
findsecbugs:WEAK_MESSAGE_DIGEST_SHA1 |
The algorithms SHA-1 is not a recommended algorithm for hash password, for signature verification and other uses. PBKDF2 should be used to hash password for example. "SHA-1 for digital signature generation: "The main idea of a PBKDF is to slow dictionary or brute force attacks on the passwords by increasing the time needed to test each password. An attacker with a list of likely passwords can evaluate the PBKDF using the known iteration counter and the salt. Since an attacker has to spend a significant amount of computing time for each try, it becomes harder to apply the dictionary or brute force attacks."
Vulnerable Code: MessageDigest sha1Digest = MessageDigest.getInstance("SHA1"); sha1Digest.update(password.getBytes()); byte[] hashValue = sha1Digest.digest(); byte[] hashValue = DigestUtils.getSha1Digest().digest(password.getBytes());
Solution (Using bouncy castle): public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException { PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest()); gen.init(password.getBytes("UTF-8"), salt.getBytes(), 4096); return ((KeyParameter) gen.generateDerivedParameters(256)).getKey(); } Solution (Java 8 and later): public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException { KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8); SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"); return f.generateSecret(spec).getEncoded(); }
References |
findsecbugs:XSS_REQUEST_WRAPPER |
An implementation of The filtering is weak for a few reasons:
Example of bypass: <scrivbscript:pt>alert(1)</scrivbscript:pt>
The previous input will be transformed into For stronger protection, choose a solution that encodes characters automatically in the view (template, jsp, ...) following the XSS protection rules defined in the OWASP XSS Prevention Cheat Sheet.
References |
findsecbugs:NULL_CIPHER |
The NullCipher is rarely used intentionally in production applications. It implements the Cipher interface by returning ciphertext identical to the supplied plaintext. In a few contexts, such as testing, a NullCipher may be appropriate.
Vulnerable Code: Cipher doNothingCihper = new NullCipher(); [...] //The ciphertext produced will be identical to the plaintext. byte[] cipherText = c.doFinal(plainText);
Solution:
Reference |
findsecbugs:COOKIE_PERSISTENT |
Storing sensitive data in a persistent cookie for an extended period of time can lead to a breach of confidentiality or account compromise.
Explanation:
Vulnerable Code: The following code sets a cookie to expire in 1 year. [...] Cookie cookie = new Cookie("email", email); cookie.setMaxAge(60*60*24*365); [...]
Solution:
References |
findsecbugs:CUSTOM_MESSAGE_DIGEST |
Implementing a custom MessageDigest is error-prone. NIST recommends the use of SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256. "SHA-1 for digital signature generation:
Vulnerable Code: MyProprietaryMessageDigest extends MessageDigest { @Override protected byte[] engineDigest() { [...] //Creativity is a bad idea return [...]; } }
Upgrade your implementation to use one of the approved algorithms. Use an algorithm that is sufficiently strong for your specific security needs.
Example Solution: MessageDigest sha256Digest = MessageDigest.getInstance("SHA256"); sha256Digest.update(password.getBytes());
References |
findsecbugs:PLAY_UNVALIDATED_REDIRECT |
Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
Scenario Vulnerable Code: def login(redirectUrl:String) = Action { [...] Redirect(url) }
Solution/Countermeasures:
References |
findsecbugs:LDAP_ENTRY_POISONING |
JNDI API support the binding of serialize object in LDAP directories. If certain attributes are presented, the deserialization of object will be made in the application querying the directory (See Black Hat USA 2016 white paper for details). Object deserialization should be threated as risky operation that can lead to remote code execution. The exploitation of the vulnerability will be possible if the attacker has an entry point in an LDAP base query, by adding attributes to an existing LDAP entry or by configuring the application to use a malicious LDAP server. Vulnerable Code: DirContext ctx = new InitialDirContext(); //[...] ctx.search(query, filter, new SearchControls(scope, countLimit, timeLimit, attributes, true, //Enable object deserialization if bound in directory deref)); Solution: DirContext ctx = new InitialDirContext(); //[...] ctx.search(query, filter, new SearchControls(scope, countLimit, timeLimit, attributes, false, //Disable deref));
References |
findsecbugs:SERVLET_HEADER_REFERER |
Behavior:
Recommendations:
|
findsecbugs:HARD_CODE_KEY |
Cryptographic keys should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores. (Hard coded passwords are reported separately by Hard Coded Password pattern)
Vulnerable Code: byte[] key = {1, 2, 3, 4, 5, 6, 7, 8}; SecretKeySpec spec = new SecretKeySpec(key, "AES"); Cipher aes = Cipher.getInstance("AES"); aes.init(Cipher.ENCRYPT_MODE, spec); return aesCipher.doFinal(secretData);
References |
findsecbugs:SPRING_CSRF_UNRESTRICTED_REQUEST_MAPPING |
Methods annotated with
Vulnerable Code: @Controller public class UnsafeController { @RequestMapping("/path") public void writeData() { // State-changing operations performed within this method. } }
Solution (Spring Framework 4.3 and later): @Controller public class SafeController { /** * For methods without side-effects use @GetMapping. */ @GetMapping("/path") public String readData() { // No state-changing operations performed within this method. return ""; } /** * For state-changing methods use either @PostMapping, @PutMapping, @DeleteMapping, or @PatchMapping. */ @PostMapping("/path") public void writeData() { // State-changing operations performed within this method. } }
Solution (Before Spring Framework 4.3): @Controller public class SafeController { /** * For methods without side-effects use either * RequestMethod.GET, RequestMethod.HEAD, RequestMethod.TRACE, or RequestMethod.OPTIONS. */ @RequestMapping(value = "/path", method = RequestMethod.GET) public String readData() { // No state-changing operations performed within this method. return ""; } /** * For state-changing methods use either * RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE, or RequestMethod.PATCH. */ @RequestMapping(value = "/path", method = RequestMethod.POST) public void writeData() { // State-changing operations performed within this method. } }
References |
findsecbugs:SPEL_INJECTION |
A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. Code at risk:
public void parseExpressionInterface(Person personObj,String property) { ExpressionParser parser = new SpelExpressionParser(); //Unsafe if the input is control by the user.. Expression exp = parser.parseExpression(property+" == 'Albert'"); StandardEvaluationContext testContext = new StandardEvaluationContext(personObj); boolean result = exp.getValue(testContext, Boolean.class); [...]
References |
findsecbugs:WEAK_MESSAGE_DIGEST_MD5 |
The algorithms MD2, MD4 and MD5 are not a recommended MessageDigest. PBKDF2 should be used to hash password for example. "The security of the MD5 hash function is severely compromised. A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor (complexity of 224.1).[1] Further, there is also a chosen-prefix collision attack that can produce a collision for two inputs with specified prefixes within hours, using off-the-shelf computing hardware (complexity 239).[2]" "SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256: "The main idea of a PBKDF is to slow dictionary or brute force attacks on the passwords by increasing the time needed to test each password. An attacker with a list of likely passwords can evaluate the PBKDF using the known iteration counter and the salt. Since an attacker has to spend a significant amount of computing time for each try, it becomes harder to apply the dictionary or brute force attacks."
Vulnerable Code: MessageDigest md5Digest = MessageDigest.getInstance("MD5"); md5Digest.update(password.getBytes()); byte[] hashValue = md5Digest.digest(); byte[] hashValue = DigestUtils.getMd5Digest().digest(password.getBytes());
Solution (Using bouncy castle): public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException { PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest()); gen.init(password.getBytes("UTF-8"), salt.getBytes(), 4096); return ((KeyParameter) gen.generateDerivedParameters(256)).getKey(); } Solution (Java 8 and later): public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException { KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8); SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"); return f.generateSecret(spec).getEncoded(); }
References |
findsecbugs:TAPESTRY_ENDPOINT |
A Tapestry endpoint was discovered at application startup. Tapestry apps are structured with a backing Java class and a corresponding Tapestry Markup Language page (a .tml file) for each page. When a request is received, the GET/POST parameters are mapped to specific inputs in the backing Java class. The mapping is either done with fieldName:
or the definition of an explicit annotation:
The page is mapped to the view Each Tapestry page in this application should be researched to make sure all inputs that are automatically mapped in this way are properly validated before they are used.
References |
findsecbugs:PERMISSIVE_CORS |
Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, cull through it, and communicate it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, caution should be taken when defining the header because an overly permissive CORS policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks. Vulnerable Code: response.addHeader("Access-Control-Allow-Origin", "*");
Solution:
References |
findsecbugs:SEAM_LOG_INJECTION |
Seam Logging API support an expression language to introduce bean property to log messages. The expression language can also be the source to unwanted code execution. In this context, an expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. Code at risk:
public void logUser(User user) { log.info("Current logged in user : " + user.getUsername()); //... } Solution:
public void logUser(User user) { log.info("Current logged in user : #0", user.getUsername()); //... }
References |
findsecbugs:HTTP_RESPONSE_SPLITTING |
When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks. According to OWASP, the issue has been fixed in virtually all modern Java EE application servers, but it is still better to validate the input. If you are concerned about this risk, you should test on the platform of concern to see if the underlying platform allows for CR or LF characters to be injected into headers. This weakness is reported with lower priority than SQL injection etc., if you are using a vulnerable platform, please check low-priority warnings too.
Code at risk: String author = request.getParameter(AUTHOR_PARAMETER); // ... Cookie cookie = new Cookie("author", author); response.addCookie(cookie);
References |
findsecbugs:PATH_TRAVERSAL_OUT |
A file is opened to write to its contents. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files at an arbitrary filesystem location could be modified. This rule identifies potential path traversal vulnerabilities. In many cases, the constructed file path cannot be controlled by the user. If that is the case, the reported instance is a false positive.
References |
findsecbugs:WEAK_TRUST_MANAGER |
Empty TrustManager implementations are often used to connect easily to a host that is not signed by a root certificate authority. As a consequence, this is vulnerable to Man-in-the-middle attacks since the client will trust any certificate. A TrustManager allowing specific certificates (based on a truststore for example) should be built. Detailed information for a proper implementation is available at: [1] [2]
Vulnerable Code: class TrustAllManager implements X509TrustManager { @Override public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { //Trust any client connecting (no certificate validation) } @Override public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { //Trust any remote server (no certificate validation) } @Override public X509Certificate[] getAcceptedIssuers() { return null; } }
Solution (TrustMangager based on a keystore): KeyStore ks = //Load keystore containing the certificates trusted SSLContext sc = SSLContext.getInstance("TLS"); TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); tmf.init(ks); sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);
References |
findsecbugs:RSA_NO_PADDING |
The software uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
Vulnerable Code: Cipher.getInstance("RSA/NONE/NoPadding")
Solution: Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")
References |
findsecbugs:URL_REWRITING |
The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL.
Vulnerable Code: out.println("Click <a href=" + res.encodeURL(HttpUtils.getRequestURL(req).toString()) + ">here</a>");
Solution:
References |
findsecbugs:INSECURE_COOKIE |
A new cookie is created without the
Code at risk: Cookie cookie = new Cookie("userName",userName); response.addCookie(cookie);
Solution (Specific configuration): Cookie cookie = new Cookie("userName",userName); cookie.setSecure(true); // Secure flag cookie.setHttpOnly(true);
Solution (Servlet 3.0 configuration): <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0"> [...] <session-config> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config> </web-app>
Reference |
findsecbugs:ANDROID_WEB_VIEW_JAVASCRIPT_INTERFACE |
The use of JavaScript Interface could expose the WebView to risky API. If an XSS is triggered in the WebView, the class could be called by the malicious JavaScript code.
Code at risk: WebView myWebView = (WebView) findViewById(R.id.webView); myWebView.addJavascriptInterface(new FileWriteUtil(this), "fileWriteUtil"); WebSettings webSettings = myWebView.getSettings(); webSettings.setJavaScriptEnabled(true); [...] class FileWriteUtil { Context mContext; FileOpenUtil(Context c) { mContext = c; } public void writeToFile(String data, String filename, String tag) { [...] } }
References |
findsecbugs:REDOS |
Regular expressions (regexs) are frequently subject to Denial of Service (DOS) attacks (called ReDOS). This is due to the fact that regex engines may take a large amount of time when analyzing certain strings, depending on how the regex is defined.
For example, for the regex: ^(a+)+$, the input " Therefore, it is possible that a single request may cause a large amount of computation on the server side. The problem with this regex, and others like it, is that there are two different ways the same input character can be accepted by the Regex due to the + (or a *) inside the parenthesis, and the + (or a *) outside the parenthesis. The way this is written, either + could consume the character 'a'. To fix this, the regex should be rewritten to eliminate the ambiguity. For example, this could simply be rewritten as: ^a+$, which is presumably what the author meant anyway (any number of a's). Assuming that's what the original regex meant, this new regex can be evaluated quickly, and is not subject to ReDOS.
References |
findsecbugs:BLOWFISH_KEY_SIZE |
The Blowfish cipher supports keysizes from 32 bits to 448 bits. A small key size makes the ciphertext vulnerable to brute force attacks. At least 128 bits of entropy should be used when generating the key if use of Blowfish is required. If the algorithm can be changed, the AES block cipher should be used instead. Vulnerable Code: KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish"); keyGen.init(64); Solution: KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish"); keyGen.init(128);
References |
findsecbugs:TEMPLATE_INJECTION_FREEMARKER |
Freemarker template engine is powerful. It is possible to add logic including condition statements, loops and external calls. It is not design to be sandbox to templating operations. A malicious user in control of a template can run malicious code on the server-side. Freemarker templates should be seen as scripts. Vulnerable Code: Template template = cfg.getTemplate(inputTemplate); [...] template.process(data, swOut);
Solution:
References |
findsecbugs:OBJECT_DESERIALIZATION |
Object deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation. Libraries developers tend to fix class that provided potential malicious trigger. There are still classes that are known to trigger Denial of Service[1]. Deserialization is a sensible operation that has a great history of vulnerabilities. The web application might become vulnerable as soon as a new vulnerability is found in the Java Virtual Machine[2] [3].
Code at risk: public UserData deserializeObject(InputStream receivedFile) throws IOException, ClassNotFoundException { try (ObjectInputStream in = new ObjectInputStream(receivedFile)) { return (UserData) in.readObject(); } }
Solutions: Avoid deserializing object provided by remote users.
References |
findsecbugs:SQL_INJECTION_JPA |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Vulnerable Code: EntityManager pm = getEM(); TypedQuery<UserEntity> q = em.createQuery( String.format("select * from Users where name = %s", username), UserEntity.class); UserEntity res = q.getSingleResult();
Solution: TypedQuery<UserEntity> q = em.createQuery( "select * from Users where name = usernameParam",UserEntity.class) .setParameter("usernameParam", username); UserEntity res = q.getSingleResult();
References (JPA) |
findsecbugs:SERVLET_HEADER |
Request headers can easily be altered by the requesting user. In general, no assumption should be made that the request came from a regular browser without modification by an attacker. As such, it is recommended that you not trust this value in any security decisions you make with respect to a request. |
findsecbugs:JACKSON_UNSAFE_DESERIALIZATION |
When the Jackson databind library is used incorrectly the deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation.
Solutions: Explicitly define what types and subtypes you want to be available when using polymorphism through JsonTypeInfo.Id.NAME. Also, never call ObjectMapper.enableDefaultTyping (and then readValue a type that holds a Object or Serializable or Comparable or a known deserialization type).
Code at risk: public class Example { static class ABean { public int id; public Object obj; } static class AnotherBean { @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS) // or JsonTypeInfo.Id.MINIMAL_CLASS public Object obj; } public void example(String json) throws JsonMappingException { ObjectMapper mapper = new ObjectMapper(); mapper.enableDefaultTyping(); mapper.readValue(json, ABean.class); } public void exampleTwo(String json) throws JsonMappingException { ObjectMapper mapper = new ObjectMapper(); mapper.readValue(json, AnotherBean.class); } }
References |
findsecbugs:LDAP_INJECTION |
Just like SQL, all inputs passed to an LDAP query need to be passed in safely. Unfortunately, LDAP doesn't have prepared statement interfaces like SQL. Therefore, the primary defense against LDAP injection is strong input validation of any untrusted data before including it in an LDAP query.
Code at risk: NamingEnumeration<SearchResult> answers = context.search("dc=People,dc=example,dc=com", "(uid=" + username + ")", ctrls);
References |
findsecbugs:XSS_SERVLET |
A potential XSS was found. It could be used to execute unwanted JavaScript in a client's browser. (See references) Vulnerable Code: protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String input1 = req.getParameter("input1"); [...] resp.getWriter().write(input1); } Solution: protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String input1 = req.getParameter("input1"); [...] resp.getWriter().write(Encode.forHtml(input1)); } The best defense against XSS is context sensitive output encoding like the example above. There are typically 4 contexts to consider: HTML, JavaScript, CSS (styles), and URLs. Please follow the XSS protection rules defined in the OWASP XSS Prevention Cheat Sheet, which explains these defenses in significant detail. Note that this XSS in Servlet rule looks for similar issues, but looks for them in a different way than the existing 'XSS: Servlet reflected cross site scripting vulnerability' and 'XSS: Servlet reflected cross site scripting vulnerability in error page' rules in FindBugs.
References |
findsecbugs:BAD_HEXA_CONVERSION |
When converting a byte array containing a hash signature to a human readable string, a conversion mistake can be made if the array is read byte by byte. The following sample illustrates the use of Integer.toHexString() which will trim any leading zeroes from each byte of the computed hash value. MessageDigest md = MessageDigest.getInstance("SHA-256"); 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(); This mistake weakens the hash value computed since it introduces more collisions. For example, the hash values "0x0679" and "0x6709" would both output as "679" for the above function. In this situation, the use of toHexString() should be replaced with String.format() as follows: stringBuilder.append( String.format( "%02X", b ) );
References |
findsecbugs:WICKET_ENDPOINT |
This class represents a Wicket WebPage. Input is automatically read from a PageParameters instance passed to the constructor. The current page is mapped to the view [/package/WebPageName].html. Each Wicket page in this application should be researched to make sure all inputs that are automatically mapped in this way are properly validated before they are used.
References |
findsecbugs:SQL_INJECTION_ANDROID |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Vulnerable Code: String query = "SELECT * FROM messages WHERE uid= '"+userInput+"'" ; Cursor cursor = this.getReadableDatabase().rawQuery(query,null);
Solution: String query = "SELECT * FROM messages WHERE uid= ?" ; Cursor cursor = this.getReadableDatabase().rawQuery(query,new String[] {userInput}); References (Android SQLite) InformIT.com: Practical Advice for Building Secure Android Databases in SQLite Packtpub.com: Knowing the SQL-injection attacks and securing our Android applications from them Android Database Support (Enterprise Android: Programming Android Database Applications for the Enterprise) Safe example of Insert, Select, Update and Delete queryies provided by Suragch References (SQL injection) WASC-19: SQL Injection CAPEC-66: SQL Injection CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') OWASP: Top 10 2013-A1-Injection OWASP: SQL Injection Prevention Cheat Sheet OWASP: Query Parameterization Cheat Sheet |
findsecbugs:CRLF_INJECTION_LOGS |
When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).
Code at risk: String val = request.getParameter("user"); String metadata = request.getParameter("metadata"); [...] if(authenticated) { log.info("User " + val + " (" + metadata + ") was authenticated successfully"); } else { log.info("User " + val + " (" + metadata + ") was not authenticated"); }A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer" .
Solution:You can manually sanitize each parameter. log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated"); You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function. <pattern>%-5level - %replace(%msg){'[\r\n]', ''}%n</pattern>
References |
findsecbugs:UNENCRYPTED_SERVER_SOCKET |
The communication channel used is not encrypted. The traffic could be read by an attacker intercepting the network traffic.
Vulnerable Code: ServerSocket soc = new ServerSocket(1234);
Solution: ServerSocket soc = SSLServerSocketFactory.getDefault().createServerSocket(1234); Beyond using an SSL server socket, you need to make sure your use of SSLServerSocketFactory does all the appropriate certificate validation checks to make sure you are not subject to man-in-the-middle attacks. Please read the OWASP Transport Layer Protection Cheat Sheet for details on how to do this correctly.
References |
findsecbugs:SQL_INJECTION_SPRING_JDBC |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Vulnerable Code: JdbcTemplate jdbc = new JdbcTemplate(); int count = jdbc.queryForObject("select count(*) from Users where name = '"+paramName+"'", Integer.class);
Solution: JdbcTemplate jdbc = new JdbcTemplate(); int count = jdbc.queryForObject("select count(*) from Users where name = ?", Integer.class, paramName); References (Spring JDBC) Spring Official Documentation: Data access with JDBC References (SQL injection) WASC-19: SQL Injection CAPEC-66: SQL Injection CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') OWASP: Top 10 2013-A1-Injection OWASP: SQL Injection Prevention Cheat Sheet OWASP: Query Parameterization Cheat Sheet |
findsecbugs:DES_USAGE |
DES and DESede (3DES) are not considered strong ciphers for modern applications. Currently, NIST recommends the usage of AES block ciphers instead of DES/3DES. Example weak code: Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText); Example solution: Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText);
References |
findsecbugs:ANDROID_GEOLOCATION |
It is suggested to ask the user for a confirmation about obtaining its geolocation.
Code at risk: webView.setWebChromeClient(new WebChromeClient() { @Override public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) { callback.invoke(origin, true, false); } });
Suggested code: webView.setWebChromeClient(new WebChromeClient() { @Override public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) { callback.invoke(origin, true, false); //Ask the user for confirmation } });
References |
findsecbugs:SQL_INJECTION |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Alternatively to prepare statements, each parameter can be escaped manually.
Vulnerable Code: createQuery("select * from User where id = '"+inputId+"'");
Solution: import org.owasp.esapi.Encoder; createQuery("select * from User where id = '"+Encoder.encodeForSQL(inputId)+"'");
References (SQL injection) |
findsecbugs:DESERIALIZATION_GADGET |
Deserialization gadget are class that could be used by an attacker to take advantage of a remote API using Native Serialization. This class is either adding custom behavior to deserialization with the readObject method (Serializable) or can be called from a serialized object (InvocationHandler). This detector is intended to be used mostly by researcher. The real issue is using deserialization for remote operation. Removing gadget is an hardening practice to reduce the risk of being exploited.
References |
findsecbugs:COMMAND_INJECTION |
The highlighted API is used to execute a system command. If unfiltered input is passed to this API, it can lead to arbitrary command execution.
Vulnerable Code: import java.lang.Runtime; Runtime r = Runtime.getRuntime(); r.exec("/bin/sh -c some_tool" + input);
References |
findsecbugs:SPRING_UNVALIDATED_REDIRECT |
Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
Scenario Vulnerable Code: @RequestMapping("/redirect") public String redirect(@RequestParam("url") String url) { [...] return "redirect:" + url; }
Solution/Countermeasures:
References |
findsecbugs:STRUTS_FORM_VALIDATION |
Form inputs should have minimal input validation. Preventive validation helps provide defense in depth against a variety of risks.
Validation can be introduce by implementing a public class RegistrationForm extends ValidatorForm { private String name; private String email; [...] public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) { //Validation code for name and email parameters passed in via the HttpRequest goes here } }
References |
findsecbugs:SPRING_ENDPOINT |
This class is a Spring Controller. All methods annotated with |
findsecbugs:XXE_XMLREADER |
AttackXML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. Risk 1: Expose local file content (XXE: XML eXternal Entity)
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]> <foo>&xxe;</foo>Risk 2: Denial of service (XEE: Xml Entity Expansion)
<?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> [...] <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz> SolutionIn order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code. Vulnerable Code:
XMLReader reader = XMLReaderFactory.createXMLReader(); reader.setContentHandler(customHandler); reader.parse(new InputSource(inputStream)); The following snippets show two available solutions. You can set one property or both. Solution using "Secure processing" mode: This setting will protect you against Denial of Service attack and remote file access. XMLReader reader = XMLReaderFactory.createXMLReader(); reader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); reader.setContentHandler(customHandler); reader.parse(new InputSource(inputStream)); Solution disabling DTD: By disabling DTD, almost all XXE attacks will be prevented. XMLReader reader = XMLReaderFactory.createXMLReader(); reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); reader.setContentHandler(customHandler); reader.parse(new InputSource(inputStream));
References |
findsecbugs:FORMAT_STRING_MANIPULATION |
Allowing user input to control format parameters could enable an attacker to cause exceptions to be thrown or leak information.
Vulnerable Code: Formatter formatter = new Formatter(Locale.US); String format = "The customer: %s %s has the balance %4$." + userInput + "f"; formatter.format(format, firstName, lastName, accountNo, balance);
Solution:
References |
findsecbugs:ANDROID_WORLD_WRITABLE |
The file written in this context is using the creation mode
Code at risk: fos = openFileOutput(filename, MODE_WORLD_READABLE); fos.write(userInfo.getBytes());
Solution (using MODE_PRIVATE): fos = openFileOutput(filename, MODE_PRIVATE);
Solution (using local SQLite Database):
References |
findsecbugs:ECB_MODE |
An authentication cipher mode which provides better confidentiality of the encrypted data should be used instead of Electronic Codebook (ECB) mode, which does not provide good confidentiality. Specifically, ECB mode produces the same output for the same input each time. So, for example, if a user is sending a password, the encrypted value is the same each time. This allows an attacker to intercept and replay the data. To fix this, something like Galois/Counter Mode (GCM) should be used instead. Code at risk: Cipher c = Cipher.getInstance("AES/ECB/NoPadding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText); Solution: Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText);
References |
findsecbugs:PREDICTABLE_RANDOM |
The use of a predictable random value can lead to vulnerabilities when used in certain security critical contexts. For example, when the value is used as:
A quick fix could be to replace the use of java.util.Random with something stronger, such as java.security.SecureRandom.
Vulnerable Code: String generateSecretToken() { Random r = new Random(); return Long.toHexString(r.nextLong()); } Solution: import org.apache.commons.codec.binary.Hex; String generateSecretToken() { SecureRandom secRandom = new SecureRandom(); byte[] result = new byte[32]; secRandom.nextBytes(result); return Hex.encodeHexString(result); }
References |
findsecbugs:UNVALIDATED_REDIRECT |
Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
Scenario Vulnerable Code: protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { [...] resp.sendRedirect(req.getParameter("redirectUrl")); [...] }
Solution/Countermeasures:
References |
findsecbugs:JAXRS_ENDPOINT |
This method is part of a REST Web Service (JSR311). The security of this web service should be analyzed. For example:
References |
findsecbugs:SQL_INJECTION_TURBINE |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Turbine API provide a DSL to build query with Java code.
Vulnerable Code: List<Record> BasePeer.executeQuery( "select * from Customer where id=" + inputId );
Solution (using Criteria DSL): Criteria c = new Criteria(); c.add( CustomerPeer.ID, inputId ); List<Customer> customers = CustomerPeer.doSelect( c );Solution (using specialized method): Customer customer = CustomerPeer.retrieveByPK( new NumberKey( inputId ) );Solution (using OWASP Encoder): import org.owasp.esapi.Encoder; BasePeer.executeQuery("select * from Customer where id = '"+Encoder.encodeForSQL(inputId)+"'");
References (Turbine) |
findsecbugs:BEAN_PROPERTY_INJECTION |
An attacker can set arbitrary bean properties that can compromise system integrity. Bean population functions allow to set a bean property or a nested property. An attacker can leverage this functionality to access special bean properties like class.classLoader that will allow him to override system properties and potentially execute arbitrary code.
Vulnerable Code: MyBean bean = ...; HashMap map = new HashMap(); Enumeration names = request.getParameterNames(); while (names.hasMoreElements()) { String name = (String) names.nextElement(); map.put(name, request.getParameterValues(name)); } BeanUtils.populate(bean, map);
Solution:
References |
findsecbugs:SSL_CONTEXT |
Vulnerable Code: SSLContext.getInstance("SSL");
Solution: SSLContext.getInstance("TLS");
References |
findsecbugs:WEAK_FILENAMEUTILS |
Some FilenameUtils' methods don't filter NULL bytes ( If a null byte is injected into a filename, if this filename is passed to the underlying OS, the file retrieved will be the name of the file that is specified prior to the NULL byte, since at the OS level, all strings are terminated by a null byte even though Java itself doesn't care about null bytes or treat them special. This OS behavior can be used to bypass filename validation that looks at the end of the filename (e.g., endswith ".log") to make sure its a safe file to access. To fix this, two things are recommended:
If you know you are using a modern version of Java immune to NULL byte injection, you can probably disable this rule.
References |
findsecbugs:ESAPI_ENCRYPTOR |
The ESAPI has a small history of vulnerabilities within the cryptography component. Here is a quick validation list to make sure the Authenticated Encryption is working as expected. 1. Library Version
This issue is corrected in ESAPI version 2.1.0. Versions <= 2.0.1 are vulnerable to a MAC bypass (CVE-2013-5679).
For Maven users, the plugin versions can be called using the
following command. The effective version of ESAPI will be available in the output. $ mvn versions:display-dependency-updates Output: [...] [INFO] The following dependencies in Dependencies have newer versions: [INFO] org.slf4j:slf4j-api ................................... 1.6.4 -> 1.7.7 [INFO] org.owasp.esapi:esapi ................................. 2.0.1 -> 2.1.0 [...]
or by looking at the configuration directly. <dependency> <groupId>org.owasp.esapi</groupId> <artifactId>esapi</artifactId> <version>2.1.0</version> </dependency> For Ant users, the jar used should be esapi-2.1.0.jar. 2. Configuration:
The library version 2.1.0 is still vulnerable to key size being changed in the ciphertext definition (CVE-2013-5960). Some precautions need to be taken. The cryptographic configuration of ESAPI can also be vulnerable if any of these elements are present:
Insecure configuration: Encryptor.CipherText.useMAC=false Encryptor.EncryptionAlgorithm=AES Encryptor.CipherTransformation=AES/CBC/PKCS5Padding Encryptor.cipher_modes.additional_allowed=CBC
Secure configuration:
#Needed Encryptor.CipherText.useMAC=true #Needed to have a solid auth. encryption Encryptor.EncryptionAlgorithm=AES Encryptor.CipherTransformation=AES/GCM/NoPadding #CBC mode should be removed to avoid padding oracle Encryptor.cipher_modes.additional_allowed=
References |
findsecbugs:SERVLET_QUERY_STRING |
The query string is the concatenation of the GET parameter names and values. Parameters other than those intended can be passed in. For the URL request Just as is true for individual parameter values retrieved via methods like
Reference |
findsecbugs:SQL_INJECTION_JDBC |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Vulnerable Code: Connection conn = [...]; Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("update COFFEES set SALES = "+nbSales+" where COF_NAME = '"+coffeeName+"'");
Solution: Connection conn = [...]; conn.prepareStatement("update COFFEES set SALES = ? where COF_NAME = ?"); updateSales.setInt(1, nbSales); updateSales.setString(2, coffeeName); References (JDBC) Oracle Documentation: The Java Tutorials > Prepared Statements References (SQL injection) WASC-19: SQL Injection CAPEC-66: SQL Injection CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') OWASP: Top 10 2013-A1-Injection OWASP: SQL Injection Prevention Cheat Sheet OWASP: Query Parameterization Cheat Sheet |
findsecbugs:ANDROID_WEB_VIEW_JAVASCRIPT |
Enabling JavaScript for the WebView means that it is now susceptible to XSS. The page render should be inspected
for potential reflected XSS, stored XSS and DOM XSS. WebView myWebView = (WebView) findViewById(R.id.webView); WebSettings webSettings = myWebView.getSettings(); webSettings.setJavaScriptEnabled(true);
Code at risk: function updateDescription(newDescription) { $("#userDescription").html("<p>"+newDescription+"</p>"); }
References |
findsecbugs:EL_INJECTION |
A expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. Code at risk:
public void evaluateExpression(String expression) { FacesContext context = FacesContext.getCurrentInstance(); ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory(); ELContext elContext = context.getELContext(); ValueExpression vex = expressionFactory.createValueExpression(elContext, expression, String.class); return (String) vex.getValue(elContext); }
References |
findsecbugs:PATH_TRAVERSAL_IN |
A file is opened to read its content. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read. This rule identifies potential path traversal vulnerabilities. In many cases, the constructed file path cannot be controlled by the user. If that is the case, the reported instance is a false positive.
Vulnerable Code: @GET @Path("/images/{image}") @Produces("images/*") public Response getImage(@javax.ws.rs.PathParam("image") String image) { File file = new File("resources/images/", image); //Weak point if (!file.exists()) { return Response.status(Status.NOT_FOUND).build(); } return Response.ok().entity(new FileInputStream(file)).build(); }
Solution: import org.apache.commons.io.FilenameUtils; @GET @Path("/images/{image}") @Produces("images/*") public Response getImage(@javax.ws.rs.PathParam("image") String image) { File file = new File("resources/images/", FilenameUtils.getName(image)); //Fix if (!file.exists()) { return Response.status(Status.NOT_FOUND).build(); } return Response.ok().entity(new FileInputStream(file)).build(); }
References |
findsecbugs:MALICIOUS_XSLT |
"XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents".[1]
Code at risk: Source xslt = new StreamSource(new FileInputStream(inputUserFile)); //Dangerous source to validate Transformer transformer = TransformerFactory.newInstance().newTransformer(xslt); Source text = new StreamSource(new FileInputStream("/data_2_process.xml")); transformer.transform(text, new StreamResult(...));
Solution: The solution would be to make sure the stylesheet is loaded from a safe sources and make sure that vulnerabilities such as Path traversal [3][4] are not possible.
References |
findsecbugs:STRUTS2_ENDPOINT |
In Struts 2, the endpoints are Plain Old Java Objects (POJOs) which means no Interface/Class needs to be implemented/extended. When a request is routed to its controller (like the selected class), the supplied HTTP parameters are automatically mapped to setters for the class. Therefore, all setters of this class should be considered as untrusted input even if the form doesn't include those values. An attacker can simply provide additional values in the request, and they will be set in the object anyway, as long as that object has such a setter. The use of these parameters should be reviewed to make sure they are used safely. |
findsecbugs:SERVLET_HEADER_USER_AGENT |
The header "User-Agent" can easily be spoofed by the client. Adopting different behaviors based on the User-Agent (for crawler UA) is not recommended. |
findsecbugs:STRUTS_FILE_DISCLOSURE |
Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories.
Vulnerable Code: ... String returnURL = request.getParameter("returnURL"); Return new ActionForward(returnURL); ...
Solution:
References |
findsecbugs:XXE_SAXPARSER |
AttackXML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. Risk 1: Expose local file content (XXE: XML eXternal Entity)
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]> <foo>&xxe;</foo>Risk 2: Denial of service (XEE: Xml Entity Expansion)
<?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> [...] <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz> SolutionIn order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code. Vulnerable Code:
SAXParser parser = SAXParserFactory.newInstance().newSAXParser(); parser.parse(inputStream, customHandler); The following snippets show two available solutions. You can set one feature or both. Solution using "Secure processing" mode: This setting will protect you against Denial of Service attack and remote file access. SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); SAXParser parser = spf.newSAXParser(); parser.parse(inputStream, customHandler); Solution disabling DTD: By disabling DTD, almost all XXE attacks will be prevented. SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); SAXParser parser = spf.newSAXParser(); parser.parse(inputStream, customHandler);
References |
findsecbugs:SQL_INJECTION_HIBERNATE |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Alternatively to prepare statements, Hibernate Criteria can be used.
Vulnerable Code: Session session = sessionFactory.openSession(); Query q = session.createQuery("select t from UserEntity t where id = " + input); q.execute();
Solution: Session session = sessionFactory.openSession(); Query q = session.createQuery("select t from UserEntity t where id = :userId"); q.setString("userId",input); q.execute();
Solution for dynamic queries (with Hibernate Criteria): Session session = sessionFactory.openSession(); Query q = session.createCriteria(UserEntity.class) .add( Restrictions.like("id", input) ) .list(); q.execute();
References (Hibernate) |
findsecbugs:XXE_XMLSTREAMREADER |
AttackXML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. Risk 1: Expose local file content (XXE: XML eXternal Entity)
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]> <foo>&xxe;</foo>Risk 2: Denial of service (XEE: Xml Entity Expansion)
<?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> [...] <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz> SolutionIn order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code. Vulnerable Code:
public void parseXML(InputStream input) throws XMLStreamException { XMLInputFactory factory = XMLInputFactory.newFactory(); XMLStreamReader reader = factory.createXMLStreamReader(input); [...] } The following snippets show two available solutions. You can set one property or both. Solution disabling External Entities:
public void parseXML(InputStream input) throws XMLStreamException { XMLInputFactory factory = XMLInputFactory.newFactory(); factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); XMLStreamReader reader = factory.createXMLStreamReader(input); [...] } Solution disabling DTD:
public void parseXML(InputStream input) throws XMLStreamException { XMLInputFactory factory = XMLInputFactory.newFactory(); factory.setProperty(XMLInputFactory.SUPPORT_DTD, false); XMLStreamReader reader = factory.createXMLStreamReader(input); [...] }
References |
findsecbugs:SERVLET_CONTENT_TYPE |
The HTTP header Content-Type can be controlled by the client. As such, its value should not be used in any security critical decisions. |
findsecbugs:SERVLET_SERVER_NAME |
The hostname header can be controlled by the client. As such, its value should not be used in any security critical decisions.
Both GET /testpage HTTP/1.1 Host: www.example.com [...] The web container serving your application may redirect requests to your application by default. This would allow a malicious user to place any value in the Host header. It is recommended that you do not trust this value in any security decisions you make with respect to a request. |
findsecbugs:DEFAULT_HTTP_CLIENT |
Vulnerable Code: HttpClient client = new DefaultHttpClient();
Solution:
Sample Code: HttpClient client = new SystemDefaultHttpClient();
Sample Code: HttpClient client = HttpClientBuilder.create().useSystemProperties().build();
Sample Code: HttpClient client = HttpClients.createSystem();
References |
findsecbugs:HAZELCAST_SYMMETRIC_ENCRYPTION |
The network communications for Hazelcast is configured to use a symmetric cipher (probably DES or blowfish). Those ciphers alone do not provide integrity or secure authentication. The use of asymmetric encryption is preferred.
References |
findsecbugs:JAXWS_ENDPOINT |
This method is part of a SOAP Web Service (JSR224). The security of this web service should be analyzed. For example:
References |
findsecbugs:CIPHER_INTEGRITY |
The ciphertext produced is susceptible to alteration by an adversary. This mean that the cipher provides no way to detect that the data has been tampered with. If the ciphertext can be controlled by an attacker, it could be altered without detection. The solution is to used a cipher that includes a Hash based Message Authentication Code (HMAC) to sign the data. Combining a HMAC function to the existing cipher is prone to error [1]. Specifically, it is always recommended that you be able to verify the HMAC first, and only if the data is unmodified, do you then perform any cryptographic functions on the data. The following modes are vulnerable because they don't provide a HMAC: Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText); Triple DES with ECB mode Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText); Solution: Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText); In the example solution above, the GCM mode introduces an HMAC into the resulting encrypted data, providing integrity of the result.
References |
findsecbugs:INSECURE_SMTP_SSL |
Server identity verification is disabled when making SSL connections. Some email libraries that enable SSL connections do not verify the server certificate by default. This is equivalent to trusting all certificates. When trying to connect to the server, this application would readily accept a certificate issued to "hackedserver.com". The application would now potentially leak sensitive user information on a broken SSL connection to the hacked server.
Vulnerable Code: ... Email email = new SimpleEmail(); email.setHostName("smtp.servermail.com"); email.setSmtpPort(465); email.setAuthenticator(new DefaultAuthenticator(username, password)); email.setSSLOnConnect(true); email.setFrom("user@gmail.com"); email.setSubject("TestMail"); email.setMsg("This is a test mail ... :-)"); email.addTo("foo@bar.com"); email.send(); ...
Solution: email.setSSLCheckServerIdentity(true);
References |
findsecbugs:SERVLET_PARAMETER |
The Servlet can read GET and POST parameters from various methods. The value obtained should be considered unsafe. You may need to validate or sanitize those values before passing them to sensitive APIs such as:
Reference |
findsecbugs:TEMPLATE_INJECTION_VELOCITY |
Velocity template engine is powerful. It is possible to add logic including condition statements, loops and external calls. It is not design to be sandbox to templating operations. A malicious user in control of a template can run malicious code on the server-side. Velocity templates should be seen as scripts. Vulnerable Code: [...] Velocity.evaluate(context, swOut, "test", userInput);
Solution:
References |
findsecbugs:XXE_DOCUMENT |
AttackXML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. Risk 1: Expose local file content (XXE: XML eXternal Entity)
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]> <foo>&xxe;</foo>Risk 2: Denial of service (XEE: Xml Entity Expansion)
<?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> [...] <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz> SolutionIn order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code. Vulnerable Code:
DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = db.parse(input); The following snippets show two available solutions. You can set one feature or both. Solution using "Secure processing" mode: This setting will protect you against Denial of Service attack and remote file access. DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); DocumentBuilder db = dbf.newDocumentBuilder(); Document doc = db.parse(input); Solution disabling DTD: By disabling DTD, almost all XXE attacks will be prevented. DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); DocumentBuilder db = dbf.newDocumentBuilder(); Document doc = db.parse(input);
References |
findsecbugs:PADDING_ORACLE |
This specific mode of CBC with PKCS5Padding is susceptible to padding oracle attacks. An adversary could potentially decrypt the message if the system exposed the difference between plaintext with invalid padding or valid padding. The distinction between valid and invalid padding is usually revealed through distinct error messages being returned for each condition. Code at risk: Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText); Solution: Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte[] cipherText = c.doFinal(plainText);
References |
findsecbugs:ANDROID_BROADCAST |
Broadcast intents can be listen by any application with the appropriate permission. It is suggested to avoid transmitting sensitive information when possible.
Code at risk: Intent i = new Intent(); i.setAction("com.insecure.action.UserConnected"); i.putExtra("username", user); i.putExtra("email", email); i.putExtra("session", newSessionId); this.sendBroadcast(v1);
Solution (if possible): Intent i = new Intent(); i.setAction("com.secure.action.UserConnected"); sendBroadcast(v1);
Configuration (receiver)[1] Source: StackOverflow: <manifest ...> <!-- Permission declaration --> <permission android:name="my.app.PERMISSION" /> <receiver android:name="my.app.BroadcastReceiver" android:permission="my.app.PERMISSION"> <!-- Permission enforcement --> <intent-filter> <action android:name="com.secure.action.UserConnected" /> </intent-filter> </receiver> ... </manifest>
Configuration (sender)[1] Source: StackOverflow: <manifest> <!-- We declare we own the permission to send broadcast to the above receiver --> <uses-permission android:name="my.app.PERMISSION"/> <!-- With the following configuration, both the sender and the receiver apps need to be signed by the same developer certificate. --> <permission android:name="my.app.PERMISSION" android:protectionLevel="signature"/> </manifest>
References |
findsecbugs:AWS_QUERY_INJECTION |
Constructing SimpleDB queries containing user input can allow an attacker to view unauthorized records.
Vulnerable Code: ... String customerID = getAuthenticatedCustomerID(customerName, customerCredentials); String productCategory = request.getParameter("productCategory"); ... AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials); String query = "select * from invoices where productCategory = '" + productCategory + "' and customerID = '" + customerID + "' order by '" + sortColumn + "' asc"; SelectResult sdbResult = sdbc.select(new SelectRequest(query));
Solution:
References |
findsecbugs:STRUTS1_ENDPOINT |
This class is a Struts 1 Action. Once a request is routed to this controller, a Form object will automatically be instantiated that contains the HTTP parameters. The use of these parameters should be reviewed to make sure they are used safely. |
findsecbugs:EXTERNAL_CONFIG_CONTROL |
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious ways. An attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
Code at risk: conn.setCatalog(request.getParameter("catalog"));
References |
findsecbugs:RSA_KEY_SIZE |
The NIST recommends the use of 2048 bits and higher keys for the RSA algorithm. "Digital Signature Verification | RSA: 1024 ≤ len(n) < 2048 | Legacy-use" Vulnerable Code: KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA"); keyGen.initialize(512); Solution: KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA"); keyGen.initialize(2048);
References |
findsecbugs:OGNL_INJECTION |
A expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. Code at risk:
public void getUserProperty(String property) { [...] //The first argument is the dynamic expression. return ognlUtil.getValue("user."+property, ctx, root, String.class); } Solution: In general, method evaluating OGNL expression should not received user input. It is intented to be used in static configurations and JSP.
References |
findsecbugs:COOKIE_USAGE |
The information stored in a custom cookie should not be sensitive or related to the session. In most cases, sensitive data should only be stored in session and referenced by the user's session cookie. See HttpSession (HttpServletRequest.getSession()) Custom cookies can be used for information that needs to live longer than and is independent of a specific session.
Reference |
findsecbugs:TRUST_BOUNDARY_VIOLATION |
"A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data." [1]
Code at risk: public void doSomething(HttpServletRequest req, String activateProperty) { //.. req.getSession().setAttribute(activateProperty,"true"); } public void loginEvent(HttpServletRequest req, String userSubmitted) { //.. req.getSession().setAttribute("user",userSubmitted); }
Solution: The solution would be to add validation prior setting a new session attribute. When possible, prefer data from safe location rather than using direct user input.
References |
findsecbugs:WEAK_HOSTNAME_VERIFIER |
A A TrustManager allowing specific certificates (based on a truststore for example) should be built. Wildcard certificates should be created for reused on multiples subdomains. Detailed information for a proper implementation is available at: [1] [2]
Vulnerable Code: public class AllHosts implements HostnameVerifier { public boolean verify(final String hostname, final SSLSession session) { return true; } }
Solution (TrustMangager based on a keystore): KeyStore ks = //Load keystore containing the certificates trusted SSLContext sc = SSLContext.getInstance("TLS"); TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); tmf.init(ks); sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);
References |
findsecbugs:ANDROID_EXTERNAL_FILE_ACCESS |
The application write data to external storage (potentially SD card). There are multiple security implication to this
action. First, file store on SD card will be accessible to the application having the
Code at risk: file file = new File(getExternalFilesDir(TARGET_TYPE), filename); fos = new FileOutputStream(file); fos.write(confidentialData.getBytes()); fos.flush();
Better alternative: fos = openFileOutput(filename, Context.MODE_PRIVATE); fos.write(string.getBytes());
References |
findsecbugs:SERVLET_SESSION_ID |
The method
The value passed to the client is generally an alphanumeric value (e.g., GET /somePage HTTP/1.1 Host: yourwebsite.com User-Agent: Mozilla/5.0 Cookie: JSESSIONID=Any value of the user's choice!!??'''"> As such, the JSESSIONID should only be used to see if its value matches an existing session ID. If it does not, the user should be considered an unauthenticated user. In addition, the session ID value should never be logged. If it is, then the log file could contain valid active session IDs, allowing an insider to hijack any sessions whose IDs have been logged and are still active.
References |
findsecbugs:LDAP_ANONYMOUS |
Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to abuse poorly configured LDAP environment. All LDAP queries executed against ctx will be performed without authentication and access control. An attacker may be able to manipulate one of these queries in an unexpected way to gain access to records that would otherwise be protected by the directory's access control mechanism. Vulnerable Code: ... env.put(Context.SECURITY_AUTHENTICATION, "none"); DirContext ctx = new InitialDirContext(env); ...
Solution:
References |
findsecbugs:SPRING_CSRF_PROTECTION_DISABLED |
Disabling Spring Security's CSRF protection is unsafe for standard web applications. A valid use case for disabling this protection would be a service exposing state-changing operations that is guaranteed to be used only by non-browser clients.
Insecure configuration: @EnableWebSecurity public class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable(); } }
References |
findsecbugs:HTTP_PARAMETER_POLLUTION |
Concatenating unvalidated user input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach. HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks.
Vulnerable Code: String lang = request.getParameter("lang"); GetMethod get = new GetMethod("http://www.host.com"); get.setQueryString("lang=" + lang + "&user_id=" + user_id); get.execute();
Solution:
References |
findsecbugs:HTTPONLY_COOKIE |
A new cookie is created without the
Code at risk: Cookie cookie = new Cookie("email",userName); response.addCookie(cookie);
Solution (Specific configuration): Cookie cookie = new Cookie("email",userName); cookie.setSecure(true); cookie.setHttpOnly(true); //HttpOnly flag
Solution (Servlet 3.0 configuration): <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0"> [...] <session-config> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config> </web-app>
Reference |
findsecbugs:FILE_UPLOAD_FILENAME |
The filename provided by the FileUpload API can be tampered with by the client to reference unauthorized files. For example:
Therefore, such values should not be passed directly to the filesystem API. If acceptable, the application should generate its own file names and use those. Otherwise, the provided filename should be properly validated to ensure it's properly structured, contains no unauthorized path characters (e.g., / \), and refers to an authorized file.
References |
findbugs:PT_RELATIVE_PATH_TRAVERSAL |
The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory. See http://cwe.mitre.org/data/definitions/23.html for more information. SpotBugs looks only for the most blatant, obvious cases of relative path traversal. If SpotBugs found any, you almost certainly have more vulnerabilities that SpotBugs doesn't report. If you are concerned about relative path traversal, you should seriously consider using a commercial static analysis or pen-testing tool. |
findbugs:XSS_REQUEST_PARAMETER_TO_SEND_ERROR |
This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information. SpotBugs looks only for the most blatant, obvious cases of cross site scripting. If SpotBugs found any, you almost certainly have more cross site scripting vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool. |
findbugs:HRS_REQUEST_PARAMETER_TO_COOKIE |
This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information. SpotBugs looks only for the most blatant, obvious cases of HTTP response splitting. If SpotBugs found any, you almost certainly have more vulnerabilities that SpotBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool. |
findbugs:DMI_CONSTANT_DB_PASSWORD |
This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can easily learn the password. |
findbugs:HRS_REQUEST_PARAMETER_TO_HTTP_HEADER |
This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information. SpotBugs looks only for the most blatant, obvious cases of HTTP response splitting. If SpotBugs found any, you almost certainly have more vulnerabilities that SpotBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool. |
findbugs:PT_ABSOLUTE_PATH_TRAVERSAL |
The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory. See http://cwe.mitre.org/data/definitions/36.html for more information. SpotBugs looks only for the most blatant, obvious cases of absolute path traversal. If SpotBugs found any, you almost certainly have more vulnerabilities that SpotBugs doesn't report. If you are concerned about absolute path traversal, you should seriously consider using a commercial static analysis or pen-testing tool. |
findbugs:SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE |
The method invokes the execute or addBatch method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks. |
findbugs:XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER |
This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information. SpotBugs looks only for the most blatant, obvious cases of cross site scripting. If SpotBugs found any, you almost certainly have more cross site scripting vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool. |
findbugs:DMI_EMPTY_DB_PASSWORD |
This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password. |
findbugs:SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING |
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable. |
findsecbugs-jsp:JSP_JSTL_OUT |
A potential XSS was found. It could be used to execute unwanted JavaScript in a client's browser. (See references) Vulnerable Code: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <c:out value="${param.test_param}" escapeXml="false"/> Solution: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <c:out value="${param.test_param}"/>
References |
findsecbugs-jsp:XSS_JSP_PRINT |
A potential XSS was found. It could be used to execute unwanted JavaScript in a client's browser. (See references) Vulnerable Code: <% String taintedInput = (String) request.getAttribute("input"); %> [...] <%= taintedInput %> Solution: <% String taintedInput = (String) request.getAttribute("input"); %> [...] <%= Encode.forHtml(taintedInput) %> The best defense against XSS is context sensitive output encoding like the example above. There are typically 4 contexts to consider: HTML, JavaScript, CSS (styles), and URLs. Please follow the XSS protection rules defined in the OWASP XSS Prevention Cheat Sheet, which explains these defenses in significant detail.
References |
findsecbugs-jsp:JSP_XSLT |
"XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents".[1]
Code at risk: <x:transform xml="${xmlData}" xslt="${xsltControlledByUser}" />
Solution: The solution would be to make sure the stylesheet is loaded from a safe sources and make sure that vulnerabilities such as Path traversal [3][4] are not possible.
References |
findsecbugs-jsp:XSS_REQUEST_PARAMETER_TO_JSP_WRITER |
This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information. SpotBugs looks only for the most blatant, obvious cases of cross site scripting. If SpotBugs found any, you almost certainly have more cross site scripting vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool. |
findsecbugs-jsp:JSP_INCLUDE |
The inclusion of JSP file allow the entry of dynamic value. It may allow an attacker to control the JSP page included. If this is the case, an attacker will try to include a file on disk that he controls. By including arbitrary files, the attacker gets the ability to execute any code. Vulnerable Code: <jsp:include page="${param.secret_param}" /> Solution: <c:if test="${param.secret_param == 'page1'}"> <jsp:include page="page1.jsp" /> </c:if>
References |
findsecbugs-jsp:JSP_SPRING_EVAL |
A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. Vulnerable Code: <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %> <spring:eval expression="${param.lang}" var="lang" /> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %> <spring:eval expression="'${param.lang}'=='fr'" var="languageIsFrench" /> Solution: <c:set var="lang" value="${param.lang}"/> <c:set var="languageIsFrench" value="${param.lang == 'fr'}"/>
References |
php:S2068 |
Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to end up in the hands of an attacker. This is particularly true for applications that are distributed. Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database. Noncompliant Code Example$uname = "steve"; $password = "blue"; connect($uname, $password); Compliant Solution$uname = getEncryptedUser(); $password = getEncryptedPass(); connect($uname, $password); See
|
php:S2964 |
Noncompliant Code Exampleif (is_bad_ip($requester)) { sleep(5); // Noncompliant } |
php:S1523 |
The According to the PHP documentation
Noncompliant Code Exampleeval($code_to_be_dynamically_executed) See
|
php:S3336 |
PHP's
For that reason, it's better to practice a little "tough love" with your users and force them to turn on cookies. Since Noncompliant Code Example; php.ini session.use_trans_sid=1 ; Noncompliant See
|
php:S3337 |
This rule raises an issue when Noncompliant Code Example; php.ini enable_dl=1 ; Noncompliant Compliant Solution; php.ini enable_dl=0 See
|
php:S3334 |
This rule raises an issue when either property is explicitly enabled in php.ini and when Noncompliant Code Example; php.ini Noncompliant; allow_url_fopen not explicitly disabled allow_url_include=1 ; Noncompliant Compliant Solution; php.ini allow_url_fopen=0 allow_url_include=0 See
|
php:S3335 |
The This rule raises an issue when when Noncompliant Code Example; php.ini cgi.force_redirect=0 ; Noncompliant See
|
php:S3332 |
Cookies without fixed lifetimes or expiration dates are known as non-persistent, or "session" cookies, meaning they last only as long as the browser session, and poof away when the browser closes. Cookies with expiration dates, "persistent" cookies, are stored/persisted until those dates. Non-persistent cookies should be used for the management of logged-in sessions on web sites. To make a cookie non-persistent, simply omit the
This rule raises an issue when See
|
php:S3333 |
The
This is not a fool-proof configuration; it can be reset or overridden at the script level. But its use should be seen as a minimum due diligence
step. This rule raises an issue when Noncompliant Code Example; php.ini try 1 ; open_basedir="${USER}/scripts/data" Noncompliant; commented out ; php.ini try 2 open_basedir="/:${USER}/scripts/data" ; Noncompliant; root directory in the list Compliant Solution; php.ini try 1 open_basedir="${USER}/scripts/data" See
|
php:S3338 |
This rule raises an issue when Noncompliant Code Example; php.ini file_uploads=1 ; Noncompliant Compliant Solution; php.ini file_uploads=0 See
|
findsecbugs:HARD_CODE_PASSWORD |
Passwords should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores. (Hard coded keys are reported separately by Hard Coded Key pattern)
Vulnerable Code: private String SECRET_PASSWORD = "letMeIn!"; Properties props = new Properties(); props.put(Context.SECURITY_CREDENTIALS, "p@ssw0rd");
References |
findsecbugs:XPATH_INJECTION |
XPath injection risks are similar to SQL injection. If the XPath query contains untrusted user input, the complete datasource could be exposed. This could allow an attacker to access unauthorized data or maliciously modify the target XML.
References |
findsecbugs:SCRIPT_ENGINE_INJECTION |
Dymanic code is being evaluate. A careful analysis of the code construction should be made. Malicious code execution could lead to data leakage or operating system compromised. If the evaluation of user code is intended, a proper sandboxing should be applied (see references). Code at risk:
public void runCustomTrigger(String script) { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine = factory.getEngineByName("JavaScript"); engine.eval(script); //Bad things can happen here. } Solution:
Safe evaluation of Javascript code using "Cloudbees Rhino Sandbox" library. public void runCustomTrigger(String script) { SandboxContextFactory contextFactory = new SandboxContextFactory(); Context context = contextFactory.makeContext(); contextFactory.enterContext(context); try { ScriptableObject prototype = context.initStandardObjects(); prototype.setParentScope(null); Scriptable scope = context.newObject(prototype); scope.setPrototype(prototype); context.evaluateString(scope,script, null, -1, null); } finally { context.exit(); } }
References |
findsecbugs:SQL_INJECTION_JDO |
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Vulnerable Code: PersistenceManager pm = getPM(); Query q = pm.newQuery("select * from Users where name = " + input); q.execute();
Solution: PersistenceManager pm = getPM(); Query q = pm.newQuery("select * from Users where name = nameParam"); q.declareParameters("String nameParam"); q.execute(input);
References (JDO) |
findsecbugs:STATIC_IV |
Initialization vector must be regenerated for each message to be encrypted. Vulnerable Code:
private static byte[] IV = new byte[16] {(byte)0,(byte)1,(byte)2,[...]}; public void encrypt(String message) throws Exception { IvParameterSpec ivSpec = new IvParameterSpec(IV); [...] Solution:
public void encrypt(String message) throws Exception { byte[] iv = new byte[16]; new SecureRandom().nextBytes(iv); IvParameterSpec ivSpec = new IvParameterSpec(iv); [...]
References |
findsecbugs:XML_DECODER |
XMLDecoder should not be used to parse untrusted data. Deserializing user input can lead to arbitrary code execution. This is possible because XMLDecoder supports arbitrary method invocation. This capability is intended to call setter methods, but in practice, any method can be called. Malicious XML example: <?xml version="1.0" encoding="UTF-8" ?> <java version="1.4.0" class="java.beans.XMLDecoder"> <object class="java.io.PrintWriter"> <string>/tmp/Hacked.txt</string> <void method="println"> <string>Hello World!</string> </void> <void method="close"/> </object> </java> The XML code above will cause the creation of a file with the content "Hello World!". Vulnerable Code: XMLDecoder d = new XMLDecoder(in); try { Object result = d.readObject(); } [...] Solution: The solution is to avoid using XMLDecoder to parse content from an untrusted source.
References |
findsecbugs:UNENCRYPTED_SOCKET |
The communication channel used is not encrypted. The traffic could be read by an attacker intercepting the network traffic.
Vulnerable Code: Socket soc = new Socket("www.google.com",80);
Solution: Socket soc = SSLSocketFactory.getDefault().createSocket("www.google.com", 443); Beyond using an SSL socket, you need to make sure your use of SSLSocketFactory does all the appropriate certificate validation checks to make sure you are not subject to man-in-the-middle attacks. Please read the OWASP Transport Layer Protection Cheat Sheet for details on how to do this correctly.
References |
pmd:MethodReturnsInternalArray |
Exposing internal arrays directly allows the user to modify some code that could be critical. It is safer to return a copy of the array.
This rule is deprecated, use S2384 instead. |
pmd:ArrayIsStoredDirectly |
Constructors and methods receiving arrays should clone objects and store the copy. This prevents that future changes from the user affect the internal functionality.
This rule is deprecated, use S2384 instead. |
cdk-cobol-rules:S3394 |
The Noncompliant Code Example01 USER-INPUT PIC X(4). GET-USER-INPUT. MOVE 'N' TO WS-NUMERIC. PERFORM UNTIL WS-NUMERIC = 'Y' DISPLAY 'ENTER YOUR 4 DIGIT RECORD NUMBER: ' NO ADVANCING ACCEPT USER-RECORD *> Noncompliant ExceptionsThis rule ignores uses of |
cdk-cobol-rules:SQL.SelectWithNoWhereClauseCheck |
Although the Noncompliant Code ExampleSELECT * FROM db_persons INTO us_persons Compliant SolutionSELECT * FROM db_persons INTO us_persons WHERE country IS 'US' ExceptionsNot having a WHERE clause is acceptable in read-only cursors as results are generally sorted and it is possible to stop processing in the middle. |
cdk-cobol-rules:SQL.DynamicSqlCheck |
It is a bad practice to use Dynamic SQL. It differs from static embedded SQL in that part or all of the actual SQL commands may be stored in a host variable that is built on the fly during execution of the program. In the extreme case, the SQL commands are generated in their entirety by the application program at run time. While dynamic SQL is more flexible than static embedded SQL, it does require additional overhead and is much more difficult to understand and to maintain. Moreover, dynamic SQL may expose the application to SQL injection vulnerabilities. This rule raises an issue when Noncompliant Code ExampleEXEC SQL PREPARE SEL INTO :SQLDA FROM :STMTBUF END-EXEC. |
cdk-cobol-rules:S1686 |
Defining a subprogram to be called at runtime is possible but ill-advised. This extremely powerful feature can quite easily be misused, and even when used correctly, it highly increases the overall complexity of the program, and makes it impossible before runtime to know exactly what will be executed. Therefore defining the subprogram to be called at runtime is a feature that should be avoided. Noncompliant Code ExampleMOVE SOMETHING TO MY_SUBPROG. ... CALL MY_SUBPROG. Compliant Solution01 MY_SUBPROG PIC X(10) VALUE "SUB123". .... CALL MY_SUBPROG. |
cdk-cobol-rules:S1685 |
Debug statements (ones with 'D' or 'd' in the indicator area) should not be executed in production, but the Noncompliant Code ExampleSOURCE-COMPUTER. IBM-370 WITH DEBUGGING MODE. Compliant SolutionSOURCE-COMPUTER. IBM-370. See
|
cdk-cobol-rules:COBOL.DisplayStatementUsageCheck |
The Noncompliant Code ExampleDISPLAY "hello world" *> Noncompliant |