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.
I’ve spent the last few days attending Oracle OpenWorld conference at San Francisco..it is my second OOW experience, so it is not a surprise to see the conference was fully packed with people, hundreds of sessions and demos – I did have an opportunity to attend few and also present two sessions focused on Security topics featuring “Hardware Assisted Security Solution for SOA, XML Web Services and Java EE applications” – showcasing how “Hardware and Software Engineered together”.
During the conference, John Fowler – Oracle EVP, Systems announced the industry’s first 16 core processor introducing new SPARC T3 systems with integrated security and virtualization capabilities. Each SPARC T3 processor features 16 on-chip cryptographic accelerators that deliver cryptographic operations running in parallel at CPU speeds and offloading compute-intensive cryptographic functions from software – thus eliminating the need for additional special-purpose cryptographic accelerators such as PCIe cards or network appliances. The cryptographic operation offload and acceleration is accomplished using dedicated cryptographic accelerator drivers, called the Niagara Crypto Provider (NCP), Niagara 2 Crypto Provider (N2CP) and Niagara 2 Random Number Generator (N2RNG). In practice, the NCP and N2CP accelerators uses the Oracle Solaris Cryptographic Framework for enabling user-level applications to off-load cryptographic operations via PKCS#11 standard interfaces and take advantage of NCP and N2CP based on-chip cryptographic acceleration. The current UltraSPARC T3 processors provide acceleration support for public-key encryption mechanisms including RSA, DSA, DH and ECC algorithms, symmetric key-based encryption amechanisms including DES, 3DES, AES and Kasumi algorthms and Message disgest/hashing mechanisms MD5, SHA1, SHA-256 and SHA-512 algorithms. The Solaris Cryptographic Framework (SCF) library plays a vital role for providing applications access to NCP and N2CP accelerators through a set of cryptographic services for kernel-level and user-level consumers. Using PKCS#11 interfaces of Solaris Cryptographic Framework, SOA and Java EE Applications (ex. Oracle Fusion Middleware, WebLogic, Glassfish, JBoss, Websphere) can take advantage of NCP and N2CP based cryptography acceleration (Refer figure).
Hardware Assisted Cryptographic Acceleration using Solaris on UltraSPARC T3 Servers
Cryptographic Acceleration for SOA and Java EE Security
Both SOA/XML Web services and Java EE based applications can significantly gain on security performance by offloading and delegating their cryptographic operations to the on-chip cryptographic accelerators of Oracle SPARC Enterprise T-Series servers.
Applied Security Mechanisms and Usage Scenarios
To enhance security performance, both the Oracle WebLogic server and Oracle WSM secured applications can offload select cryptographic operations to address the following security scenarios.
- Transport-layer Security
- SSL/TLS acceleration offloads computationally intensive public-key cryptographic operations such as RSA, DH and ECC.
- RMI over IIOP with SSL uses SSL/TLS to protect IIOP connections to RMI remote objects.
- Message-Layer Security
- Acceleration of cryptographic operations intended for supporting XML Web Services security standards such as WS-Security, WS-SecurityPolicy. XML Web services security relies on public-key encryption, digital signature (ex. RSA, DSA), bulk encryption (ex. AES, 3DES,DES) and message digest (ex. SHA-1, SHA-2, MD5) functions intended for supporting XML encryption, XML digital signature and related cryptographic operations.
Performance Characteristics
Based on a performance study, Oracle’s SPARC Enterprise T3-1 server was used to evaluate both SSL and WS-Security application performance of a SOA/XML Web Services application deployed on Oracle Fusion Middleware (WebLogic 10.3.3 and Oracle Web Services Manager).
- Enabling on-chip acceleration for SSL (Cipher suite using RSA-1024/AES-256) and WS-Security (Algorithm suite using Basic256Rsa15) usecases solidly delivered between 2X – 3X overall application throughput performance gain in comparison with SSL and WS-Security usecases running with no acceleration.
- Using Oracle Solaris KSSL as an SSL proxy provided an additional performance gain of about 25-30% outperforming WebLogic server SSL configured using Java SunPKCS11 provider for enabling cryptographic acceleration.
Now, you got the highlights, if you are ready to dig deeper on the details and test-drive the solution – Please download and read the following two whitepapers (available from Oracle Technology network) that explores the above solution from ground up.
- High Performance Security for Oracle Weblogic Applications Using Oracle SPARC Enterprise T-Series Servers (external pdf)
- High Performance Security for SOA and XML Web Services Manager and Oracle SPARC Enterprise T-Series Servers (external pdf)
If you are curious to see the OOW presentation – It is right here.
Thanks to Vikas Jain, Nitin Handa and Chad Prucha for all the help and support on this effort.
Don’t forget to let me know, if you had any comments and suggestions.
When it comes to Java cryptography based application security – Solaris has significant performance advantage over Linux and Windows on Intel Westmere processor equipped servers. I am not debunking Linux performance on Intel but evidently Linux does not take advantage of Intel Westmere’s AES-NI instructions when the Java applications relies on Java cryptographic implementations for performing AES encryption/decryption functions. AES is one of the most popular symmetric-key encryption algorithm widely used in security transaction protocols (SSL/TLS, IPSEC), Disk encryption, Database encryption, XML Web Services security standards (WS-Security) and so forth. If you are a Java security enthusiast or a developer who is curious about Intel Westmere and Java security – here is some observations:
Intel introduced the new 32nm Westmere processors family (Xeon processor 5600 series) that incorporates instructions for AES algorithm (AES-NI) to faster cryptographic applications that uses AES – a symmetric-key encryption standard. AES is a block cipher, with a fixed block size of 128 bits that encrypts and decrypts data using multiple rounds where the number of rounds (10, 12, or 14) depends on the keysize (128, 192 or 256 bits). The Intel’s AES-NI implementation consists of seven new instructions for AES algorithm - AESENC, AESENCLAST, AESDEC, AESDECLAST, CLMUL, AESIMC, and AESKEYGENASSIST to support performing computations for 10 (128 Bit), 12 (192 Bit), and 14 (256 Bit) rounds and most operational modes including ECB, CBC and CTR. AES-NI accelerates AES based encryption/decryption operations in the CPU by offloading them from the software and eliminates its time spent in AES encryption/decryption functions. This means applications relying on AES algorithm can delegate its AES encryption/decryption functions to Intel’s AES-NI. To enable applications make use of Intel AES-NI, it is critical that the applications must be recompiled to use Intel’s Integrated Performance Primitives (Intel IPP) library that contains functions and optimizations for achieving AES performance using AES-NI on Intel Westmere processors. Assuming the applications are recompiled and optimized to include Intel’s IPP library – applications can benefit from AES-NI features of Intel Westmere.
Intel Westmere - AES-NI (Source: pcsstats.com)
Java Security: The Solaris Advantage
With the release of Solaris 10 Update 8 and above, Solaris 10 introduced support for Intel AES-NI through integration with Solaris Cryptographic Framework (SCF). As Solaris Cryptographic Framework acts as the intermediary for cryptographic operations, all applications relying on Solaris based PKCS#11 provider APIs, CLIs and Solaris kernel modules will automatically take advantage of AES-NI instructions for AES encryption and decryption. More importantly, with AES-NI integration - Java SE/Java EE applications using JDK’s SunPKCS11 provider for supporting Java Cryptographic Extensions (JCE) and Java Secure Socket Extensions (JSSE), applications using OpenSSL with Solaris PKCS11 and Mozilla NSS with Solaris PKCS11 automatically use Intel AES-NI accelerating AES encryption/decryption operations on Solaris.
By default on Solaris, the Sun JDK and its JCE provider environment uses a Sun PKCS#11 implementation (SunPKCS11) that allows Java applications to access Solaris managed software/hardware cryptographic services. The SunPKCS11 provider is a Java based PKCS#11 implementation that integrates with underlying Solaris PKCS#11 implementations provided by the SCF and its exposed cryptographic providers (ex. Intel AES-NI). In a typical JDK installation on Solaris, the Java runtime environment is pre-configured to make use of the SunPKCS11 provider. To verify this refer to the Java security properties file located at $JAVA_HOME/jre/lib/security/java.security properties file and make sure it identifies SunPKCS11 as the default provider.
security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/sunpkcs11solaris.cfg
The $JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfg file contains the configuration information used by the SunPKCS11 provider for accessing the SCF. To leverage AES-NI acceleration, it is important to enable and enforce delegation of the required cryptographic mechanisms to the underlying Solaris PKCS#11 provider that facilitates the AES-NI acceleration support. Make sure to include the required AES mechanisms (ex. CKM_AES) in the Java SunPKCS11 provider configuration file that lists as part of enabledMechanisms list or removes the mechanisms from the list of disabledMechanisms of the Java SunPKCS11 configuration file. Doing so forces the required AES operations performed by Intel AES-NI.
For SSL scenarios using AES for bulk encryption, it is important that the Java application server’s SSL configuration is enforced to use TLS_*_AES* cipher suites (-Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA). For WS-Security scenarios using AES for XML Encryption scenarios, it is required to choose WS-SecurityPolicy using algorithm suite that includes AES ciphers. If the WS-SecurityPolicy specified algorithm suite is Basic256Rsa15, it uses Aes256 encryption and Rsa-oaep-mgf1p for key wrap. To enable acceleration, you need to remove the required bulk encryption algorithms in the disabledMechanisms list that forces those operations (ex. CKM_AES) performed by Intel AES-NI.
AES-NI Performance on Solaris for SSL and WS-Security
As I tested on a Xeon 5660 based server, using AES-NI for securing Java EE applications and XML Web services on Solaris 10 Update 9 showed significant SSL and WS-Security performance gains on Solaris 10. The SSL performance (RSA-1024/AES-256) showed 30% – 40% performance gain over not using AES-NI and WS-SecurityPolicy (using Basic256Rsa15) showed about 2X – 3X performance on XML encryption and decryption operations. Certainly Java security applications has strong advantage while running on Solaris on Intel Westmere processor based servers.
I am not a performance guru…but in my opinion Java Cryptographic performance on Linux (Intel Westmere) has NO EFFECT as Linux lacks support for a software PKCS#11 provider that takes advantage of AES-NI. If your Java applications has significant AES workloads then Solaris 10 is ideal choice on Intel Westmere based servers.
Try it out and let me know your comments.
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
The untold reality is ….when your Web application on the DMZ hits the Internet… the colorful performance graphs/numbers does’nt mean anything ! Unless your performance guru in the lab captured the QoS requirements and realized it proactively and accounted its actual overheads associated with Security, Network bandwidth, High-availability and other mission-critical requirements. Otherwise…performance is the nagging issue that every datacenter guy gnaws…. when an application bloats up with its cryptograhic shields such as SSL and WS-Security and then goes into production. If you are one of them in the datacenter, who is pulling the hair out on Security performance issues and compelled to meet the SLA including IT Security and compliance requirements mandating the use of cryptography for securing the exposed application layers – transport, data and network – Then this Sun solution blueprint should help you for accelerating the real-world performance of Java EE based Web applications (especially Oracle Weblogic) delivering Security ground-up and all WITHOUT your performance engineer help :-)
No magic or surprises – The Sun CMT server features On-chip Cryptography and multi-threaded 10GbE networking out of the box – No kidding! If you are curious to know more or seize the power of your Sun CMT servers for security, take a look at the blueprint and also take a look at my previous post highlighting our presentation at Oracle Open World - Wire-speed Cryptographic Acceleration for SOA and Java EE Security.
Time flies..it is amazing to know, yesterday marked the 15th anniversary of Design Patterns: Elements of Reusable Object-Oriented Software by Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides), a seminal work in object-oriented software design and development that changed the way how we think and solve software implementation problems. In simpler terms., Design patterns is all about adopting to proven solutions evolved from prior experiences and the known bestpractices/pitfalls without ending up reinvent the wheel ! In my experience, using design patterns helped understanding the architecture and design the software right at the first attempt and resulting reusable code artifacts – easier to reuse with subsequent design and development process.
When Chris and I started our security patterns work… unthinkably..the GoF patterns and its core principles has always been our primary source of guidance for evolving the Security Patterns catalog. With 14+ years passed by, the Design patterns book has never gone out off my sight and always remained in my reaching distance… when so many other books collecting dust in my shelf ! Now, my shameless promotion… about celebrating the 15th anniversary of Design Patterns - Prentice Hall/Addison Wesley is bringing out a series of interviews (featuring GoF and others), articles and takes this opportuntity to further influencing the relevance of Design patterns books with 30% off on the cover price.. Here you go:
Enjoy…
Back to top