Core Security Patterns Weblog
Practical security facts and fun….off the record
1
Way cool ! HTTP Session Hijacking can’t be made simpler than using Firesheep. Couple of days ago, a friend of mine suggested me to login a most popular website and he demonstrated how he took control and accessed my user session in less than a minute. First, I thought he used a network protocol analyser tool such as Wireshark or sniffer to access my session information…but I was a bit surprised to see he used a simple and user friendly Firefox plugin (Firesheep) to steal and access my session information. Believe it or not – in an unsecured network, Firesheep can easily capture active user session information exchanged with a Website that uses clear-text/unencrypted HTTP communication and session ID cookies irrespective of their underlying Operating System and user’s Browser. Ofcourse sending and receiving clear-text over HTTP has always posed a huge risk and compromising the session cookie allows impersonation….. interestingly majority of us don’t care much till we become a victim of a data loss ! Even the many popular social network websites still uses clear-text over HTTP.
With my first experience, Firesheep worked well on my Mac… capturing my Facebook and WordPress sessions running on a PC… so quick ! Not just Facebook sessions – if you are using an unsecured/clear network and accessing any unsecured web site (without SSL), Firesheep can act as a “Man-in-the-Middle” attacker who can comfortably capture, hijack and obtain unauthorized access to the currently active user’s HTTP session. Unfortunately, there is no silver bullet to thwart these attacks unless you are aware and avoid the risks of using unsecured networks and clear-text communication.
Thwarting Firesheep !
If you are concerned about Firesheep attacks on the client side (user’s browser) then make sure to use a Secured VPN or Secure Shell (SSH) or IPSec or Encrypted WiFi (ex.WPA2) connection for accessing unsecured web applications. In case of accessing from unsecured networks, you may use Blacksheep tool which helps to find out whether your user session is currently being captured by a rogue Firesheep user on the network. In case of accessing Facebook, you may consider using HTTPS Everywhere a firefox extension that allows to rewrite Facebook requests and other HTTPS supported Websites.
On the server-side, if you are curious about securing your web application and user sessions from prying eyes….here is some best practices that can help thwarting similar session hijacking attacks:
- Use SSL/TLS communication to ensure encrypted transport between the user’s client and Web server.
- Use encrypted session cookies and use encrypt/decryption mechanisms for setting and getting of cookie data.
- Enable Hostname/IP address verification for all critical requests, identify and compare the current user’s host with the originating user’s host in the user’s session cookie.
If you are concerned about SSL/TLS overheads and looking for high-performance SSL/TLS acceleration solutions then refer to my previous entries..that would able to help you.
Goodluck.
In a typical Single Sign-On (SSO)/Federation scenario using SAML, the Service Provider (SP) initiates the user authentication request using SAML AuthnRequest assertion with an Identity Provider (IDP). The IDP authenticates the principal and returns a SAML AuthnStatement assertion response confirming the user authentication. If the user is successfully authenticated, the SP is required to have the subject’s profile attributes of the authenticated principal for making local authorization decisions. To obtain the subject’s profile attributes (ex. organization, email, role), the SP initiates a SAML AttributeQuery request with the target IDP. The IDP returns a response SAML AttributeStatement assertion listing the name of the attributes and the associated values. Using the subject’s profile attributes, the SP can perform authorization operations.
Ofcourse, it looks simple…here is the complexity – Last two weeks I spent on building a Proof-of-Concept that conforms to HSPD-12 Back-end Attribute Exchange specifications and SAMLv2 Attribute Sharing Profile for X.509 Authentication based systems (Both specifications are mandated as part of Federal Identity, Credential and Access Management (ICAM) initiative of Federal CIO Council). I had been experimenting with an Identity Federation scenario that makes use of Smartcard/PKI credentials – Card Authentication Key (CAK)/X.509 Certificate on a PIV card authenticates a PKI provider (using OCSP) and then using its X.509 credential attributes (Subject DN) for looking up off-card user attributes from an IDP (that acts as an Attribute Authority). The IDP provides the user profile attribute information to the requesting SP. In simpler terms, the SP initiated X.509 authentication directly via OCSP request/response with a Certificate Validation Authority (VA) of a Certificate Authority (CA). Upon successful authentication, the SP initiates a SAML AttributeQuery to the IDP (which acts as an Attribute Authority), the SAML AttributeQuery uses the SubjectDN of the authenticated principal from the X.509 certificate and requests the IDP to provide the subject’s user profile attributes.
Using Fedlet for SAML X.509 Authentication based Attribute Sharing
SAML Attribute Exchange for X.509 based Authentication
Fedlet is a lightweight SAMLv2 based Service Provider (SP) implementation (currently part of Sun OpenSSO 8.x and sooner to be available in Oracle Identity Federation) for enabling SAMLv2 based Single Sign-On environment. In simpler terms, Fedlet allows an Identity Provider (IDP) to enable an SP that need not have federation implemented. The SP plugs in the Fedlet to a Java/.NET web application and then ready to initiate SAML v2 based SSO authentication, authorization and attribute exchanges. A Fedlet installed and configured with a SP can set up to use multiple IDPs where select IDPs can acts as Attribute Authorities. In this case, the Fedlet need to update its configuration with the IDP Metadata configuration (such as entity ID, IDP Meta Alias, Attribute Authority Meta Alias – same as IDP ). In addition, the Fedlets are capable of performing XML signature verification and decryption of responses from the IDP must identify the alias of signing and encryption certificates.
Here is the quick documentation, which I referred for putting together the solution using Fedlets for SAMLv2 Attribute Sharing for X.509 based authentication scenarios. In case, if you want your Service Provider to use OpenSSO for PIV/CAC based certificate authentication, you may refer to my earlier entry on Smartcard/PKI authentication based SSO (Using OpenSSO). Besides that you should be good to test-drive your excercise. Ofcourse, you can use Fedlets for Microsoft .NET service providers but it was’nt in my scope of work !
In case of SP requiring to fetch multiple user profile attributes you may also choose to use SPML based queries (SPML Lookup/Update/Batch Request/Response) to an Identity Manager (acting as Attribute Authority) – assuming it facilitates an SPML implementation). If you are looking for a solution that requires user profile attributes after a single-user X.509 authentication, then SAML Attribute query should help fetching a single user profile of an authenticated principal !
Life goes on… as everyone know by now, EU approved the Oracle’s Sun acquisition deal.
After my 10+ years long saga ending at Sun…..now I am pushed into Oracle (Sun + Oracle). It looks like I will be doing the same job….as always I continue my passion towards security and identity technologies… especially on Solaris and Sun systems (oops…Oracle servers)… maybe a bit more on Oracle software stack.
Sun Memorial by James Gosling
With increasing incidents of online frauds through username/password compromises and stolen/forged identity credentials - Strong authentication using multi-factor credentials is often considered as a defensive solution for ensuring high-degree of identity assurance to accessing Web applications. Adopting multi-factor credentials based authentication has also become a most common security requirement for enabling access control to critical online banking transactions and to safeguard online customer information (Mandated by FFIEC authentication guidelines). One-time Passwords using Tokens, USB dongles, Java Smartcards/SIM cards, Mobile Phones and other specialized devices has become the most simplest and effective option that can be easily adopted as the “second-factor credential (Something I have)” for strong authentication solution. Although…and there is a myriad ways to create one-time passwords, the overwhelming developer issue is to make it to work by readily integrating it with existing applications and further enabling them for use in Web SSO and Federation scenarios.
One-time Password (OTP) Authentication using OpenSSO
The One-time password (OTP) is commonly generated on a physical device such as a token and is entered by the user at the time of authentication, once used it cannot be reused which renders it useless to anyone that may have intercepted it during the authentication process.
Sun OpenSSO Enterprise 8.x offers a ready-to-use OTP based authentication module that allows to deliver One-time passwords via SMS (on Mobile phones) and Personal email or combination of both. OpenSSO implements Hashed Message Authentication Code (HMAC) based One-time password (HOTP) algorithm as defined in RFC 4226 - an IETF – OATH (Open Authentication) joint initiative. The HOTP is based on HMAC-SHA-1 algorithm - using an increasing 8-bit counter value and a static symmetric key that is known to the HOTP generator and validation service. In a typical OpenSSO deployment, the HOTP authentication module is configured to work as part of an authentication chain that includes a first-factor authentication (ex. Username/Password authentication with LDAP, Datastore). This means that atleast one of the existing authentication must be performed successful before commencing HOTP authentication.
Try it yourself
To deploy OTP for Web SSO authentication, all you would need is to have OpenSSO Enterprise 8.x and configured up and running…. and then follow these steps:
- Login to OpenSSO Administrator console, select the “Access Control” tab, select your default “Realm”, select “Authentication”. Click on “Module Instances” and click on “New” to create a Module instance. Assign a name to the module instance (ex. HOTP) and select “HOTP” as type.
- Configure the HOTP authentication module properties. You need to identify the values for Authentication Level, SMTP Server (Access credentials including host name, port, username, password), One-time password validity length (Maximun validity time valid since creation and before OTP expires), One-time Password length (6 or 8 digits), One-time Password Delivery (“SMS” or “Email” or “Both” to receive SMS and Email).
-
Configuring HOTP Authentication Module Properties
-
- Configure an Authentication Chain that includes HOTP authentication module with any other authentication module (ex. Datastore, LDAP). You may note HOTP authentication cannot act as primary authentication since it HOTP authentication does not identify the user profile, so it must be combined with an authentication module that identifies the calling user identity. To create an authentication chain… goto the OpenSSO administrator console, select “Access Control”, Goto “Authentication Chaining”, click on “New”, assign a name to the authentication chain (ex. Two-factor”) and the choose “HOTP” module instance and select “Required”.
-
Configuring the Two-factor authentication chain including HOTP
-
- Now the OpenSSO One-time Authentication Module is ready for use as par of “Two-factor” authentication chain.
- Create an User Profile that identifies the user’s “Telephone Number” attribute with the Mobile Phone Number appended with the SMS Gateway domain.
- For example:
- AT&T (USA) : YourPhoneNumber@txt.att.net (178199931234@txt.att.net)
- SprintPCS : YourPhoneNumber@messaging.sprintpcs.com
- T-Mobile : YourPhoneNumber@tmomail.net
- Virgin Mobile: YourPhoneNumber@vmobl.com
- Verizon: YourPhoneNumber@vtext.com
- Metro PCS: YourPhoneNumber@MyMetroPcs.com
- For a complete list of Email to SMS Gateways refer to: http://www.mutube.com/projects/open-email-to-sms/gateway-list/
- For example:
- Test drive the configured One-time Password based SSO authentication, by accessing the URL of the configured “Two-factor” authentication chain as follows:
- As a result, you will be prompted to perform username/password authentication and then followed by HOTP. To deliver One-Time Password, click “Request OTP Code”, the One-time password will be delivered to your Mobile via SMS and also via email (provided in your User profile).
-
One-time Password based SSO
- As verified using my Blackberry…the OTP showed up as follows:
-
Adopting to One-time Pasword based authentication credentials certainly helps to defend against many illegitimate access using compromised user credentials such as Passwords, PIN and Digital certificates. Using OpenSSO based OTP authentication is just a no-brainer… try it for yourselves, I am sure you will enjoy !
When it comes to application security, Secure coding is the first line of defense….and it is very critical to follow the best practice patterns and avoid pitfalls to secure the application from known risks and vulnerabities. The Java Security team has just released the updated – “Secure Coding Guidelines for the Java Programming Language, Version 3.0“ . Certainly it included a newer set of fundamentals and enhanced set of secure coding guidelines.
A must have URL for your quick reference…if you are a security conscious developer !
Java EE 6 RI was released few weeks ago….I am bit late to have my first look Without a doubt, the new Web container security enhancements are very compelling for any budding or experienced Java developer working on Web applications. The Java EE 6 has unveiled several new security features with ease of use and targetted for simplified Web application security deployments. Based on Servlet 3.0 specification, the Java EE 6 Web applications can take advantage of an enriched set of programmatic and declarative security features and Security annotations previously available to EJB 3.x applications. Also, the deployed Web applications/Web Services can use JSR-196 based pluggable authentication/authorization modules (based on SOAP Web Services) that can be configured as part of the Servlet container.
Java EE 6 : Programmatic Security for Web Applications
The newly introduced Java EE 6 programmatic security features for Web applications are represented by the following methods of HttpServletRequest interface:
1. authenticate()
- This method helps to initiate authentication of the calling user by launching an authentication dialog for acquiring username/password and perform BASIC authentication by the container within an unconstrained request context.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class MyAuthServlet extends HttpServlet {
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(“text/html;charset=UTF-8″);
PrintWriter out = response.getWriter();
try {
//Launch the BASIC authentication dialog
request.authenticate(response);
out.println(“Authenticate Successful”);
} finally {
out.close();
}
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}
}
2. login() and logout ()
- The login() method allows to programmatically collect with the provided username/password credentials (as an alternative to FORM-based authentication) and perform user authentication.
- The logout() method performs logging out the user and resets the context.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class MySecurityServlet extends HttpServlet {
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(“text/html;charset=UTF-8″);
PrintWriter out = response.getWriter();
try {
String myUsername = request.getParameter(“UserName”);
String myPassword = request.getParameter(“Password”);
try {
request.login(myUsername, myPassword);
} catch(ServletException ex) {
out.println(“Login Failed” + ex.getMessage());
return;
}
} catch (Exception e) {
throw new ServletException(e);
} finally {
request.logout();
out.close();
}
}
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}
}
The above code assumes the authentication is configured to BASIC by setting the login-config element in web.xml. If the authentication is the successful, the Web application can take advantage of the following methods in the HttpServletRequest interface to identify the remote user, role attributes and to perform business logic decisions.
3. getRemoteUser()
- Determines the authenticate username of the remote user associated with the request. If no authentication occured, it will return a null value.
4. IsUserInRole(..rolename..)
- Determines whether the authenticated user is in a specified security role. If the user is not authenticated, it returns false.
5. getUserPrincipal()
- Determines the principal name that represents the authenticated user entity (name of the remote user) and returns a java.security.Principal object corresponding to the user.
Here is my sample code that I tested it on Glassfish v3 (Developer Sample):
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.annotation.WebServlet;
import javax.annotation.security.DeclareRoles;
//Annotation for defining the Servlet name and its URL pattern
@WebServlet(name=”MySecurityServlet”, urlPatterns={“/MySecurityServlet”})
// Annotation for declaring roles
@DeclareRoles(“securityguy”)
public class MySecurityServlet extends HttpServlet {
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(“text/html;charset=UTF-8″);
PrintWriter out = response.getWriter();
try {
String myUsername = request.getParameter(“UserName”);
String myPassword = request.getParameter(“Password”);
try {
request.login(myUsername, myPassword);
} catch(ServletException ex) {
out.println(“Login Failed” + ex.getMessage());
return;
}
out.println(“The authenticated user is in Role: ” + request.isUserInRole(“securityguy”));
out.println(“The authenticated remote username: ” + request.getRemoteUser());
out.println(“The authenticated Principal name: ” + request.getUserPrincipal());
out.println(“The authentication type: ” + request.getAuthType());
} catch (Exception e) {
throw new ServletException(e);
} finally {
request.logout();
out.close();
}
}
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}
}
To test the code, it is assumed that you have the Java EE runtime deployment descriptor include the appropriate role mapping that associated the user with the specified role-name.
Security Annotations for the Web Applications
With Servlet 3.0 implementation, we would able to use standard Java annotations for declaring security constraints as equivalent to those defined in a standard Web deployment descriptor (web.xml). With Security annotation you should able to define roles, access control to HTTP methods, transport-layer protection (for enforcing SSL/TLS). To make use of security annotations in Servlets, Servlet 3.0 has introduced @ServletSecurity annotation to support defining security constraints.
Using @ServletSecurity
The @ServletSecurity annotation allows to define the security constraints as its fields:
- @HttpConstraint – Used as a field of @ServletSecurity to specify roles to all methods and ensure transport-layer security)
- ex. @ServletSecurity(@HttpConstraint(rolesAllowed={“customer”})) - Ensures all HTTP methods (GET, POST, TRACE) are protected and access is allowed to security role “customer”.
- ex. @ServletSecurity(@HttpConstraint(transportGuarantee=ServletSecurity.TransportGuarantee.CONFIDENTIAL)) – Ensures all methods require SSL transport
- @HttpMethodConstraint (Applied to define methods ex. GET, POST, TRACE)
- ex. ServletSecurity(value=@HttpConstraint(httpMethodConstraints={ @HttpMethodConstraint(value=”POST”, transportGuarantee=ServletSecurity.TransportGuarantee.NONE, rolesAllowed={“customer”}) }) – Ensures only authenticated users with security role is allowed to access HTTP POST method and transport-layer security/SSL is supported but not required.
- @DeclareRoles (Allows to define security roles)
- @RoleAllowed (Allows to define authorized roles)
Here is a quick usage scenario of @ServletSecurity annotation (Developer Sample):
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.annotation.security.*;
@DeclareRoles("customer","guest")
@ServletSecurity(@HttpConstraint(rolesAllowed={"customer"}))
public class MyHelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println("Hello World");
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("Hello World");
out.close();
}
}
Sometimes, it’s the small things that make even complex things much easier. Way to go…Java EE 6 !
Here is couple of references, you may consider to explore Java EE 6:
Glassfish v3/Java EE 6 Sample Applications
Enjoy
Absolutely…Security cannot be an afterthought when it comes to hosting on Cloud.
Back to top