Core Security Patterns Weblog

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:

1. Use SSL/TLS communication to ensure encrypted transport between the user’s client and Web server.
2. Use encrypted session cookies and use encrypt/decryption mechanisms for setting and getting of cookie data.
3. 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.

Web 2.0 is not my forte but I am not ignorant to know its overwhelming adoption and popularity !  In my understanding, Web 2.0 is another Web based application paradigm that enables delivering user-generated content via aggregation, participation and collaboration on the Internet using Web based protocols.  No doubt, everyday a new breed of Web 2.0 application is finding its place in the IT industry and it changes the existing Web based applications  through convergence of consumer and enterprise collaboration.  Although it is amazing to see the changes brought by Web 2.0 is compelling, these improvements are mostly getting accompanied by newer set of security threats and vulnerabilities partially due to the known complexities with underlying architecture and design choices ignorant to the critical real-world security requirements.

Recently, Secure Enterprise 2.0 published the  2009 Industry Report on Top Web 2.0 Security Threats which highlights the most common security vulnerabilities associated with Web 2.0 applications. At my first look, I am bit puzzled by the long list of security threats identifying the known exploit scenarios and security incidents from most popular Web 2.0 sites such as Facebook, MySpace, Craigslist, Yahoo HotJobs, Twitter, My.BarackObama.Com, Wikipedia and so on.  I am not surprised by the list, whomsoever coined the term Web 2.0 might’ve forgotten or decided to have Web 2.0′s security as an afterthought !

Looks like Web 2.0 is another goldmine for security enthusiasts   ! Go ahead and read the report for yourself..The report is right here.

Few weeks ago, US Dept. of Homeland security (National Cyber Security Division) in collaboration with SANS Institute/MITRE teams worked together and released a list of 25 dangerous programming errors as common security flaws, which opens doors for easy exploitation. My first look at this list, I thought it is a old wine in a new bottle as the document sounded a bit more high-level without applied countermeasures and reality checks. The list did go extra mile highlighting the mitigation strategies and countermeasures. For those follow OWASP Top 10 (Most compelling), the CWE Top 25 list is a bit more augmented to include the weakest links of security in target resource and client/server environment. At the outset, the Top 25 list certainly helps our budding developers on understanding the potential weaknesses and vulnerabilities arise due to poor coding practices.

Here is the list of SANS/MITRE’s Top 25 Most Dangerous Programming Errors, in no particular order…

1. Improper Input Validation
2. Improper Encoding or Escaping of Output
3. Failure to Preserve SQL Query Structure (SQL Injection)
4. Failure to Preserve Web Page Structure (Cross-site Scripting)
5. Failure to Preserve OS Command Structure (OS Command Injection)
6. Cleartext Transmission of Sensitive Information
7. Cross-Site Request Forgery (CSRF)
8. Race Condition
9. Error Message Information Leak
10. Failure to Constrain Operations within the Bounds of a Memory Buffer
11. External Control of Critical State Data
12. External Control of File Name or Path
13. Untrusted Search Path
14. Failure to Control Generation of Code (Code Injection)
15. Download of Code Without Integrity Check
16. Improper Resource Shutdown or Release
17. Improper Initialization
18. Incorrect Calculation
19. Improper Access Control (Authorization)
20. Use of a Broken or Risky Cryptographic Algorithm
21. Hard-Coded Password
22. Insecure Permission Assignment for Critical Resource
23. Use of Insufficiently Random Values
24. Execution with Unnecessary Privileges
25. Client-Side Enforcement of Server-Side Security

It is an impressive list…that leaves me with some hard questions, when it comes to how to implement the required safeguards and countermeasures – Yes, the Devil is always in the Implementation details as there is No Magic Silver Bullet and it becomes critical to the developer to choose, adopt and practice the appropriate “Security Design and Best Practices” that identifies the safeguard and helps proactively defend against those known errors.  As a developer – in the first place you must understand – how to bake-in security in your application choosing the relevant “Security patterns, Best practices, Pitfalls and Reality checks”…for your target application development and deployment environment.

This gives me another opportunity for my shameless book promotion (is here), especially for those who is interested in knowing the security patterns and require implementation guidance for securing Java/J2EE/Web Services environments.

Couple of days ago, I received the above question from one of our readers.  Although I briefly responded to him over email,  I really wanted to explore the known traits for defending this vulnerability :

