Security

A secure system is one that retains its functional and non-functional qualities, even while being attacked by malicious parties. The non-functional qualities include service-level architectural requirements, such as performance, available, and reliability. A secure system also protects against accidental damage.

Security Threats

Threats can be broadly grouped into three categories:

  • Attacks on secrecy: Parties attempt to read confidential information that they are not entitled to.
  • Attacks on integrity: Parties attempt to make systems changes when they should not be able to.
  • Attacks on availability: Parties attempt to disrupt normal operations, limiting performance and availability.

Specific threats include:

Threat Response
Input validation failures Validate input on both the client and server.
SQL injection Filter inputs for SQL. Use parameterized PreparedStatements.
Cross site scripting Filter inputs for HTML meta characters. Escape web output for HTML characters.
Cross site request forgery Limit login session times. Forms that alter data should use the POST method rather than GET. Implement synchronizer token on all forms. Use the double-submitted cookie pattern.
Insecure data transit and storage Use strong encryption on transit. Manage physical security. Establish a security perimeter.
Weak passwords and security tokens Establish standards on passwords and tokens. Use two factors for authentication.
Session theft Make session tokens hard to guess.
Man-in-the-Middle attacks Require client and server certificates.

For any given system, it is possible to write a Threat Model describing the vulnerabilities an the possible attacks against it. One template for constructing threat models uses the mnemonic STRIDE. Threat categories include:

  • Spoofing of user identity
  • Tampering of data or software
  • Repudiation. Taking action but then denying it.
  • Information disclosure
  • Denial of Service
  • Elevation of privilege

Java Security Concepts

A permission is the right to perform some action on some resource. In Java, a permission is represented by an object extending from the java.security.permission class.

A subject represents an entity who is taking actions and obtaining information. A principal is a subject who has been authenticated. A login or an individual can be a principal. Permissions are granted to a principal. In Java, these concepts are wrapped into the the javax.security.auth.Subject and java.security.Principal. Principal objects will typically encapsulate a user ID and a password.

A protection domain is a convenient mechanism for grouping and isolation between units of protection. A domain is a collection of resources encapsulating data and process. It is possible to separate protection domains from interacting with each other so that any permitted interaction must be either through trusted system code or explicitly allowed by the domains concerned. In Java, a java.security.ProtectionDomain encloses a set of classes whose instances are granted the same set of permissions. Classes within a protection domain have full access to other classes in that domain.

Domains typically fall into two categories: system domains and application domains. It is often necessary to restrict access to certain system resources so they can only be accessed from system domains.

As a principal performs work, its current set of active permissions is the intersection of its original set and all the permission sets of its current execution stack. In Java, a java.security.Policy object does the work of determining whether code executing in the Java runtime environment has permission to perform a security-sensitive operation.

There is only one Policy installed at a time. Application code can install a new Policy. If no Policy is provided, a default Policy will be constructed based on the $HOME/.java.policy file or the $JRE_HOME/lib/security/java.policy file.

During execution of a Java program, much of the security policy is implemented by the SecurityManager object. Only one SecurityManager can be installed in the System at a time. Once a SecurityManager is set into the System, it can never be changed. Setting the SecurityManager is optional. If a default SecurityManager is requested, it is constructed based on the $JRE_HOME/lib/security/java.security file.

The SecurityManager concept was introduced with Java 1.0. In newer versions of Java, most of the work is delegated to the AccessController object, but the SecurityManager is still the focal point.

Java Client Security

Security can be implemented in every tier and at each layer. Client security can be implemented for applications and applets.

Low level security mechanisms

When classes are being loaded into the JVM, the ClassLoader can check the permissions to load and the integrity of the classes. Security checks can be programmaticaly implemented in the ClassLoader code, or can be decoratively specified by the SecurityManager.

As classes are loaded, they may be subject to byte code verification, which checks that the class bytes are generally in a valid format, and then applies a simple theorem prover that verifies that the class follows certain rules.

  • it doesn't forge pointers.
  • it doesn't violate access restrictions.
  • it accesses objects as what they are (for example, InputStream objects are always used as InputStreams and never as anything else).
  • the types of the parameters of all bytecode instructions are known to always be correct.

Most of these checks are already performed by the Java compiler, but the verifier protects against an attacker has not subverted the compiler checks.

Note that the byte code verifier is optional. You must specify the -verify command line option to turn it on.

J2SE comes with tools for key management, digital signing and SSL communication. The default location for a user's keystore is in $HOME/.keystore. There will also be a system-wide keystore holding certificate authorities at $JAVA_HOME//lib/ext/cacerts. There is a command line keystore tool for managing the keys in any keystore.

