Web Session Hijacking

Abstract

This work addresses the issue of web application session hijacking via the sniffing of unencrypted cookies over a wireless network. I focus our analysis on FireSheep, a recently released third-party add-on for Mozilla Firefox which allows attackers to hijack the web application sessions of users with a single click. Although this type of session hijacking, commonly referred to as “sidejacking,” has been well understood by security researchers for some time, FireSheep’s ease of use has brought new attention to the insecurity of using unencrypted cookies to maintain web application sessions. As of writing, FireSheep has been downloaded over a million times since its release on October 24th, 2010 at the twelfth annual Toorcon security conference in San Diego California by security researchers Eric Butler and Ian Gallagher.

1. Introduction

• Objectives
• Scope
• Legality

1. Literature Review

• Related Tools
• WEP and WPA(2)
• SSL, TLS and HTTPS
• SessionLock

1. Hypotheses
2. Methodology
3. Experimentation

• FireSheep
• Idiocy
• FireShepherd
• BlackSheep

1. Conclusions and Recommendations

• Non-Expert Users
• Expert-Users
• Wireless Network Administrators
• Website Administrators
• Future Research

1. References

Provided is an analysis of FireSheep’s publicly available source code as well as experimental results of its use hijacking the sessions of several popular web applications. I then proceed by discussing various defense methodologies and tools which mitigate the threats posed by such attacks as are facilitated by FireSheep. HTTPS, VPNs, and SSH tunnels are examined as countermeasures, as are BlackSheep [2] and FireShephard [10], two programs developed specifically in response to FireSheep in an attempt to mitigate the risk it poses to unsecured users. I also discuss Idiocy, an automated session hijacker specifically for Twitter sessions. Idiocy was inspired by the development of FireSheep, from which its code is forked [15]. I also examine HTTPS Everywhere [14], an extension for Mozilla Firefox which forces the browser to use HTTPS for sites that allow doing so as an option. I provide a brief theoretical analysis of SessionLock, a novel security architecture developed by security researcher Ben Adida as a method of defending against session hijacking attempts without requiring persistent SSL throughout a user’s session [1]. I conclude by providing a summary of experimental results and by synthesizing my analyses into actionable recommendations for users with varying expertise, security requirements, and resource limitations.

Introduction

In this paper I address the issue of web application session hijacking via the sniffing of unencrypted cookies over a wireless network without security or one with Wired Equivalent Privacy (WEP). I focus my analysis on FireSheep, a recently released third-party add-on for Mozilla Firefox which allows attackers to hijack the web application sessions of users with a single click. Although the attack vector involved in this type of session hijacking, commonly and hereafter referred to as “sidejacking,” has been well understood for some time, FireSheep’s ease of use has brought new and intense attention to the insecurity of using unencrypted cookies to maintain web application sessions. Between its release on October 24th, 2010 and the time of writing (December 7th, 2010), FireSheep had been downloaded 917,098 times.

Prior to FireSheep, sidejacking required at least a basic knowledge of the command line, even for tools with a graphical user interface such as the sidejacking tool Hamster, which was released in 2007 by the consulting group Errata Security [12]. Accordingly, while Hamster proved to be an effective tool for sidejacking, its use did not garner much attention outside of the information security community, who were already well aware of the unsecure nature of unencrypted cookie traffic. As is understandable, the requirement of even a few command executions at the command line is enough to deter most non-expert computer users. Although the intention of the authors of Hamster was to raise awareness about sidejacking as an important security issue, they failed to do so because the average computer user was unable or unwilling to look at their software because of the technical knowledge requisite of its user.

Similarly motivated, the author of FireSheep, Eric Butler, has declared that he intends FireSheep to be an educational tool that raises awareness and brings attention to an important security issue. He hopes that the developers and providers of web applications and services address the unsecure nature of unencrypted cookies used for web application session maintenance. The volume of downloads that FireSheep has experienced in a relatively short period of time suggests that this goal is being achieved.

“In the three weeks since was released, there has been some encouraging news that companies are waking up to the reality that HTTP is dead, and that full end-to-end encryption (HTTPS/SSL) is no longer optional but rather a requirement of doing business online.” Eric Butler

Objectives

my objectives in this paper are first to analyze the source code of FireSheep to better understand how it functions, then to test its effectiveness as a sidejacking tool against the sessions of several popular web applications. Finally, I will implement and test various defenses against FireSheep and sidejacking attacks in general.