HTTP response splitting is a Web application input validation vulnerability that allows to exploit the HTTP headers of a Web application for initiating attacks leading to Cross-site Scripting (XSS),  user/page hijacking, cookie poisioning, Web-site spoofing/defacement and so on. The attacker initiates this attack through the injection of  a  sequence of hex-coded Carriage-Return (CR) and Line-Feed (LF) characters in the HTTP heaer and then appending it with malicious HTTP Set-Cookie headers  crafted to force the server to process and  break the requests into two individual responses.  To protect Java EE (J2EE) based Web applications from  HTTP Response Splitting related risks and vulnerabilities, the golden rule is to perform “Input Validation and Output Sanitation” of Web-tier/presentation components that allows user interaction via a Web browser or a client application.

• Input Validation in a Java EE Web application is done via Filtering and Encoding mechanisms. In practice, it is quite important to validate the input parameters at both “client-side and server-side” before accepting the request and resuming the process on input parameters. The filtering mechanism should validate data in terms of data type (string, integer), format, length, range, null-value handling, verifying for character-set, locale, patterns, context, legal values, session validity, redirection URL, idle time and so on. Although filtering is a promising solution, in some scenarios we cannot discard or reject data using filters where the user is requested to provide input content that includes special characters. Particularly to mitigate HTTP Response Splitting risks,  it becomes important to parse and verify the input for CRLF \r\n %0d%0a or any other form of encoding CRLF characters before processing them. To handle special input content with undiagnosed characters or scripts, it is often recommended to use encoding mechanisms that allows to transform the stream of encoded characters as special sequence of character sets that cannot be executed at the Java EE application server or Web server. This allows to defeat HTTP Response Splitting and related XSS attempts through malicious code and script injection. If the Web application relies on client-side data validation, it is always safe and good practice to re-verify and re-validate input at server-side, even after client-side validation.

• Output Sanitation also plays a vital role in avoiding HTTP Response Splitting. Re-displaying or echoing the data values entered by users causes a potential threat because it provides a hacker with a means to match the given input and its output. This provides a way to explore the Web component by inserting malicious data inputs. If the page generated by a user’s request is not properly sanitized before it is displayed, a hacker may be able to identify a weakness or loophole by reading the generated output. Using the weakness, the hacker can design and insert malicious scripts and hyperlinks that may be able to change the content originally displayed by the site or perform malicious operations.

For Java EE Web application developers, I strongly recommend using appropriate design strategies prescribed in the “Intercepting Validator” and “Secure Session Manager” patterns from the Core Security patterns catalog. In addition to “Input Validation and Output Sanitization” mechanisms, I often recommend the following best practices to be considered for pro-actively thwarting related attacks:

1. Secure the Transport: For all security-sensitive Web applications and Web-based online transactions, make sure the session and data exchanged between the server and client remain confidential and tamper-proof during transit. Using SSL communication with digital certificates offers confidentiality and integrity of data transmitted between the Web applications and client authentication.
2. Use Stateful Firewalls. Use a stateful firewall inspection to keep track of all Web-tier transmissions and protocol sessions. Make sure it blocks all unrequested transmissions.
3. Validate Form Fields: Ensure that any alteration, insertion, and removal of HTML form fields by the originating browser are detected, logged, and result in an error message.
4. Use HTTP POST: Use HTTP POST rather than HTTP GET and avoid using HTTP GET requests while generating HTML forms. HTTP GET requests reveal URL-appended information, allowing sensitive information to be revealed in the URL string. Also, disable processing of HTTP TRACE method in the target Java EE application or Web server to defeat Cross-site Tracing (XST) attacks.
5. Track User Sessions: Identify the originating user and the host destination making the application request in the user sessionid. Verify that all subsequent requests are received from that same user s host origin until the user logs out. This protects application sessions from XSS hijacking and spoofing.
6. Error reporting: Always return an error page or exception specific to the application error and the user s request. For example, you might use an application-specific InvalidUserException and NoAccessPrivilegesException. Do not expose remote, system-level, and naming service specific exceptions to the user accessing the applications. These exceptions to the end user expose weakness in the application and allow hackers to design potential attacks.
7. Audit All Relevant Business Tasks: Create audit trails for all identified user-level sessions and actions with timestamps and store them in a different log file with unique line identifiers. This helps identifying any potential exploitation or weakness of the Web application. The audit trails should include user attempts and failures, logouts, disconnects, timeouts, administration tasks, user requests and responses, exceptions, database connections, and so forth.