CLIENT - SIDE SECURITY
Thesis
Submitted in partial fulfillment of the requirements for the degree of
MASTER OF TECHNOLOGY in
COMPUTER SCIENCE & ENGINEERING – INFORMATION SECURITY
by
HALARNKAR VRINDA NILKANTH
(08IS04F)
DEPARTMENT OF COMPUTER ENGINEERING
NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA
SURATHKAL, MANGALORE-575025
June, 2010
ABSTRACT
Web Browsers are one of the most powerful pieces of client software and have
therefore become prime targets for hacking next to operating systems. Browsers have
users who are not technically savvy who can be lured into tricks using social
engineering traps. Browsers are used to conduct various financial transactions and
hence a successful attack on a browser can have a disastrous impact.
In phase one Firefox extensions are explored as a way of building web
application security testing tools. A SQL Injection Tool and a Dictionary Attack Tool
are built which interact with the internal file system as well as with the web
applications. XPCOM services of Mozilla help in achieving the required
functionalities. With the help our dictionary attack tool we explored username
enumeration vulnerability of web application. If the application is vulnerable it
reveals some valid usernames in the system which can be further used to direct the
dictionary attack.
In phase two, we have explored the threats due to malicious extensions,
considering Firefox browser as our case study. As a proof- of- concept we have
demonstrated the phishing attack and password stealing using malicious extensions.
In accordance with the ethical hacking norms we surveyed the impact of our
malwares in the real world. Finally we propose the security measures to be taken at
the design ,distribution , installation and runtime stages of an extension which will
mitigate the threats to a great extent.
i
TABLE OF CONTENTS
Page No.
Table of contents i
List of figures iv
List of tables v
Chapter I INTRODUCTION 1
1.1 Overview of Browser Extensions 1
1.2 Extension Support in IE and Firefox 2
1.3 Problem Statement 4
1.4 Organization of the Thesis 5
Chapter II RELATED WORK 6
Chapter III XPCOM FRAMEWORK 8
3.1 Mozilla’s XPCOM 8
3.2 XPCOM interfaces 10
3.3 Sensitive XPCOM services 12
Chapter IV SQL INJECTION TOOL 14
4.1 SQL Injection Overview 14
4.2 Tool Design 15
4.3 Working 16
ii
4.4 Results and Analysis
17
Chapter V DICTIONARY ATTACK TOOL
5.1 Username Enumeration Vulnerability 18
5.2 Vulnerability Detection 19
5.3 Design 20
5.4 Working 21
5.5 Results and Analysis 23
Chapter VI PASSWORD STEALING 25
6.1 Overview 25
6.2 Password Management in Mozilla Firefox Browser 25
6.3 Penetrating the Master Password Security 26
6.4 Password Stealer Malware Design 27
6.5 Implementation 28
6.6 Survey of the malware impact 29
iii
REFERENCES 53
Chapter VII PHISHING USING BOOKMARKS 31
7.1 Working 31
7.2 Statistics of phishing attack
34
Chapter VIII
MITIGATION PROPOSAL
8.1 Extension Security Model 35
8.2 Other Security measures
39
Chapter IX CONCLUSION AND FUTURE SCOPE 40
APPENDIX I Current Firefox Extension Testing Methodology 42
APPENDIX II XPCOM Related Technical Terms Used by Mozilla 46
APPENDIX III Firefox Extension Development 48
iv
LIST OF FIGURES
Fig
No. Description Page No
1.1 Browser Helper Object loading IE 2
3.1 Mozilla Backend Architecture 9
3.2 nsISupports Interface 10
4.1 SQL injection using a attack vector 16
4.2 An Example site vulnerable to SQL injection 17
5.1 Dictionary Attack tool injecting attack vectors 22
5.2 Username enumeration Vulnerability : Case 2 22
5.3 Username enumeration Vulnerability : Case 3 23
5.4 FednetBank.com error for invalid login ID & Password 24
5.5 FednetBank.com error for valid login ID & invalid Password 24
6.1 Password Stealing Activity 27
6.2 NoConstraints hosted on Mozilla site 30
7.1 Malware Extension Installation in Firefox 31
7.2 Change of bookmarked Facebook URI 31
v
7.3 SQLite Database after installation and URI change 32
7.4 Facebook Bookmark reverted to original 32
8.1 Security Measures at different phases 36
LIST OF TABLES
Table
No. Description Page No
6.1 Password Stealing Statistics 29
6.2 Phishing Attack Statistics 34
1
CHAPTER 1
INTRODUCTION
A Web Browser is the most commonly used client side application in the world of
Internet technology. Web users perceive browsers as an interface which helps them
consume online services like e-mail, banking and shopping besides browsing the
Internet. Users view the web page the way their browser renders them. Thus Web
browsers have to take care of usability, functionality and at the same time also protect
the clients by providing adequate security.
1.1 OVERVIEW OF BROWSER EXTENSIONS
As the web applications throw more and more challenges and evolve it is not possible
to include all the functionality within the browser itself. Moreover as the demands
vary across user groups, customized browser service allows the application to scale.
Browser extensions have helped in meeting these demands to a great extent. Browser
Extension is a piece of software that allows developers to add functionality to browser
and enhance the user interface. To modify the core browser user experience extension
code is given full privileges. Extensions have full access to browser internals and the
user’s file system. The powerful features of the extensions can be used to build
various utility tools. Extensions have become trusted entities and usually escape the
security checks. Given the current scenario of the current extension systems in
browser malware can be crafted as an extension or an extension may be tampered to
inject malware. In both the cases the effect can be disastrous.
2
1.2 EXTENSION SUPPORT IN INTERNET EXPLORER AND FIREFOX
Most of the mainstream browsers provide support for extensions which are very
popular with the user communities. Internet Explorer, having nearly sixty percent of
the market share, provides support for extensions in terms of Browser Helper Objects.
Browser Helper Objects are in-process Component Object Model (COM)
components—that Internet Explorer loads each time it starts up. Such objects run in
the same memory context as the browser and can perform any action on the available
windows and modules. For example, a BHO could detect the browser's typical events,
such as GoBack, GoForward, and DocumentComplete; access the browser's menu and
toolbar and make changes; create windows to display additional information on the
currently viewed page; and install hooks to monitor messages and actions. Unlike
Firefox Extensions, BHOs are implemented as native binaries.
Figure 1.1 Browser Helper Object loading in IE
Every COM class object has a globally unique identifier known as CLSID. The
browser finds a list of CLSIDs in the registry and creates an in-process instance of
each. As a result, such objects are loaded in the browser's context and can operate as if
they were native components. The browser initializes the object and asks it for a
certain interface. If that interface is found, Internet Explorer passes
3
its IUnknown pointer down to the helper object. The BHO site is the COM interface
used to establish a communication.
BHO can access Document Object Model (DOM) of the rendered page, detect
HTTP connections, make visible changes to browser’s interface or run without any
changes to the interfaces. Malwares like Download.ject, MyWay Searchbar, DyFuCA
spyware have used BHO to perform malice ous tasks. After being installed, the BHO
seldom requires permission before performing further actions making it an in-house
threat to Internet Explorer’s defense mechanism.
Mozilla Firefox, with twenty four percent of market share, has nearly one third
of its users using at least one extension. Among all the browsers, Firefox has used
the extension concept to the greatest success. Mozilla’s official site for add-ons hosts
thousands of add-ons in different categories ranging from appearance to privacy and
security. This can be attributed to its open source nature and the ease with which a
vast pool of Firefox developers can publish their add-ons. With millions of original
add-on downloads, AMO also receives around 100 million update pings. The ease of
use and the additional functionality provided lures number of users to download these
extensions .Apart from official site there are number of other sites which allow add-
ons to be hosted. Firefox Extensions are platform independent. This is due to neutral
nature of technologies like JavaScript and XML which are used to implement them.
Hence a large number of users are it on windows or Linux can use these extensions.
To summarize, we have chosen Mozilla’s Firefox browser for our
case study and development mainly due to the following reasons: (i) Firefox has
nearly twenty four percent of market share(ii)Firefox is open source browser (iii)
Firefox has rich collection of extensions which are open source (iv)Nearly one third
of Firefox users use at least one extension.(v) Firefox is highly popular and trusted
among both Linux and Windows users(vi) Extensions are platform independent.
4
1.3 PROBLEM STATEMENT
The initial work of the project aims at exploring the power of Firefox extensions.
Given that browser extensions can observe all the events in a browser, it is a pretty
good choice for web vulnerability detection. As organizations get serious about
developing secure applications they must develop a plan and framework to make the
development process conducive to producing secure applications. With the increase in
digital infrastructure complexity and interconnection, the difficulty of achieving
application security increases exponentially. The web application vulnerability
detection tools are used to launch security attacks on application, observe and analyze
the responses obtained from the server.
The aim is to build a SQL injection tool and a Dictionary attack tool to penetrate the
authentication system of a web application. Authentication mechanism used by the
website forms the gateway to web resources. Detection of the username enumeration
vulnerability and SQL injection vulnerabilities of the web application can be
systematically used destroy the first line of defense of web resources.
Many extensions interact extensively with arbitrary web pages, creating a
large attack surface that attackers can scour for vulnerabilities. Given the fact that
extensions run with browsers full privileges this can be a dangerous situation .The
next phase of our project focuses at exposing the threats emanating from malicious
browser extensions. The aim is to give a proof- of- concept demonstration of phishing
attack and password stealing using malicious extensions. We demonstrate how easily
user’s privacy and confidentiality can be compromised using extension malware and
social engineering tricks. We also aimed to survey the impact of our malwares in the
real world within the norms of ethical hacking. Mozilla, till now does not have any
concrete extension security mechanism in place. Final goal is to propose the security
measures to be taken at the design, distribution, installation and runtime stages of
Firefox extension which will mitigate the threats to a great extent.
5
1.4 ORGANISATION OF THESIS
The remaining part of the thesis is organized as follows: Chapter 2 discusses the
previous work done in the area of browser security. In Chapter 3 Cross platform
Component Object is discussed in detail. It gives the fundamentals XPCOM
interfaces, which powers the Firefox browser. The interfaces used in the design of
malware are discussed in particular. Chapter 4 and 5 gives detailed design and
implementation of SQL injection tool and dictionary attack tool. Chapter 4 also
describes the username enumeration vulnerability and method of detecting the same.
Chapter 6 and 7 focus on the malware design and the method we used to package the
malware. In chapter 6 password stealing process for Firefox is described in detail.
The current password management activity of Mozilla and the flaws in the same are
detailed out. The chapter 7 describes the phishing process using bookmarks. Our
proposed mitigation strategy is given in chapter 8. Chapter 9 concludes the thesis.
6
CHAPTER 2
RELATED WORK
Web browser security has been the burning issue in the world of cyber Security,
ever since cyber crimes have started causing panic among the internet user
community. The security issues in browser architecture and the protection browser
provides against the web malware are mainly the focal points research in this area.
Jeff Jones(J. Jones 2007) has come up with analysis of Internet Explorer and
Firefox vulnerabilities since Internet Explorer 6 on Windows XP SP2 became
available and Mozilla launched Firefox. The vendor actions and policies in fixing the
bugs over the years have been analyzed. Barth (Barth & Jackson 2009) presented the
security architecture of Chromium. The threat model for browser exploits is defined
in their work and evaluation of how the architecture would have mitigated past
vulnerabilities is carried out .
Malicious JavaScript has been the prime focus of much of the work done on
browser security till now. Hallarker (Hallarker & Vigna 2005 )have proposed the
solution to detect the JavaScript based attacks on browsers by monitoring the
JavaScript code execution. The authors have also implemented auditing system for
JavaScript interpreters. Chander(Chander,Islam,Serikov 2007) proposed to thwart the
JavaScript based attacks like XSS by programmed instrumentation. A unified
framework is proposed which monitors and rewrites the questionable operations in
incoming JavaScript, performs the necessary security checks in line with the security
policies and generates necessary user prompts. The browsers along with DOM
provide primary security mechanisms like sandboxing, same-origin policy, and signed
scripting. The JavaScript in a web page runs in a sandbox hence browser integrity is
not a cause of concern. We are mainly concerned with the extension code which runs
with the same privileges as the browser itself. Louw( Louw, Lim, Venkatakrishnan
2008) have addressed two problems caused by malicious extensions: installation
integrity problem and data security problem. They also proposed the mechanism for
runtime monitoring of sensitive APIs calls. Barth (Barth, Felt,Saxena, Boodman.
7
2009) have surveyed the API requirement of some of the popular extensions and
proposed a new browser extension system, by using least privileges . This extension
system is being used by Google Chrome.
Kals(Kals et.al, 2006) demonstrated the ease of discovering the application-
level vulnerabilities of web applications. A tool named ―Secubat‖ was developed
which automatically analyzes web sites with the aim of detecting SQL injection and
XSS vulnerabilities. To detect SQL injection, Secubat uses error strings and
associates a confidence factor with it. The authors claim the confidence factor to be
the significance of occurrence of the corresponding error string in the web application
response. The values are chosen based on the analysis of the response pages returned
by vulnerable sites. Secubat is implemented as a Windows Forms .NET application in
C# using Microsoft Visual Studio .NET. The tool makes use of crawler component.
The other important SQL injection tool, developed by security compass, as an
extension of Firefox is SQL-inject-Me. This tool works by submitting the HTML
forms by substituting the form fields with attack vectors. The tool does the work of a
QA tester by automating the entry of the attack strings in the forms.
The most widely used password cracking tool with high reliability is Brutus. It
works on the principle of brute force attack. It also has a dictionary component in it.
The tool works only on Windows. Apart from this there are many password crackers
designed for specific applications. None of the previous work have emphasized on
the username enumeration vulnerability.
8
CHAPTER 3
XPCOM FRAMEWORK
The Cross Platform Component Object Module (XPCOM) is a framework which
allows developers to break up monolithic software projects into smaller modularized
pieces. These pieces, known as components, are then assembled back together at
runtime. The goal of XPCOM is to allow different pieces of software to be developed
and built independently of one another. In order to allow interoperability between
components within an application, XPCOM separates the implementation of a
component from the interface. But XPCOM also provides several tools and libraries
that enable the loading and manipulation of these components, services that help the
developer write modular cross-platform code, and versioning support, so that
components can be replaced or upgraded without breaking or having to recreate the
application. Using XPCOM, developers create components that can be reused in
different applications or that can be replaced to change the functionality of existing
applications. XPCOM not only supports component software development, it also
provides much of the functionality that a development platform provides, such as:
•Component management
•File abstraction
•Object message passing
•Memory management
3.1 MOZILLA’S XPCOM
Mozilla boast of being a platform for innovation and experimentation. It
contains an object library of over a thousand objects. The sources of power of Mozilla
applications are XPCOM objects which form a major part of the object library.
Without XPCOM components, an application programmer is trapped within an XML
document, whether it is HTML or XUL. Inside such a document, URLs, HTTP,
SOAP, and WSDL are the only mechanisms out. By adding XPCOM components,
everything opens up dramatically. Components add support for networking,
9
databases, files, and processes — all the meat and drink of traditional software
applications. XPCOM components are available on all platforms where Mozilla runs
and are entirely portable with only a very few exception.
Figure 3.1: Mozilla Backend Architecture
As shown in the diagram the back half of Mozilla is the home of XPCOM
components. The XPCOM and XPConnect technologies rely on various external files;
a registry (a simple database like the Microsoft Windows registry) and type libraries
(component descriptions) are foremost. From a programmer's point of view, the most
interesting part of the XPCOM system are the externally stored XPIDL files, which
contain readable descriptions of all the XPCOM interfaces.
10
3.2 XPCOM INTERFACES
Interfaces allow developers to encapsulate the implementation and inner
workings of their software, and allow clients to ignore how things are made and just
use that software.
3.2.1 The nsISupports Base Interface
This interface is considered to be the mother of all interfaces in XPCOM which
provides solutions to two fundamental issues of object ownership, and interface
querying in component programming for XPCOM developers. In XPCOM, all classes
derive from the nsISupports interface, so all objects are nsISupports but they are also
other, more specific classes, which you need to be able to find out about at runtime.
nsISupports, supplies the basic functionality for dealing with interface discovery and
reference counting. The members of this interface, QueryInterface, AddRef, and
Release, provide the basic means for getting the right interface from an object,
incrementing the reference count, and releasing objects once they are not being used,
respectively.
Figure 3.2 shows the nsISupports interface.
Figure 3.2 :nsISupports Interface
Every interface is assigned an identifier that gets generated from a tool commonly
named ―uuidgen‖. This universally unique identifier (UUID) is a unique, 128 bit
number. Used in the context of an interface (as opposed to a component, which is
what the contract ID is for), this number is called an IID. When a client wants to
11
discover if an object supports a given interface, the client passes the IID assigned to
that interface into the QueryInterface method of that object.
XPCOM uses two other very important identifiers to distinguish classes and
components.
• ―CID‖
• ―Contract ID‖
A CID is a 128 bit number that uniquely identifies a class or component in
much
the same way that an IID uniquely identifies an interface. The CID for nsISupports
looks like this: 00000000-0000-0000-c000-000000000046
A contract ID is a human readable string used to access a component. A CID
or a contract ID may be used to get a component from the component manager. This
is the contract ID for the LDAP Operation component:
"@mozilla.org/network/ldap-operation;1"
The format of the contract ID is the domain of the component, the module, the
component name, and the version number, separated by slashes.
3.2.2 XPCONNECT
When components are accessed from other languages, as they can be in XPCOM,
they use the binary type library to access the interface, learn what methods it supports,
and call those methods. This aspect of XPCOM is called XPConnect. XPConnect is
the layer of XPCOM that provides access to XPCOM components from languages
such as JavaScript.
3.2.3 XPCOM Services
A service is an object of which there is always only one copy. Each time a
client wants to access the functionality provided by a service, they talk to the same
instance of that service. Services provide single point of access functionality. In
12
XPCOM, in addition to the component support and management, there are a number
of services that help the developer write cross platform components. These services
include a cross platform file abstraction which provides uniform and powerful access
to files, directory services which maintain the location of application and system-
specific locations, memory management to ensure everyone uses the same memory
allocator, and an event notification system that allows passing of simple messages.
3.3 Sensitive XPCOM Interfaces
This is list critical XPCOM interfaces used in our implementation.
nsILoginManager
In our implementation we have used nsILoginManager to get an access to host,
username and password. The getAllLogins method of this interface is sufficient
enough to fetch all the logins in plain text logins can also be added or deleted or
modified
nsIPK11Token
Method of nsIPK11TokenDB getInternalKeyToken gives an access to nsIPK11Token
interface which is one of the most crucial interfaces that can be used to penetrate the
master password security. Methods like setAskPasswordDefaults can be used to set
the timeout of master password in case option 2 is set and also helps to set larger
timeout and hence enough time to steal the passwords. Methods isLoggedIn and
checkPassword allow us to listen to the action of entering the master password
during a browser session.
nsIExtensionManager
This Interface represents a system for the installation and management of Extensions,
Themes etc. and is used in the implementation to perform installation and un-
installation of tampered extensions.
13
nsINavBookmarksService
This interface includes changeBookmarkURI method which can be used to change the
URI a bookmark is pointing to without changing the caption visible to the user.
Apart from these there are interfaces like nsIRDFDataSource, nsIHistoryListener,
nsIHttpChannel, nsICookieManager, nsICookiePermission and many other DOM
interfaces which have methods and attributes which can be used easily for malicious
purposes. Listeners can be deployed and every event in the browser can be observed.
14
CHAPTER 4
SQL INJECTION TOOL
4.1 SQL INJECTION OVERVIEW
SQL injection is an attack in which malicious code is inserted into strings that are
later passed to an instance of database Server for parsing and execution. Any
procedure that constructs SQL statements should be reviewed for injection
vulnerabilities because SQL Server will execute all syntactically valid queries that it
receives. Even parameterized data can be manipulated by a skilled and determined
attacker. The primary form of SQL injection consists of direct insertion of code into
user-input variables that are concatenated with SQL commands and executed. A less
direct attack injects malicious code into strings that are destined for storage in a table
or as metadata.SQL Injection vulnerabilities can cause a lot of damage to a web
application. A malicious user can possibly view records, delete records, drop tables or
gain access to your server. It is difficult to detect the tampering programmatically as
the injected SQL code is syntactically correct. Therefore, all user inputs should be
validated and code that executes constructed SQL commands in the server should be
carefully reviewed.
We developed a simple SQL injection vulnerability detection tool which aims at
finding the SQL injection vulnerabilities in a web application. The tool is
implemented as a Firefox extension. This has the following advantages:
1. Extension can observe all the events in browser.
2. Extension have access incoming web contentment as well as internal file
system
3. In Firefox APIs of XPCOM are available for an extension which simplifies the
design and reduces the development cost.
4. Less discrepancy in perception by a web user and the extension.
15
4.2 Tool Design
Modules
1. User Interface Module: This contains GUI for user to launch an attack and to
maintain attack string library.
2. Database Access Module: Provides functions to access, insert or delete attack
strings in the storage.
3. Attack launcher and response handler: Takes the input from user interface
and database, forms and sends request with attack string to a web application
and reads the response.
Database design
We use Slate database of Firefox. SQLite is an ACID-compliant embedded
relational database management system contained in a relatively small (~225 KB) C
programming library. The source code for SQLite is in the public domain.
There are two tables:
1. injector(in_cod INTEGER PRIMARY KEY AUTOINCREMENT, in_string
VARCHAR (255))
2. errorstr(in_cod INTEGER PRIMARY KEY AUTOINCREMENT,in_errorstr
VARCHAR(255) )
The database is created when the extension is installed for the first time and is
persistent. Subsequent installation does not change the file .To reinstall the database
delete ―C:\Documents and Settings\<user>\ApplicationData\Mozilla\Firefox\ Profiles
\cwvm08dv.test2\SQLinhecctionDB‖ and install the extension. cwvm08dv.test2 is our
profile directory.
The tool is developed on Firefox 3.6.3.
16
4.3 Working
1. The tool when loaded in the browser reads the web page rendered in the browser.
2. Input elements used for authentication in web page are identified. SQL injection is
possible in these fields.
3. Connection is made to the database and attack strings are retrieved.
4. User is asked to choose from the authentication parameters identified by the tool.
5. Authentication parameters’ values are set to an attack string in the database.
6. A query string is formed with the required parameters and sent to the server.
7. Responses are read and stored in the local file .
8. Response pages are analyzed and checked for the presence of error strings.
9. Steps 2-8 are repeated till all the possible attack string pairs are tried.
Figure 4.1: SQL injection using a attack vector
17
Figure 4.2 An Example site vulnerable to SQL injection
4.4 Results and Analysis
The tool was developed to study the XPCOM requirement for building vulnerability
detection tools. For the testing purpose we executed the tool on few sites and found
the following two sites vulnerable to the SQL injection attack.
1)http://www.oralcareindia.com
2)www.chowgules.ac.in
The Fig 4.2 shows the vulnerability detection of http://www.oralcareindia.com site.
The site allowed access to one of its member’s profile which most probably is the first
record in the database. In case of www.chowgules.ac.in the site only gave the database
server related information in response.
XPCOM provides useful services to send asynchronous requests to web server. The
data storage interfaces help us to build large database of attack strings.
nsIHttpChannel interface allows for the modification of HTTP request parameters and
the inspection of the resulting HTTP response status and headers when they become
available.
18
CHAPTER 5
DICTIONARY ATTACK TOOL
Authentication plays a critical role in the security of web applications. When a user
provides the credentials to authenticate and prove identity, the application assigns the
user specific privileges to the system, based on the identity established by the supplied
credentials.
A dictionary attack uses pre-computed wordlists like dictionaries to try to
authenticate on the web applications by trying number of combinations of these words
as usernames and passwords.
The tool tries penetration of the authentication system using predefined lists of
usernames and passwords. If penetration into authentication system fails, the next
goal is to detect the username enumeration vulnerability.
5.1 Username Enumeration Vulnerability
This vulnerability is due to the mis-configuration or design decision of authentication
mechanism. If the application is vulnerable it reveals the valid usernames in the
system. This helps the hackers to launch a dictionary attack or brute force attack
against the application using enumerated valid usernames. Consider a web application
requiring user authentication before accessing its resources. The most common form
of authentication is entering username and password on login page. If wrong
credentials are entered, a vulnerable application will explicitly inform the user
whether the password entered is wrong or the username. This is bruteforcable type
username enumeration vulnerability as dictionary attack can be executed to exploit
the responses of the application. The other type of username enumeration
vulnerability is known as dumpable type. In this the targeted web application just
gives a dump of valid usernames may be by accessing exposed config files (i.e.
users.conf.xml) or without being logged in allows the visitors to view the existing
usernames. In brief the vulnerability exists because the response from web
19
application or web server when we provide a valid username is different than when
we use an invalid one.
5.2 Vulnerability Detection
Check for the response for various combinations
1. Valid username and password
2. Invalid username and Invalid password
3. Valid username and Invalid password
Response Analysis:
Case 1:
Input: Valid username and password
Response:
I. Successful authentication
Username and password match and user is authenticated
Case 2:
Input: Invalid username and Invalid password
Response:
I. Invalid username. ―Please try again or the user is not active or user is
not recognized.‖ The authentication failure is due to invalid username.
The password may or may not be correct
II. Unsuccessful authentication
In this kind of response there is no clear indication of reason of failure.
Username or password or both may be incorrect
Case 3:
Input: Valid username and Invalid password
Response:
I. Invalid password: Password Incorrect.
It gives an indication that username is valid and password is incorrect.
20
II. Unsuccessful authentication
In this kind of response there is no clear indication of reason of failure.
Username or password or both may be incorrect
After dictionary attack, though type 1 and type 2 indicates failed attack, the
responses obtained can be used as a guideline for further attack. Response I in type 1
and 2 gives a proof of username enumeration vulnerability. The web application is
clearly stating the authentication parameter that has failed. Thus we can easily
enumerate the valid username of the site. This can be used as input to launch further
dictionary attack.
5.3 Design
Modules:
1. User Interface: This contains GUI for
I) user to specify attack settings. User can choose single/multiple
username/password combinations.
II) username/password dictionary entry
2. Database Access Module: Provides functions to access, insert or delete attack
strings in the storage.
3. Attack launcher and result handler: Takes the input from user interface and
database, forms and sends request with dictionary username and password
strings to a web application and reads the response.
Database Design:
Username dictionary table structure:
bdata_user (in_cod INTEGER PRIMARY KEY AUTOINCREMENT,in_username
VARCHAR(255))
21
Password dictionary table structure:
bdata_pass(in_cod INTEGER PRIMARY KEY AUTOINCREMENT,in_password
VARCHAR(255) )
The tool is developed on Firefox 3.6.3
5.4 Working
Following steps explains the default working (multiple usernames, multiple
passwords) of the tool:
1. The tool when loaded in the browser reads the web page rendered in the browser.
2. Input elements used for authentication in web page are identified. SQL injection is
possible in these fields.
3. Connection is made to the database and username/password dictionary values are
retrieved.
4. User is asked to choose from the authentication parameters identified by the tool.
5. Username authentication field and password authentication field are set to a value
in the corresponding dictionary.
6. A query string is formed with the required parameters and sent to the server.
7. Responses are read and stored in a local file.
8. Response pages are analyzed. In case of failed attempt, username enumeration
check is done.
9. Steps 2-9 are repeated till all the possible username-password pairs in the
dictionary are tried.
Single username/password (multiple or single) can be used for well directed
attempts. This will be used when attacker has a fair idea of the usernames or when
usernames enumeration vulnerability is detected after analysis of the responses and
the valid usernames of the application are enumerated by analyzing further.
22
Figure 5.1: Dictionary Attack tool injecting attack vectors
Figure 5.2: Username enumeration Vulnerability - Case 2
23
Figure 5.3: Username enumeration Vulnerability - Case 3
5.5 Results and Analysis
The tool was developed on similar lines as SQL injection tool. For testing purpose we
included dictionary of common Indian names and commonly used passwords in the
tool and tried it on several sites. It was also tried on around 23 banking sites. No
direct penetration was made but username enumeration vulnerability was found on
two sites :i) http://www.chowgules.ac.in
ii)https://www.fednetbank.com
Figures 5.2. and 5.3 show detection of Username Enumeration vulnerability for
http://www.chowgules.ac.in site . In fig 5.2 the input is invalid username and invalid
password. The web site clearly shows the message ―username invalid‖. For case 3
input i.e. valid username, invalid password the error message is ―password invalid‖.
24
Figure 5.4: Fednetbank.com error for invalid login ID & Password
Figure 5.5: Fednetbank.com error for valid login ID & invalid Password
Figures 5.4 and 5.5 show Fednetbank.com, the internet banking site of federal
bank is also susceptible to username enumeration. In fig 4.4 the input is invalid
username and invalid password. The web site clearly shows the message ―invalid
login or password‖. For case 3 input i.e. valid username , invalid password the error
message is ―invalid password . You are left with 3 more attempts‖. This gives clear
indication of username being valid.
25
CHAPTER 6
PASSWORD STEALING
6.1 Overview
Besides increasing the browser functionality and usability a malicious or vulnerable
extension gives attacker the ability to penetrate through the browser’s defense
mechanism. With the increase in the popularity of the browser extensions, the
unrestricted access enjoyed by the extension code has become a cause of concern.
Extension’s vulnerabilities can be exploited by attackers to intrude into user’s privacy,
confidentiality and browser’s integrity.
This module of the project explores the threats emanating from the malicious
extensions by crafting one.
The implementation of malware extension has allowed in getting a deeper
insight into (i) the scope of the threats posed due to full privileges of the extension
code. (ii) the gravity of the situation as the malwares can be developed with low
development cost and efforts (iii) Mozilla’s lack of extension security system (iv) ease
of malware injection and piggybacking.
The two important criteria followed in the malware design are:
1. A naïve user would not become aware of the malicious activity.
2. After carrying out the malicious activity, no trace of it is left. Hence Browser
forensics if carried out would not get any clue.
The first malware, Password Stealer’s aim is to steal the passwords from the database
in the Firefox browser.
6.2 Password Management in Mozilla Firefox Browser
Mozilla comes with built in password manager to remember, store and autofill the
usernames and passwords in the following database file under user profile:
1) key3.db – This file stores a copy of the encryption key used to encrypt the saved
passwords.
26
2) signons.txt, signons2.txt, or signons3.txt – These files store the saved passwords
and are in the form of text files containing the encrypted passwords and logons. The
signons.txt file is from early versions of Firefox 2 and signons2.txt is used in Firefox
version 2.0.0.2 and later. Firefox 3 or later uses the signons3.txt file.
Mozilla provides an optional higher level of security to the encrypted
passwords using master password. If user has to set a master password than any query
to password storage checks for the entry of the master password in the browser
.Stored password can be retrieved only if only when a valid master password is
available.
The master password is not stored anywhere. The master password is used to
decrypt the encrypted data associated with a known plain text string. So for correctly
entered master password decrypted data matches. Recovery of master password is
impossible. Hence master password is considered as a secure way of storing the other
password.
6.3 Penetrating the Master Password Security
The preference configuration setting for security.ask_for_password property can take
the following values:
0: This is the default preference setting. After the first use of the password
database, it remains open for further retrievals during the browser session.
1: User has to enter the master password every time any password is to be
retrieved or stored in the database.
2: The password authentication remains valid for next n minutes. Value of n can
be configured by the user.
If option 0 or 2 is set, we have a certain time duration during which password
database is open for retrieval of records. Password stealer malware works during this
vulnerable period and retrieves the password. In case of option 1, there is no way of
retrieval, without violating the first criteria of design.
27
6.4 Password Stealer Malware Design
Figure 6.1 Password Stealing Activity
Master
Password set?
Is time
up?
Delay=60ms
SSSi
ssig
non
s3.t
xt
Retrieve the
passwords
Post Password records
Is time
up?
Delay=60ms
No
No
No
Attacker’s
Server
Are the records
already posted?
Records
Yes
Yes
Yes
Yes
Is master
password
entered? No
Yes
No
Signon3
28
Case 1: No master password is set
1. Retrieve the passwords directly from password storage and post it to the
attacker’s server.
2. After a delay of 60 ms repeat step 1, this time checking for the new password
records.
Case 2: Master password is set
1. Check if master password is entered. If yes retrieve the password records
directly from password storage and post to the attacker’s server else wait for
60ms and execute step 1 again.
2. After a delay of 60 ms repeat step 1, this time checking for new password
records.
6.5 Implementation
Malware makes use of nsILoginManager and nsIPK11TokenDB XPCOM APIs.The
details of these interfaces are given in chapter 3. The saved passwords are retrieved
with the help of services of nsILoginManager. Malware senses the setting of master
password using checkPassword methods of nsIPK11TokenDB interface, and entry of
the master password using isLoggedIn method.
Packaging:
Password stealer file is hidden in another non malicious extension, NoConstraints.
NoConstraints is designed to remove constraints imposed by a web application. It has
the following functionalities:
Allows user to enable right click
Allows viewing of password in plain text.
Allows saving of password from sites which usually disable the save option in
browser
29
NoConstraints is piggybacked with password stealer .xpi file. Once
NoConstraints is installed, it initializes the installation of password stealer. After a
restart password stealer gets activated.
Malware removal
Seven days expiry time is set for the malware. So seven days after installation,
password stealer is uninstalls itself. The un-installation process is clean and leaves no
trace of the malware.
6.6 Survey of the malware impact
6.6.1 Results on the Internal Server
We hosted the tampered NoConstraints on our internal server
http://isea.nitk.ac.in/addons/ to survey the severity impact. Following are the statistics
we obtained with the malware attack using our internal server for duration of 12 days.
Table 6.1: Password Stealing statistics
NoContraints
piggybacked with
password stealer
Count
Downloads
Successful installation
Successful uninstall
Username /Password
collected
48
40
8
21
30
6.6.2 Results on the Mozilla Site
NoConstraints addon is hosted on the official Mozilla site https://addons.mozilla.org
with the malware(without calls to post method). It has passed all the initial validation
tests. . From 6 june 2010 to 28th
june 2010 there are 61 downloads.
Fig 6.2: NoConstraints hosted on Mozilla site
31
CHAPTER 7
PHISHING USING BOOKMARKS
7.1 Working
The goal of second malware extension was to silently change the bookmark URIs.
We further used this function to give a proof of concept demo of a phishing attack for
the popular sites : gmail, yahoo, facebook and Indian railways ticket booking site.
First we created a hit list of some of the popular sites. We built a phishing site
that hosted login pages of the sites in the hit list and hosted it on our server. Our
malware extension, when loaded in the browser scans the bookmark to check if login
pages of any of the sites in the hit list are present. If hit listed site is found in the
bookmarks, it will change the URI to point to the page on our phishing site. The link
shown to user will not change. When user clicks the tampered bookmark link she will
be directed to the page hosted on our site. When user signs-in, the credentials are
grabbed and stored on our server. The user is either redirected after stealing the
credentials or error page is displayed giving an illusion of authentication failure. Once
user visits the phishing site the URI in bookmarks is reverted back to point to the
genuine link.
The extension also listens to the bookmark addition event. If the URI of the
added bookmark is same as one in the hit list then it is changed to point to page on our
server. The services of nsINavBookmarksService and nsINavBookmarkObserver
interfaces used for the implementation.
We used one of the most popular Firefox Extension in the Bookmarks
category, SmartBookmarks, as the carrier. The installation process can be made silent
if required. Once all the sites in the hit list visited or 7 days after installation are
passed, the malware automatically uninstalls itself.
32
Figure 7.1: Malware Extension Installation in Firefox
Figure 7.2: Facebook Bookmark pointing to http://www.isea.nitk.ac.in/addons/facebook
33
Figure 7.3: SQLite Database after installation and URI change
Figure 7.4: Facebook Bookmark reverted to original
34
7.2 Statistics of phishing attack
Table 7.1: Phishing Attack Statistics
Bookmark Phishing Count
Downloads
Successful installations :
Successful uninstall
No. of Phishing Site hits :
Username /Password collected:
25
24
7
35
35
35
CHAPTER 8
MITIGATION PROPOSAL
The demonstrated attacks exposed easy exploitation of security vulnerabilities of one
of the most trusted applications in the internet world. Malicious extensions can have
two severe impacts. A Malicious extensions may (i) alter the code base of the browser
(ii) intrude the privacy of the user. The ease with which we could carry out the attacks
and get the confidential data shows the gravity of the problem and demands the need
for Browser Extension security Model.
8.1 Extension Security Model
We theoretically propose security model for the Firefox browser. In Firefox
the security enhancement features can be introduced at following stages:
1. Development of extension
2. Distribution of extension and browser
3. Execution phase (install and runtime) of an extension.
The Malicious Extensions may be written intentionally like the ones which we
crafted or may result due to injection of malicious code into an already installed
extension. The former case can be caught at the distribution phase. In later case the,
attacker exploits the fact that no integrity check is done after the installation process.
Hence we need execution level mitigation. For comprehensive solution the security
checks have to be introduced at all the above stages.
36
Figure 8.1: Security Measures at different phases
8.1.1 Development Phase
Each XPCOM API and its methods have to be categorized according to the
sensitivity of their operations. The categorization can be done per the security ratings
given in by Barth(Barth, Felt, Saxena, Boodman. 2009) with due attention to
escalation of privileges. The extension should be given the least possible privileges.
This will control the damage in case the code is compromised at any time later. All
the extensions do not require access to highly sensitive XPCOM interfaces. Even if a
sensitive API is used by an extension, the methods actually called may require lower
privileges.
We suggest the following ways to increase the trust level of an extension:
API Registration: The structure of the extension code can be altered to
include a mandatory file which will contain declaration of XPCOM interfaces to be
Development
•API Registration: Declare the XPCOM API requirement of the code.
•Code Signing :The extension should be signed by the author
Distribution
(At the Official Site)
•Validate the code;
•Review the extensions e demanding sensitive APIs thoroughly ; Correctly analyse the privilege requirement
•Certify the extension based on review results No Cert;Cert(L1);Cert(L2)
Execution
•Installation: verify the certificates as per the browser mode
• Runtime Monitoring : Monitor the XPCOM calls at the runtime
37
used in the extension code. Such registration can help in the Firefox extension review
process carried out on the official Mozilla site.
Signing of the extension: This should be made mandatory so that no
tampering of code is done at a later stage and the author is verified.
8.1.2 Extension hosting and distribution
Currently the Firefox extensions are officially hosted on the AMO site. Code
validation and review is carried out before making the extensions public. We suggest
the following additional checks in the process.
Automatic Code Validation: Currently this process is carried out on Mozilla
site and includes JavaScript tests, setting tests, and checksum tests. This should
include the matching of API declaration and actual usage in the extension code. Any
discrepancy in this should be considered as critical and brought to immediate attention
of the author .Currently piggybacking of any files is allowed in the xpi file.
Piggybacked xpi files should also be validated.
Extension Review: The editor’s review process done by Mozilla can be made
more stringent for extensions demanding highly sensitive XPCOM APIs. More
sensitive APIs authors demand, more the days they can expect the extension to be in
the sandbox. This will discourage developers from simply demanding for critical
functionalities. After thoroughly reviewing each interface and the method used and
determining the sensitivity of the operations, the extension code should be certified.
The certification can be of different levels, for example cert (L1) indicates the use of
highly sensitive operations in the extension code. No certification will indicate either
malicious use of interface methods or inability of the author to justify the code when
demanded by the reviewer. Extensions which are not certified can be retained in the
sandbox. At the end of the process, the certificate of the extension should indicate
the sensitivity of the operations to be carried out by the extension.
38
8.1.3 Browser Distribution
Browsers like Mozilla Firefox have two important functionalities (i) Provide
features allowing naïve users to carry out day-today online transactions and browsing
activity (ii)provide development platform which allows developers to test their code.
The users of browsers vary from a security experts to illiterate person. To meet such
varying demands and at the same time to protect user’s confidentiality, integrity and
privacy, the browsers have to follow the operating system’s principle of multiple
modes and integrated security levels in different modes . Even though Firefox has
profiles and private browsing mode, these features are rarely used. The key is to
increase the awareness about the user modes by allowing authorized use of browsers.
In case of Firefox we can have two significant modes:
Developer’s mode This is similar to the root user of an operating system in
terms of privileged access and quite opposite to current debug mode. In this mode all
the critical XPCOM interfaces should be accessible. This is the mode extension
developers will use to debug their extensions. The users of this mode are assumed to
be smart enough to take care of the security issues. All the signed or unsigned and
experimental add-ons or non-certified extensions we described above should be
allowed to be used in this mode. The extensions execute with full privileges in this
mode.
Naïve user’s mode in this mode can install only extensions certified by
Mozilla. Along with other checks done during installation an installation procedure
should (i) Verify the author’s signature (ii) Check for the extension certificate.
Installation should fail in case of any discrepancy. User should be made aware of the
author’s rating and the certification level. At the time of installation the signature
should be verified and the XPCOM interfaces requirement should be checked. If the
critical XPCOM interfaces are demanded then extension certificate should match with
the demand.
39
8.1.4 Execution
Installation
This will differ according to the browser modes. In the Naïve user’s mode verification
of certificates has to be carried out as mentioned in section 4.1.3. The integrity check
should be done using by verifying author’s signature. Installation should not proceed
if any discrepancy is found. In developer’s mode no strict restrictions are imposed.
User should be warned of uncertified extensions but installation should proceed if
user authorizes.
Runtime Monitoring of Extensions
Code signing and Mozilla certification will expose most of the malwares. But
extension may be injected with malicious code after installation. This has been
demonstrated in [2]. Authors have also proposed a solution in terms of runtime
monitoring of the XPCOM calls based on policies. The API registration we have
proposed can aid in formulating the policies for runtime monitoring. Runtime
monitoring will keep a check on extension code and prompt user if extension code
tries to elevate the privileges during execution.
8.2 Other Security measures
Antivirus softwares should evolve to trap the browser malware as it can cause damage
equivalent to the operating system malware. As the browser forensic techniques
improve we can look forward to anti-malware commercial products specially
designed for browsers.
40
CHAPTER 9
CONCLUSION AND FUTURE SCOPE
The project focuses the crucial area of client side security. The confidentiality and
privacy issue of millions of internet users is at the mercy of browser security. The
project has in particular addressed the security issues of Firefox extensions.
Extension code is given full access to the browser resources. The XPCOM
interfaces used by browser code are also available to extension. Using these interfaces
we built two security testing tools, SQL injection tool and Dictionary Attack tool. We
also show how the responses of dictionary attack can be used for username
enumeration vulnerability detection which in turn can be used as feedback to
Dictionary attack tool.
As the XPCOM can observe all the events in browser, interface with incoming
data as well as internal file system, powerful code snippets can be built. Such a high
privilege code along with lack of concrete extension security model provoked us to
explore the malicious side of the extensions.
Extensions are considered to be safe by the users as is indicated by more than
a billion downloads of extensions on Mozilla site. Our proof-of-concept
demonstrations exposed the vulnerabilities of the extension mechanism. We were
successful in crafting password stealer malware even for browser with master
password security. The easy way of changing the bookmark URIs allowed for
successful phishing attack. The statistics of the data collected by us after the
successful attack reveals the gravity of the situation as millions of users who trust
extension code blindly are at risk.
We have proposed secure measures to be introduced at development,
distribution and execution phases. This can solve the security problems of
intentionally designed malware extensions as well as compromised extensions.
Prominent use of multiuser policy in browsers will help developers as well as naïve
users. Of course, more research is needed in formulating the policies for actual
41
implementation with less overheads and tolerable delays in extension development,
release and execution.
Scope for Future Work
Dictionary attack tool can be further enhanced by creating a result analysis module
which performs content diff, uses the feedback from username enumeration and
launches a well directed attack.
The security policies suggested in chapter 8 can be implemented and performance
analysis can be carried out. Some of the policies like checking for API registration
during installation and runtime monitoring of APIs can be done by modifying the
browser code.
The extension vulnerabilities of the latest browser, Google Chromium can be
studied and exploited to launch attacks.
42
APPENDIX I
Current Firefox Extension Testing Methodology
Fig 1: Addon Transition
The following is the current add-on testing and reviewing methodology as given on
the Mozilla site (https://addons.mozilla.org/en-US/developers/docs/policies/reviews):
Sandbox Review System
New add-ons submitted to the site and hosted by Mozilla are marked as
experimental by default, requiring the user to indicate their understanding that the
add-on has not been reviewed by an Editor and may harm their computer. After an
experimental add-on is installed, no updates are sent to the user until the add-on is
reviewed and public. The add-on remains in the SANDBOX till it is reviewed and
made public.
Authors of experimental add-ons can request Editor review by nominating
their add-on for public status through the Developer Tools provided. The add-on will
then go into a queue of other nominated add-ons, awaiting review .
43
Testing Methods & Common Issues
Mozilla-hosted add-ons are reviewed by the AMO Editors, a group of talented
developers that volunteer to help the Mozilla project by reviewing add-ons to ensure a
stable and safe experience for users.All add-on submissions that wish to be public
must be reviewed by an Editor. As part of this process, an Editor will review your
add-on's source code and any changes that have been made since the last version, if
applicable. During the review, the Editor will look for common issues, including:
JavaScript namespace pollution - the most common reason for being retained in
the sandbox. Be sure to wrap your loose variables.
remote JavaScript execution or injection
remote XUL
synchronous XMLHttpRequests
obfuscated code
binary components or executables
inclusion of third-party software
errors generated in the Error Console
memory leaks
possible conflicts with other add-ons
All add-ons are tested in a virtual machine to allow the editor to install the add-on and
test the user experience without damaging their systems. Many of the above
restrictions are tested automatically by an extension scanner that will flag suspicious
add-ons for Editor review.
Prohibited Add-ons
According to Mozilla site the following practices are not permitted, even for
experimental and self-hosted add-ons:
Conduit-based toolbars without explicit pre-approval
Add-ons that embed known spyware or malware
Illegal and criminal add-ons, such as click fraud generators, warez download and
directory assistants, child pornography finders, etc.
44
Add-ons whose main purpose is to facilitate access to pornographic material, or
include references to this material in their descriptions
Add-ons that, upon installation, auto-install or launch installers of non-Firefox
software
Add-ons that provide their own update mechanism for chrome-privileged
resources
Add-ons that make changes to web content in ways that are non-obvious or
difficult to trace by their users.
Post-Review Scenario
After an Editor has reviewed your hosted add-on, a decision will be made about your
add-on's acceptance into public, non-experimental status. There are several possible
outcomes of this review:
The add-on can be pushed public. If your add-on met all of the criteria and the
Editor feels it's ready for primetime, the add-on may be made public and users will be
able to download the add-on without restrictions and receive updates after installation.
You will receive an email informing you of this status change. Only the latest version
of your add-on will be pushed public; older versions that were not reviewed will
remain in the sandbox. New versions to public add-ons still require Editor review, as
described below.
The add-on can be retained in the sandbox. If there were some problems with add-
on, it will be held in the sandbox and developer will receive an email with the Editor's
comments. After addressing these concerns, developer may re-nominate add-on for
review. Editors will check to see if their previous requests were addressed, so re-
nominating add-on without changes will likely lessen the add-on's chances of being
public.
The Editor may request additional information from developer. If the Editor
needs additional information about add-on in order to process the review, he or she
will request information from the developers, which will send an email with
information on how to respond with the requested details.
45
The add-on may be escalated for super-review. If add-on has potential
copyright/trademark violations, has binary or obfuscated components, or has other
issues that need special attention, the Editor may request that a Senior Editor or
Administrator look into their concerns. This does not alter the status or position in the
queue of add-on, but the action the super-reviewer takes likely will.
Updates to Public Add-ons
New versions of public add-ons are kept in the sandbox but automatically added to a
queue for Editor review. An Editor will review the new version, focusing on the
changes made since the last version. The potential outcomes of the review are the
same as for new add-ons listed above.
Self-hosted Add-ons
Add-ons listed on the website that are self-hosted do not undergo review, but are
expected to comply with policies marked as applicable to all add-ons. Additionally,
self-hosted add-ons are not permitted to link directly to any file as their homepage.
46
APPENDIX II
XPCOM Related Technical Terms Used by Mozilla
binding. A binding is an interface written down in a particular programming
language. In Mozilla, a binding is either an ECMAScript interface stated in the
W3C DOM standards or an XBL binding.
class. The only classes in Mozilla are the component classes of XPCOM. Each
class is used to create zero or more objects. JavaScript 2.0 (ECMAScript 1.4)
will have class definitions of a different type, but JavaScript 1.5 does not have
these.
component. A component is a thing with unique identity within the XPCOM
system. It is a class with a CID (a component identifier) and a matching
ContractID (like @mozilla.org/test;1), or it is an interface with an IID
(an interface identifier). Because interfaces can't be used without a concrete
implementation but classes can, classes are thought of as the only real
components.
interface. An interface is a set of access points to an object. XPCOM
interfaces are the only interfaces in Mozilla. Any object that supplies those
access points is said to implement that interface. Each XPCOM object and
XBL binding implements zero or more XPCOM interfaces; JavaScript objects
may also implement XPCOM interfaces.
library. The Mozilla Platform has a number of dynamically linked libraries,
but those libraries are of no particular interest to the application programmer.
General-purpose JavaScript scripts may informally be called libraries. Type
libraries are data files that define XPCOM interfaces. These are created when
the platform is compiled and automatically used by XPConnect.
module. XPCOM components in the Mozilla Platform are grouped into
modules, but this is only obvious to developers of the platform. Modules have
no meaning to application programmers, unless a whole new XPCOM module
is being created.
47
object. Mozilla contains XPCOM objects and JavaScript objects. An XPCOM
object is of a given class type and implements one or more interfaces. A
JavaScript object may be anything from a simple data structure to a complex
host object. JavaScript host objects are either XPCOM objects or Java objects.
package. A group of related files installed in Mozilla's chrome is called a
package. A package has a name that matches a file system directory name.
48
APPENDIX III
Firefox Extension Development
Introduction
Extensions are the best way of increasing the browser functionality. Firefox, has a
much simpler structure than other full-featured browsers as it did not aim to be an all-
in-one browser that can satisfy everyone. Instead it used extensions for this purpose.
The required features in a standard browser like fine-grained tab controls, mouse
gestures, extensive toolbars and buttons, a feed reader, integration with a variety of
web applications, or sophisticated tools to assist with web design, all unlike other
browsers come as extensions to Mozilla’s Firefox. Till date Mozilla’s site boasts of
1,996,593,956 add-ons downloads and 130,783,578 add-ons in use.
Add-ons Manager
Fig 2: Add-ons Manager
The Firefox Add-ons manager provides a GUI to user to easily use the add-ons. Add-
on term is used to mean add-on or and extension or plug-in in this document.
49
The Add-ons Manager handles the following tasks:
Safely installs and uninstalls add-ons
Makes sure add-ons are compatible with the version of Firefox being used
Manages a whitelist of sites trusted for installing add-ons
Helps troubleshoot add-ons by disabling them and offering a safe mode
Confirms and runs updates
Provides access to add-ons' settings dialogs
Provides access to add-ons' support sites.
List of essential files in an extension
Consider building a sample HelloWorld extension. The following are the essential
files:
chrome.manifest : Informs Firefox about location of chrome files are and what to do
with them.
install.rdf: The description file for the extension ("Install manifest"):
overlay.xul: The file describing UI elements to add to the browser window
overlay.js: The file with scripts to run in the browser window
overlay.dtd: Contains translation for text string codes in overlay.xul
hello.dtd: Contains translation for the strings in hello.xul
overlay.css: Helps to adjust appearance of UI elements with CSS
hello.xul: The file describing the UI of the new window
[email protected]: A pointer to extension files.
Extensions usually modify an application's UI ("chrome") and behavior by
providing overlays to already existent windows/documents. Those overlays are a part
of the extension's content package (content provider). Most extensions also have one
or more locales and skins. The UI is developed using XUL.
50
General structure of extension folder :
helloworld/
chrome.manifest
install.rdf
content/
overlay.js
overlay.xul
hello.xul
locale/
en-US/
overlay.dtd
hello.dtd
skin/
overlay.css
The folders are named "content", "locale" and "skin", and all should follow the\is
convention. Files inside those folders may be named anything.
(except chrome.manifest and install.rdf).
Registering your extension in the Extension Manager
With Firefox closed, create a "pointer" file with the same name as your extension's ID
in profile folder/extensions/ and edit it so that it contains the path to your folder
containing install.rdf and chrome.manifest files. E.g. helloworld's ID
is [email protected] and we would like to register it
in X:\Dev\helloworld\ (i.e. there isX:\Dev\helloworld\install.rdf file etc.). Just put a
single line into the file at this path: profile
Folder/extensions/[email protected]
X:\Dev\helloworld
Start Firefox, and check that your extension is installed. Then test it.
Development cycle
Once you have registered your extension following the steps above , if set
the development preferences are set, the development cycle will be like this:
51
1. Edit your extension files.
2. Reopen the window(s) that modified files apply to, or use Reload chrome
feature of Extension Developer Extension.
If you changed chrome.manifest, you'll have to restart.
If you changed install.rdf, you need to touch the extension folder specified
in your "pointer" file (update its Last modified time) and restart.
The xpi file for release can be created without much efforts using extension
developer’s extension listed below.
Development extensions
These extensions may help you with your development.
DOM Inspector, used to inspect and edit the live DOM of any web document or
XUL application (Firefox and Thunderbird)
Venkman, a JavaScript Debugger (Firefox version, Thunderbird version)
Extension Developer's Extension a suite of tools for extension development
(Firefox)
Console enhanced JavaScript console (Firefox version, Thunderbird version)
Javascript Command for writing/testing javascript on Firefox windows
Chrome List navigate and view files in chrome:// (Firefox version, Thunderbird
version)
Chrome Edit Plus a user file editor (Firefox and Thunderbird)
Add-on Builder a web-based application that generates an extension skeleton
(Firefox, Thunderbird, and others)
Firebug a variety of development tools (Firefox)
Chromebug combines elements of a JavaScript debugger and DOM (Firefox,
"kinda works for Thunderbird")
52
MozRepl explore and modify Firefox and other Mozilla apps while they run
(Firefox and Thunderbird)
ExecuteJS an enhanced JavaScript console (Firefox version, Thunderbird version)
XPCOMViewer an XPCOM inspector (Firefox and Thunderbird)
JavaScript shells to test snippets of JavaScript (Firefox and Thunderbird)
SQLite Manager to manage the SQLite database (Firefox and Thunderbird)
ViewAbout enables access to various about: dialogs from the View menu (Firefox
version, Thunderbird version)
Crash Me Now! useful for testing debug symbols and the crash reporting system
(Firefox and Thunderbird)
53
REFERENCES
Barth,A., Felt, Saxena, P., Boodman, A.(2009) ―Protecting Browsers from
ExtensionVulnerabilities‖, Technical report, Electrical Engineering and Computer
Sciences,University of California at Berkeley , 2009.
―Brutus Tool download ―, http://www.hoobie.net/brutus
Bursztein,E.(2007), ― Basic web security model‖
http://crypto.stanford.edu/cs155/lectures/14-basic-web.pdf
"Building Browser Helper Objects with Visual Studio 2005"
http://msdn.microsoft.com/en-us/library/bb250489(VS.85).aspx
Chou, N., Ledesma, R.(2004) ―Client-side defense against web-based identity theft”
11th Annual Network and Distributed System Security Symposium (NDSS '04), San
Diego, February, 2004.
―nsIExtension manager interface Reference‖
http://doxygen.db48x.net/mozilla/html/interfacensIExtensionManager.html#af67d5ca
896d7fc65a226a2401b803c8e
Extension upload, validation review related information on http://addons.mozilla.org
―Extensions.checkUpdateSecurity‖
http://kb.mozillazine.org/Extensions.checkUpdateSecurity
Firefox extension development Information on http://kb.mozillazine.org/
Hallaraker, O., Vigna G. (2005), ―Detecting malicious JavaScript code in Mozilla‖. In
10th IEEE International Conference on Engineering of Complex Computer Systems
(ICECCS), Shanghai, China(2005)
Jones, J. (2009), ―Web Browser Security : Socially Engineered Malware Protection
Comparative Test Results 2009‖.Technical Report, NSS Labs
54
Kals,S., Kirda,E., Kruegel,C., and Jovanovic,N. (2006). ―Secubat: A Web
Vulnerability Scanner.‖ International World Wide Web Conference (WWC’06),
ACM, Edinburgh, Scotland.
Louw, M, Lim, J and Venkatakrishnan, V.(2008). ―Enhancing web browser security
against malware extensions‖. Journal in Computer Virology, August 2008
Pederick,C.(2008) ―Firefox Web Development Using the Web Developer extension to
develop and debug web sites‖, Webmaster Jam Session 2008
―Statistics on market share‖ http://marketshare.hitslink.com/browser-market-
share.aspx?qprid=0
―Username Enumeration Vulnerability Information‖
http://www.owasp.org/index.php/Testing_for_user_enumeration_%28OWASP-AT-
002%29
―XPCOM API‖ http://www.oxymoronical.com/experiments/apidocs/
Yu, D.,Chander,A.,Islam,N.,Serikov,I.(2007) ―Javascript Instrumentation for Browser
Security‖. In POPL’07 , Nice, France(January 17–19,2007)
―600,000,000 ADD-ON DOWNLOADS ‖
ht tp:/ /blog.mozi l la .com/metrics /2008/01/30/600000000 -add-on-
downloads/