Hacker Proofing Web Apps with the New Java EE 6
by abhaybhargav on Oct 18, 2010
- 1,419 views
Slides of the popular talk "Hacker Proofing Web Apps with the new Java EE 6" The talk was first showcased at the JavaOne, Oracle OpenWorld 2010. It was very well received by the audiences in the confer...
Slides of the popular talk "Hacker Proofing Web Apps with the new Java EE 6" The talk was first showcased at the JavaOne, Oracle OpenWorld 2010. It was very well received by the audiences in the conference. It is by the authors of the book "Secure Java: For Web Application Development"
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 0
- Downloads
- 0
- Comments
- 0
- Embed Views
- Views on SlideShare
- 1,160
- Total Views
- 1,419
Dr. Kumar: This talk evolved from a discussion we had in one of the many pubs in Bangalore. We were discussing the state of web security and web application security in general. Such nerdy behaviour is observed after a few drinks...
Abhay: I had gone off on a tangent about a super-vulnerable web application I was testing and how the developers there seemed clueless about security
Dr. Kumar: and I told him that my apps could not be hacked.
Abhay: Which I found unbelievable. That naive confidence that he had in his app security skills was cute, but so wrong
Dr. Kumar: So I challenged him. I told him that I would build an app
Abhay: and I told him I would break it.
Dr. Kumar: What do you mean by breaking an app?
Abhay: By breaking an app, I mean that I will identify vulnerabilities and exploit them using proof-of-concept exploits for them....
Dr. Kumar: That’s why we are here. To tell you what this is all about.
Dr. Kumar: You are making bold statements. But tell me something, how are you actually planning to break my app???
Abhay: This is not the first time, I am breaking an app. Let me share some of my personal experiences on how easy it is to break apps.....
Dr. Kumar: I have had some expertise with web application security. I will tell you three types of attacks and you tell me if you are able to do anything like this...
Abhay: What are those?
Dr. Kumar: Have you used Cross Site Scripting?
Abhay: I love Cross Site Scripting. I have tons of Cross Site Scripting experience
Dr. Kumar: What about SQL Injection?
Abhay: SQL Injection is a great attack. Yes, I have injected SQL in several sites and have owned the database after that.....
Dr. Kumar: What about Authentication and Authorization Bypass??
Abhay: Oh yes, I love breaking Access Control. I have story for that as well.
Dr. Kumar: Ok then, tell me your stories.....
Dr. Kumar: Reputation - It takes 20 years to build a reputation and it takes 10 minutes to destroy it. Customers would think more than twice before offering your organization financial and personal information. Believe me
Abhay: In the wake of several security breaches and high profile incidents, the government and governing bodies have realized that it is no longer a matter of comfort, but a matter of necessity to secure critical information assets. We have several security compliance requirements from the government, namely HIPAA - for Health Information, GLBA - for Financial Information, SB1386 - California Breach Security Act for Personal Information of users. We will discuss compliance at length in the next slide.
Dr. Kumar: Hackers earlier, for the most part were individuals who did it for the fun of it or in some cases for individual personal gain. However, in the web2.0 world it has all changed. Large criminal rings and transnational criminal elements fund and support large scale hacking of financial data and personally sensitive information to fuel identity theft and financial theft. Hacking has taken an ugly turn.
Compliance is one of the driving forces for Web Application Security. Some of the important Security Requirements are as follows:
PCI-DSS: PCI-DSS is the Payment Card Industry Data Security Standard. This is a standard laid down by the card payment brands like visa, mastercard, amex, jcb and discover. This standard mandates several specific application security requirements among other information security requirements. The standard mandates compliance for any entity, storing, processing or transmitting cardholder information. Merchants, service providers, banks and hosting providers are some of the entities that are under the purview of this standard.
The HIPAA is an important compliance standard that is mandatory for entities handling personal health information. The act mandates security measures which may include web application security, as these apps handle a great volume of sensitive health information.
The GLBA is an act driven to modernize the Financial Services industry. In its multiple requirements, GLBA also mandates entities handling personal financial information to have a stringent information security program.
SOX is a law requiring listed entities to have internal control measures to ensure integrity of their financial statements. Now, in this age of computerized accounting and ERP, web applications play a major role in the preparation and creation of financial statements, thereby requring application security measures to be a part of the system.
Abhay: Cross Site Scripting is a vulnerability where an attacker injects JavaScript into application input. If the application does not filter input and output, the application deems the input to be html code and executes the JavaScript on the user’s browser. This has multi-pronged effects. This could be used to steal user cookies, or even take over the user’s browser and feed him/her with malware. User Session Hijacking, Malicious redirection to another site, Denial of service, a crafted JavaScript could force the site to crash after a point. This has been seen with several sites like Myspace....
Abhay: SQL Injection is an attack where an attacker passes SQL queries into the application’s input. If the application does not filter the input effectively, the query is executed and the attacker can gain access to sensitive database information and in some cases, can compromise the entire database.
We will show you a demo of a SQL Injection attack.
This is the site of an e-commerce where people can buy and sell items. Its a typical e-commerce site.
We will show you how we identify SQL Injection vulnerabilities. We add a single quote to the HTTP GET request parameter. This is done to induce an error page. If the error page comes up, the parameter with the single quote is being parsed and the app is potentially vulnerable to SQLi
We will show you how we use tools to exploit the given vulnerability. We fire up SQLmap to identify and exploit the given SQL Injection vulnerability.
The tool is able to perform any kind of injection, including enumerating DB usernames and passwords
This is a login screen for a typical e-ticket booking website. In this case a bus booking site
We dont have valid credentials on the site, we just improvise!!
We use an innocuous parameter like chkRules and nullify all the values.
We use an interception proxy to alter the param values on the fly
Voila!! We gain access to a user account and use our access to pivot to other parts of the web app.
Abhay: Yup, here it is....
Dr. BVK: We will be exploring each of these elements that are summed up to make a secure web application.....
One of the primary authentication requirements is password management. The web app must enforce password strength requirements (atleast in the case of high risk applications like Banking and E-Commerce or Admin Consoles). Web Apps should also enforce password changes.
Another important password feature is the password lockout. For high-risk applications accounts should be locked out of the application after say 4/5 failed authentication attempts. Oftentimes, it is seen that password bruteforcing is done extensively by attackers. Another major bone of contention is password reset questions. How many of you have come across Rudimentary questions when you do a password reset like “What is the name of your school?” or “What is your favourite hobby?”. I have a great answer to all these questions and it is called “Social Networking” Using the power of Social Networks, where you put up everything from your favourite shirt colour to your dog’s spouse’s name. Its easy to find the name of your highschool or your favourite hobby. In fact, a major telecom company had this particular password reset question. Which car do you own at home? with 4 options: Lamborghini, Lotus, Fiat or Honda. No prizes for guessing the correct answer.
Many applications also implement Authentication parameters like isValidated() or isAuthenticated() and by setting these parameters to null or no, the attacker is able to gain access to the account. The key is to validate these parameters.
Abhay: There is another attack called CSRF, which we will discuss at a later part of the presentation.
Abhay: Another important point of mention is that Authorization systems need to be driven by the server side. I have seen certain “Authorization systems” that have relied on either JavaScript or HTML commenting to enforce authorization to pages and disabled functionality. Authorization needs to be driven based on the sensitivity of the resource/function and the need for a user to access the resource/perform the function.
Applications must also enforce Session timeouts after a stipulated timeframe, say 15 minutes. In case of high-risk web apps like Banking, session timeout must be set to lower, like 5 minutes or so...
Certain functions or actions in a web application are highly privileged functions, which are also highly at risk. For instance, transfer of funds in a banking web app is a highly critical function. In such cases, it is prudent to have the user reauthenticate with a different set of credentials or regenerate the session token for a higher privilege transaction. This may also be implemented for Application Administrators when they need to perform highly privileged functions in the web app.
Session fixation attacks are common among several applications. Session fixation attacks rely on the fact that the application does not invalidate existing session tokens, when logging a user into the application, Thereby giving an attacker access to the user’s account on an older session. Existing sessions must be invalidated before giving a user access to the application.
Dr. Kumar: Authentication and authorization part of the java web applications can be handled using the Services and APIs of JAAS - The Java Authentication and Authorization Services part of the Java Platform. The JAAS has evolved since a long time along with the platform and has been easing the pains of the web application developers using the Java Platform for Application Access Control Implementation. We focus, in this particular talk, on the advanced features of Java EE 6 and of the security aspects as applicable to a web application.
As we are focusing on the web application security part, we will restrict our time in understanding the web application development part of the new security features in Java EE 6. Again we will filter-out the non-java part (on things such as http-method-omissions, Filter Mappings etc). We will elucidate the servlet security feature that was introduced in Java EE 6. There are essentially three items that we need to focus - the authenticate() method, the login() method and logout() method. Also, note that their implementation as a part of the new GlassFish V3 app is complete and tested for the new Java EE 6 version.
The authenticate() method is provided in the javax.servlet.http.HttpServletRequest interface. This method is one of the examples of programmatic security (login, in particular) in Java EE 6. It can be used as an alternative to the . When used in a servlet or a JSP, it forces authentication, using the login-mechanism specified in web.xml even if no security-constraint element is specified in the web.xml. After a call to authenticate succeeds, the user credentials are validated using appropriate methods().
Abhay: Oh! What are these methods and how do they help??
Dr. Kumar: The following methods provide the desired results for authentication part of the web application:
(i) getRemoteUser(), (ii) isUserInRole(), (iii) getUserPrincipal()
We will discuss aout these methods a little later during the Authorization part of the presentation.
The advantage of using the authenticate method is that it provides the flexibility to login in dynamically combined with the ability to be used with the configured login-mechanism like BASIC. Here is a sample code that illustrates the use of the new authenticate() method. On deploying the war file and accessing the servlet (http://:/application/test , a BASIC authentication is forced by the container, since the call to authenticate() is made in the service method of the servlet.
The other two related methods are login() and logout(). Note that they also throw ServletException.
Similar to the authenticate() method, the login() method serves to authenticate a given username and password programmatically. This method throws a ServletException when the validation of username, password provided fails or if the caller identity has been already established before a call to this method or if the configured login mechanism (in web.xml) is does not support username, password validation.
A recent fix was made to have the authentication state in the existing session after a successful login. The session is created if it does not exist at this time to store the auth state. In the orthogonal HttpServletRequest.logout() method, this authentication state is cleared from the session. Please note the servers need to appropriately implement these new features. For example the new GlassFish V3 takes care of the same.
Notice that the login() method allows to programmatically collect with the provided username/password credentials (as an alternative to FORM-based authentication) and perform user authentication. Similarly, the logout() method performs logging out the user and resets the context.
Dr. Kumar: We have a few new methods introduced which are very useful in the Authorization part of the application. After a call to authenticate() method succeeds, the user credentials can be validated and the following methods provide the desired results: Recall we mentioned it earlier that there are three of them. They are:
(i) getRemoteUser()
(ii) isUserInRole()
(iii) getUserPrincipal()
Dr. Kumar: Sure. Lets go with the first one, the getRemoteUser() method. The method getRemoteUser() - provides the name of the remote user associated with the request, as highlighted here. In this code snippet, we are just printing the remote user name....
The next method is the isUserInRole() Method: This method determines if the remote user (that is, the caller) associated with the request is in a specified security role - returns true after a successful authenticate, provided the role is specified. We have provided a snap shot of the usage of validating whether the user is in a given role or not in this if statement.
FInally the getUserPrincipal() method: This method determines the principal name of the remote user (that is, the caller) and returns a java.security.Principal object corresponding to the remote user. Here is the usage of the getUserPrincipal() method.
Dr. Kumar: The annotations part of the java has enter the Servlet world now. Accordingly we also have security related annotations (and the corresponding deployment descriptors) taking care of Security requirements for 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.
Dr. Kumar: The @ServletSecurity annotation allows to define the security constraints as its fields - @HTTPConstraint, @HTTPMethodConstraint. @DeclareRoles and @RoleAllowed.
Abhay: Can you briefly mention how these annotations are used in the web application for handling the security??
Dr. Kumar: For example use @HttpConstraint(rolesAllowed to ensure that all HTTP methods (GET, POST, TRACE) are protected and access is allowed to security role “customer” and @HttpConstraint annotation to ensure the methods require SSL transport.
Similarly, we can use HttpMethodConstraints to ensure only authenticated users with security role is allowed to access HTTP POST method and transport-layer security/SSL is supported but not required.
Finally, the @DeclareRoles and @ RoleAllowed are a no brainer
Abhay: Let me give you Scenario: Let us say an attacker wants to hack your bank account and steal some money. He sends you an email with a URL, actioning a transfer to his account. Let us assume that you are logged into your email and your bank account simultaneously. You click on the link of the malicious email and a request is raised to the bank. The bank does not know that it is a phantom request coming from a phantom source. For the bank, you a currently logged in and the request is legit. The funds are transferred because the bank’s site was vulnerable to CSRF.
Abhay: This can be prevented in a few ways. One of the most effective ways is to raise a cryptographically secure string and store it in every user’s session object. The string should be accessed and made as an HTML hidden form field and submitted with every request that the user makes to the application. On the server side, the token submitted must be matched against the string in the session object. If it matches, the request should be considered legit. Usage of Java’s SecureRandom is ideal for these implementations.
Abhay: One of the primary mistakes people make is to believe that the cryptographic algorithms they develop are way better than the industry standard algorithms out there and design their own encryption schemes. Once, I came across a developer who wanted to encrypt credit card numbers in his app by subtracting with one set of digits and adding with another set of digits. Please do not write home grown crypto.
Strong Encryption algorithms need to be used to protect data at rest. Preferably AES-128 bit or above) or 3DES or in case of asymmetric crypto, keylengths of atleast 1024 bit.
Apart from key and key parameters, it is very important to ensure that a single encryption key performs a single task, for instance, a key used to encrypt data should not be used as a key used to encrypt transmissions. Higher usage of the key results in higher possibility of a key compromise.
Ensure that data at rest is stored with a key and and that key is encrypted with another key called the Key Encrypting Key. The data encryption key is more likely to be compromised, therefore there is an additional layer of security with the key encrypting key. It has to be ensured that the DEK and KEK are not stored in the same location.
One of the golden rules of thumb is to never ever store key or key strings in the source code. I was assessing a banking application, where the developer had written down the key value in a serverside comment and their application was also vulnerable to a source code disclosure attack, where I could enter arbitrary strings and gain access to their source code on my browser. Finding a key encrypting millions of personal records is like gold for an attacker....
Asymmetric crypto requires a public-private key pair. And the private key, as the word goes needs to be kept private. Export of the private key should be disallowed.
In many cases, encryption keys are generated, in some other cases, the key is a password or passphrase which is created by the key custodian(s). In such cases, the quality of the password must be compulsorily specified by the organization to ensure that the quality of the encryption key remains paramount.
Dr. Kumar: We have the JCA / JCE coming to our rescue, as usually. You know it is not at all new. The new Java EE 6 introduces several new features for Cryptography, Cipher and Encryption which eases the web application data security.
The JCA / JCE provides an extensible, full featured API for building secure applications which are Algorithm and implementation independent in a provider-based (pluggable) architecture
We already know JCA and JCE provide a wide range of cryptographic services such as digital signatures, message digest, symmetric and symmetric ciphers, stream and block ciphers, message authentication codes, key generators and key factories.
These rich libraries also provide support for standard algorithms such as RSA, DSA, AES, Triple DES, SHA, PKCS#5, RC2 and RC4
Dr. Kumar: Some of the new features specific to Java EE 6 (and not necessarily web application focused) are:
Elliptic Curve Cryptography (ECC) in SunPKCS11
Elliptic Curve CipherSuites in SunJSSE
Access Network Security Services (NSS) using SunPKCS11
Cipher Text Stealing (CTS) mode added to SunJCE block ciphers
Removed the 2048 RSA keysize limit from local_policy.jar
Access to native PKI and cryptographic services on Microsoft Windows
-------Additional notes in case there are questions on specifics -------------
Elliptic Curve Cryptography (ECC) in SunPKCS11
(For elaboration in case of question - The SunPKCS11 provider now exposes ECC algorithms if the underlying PKCS#11 token supports them. This include ECDSA signing and verification, ECDH key agreement, and generation of EC keypairs. For more information about the supported mechanisms, see the supported algorithms section in the PKCS#11 reference guide.)
Elliptic Curve CipherSuites in SunJSSE
(For elaboration in case of question - The SunJSSE now supports the ECC ciphersuites defined in RFC 4492, if a suitable crypto provider is available (for example, SunPKCS11 with an appropriate PKCS#11 library)
Access Network Security Services (NSS) using SunPKCS11
(For elaboration in case of question - The SunPKCS11 provider supports new configuration directives which allow it to access the NSS security library. This enables Java applications to read keys stored in the NSS database files, use ECC algorithms, and to use the NSS Softtoken as a FIPS 140 compliant cryptography provider)
Cipher Text Stealing (CTS) mode added to SunJCE block ciphers
(For elaboration in case of question - CTS is described in Bruce Schneier's book "Applied Cryptography-Second Edition", John Wiley and is used by some Kerberos implementations)
Removed the 2048 RSA keysize limit from local_policy.jar
(For elaboration in case of question - Implementations were previously restricted from obtaining RSA keys larger than 2048 bits without installing the unlimited crypto policy files)
Access to native PKI and cryptographic services on Microsoft Windows
Added the SunMSCAPI JCE provider which uses the Microsoft CryptoAPI (CAPI) to offer a variety of RSA cryptographic functions. It acts as a bridge between Java applications and the services offered by the default RSA cryptographic service provider available via CAPI. It provides access to X.509 certificates and RSA key pairs, it performs RSA encryption and decryption, and it creates and validates RSA signatures. It also supports a cryptographic random number generator)
Abhay: Yes, Hashing is another important data protection technique for data at rest. Hashing as some of you may know, is a one way operation, in that the data once hashed cannot be regenerated as in the case of encryption. In many ways hashing is better as the data is subjected to a one-way procedure and it can be validated with queries and other processes. It is common practice to hash passwords in web apps.
Having said that it is imperative that strong hashing algorithms upwards of SHA-1 be used. It was proved recently, that MD5 an extremely popular hash algorithm was broken and proven non-secure. So, please change your hashing algos if you are using MD5.
A Salt is not for food in the case of hashing. Salt is a nonce or a string that is used to add a greater degree of randomness to the hash value. Adding a salt prevents collision of hash values of similar data, thereby adding an extra measure of security to the hashed information.
Abhay: Logging is considered by many to be an unnecessary resource. But imagine this, your application is hacked with a SQL Injection attack and the attacker consistently extracts information out of the database for 6 months and you finally figure it out and want to look for the source and starting point of this attack, the only thing that will tell you this are the logs. This story was a real life incident at one of the largest universities in california, not too far from here....
Logging currently is not a part of the Java Security Requirements. However, we believe that it should be and we have also made a special mention of the same in our book.
What should be logged, (READ OUT)
First step to input validation is to understand all the input to the application, whether it is from user or from a webservice, or other site, or file. All input needs to be identified, text input, checkboxes, radio buttons can all be manipulated to inject if note validated.
Regular expressions should be used to validate input. Let us suppose that you want to validate an email address, a regular expression with the java.util.regex library can be used for creating the reg ex and validating the user input based on the regex.
Need I say, that Input Validation has to be done server side and not client side with JavaScript because of that one word : Client side.
There are 2 approaches to validating input. One is a black list where one needs to identify all the characters deemed as contraband and filter the application input based on these known bad characters. The other is the whitelist, which is a highly recommended approach. Whitelisting allows you to create a known-good set of characters that one can use to filter input. For instance if you would like to filter a username field, you would filter it to only allow letters, numbers and perhaps underscore. This is a better approach than blacklisting, because you cannot effectively ensure 100% protection against attacks in a blacklisting approach as there are several injection attacks that can be encoded differently for the attack to be successful.
Dr Kumar: For Input validation, we have the usual classes from the java.util.regex and the java.text libraries of the Java Standard edition which can be used as appropriately.
The Matcher and Pattern classes of the java.util.regex package helps us in matching character sequences against patterns specified by regular expressions.
Similarly, the Normalizer class in the java.text package provides the method normalize which transforms Unicode text into an equivalent composed or decomposed form, allowing for easier sorting and searching of text. The normalize method supports the standard normalization forms described in the Unicode Normalized forms.
Specifically for the web components, we have the HttpServletRequestWrapper class, whose methods are useful in wrapping the given HTTPServletRequest object for processing the data input for validation. And, of-course, we have the Filter interface which can help us in designing a validating filter.
Dr. Kumar: For Output encoding we have the URLEncoder class from the java.net package for the HTML form encoding. The static encode method converting a String object to the application/x-www-form-urlencoded MIME format.
Although not a part of the Java EE 6 part we are discussing, we have some interesting libraries from apache.commons.lang whose StringEscapeUtils class provides a number of methods to Escapes and unescapes String objects for Java, Java Script, HTML, XML, and SQL.
The ResponeUtils class of the Struts framework (of the yesteryears) can also be highlighted here. General purpose utility methods of this class is related to generating a servlet response in the Struts controller framework.