Although the problem of sidejacking is not new, the proliferation of wireless networks and the migration of many applications and services to the cloud have increased the importance of web application security over wireless networks in recent years. Sidejacking relates to computer networking very directly as a relevant security issue that affects anyone who uses web applications with authenticated sessions that send unencrypted traffic (i.e. just about everyone with a laptop). Previous efforts have failed to bring attention to this security vulnerability. Because FireSheep is currently bringing a firestorm of interest and publicity to this security issue, I believe that now is the ideal time to investigate sidejacking, session hijacking tools and various defensive countermeasures.

Scope

I limit my research and analysis to the single attack vector of unencrypted packet sniffing over wireless networks with shared access (attacker and user will be on the same network). I will limit my discussion to FireSheep and a handful of related tools, including Blacksheep, FireShepherd, Idiocy, HTTPS Everywhere and secure tunnels. my study of defensive methods will include multiple avenues of investigation, some of which eliminate and others which merely mitigate, the risk posed by sidejacking attacks. SessionLock, a security architecture for web application protection against sidejacking, will be analyzed and its concepts explored. Additionally, I will discuss the environmental factors pertinent to the systems and networks on which FireSheep does and does not work.

While other methods that allow malicious attackers to obtain a user’s cookies exist, I focus on wireless packet sniffing as the primary method of attack. The particulars of alternate attack vectors are not my focus because wireless packet sniffing is the point of greatest vulnerability for most users. Additionally, alternate vectors (e.g. cross site scripting and cross site forgery requests) either can be addressed by the user’s use of a current, updated browser or cannot be addressed by the user at all. For example, cross site forgery requests must be prevented by the administrators of a web site through proper security architecture.

Legality

The question of whether or not the use of FireSheep breaks federal wiretapping laws in the United States is currently being debated. This question will likely be settled by the ruling in the first court case which involves the use of FireSheep; such a case has yet to arise. The crux of the legal debate surrounding FireSheep stems from the question of whether or not users on a public network, at a Starbucks, for example, have “a reasonable expectation of privacy” on an unsecure wireless network [16]. Legal experts are currently coming down on both sides of this issue, with some suggesting that wiretap laws make it illegal to intercept communications in real-time. The current legal ambiguity surrounding FireSheep is primarily a result of the laws and statutes in question having been written before the internet became widely used.

Literature Review

Sidejacking has widely been written about as a known attack vector with a trivial execution difficulty [1][3][5][6][9][11][13][22][23]. A great deal of research interest in the domain of session hijacking has been devoted to the detection of such attacks through signal processing algorithms [20] [21]. The problem of session hijacking arises from the use of session identifiers as authentication tokens [5]. Although many sites encrypt user logins via HTTPS (HTTP with TSL/SSL), they often revert sessions to HTTP after authentication. Accordingly, although the password of a user may be encrypted, while a session is active the user remains vulnerable to session hijacking attacks via the sniffing of cookie(s) containing session identifiers. While existing literature widely describes users’ vulnerability to sidejacking attacks, few countermeasures other than full HTTPS or SSH tunneling have been proposed. Just as full HTTPS proves to be an infeasible solution for some site administrators, so too does the technical complexity of an SSH tunnel often prove to be unworkable for the average user [1][22][23].

Accordingly, Ben Adida’s SessionLock appears to be a viable, lightweight solution worthy of close consideration. Alternative solutions such as Teahwan Choi and Mohamed Gouda’s “HTTP Integrity” [7] propose a complete re-architecting of the HTTP protocol. Solutions which require the re-architecting of current, widely-deployed protocols and standards are both incredibly expensive and highly infeasible. Defenses against session hijacking which work with existing technologies and which are relatively inexpensive to implement will prove to be more valuable in the short term (i.e. until the next evolution of protocols and standards).

Preecha Noiumkar and Thawatchai Chomsiri have published a paper in which they successfully hijack sessions of major web mail providers Gmail, Inbox Mail, Fast Mail, and Hotmail with trivial sidejacking attacks [22]. I will replicate aspects of their methodology to experimentally prove the viability of FireSheep as a session hijacking tool for major web applications.

Related Tools

