A look at Java security and how to improve it.

Java was originally designed with security in mind, making its current reputation for insecurity miserable. Yet it is probably inevitable that the flaws of a twenty-five-year-old language will be discovered and exploited. Especially with a language like Java which is still part of the The first three most popular programming languages ​​today.

Java is not the least secure and widely used programming language, but it is also in the top three list, according to recent research. These poor security ratings occur despite the extensive security features built into Java development and available through libraries. For example, Java security libraries offer:

• Strong data entry
• Automatic memory management
• Bytecode verification
• Safe class loading

Java was designed with the security weaknesses of C and C ++ in mind, and actively designed to improve their weaknesses. Highly vulnerable processes such as memory deallocation have been offloaded to the automated garbage collector rather than left in the hands of developers. Other dangerous constructs have been left outside of Java or modified to run more securely – forced index checking before accessing arrays, for example. In a broad attempt to correct coding errors in general, forced exception catching has been incorporated into the compiler.

Yet despite the hard work that Oracle and others have done to secure the platform, the well-known features of Java remain. unsafe.

Why is Java not secure?

One of the factors contributing to the insecurity of Java is the Java Virtual Machine (JVM) which is needed to handle the bad byte code. Java is also vulnerable to the insecurities built into of confidence code or user input that can maliciously subvert it through injection attacks. Java applications importing vulnerabilities from bugged open source components is another issue, which impacts an estimate. 97% of test cases.

Five tips for securing Java applications

Writing a bulletproof Java application would be difficult, if not impossible. However, many Java applications can become considerably more secure by following a few simple guidelines. Taking a few small steps to harden a Java application against cyberthreats is well worth the long-term benefits of releasing a robust program. Developers who want to make sure their Java applications are more secure than average should consider the following five tips:

Clear sensitive data

An easy way to secure Java applications is to erase sensitive data after use. Leaving high-value data such as encryption keys, Personally Identifiable Information (PII), or user credentials for garbage collection exposes them to potential danger. For example, users with the same access rights as the Java application may be able to read sensitive data before it is destroyed. Remote attackers could use Bleeding heart, the bug of over-reading the buffer in Open SSL to access persistent information. Firewire or Thunderbolt ports are also vulnerable to DMA attacks that could expose sensitive data in memory.

Data that has not been erased may also be saved to the disc. This can happen if the host system goes into hibernation mode, if the memory becomes too full, or if the application crashes and performs core dumps. Once sensitive data is written to disk, it is vulnerable to dumpster dive attacks. However, all of these attack vectors can be mitigated by erasing sensitive data as soon as it is no longer needed by the application.

Minimize or avoid deserialization of objects

Deserialization has proven to be a persistent and serious problem for Java. Deserialization occurs after an object is serialized (converted to a bitstream), transferred, and then recreated as an object.

1 Serialization, transfer and deserialization of Java objects.

The problem occurs when the JVM deserializes or restores the bit stream to an object. If the JVM selects the correct type of object during the restore process, all is well. However, attackers can create exploitation opportunities by forcing the JVM to translate bit streams into the wrong type of objects. Some exploits of deserialization allow remote code execution, which makes it a serious security threat.

The best way to avoid this vulnerability is to simply not use deserialization at all. Learning to code in Java without using serialization can ultimately come in handy as there are serious discussions about removing the feature. absolutely.

Prevent code injections

Code injections come in many forms, but generally work according to the same basic principles:

• Attackers provide malicious input to a program, often in the form of a command or request
• The wrong entry is processed by an interpreter
• Malicious data interpretation alters program execution for the benefit of attackers

One effective technique for combating code injections is to clean up a user’s input by making it conform to a whitelist of acceptable characters. This prevents malicious actors from including executable input or other characters that could subvert the program through the interpreter.

Another common form of injection attack against Java is XML External Entity (XXE) attacks targeting the XML interpreter. A well-known example is the Billions of laughs attack. This denial of service attack uses an exponentially growing, self-referencing malicious XML entity created through Document Type Definitions (DTDs), see Figure 2.

2 Example of Billion Laughs XXE exploit, using XML with DTD

XXE attacks can be stopped by ensuring that input conforms to specific lengths and formats, whitelists, or disallows DTDs. Blocking the expansion of entities is another viable solution.

Never accept unauthorized file downloads

If a Java application accepts files, it is important to make sure that it rejects malicious, untrusted, and unauthorized downloads. Making sure a file matches the expected file type goes a long way in avoiding security issues. For example, if an application calls an image file, it must verify that no element containing executable code is accepted. There are several ways to check the contents of a file, ranging from simply checking the filename to magic number test, to fully scan the file. While a balance must be struck between scanning files and the overall performance of the application, stronger verification processes will inevitably lead to better security.

Perform application security testing throughout the SDLC

Creating a secure Java application is easier when effective application security testing is integrated throughout the SDLC. Two particularly useful testing methods that work well during development are security testing of next-generation static applications (NG-SAST) and Smart SCA.

Benefits of ShiftLeft CORE NG-SAST

ShiftLeft CORE’s NG-SAST improves upon traditional SAST by leveraging the power of the Code Property Graph (CPG) to shorten test times and improve results. The CPG is a joint data structure that combines information from abstract syntax trees, control flow charts, and program dependency charts. This allows the CPG to quickly detect attackable paths in custom code.

3 The Code Property Graph (CPG) combines three representations of the source code into a general-purpose common data structure

Compared to traditional static tests, NG-SAST using GCs achieved a 100% true positive rate and scored 45% above average in OWASP trials.

Benefits of ShiftLeft CORE Smart SCA

Software Composition Analysis (SCA) is a useful technique for determining whether an application relies on libraries with known vulnerabilities. Java applications, as well as 96% other applications use open source components which may contain vulnerabilities.

However, it is possible for applications to use vulnerable components in a way that makes them inaccessible by the inputs controlled by the attacker. ShiftLeft CORE’s Intelligent SCA (I-SCA) not only identifies known vulnerabilities in packages, but it uses attack capability to determine if vulnerabilities are accessible by threat actors. By objectively analyzing risk exposure, Smart SCA can save developers time by ensuring they only mitigate actionable issues.

Interested in security testing of Java applications?

To see how the attack provides high contextual security scores for Java early in the development lifecycle, create a free account at https://www.shiftleft.io/register.

Five useful tips for securing Java applications was originally published in ShiftLeft Blog on Medium, where people continue the conversation by highlighting and responding to this story.

*** This is a Syndicated Security Bloggers Network blog by ShiftLeft Blog – Medium written by the ShiftLeft team. Read the original post on: https://blog.shiftleft.io/five-useful-tips-for-securing-java-apps-8d834e875ec?source=rss—-86a4f941c7da—4