SpotBugs Security: High level issues

WebView myWebView = (WebView) findViewById(R.id.webView);
WebSettings webSettings = myWebView.getSettings();
webSettings.setJavaScriptEnabled(true);

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: SHA-1 may only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance. For all other applications, SHA-1 shall not be used for digital signature generation. SHA-1 for digital signature verification: For digital signature verification, SHA-1 is allowed for legacy-use. […] SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256: The use of these hash functions is acceptable for all hash function applications.” – NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15

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.

1. Authentication, if enforced, should be tested.
2. Access control, if enforced, should be tested.
3. The inputs should be tracked for potential vulnerabilities.
4. The communication should ideally be over SSL.
5. If the service supports writes (e.g., via POST), its vulnerability to CSRF should be investigated.[1]

1. Authentication, if enforced, should be tested.
2. Access control, if enforced, should be tested.
3. The inputs should be tracked for potential vulnerabilities.
4. The communication should ideally be over SSL.

Scenario:
1. A user is tricked into visiting the malicious URL: “http://website.com/login?redirect=http://evil.vvebsite.com/fake/login “
2. The user is redirected to a fake login page that looks like a site they trust. (“http://evil.vvebsite.com/fake/login”)
3. The user enters his credentials.
4. The evil site steals the user’s credentials and redirects him to the original website. This attack is plausible because most users don’t double check the URL after the redirection. Also, redirection to an authentication page is very common.

A quick fix could be to replace the use of java.util.Random with something stronger, such as java.security.SecureRandom.

A quick fix could be to replace the use of java.util.Random with something stronger, such as java.security.SecureRandom.

Vulnerable Code:
@(value: Html)

@value

Solution:
@(value: String)

@value

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.

Recommendations: No access control should be based on the value of this header. No CSRF protection should be based only on this value (because it is optional).

1. SQL query (May lead to SQL injection)
2. File opening (May lead to path traversal)
3. Command execution (Potential Command injection)
4. HTML construction (Potential XSS)
5. etc…

For the URL request /app/servlet.htm?a=1&b=2, the query string extract will be a=1&b=2

Just as is true for individual parameter values retrieved via methods like HttpServletRequest.getParameter(), the value obtained from HttpServletRequest.getQueryString() should be considered unsafe. You may need to validate or sanitize anything pulled from the query string before passing it to sensitive API

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.

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.

Scenario:
1. A user is tricked into visiting the malicious URL: “http://website.com/login?redirect=http://evil.vvebsite.com/fake/login”
2. The user is redirected to a fake login page that looks like a site they trust. (“http://evil.vvebsite.com/fake/login”)
3. The user enters his credentials.
4. The evil site steals the user’s credentials and redirects him to the original website. This attack is plausible because most users don’t double check the URL after the redirection. Also, redirection to an authentication page is very common.

or the definition of an explicit annotation:

@org.apache.tapestry5.annotations.Component(id = “password”)
private PasswordField passwordField;
[…]

The page is mapped to the view [/resources/package/PageName].tml.

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.

Scenario:.
1. A user is tricked into visiting the malicious URL: “http://website.com/login?redirect=http://evil.vvebsite.com/fake/login”
2. The user is redirected to a fake login page that looks like a site they trust. (“http://evil.vvebsite.com/fake/login”)
3. The user enters his credentials.
4. The evil site steals the user’s credentials and redirects him to the original website. This attack is plausible because most users don’t double check the URL after the redirection. Also, redirection to an authentication page is very common.

“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]” – Wikipedia: MD5 – Security

“SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256: The use of these hash functions is acceptable for all hash function applications.” – NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15

“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.” – NIST: Recommendation for Password-Based Key Derivation p.12

“SHA-1 for digital signature generation: SHA-1 may only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance. For all other applications, SHA-1 shall not be used for digital signature generation. SHA-1 for digital signature verification: For digital signature verification, SHA-1 is allowed for legacy-use. […] SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256: The use of these hash functions is acceptable for all hash function applications.” – NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15

“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.” – NIST: Recommendation for Password-Based Key Derivation p.12

Malicious XML example:

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.

The filtering is weak for a few reasons:
1. It covers only parameters not headers and side-channel inputs
2. The replace chain can be bypassed easily (see example below)
3. It’s a black list of very specific bad patterns (rather than a white list of good/valid input)