The recent explosion of interest in sidejacking that FireSheep has brought about has also resulted in the creation of a variety of related tools which are also worth examining. Idiocy, for example, automates the session hijacking process by running a variant of the FireSheep source code which automatically hijacks vulnerable Twitter sessions and posts to them a self-referencing tweet in an attempt to raise awareness about sidejacking as a security issue [15]. FireShepherd, on the other hand, is an extension for Mozilla Firefox that was developed specifically to defend against FireSheep attacks via spoofed packet flooding [10]. Another program called BlackSheep does not try to actively defend against FireSheep attacks but rather notifies users when FireSheep is being run on their network [2].

WEP and WPA(2)

In order for a sidejacking attack to be successful, the attacker must first obtain the session cookie(s) of a victim. This can happen when, for example, the attacker and victim are authenticated to the same wireless network and the traffic on that network is either unencrypted or encrypted with a shared key. Accordingly, on unsecured (i.e. security-less) and WEP wireless networks, network traffic is susceptible to eavesdropping by those connected to the network. WEP was originally designed to provide wireless security on par with the security of a traditional wired network (hence the name, “Wired Equivalent Privacy”) [18][20].

WEP networks employ a stream cipher encryption algorithm for security and the cyclic redundancy check (CRC) algorithm for error-checking [26]. WEP can operate either in open-system authentication mode(password-less) or in shared-key authentication mode. Authentication to an access point is accomplished via a four way handshake (authentication request, clear-text challenge, encrypted response, acknowledgement). “Cracking,” or determining the encryption key, of WEP networks can now be done by a number of widely available tools such as AirCrack-NG [25].

The attack vectors for breaking WEP encryption include dictionary attacks and exploits of vulnerabilities in the particular stream cipher (RC4) employed by the WEP standard. For example, Aircrack can determine 104 bit WEP key with a 50% probability after capturing 40,000 packets. After 60,000 packets, this probability jumps to 80% and reaches 95% after 85,000 packets have been captured [24]. Because WEP employs a shared key, once an has this key, all traffic on the network becomes intelligible and may be used, for example, in a session hijacking attack.

Subsequent to the development of WEP, Wi-Fi Protected Access (WPA and later, WPA2) was established as a new security standard meant to replace WEP by addressing its primary weaknesses and deficiencies. The temporal key integrity protocol (TKIP) lies at the heart of the WPA standard. TKIP dynamically generates new encryption keys for each packet which prevents key-collision, one of the WEP primary weaknesses of WEP that allows it to be cracked so quickly and consistently. Because each packet is sent with a unique encryption key, WPA is significantly more computationally intense than WEP. This additional complexity, however, makes attacks more difficult as well. Due to WPA’s increased resource equirements, some legacy WEP hardware can be repurposed for WPA networks with firmware updates.

WPA also employs a check on message integrity different from WEP’s implementation of CRC. If a packet does not pass WPA’s message integrity check it is dropped, preventing attackers from spoofing packets on a WPA network. Although significantly more secure than WEP networks, WPA networks are vulnerable to attackers if the password used to generate the encryption key is sufficiently weak and common (rainbow tables used by attackers are optimized for common passphrases and dictionary words). WPA2, the second iteration of development in the WPA family, employs the advanced encryption standard (AES) instead of TKIP. AES was standardized by the National Institute of Standards and Technology (NIST) in 2001 as the result of a cryptographic development competition. As the name suggests, it is sufficiently advanced as to prohibit succinct explanation here. Formy purposes, the primary distinction of importance between WEP and WPA is that WPA networks isolate users from one another such that the traffic of one user is not intelligible to another user on the same WPA network.

SSL, TLS and HTTPS

Secure Sockets Layer (SSL) is an encryption protocol that secures communications against eavesdropping. It works via a handshake where the server and client agree on the strongest possible implementation of SSL that they both support. As the second part of this handshake, the server sends a certificate to the client. Certificates are generally signed from a certificate authority, on whose name and reputation the validity and authenticity of the certificate rests. Certificates also contain a public key. Clients generally authenticate a certificate with a signing authority to ensure legitimacy. The Client then encrypts a pseudorandom number with the public key and sends it to the server, which will be able to decrypt it with its private key. The private key is to be held only by the legitimate owner of the certificate. Thus, authenticating with the certificate authority and maintaining the integrity of the private key are essential for ensuring communication which is protected from eavesdropping. Transport Layer Security (TLS) is based on SSL 3.0 and functions in a similar fashion.

