OWASP's top 10 Web security problems are totally out of control in the JEE System

OWASP's top 10 Web security problems are totally out of control in the JEE System

Although Java ee has some excellent built-in security mechanisms, it cannot fully cope with various threats facing applications, especially many of the most common attacks: Cross-Site attacks (XSS ), SQL Injection, Cross-Site Request Forgery (CSRF), and XML eXternal Entities (XXE. If you do not perform a large number of security tests, vulnerability fixes, or purchase application-level security protection tools, your applications will be completely exposed to these attacks.

Fortunately, the open-source Web Application Security Organization (OWASP) has listed the following 10 Web problems as the most important security attacks. For details, see: ten Most Critical Web Application Security Risks report. We hope to attract enough attention to these security issues.

The following describes in detail how these most famous security attacks work in Java EE Web applications and Web Services:

1. injection attacks

During program writing, any suspicious information input may be injection attacks, such as request. getParameter (), request. getCookie () and request. getHeader (), or even the USER command line interface, also has the risk of injection. If the developer concatenates data and SQL commands to form an SQL statement, there is a risk of SQL injection. For example, "SELECT * FROM users WHERE username = '" + request. getParameter ("user") + "'AND password ='" + request. getParameter ("pass") = "'"; the correct way for developers is to use the PreparedStatement method to avoid hackers having the opportunity to change the original meaning of SQL statements and control the database. In addition to SQL Injection, there are many Injection attacks, including Command Injection, LDAP Injection, and Expression Language (EL) Injection. All these injections are very dangerous, be very careful when writing a module that accepts data.

2. invalid identity and session management

Java EE supports identity verification and session management, but does not have enough security capabilities. There are many ways to destroy it. The programmer has to ensure that each authentication passes the SSL Secure Channel and that no exceptions occur. If a JSESSIONID is unfortunately exposed, hackers can hijack the session as long as they have mastered the JSESSIONID. In many cases, they have to confuse the JSESSIONID to prevent Session Fixation attacks. Using response. encodeURL () to add JSESSIONID to the URL is very dangerous, and JSESSIONID is easily stolen. This behavior must be avoided.

3. Cross-Site Scripting (XSS)

If the application receives untrusted data, it sends it to a web browser without proper verification and escape, cross-site scripting (XSS) attacks will occur ). XSS allows attackers to execute scripts on the victim's browser to hijack user sessions, harm websites, or redirect users to malicious websites.

4. Insecure direct object reference

When a developer exposes a reference to an internal implemented object, such as a file, directory, or database key, an insecure direct object reference is generated. Without access control detection or other protection, attackers can manipulate these references to access unauthorized data.

5. Security Configuration Error

Modern JavaEE applications and frameworks such as Struts and Spring have many security configurations. When using these frameworks, make sure these configurations are correct. For example, be careful when developing Web applications. In Label, which means that security-constraint only applies to the methods listed in the label. Hackers can use methods other than this list, such as HEAD and PUT, to launch attacks, thus crossing security restrictions. In most cases, developers should delete Label.

6. Sensitive Information Leakage

Java implements encryption and decryption using the extension library. Java provides common interfaces. Any user can implement encryption based on interfaces with simple configurations. This advantage is that the scalability is strong, the disadvantage is that it is not easy to correctly use the password Library: Step 1: Find a JCE-based top-level encryption library and provide simple and secure encryption methods. Jasypt and ESAPI are very good. Step 2: Use strong encryption algorithms such as AES for encryption and SHA256 for hash. for sensitive information such as passwords, wide hashing is not enough. Hackers can decrypt the data through the Rainbow table, therefore, adaptive security algorithms such as bcrypt or PBKDF2 must be used. Improper use may cause leakage of sensitive information.

7. Lack of function-level access control

Java EE supports both declarative and programming access control methods. frameworks such as Spring also support annotation-Based Access Control. However, many applications still choose to create their own access control processes, in fact, this is a very dangerous behavior. More importantly, make sure that each exposed interface and Web Service has correct access control. Never assume that the customer can control everything, in this way, hackers can directly access the program.

8. Cross-Site Request Forgery (CSRF)

For each State change, the application should verify whether the request is forged. The developer places a random token in each user session and then verifies each request, otherwise, attackers may create harmful tags, such as IMG, SCRIPT, FRAME, or FORM, which may point to unprotected applications. When a victim accesses such a page, the browser will automatically generate a forged HTTP request to the specified URL in the tag, which usually contains the credential of the victim.

9. Use components with known vulnerabilities

Modern JavaEE applications usually include hundreds of databases, especially over the past five years when dependency management tools are available, this number is even more explosive. The widely used Java library contains many known vulnerabilities, which are very dangerous. There is no other way to fix these vulnerabilities. You can only wait for the database provider to fix the vulnerabilities and update them to the latest version in time.

10. Unverified redirection and forwarding

Trusted Web applications often redirect or forward users to other webpages and websites, and use untrusted data to determine target pages. If not properly verified, attackers can redirect victims to phishing software or malicious websites, or use forwarding to access unauthorized pages. When response is called in the JavaEE Web program. sendRedirect () is using request. getParameter () or request. this often happens when getCookie () is used to obtain untrusted data.

Every Java EE programmer will often encounter these ten security problems, and new attacks and vulnerabilities are constantly discovered, what we can do now is to constantly use security code check tools to scan the project during development, testing, and deployment to check for vulnerabilities that are not fixed.

You can try to use some free comparison plug-ins of Eclipse to check these vulnerabilities. These are not only static analysis tools, but C4E is a very meaningful tool, it uses Java Instrumentation API to view security-related content in the monitoring application. It can also analyze the entire data stream in real time and track data from the request in a complex application. For example, the common data streams in Java EE Web applications are as follows: the code obtains parameters from the request, decodes the data with base64, stores the data in the Map, and then stores the Map in a Bean, then, put the Bean in the Session as the attribute, and finally extract it from the JSP. Use the EL language to enter the Bean value on the page. The Eclipse comparison tool can track this data stream and report whether XSS vulnerabilities exist. This tool is very convenient and even useful for applications that use very complex frameworks and libraries. Compared with many existing analysis tools, this tool has obvious advantages in speed, accuracy, and ease of use.

Of course, the popular RASP (Runtime Aplication Security Protector) is also a powerful tool to deal with these ten Security issues. It combines real-time code check and real-time interception, integrates security protection code with applications to make applications self-immune like vaccines. This is an application security protection solution that Gartner strongly recommends. It is very convenient to use, provides complete real-time protection, and is easy to use. Security protection can be easily implemented without modifying any application code.