Java Security

Java Security

It is interesting to note that until a few years ago, security concerns
were raised about downloading data: do they contain viruses, or maybe
Trojan horses? The advent and popularity of Java has created a new
paradigm: downloaded content can now also be executable.
Java developers have tried to address security by implementing a few
mechanisms, which are supposed to remove the risks of executing
untrusted code:
• Memory access.
• The Java Sandbox.
• The Byte-code Verifier.
• The Applet Class Loader.
• The Security Manager.

Memory Access

Java developers have often promoted Java as a secure language. At the
lowest level, security goes hand in hand with robustness. Java
programs cannot:
• Forge pointers to memory
• Overflow arrays
• Read memory outside the bounds of an array or string

These features are supposed to be the main defences against malicious
code. It has been argued that by disallowing direct access to memory, a
huge, messy class of security attacks is ruled out.
Byte-code Verification
The second line of defence against malicious code is the byte-code
verification procedure that the Java interpreter performs on any
untrusted code it loads. The verification procedure should ensure that
the code is well formed. For example, it should not overflow or
underflow the stack or contain illegal byte-codes. If the byte-code
verification step was skipped, inadvertently corrupted or maliciously
crafted byte-codes might be able to take advantage of implementation
weaknesses in a Java interpreter.