HTTPS (Hyper Text Transport Protocol Secure) is the HTTP protocol implemented with SSL or TLS encryption for protected network communication. Essentially, the HTTP protocol is tunneled through an SSL or TLS session to provide encrypted web browsing.

SessionLock and Future Research

I have been unable to locate any literature regarding an implementation of SessionLock. Its developer, Ben Adida, works nearby in Mountain View and I have contacted him to requesting a meeting to learn more. I are currently looking forward to meeting with Mr. Adida in January to consult with him regarding a potential, proof-of-concept implementation of SessionLock. I believe that such an experimental implementation would provide important information as to the potential value of SessionLock as a countermeasure to sidejacking attacks and FireSheep in particular. Because I believe that the frequency of these attacks will increase as a consequence of the success of FireSheep, I look forward to working with Mr. Adida on this project.

For the purposes of this paper, I provide the following analysis of SessionLock’s mechanisms and functionality. SessionLock uses a shared secret (key) exchanged during an encrypted login (generally via SSL/HTTPS) to maintain control of a user session and to prevent sidejacking. URL fragments (http://www.site.com/page.html#URL_Fragment) are used to maintain the session secret within the client’s browser via javascript; the session secret is never sent unencrypted over the browser. Rather, it is used as the key in Hash-based Message Authentication Code (HMAC) communication between the client and the server. This is how, via javascript and a bit of server-side code, SessionLock is able to secure against session hijacking. Although an attacker authenticated to the same network as a user would still be able to snoop on unencrypted network traffic, the attacker would no longer be able to generate valid HTTP requests for the user’s session.

Hypotheses

• H1: FireSheep will effectively facilitate sidejacking attacks against web application sessions using unencrypted cookies as session tokens.
• H2: Idiocy will effectively facilitate sidejacking attacks against Twitter sessions using 
unencrypted cookies as session tokens.
• H3: FireShepherd will effectively defend against sidejacking attacks (i.e. FireSheep in particular).
• H4: BlackSheep will effectively identify FireSheep instances running on a local network.

Methodology

I conduct the primary experiments as follows: I test FireSheep with Mozilla Firefox in Windows (XP & 7), Linux (Ubuntu), and Mac OSX environments. I attempt to hijack sessions of the following applications: Yahoo Mail, HotMail, Flickr, Twitter, gitHub and Facebook. I will also test the following:
Idiocy: a FireSheep derivative/code-fork which automatically hijacks vulnerable Twitter 
 accounts and posts an educational, self-referencing tweet. FireShepherd: a countermeasure developed specifically to combat FireSheep. FireShepherd 
 floods the network with packets designed to overload and shut down instances 
 of FireSheep running on the same network. BlackSheep: closed-source tool designed to detect the use of FireSheep on a local network. I then provide an overview of defensive countermeasures and their effectiveness. These defenses include HTTPS Everywhere, virtual private networks (VPNs), and secure shell (SSH) tunnels. I conclude with some recommendations for various user groups regarding the best tools and methods available for securing themselves against session hijacking attacks.

Experimentation

All four Hypotheses were proved correct by my experiments and testing. FireSheep, Idiocy, FireShepherd and Blacksheep all operated as expected.

FireSheep

Due to the difficulty of enabling promiscuous mode on most wireless hardware in Windows environments, I performed our testing of FireSheep within OS X (version 10.6.5) and Linux (Ubuntu version 10.10). FireSheep ran successfully in an Apple environment on OSX with an Intel processor and a standard Airport wireless adapter. After much effort, I were unable to run FireSheep successfully in a Linux environment. This is likely due to the fact that FireSheep was developed on and for modern Apple computers and the code has not yet been ported to Linux.

FireSheep, once installed as an add-on in an installation of Mozilla Firefox, operates as a sidebar within the FireFox window.

Traffic is captured over the specified network interface, which must be running in monitor, or promiscuous, mode in order for FireSheep to be able to process packets from other IP addresses on the same network other than its own. Once FireSheep begins processing network traffic, it executes a series of handlers as it tries to identify cookies of interest (i.e. cookies pertaining to the sessions of various websites).

To illustrate how handlers work, consider the following code sample from the handler I wrote for Wikipedia:

<div class="highlight">
register({
name: 'wikipedia.org',
url: 'http://en.wikipedia.org/',
icon: 'http://en.wikipedia.org/images/favicon.gif?2',
domains: [ 'wikipedia.org' ],
sessionCookieNames: [ 'centralauth_Session'] })
</div>

Here the name of the session cookie which is used to authenticate user HTTP sessions to the en.wikipedia.org server is named “centralauth_Session.” I were able to determine the name of the session cookie through an iterative testing process of deactivating cookies and checking the session status. Once I had deactivated the “centralauth_Session” cookie, I had brokenthesession with Wikipedia and thus identifiedthesession token.

Currently, handlers exist for capturing the sessions of the following sites:

• Amazon
• Aol
• Basecamp
• Bit.ly
• Cisco
• Craigslist
• Digg
• Dropbox
• eBay
• Evernote
• Facebook
• Flickr
• FourSquare
• Github
• Google
• LinkedIn
• Match
• Mobileme
• Myspace
• Netflix
• New York Times
• Reddit
• Salesforce
• Scribd
• Slashdot
• Tumblr
• Twitter
• Windows Live
• Yahoo
• Youtube

Idiocy

A simple code fork of FireSheep, Idiocy automates the session hijacking process. It focuses only on hijacking vulnerable Twitter accounts it detects and posting the following tweet, “I browsed twitter insecurely on a public network and all I got was this lousy tweet. http://jonty.co.uk/idiocy-what.”

Idiocy was run successfully on a virtualized instance of Ubuntu Linux 10.10. The host machine was an Intel-based MacBook Pro running OS X v.10.6.5 with a standard Airport wireless adapter.

FireShepherd

FireShepherd, which does not require wireless hardware capable of monitor/promiscuous mode, repeatedly sends garbage packets over the network at regular intervals. These garbage packets are loaded with gibberish characters that successfully halt any instance of FireSheep running on their network. The packers are designed to imitate session authentication packets to facebook but instead of actual cookie values they contain nonsensical characters which cause FireSheep to throw an error (by design) and halt its sniffing operations.

FireShepherd was run successfully on Windows XP and Windows 7. Although FireShepherd does successfully frustrate FireSheep instances on the same server, it does not protect against sidejacking attacks in general. Eric Butler’s description of FireShepherd quoted below:

“To understand how this tool works, imagine your friend gets drunk at a bar and starts shouting his credit card number to everyone within earshot. Knowing he isn’t in his right mind and will likely regret his actions in the morning, you decide to intervene by shouting “LALALA” even louder with the hope that nobody will be able to hear what he is saying. While this may prevent some people from hearing the card number, it won’t stop everyone, and will most certainly upset everyone else at the bar even further.”

BlackSheep

BlackSheep ran successfully on an Intel-based MacBook Pro running OS X v.10.6.5 with a standard Airport wireless adapter. BlackSheep successfully identified instances of FireSheep running on the same network.

Although BlackSheep worked, it required wireless hardware to be operating in monitor/promiscuous mode, an unfeasible resource requirement for most windows users. BlackSheep needs monitor mode enabled because it operates by periodically sending out a spoofed packet with false, unique session information. BlackSheep then needs to listen on the network to see if anyone running FireSheep processes the packet with a known site handler. This works because every time a packet of potential value is identified by FireSheep, it sends a request to the server with the session information it has found in an attempt to find a username and to retrieve the site and profile image thumbnails for its user interface. Although BlackSheep is functional and may prove to be a valuable tool for some, most Windows users will be unable to use BlackSheep without acquiring specialized wireless hardware with Windows-native monitor/promiscuous driver support.

Conclusions and Recommendations

FireSheep is proving itself to be a powerful, easy to use tool for web application session hijacking. The rapidity of such a great number of downloads (nearly a million) suggests that sidejacking attacks via FireSheep will become increasingly prevalent as time goes on and as the code evolves and is ported to various platforms. A version of FireSheep for mobile devices could be an especially powerful weaponization of the sidejacking attack, although finding mobile hardware and drivers to support monitor/promiscuous mode might be difficult (as it is with Windows environments).

Non-Expert Users

Non-expert computer users who wish to protect themselves from sidejacking attacks should consider installing the Electronic Frontier Foundation’s “HTTPS Everywhere” add-on for Mozilla Firefox. This add-on works for many major sites susceptible to sidejacking by FireSheep (or other tools) such as Wikipedia, Twitter and Facebook. The add-on works by forcing HTTPS connections wherever possible. This is possible because many websites offer their content over both HTTP and HTTPS protocols. I tested HTTPS Everywhere as successfully defending against FireSheep attacks on sessions with supported sites.

Expert Users:

Expert users who wish to encrypt all of their HTTP traffic and not just traffic to the sites supported by the HTTPS Everywhere extension should consider implementing either a VPN or an SSH tunnel. I tested both methods as effectively defending against FireSheep attacks. Furthermore, these methods can provide total encryption of all network traffic and can be customized to support more than just HTTP/HTTPS security.

Network Administrators

I strongly recommend that network administrators secure currently insecure open and WEP networks by migrating to WPA networks, preferably WPA2(AES). I believe that the investment in new hardware, if required, is worthwhile for the providers of public wireless networks to ensure the security and privacy of their users. The inconvenience of adding a password to a currently password-less public network could be overcome either by setting the password name equal to the SSID itself, by referencing the password in the SSID name or by posting signs for users to see. While the user isolation provided by WPA(2) would not fully eliminate the risk of sidejacking by expert attackers able to authenticate to the network, this level of security would likely be sufficient to prevent trivial attacks by non-expert attackers via FireSheep.

Web Application/Site Administrators

Although SessionLock may prove a viable stop-gap measure for some website, I will defer further judgment on its viability as a solution until implementing it ourselves. Regardless, all websites which require logins and all Web 2.0 applications that want to protect user privacy and session integrity should begin moving towards implementing HTTPS for the duration of a user’s session, not just at the time of login. Although the overhead involved in doing so can be daunting, for most popular, widely successful web applications, the cost of SSL implantation will increasingly become overshadowed by the expenses of compromised user sessions. A Facebook session, for example, contains a significant amount of sensitive user information. The compromise of such a session and the resulting fear instilled in the user base will become a greater risk to companies than the known costs of migrating to full SSL. In this regard, I expect FireSheep to be successful in its stated goal of pushing content providers towards a Web2.0 that is more pervasively HTTPS.

Future Research

Eric Butler and Ian Gallagher will be speaking at the iSEC Open Security Forum (an information security conference) this December in Seattle, Washington. I look forward to following their work and to monitoring the impact that FireSheep will have on the move towards a SSL Web2.0 future.

References

1. Adida, Ben. “SessionLock: Securing Web Sessions against Eavesdropping,” WWW Conference, April 2008, Beijing, China.

   Paper: http://www2008.org/papers/pdf/p517-adida.pdf
   Presentation: http://adida.net/presentations/2008-04-24-www2008-sessionlock.pdf
   
Source Code: https://github.com/benadida/sessionlock
2. BlackSheep (ZScaler Inc.) FireSheep Identifier: http://www.zscaler.com/blacksheep.html
3. Butler, Eric, and Ian Gallagher. “FireSheep,” A Firefox Extension for Web Session Hijacking. Released 18 Nov. 2010 at the Toorcon 2010 conference, San Diego, California.
   
News Site: http://www.zscaler.com/blacksheep.html
   
Presentation:http: sandiego.toorcon.org<="" a=""Source Code:</http:> https://github.com/codebutler/firesheep
4. Butler, Eric, and Ian Gallagher. “FireSheep, Three Weeks Later: Fallout,” http://codebutler.com/firesheep-three-weeks-later-fallout
5. Chen, Lanxiang; Dan Feng; Zhan Shi; Feng Zhou. “Using Session Identifiers as Authentication Tokens,” Communications, 2009. ICC ‘09. IEEE International Conference on, vol., no., pp.1-5, 14-18 June 2009.
6. Cheng, Kefei; Meng Gao; Ruijie Guo. “Analysis and Research on HTTPS Hijacking Attacks,” Networks Security Wireless Communications and Trusted Computing (NSWCTC), 2010 Second International Conference on , vol.2, no., pp.223-226, 24-25 April 2010.

7. Choi, T., and M. Gouda. “HTTP Integrity: A lite and Secure Web against World WideWoes,” The University of Texas at Austin, Department of Computer Science. Report TR-09-41. Dec, 2009. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.155.2026&rep=rep1&type=pdf
8. Chomsiri, T. “Sniffing Packets on LAN without ARP Spoofing,” Convergence and Hybrid Information Technology, 2008. ICCIT ‘08. Third International Conference, vol.2, no., pp.472-477, 11-13 Nov. 2008.
9. Cooligan, Paul. “ And Protecting Your Wifi Connection – A Few Thoughts And Best Practices.” November 1, 2010.
Podcast http://www.paulcolligan.com/2010/11/01/firesheep-and-protecting-your-wifi-connection-a-few-thoughts-and-best-practices/
10. FireShepherd: A Mozilla Firefox extension to defend against FireSheep attacks via spoofed packet flooding. http://notendur.hi.is/~gas15/FireShepherd/
11. Gray, Patrick. “Risky Business Episode 174: , news and more.” 28th Oct. 2010.
Podcast http://risky.biz/RB174
12. Hamster – SideJacking Tool (Errata Security). BlackHat Conference, 2007, Las Vegas
, Author’s Notes. http://erratasec.blogspot.com/2007/08/sidejacking-with-hamster_05.html
13. Hayes, Rick; Keith Pachulski, and Adrian Crenshaw. “InfoSec Daily Podcast Episode 242: & Apple Virus Threats.” October 25th 2010. 
Podcast http://www.isdpodcast.com/episode-242-firesheep-apple-virus-threats/
14. HTTPS Everywhere: https://www.eff.org/https-everywhere
15. Idiocy: Automated Twitter Account Session Hijacking. Author: Jonty Wareing. Published 27th Oct. 2010.
 http://jonty.co.uk/idiocy
16. Keizer, Gregg. “Is it legal to use at Starbucks?” ComputerWorld. Nov 1, 2010. http://www.computerworld.com/s/article/9194159/…
17. Keizer, Gregg. “Mozilla: No ‘kill switch’ for add-on.” ComputerWorld. Oct 27, 2010. http://www.computerworld.com/s/article/9193420/…
18. Lashkari, A.H.; Danesh, M.M.S.; Samadi, B. “A survey on wireless security protocols (WEP, WPA and WPA2/802.11i),” Computer Science and Information Technology, 2009. ICCSIT 2009. 2nd IEEE International Conference on , vol., no., pp.48-52, 8-11 Aug. 2009.

19. Lashkari, A.H.; Mansoor, M.; Danesh, A.S. “Wired Equivalent Privacy (WEP) versus Wi-Fi Protected Access (WPA),” 2009 International Conference on Signal Processing Systems , vol., no., pp.445-449, 15-17 May 2009.

20. Long, Xiaobo; Sikdar, B. “Wavelet Based Detection of Session Hijacking Attacks in Wireless Networks,” Global Telecommunications Conference, 2008. IEEE GLOBECOM 2008. IEEE , vol., no., pp.1-5, Nov. 30 2008-Dec. 4 2008.

21. Long, Xiaobo; Sikdar, B. “A mechanism for detecting session hijacks in wireless networks,” Wireless Communications, IEEE Transactions on , vol.9, no.4, pp.1380-1389, April 2010.

22. Noiumkar, P.; Chomsiri, T. “Top 10 Free Web-Mail Security Test Using Session Hijacking,” Convergence and Hybrid Information Technology, 2008. ICCIT ‘08. Third International Conference on , vol.2, no., pp.486-490, 11-13 Nov. 2008.

23. Riley, R. D., et al. “Empowering Users Against SideJacking Attacks,” SIGCOMM’10, Sept. 2010, New Delhi, India.
 http://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p435.pdf
24. Saltzman, Roi; Adi Sharabani. “Active Man in the Middle Attacks: A Security Advisory,” IBM Rational Application Security Group. Feb. 2009.
25. Tews, Eric; A. Pychkine, and R.P. Weinmann. “AirCrack-ptw: A history of WEP and RC4,” Technische Universitat Darmstat.
 http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/
26. Ying Wang; Zhigang Jin; Ximan Zhao; “Practical Defense against WEP and WPA-PSK Attack for WLAN,” Wireless Communications Networking and Mobile Computing (WiCOM), 2010 6th International Conference on , vol., no., pp.1-4, 23-25 Sept. 2010

27. Wireshark – Packet Sniffing Software (CACE Technologies) Version 1.4.1.
 http://www.wireshark.org/download.html