Security is one of the most complex, extensive, and important considerations in software development. Java is a development platform with many built-in security functions. In the long-term development process of Java, it has passed a lot of high-intensity security tests, and often updated security vulnerabilities. And the Java ecosystem includes tools for analyzing and reporting security issues.
However, even with a solid development platform in place, be vigilant. Application development is complex and bugs can be hidden. Programmers should consider security at every stage of application development, from class-level code programming to API endpoint authorization.
Here are some basic rules to build a good foundation for more secure Java applications. For reference study!
Java Security Rule 1: Write simple and powerful Java code
Bugs like to hide in complex code, so keep the code as simple as possible without sacrificing functionality. Expose as little information as possible in your code, hide implementation details, and support maintainable and secure code. Here are three tips that will go a long way toward writing secure Java code:
- Take full advantage of Java’s access modifiers. For classes, methods and their properties declare access levels, and everything that can be set private should be private.
- Avoid excessive use of reflection and introspection. In some cases, you should use such advanced techniques, but in most cases, you should avoid them. Using reflection eliminates strong typing, which can introduce bugs and instability into your code. Comparing a class name to a string is error-prone and can easily lead to namespace conflicts.
- Always define the smallest API and interface possible. Decouple components and make them interact in the smallest possible area. Even if one area of your application is compromised, the rest will be safe.
Java Safety Rule 2: Avoid using Java native serialization
Serialization takes remote input and converts it to a fully assigned object. It dispenses with constructors and access modifiers and allows unknown data streams to become running code in the JVM. Java serialization is fundamentally insecure.
Oracle has long planned to remove its own serialization functionality from Java, and a third or more of Java vulnerabilities involve serialization issues, says Mark Reinhold, lead architect for Oracle’s Java Platform group.
Avoid using native serialization/deserialization in Java code whenever possible. Consider using serialization formats such as JSON or YAML, and never expose unprotected network request endpoints that are received and used to serialize streams.
Java Security Rule 3: Never expose unencrypted credentials or PIIs
In many applications, when a user enters a password in a browser, it will be sent to your server in plain text. The correct way to do this is to encrypt the password with a one-way password, then persist it to the database, and then encrypt it again every time it is compared to the value. Password rules apply to all personally identifiable information (PII) : credit cards, Social Security numbers, etc. Any personal information entrusted to your application should be protected to the highest degree. An unencrypted credential or PII in a database is a huge security hole waiting to be discovered by an attacker. Likewise, do not log the original credentials or otherwise transfer them to a file or network. Save the password and key separately.
Java security Rule 4: Use known and tested libraries
Use known, reliable libraries and frameworks whenever possible. From password hashing to REST API authorization, choose third-party libraries carefully. Spring Security has become the de facto standard for Web application Security. It provides a wide range of choices and flexibility to accommodate any application architecture and incorporates multiple security approaches.
Java security Rule 5: Don’t have any illusions about external input
Don’t let your guard down on any external input, whether from a user input form, a data store, or a remote API.
SQL injection and cross-site scripting (XSS) are the most common attacks caused by handling external input errors. Each time you receive input, it should be checked and validated.
Java Security Rule 6: Always use a PreparedStatement to process SQL parameters
Every time you build an SQL statement, it is possible to insert a piece of executable SQL code. Always use a Java, SQL PreparedStatement class to create SQL is a good habit. Similar functionality exists for NoSQL stores such as MongoDB. Most ORM frameworks support this functionality.
Java Security Rule 7: Do not display service exception information to users
Service exception information in production can provide a rich source of information for attackers. Stack traces in particular can reveal information about the technology you are using and how you are using it. It is important to avoid showing stack trace information to the end user.
Java Security Rule 8: Keep security releases up to date
Make sure you know what important patches are available by periodically checking the Oracle home page for security-Alerts. Every quarter, Oracle provides an automatic patch update for the current LTS (long Term support) release of Java. The catch is that this patch is only available if you purchase a Java support license.
Java Security Rule 9: Find dependency library vulnerabilities
There are many tools that automatically scan your code base and dependencies for vulnerabilities. OWASP (Open Web Application Security Project) is an organization dedicated to improving code security. OWASP’s list of trusted, high-quality automated code scanning tools, including several Java-oriented security checking tools.
Java Security Rule 10: Monitor and log user activity
If you don’t actively monitor the health of your app, even a simple violent attack can succeed in bringing your app down. Use monitoring and logging tools to monitor the health of your application. Monitoring can alert you to spikes that cannot be explained, and logging can help you understand what went wrong after an attack.
Java Security Rule 11: Beware of DoS attacks
Every time you perform a resource-consuming operation, such as unzipping a compressed file, you should monitor the increase in resource usage. Monitoring and preventing overuse of server resources, as well as more automated emergency response solutions.
Java Security Rule 12: Consider using a Java security manager
Java has a security manager that can be used to restrict the resources that a running process can access. It can isolate programs based on disk, memory, network, and JVM access. Narrowing the overuse of these resources on an application can reduce the damage that an attack can cause.
Welcome to my blog, where there are many fine collections
- This article is reprinted with a credit (must be accompanied by a link, not only the text) : Antetokounmpo blog.
Feel helpful to you, help me like, share! Your support is my inexhaustible creative power! . In addition, the author recently a period of time output as follows boutique content, looking forward to your attention.
- Spring Boot2.0 by Hand
- Spring Security- JWT-OAUTH2
- RBAC Authority Management System for Actual Combat Front-end and Back-end Separation
- “Actual SpringCloud Micro-service from Bronze to King”
- VUE Series