Applet Security

By default, applets are run in a "security sandbox" where potential damage is limited. This is accomplished by the browser installing a SecurityManager. The default applet SecurityManager allows the applet to:

  • Read most of the basic System properties. Applets can see JVM type and version, operating system type and version, and path/line separators. Applets are specifically restricted from seeing classpath, file paths, or user name.
  • Make network connections back to the remote host from which it was downloaded
  • Download files and libraries from its remote host

By default, applets cannot:

  • Read or write local files
  • See some of the System properties
  • Start any process on the client machine
  • Access local system resources.

Applets get around these security restrictions if they are loaded from the client's filesystem or if they have been digitally signed. Local or signed applets are considered "trusted".

Java Application Security

Java applications are often run with no SecurityManager. A SecurityManager can be created by the application code, or it can be specified on the command line. You can name a specific SecurityManager class, or get a default one.

java -Djava.security.manager=custom.manager.class MyApplication
java -Djava.security.manager  MyApplication
Web Start Security

By default, untrusted Java Web Start applications execute in a sandbox defined by a SecurityManager. The Web Start sandbox is more flexible than for applets. A Web Start application can:

  • Use the network to access the host from which it was downloaded.
  • With the user's permission, use the local printer.
  • Persist session data.
  • Use JNLP APIs to access the local file system.
    Also, untrusted applications can use these APIs to access the clipboard.

Trusted Web Start applications can skip the user dialogs if they are digitally signed. The JNLP file can specify one of two security levels:

  • all-permissions : Application gets full access to local file system and network.
  • j2ee-application-client-permissions : Application gets access to resources that have been defined for J2EE applications.

JEE Security

Architecture diagram and where to put security

Declarative Security

In a declarative security model, the application security is expressed using rules and permissions in a declarative syntax specific to the J2EE application environment.

In web applications, security restrictions can be defined in the deployment descriptor file. EJB applications can declare security in deployment descriptors or using annotations. Some of these annotations may become available to servlets with the Servlet 3.0 specification.

annotation target description
@DeclareRoles class Declare what roles might be used within an EJB
@RolesAllowed method Declare what caller roles can access a method or a whole class
@PermitAll method Allow anyone to call a method
@DenyAll method Deny access to everyone
@RunAs method Change the role of callers

Programmatic Security

In a programmatic security model, Java code makes security decisions based on the invoked business methods to determine whether the caller has been granted a privilege to access or deny a resource.

Web applications can retrieve the user's principal or test for user roles using the HttpServletRequest. EJB applications can get the same services from the EJBContext object.

Authentication and Authorization: JAAS

The Java Authentication and Authorization Service (JAAS) provides API mechanisms and services for enabling authentication and authorization in Java-based application solutions.  JAAS has been built into J2SE since version 1.4.

A secured application will have configured one or more LoginModules, as well as defining ProtectionDomains, Permissions, and Subjects with Principals

To use JAAS, a programmer first creates a LoginContext object and calls its login() method, which attempts to log in on all configured LoginModules.  A Subject can then be retrieved from the LoginContext with a list of Principals.   The programmer can then attempt to do PrivilegedActions as the given Subject.

Single Sign-on

Single sign-on is an authentication solution allowing multiple applications to share the same user sign-on information. Signing onto one application gives authentication and authorization on other applications. Logging off one application logs off all others.

Security Assertion Markup Language (SAML) is an XML based framework for exchanging security information about subjects. SAML is a protocol for representing authentication and authorization assertions and is used for single sign-on and global logout.

The Single Sign-on Delegator pattern encapsulates access to identity management and single sign-on functionalities, allowing independent evolution of loosely coupled identity management services while providing system availability.

Cryptography

The Java Cryptographic Architecture (JCA) provide general utilities for digital signatures, message digests , certificates and certificate validation, encryption , key generation and management, and secure random number generation.

Prior to JDK 1.4, the Java Cryptographic Extension (JCE) was an unbundled product, and as such, the JCA and JCE were regularly referred to as separate, distinct components. As JCE is now bundled in the JDK, the distinction is becoming less apparent. Since the JCE uses the same architecture as the JCA, the JCE should be more properly thought of as a part of the JCA.

The Java Secure Socket Extension (JSSE) enables end-to-end communication security for Java applications by providing a standardized API framework and mechanisms for client/server communications. JSSE provides support for SSL and TLS protocols and includes functionalities related to data encryption, message integrity and peer authentication.


Sub