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

helloworld@mozilla.doslash.org: 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 helloworld@mozilla.doslash.org 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/helloworld@mozilla.doslash.org

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/