Disallowing pointer arithmetic
Checking ArrayBounds at runtime
Verifying bytecodes during classloading.
Verifying bytecodes and access during first method call.
Access Control of packages.
Virtual Machine level: The notion is whether or not to allow/grant a code access/execute to JVM.
J2SE uses Java Policy based access control, policy file found in JAVA_HOME/lib/security or $HOME/.java.policy. For default applications there is no policy involved. But policy and the corresponding SecurityManager comes in picture for applets, classes downloaded from URL's. We can specify the policy in the policy file. This is a code based policy, meaning code downloaded from so and so location can execute or not. In summary, it controls 'WHAT' executes on the JVM.
Applets: Applets running in browsers are by default restricted to access only the host from which they are downloaded to avoid malicious applets trying to spy on ports inside a firewall or sending emails etc..
Applets(browsers) cannot access files on the users computer. Applets cannot read any system properties or can they start a new window. The dialogs from applets have a warning message saying that this is an applet, to save users from some spoofing login prompt dialogs
Signed Applets (CABS for IE) provide a way of releasing restrictions to an extent. They usually prompt the user for permission.
Application Level:
JAAS has 2 parts Authentication and authorization.
JAAS
Authentication: A subject can be either a single user or a group of users or a service.Principal is like a name and credential is like a password. Subjects have principals and credentials. Authenication involves autheticating subjects for a service by verifying provided credentials.
JAAS supports PAM (Pluggable Authentication Model). Authenication modules can be plugged transparently.
JAAS uses Java GSS-API for Single-SignOn. Java GSS-API uses Kerberos. Java-GSS uses Credentials as the cache for Kerberos TGT.
Concepts of interest: Principals, Subjects, Credentials, LoginContext, LoginModule.
Authorization: JAAS authorization is analogous to Java policy based access control, and extends the code based access control to include user based access control (controls WHO executes). Authorization is by default not enabled for applications. We can enable it by specifying on the command line during jvm startup to use the securityManager (-D java.security.Manager).Once enabled, the policy file needs to be edited to allow access to code, users for properties, resources (network, files).
Authentication:
LoginContext provides the abstraction from the underlying login modules for the application. LoginContext is the gateway for authentication. Login Modules can be specified in a configuration file and the name of the configuration file needs to be provided during the JVM start up (-Djava.security.auth.login.config==example.conf ).
LoginContext reads the login configuration and uses the specified login modules.
LoginModules are created with a CallBackHandler, that supports different callbacks. The callBack handler has a overloaded execute method that accepts array of different callback types, and we can handle the required callback type.
CallbackHandler fills the principal name, password etc in the correspondig callback object and returns. The login module uses those details to authenticate.
If all LoginModules successfully authenticate the Principal, the principal is added to the subject. and authentication is successful or authentication fails.
If authentication is succesful, then the subject can call the privileged action, an action that implements the privileged interface(basically should have a run() method) using doAs methods of Subject.
Message Digest: It is similar to CRC, a fixed size value computed from the message. This is used to ensure that message is arrived without tampering. But to avoid spoofing the message and message digest both, message digest can be encrypted(using the public key of sender).
Public key of the sender is known to the receiver, hence receiver can compute the message digest and encrypt using public key of sender and compare the encrypted message digests.
If the message needs to be encrypted as well, both message and encrypted message digest are encrypted using receivers public key, which will be decrypted at the receiver using receivers private key.
pk: public key, prk: private key, m:msg, md:message digest, s:sender, r:receiver
At sender:
- md1 = messageDigest(m);// compute Message digest
- e_md1 = pks(md1); // encryption step 1
- M = m+ e_md1; // Full message
- e_M = pkr(M): // encryption step 2
At receiver
- M = m + e_md1 = decrypt_prkr(e_M);
- md2 = messageDigest(m);
- e_md2 = pks(md2);
- e_md2 == e_md1
JSSE provides SSL and certificate store support. Use keytool to generate certificates. Use the same tool to import certificates into $JAVA_HOME/lib/secuirty/jssecerts . Certificate store contains certificates and trust store contains trusted certificates of clients. The name of a certificate can be referenced using an alias.
SSL Handshake involves Hello Protocol comprising of negotiating the cipher suites, and exchanging public keys etc...
A secure webserver request is forwarded to port 443. A resource configured in web.xml as "CONFIDENTIAL" will have to be requested using https. A http request for such a resource will be redirected to https. If the webserver cannot use port 443 and uses some other port then use iptables command on linux server to redirect requests on 443 port to the other actual port.
web server security.
Three web server security mechanisms: Basic, digest and HTTPS client authentication. Basic uses well known base 64 encoding; so no good. Digest is improvement over Base64. But not popular though. In a response to the protected resource request, web server sends, timestamp, url, etc and client uses MD5 to compute message digest. Anyway, in HTTPS client authentication web clients send their certificate when they connect the server, and server maintains client credentials till the connection is closed.
Servlet containers have to support 'Form based' authentication. This is similar to Basic, but allows a custom login page. To enhance security this can be combined with SSL.
J2EE security is based on roles and not users or groups. Users and groups can be configured outside either in database or standard xml file (server specific) and mapped to different roles.
Personalization of web pages can be achieved one possible way by checking roles using isUserInRole() method. Other than that both web server resources and ejb's should better be secured declaratively using web.xml and ejb deployment descriptors.
No comments:
Post a Comment