The 10 most important security controls missing from Java EE

JavaEE has some awesome built-insecuritymechanisms, but they fall far short of covering them All the threats your application faces. Many common attacks such as Cross-Site Scripting (XSS), SQL Injection, Cross-Site Request Forgery (CSRF), andXMLExternal Entities (XXE) are not covered at all. It is possible to prevent web applications and web services from being exposed to these attacks, but it requires a certain amount of work and testing. Fortunately, the Open Web Application Security Project (OWASP) published the "Top 10 most critical ones". "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. Injection

Injection occurs when the developer obtains untrusted information, such as request.getParameter(), request.getCookie(), or request.getHeader(), and in Use it anytime in a command interface. For example, SQL injection when you connect untrusted data to a regular SQL query like "SELECT * FROM users WHERE username='" + request.getParameter("user") + "' AND password='" + request.getParameter("pass") = "'" Occurs when developers should use PreparedStatement to prevent attackers from changing the meaning of queries and taking over the database host. There are many other types Injections such as Command injection, LDAP injection, and ExpressionLanguage (EL) injection, all of which are extremely dangerous, so be extremely careful when sending data to these interpreters

2. .Broken Authentication and Session Management

JavaEE supports authentication and session management, but there are a lot of things that can go wrong here. You must ensure that all authenticated traffic goes over SSL, no exceptions if you ever expose J##. #SESSIONID, then it can be used to hijack a user's session without your knowledge. You should rotate the JSESSIONID when the user authenticates to prevent session fixation attacks. Avoid using response.encodeURL() as it adds the user's JSESSIONID to the URL, making it more susceptible to disclosure or theft.

3. Cross-site scripting attack (XSS)

XSS occurs when a JavaEE developer obtains untrusted information from an HTTP request and puts it into the HTTP response without appropriate Context output when encoding. Attackers can exploit this

behaviorto inject their scripts into a website where they can then hijack sessions and steal data. To prevent these attacks, developers need to perform sensitive context output encoding. If you are converting data to HTML, use the x; format. Be sure to bracketHTML attributes, as attributes without brackets will be terminated if there are many different characters. If you put untrusted data intoJavaScript, a URL, or CSS, you should use the appropriate escape method for each. And be very careful when dealing with nested context, such as a URL written in Javascript within an HTML attribute. You may want to help with coding libraries such as OWASP ESAPI.

4. Insecure direct object references

Any time an application exposes an internal identifier, such as a database key, file name, or

hashmapindex, an attacker can 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 can use "../" or null byte attacks to trick your validation. You should consider using indirect references to your data to prevent this type of attack. The ESAPI library supports ReferenceMaps that facilitate such indirect references.

5. Wrong security configuration

Modern JavaEE applications andframeworks, such as Struts and Spring, have a large number of security settings. Make sure you go through the security settings and set them up the way you want. For example, be careful with the tag in . This indicates that the security constraintsonly apply to the listed methods, allowing an attacker to use other HTTP methods, such as HEAD and PUT, to bypass the entire security constraint. Maybe you should remove the tag in web.xml.

6. Sensitive data exposure

Java has a large number of encryption libraries, but they are not easy to use correctly. You should find a library built on top of JCE that provides useful encryption methods conveniently and securely. For example, Jasypt and ESAPI are such libraries. You should use strong algorithms such as AES for encryption, and SHA256 for hashes. But be careful with password hashes as they can be decrypted using a Rainbow Table, so use an adaptive algorithm like bcrypt or PBKDF2.

7. Lack of functional-level access control

JavaEE supports declarative and procedural access control, but many applications still choose to create their own solutions. The Spring framework also has access control primitives based on

annotations. The most important thing is to ensure that every exposed port has appropriate access control checks, including web services. Don't assume that the client can control anything, as attackers will have direct access to your endpoints.

8. Cross-site request forgery (CSRF)

Each endpoint that changes

statusneeds to verify that the request has not been forged. Developers should put a random token into each user's session and then validate it when the request arrives. Otherwise, an attacker could create an "attack" page via a malicious IMG, SCRIPT, FRAME or FORM tag linked to an unprotected application. When a victim views such a page, the browser generates a "fake" HTTP request to whatever URL is specified in the tag, automatically including the victim's authentication information.

9. Use components with known vulnerabilities

Modern JavaEE applications have hundreds of libraries. Dependency resolution tools, such as Maven, have caused this number to explode over the past five years. Many widely used Java libraries have known vulnerabilities that can completely subvert web applications. The solution is to

updatethe library in a timely manner. Don't just run a single scan, as new vulnerabilities are released every day.

10. Unauthenticated forwarding and forwarding

Anytime your application uses untrusted data, such as request.getParameter() or request.getCookie(), when calling response .sendRedirect(), an attacker can force the victim's browser to go to an untrusted website with the goal of

installingmalware. forward presents a similar problem, except that attackers can forward themselves to unauthorized functionality, such as admin pages. Be sure to double-check redirects and forwarding destinations.

You should continue to pay attention to these issues. New attacks and vulnerabilities are being discovered all the time. 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

Eclipseplugin. This is not a simplestaticanalysis tool. Instead, C4E leverages Java instrumentation APIs to monitor everything security-related in the application. C4E can even do complete data flow analysis in real time, so it can trace data from a request through a complex application. For example, suppose your code takes a parameter value, decodes it with base64, stores it in a map, puts the map in a data bean, and stores the bean in a session property, inJSPGet the bean's value and insert this value into the web page using EL. Contrast for Eclipse can track this data and report XSS vulnerabilities. Even if you are using complex frameworks and libraries. No other tool can match its speed, accuracy and ease of use.

You can find Contrast for Eclipse in the Eclipse Marketplace. Then, just go to the server tab "Start with Contrast" - it will do the rest.

The above is the detailed content of The 10 most important security controls missing from Java EE. For more information, please follow other related articles on the PHP Chinese website!