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.
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:
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.
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.
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: