The 10 most important security controls missed in Java EE

This article by the code Farm-small peak original translation, reproduced please see the text at the end of the reprint requirements, welcome to participate in our paid contribution program!

Java EE has some great built-in security mechanisms, but they are far from covering all the threats your application faces. Many common attacks, such as cross-site scripting attacks (XSS), SQL injection, cross-site forgery requests (CSRF), and XML external entities (XXE) are not covered in the slightest. You can prevent Web applications and Web services from exposing these attacks, but this requires a certain amount of work and testing. Fortunately, Open Web Application Security Project (OWASP) publishes the "Top 10 most critical WEB application Security Risks" report.

Let's take a look at how these key risks apply to Java EE Web applications and Web services:

1. Inject

Injection occurs at any time that the developer obtains untrusted information, such as Request.getparameter (), Request.getcookie (), or Request.getheader (), and uses it in the command interface. For example, SQL injection when you connect untrusted data to a regular SQL query, such as "select * from Users where username= '" + request.getparameter ("user") + "' and password= '" + R Equest.getparameter ("pass") = "'" occurs. Developers should use PreparedStatement to prevent attackers from changing the meaning of the query and taking over the database host. There are many other types of injections, such as command injection, LDAP injection, and expression Language (EL) injection, all of which are extremely dangerous, so be cautious when sending data to these interpreters.

2. Corrupted authentication and Session management

Java EE supports authentication and session management, but there are many error-prone areas. You must ensure that all authenticated traffic passes through SSL, with no exceptions. If you have ever exposed jsessionid, then it can be used to hijack user sessions without your knowledge. You should rotate the jsessionid when the user authenticates to prevent the session from pinning the attack (session fixation attack). You should avoid using Response.encodeurl () because it will add the user's jsessionid to the URL, making it easier to be disclosed or stolen.

3. Cross-site scripting attacks (XSS)

XSS occurs when a Java EE developer obtains untrusted information from an HTTP request and places it in an HTTP response without the appropriate context output encoding. Attackers can use this behavior to inject their scripts into a Web site and then hijack sessions and steal data on the site. To prevent these attacks, developers need to perform sensitive context output coding. If you convert the data into HTML, use the & #xx; Be sure to bracket the HTML property, because there are many different characters without parentheses in the property will be terminated. If you put untrusted data into Javascript,url or CSS, you should use the appropriate escape method for each one. And be very careful when dealing with nested contexts, such as a URL written in JavaScript in HTML properties. You might want to encode libraries such as owasp Esapi help.

4. Unsafe direct Object references

Any time an application exposes an internal identifier, such as a database key, file name, or HashMap index, an attacker could attempt to manipulate these identifiers to access unauthorized data. For example, if you pass untrusted data from an HTTP request to a Java file constructor, an attacker could take advantage of the ".. /"or an empty byte attack to spoof your authentication. You should consider using indirect references to your data to prevent this type of attack. The ESAPI library supports referencemaps that facilitate this indirect reference.

5. Wrong Security Configuration

Modern Java EE applications and frameworks, such as struts and spring, have a large number of security settings. Make sure you've browsed through these security settings and set them as you want. For example, be careful with the

6. Sensitive data exposure

Java has a large number of cryptographic libraries, but they are not easy to use correctly. You should find a library based on JCE, and it can provide useful encryption methods conveniently and safely. For example, Jasypt and ESAPI are such libraries. You should use powerful algorithms such as AES for encryption, and SHA256 for hashes. But be careful with password hashes, because they can be decrypted with rainbow table, so use an adaptive algorithm such as Bcrypt or PBKDF2.

7. Lack of functional level access control

Java EE supports declarative and programmatic access control, but many applications still choose to create their own scenarios. Like the spring framework, there is also a comment-based access control primitive. The most important thing is to ensure that every exposed port has appropriate access control checks, including Web services. Do not assume that the client can control anything because the attacker will directly access your endpoint.

8. Cross-site forgery requests (CSRF)

Each endpoint that changes the state needs to verify that the request has not been forged. The developer should put a random token in each user's session and then validate it when the request arrives. Otherwise, an attacker could create an "attack" page from a malicious img,script, frame or form tag linked to an unprotected application. When the victim browses to this page, the browser generates a "fake" HTTP request to any content specified in the URL in the tag, and automatically includes the victim's authentication information.

9. Using a component with a known vulnerability

Modern Java EE applications have hundreds of of libraries. Dependency resolution tools, such as MAVEN, have caused this number to explode over the last five years. Many of the widely used Java libraries have some known vulnerabilities that can make Web applications completely subversive. The solution is to update the library in a timely manner. Do not just run a single scan, because new vulnerabilities are released every day.

10. Unauthenticated forwarding and forwarding

Any time your application uses untrusted data, For example, Request.getparameter () or Request.getcookie (), when calling Response.sendredirect (), an attacker could force the victim's browser to go to an untrusted Web site in order to install malicious software. Forward also has a similar problem, except that attackers can transfer themselves to unauthorized functions, such as administration pages. Be sure to carefully verify the forwarding and forwarding targets.

You should keep an eye on these questions. New attacks and vulnerabilities are always being discovered. Ideally, you can integrate security checks into your existing build, test, and deployment processes.

To check for these issues in your application, you can try the free contrast for Eclipse plugin. This is not a simple static analysis tool. Instead, C4E uses the Java Instrumentation API to monitor everything in the application that is relevant to security. C4E can even do complete data flow analysis in real time, so it tracks data from the request through a complex application. For example, suppose your code obtains a parameter value, decodes it with Base64, stores it in a map, places the map into a data bean, stores the Bean in a session property, gets the bean's value in the JSP, and uses El to insert the value into the Web page. Contrast for Eclipse can track this data and report XSS vulnerabilities. Even if you are using a complex framework and library. No other tool can match the speed, precision and ease of use.

You can find contrast for eclipse in Eclipse Marketplace. Then, just go to the Server tab "Start with contrast"--leave the rest to it.

The 10 most important security controls that are missing from Java EE