SPCI 206

POSTGRADUATE COURSE
M.Sc. - CYBER FORENSICS AND
INFORMATION SECURITY

SECOND YEAR
FOURTH SEMESTER

PAPER - XIII
APPLICATION SECURITY

INSTITUTE OF DISTANCE EDUCATION

UNIVERSITY OF MADRAS
M.Sc., CYBER FORENSICS AND PAPER - XIII
INFORMATION SECURITY APPLICATION SECURITY
SECOND YEAR
FOURTH SEMESTER

WELCOME
Warm Greetings.

It is with a great pleasure to welcome you as a student of Institute of Distance Education,

University of Madras. It is a proud moment for the Institute of Distance education as you are
entering into a cafeteria system of learning process as envisaged by the University Grants
Commission. Yes, we have framed and introduced Choice Based Credit System(CBCS) in
Semester pattern from the academic year 2018-19. You are free to choose courses, as per the
Regulations, to attain the target of total number of credits set for each course and also each
degree programme. What is a credit? To earn one credit in a semester you have to spend 30
hours of learning process. Each course has a weightage in terms of credits. Credits are assigned
by taking into account of its level of subject content. For instance, if one particular course or
paper has 4 credits then you have to spend 120 hours of self-learning in a semester. You are
advised to plan the strategy to devote hours of self-study in the learning process. You will be
assessed periodically by means of tests, assignments and quizzes either in class room or
laboratory or field work. In the case of PG (UG), Continuous Internal Assessment for 20(25)
percentage and End Semester University Examination for 80 (75) percentage of the maximum
score for a course / paper. The theory paper in the end semester examination will bring out your
various skills: namely basic knowledge about subject, memory recall, application, analysis,
comprehension and descriptive writing. We will always have in mind while training you in
conducting experiments, analyzing the performance during laboratory work, and observing the
outcomes to bring out the truth from the experiment, and we measure these skills in the end
semester examination. You will be guided by well experienced faculty.

I invite you to join the CBCS in Semester System to gain rich knowledge leisurely at
your will and wish. Choose the right courses at right times so as to erect your flag of success.
We always encourage and enlighten to excel and empower. We are the cross bearers to make
you a torch bearer to have a bright future.

With best wishes from mind and heart,

DIRECTOR

(i)
M.Sc., CYBER FORENSICS AND PAPER - XIII
INFORMATION SECURITY APPLICATION SECURITY
SECOND YEAR
FOURTH SEMESTER

COURSE WRITER & EDITOR

C. Vishnu Priya
Guest Faculty
Centre for Cyber Forensics & Information Security
University of Madras
Chennai

COORDINATION

Dr. M. Srinivasan
Professor & Head
Department of Criminology
University of Madras
Chennai.

© UNIVERSITY OF MADRAS, CHENNAI 600 005.

(ii)
 M.Sc. - DEGREE COURSE

SECOND YEAR -

FOURTH SEMESTER

Paper - XIII

APPLICATION SECURITY

SYLLABUS
Unit 1: Application Types
 Client/Server Applications

 Components of Client/Server Applications (Logical & Physical Architecture)

 Web Applications

o About Web Applications

o Technologies used to create Web Applications

o Components of Web Application Architecture

 Data Warehouse Applications

o About DW Applications

o Uses

o Physical & Logical Architecture

 Management Information Systems

Unit 2: Web application security

 Introduction to web application

o Primer

o OWASP Top 10 vulnerabilities

o Mitigation techniques

 Web Application Security Fundamentals

o What Do We Mean By Security?

(iii)
 o The Foundations of Security

o Threats, Vulnerabilities, and Attacks Defined

o How to Build a Secure Web Application

 Secure Your Network, Host, and Application

o Securing Your Network

o Network Component Categories

o Securing Your Host

o Host Configuration Categories

 Securing Your Application

o Application Vulnerability Categories

o Security Principles

Unit 3: Threats and Countermeasures

 Overview: Anatomy of an Attack

o Survey and Assess

o Exploit and Penetrate

o Escalate Privileges

o Maintain Access

o Deny Service

 Understanding Threat Categories

o STRIDE

o STRIDE Threats and Countermeasures

 Network Threats and Countermeasures

o Information Gathering

o Sniffing

o Spoofing

o Session Hijacking

(iv)
 o Denial of Service

 Host Threats and Countermeasures

o Viruses, Trojan Horses, and Worms

o Foot printing

o Password Cracking

o Denial of Service

o Arbitrary Code Execution

o Unauthorized Access

 Application Threats and Countermeasures

o Input Validation

o Buffer Overflows

o Cross-Site Scripting

o SQL Injection

o Canonicalization

 Authentication

o Network Eavesdropping

o Brute Force Attacks

o Dictionary Attacks

o Cookie Replay Attacks

o Credential Theft

 Authorization

o Elevation of Privilege

o Disclosure of Confidential Data

o Data Tampering

o Luring Attacks

 Configuration Management

(v)
 o Unauthorized Access to Administration Interfaces

o Unauthorized Access to Configuration Stores

o Retrieval of Plaintext Configuration Secrets

o Lack of Individual Accountability

o Over-privileged Application and Service Accounts

 Sensitive Data

o Access to Sensitive Data in Storage

o Network Eavesdropping

o Data Tampering

 Session Management

o Session Hijacking

o Session Replay

o Man in the Middle Attacks

 Cryptography

o Poor Key Generation or Key Management

o Weak or Custom Encryption

o Checksum Spoofing

 Parameter Manipulation

o Query String Manipulation

o Form Field Manipulation

o Cookie Manipulation

o HTTP Header Manipulation

 Exception Management

o Attacker Reveals Implementation Details

o Denial of Service

 Auditing and Logging

(vi)
 o User Denies Performing an Operation

o Attackers Exploit an Application Without Leaving a Trace

o Attackers Cover Their Tracks

Unit 4: Mobile application security

 Mobile Platforms

o Top issues facing mobile devices

o Secure Mobile application development

o Android security

o IOS Security

o Windows, Blackberry & Java Mobile Security

o Symbian OS security

o Web OS security

o WAP and mobile HTML Security

o Bluetooth security

o SMS Security

o Mobile Geo location

o Enterprise Security on Mobile OS

o Mobile Malwares

o Mobile security penetration security

o Encryption and authentications

o Mobile privacy concerns

Unit 5: Threat Modelling

 Overview

 Threat Modelling Principles

o The Process

o The Output

(vii)
 Step 1. Identify Assets

 Step 2. Create an Architecture Overview

o Identify What the Application Does

o Create an Architecture Diagram

o Identify the Technologies

 Step 3. Decompose the Application

o Identify Trust Boundaries

o Identify Data Flow

o Identify Entry Points

o Identify Privileged Code

o Document the Security Profile

 Step 4. Identify the Threats

o Identify Network Threats

o Identify Host Threats

o Identify Application Threats

o Using Attack Trees and Attack Patterns

 Step 5. Document the Threats

 Step 6. Rate the Threats

o Risk = Probability * Damage Potential

o High, Medium, and Low Ratings

o DREAD

 What Comes After Threat Modelling?

o Generating a Work Item Report

Unit 6: Application security standards and checklist

 Application security checklist NIST

 OWASP security checklist

 OWASP Application Security Verification Standard

(viii)
 M.Sc. - DEGREE COURSE

SECOND YEAR -

FOURTH SEMESTER

Paper - XIII

APPLICATION SECURITY
SCHEME OF LESSONS

Sl.No. Title Page

1. Client Server Applications 1

2. Web Application 9

3. Data Warehouse Application 17

4. OWASP 25

5. Web Application Security 37

6. Securing the Network,Host and Application 47

7. Anatomy of an Attack 56

8. Network Threats and Counter measures 67

9. Host and Application Threats 77

10. Authentication and Authorization 91

11. Session Management 102

12. Mobile Platforms 112

13. Mobile Services 138

14. Geo Location and Mobile Malware 160

15. Threat Modelling 178

16. Checklist 205

(ix)
 1

UNIT 1
CLIENT SERVER APPLICATIONS

Learning Objectives

 In this chapter, the concept of client server application is discussed and various places
where security is implemented in the application.

 A learner will be able to understand the security of client server application and various
components of the client server applications.

Structure
1.1 Introduction

1.2 Client Server Application

1.3 Client and User Security

1.4 Server and Network Security

1.5 Endpoint Security

1.6 Components of Client Server Application

1.7 Summary

1.8 Review Questions

1.9 Further Reading

1.1. Introduction

This lesson discusses about the overview of client server application with its components
and security in the client server applications.

1.2. Client Server Application

In principle, a client/server application consists of a client program that consumes services

provided by a server program. The client requests services from the server by calling functions
2

in the server application. In a distributed computing environment, where the client program and
the server program execute on different machines and possibly even on different platforms, the
client and server communicate through a communications layer that is often called middleware.

As shown in Figure 1.1, the client establishes a connection to the server over a local area
network (LAN) or wide-area network (WAN), such as the Internet. Once the server has fulfilled
the client’s request, the connection is terminated. Because multiple client programs share the
services of the same server program, a special server called a daemon may be activated just
to await client requests.

Figure 1.1: Client Server Application

1.3. Client and User Security

Clients connect to servers and these connections, if left open or not secured, provide
entry points for hackers and other intruders that may use data for immoral purposes. Aside
from physical client security in the form of disk drive locks or diskless workstations that prohibit
the loading of unauthorized software or viruses, accessibility to all files stored on a workstation
operating system is the other gaping security hole in clients.

For example, the machine assumes that whoever turns on the computer is the owner of
all the files stored on it. They even have access to configuration files. This could result in
damage or the leaking of sensitive data. The transmission of corrupted data may also occur on
the level of the operating system, outside the realm of client-server application security, as data
is transferred to different tiers of the architecture.
 3

However, the primary culprits of breaching client security are not hackers or viruses, but
the users themselves. The front-line of defence in client security is user identification and
authentication. The easiest way to gain illegal access to computers is to get user’s login ID and
passwords. Sometimes users pick short or easily guessed passwords or share their passwords
with others.

Password management provides a security measurement for this by requiring a minimum

amount of characters to be used in passwords checking passwords for guessability, and regularly
asking users to change their passwords. For example, more organizations are adopting policies
of ‘passphrases’ rather than passwords that are more complicated and harder to identify or
guess.

1.4. Server and Network Security

Security is often thought of only in terms of protecting software. However, any security
plan should be implicated hierarchically at every level. Servers must be located in secure,
access-controlled environments. Only authorized personnel should be allowed to supervise
and administrate it. Essentially, server security is the controlling of access to the database
server itself. The server must be attached to a stable power supply that provides backup up
power if the there’s a problem with the supply. This enables the server to shut down in a way
that protects data and causes the least amount of damage. They should comply with business
standards in password policy to protect database access.

Encryption also protects data through advanced DES (Data Encryption Standard)
mechanisms or cryptograms. The degree of encryption depends on government standards.
Database servers should not be visible to the world. (Web servers; however require specific
security measurements, since they support anonymous connections.)

For security and performance issues, the database backend should never be on the
same machine as the web server with its open connections. To secure the database, the
server should be configured to accept only trusted IP addresses. If the database is a backend
for a web server, the IP address of the web server should be the only address that can access
the database server. Another security gap in servers emerges from increasingly dynamic
applications that allow on-line upgrades and can infiltrate the database server.
4

Networks are vulnerable to intruders who ‘sniff’ or eavesdrop on networks that can contain
sensitive company information, passwords, and other potential company weaknesses. Secure
networks should conform to four principles that form a ‘Trusted Computing Base’ (TCB). These
are:

 Identification and authorization

 Discretionary control

 Audit, and

 Objects re-use.

Identification determines the user’s identity. The user is then authenticated through a
password or the completion of a registration form or some other access-controlling barrier.
Authentication also ensures the identity stays consistent across time. Authorization defines
what the user is allowed to do, what processes users have access to.

Discretionary access control (DAC) is a security system that gives users, processes,
and devices specified permissions to gain access to system resources in clearly defined ways.

Audits are systematic evaluations of the security of a company’s information systems.

Audits examine the most secure physical configuration of hardware and software connections,
how information is handled, and user practices.

Object reuse takes a storage medium that contains one or more objects. It protects
network security by ensuring that all residual data from previous objects is removed before the
storage can be re-assigned.

1.5. Endpoint Security

There are several types of client-server security strategies. One example of client-server
security is called endpoint security. This type of security includes simpler forms of itself, such
as firewalls and anti-virus software.

In endpoint security programs, security software in the form of a client program is

downloaded to every endpoint or user device connected to the network being protected. The
 5

security program is hosted on a server or gateway. This centralizes security and takes care of
updates, login verification and patches. A patch is a quick-fix for a programming bug that develops
during product-testing.

Firewalls and anti-virus software offer the simplest examples of endpoint security software.
Personal or desktop firewalls are software applications that protect single computers that are
connected to the Internet. The connections are usually DSL or cable modem. Since these
connections are always open and use static IP addresses, they are easy for intruders or hackers
to break into.

Firewalls work at the device level or link layer. This is between the physical machine and
the transaction layer. It is the lowest level of Internet protocol, responsible for the physical
connections between computers. It translates requests and responses into packets, decoding
incoming packets by providing address and channel decoding. By acting on this level, firewalls
control Internet connections, filter incoming and outgoing network traffic, and alert users to
suspected intrusions.

Endpoint security is evolving to include other essentials such as the detection and
prevention of intruders gaining access to a network, database, or workstation. Anti-spyware
software is also increasing in popularity. Anti-spyware protects against programs that collect
data on individuals or organizations without their knowledge for unknown uses. They can be
secretly installed on computer through a new program or a virus.

1.6. Components of Client Server Application

There are three Components of Client Server Application.

 Workstations

 Servers

 Network devices
6

1.6.1. Workstations

Workstation or client computers are subordinate to servers. Initially they differentiate

themselves by the operating systems running them. In a client/server network, Windows 2000,
Windows XP, Windows Vista, Windows 7 and Window 10 are all examples of workstation
operating systems. Workstations also have lower technical specifications than servers in the
areas of memory, hard drive space and processor speed, because Workstation send requests
to servers to accessing the programs, files and data. Workstation functions and processes are
essentially intended for client computers. The database security policies and shared programs
management are not part of their operating systems. They have localised versions of databases,
programs and policies.

Characteristics of a Client

 Active (master)

 Sends requests

 Waits for and receives server replies

1.6.2. Server

Servers are distinguished by different sets of operating systems like Windows 2000 Server,
Windows 2003 or Windows 2008. They also have higher memory and hard drive space and
faster processors because they store and service multiple requests from workstations. A server
can assume many roles in a client/server network. It can be a file server, a mail server, a
database server and a domain controller all at the same time. A well-set-up network, however,
delineates these roles to different servers to optimize performance. A server, regardless of
what role it has, essentially acts as a centralized repository of network files, programs, databases
and policies. It makes for easier management and backup because it is not dependent to individual
user configurations, but can be universally and uniformly implemented across the network.

Characteristics of a server

 Passive (slave)
 7

 Waits for requests

 Upon receipt of requests, processes them and then serves replies Servers can be
stateless or stateful. A stateless server does not keep any information between requests.
A stateful server can remember information between requests.

1.6.3. Network devices

Network devices connect workstations and servers. They ensure that requests to and
from workstations are routed properly to the correct server. Several network devices each
provide different types of network connectivity. In a simple client/server network, a hub can
connect a server to multiple workstations. It acts as a repeater, passing on data from one
device to another. Bridges separate network segments. This is useful for offices with several
departments to distinguish which department a particular workstation belongs to. Another network
device, a switch, is similar to a bridge, but can detect conflicts between network segments like
same IP addresses or computer names across departments. Wide-area networks use routers
to connect network segments in different locations. Routers are also used to connect networks,
or route information to the Internet.

1.7. Summary

 A client/server application consists of a client program that consumes services provided

by a server program.

 The client and server communicate through a communications layer that is often
called middleware.

 Identification and authorization, Discretionary control, Audit and Objects re-use are the
four principles that form a ‘Trusted Computing Base’ (TCB).

 Workstations, Servers and Network Devices are the three Components of Client Server
Application.
8

1.8. Review Questions

1. What is Client Server Application?

2. Explain the components of client server application.

3. Write short notes on Endpoint Security.

4. Elaborate the principles that form a TCB.

1.9. Further Reading

 http://www.exforsys.com/tutorials/client-server/client-server-security.html

 https://www.client-server.com/disciplines/cyber-security

 https://study.com/academy/lesson/what-is-a-client-server-network-definition-advantages-
disadvantages.html

 https://www.sciencedirect.com/topics/social-sciences/client-server

 https://www.secureblackbox.com/kb/articles/Securing-client-server-app.rst
 9

UNIT 2
WEB APPLICATION

Learning Objectives

 In this chapter, the concept of web application is discussed along with its benefits and
working.

 A learner will be able to understand the technologies that are used to develop web
applications. It also focuses on the various models and components of web application
architecture.

Structure
2.1 Introduction

2.2 Technology used to build a Website

2.3 Web Application Architecture

2.4 Summary

2.5 Review Questions

2.6 Further Reading

2.1. Introduction

A web application is a software or program which is accessible using any web browser.
Its frontend is usually created using languages like HTML, CSS, Javascript, which are supported
by major browsers. While the backend could use any programming stack like LAMP, MEAN,
etc. Unlike mobile apps, there is no specific SDK for developing web applications. Web
Applications came to prominence with the advent of Software as a Service (SaaS) movement.

2.1.1. Working of Web Application

Web applications are usually coded in browser-supported language such as JavaScript

and HTML as these languages rely on the browser to render the program executable. Some of
10

the applications are dynamic, requiring server-side processing. Others are completely static
with no processing required at the server. The web application requires a web server to manage
requests from the client, an application server to perform the tasks requested, and, sometimes,
a database to store the information.

Here’s what a typical web application flow looks like:

1. User triggers a request to the web server over the Internet, either through a web browser
or the application’s user interface

2. Web server forwards this request to the appropriate web application server

3. Web application server performs the requested task – such as querying the database or
processing the data – then generates the results of the requested data

4. Web application server sends results to the web server with the requested information
or processed data

5. Web server responds back to the client with the requested information that then appears
on the user’s display

2.1.2. Example of a web application

Web applications include online forms, shopping carts, word processors, spreadsheets,
video and photo editing, file conversion, file scanning, and email programs such as Gmail,
Yahoo and AOL. Popular applications include Google Apps and Microsoft 365.Google Apps Work
has Gmail, Google Docs, Google Sheets, Google Slides, online storage and more. Other
functionalities include online sharing of documents and calendars. This lets all team members
access the same version of a document simultaneously.

2.1.3. Benefits of a web application

 Web applications run on multiple platforms regardless of OS or device as long as the

browser is compatible.

 All users access the same version, eliminating any compatibility issues.

 They are not installed on the hard drive, thus eliminating space limitations.
 11

 They reduce software piracy in subscription-based web applications (i.e. SaaS).

 They reduce costs for both the business and end user as there is less support and
maintenance required by the business and lower requirements for the end user’s computer.

2.2. Technology used to build a website

 Java web application architecture makes it possible to combine different Java tools
(continuous integration, version control, etc.) and frameworks (development and testing)
to build apps regardless of their complexity.

 Cloud-based architecture involves storing all data and functions on the cloud or local
servers, which forms an environment where systems can interact with each other while
not directly connected.

 RabbitMQ is a widely-used message broker that acts as a middleman between applications,

storing queued messages until the receiving app can access them. It can be used in
transactional systems, where you want things done in a certain order.

 .NET web server architecture can handle cross-platform software, Docker, microservices,
and execution multiple app versions on the same computer. It doesn’t demand source
code for storing information and enables optimizing and improving the feature set and
development thanks to ASP.NET Core and .NET Core.

 PHP : The tools and features offered by PHP frameworks allow for less code and guarantee
strong protection, prompt development, simple operation, and enhanced support from the
developer community.

 Angular is a framework that brings a variety of advantages, including UX with lazy loading
effect added to minimize code size.

 Python features compressed, legible, and supported code. Python contributes to the
increased web application speed and is exempt from app maintenance. Additionally, it is
extremely limber and well-integrated with other languages.
12

 Node.js framework creates competition for many other computer languages. Developers
use it for coding services and UIs due to its consistency, codesharing and reusing, and
hassle-free knowledge exchange. It offers many free tools and enables integrating multiple
systems and services via a single UI. Thus, you can expect more efficiency and a quicker
design process.

 Ruby on Rails. Relying on the “Convention over Configuration” principle (where convention
means hypotheses), this platform contributes to effective and fast web design. Conventions
are used for decision making.

2.3. Web Application Architecture

A web application is a program that uses an Internet browser to perform certain functions.
It comes with middleware and UIs that connect both the client (what a user sees and utilizes in
the browser), server (the backend of operations), and database(s). While backend scripting
keeps data, the frontend transfers that data to the consumers supporting data exchange. In
simple terms, web app architecture is how the system works during your everyday browsing —
entering a web address, viewing the site, and interacting with it — whereas the browser conveys
data to the server.

A well-formed architecture:

 Maintains visual component.

 Guarantees prompt UI.

 Ensures security.

 Enables stability and self-regulation.

 Scales and records bugs in the easiest way.

2.3.1. Web Application Components

 UI/UX Web Application Components – This includes activity logs, dashboards,

notifications, settings, statistics, etc. These components have nothing to do with the
operation of web application architecture. Instead, they are part of the interface layout
plan of a web app.
 13

 Structural Components – The two major structural components of a web app are
client and server sides.

 Client Component - The client component is developed in CSS, HTML, and JS. As it
exists within the user’s web browser, there is no need for operating system or device-
related adjustments. The client component is a representation of a web application’s
functionality that the end-user interacts with.

 Server Component - The server component can be build using one or a combination
of several programming languages and frameworks, including Java, .Net, NodeJS, PHP,
Python, and Ruby on Rails. The server component has at least two parts; app logic and
database. The former is the main control centre of the web application while the latter is
where all the persistent data is stored.

2.3.2. Models of Web Application Components

Depending on the total number of servers and databases used for a web application, the
model of a web app is decided. It can be any of the following three:

 One Web Server, One Database

It is the most simple as well as the least reliable web app component model. Such a
model uses a single server as well as a single database. A web app builds on such a model will
go down as soon as the server goes down. Hence, it isn’t much reliable.

One web server, one database web application component model is not typically used for
real web applications. It is mostly used for running test projects as well as with the intent of
learning and understanding the fundamentals of the web application.

 Multiple Web Servers, One Database (At a Machine Rather than the
Web server)

The idea with this type of web application component model is that the web server doesn’t
store any data. When the web server gets information from a client, it processes the same and
then writes it to the database, which is managed outside of the server. This is sometimes also
referred to as a stateless architecture.
14

At least 2 web servers are required for this web application component model. This is all
for avoiding failure. Even when one of the web servers goes down, the other one will take
charge.

All requests made will be redirected automatically to the new server and the web app will
continue execution. Hence, reliability is better as compared to the single server with inherent
database model. However, if the database crashes the web app will follow to do the same.

 Multiple Web Server, Multiple Databases

It is the most efficient web application component model because neither the web servers
nor the databases have a single point of failure. There are two options for this type of model.
Either to store identical data in all the employed databases or distribute it evenly among them.

Not more than 2 databases are required typically for the former case, while for the latter
case some data might become unavailable in the scenario of a database crash. DBMS
normalization is used, however, in both scenarios.

When the scale is large i.e. more than 5 web servers or databases or both, it is advised
to install load balancers.

2.3.3. Types of Web Application Architecture

Web application architecture is a pattern of interaction between various web application

components. The type of web application architecture depends on how the application logic is
distributed among the client and server sides.

There are three primary types of web application architecture. Each one of them is
explained as follows:

 Single-Page Applications (SPAs) – Instead of loading completely new pages from

the server each time for a user action, single page web applications allows for a dynamic
interaction by means of providing updated content to the current page.

AJAX, a concise form of Asynchronous JavaScript and XML, is the foundation for enabling
page communications and hence, making SPAs a reality. Because single-page applications
 15

prevent interruptions in user experience, they, in a way, resemble traditional desktop applications.
SPAs are designed in a way so that they request for most necessary content and information
elements. This leads to the procurement of an intuitive as well as interactive user experience.

 Microservices – These are small and lightweight services that execute a single
functionality. The Microservices Architecture framework has a number of advantages that
allows developers to not only enhance productivity but also speed up the entire deployment
process. The components making up an application build using the Microservices
Architecture aren’t directly dependent on each other. As such, they don’t necessitate to
be built using the same programming language.

Hence, developers working with the Microservices Architecture are free to pick up a
technology stack of choice. It makes developing the application simpler and quicker.

 Serverless Architectures – In this type of web application architecture, an application

developer consults a third-party cloud infrastructure services provider for
outsourcing server as well as infrastructure management. The benefit of this approach is
that it allows applications to execute the code logic without bothering with the infrastructure-
related tasks. The Serverless Architecture is best when the development company doesn’t
want to manage or support the servers as well as the hardware they have developed the
web application for.

2.4. Summary
 A web application is a software or program which is accessible using any web browser.

 Web applications run on multiple platforms regardless of OS or device as long as the

browser is compatible.

 Some of the Technologies that are used in to build a website are RabbitMQ, .NET, Python,
Angular, Node.js, Ruby on Rails.

 A well-formed web application architecture Maintains visual component, Guarantees

prompt UI, Ensures security, Enables stability and self-regulation., Scales and records
bugs in the easiest way.
16

 Web Application Components includes UI/UX Web Application Components and Structural
Components.

 The Model of a web application components are classified depending on the total number
of servers and databases used for a web application.

 The three primary types of web application architecture include Single Page Applications,
Microservices and Serverless Architectures.

2.5. Review Questions

1. List down the technologies used to develop a web application.

2.· Based on the counts of servers and databases classify the web application components.

3. Explain the types of Web Application Architecture.

4. What are the benefits of a Web Application?

2.6. Further Reading

 https://www.cloudflare.com/learning/security/what-is-web-application-security/

 https://www.veracode.com/security/cyber-security

 https://www.netsparker.com/blog/web-security/getting-started-web-application-security/

 https://www.keycdn.com/blog/web-application-security-best-practices

 https://resources.infosecinstitute.com/application-architecture-review/#gref

 https://www.giac.org/paper/gsec/2720/application-security-architecture/104640

 https://martinfowler.com/articles/web-security-basics.html

 https://existek.com/blog/web-application-architecture/
 17

UNIT 3
DATA WAREHOUSE APPLICATION

Learning Objectives

 In this chapter, the concept of data warehouse application is discussed along with its
characteristics.

 A learner will be able to understand data warehouse architecture along with its components
and tools.

Structure
3.1 Introduction

3.2 Characteristics of Data Warehouse

3.3 Data Warehouse Architecture

3.4 Data Warehouse Components

3.5 Summary

3.6 Review Questions

3.7 Further Reading

3.1. Introduction

Data warehousing is a process requiring a set of hardware and software components

that can be used to better analyse the massive amounts of data that organisations, companies
and research disciplines are accumulating to make better operational and/or strategic decisions.
The data warehousing process does not consist of just adding data to the Data warehouse, but
also requires the architecture and tools to collect, query, analyse and present information. “Data
warehousing is a process, not a product, for assembling and managing data from various
sources for the purpose of gaining a single, detailed view of part or all of a business”
18

3.2. Characteristics of Data warehouse

A data warehouse has following characteristics:

 Subject-Oriented

 Integrated

 Time-variant

 Non-volatile

Subject-Oriented

Subject-oriented means that all relevant data about a subject is gathered and stored as a
single set in a useful format. Information is presented according to specific subjects or areas of
interest. A data warehouse never focuses on the ongoing operations. Instead, it put emphasis
on modelling and analysis of data for decision making. It also provides a simple and concise
view around the specific subject by excluding data which not helpful to support the decision
process.

Integrated

Integrated refers to data being stored in a globally acceptable fashion with consistent
naming conventions, measurements, encoding structures, and physical attributes, even when
the underlying operational systems store the data differently.

Time-Variant

Time-variant means that the data warehouse contains a history of the subject, as well as
current information. Data warehouse data represents long-term data from five to ten years in
contrast to the 30 to 60 day time period of operational data. Another aspect of time variance is
that once data is inserted in the warehouse, it can’t be updated or changed.

Non-volatile

Data warehouse is also non-volatile means the previous data is not erased when new
data is entered in it. Data is read-only and periodically refreshed. This also helps to analyze
 19

historical data and understand what & when happened. It does not require transaction process,
recovery and concurrency control mechanisms. Non-volatile means stable information that
does not change each time an operational process is executed. Information is consistent
regardless of when the warehouse is accessed.

3.3. Data Warehouse Architectures

There are mainly three types of Data warehouse Architectures:

Single-Tier Architecture

The objective of a single layer is to minimize the amount of data stored. This goal is to
remove data redundancy. This architecture is not frequently used in practice.

Two-Tier Architecture

Two-layer architecture separates physically available sources and data warehouse. This
architecture is not expandable and also not supporting a large number of end-users. It also has
connectivity problems because of network limitations.

Three-Tier Architecture

This is the most widely used architecture. It consists of the Top, Middle and Bottom Tier.

 Bottom Tier: The database of the Data warehouse servers as the bottom tier. It is usually
a relational database system. Data is cleansed, transformed, and loaded into this layer
using back-end tools.

 Middle Tier: The middle tier in Data warehouse is an OLAP server which is implemented
using either ROLAP or MOLAP model. For a user, this application tier presents an
abstracted view of the database. This layer also acts as a mediator between the end-
user and the database.

 Top-Tier: The top tier is a front-end client layer. Top tier is the tools and API that you
connect and get data out from the data warehouse. It could be Query tools, reporting
tools, managed query tools, Analysis tools and Data mining tools.
20

3.4. Data warehouse Components

The data warehouse is based on an RDBMS server which is a central information repository
that is surrounded by some key components to make the entire environment functional,
manageable and accessible.

3.4.1. Overall Architecture

The data warehouse architecture is based on a relational database management system.

The central information repository is surrounded by a number of key components designed to
make the entire environment functional manageable and accessible by the both the operational
systems. The transformation process may involve conversion, summarization, filtering and
condensation of data.

3.4.2. Data Warehouse Database

The central database is the foundation of the data warehousing environment. This database
is implemented on the RDBMS technology. Although, this kind of implementation is constrained
by the fact that traditional RDBMS system is optimized for transactional database processing
and not for data warehousing. For instance, ad-hoc query, multi-table joins; aggregates are
resource intensive and slow down performance.

Hence, alternative approaches to Database are used as listed below-

 In a data warehouse, relational databases are deployed in parallel to allow for scalability.
Parallel relational databases also allow shared memory or shared nothing model on various
multiprocessor configurations or massively parallel processors.

 New index structures are used to bypass relational table scan and improve speed.

 Use of multidimensional database (MDDBs) to overcome any limitations which are placed
because of the relational data model. Example: Essbase from Oracle.

3.4.3. Sourcing, Acquisition, Cleanup and Transformation Tools

The data sourcing, cleanup, transformation and migration tools perform all of the
conversions, summarization, key changes, structural changes and condensations needed to
transform disparate data into information that can be used by decision support tool.
 21

The functionality includes:

Removing unwanted data from operational database.

 Converting to common data names and definitions.

 Establishing defaults for missing data.

 Accommodating source data definition changes

The data sourcing, cleanup, transformation and migration tools have to deal with some significant
issues include:

 Database heterogeneity DBMSs are very different in data models, data access language,
data navigation operations, concurrency integrity, recovery etc.

 Data heterogeneity, this is difference in the way data is defined and used in different
models.

3.4.4. Meta data

Meta data is data about data that describes the data warehouse it is used for building,
maintaining, managing and using the data warehouse. Meta data can be classified into:

 Technical Meta Data, which contains information about warehouse data for use by
warehouse designers and administrations.

 Business Meta Data, which contains information that gives users an easy to understand
perspective of the information stored in the data warehouse.

3.4.5. Query Tools

One of the primary objects of data warehousing is to provide information to businesses to

make strategic decisions. Query tools allow users to interact with the data warehouse system.

These tools fall into four different categories:

1. Query and reporting tools

2. Application Development tools

3. Data mining tools

4. OLAP tools
22

1. Query and reporting tools:

Query and reporting tools can be further divided into

 Reporting tools

 Managed query tools

Reporting tools: Reporting tools can be further divided into production reporting tools
and desktop report writer.

1. Report writers: This kind of reporting tool is tools designed for end-users for their analysis.

2. Production reporting: This kind of tools allows organizations to generate regular operational
reports. It also supports high volume batch jobs like printing and calculating. Some popular
reporting tools are Brio, Business Objects, Oracle, PowerSoft, SAS Institute.

Managed query tools: This kind of access tools helps end users to resolve snags in
database and SQL and database structure by inserting meta-layer between users and database.

2. Application development tools:

Sometimes built-in graphical and analytical tools do not satisfy the analytical needs of an
organization. In such cases, custom reports are developed using Application development tools.

3. Data mining tools:

Data mining is a process of discovering meaningful new correlation, patterns, and trends
by mining large amount data. Data mining tools are used to make this process automatic.

4. OLAP tools:

These tools are based on concepts of a multidimensional database. It allows users to

analyse the data using elaborate and complex multidimensional views.
 23

3.4.6. Data Marts

The concept of a data mart is causing a lot of excitement and attracts much attention in
the data warehouse industry.

These types of data mart, called dependent data marts because their data is sourced
from the data warehouse. Each independent data mart makes to own assumptions about how
to consolidate the data, and the data across several data marts may not be consistent.

3.4.7. Data warehouse Administration and Management

Data warehouse lend to be as much as 4 times as large as related operational databases,

reaching terabytes in size depending on how much history needs to be saved. Managing data
warehouses includes security and priority management, monitoring updates from the multiple
sources.

3.4.8. Information Delivery System

The information delivery component is used to enable the process of subscribing for data
warehouse information and having it delivered to one or more destinations. The web removes
a lot of these issues by giving users universal and relatively inexpensive across to data couple
this across with the ability.

3.5. Summary

 Data warehousing is a process requiring a set of hardware and software components

that can be used to better analyse the massive amounts of data that organisations,
companies and research disciplines are accumulating to make better operational and/or
strategic decisions.

 The characteristics of Data Warehouse application are Subject-Oriented, Integrated, Time-

variant and Non-volatile.

 Subject-oriented means that all relevant data about a subject is gathered and stored as a
single set in a useful format.
24

 Time-variant means that the data warehouse contains a history of the subject, as well as
current information.

 Data warehouse is also non-volatile means the previous data is not erased when new
data is entered in it.

 Single-tier, Two-tier and Three-tier are the three architectures of data warehouse.

 Query tools allow users to interact with the data warehouse system.

3.6. Review Questions

1. Elaborate the characteristics of Data Warehouse.

2. Write short notes on Query Tools.

3. Explain the types of Data Warehouse Architecture.

3.7. Further Reading

 https://datawarehouseinfo.com/data-warehouse/applications-of-a-data-warehouse/

 https://tdan.com/data-warehouse-applications-by-industry/5070

 http://www.folkstalk.com/2011/04/data-warehouse-design- approaches.html.

 https://www.sisense.com/glossary/data-warehouse-architecture/

 PaulrajPonniah,Data Warehousing Fundamentals: A Comprehensive Guide for IT

Professionals published by John Wiley & Sons, Inc

 Data warehousing in the Real World – Sam Anahory& Dennis Murray. Pearson Edn Asia

· Data Warehousing Fundamentals – Paulraj PonniahWiley Student Edition

 25

UNIT 4
OWASP

Learning Objectives
 In this chapter, OWASP is discussed.
 A learner will be able to understand the top 10 vulnerabilities in detail categorized by
OWASP

Structure
4.1 Introduction
4.2 Injection
4.3 Broken Authentication
4.4 Sensitive Data Exposure
4.5 XML External Entities
4.6 Broken Access Control
4.7 Security Misconfiguration
4.8 Cross-Site Scripting
4.9 Insecure Deserialization
4.10 Using Components with Known Vulnerabilities
4.11 Insufficient Logging and Monitoring
4.12 Mitigation Techniques
4.13 Summary
4.14 Review Questions

4.15 Further Reading

4.1. Introduction

OWASP stands for the Open Web Application Security Project, an online community that
produces articles, methodologies, documentation, tools, and technologies in the field of web
application security. OWASP Top 10 is the list of the 10 most seen application vulnerabilities. It
also shows their risks, impacts, and countermeasures.
26

4.2. Injection

An injection of code happens when an attacker sends invalid data to the web application
with the intention to make it do something different from what the application was designed/
programmed to do.

Perhaps the most common example around this security vulnerability is the SQL query
consuming untrusted data as shown in the example below

String query = “SELECT * FROM accounts WHERE custID

= “” + request.getParameter(“id”) + “”;

This query can be exploited by calling up the web page executing it with the following
URL: http://example.com/app/accountView?id=’or’1’=’1, causing the return of all the rows stored
on the database table.

The core of a code injection vulnerability is the lack of validation and sanitization of the
data consumed by the web application, which means that this vulnerability can be present on
almost any type of technology.

4.3. Broken Authentication

Broken authentication vulnerability can allow an attacker to use manual and/or automatic
mediums to try to gain control over any account he/she wants in a system – or even worse – to
gain complete control over the system.

Websites with broken authentication vulnerabilities are very common on the web. Broken
Authentication usually refers to logic issues that occur on the application authentication’s
mechanism, like bad session management prone to username enumeration.

To avoid broken authentication put into practice not leaving the login page for admins
publicly accessible to all visitors of the website:

 /administrator on Joomla!,

 /wp-admin/ on WordPress,
 27

 /index.php/admin on Magento,

 /user/login on Drupal.

The second most common form of this flaw is allowing users to brute force username/
password combination against those pages.

4.4. Sensitive Data Exposure

Sensitive data exposure is one of the most widespread vulnerabilities. It consists of

compromising data that should have been protected.

4.4.1. Examples of Sensitive Data

Some sensitive data that requires protection is:

 Passwords

 Credit card numbers

 Credentials

 Social Security Numbers

 Health information

 Personally Identifiable Information

 Other personal information

It is vital for any organization to understand the importance of protecting users’ information
and privacy. All companies should comply with their local privacy laws.

Responsible sensitive data collection and handling have become more noticeable
especially after the advent of the General Data Protection Regulation (GDPR). GDPR is a new
data privacy law that came into effect May 2018. It mandates how companies collect, modify,
process, store, and delete personal data originating in the European Union for both residents
and visitors.
28

There are 2 types of data:

 Stored data – data at rest

 Transmitted data – data that is transmitted internally between servers, or to web browsers

4.4.2. Protecting Data in Transit

Both types of data should be protected. When thinking about data in transit, one way to
protect it on a website is by having an SSL certificate.SSL is the acronym for Secure Sockets
Layer. It is the standard security technology for establishing an encrypted link between a web
server and a browser. SSL certificates help protect the integrity of the data in
transit between the host (web server or firewall) and the client (web browser).

4.5. XML External Entities (XXE)

According to Wikipedia,

An XML External Entity attack is a type of attack against an application that

parses XML input. This attack occurs when XML input containing a reference to an external
entity is processed by a weakly configured XML parser.Most XML parsers are vulnerable to
XXE attacks by default. That is why the responsibility of ensuring the application does not have
this vulnerability lays mainly on the developer.

4.6. Broken Access Control

In website security, access control means to put a limit on what sections or pages visitors
can reach, depending on their needs.

For example, if you own an ecommerce store, you probably need access to the admin
panel in order to add new products or to set up a promotion for the upcoming holidays. However,
hardly anybody else would need it. Having the rest of your website’s visitors be able to reach
your login page only opens up your ecommerce store to attacks.

And that’s the problem with almost all major content management systems (CMS) these
days. By default, they give worldwide access to the admin panel. Most of them also won’t force
 29

you to establish a second-factor authentication method (2FA). The above makes you think a lot
about software development with a security-first philosophy.

4.7. Security Misconfiguration

Hackers are always looking for ways to penetrate websites, and security misconfigurations
can be an easy way in. Here are some examples of things that hackers usually try to exploit in
order to gain unauthorized access:

 unpatched flaws

 default configurations

 unused pages

 unprotected files and directories

 unnecessary services

One of the most common webmaster flaws is to keep the CMS default configurations.
Today’s CMS applications (although easy to use) can be tricky from a security perspective for
the end users. By far the most common attacks are entirely automated. Many of these attacks
rely on users to have only default settings.

This means that a large number of attacks can be avoided by changing the default
settings when installing a CMS.

For example, some CMS applications are writeable by the user – allowing a user to install
whatever extensions they want. There are settings you may want to adjust to control comments,
users, and the visibility of user information. The file permissions are another example of a
default setting that can be hardened.

4.8. Cross-Site Scripting (XSS)

Cross Site Scripting (XSS) is a widespread vulnerability that affects many web applications.
XSS attacks consist of injecting malicious client-side scripts into a website and using the website
as a propagation method.
30

The danger behind XSS is that it allows an attacker to inject content into a website and
modify how it is displayed, forcing a victim’s browser to execute the code provided by the
attacker while loading the page.

XSS is present in about two-thirds of all applications. Generally, XSS vulnerabilities require
some type of interaction by the user to be triggered, either via social engineering or via a visit to
a specific page. If XSS vulnerability is not patched, it can be very dangerous to any website.

4.8.1 Examples of XSS Vulnerabilities

Imagine you are on your WordPress wp-admin panel adding a new post. If you are using
a plugin with a stored XSS vulnerability that is exploited by a hacker, it can force the browser to
create a new admin user while in the wp-admin panel or it can edit a post and perform other
similar actions.

4.8.2 Types of XSS

According to OWASP, there are 3 types of XSS as shown in Table 4.1:

XSS Type Server Client

Stored Stored Server Stored Client

Reflected Reflected Server Reflected Client

DOM-Based Subset of Client

Table 4.1.Types of XSS

Reflected XSS:

The application or API includes unvalidated and unescaped user input as part of HTML
output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in
the victim’s browser.

Typically, the user will need to interact with some malicious link that points to an attacker-
controlled page, such as malicious watering hole websites, advertisements, or similar.
 31

Stored XSS:

The application or API stores unsensitized user input that is viewed at a later time by
another user or an administrator. Stored XSS is often considered high or critical risk.

DOM XSS:

JavaScript frameworks, single-page applications, and APIs that dynamically include

attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not
send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM-node
replacement or defacement (such as Trojan login panels), attacks against the user’s browser
such as malicious software downloads, keylogging, and other client-side attacks.

4.9. Insecure Deserialization

Every web developer needs to make peace with the fact that attackers/security researchers
are going to try to play with everything that interacts with their application–from the URLs to
serialized objects.

In computer science, an object is a data structure; in other words, a way to structure

data. To make it easier to understand some key concepts:

 The process of serialization is converting objects to byte strings.

 The process of deserialization is converting byte strings to objects.

4.10. Using Components with Known Vulnerabilities

These days, even simple websites such as personal blogs have a lot of dependencies.
We can all agree that failing to update every piece of software on the backend and frontend of
a website will, without a doubt, introduce heavy security risks sooner rather than later.

For example, our hacked website report for 2017 has a dedicated section around outdated
CMS. This report shows that at the time of the infection:
32

 39.3% of WordPress websites were out of date;

 69.8% of Joomla! websites were out of date;

 65.3% of Drupal websites were out of date;

 80.3% of Magento websites were out of date.

The question is, why aren’t we updating our software on time? Why is this still such a
huge problem today?

There are some possibilities, such as:

 Webmasters/developers cannot keep up with the pace of the updates; after all,
updating properly takes time.

 Legacy code won’t work on newer versions of its dependencies.

This might be a little too dramatic, but every time you disregard an update warning, you
might be allowing a now known vulnerability to survive in your system. Trust me, cybercriminals
are quick to investigate software and update changelogs.

Whatever the reason for running out-of-date software on your web application is, you
can’t leave it unprotected. OWASP recommend virtual patching for the cases where patching
is not possible.

Virtual patching affords websites that are outdated (or with known vulnerabilities) to be
protected from attacks by preventing the exploitation of these vulnerabilities on the fly. This is
usually done by a firewall and an intrusion detection system.

4.11. Insufficient Logging and Monitoring

The importance of securing a website cannot be understated. While 100% security is not
a realistic goal, there are ways to keep your website monitored on a regular basis so you can
take immediate action when something happens. Not having an efficient logging and monitoring
process in place can increase the chances of a website compromise.
 33

If you need to monitor your server, OSSEC is freely available to help you. OSSEC actively
monitors all aspects of system activity with file integrity monitoring, log monitoring, root check,
and process monitoring.

4.12. Mitigation Techniques

Injection

 Input sanitization: Implement whitelisting approach at server side for what all can be
accepted

 Use of safe API’s and parametrized queries

Broken Authentication

 Use of multifactor authentication

 Session isolation

 Idle session timeouts

 Using secured cookies

Sensitive Data Exposure

 Encrypt all data in transit and at rest

 Use secure protocols and algorithms

 Disable caching of responses with sensitive data. Hackers might get the cached copies
and steal the information from them

XML External Entities (XXE)

 Avoid serialization of sensitive data

 Implement whitelisting approach at server side to prevent malicious XML upload

 Use of Web Application Firewall (WAF) to detect and block XXE

Broken Access Control

 Invalidate tokens and cookies after logout

 Forced login/logout after a password change

34

 Server-side resource restriction e.g. directories

 Restrict access to all resources basis roles

Security Misconfiguration

 Have a hardening process in place for both hardware and applications. Do ensure that
defaults are changed.

 Install only the required features from a framework

 Review the security of the configurations at fixed intervals

Cross-Site Scripting (XSS)

 Output encoding and escaping untrusted characters

 Enabling Content-Security-Policy (CSP)

Insure Deserialization

 Encryption of the serialized data

 Deserializers to run with least privileges

Using Components with Known Vulnerabilities

 Regular patching process

 Subscribe to various forums which share the latest vulnerabilities along with the CVE
numbers and mitigation techniques / fixes. Check if the vulnerability affects the devices /
software in your inventory and fix them.

Insufficient Logging & Monitoring

 24x7 monitoring of application traffic and log analysis

 Effective Security Incident and Response procedures to be in place and practice

 35

4.13. Summary

 OWASP stands for the Open Web Application Security Project, an online community that
produces articles, methodologies, documentation, tools, and technologies in the field of
web application security.

 OWASP Top 10 is the list of the 10 most seen application vulnerabilities. Web applications
run on multiple platforms regardless of OS or device as long as the browser is compatible.

 An injection of code happens when an attacker sends invalid data to the web application
with the intention to make it do something different from what the application was designed/
programmed to do.

 Broken authentication vulnerability can allow an attacker to use manual and/or automatic
mediums to try to gain control over any account he/she wants in a system – or even
worse – to gain complete control over the system.

 XSS attacks consist of injecting malicious client-side scripts into a website and using the
website as a propagation method.

 The process of serialization is converting objects to byte strings. The process

of deserialization is converting byte strings to objects.

4.14. Review Questions

1. List down the most seen top vulnerabilities of OWASP.

2. What is XML External Entities attack?

3. Define Serialization and Deserialization.

4. What are the types of XSS?

5. Explain the mitigation techniques of OWASP Vulnerabilities.

36

4.15. Further Reading

· https://www.veracode.com/directory/owasp-top-10

 https://owasp.org/www-project-top-ten/

 https://resources.whitesourcesoftware.com/blog-whitesource/owasp-top-10-vulnerabilities

 https://www.cloudflare.com/learning/security/threats/owasp-top-10/

 https://www.synopsys.com/blogs/software-security/owasp-top-10-application-security-
risks/

 https://www.ibm.com/developerworks/library/se-owasptop10/
 37

UNIT 5
WEB APPLICATION SECURITY

Learning Objectives

 In this chapter, the concept of web application Security is discussed along with its aim
and principles.

 A learner will be able to get an idea on threats, attacks and vulnerabilities. And also the
learner would know the needs for building a secure web application.

Structure
5.1 Introduction

5.2 Threats, Attacks, Vulnerabilities

5.3 Build a Secure Web Application

5.4 Summary

5.5 Review Questions

5.6 Further Reading

5.1. Introduction

Web application security is the process of protecting websites and online services against
different security threats that exploit vulnerabilities in an application’s code. Common targets
for web application attacks are content management systems (e.g., WordPress), database
administration tools (e.g., phpMyAdmin) and SaaS applications.

Offenders consider web applications high-priority targets due to:

 The inherent complexity of their source code, which increases the likelihood of unattended
vulnerabilities and malicious code manipulation.

 High value rewards, including sensitive private data collected from successful source
code manipulation.
38

 Ease of execution, as most attacks can be easily automated and launched indiscriminately
against thousands, or even tens or hundreds of thousands of targets at a time.

Organizations failing to secure their web applications run the risk of being attacked. Among
other consequences, this can result in information theft, damaged client relationships, revoked
licenses and legal proceedings.

The aim of Web application security is to identify the following:

 Critical assets of the organization

 Genuine users who may access the data

 Level of access provided to each user

 Various vulnerabilities that may exist in the application

 Data criticality and risk analysis on data exposure

 Appropriate remediation measures

Web application security aims to address and fulfil the four conditions of security, also
referred to as principles of security:

 Confidentiality: States that the sensitive data stored in the Web application should not
be exposed under any circumstances.

 Integrity: States that the data contained in the Web application is consistent and is not
modified by an unauthorized user.

 Availability: States that the Web application should be accessible to the genuine user
within a specified period of time depending on the request.

 Nonrepudiation: States that the genuine user cannot deny modifying the data contained
in the Web application and that the Web application can prove its identity to the genuine
user.
 39

5.2. Threats, Attacks, Vulnerabilities

 Threat – A negative effect or undesired event. A potential occurrence, often best described
as an effect that might damage or compromise an asset or objective. It may or may not
be malicious in nature.

 Vulnerability – A weakness in some aspect or feature of a system that makes an exploit

possible. Vulnerabilities can exist at the network, host, or application levels and include
operational practices.

 Attack (or exploit) – An action taken that uses one or more vulnerabilities to realize a
threat. This could be someone following through on a threat or exploiting vulnerability.

 Countermeasure – Addresses a vulnerability to reduce the probability of an attack or

the impact of a threat. They do not directly address threats; instead, they address the
factors that define the threats. Countermeasures range from improving application design,
or improving your code, to improving an operational practice.

5.2.1. Example

Threats, attacks, vulnerabilities and countermeasures are used to organize your security
information. Here’s an example of organizing threats, attacks, vulnerabilities and
countermeasures for Input/Data validation:

Threats/Attacks for Input/Data Validation

 Buffer overflows

 Cross-site scripting

 SQL injection

 Canonicalization attacks

 Query string manipulation

 Form field manipulation

40

 Cookie manipulation

 HTTP header manipulation

Vulnerabilities for Input/Data Validation

 Using non-validated input in the Hypertext Markup Language (HTML) output stream

 Using non-validated input used to generate SQL queries

 Relying on client-side validation

 Using input file names, URLs, or user names for security decisions

 Using application-only filters for malicious input

 Looking for known bad patterns of input

 Trusting data read from databases, file shares, and other network resources

 Failing to validate input from all sources including cookies, query string parameters, HTTP
headers, databases, and network resources

Countermeasures for Input/Data Validation

 Do not trust input

 Validate input: length, range, format, and type

 Constrain, reject, and sanitize input

 Encode output

5.3. Build a Secure Web Application

5.3.1. Web Application Firewall (WAF)

WAFs are the cornerstone of proactive website security. They are a security solution
deployed on the network edge, which inspects all incoming traffic and continuously blocks
 41

malicious requests. WAFs are versatile, automatically blocking known attack types via built-in
rules, and letting you deploy your own security policies for specific security needs.

A major advantage of WAFs is that they can be deployed with no changes to the underlying
applications, and can block threats immediately, without requiring you to perform actions like
patching vulnerabilities or modifying problematic code.

Unlike a traditional firewall, a WAF can understand application traffic, differentiate legitimate
and malicious traffic, and thus detect and block complex attack patterns.

5.3.2. Bot Management

As mentioned, most attacks on websites are carried out by bots, making it essential to
have a tool in your security arsenal that can identify and deal with bot traffic.

Bot management solutions use data like behaviour profiles, reputation analysis, HTTP/S
headers, IP and ASN signatures, and cookie and JavaScript challenges, to determine whether
Bots hitting your site are legitimate or malicious. Bot protection solutions block bad bots, while
allowing good bots to access your site.

5.3.3. Threat Intelligence

Threat intelligence tools provide convenient access to information about threat actors,
including known bad IP addresses, bot behaviour patterns, and attack signatures. When a
security incident occurs, threat intelligence can help security teams identify which type of attack
is taking place, by whom, and how best to protect against it.

5.3.4. Backdoor Shell Protection

Data breaches take over 100 days on average to discover, and some breaches are never
discovered. If you have been breached, attackers may have installed an operating system shell
or a rootkit that can sidestep any other security solutions.

When evaluating backdoor protection tools, prefer a tool that identifies and intercepts
communication requests with operating system backdoors, instead of focusing on identifying
the backdoor directly.
42

File and vulnerability scanners can help find backdoors, but with new backdoor variants
cropping up daily and advanced obfuscation methods, they have limited effectiveness. Tools
deployed at the network edge can more easily identify new types of backdoors, and pick up
backdoor communications, even if the backdoor itself is encrypted or obfuscated.

5.3.5. SSL/TLS

The Transport Layer Security (TLS) protocol, which succeeded the SSL protocol, provides
private, encrypted communication for website traffic. Websites secured by TLS are served
using the Secure Hypertext Protocol (HTTP/S).

TSL provides privacy, ensuring third parties cannot listen into communications between
websites and their visitors. It also authenticates communications using public key cryptography,
and ensures the integrity of messages, preventing man in the middle attacks.

It has long been understood that websites providing private or sensitive content, login or
payment capabilities need to be secured by TLS.

Today, there is a broad consensus that all websites should be served over HTTP/S. The
Google search engine demotes search rankings for websites that do not use TLS, and popular
browsers, including Chrome and Firefox, display warnings saying such websites are insecure.

When selecting your website hosting and content management platform, ensure it supports
TLS. If you are currently serving your website without TLS, strongly consider switching to TLS
and redirecting existing content to HTTP/S web addresses.

Ensure security solutions you use for your website support TLS, and help you implement
it at a good level. Use evaluation tools such as the SSL Labs security test to see if your hosting
or security tools implement TLS and HTTP/S using the latest security best practices.

5.3.6. DDoS Protection

Modern DDoS protection services can protect against large-scale DDoS attacks, by scaling
up a network of cloud-based computers to match the magnitude of the attack. DDoS protection
services can perform deep packet inspection of incoming traffic and “scrub” or remove bad
requests at large scale, while allowing legitimate requests to go through.
 43

The following are key features you should look for in a DDoS protection service:

Comprehensiveness—able to protect against network layer attacks, application layer

attacks, can parse HTTP/S traffic, and protect secondary assets such as databases, file servers,
and CRMsystems.

Network capacity—check how many Gbps or Tbps of traffic are supported by the
service; this will roughly equal the scale of DDoS attack it can stop. Also, see if the service has
a proven historical track record of stopping large-scale attacks.

SLA—services should guarantee an uptime of between three nines (99.9%) and five
nines (99.999%), the best case. In addition, Service Level Agreement (SLA) should cover the
type, size and duration of attacks it can protect, and specify a guaranteed response time. A
faster response will give you a higher level of resilience.

5.3.7. Advanced Persistent Threat (APT) Protection

An APT is an attack campaign in which a threat actor or a team of malicious actors

establish a presence on a network to obtain highly sensitive data or assets. APT is a multi-
vector attack that involves a combination of techniques carried out over a long period of time,
continuing for a long time after attackers have managed to penetrate the corporate network.

APTs typically target large enterprises, governments or institutions, and are aimed at
stealing intellectual property, obtaining sensitive data, or sabotaging organizational systems.

There is no one tool that can protect against APTs. When selecting a solution for APT
protection, consider a combination of tools that can protect against multi-faceted attacks. A key
aspect is gaining visibility into attacks that may involve multiple organizational systems or multiple
users, possibly with lateral movement and gradual privilege escalation.

Technologies commonly used to protect again APTs include: two-factor authentication, to

prevent illicit access to organizational systems; web application firewalls (WAF), to block
suspicious requests to a web application; protection against backdoor shells and other
vulnerabilities; and DDoS protection. DDoS may be used as part of an APT to distract security
teams, while attackers use other methods to penetrate the network.
44

5.3.8. Access Management

A common entry point for attackers is via access control systems. Weak authentication
mechanisms, weak or seldom updated passwords, excessive privileges, and failure to block
suspicious sources, can lead to a breach, business disruption, or defacement of a website.
Access management is also critical to mitigating threats from malicious insiders.

There are several approaches and tools to achieve secure access management. Identity
and Access Management (IAM) is an enterprise system which helps enforce password policies
and manage user roles and privileges. Consider a full-blown IAM system if you manage thousands
of users in a large organization.

Whether you use IAM or not, ensure your access control solution supports multi-factor
authentication and reputation management, which can filter out traffic based on detection of
sources like anonymous proxies, TOR network or suspicious geographies.

In addition, ensure your solution includes IP blacklisting, which identifies known bad traffic
sources and uses them to block bad requests, and reputation management. To protect against
insider threats, select a tool with advanced behavioural analysis capabilities, deception devices
such as decoys and honeypots, and real time monitoring and auditing of data usage.

5.3.9. Regulatory Compliance

Many security standards and regulations, such as the European Union’s General Data
Protection Regulation (GDPR), the Payment Card Industry Data Security Standard (PCI DSS),
and the Health Insurance Portability and Accountability Act (HIPAA), define the need for specific
types of security tools, or specific security policies which can be enforced using security
solutions.

When selecting a security tool, consider your industry’s compliance standards, ensure
your tools support the standard, and see which provisions of each standard or regulation you
can address using the tools. In most cases, you will have to combine multiple tools to fully meet
compliance requirements.
 45

5.3.10. Security Customization

Some website security tools are “one size fits all”, and do not allow you to customize
security policies or rules to your organization’s specific requirements. The more advanced
security products, however, will allow you to expand on the basic security logic they provide—
either by adding exceptions to the default security rules, or by allowing you to create completely
new security policies.

Such customization could be important, as it can help minimize the amount of business
disruption caused by false positive security events. Moreover, it can also be vital for businesses
that find a need to enforce their own security policies or to modify the security rules for regulatory
compliance.

5.3.11. SIEM integration

If your team uses Security Information and Event Management (SIEM), ensure you select
security tools must integrate with it. This will enable you to use data and alerts from your security
solutions to raise SIEM alerts, and conduct security analysis and investigations.

5.4. Summary

 Web application security is the process of protecting websites and online services against
different security threats that exploit vulnerabilities in an application’s code.

 Threat is a negative effect or undesired event. A potential occurrence, often best described
as an effect that might damage or compromise an asset or objective.

 Vulnerability is a weakness in some aspect or feature of a system that makes an exploit

possible.

 Threat intelligence tools provide convenient access to information about threat actors,
including known bad IP addresses, bot behaviour patterns, and attack signatures.

 The Transport Layer Security (TLS) protocol, which succeeded the SSL protocol, provides
private, encrypted communication for website traffic. Websites secured by TLS are served
using the Secure Hypertext Protocol (HTTP/S).
46

 Service Level Agreement (SLA) should cover the type, size and duration of attacks it can
protect, and specify a guaranteed response time.

 An APT is an attack campaign in which a threat actor or a team of malicious actors

establish a presence on a network to obtain highly sensitive data or assets.

 Identity and Access Management (IAM) is an enterprise system which helps enforce
password policies and manage user roles and privileges.

 Many security standards and regulations, such as the European Union’s General Data
Protection Regulation (GDPR), the Payment Card Industry Data Security Standard (PCI
DSS), and the Health Insurance Portability and Accountability Act (HIPAA), define the
need for specific types of security tools, or specific security policies which can be enforced
using security solutions.

5.5. Review Questions

1. What makes offenders to consider web applications as high-priority targets?

2. Brief the principles of security.

3. How a secure web application is build for an organisation?

4. Write short notes on Threats, Attacks and Vulnerability.

5.6. Further Reading

 https://www.netsparker.com/blog/web-security/getting-started-web-application-security/

 https://www.cloudflare.com/learning/security/what-is-web-application-security/

 https://www.imperva.com/learn/application-security/application-security/

 https://martinfowler.com/articles/web-security-basics.html

 https://www.keycdn.com/blog/web-application-security-best-practices

 https://www.webarxsecurity.com/improve-web-application-security/

 https://www.synopsys.com/glossary/what-is-web-application-security.html
 47

UNIT 6
SECURING THE NETWORK,
HOST AND APPLICATION

Learning Objectives

 In this chapter, the concept of security in the network, host and application is discussed.

 A learner will be able to know how to secure the network, host and application of an
organization by knowing its elements and also the security principles that need to followed
for security.

Structure
6.1 Introduction

6.2 Securing your Network

6.3 Securing your Host

6.4 Securing your Application

6.5 Security Principles

6.6 Summary

6.7 Review Questions

6.8 Further Reading

6.1. Introduction

The physical view for securing your network, host and application is shown in Figure 6.1.

These categories are to organize our threats, attacks, vulnerabilities, and

countermeasures.
48

Figure 6.1 : Physical View

6.2. Securing Your Network

The three core elements of a secure network are the router, firewall, and switch are
explained in Table 6.1.

Element Description

Router Routers are your outermost network ring. They direct packets to the ports and
protocols that you have prepared your applications to work with. Insecure TCP
IP protocols are blocked at this ring.

Firewall The firewall blocks those protocols and ports that the application does not use.
Additionally, firewalls enforce secure network traffic by providing application
specific filtering to block malicious communications.

Switch Switches are used to separate network segments. They are frequently
overlooked or over trusted.

Table 6.1 : Securing your Network

 49

6.3. Securing Your Host

The organization of host security is shown in Figure 6.2.

Figure 6.2 : Host Security

Element Description

Accounts Accounts grant authenticated access to your computer, and these accounts
must be audited. Configure accounts with least privilege to help prevent
elevation of privilege. Remove any accounts that you do not need. Slow
down brute force and dictionary attacks with strong password policies, and
then audit and alert for logon failures.

Auditing and Who did what and when? Auditing and logging refer to how your
Logging application records security-related events.

Files and Secure all files and directories with restricted NTFS permissions that only
Directories allow access to necessary Windows services and user accounts. Use
Windows auditing to allow you to detect when suspicious or unauthorized
activity occurs.

Patches and Patching and updating your server software is a critical first step. If you do
Updates not patch and update your server, you provide opportunities for attackers
and malicious code.
50

Protocols Avoid using protocols that are inherently insecure. If you cannot avoid
using these protocols, take the appropriate measures to provide secure
authentication and communication.

Registry Many security-related settings are stored in the registry and as a result,
you must secure the registry. You can do this by applying restricted
Windows ACLs and by blocking remote registry administration.

Services If the service is necessary, secure it and maintain it. Consider monitoring
any service to ensure availability. If your service software is not secure,
but you need the service, try to find a secure alternative.

Table 6.2 : Securing your Host

The categories shown in Table 6.2 proved to be highly effective. We used these to create
and organize checklists for security Web servers, application servers, and database servers.
They were also helpful for matching up existing checklists. For example, we could ask questions
like, what does this security checklist for IIS say to do about accounts? Which services does it
mention and what does it tell you to do with them? … etc.

6.4. Securing Your Application

The application security is organised as shown in Table 6.3.

Element Description

Auditing and Who did what and when? Auditing and logging refer to how your
Logging application records security-related events.

Authentication Who are you? Authentication is the process that an entity uses to identify
another entity, typically through credentials such as a user name and
password.

Authorization What can you do? Authorization is the process that an application uses to
control access to resources and operations.
 51

Configuration Who does your application run as? Which databases does it connect to?
Management How is your application administered? How are these settings secured?
Configuration management refers to how your application handles these
operational issues.

Cryptography How are you protecting secret information (confidentiality)? How are you
tamper-proofing your data or libraries (integrity)? How are you providing
seeds for random values that must be cryptographically strong?
Cryptography refers to how your application enforces confidentiality and
integrity.

Exception When a method call in your application fails, what does your application
Management do? How much does it reveal about the failure condition? Do you return
friendly error information to end users? Do you pass valuable exception
information back to the caller? Does your application fail gracefully?

Input and Data How do you know that the input your application receives is valid and
Validation safe? Input validation refers to how your application filters, scrubs, or
rejects input before additional processing.

Parameter Form fields, query string arguments, and cookie values are frequently
Manipulation used as parameters for your application. Parameter manipulation refers to
both how your application safeguards tampering of these values and how
your application processes input parameters.

Sensitive Data Sensitive data is information that must be protected either in memory, over
the wire, or in persistent stores. Your application must have a process for
handling sensitive data.

Session A session refers to a series of related interactions between a user and

Management your Web application. Session management refers to how your
application handles and protects these interactions.

Table 6.3 : Securing your Application

52

6.5. Security principles

6.5.1. Minimise attack surface area

Every time a programmer adds a feature to their application, they are increasing the risk
of security vulnerability. The principle of minimising attack surface area restricts the functions
that users are allowed to access, to reduce potential vulnerabilities.

For example, you might code a search feature into an application. That search feature is
potentially vulnerable to file inclusion attacks and SQL injection attacks. The developer could
limit access to the search function, so only registered users could use it — reducing the attack
surface and the risk of a successful attack.

6.5.2. Establish secure defaults

This principle states that the application must be secure by default. That means a new
user must take steps to obtain higher privileges and remove additional security measures (if
allowed). Establishing safe defaults means there should be strong security rules for how user
registrations are handled, how often passwords must be updated, how complex passwords
should be and so on. Application users may be able to turn off some of these features, but they
should be set to a high-security level by default.

6.5.3. The principle of least privilege

The Principle of Least Privilege (POLP) states that a user should have the minimum set
of privileges required to perform a specific task. The POLP can be applied to all aspects of a
web application, including user rights and resource access. For example, a user who is signed
up to a blog application as an “author” should not have administrative privileges that allow them
to add or remove users. They should only be allowed to post articles to the application.

6.5.4. The principle of Defence in depth

The principle of defence in depth states that multiple security controls that approach risks
in different ways is the best option for securing an application. So, instead of having one security
control for user access, you would have multiple layers of validation, additional security auditing
 53

tools, and logging tools. For example, instead of letting a user login with just a username and
password, you would use an IP check, a Captcha system, logging of their login attempts, brute
force detection and so on.

6.5.5. Fail securely

There are many reasons why a web application would fail to process a transaction. Perhaps
a database connection failed, or the data inputted from a user was incorrect. This principle
states that applications should fail in a secure way. Failure should not give the user additional
privileges, and it should not show the user sensitive information like database queries or logs.

6.5.6. Don’t trust services

Many web applications use third-party services for accessing additional functionality or
obtaining additional data. This principle states that you should never trust these services from
a security perspective. That means the application should always check the validity of data that
third-party services send and not give those services high-level permissions within the app.

6.5.7. Separation of duties

Separation of duties can be used to prevent individuals from acting fraudulently. For
example, a user of an E-Commerce website should not be promoted to also be an administrator
as they will be able to alter orders and give themselves products. The reverse is also true an
administrator should not have the ability to do things that customers do, like order items from
the front end of the website.

6.5.8. Avoid security by obscurity

This OWASP principle states that security by obscurity should never be relied upon. If
your application requires its administration URL to be hidden so it can remain secure, then it is
not secure at all. There should be sufficient security controls in place to keep your application
safe without hiding core functionality or source code.
54

6.5.9. Keep security simple

Developers should avoid the use of very sophisticated architecture when developing
security controls for their applications. Having mechanisms that are very complex can increase
the risk of errors.

6.5.10. Fix security issues correctly

If a security issue has been identified in an application, developers should determine the
root cause of the problem. They should then repair it and test the repairs thoroughly. If the
application uses design patterns, it is likely that the error may be present in multiple systems.
Programmers should be careful to identify all affected systems.

6.6. Summary

 Router direct packets to the ports and protocols that you have prepared your applications
to work with.

 If you do not patch and update your server, you provide opportunities for attackers and
malicious code.

 Auditing and logging refer to how your application records security-related events.

 Authentication is the process that an entity uses to identify another entity, typically through
credentials such as a user name and password.

 Authorization is the process that an application uses to control access to resources and
operations.

 Cryptography refers to how your application enforces confidentiality and integrity.

 Input validation refers to how your application filters, scrubs, or rejects input before additional
processing.

 The Principle of Least Privilege (POLP) states that a user should have the minimum set
of privileges required to perform a specific task.
 55

6.7. Review Questions

1. What are the elements that need to be considered for securing an application?

2. Elaborate the security in the Network and Host.

3. Write short notes on POLP.

4. Explain the security principles that need to be followed in an organisation.

6.8. Further Reading

 https://www.oreilly.com/library/view/web-securityprivacy/0596000456/ch15s02.html

 https://csguide.cs.princeton.edu/security/host

 https://www.pearsonitcertification.com/articles/article.aspx?p=2321780

 https://sourcedaddy.com/windows-7/host-security.html

 https://www.slideshare.net/profansari/host-and-network-security

 https://dwheeler.com/secure-programs/Secure-Programs-HOW TO/security
principles.html

 https://infosec.mozilla.org/fundamentals/security_principles.html

 https://www.techopedia.com/2/27825/security/the-basic-principles-of-it-security
56

UNIT 7
ANATOMY OF AN ATTACK

Learning Objectives
 In this chapter, the concept of how a cyber attack occurs and how modern technologies
help in better security.

 A learner will be able to understand the technologies that are used to improve the security
and get a brief knowledge on STRIDE along with its threats and countermeasures.

Structure
7.1 Introduction

7.2 Steps in Anatomy of Cyber Attack

7.3 Protection from Cyber Attacks

7.4 Applying modern technologies for better security

7.5 Basic steps in attacker methodology

7.6 ST RIDE

7.7 STRIDE threats and countermeasures

7.8 Summary

7.9 Review Questions

7.10 Further Reading

7.1. Introduction

Many organizations are attacked for sensitive data or ransom. And, hackers are consistently
working on new malware and cyber attack techniques to find loopholes in current cyber security
standards. Hence, every organization is prone to cyber threats. To prevent these attacks,
organizations must first understand the anatomy of a cyber attack, and the motives behind it.
 57

7.2. Steps in Anatomy of Cyber Attack

Steps in the anatomy of cyber attack is as follows

7.2.1. Reconnaissance

Before launching an attack, hackers first identify a vulnerable target and explore the best
ways to exploit it. The initial target can be anyone in an organization, whether an executive or an
admin. The attackers simply need a single point of entrance to start. Targeted phishing emails
are common in this step as an effective method of distributing malware.

7.2.2. Scanning

Once the target is identified, the next step is to identify a weak point that allows the attackers
to gain access. This is usually accomplished by scanning an organization’s network – with
tools easily found on the Internet – to find entry points. This step of the process normally goes
slowly, sometimes lasting months, as the attackers search for vulnerabilities.

7.2.3. Access and Escalation

Now that weaknesses in the target network are identified, the next step in the cyber attack
is to gain access and then escalate. In almost all such cases, privileged access is needed
because it allows the attackers to move freely within the environment. Rainbow Tables and
similar tools help intruders steal credentials, escalate privileges to admin, and then get into any
system on the network that’s accessible via the administrator account. Once the attackers
gain elevated privileges, the network is taken over and is now “owned” by the intruders.

7.2.4. Exfiltration

With the freedom to move around the network, the attackers can access systems with
an organization’s most sensitive data – and extract it at will. But stealing private data is not the
only action intruders can take. They can also change or erase files on compromised systems.

7.2.5. Sustainment

The attackers have now gained unrestricted access throughout the target network. Next
is sustainment, or staying in place quietly. To accomplish this, the hackers may secretly install
58

malicious programs like root kits. This allows them to return whenever they want. And with the
elevated privileges acquired earlier, dependence on a single access point is no longer necessary.
The attackers can come and go as they please.

7.2.6. Assault

Fortunately, this step is not taken in every cyber attack, because the assault is the stage
of an attack when things become particularly nasty. This is when the hackers might alter the
functionality of the victim’s hardware, or disable the hardware. The Stuxnet attack on Iran’s
critical infrastructure is a classic example. During the assault phase, the attack ceases to be
stealth. However, the attackers have already taken control of the environment. So it’s generally
too late for the breached organization to defend itself.

7.2.7. Obfuscation

Usually the attackers want to hide their tracks, but this is not universally the case –
especially if the hackers want to leave a “calling card” behind to boast about their exploits. The
purpose of trail obfuscation is to confuse, disorientate and divert the forensic examination
process. Trail obfuscation covers a variety of techniques and tools including log cleaners,
spoofing, misinformation, zombied accounts, trojan commands, and more.

7.3. Protection from Cyber Attacks

7.3.1. Understanding the motive behind cyber attacks

To effectively protect your organization from cyber attacks, it is essential to understand

the motive behind cyber attacks. The motives of a hacker can help find flaws in the anatomy of
a cyber attack.

7.3.2. Preventing the organization from cyber attacks

To protect the organization, business leaders such as CIOs and CTOs need to hire skilled
cyber security professionals. Cyber security experts spend years in researching and studying
the anatomy of a cyber attack, and they know how to prevent or at least minimize the impact of
cyber attacks. Cyber security experts can maintain the security standards in your organization
through multiple steps and measures such as follows:
 59

 Cyber security experts test the systems and the network for vulnerabilities and fix them
pre-emptively.

 Intrusion prevention technology is capable of detecting reconnaissance attempts. And,

URL filtering and reputation-based security services can block suspicious links that may
contain viruses or malware.

 Cyber security experts install firewalls and malware scanners to block malware and
viruses. Malware is constantly redesigned by attackers to avoid being detected by traditional
signature-based systems. Hence, advanced persistent threat protection needs to be used
to detect malware based on malware behaviour.

 Organizations need to pay close attention to the outgoing traffic and apply egress filter to
monitor and restrict outgoing traffic.

 Cyber security experts must conduct regular audits of hardware and software to monitor
the health and security strength of their IT systems.

 Organizations should consider training employees and educating them about cyber attacks
as one of their top priorities.

7.3.3. Creating damage reduction and recovery strategies

Organizations have to realize that even after following all the security protocols, hackers
can still attack their networks and systems. With the help of cyber security experts, organizations
can analyze the anatomy of a cyber attack to find flaws in the attacks, and exploit the weaknesses
to reduce the damage. Various organizations only plan for protection from cyber threats,
completely avoiding recovery mechanisms, which can lead to dire consequences in case of an
attack. To reduce the damage from cyber attacks, organizations should consider the following
steps:

 The first step would be encrypting all the data that your organization owns. Even if an
attacker infiltrates the network, decrypting the data will need hours, which may buy some
time for the security experts to find the source of the attack.
60

 Organizations must adopt two-factor authentication system, as passwords can get leaked
easily. With two-factor authentication, the attacker cannot access the data even after
acquiring the leaked passwords.

 For better data loss prevention, cybersecurity systems should set up alerts for outgoing
data. The alerts can notify the organization about their data being stolen after a data
breach.

 Hackers control the systems and networks with malware-based communication systems.
Hence, blocking outgoing command and control connections can effectively stop outgoing
malware communication.

7.4. Applying modern technologies for better cyber security

Artificial intelligence is playing a pivotal role in cyber security. Machine learning has the
ability to analyze the anatomy of a cyber attack, and learn from the behaviour patterns of malware.
Moreover, artificial intelligence can automate threat detection and data recovery mechanisms.
Hence, AI-powered applications can find security threats and implement recovery strategies
more efficiently when compared to software-based solutions. And, big players such as Microsoft,
Google, Palo Alto Networks, Fortinet and Cisco Systems are already developing cyber security
solutions using artificial intelligence and machine learning. With the exponential development of
artificial intelligence, numerous security software have started adopting machine learning to
provide more effective cyber security solutions.

Likewise, blockchain technology has the potential to improve cyber security. Blockchain
can effectively detect a data breach, and disrupt the process that forms the anatomy of a cyber
attack. With blockchain, organizations can distribute their data over the network, which will
simplify the process of data recovery. And, the changes in data would be transparent. Hence, if
the data is altered or deleted, tracking the changes will be an easy process. Furthermore,
multiple cyber security firms are working on developing blockchain-powered security solutions
for mainstream applications. For example, Acronis, a cyber security organization, is applying
blockchain technology to generate a cryptographic hash, that is unique for every data file. The
hash can be used to verify the authenticity of every file. And, it is almost impossible for a hacker
 61

to compute the cryptographic hash. Thus, AI and blockchain are revolutionizing the cyber security
landscape.

Although the technology and methods to fight cyber attacks are getting better, hackers
are also developing their techniques to execute stronger attacks. And, with new malware and
ransomware being developed, these attacks can lead to bigger data breaches than any we’ve
seen before. Hence, organizations need to become aware of the anatomy of a cyber attack to
be able to tackle cyber security issues better.

7.5. Basic steps in attacker methodology

By understanding the basic approach used by attackers to target your Web application,
you will be better equipped to take defensive measures because you will know what you are up
against. The basic steps in attacker methodology are summarized below and illustrated in
Figure 7.1:

 Survey and assess

 Exploit and penetrate

 Escalate privileges

 Maintain access

 Deny service

Figure 7.1 : Basic steps for attacking methodology

62

7.5.1. Survey and Assess

The first step an attacker usually takes is to survey the potential target to identify and
assess its characteristics. These characteristics may include its supported services and
protocols together with potential vulnerabilities and entry points. The attacker uses the information
gathered in the survey and assess phase to plan an initial attack.

For example, an attacker can detect a cross-site scripting (XSS) vulnerability by testing
to see if any controls in a Web page echo back output.

7.5.2. Exploit and Penetrate

Having surveyed a potential target, the next step is to exploit and penetrate. If the network
and host are fully secured, your application (the front gate) becomes the next channel for attack.
For an attacker, the easiest way into an application is through the same entrance that legitimate
users use—for example, through the application’s logon page or a page that does not require
authentication.

7.5.3. Escalate Privileges

After attackers manage to compromise an application or network, perhaps by injecting

code into an application or creating an authenticated session with the Microsoft® Windows®
2000 operating system, they immediately attempt to escalate privileges. Specifically, they look
for administration privileges provided by accounts that are members of the Administrators group.
They also seek out the high level of privileges offered by the local system account.

Using least privileged service accounts throughout your application is a primary defense
against privilege escalation attacks. Also, many network level privilege escalation attacks require
an interactive logon session.

7.5.4. Maintain Access

Having gained access to a system, an attacker takes steps to make future access easier
and to cover his or her tracks. Common approaches for making future access easier include
planting back-door programs or using an existing account that lacks strong protection. Covering
 63

tracks typically involves clearing logs and hiding tools. As such, audit logs are a primary target
for the attacker.

Log files should be secured, and they should be analyzed on a regular basis. Log file
analysis can often uncover the early signs of an attempted break-in before damage is done.

7.5.5. Deny Service

Attackers who cannot gain access often mount a denial of service attack to prevent others
from using the application. For other attackers, the denial of service option is their goal from the
outset. An example is the SYN flood attack, where the attacker uses a program to send a flood
of TCP SYN requests to fill the pending connection queue on the server. This prevents other
users from establishing network connections.

7.6. STRIDE

Threats faced by the application can be categorized based on the goals and purposes of
the attacks. A working knowledge of these categories of threats can help you organize a security
strategy so that you have planned responses to threats. STRIDE is the acronym used at Microsoft
to categorize different threat types. STRIDE stands for:

 Spoofing. Spoofing is attempting to gain access to a system by using a false identity.

This can be accomplished using stolen user credentials or a false IP address. After the
attacker successfully gains access as a legitimate user or host, elevation of privileges or
abuse using authorization can begin.

 Tampering. Tampering is the unauthorized modification of data, for example as it flows

over a network between two computers.

 Repudiation. Repudiation is the ability of users (legitimate or otherwise) to deny that

they performed specific actions or transactions. Without adequate auditing, repudiation
attacks are difficult to prove.

 Information disclosure. Information disclosure is the unwanted exposure of private

data. For example, a user views the contents of a table or file he or she is not authorized
64

to open, or monitors data passed in plaintext over a network. Some examples of information
disclosure vulnerabilities include the use of hidden form fields, comments embedded in
Web pages that contain database connection strings and connection details, and weak
exception handling that can lead to internal system level details being revealed to the
client. Any of this information can be very useful to the attacker.

 Denial of service. Denial of service is the process of making a system or application

unavailable. For example, a denial of service attack might be accomplished by bombarding
a server with requests to consume all available system resources or by passing it
malformed input data that can crash an application process.

 Elevation of privilege. Elevation of privilege occurs when a user with limited privileges
assumes the identity of a privileged user to gain privileged access to an application. For
example, an attacker with limited privileges might elevate his or her privilege level to
compromise and take control of a highly privileged and trusted process or account.

7.7. STRIDE Threats and Countermeasures

Threats Countermeasures

Spoofing user identity  Use strong authentication.

 Do not store secrets (for example, passwords)
in plaintext.
 Do not pass credentials in plaintext over the
wire.
 Protect authentication cookies with Secure
Sockets Layer (SSL).

Tampering with data  Use data hashing and signing

 Use digital signatures.
 Use strong authorization.
 Use tamper-resistant protocols across
communication links.
 Secure communication links with protocols that
provide message integrity.
 65

Repudiation  Create secure audit trails.

 Use digital signatures.

Information disclosure  Use strong authorization.

 Use strong encryption.
 Secure communication links with protocols that
provide message confidentiality.
 Do not store secrets (for example, passwords)
in plaintext.

Denial of service  Use resource and bandwidth throttling

techniques.
 Validate and filter input.

Elevation of privilege  Follow the principle of least privilege and use

least privileged service accounts to run
processes and access resources.

Table 7.1 : Countermeasures of STRIDE Threats

7.8. Summary

 The steps in the anatomy of an attack include Reconnaissance, Scanning, Access &
Escalation, Exfiltration, Sustainment, Assault and Obfuscation.

 The basic steps in attacker methodology are summarized as Survey and assess, Exploit
and penetrate, Escalate privileges, Maintain access and Deny service.

 Spoofing is attempting to gain access to a system by using a false identity.

 Tampering is the unauthorized modification of data.

 Information disclosure is the unwanted exposure of private data.

 Denial of service is the process of making a system or application unavailable.

66

 Elevation of privilege occurs when a user with limited privileges assumes the identity of a
privileged user to gain privileged access to an application.

7.9. Review Questions

1. Elaborate the steps in the anatomy of an cyber attack.

2. Illustrate the basic steps of attacking methodology.

3. Write short notes on STRIDE.

4. Explain STRIDE threats and countermeasures?

7.10. Further Reading

 https://www.futurelearn.com/courses/cyber-security/0/steps/19631

 https://www.goconqr.com/p/8893606-stride-threats—countermeasures-flash_card_decks

 https://medium.com/faun/threat-modeling-317b375548da

 https://www.allerin.com/blog/the-anatomy-of-a-cyber-attack-dissecting-the-science-
behind-virtual-crime

 https://learn-umbrella.cisco.com/product-videos/ransomware-anatomy-of-an-attack
 67

UNIT 8
NETWORK THREATS AND
COUNTERMEASURES

Learning Objectives

 In this chapter, the concept of threats in network discussed along with its countermeasures.

 A learner will be able to understand the various attacks in the network and the
countermeasures for the attack.

Structure
8.1 Introduction

8.2 Information Gathering

8.3 Sniffing Attacks

8.4 Spoofing

8.5 Session Hijacking

8.6 Denial of Service

8.7 Summary

8.8 Review Questions

8.9 Further Reading

8.1. Introduction

The primary components that make up your network infrastructure are routers, firewalls,
and switches. They act as the gate keepers guarding your servers and applications from attacks
and intrusions. An attacker may exploit poorly configured network devices. Common
vulnerabilities include weak default installation settings, wide open access controls, and devices
lacking the latest security patches. Top network level threats include:
68

 Information gathering

 Sniffing

 Spoofing

 Session hijacking

 Denial of service

8.2. Information Gathering

Network devices can be discovered and profiled in much the same way as other types of
systems. Attackers usually start with port scanning. After they identify open ports, they use
banner grabbing and enumeration to detect device types and to determine operating system
and application versions. Armed with this information, an attacker can attack known vulnerabilities
that may not be updated with security patches.

Countermeasures to prevent information gathering include:

 Configure routers to restrict their responses to foot printing requests.

 Configure operating systems that host network software (for example, software firewalls)
to prevent foot printing by disabling unused protocols and unnecessary ports.

8.3. Sniffing Attacks

Sniffing attack means capturing the data packets when it flows through a computer network.
Packet sniffer is the device or medium used to do this sniffing attack. They are called network
protocol analyzer. Unless the packets are encrypted with strong network security, any hacker
might steal the data and analyze it. There are different packet sniffers such as wireshark,
Dsniff, Etherpeek etc..

8.3.1. Types of Sniffing Attacks

There are various types of sniffing attack such as –

 LAN Sniff – The sniffer attacks the internal LAN and scans the entire IP gaining access
to live hosts, open ports, server inventory etc.. A port specific vulnerability attacks happens
in LAN sniffing.
 69

 Protocol Sniff – Based on the network protocol used, the sniffer attacks occurs. The
different protocol such as ICMP, UDP, Telnet, PPP, DNS etc. or other protocols might be
used.

 ARP Sniff – ARP Poisoning attacks or packet spoofing attacks occur based on the data
captured to create a map of IP address and associated MAC addresses.

 TCP Session stealing – TCP session stealing is used to monitor and acquire traffic
details between the source & destination IP address. All details such as port number,
service type, TCP sequence numbers, and data are stolen by the hackers.

 Application level sniffing – Applications running on the server are attacked to plan an
application specific attack.

 Web password sniffing – HTTP session created by users are stolen by sniffers to get
the user ID, password and other sensitive information.

8.3.2. Tools used for Packet Sniffing

 Wireshark – Widely used network protocol analyzer to monitor network and packet flows
in the network. It is free and works in multi platforms.

 Tcpdump – It has less security risk, requires few resource only. In windows it runs as
WinDump.

 Dsniff – Used to sniff different protocols in UNIX and Linux systems only, to sniff and
reveal passwords.

 NetworkMiner – Makes network analysis simple, to detect host and open ports through
packet sniffing. It can operate offline.

 Kismet – Specifically used to sniff in wireless networks, even from hidden networks and
SSIDs. KisMac is used for MAC and OSX environment.

There are various other packet sniffing tools such as EtherApe, Fiddler, OmniPeek, PRTG
Network monitor and so on.
70

8.3.4. Sniffing Detection and Prevention techniques

Detecting sniffers can be difficult since they are mostly passive (collects data only)
especially in a shared Ethernet. When he is functioning on a switched ethernet network segment
it is easier to detect the sniffing using the following techniques, they are –

 Ping method – Sending ping request of the IP address of the affected machine, the sniffer
machine might respond to the ping if the suspect machine is still running. It is a not
strongly reliable method.

 ARP method – Machines always captures and caches ARP. Upon sending a non-broadcast
ARP, the sniffer/promiscuous machine will cache the ARP and it will respond to our
broadcast ping.

 On Local Host – Logs can be used to find if the machine is running on a sniffer attack or
not.

 Latency method – Ping time is used to detect the sniffing, the time is generally short. If the
load is heavy by sniffer, it takes long time to reply for pings.

 ARP Watch – Used to trigger alarms when it sees a duplicate cache of the ARP.

 Using IDS – Intrusion detection systems monitors for ARP spoofing in the network. It
records packets on network with spoofed ARP addresses.

The better way to prevent sniffing is usage of encryption tools, adding MAC address of
gateway permanently to ARP cache, switching to SSH, https instead of http and so on.

8.4. Spoofing

A spoofing attack is when a malicious party impersonates another device or user on a

network in order to launch attacks against network hosts, steal data, spread malware or
bypasses access controls. There are several different types of spoofing attacks that malicious
parties can use to accomplish this. Some of the most common methods include IP address
spoofing attacks, ARP spoofing attacks and DNS server spoofing attacks.
 71

8.4.1. ARP Spoofing Attacks

ARP is short for Address Resolution Protocol, a protocol that is used to resolve IP
addresses to MAC (Media Access Control) addresses for transmitting data. In an ARP spoofing
attack, a malicious party sends spoofed ARP messages across a local area network in order to
link the attacker’s MAC address with the IP address of a legitimate member of the network.
This type of spoofing attack results in data, that is intended for the host’s IP address getting
sent to the attacker instead. Malicious parties commonly use ARP spoofing to steal information,
modify data-in-transit or stop traffic on a LAN.

Normally, your computer communicates with a wireless router on a private network: emails,
searches, you name it. With address resolution protocol (ARP) spoofing, the attacker “sits”
(quietly) on the network too, attempting to crack the network’s IP address.

Once in, using spoofing techniques, the hacker plays both roles: you and the router. The
attacker intercepts—and yes, even modifies or stops—information to and from your computer
and the router. Unless you use ARP spoofing detection software, you most likely aren’t aware
that this malicious activity is happening.

To overwhelm your system and cause a shutdown, the attacker may mix up and direct
several IP addresses to you. These denial-of-service (DoS) attacks can crash business servers
and potentially suspend operations. Unfortunately, such attacks are frequent. As many as one-
third of networks suffered at least one DoS attack within the last two years, according to a
2017 study. ARP spoofing attacks can also be used to facilitate other types of attacks, including
denial-of-service, session hijacking and man-in-the-middle attacks. ARP spoofing only works
on local area networks that use the Address Resolution Protocol.

Routinely checking your website’s stats for unexpected traffic spikes and paying attention
to multiple “service unavailable” messages can help you predict possible DoS attacks.
72

8.4.2. IP Spoofing

Figure 8.1 : IP Spoofing

IP address spoofing is one of the most frequently used spoofing attack methods. In an IP
address spoofing attack, an attacker sends IP packets from a false (or “spoofed”) source address
in order to disguise itself. Denial-of-service attacks often use IP spoofing to overload networks
and devices with packets that appear to be from legitimate source IP addresses.

There are two ways that IP spoofing attacks can be used to overload targets with traffic.
One method is to simply flood a selected target with packets from multiple spoofed addresses.
This method works by directly sending a victim more data than it can handle. The other method
is to spoof the target’s IP address and send packets from that address to many different recipients
on the network. When another machine receives a packet, it will automatically transmit a packet
to the sender in response. Since the spoofed packets appear to be sent from the target’s IP
address, all responses to the spoofed packets will be sent to (and flood) the target’s IP address.

IP spoofing attacks can also be used to bypass IP address-based authentication. This

process can be very difficult and is primarily used when trust relationships are in place between
machines on a network and internal systems. Trust relationships use IP addresses (rather
than user logins) to verify machines identities when attempting to access systems. This enables
malicious parties to use spoofing attacks to impersonate machines with access permissions
and bypass trust-based network security measures.

8.4.3. DNS Server Spoofing Attacks

The Domain Name System (DNS) is a system that associates domain names with IP
addresses. Devices that connect to the internet or other private networks rely on the DNS for
 73

resolving URLs, email addresses and other human-readable domain names into their
corresponding IP addresses. In a DNS server spoofing attack, a malicious party modifies the
DNS server in order to reroute a specific domain name to a different IP address. In many
cases, the new IP address will be for a server that is actually controlled by the attacker and
contains files infected with malware. DNS server spoofing attacks are often used to
spread computer worms and viruses.

8.4.5. Spoofing Attack Prevention and Mitigation

There are many tools and practices that organizations can employ to reduce the threat of
spoofing attacks. Common measures that organizations can take for spoofing attack prevention
include:

 Packet filtering: Packet filters inspect packets as they are transmitted across a network.
Packet filters are useful in IP address spoofing attack prevention because they are capable
of filtering out and blocking packets with conflicting source address information (packets
from outside the network that show source addresses from inside the network and vice-
versa).

 Avoid trust relationships: Organizations should develop protocols that rely on trust
relationships as little as possible. It is significantly easier for attackers to run spoofing
attacks when trust relationships are in place because trust relationships only use IP
addresses for authentication.

 Use spoofing detection software: There are many programs available that help
organizations detect spoofing attacks, particularly ARP Spoofing. These programs work
by inspecting and certifying data before it is transmitted and blocking data that appears to
be spoofed.

 Use cryptographic network protocols: Transport Layer Security (TLS), Secure Shell
(SSH), HTTP Secure (HTTPS) and other secure communications protocols bolster
spoofing attack prevention efforts by encrypting data before it is sent and authenticating
data as it is received.
74

8.5. Session Hijacking

Session hijacking is the act of taking control of a user session after successfully obtaining
or generating an authentication session ID. Session hijacking involves an attacker using captured,
brute forced or reverse-engineered session IDs to seize control of a legitimate user’s Web
application session while that session is still in progress.

A session is a series of interactions between two communication end points that occurs
during the span of a single connection. When a user logs into an application a session is
created on the server in order to maintain the state for other requests originating from the same
user.

Applications use sessions to store parameters which are relevant to the user. The session
is kept “alive” on the server as long as the user is logged on to the system. The session is
destroyed when the user logs-out from the system or after a predefined period of inactivity.
When the session is destroyed, the user’s data should also be deleted from the allocated
memory space.

Hijacking at network layer captures TCP and UDP sessions. When a TCP session is
seized between two systems, it is known as TCP Hijacking. The problem is that authentication
only occurs at initial level, which helps hackers to gain access to a machine. UDP session
hijacking is easy to execute than TCP session hijacking, since UDP does not allow
synchronization and packet sequencing. Therefore, hijacker may simply forge server’s UDP
reply before the response.

8.5.1. Countermeasures

Countermeasures to help prevent session hijacking include

 Use encrypted session negotiation.

 Use encrypted communication channels.

 Stay informed of platform patches to fix TCP/IP vulnerabilities, such as predictable packet
sequences.
 75

8.6. Denial of Service

Denial of service denies legitimate users access to a server or services. The SYN flood
attack is a common example of a network level denial of service attack. It is easy to launch and
difficult to track. The aim of the attack is to send more requests to a server than it can handle.
The attack exploits a potential vulnerability in the TCP/IP connection establishment mechanism
and floods the server’s pending connection queue.

Countermeasures to prevent denial of service include:

 Apply the latest service packs.

 Harden the TCP/IP stack by applying the appropriate registry settings to increase the size
of the TCP connection queue, decrease the connection establishment period, and employ
dynamic backlog mechanisms to ensure that the connection queue is never exhausted.

 Use a network Intrusion Detection System (IDS) because these can automatically detect
and respond to SYN attacks.

8.7. Summary

 Configure operating systems that host network software (for example, software firewalls)
to prevent foot printing.

 Sniffing attack means capturing the data packets when it flows through a computer network.
Packet sniffer is the device or medium used to do this sniffing attack.

 The various sniffing attacks are LAN Sniff, Protocol Sniff , ARP Sniff, Application level
sniffing, web password sniffing etc.

 A spoofing attack is when a malicious party impersonates another device or user on a

network in order to launch attacks against network hosts, steal data, spread malware or
bypasses access controls.

 Session hijacking is the act of taking control of a user session after successfully obtaining
or generating an authentication session ID.
76

8.8. Review Questions

1. Write short notes on Session Hijacking with its countermeasures.

2. Explain the various spoofing attacks in the network.

3. List the types of sniffing attack.

4· Illustrate the working of IP spoofing.

8.9. Further Reading

 https://www.publicpower.org/periodical/article/anatomy-attack

 https://www.riskiq.com/research/anatomy-of-an-attack-surface/

 https://intellipaat.com/blog/tutorial/ethical-hacking-cyber-security-tutorial/sniffing-attacks/

 http://www.rroij.com/open-access/network-attacks-and-their countermeasures.php?
aid=42585

 https://www.greycampus.com/blog/information-security/what-is-a-sniffing-attack-and-how-
can-you-defend-it
 77

UNIT 9
HOST AND APPLICATION THREATS

Learning Objectives

 In this chapter, the concept of host and application threats is discussed.

 A learner will be able to understand the about virus, Trojans and worms, arbitrary code
execution and various application threats like SQL Injection, Canonicalization etc.

Structure
9.1 Introduction

9.2 Viruses, Trojans horses and worms

9.3 Footprinting

9.4. Password Cracking

9.5 Denial of Service

9.6 Arbitrary code Execution

9.7 Unauthorised Access

9.8 Application Threats

9.9 Input Validation

9.10 Buffer Overflows

9.11 Cross-Site Scripting

9.12 SQL Injection

9.13 Canonicalization

9.14 Summary

9.15 Review Questions

9.16 Further Reading

78

9.1. Introduction

Host threats are directed at the system software upon which your applications are built.
Top host level threats include:

 Viruses, Trojan horses, and worms

 Footprinting

 Profiling

 Password cracking

 Denial of service

 Arbitrary code execution

 Unauthorized access

9.2. Viruses, Trojan horses, and worms

Trojan Virus Worm

Definition Malicious program used Self-replicating program Illegitimate programs

to control a victim’s that attaches itself to that replicate
computer from a remote other programs and files themselves usually
location. over the network

Purpose Steal sensitive data, spy Disrupt normal computer Install backdoors on
on the victim’s computer, usage, corrupt user victim’s computer,
etc. data, etc. slow down the user’s
network, etc.

Table 9.1 : Virus, Trojan and Worms

9.2.1. Countermeasures

Stay current with the latest operating system service packs and software patches.

 Block all unnecessary ports at the firewall and host.

 Disable unused functionality including protocols and services.

 Harden weak, default configuration settings.

 79

9.3. Footprinting

Footprinting is the first and most convenient way that hackers use to gather information
about computer systems and the companies they belong to.

The purpose of Footprinting is to learn as much as you can about a system, its remote
access capabilities, its ports and services, and the aspects of its security.

Examples of Footprinting are port scans, ping sweeps, and NetBIOS enumeration that
can be used by attackers to glean valuable system–level information to help prepare for more
significant attacks. The type of information potentially revealed by Footprinting includes account
details, operating system and other software versions, server names, and database schema
details.

Footprinting helps to

Know Security Posture – The data gathered will help us to get an overview of the
security posture of the company such as details about the presence of a firewall, security
configurations of applications etc.

Reduce Attack Area – Can identify a specific range of systems and concentrate on
particular targets only. This will greatly reduce the number of systems we are focussing on.

Identify vulnerabilities – we can build an information database containing the

vulnerabilities, threats, loopholes available in the system of the target organization.

Draw Network map – helps to draw a network map of the networks in the target
organization covering topology, trusted routers, presence of server and other information.

9.3.1. Countermeasures

 Disable unnecessary protocols.

 Lock down ports with the appropriate firewall configuration.

 Use TCP/IP and IPSec filters for defense in depth.

80

 Configure IIS to prevent information disclosure through banner grabbing.

 Use an IDS that can be configured to pick up Footprinting patterns and reject suspicious
traffic.

9.4. Password Cracking

If the attacker cannot establish an anonymous connection with the server, he or she will
try to establish an authenticated connection. For this, the attacker must know a valid username
and password combination. If you use default account names, you are giving the attacker a
head start. Then the attacker only has to crack the account’s password. The use of blank or
weak passwords makes the attacker’s job even easier.

9.4.1. Countermeasures

 Use strong passwords for all account types.

 Apply lockout policies to end-user accounts to limit the number of retry attempts that can
be used to guess the password.

 Do not use default account names, and rename standard accounts such as the
administrator’s account and the anonymous Internet user account used by many Web
applications.

 Audit failed logins for patterns of password hacking attempts.

9.5. Denial of Service

Denial of service can be attained by many methods aimed at several targets within your
infrastructure. At the host, an attacker can disrupt service by brute force against your application,
or an attacker may know of a vulnerability that exists in the service your application is hosted in
or in the operating system that runs your server.

9.5.1. Countermeasures

 Configure your applications, services, and operating system with denial of service in
mind.
 81

 Stay current with patches and security updates.

 Harden the TCP/IP stack against denial of service.

 Make sure your account lockout policies cannot be exploited to lock out well known service
accounts.

 Make sure your application is capable of handling high volumes of traffic and that thresholds
are in place to handle abnormally high loads.

 Review your application’s failover functionality.

 Use IDS that can detect potential denial of service attacks.

9.6. Arbitrary Code Execution

If an attacker can execute malicious code on your server, the attacker can either
compromise server resources or mount further attacks against downstream systems. The
risks posed by arbitrary code execution increase if the server process under which the attacker’s
code runs is over-privileged. Common vulnerabilities include weak ID configuration and
unpatched servers that allow path traversal and buffer overflow attacks, both of which can lead
to arbitrary code execution.

9.6.1. Countermeasures

 Configure IIS to reject URLs with “../” to prevent path traversal.

 Lock down system commands and utilities with restricted ACLs.

 Stay current with patches and updates to ensure that newly discovered buffer overflows
are speedily patched.

9.7. Unauthorized Access

Inadequate access controls could allow an unauthorized user to access restricted

information or perform restricted operations. Common vulnerabilities include weak IIS Web
access controls, including Web permissions and weak NTFS permissions.
82

9.7.1. Countermeasures

 Configure secure Web permissions.

 Lock down files and folders with restricted NTFS permissions.

 Use .NET Framework access control mechanisms within your ASP.NET applications,
including URL authorization and principal permission demands.

9.8. Application Threats

A good way to analyze application-level threats is to organize them by application

vulnerability category. The various categories used in the subsequent sections of this module
and throughout the guidance, together with the main threats to your application, are summarized
in Table 9.1.

Category Threats

Input validation Buffer overflow; cross-site scripting; SQL injection; canonicalization

Authentication Network eavesdropping; brute force attacks;dictionary attacks;

cookie replay; credential theft

Authorization Elevation of privilege; disclosure of confidential data; data tampering;

luring attacks

Configuration Unauthorized access to administration interfaces; unauthorized

management access to configuration stores; retrieval of clear text configuration
data; lack of individual accountability; over-privileged process and
service accounts

Sensitive data Access sensitive data in storage; network eavesdropping; data

tampering

Session management Session hijacking; session replay; man in the middle

Cryptography Poor key generation or key management; weak or custom

encryption
 83

Parameter Query string manipulation; form field manipulation; cookie

manipulation manipulation; HTTP header manipulation

Exception Information disclosure; denial of service

management

Auditing and logging User denies performing an operation; attacker exploits an

application without trace; attacker covers his or her tracks

Table 9.1 : Threats by Application Vulnerability Category

9.9. Input Validation

Input validation is a security issue if an attacker discovers that your application makes
unfounded assumptions about the type, length, format, or range of input data. The attacker can
then supply carefully crafted input that compromises your application.

When network and host level entry points are fully secured; the public interfaces exposed
by your application become the only source of attack. The input to your application is a means
to both test your system and a way to execute code on an attacker’s behalf. Does your application
blindly trust input? If it does, your application may be susceptible to the following:

 Buffer overflows

 Cross-site scripting

 SQL injection

 Canonicalization

9.10. Buffer Overflows

A buffer overflow happens when a program tries to fill a block of memory (a memory
buffer) with more data than the buffer was supposed to hold. By sending suitably crafted user
inputs to a vulnerable application, attackers can force the application to execute arbitrary code
to take control of the machine or crash the system. Buffer overflow vulnerabilities are caused
by programmer mistakes that are easy to understand but much harder to avoid and protect
against.
84

Buffer overflow vulnerabilities can lead to denial of service attacks or code injection. A
denial of service attack causes a process crash; code injection alters the program execution
address to run an attacker’s injected code.

Countermeasures to help prevent buffer overflows include:

 Perform thorough input validation. This is the first line of defense against buffer overflows.
Although a bug may exist in your application that permits expected input to reach beyond
the bounds of a container, unexpected input will be the primary cause of this vulnerability.
Constrain input by validating it for type, length, format and range.

 When possible, limit your application’s use of unmanaged code, and thoroughly inspect
the unmanaged APIs to ensure that input is properly validated.

 Inspect the managed code that calls the unmanaged API to ensure that only appropriate
values can be passed as parameters to the unmanaged API.

 Use the /GS flag to compile code developed with the Microsoft Visual C++® development
system. The /GS flag causes the compiler to inject security checks into the compiled
code. This is not a fail-proof solution or a replacement for your specific validation code; it
does, however, protect your code from commonly known buffer overflow attacks. Example
of Code Injection Through Buffer Overflows.

An attacker can exploit a buffer overflow vulnerability to inject code. With this attack, a
malicious user exploits an unchecked buffer in a process by supplying a carefully constructed
input value that overwrites the program’s stack and alters a function’s return address. This
causes execution to jump to the attacker’s injected code.

The attacker’s code usually ends up running under the process security context. This
emphasizes the importance of using least privileged process accounts. If the current thread is
impersonating, the attacker’s code ends up running under the security context defined by the
thread impersonation token. The first thing an attacker usually does is call the RevertToSelf API
to revert to the process level security context that the attacker hopes has higher privileges.

Make sure you validate input for type and length, especially before you call unmanaged
code because unmanaged code is particularly susceptible to buffer overflows.
 85

9.11. Cross-Site Scripting

An XSS attack can cause arbitrary code to run in a user’s browser while the browser is
connected to a trusted Web site. The attack targets your application’s users and not the
application itself, but it uses your application as the vehicle for the attack.

Because the script code is downloaded by the browser from a trusted site, the browser
has no way of knowing that the code is not legitimate. Internet Explorer security zones provide
no defense. Since the attacker’s code has access to the cookies associated with the trusted
site and are stored on the user’s local computer, a user’s authentication cookies are typically
the target of attack.

9.11.1. Example of Cross-Site Scripting

To initiate the attack, the attacker must convince the user to click on a carefully crafted
hyperlink, for example, by embedding a link in an email sent to the user or by adding a malicious
link to a newsgroup posting. The link points to a vulnerable page in your application that echoes
the unvalidated input back to the browser in the HTML output stream. For example, consider the
following two links.

Here is a legitimate link:

www.yourwebapplication.com/logon.aspx?username=bob

Here is a malicious link:

www.yourwebapplication.com/logon.aspx?username=<script>alert (‘hacker code’)</script>

If the Web application takes the query string, fails to properly validate it, and then returns
it to the browser, the script code executes in the browser. The preceding example displays a
harmless pop-up message. With the appropriate script, the attacker can easily extract the
user’s authentication cookie, post it to his site, and subsequently make a request to the target
Web site as the authenticated user.
86

9.11.2. Countermeasures

 Perform thorough input validation. Your applications must ensure that input from query
strings, form fields, and cookies are valid for the application. Consider all user input as
possibly malicious, and filter or sanitize for the context of the downstream code. Validate
all input for known valid values and then reject all other input. Use regular expressions to
validate input data received via HTML form fields, cookies, and query strings.

 Use HTMLEncode and URLEncode functions to encode any output that includes user
input. This converts executable script into harmless HTML.

9.12. SQL Injection

A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands
in the database. It can occur when your application uses input to construct dynamic SQL
statements to access the database. It can also occur if your code uses stored procedures that
are passed strings that contain unfiltered user input. Using the SQL injection attack, the attacker
can execute arbitrary commands in the database. The issue is magnified if the application
uses an over-privileged account to connect to the database. In this instance it is possible to use
the database server to run operating system commands and potentially compromise other
servers, in addition to being able to retrieve, manipulate, and destroy data.

9.12.1. Example of SQL Injection

Your application may be susceptible to SQL injection attacks when you incorporate
invalidated user input into database queries. Particularly susceptible is code that constructs
dynamic SQL statements with unfiltered user input. Consider the following code:

SqlDataAdapter myCommand = new SqlDataAdapter(

“SELECT * FROM Users

WHERE UserName =’” + txtuid.Text + “‘“, conn);

Attackers can inject SQL by terminating the intended SQL statement with the single quote
character followed by a semicolon character to begin a new command, and then executing the
command of their choice. Consider the following character string entered into the txtuid field.
 87

‘; DROP TABLE Customers–

This results in the following statement being submitted to the database for execution.

SELECT * FROM Users WHERE UserName=’’; DROP TABLE Customers —’

This deletes the Customers table, assuming that the application’s login has sufficient
permissions in the database (another reason to use a least privileged login in the database).
The double dash (—) denotes a SQL comment and is used to comment out any other characters
added by the programmer, such as the trailing quote.

Note The semicolon is not actually required. SQL Server will execute two commands
separated by spaces.

Other more subtle tricks can be performed. Supplying this input to the txtuid field:

‘ OR 1=1–

Builds this command:

SELECT * FROM Users WHERE UserName=’’ OR 1=1–

Because 1=1 is always true, the attacker retrieves every row of data from the Users
table.

9.12.2. Countermeasures

 Perform thorough input validation. Your application should validate its input prior to sending
a request to the database.

 Use parameterized stored procedures for database access to ensure that input strings
are not treated as executable statements. If you cannot use stored procedures, use SQL
parameters when you build SQL commands.

 Use least privileged accounts to connect to the database.

88

9.13. Canonicalization

Different forms of input that resolve to the same standard name (the canonical name), is
referred to as canonicalization. Code is particularly susceptible to canonicalization issues if it
makes security decisions based on the name of a resource that is passed to the program as
input. Files, paths, and URLs are resource types that are vulnerable to canonicalization because
in each case there are many different ways to represent the same name. File names are also
problematic. For example, a single file could be represented as:

c:\temp\somefile.dat

somefile.dat

c:\temp\subdir\..\somefile.dat

c:\ temp\ somefile.dat

..\somefile.dat

Ideally, your code does not accept input file names. If it does, the name should be converted
to its canonical form prior to making security decisions, such as whether access should be
granted or denied to the specified file.

9.13.1. Countermeasures

 Avoid input file names where possible and instead use absolute file paths that cannot be
changed by the end user.

 Make sure that file names are well formed (if you must accept file names as input) and
validate them within the context of your application. For example, check that they are
within your application’s directory hierarchy.

 Ensure that the character encoding is set correctly to limit how input can be represented.
Check that your application’s Web.config has set the request Encoding and response
Encoding attributes on the <globalization> element.
 89

9.14. Summary

 Trojan is a malicious program used to control a victim’s computer from a remote location.
Malicious program used to control a victim’s computer from a remote location.

 Virus is a Self-replicating program that attaches itself to other programs and files.

 Worm is a Illegitimate programs that replicate themselves usually over the network.

 Footprinting is the first and most convenient way that hackers use to gather information
about computer systems and the companies they belong to.

 If an attacker can execute malicious code on your server, the attacker can either
compromise server resources or mount further attacks against downstream systems.

 Inadequate access controls could allow an unauthorized user to access restricted

information or perform restricted operations.

 Input validation is a security issue if an attacker discovers that your application makes
unfounded assumptions about the type, length, format, or range of input data. The attacker
can then supply carefully crafted input that compromises your application.

 A buffer overflow happens when a program tries to fill a block of memory (a memory
buffer) with more data than the buffer was supposed to hold.

9.15. Review Questions

1. Define Canonicalization.

2. Categorize the threats by application vulnerability.

3. Differentiate Trojan, Virus and worms with its purpose.

4. Illustrate the process of SQL injection with examples.

90

9.16. Further Reading

 http://www.exforsys.com/tutorials/client-server/client-server-security.html

 https://www.client-server.com/disciplines/cyber-security

 https://study.com/academy/lesson/what-is-a-client-server-network-definition-advantages-
disadvantages.html

 https://www.sciencedirect.com/topics/social-sciences/client-server

 https://www.secureblackbox.com/kb/articles/Securing-client-server-app.rst

 https://www.publicpower.org/periodical/article/anatomy-attack

 https://www.riskiq.com/research/anatomy-of-an-attack-surface/

 https://intellipaat.com/blog/tutorial/ethical-hacking-cyber-security-tutorial/sniffing-attacks/

 http://www.rroij.com/open-access/network-attacks-and-their-countermeasures.php?
aid=42585

 https://www.greycampus.com/blog/information-security/what-is-a-sniffing-attack-and-how-
can-you-defend-it
 91

UNIT 10
AUTHENTICATION AND AUTHORIZATION

Learning Objectives

 In this chapter, the concept authentication and authorization is discussed along with the
threats that exploit it.

 A learner will be able to understand the top threats that exploit the authentication and
authorization which includes eavesdropping, cookie replay attack, credential theft etc..
And each threat is discussed along with its countermeasures respectively.

Structure
10.1 Authentication

10.2 Authorization

10.3 Configuration Management

10.4 Sensitive Data

10.5 Summary

10.6 Review Questions

10.7 Further Reading

10.1. Authentication

Depending on your requirements, there are several available authentication mechanisms

to choose from. If they are not correctly chosen and implemented, the authentication mechanism
can expose vulnerabilities that attackers can exploit to gain access to your system. The top
threats that exploit authentication vulnerabilities include:

 Network eavesdropping

 Brute force attacks

92

 Dictionary attacks

 Cookie replay attacks

 Credential theft

10.1.1. Network Eavesdropping

If authentication credentials are passed in plaintext from client to server, an attacker armed
with rudimentary network monitoring software on a host on the same network can capture
traffic and obtain user names and passwords.

Countermeasures to prevent network eavesdropping include:

 Use authentication mechanisms that do not transmit the password over the network
such as Kerberos protocol or Windows authentication.

 Make sure passwords are encrypted (if you must transmit passwords over the network)
or use an encrypted communication channel, for example with SSL.

10.1.2. Brute Force Attacks

Brute force attacks rely on computational power to crack hashed passwords or other
secrets secured with hashing and encryption. To mitigate the risk, use strong passwords.

10.1.3. Dictionary Attacks

This attack is used to obtain passwords. Most password systems do not store plaintext
passwords or encrypted passwords. They avoid encrypted passwords because a compromised
key leads to the compromise of all passwords in the data store. Lost keys mean that all passwords
are invalidated.

Most user store implementations hold password hashes (or digests). Users are
authenticated by re-computing the hash based on the user-supplied password value and
comparing it against the hash value stored in the database. If an attacker manages to obtain the
list of hashed passwords, a brute force attack can be used to crack the password hashes.
 93

With the dictionary attack, an attacker uses a program to iterate through all of the words
in a dictionary (or multiple dictionaries in different languages) and computes the hash for each
word. The resultant hash is compared with the value in the data store. Weak passwords such
as “Yankees” (a favorite team) or “Mustang” (a favorite car) will be cracked quickly. Stronger
passwords such as “?You’LlNevaFiNdMeyePasSWerd!”, are less likely to be cracked.

Note: Once the attacker has obtained the list of password hashes, the dictionary attack
can be performed offline and does not require interaction with the application.

Countermeasures to prevent dictionary attacks include:

 Use strong passwords that are complex, are not regular words, and contain a mixture of
upper case, lower case, numeric, and special characters.

 Store non-reversible password hashes in the user store. Also combine a salt value (a
cryptographically strong random number) with the password hash.

10.1.4. Cookie Replay Attacks

 With this type of attack, the attacker captures the user’s authentication cookie using
monitoring software and replays it to the application to gain access under a false identity.

Countermeasures to prevent cookie replay include:

 Use an encrypted communication channel provided by SSL whenever an authentication

cookie is transmitted.

 Use a cookie timeout to a value that forces authentication after a relatively short time
interval. Although this doesn’t prevent replay attacks, it reduces the time interval in which
the attacker can replay a request without being forced to re-authenticate because the
session has timed out.

10.1.5. Credential Theft

If your application implements its own user store containing user account names and
passwords, compare its security to the credential stores provided by the platform, for example,
94

a Microsoft Active Directory® directory service or Security Accounts Manager (SAM) user store.
Browser history and cache also store user login information for future use. If the terminal is
accessed by someone other than the user who logged on, and the same page is hit, the saved
login will be available.

Countermeasures to help prevent credential theft include:

 Use and enforce strong passwords.

 Store password verifiers in the form of one way hashes with added salt.

 Enforce account lockout for end-user accounts after a set number of retry attempts.

 To counter the possibility of the browser cache allowing login access, create functionality
that either allows the user to choose to not save credentials, or force this functionality as
a default policy.

10.2. Authorization

Based on user identity and role membership, authorization to a particular resource or

service is either allowed or denied. Top threats that exploit authorization vulnerabilities include:

 Elevation of privilege

 Disclosure of confidential data

 Data tampering

 Luring attacks

10.2.1. Elevation of Privilege

When you design an authorization model, you must consider the threat of an attacker
trying to elevate privileges to a powerful account such as a member of the local administrators
group or the local system account. By doing this, the attacker is able to take complete control
over the application and local machine. For example, with classic ASP programming, calling
the RevertToSelf API from a component might cause the executing thread to run as the local
system account with the most power and privileges on the local machine.
 95

The main countermeasure that you can use to prevent elevation of privilege is to use
least privileged process, service, and user accounts.

10.2.2. Disclosure of Confidential Data

The disclosure of confidential data can occur if sensitive data can be viewed by
unauthorized users. Confidential data includes application specific data such as credit card
numbers, employee details, financial records and so on together with application configuration
data such as service account credentials and database connection strings. To prevent the
disclosure of confidential data you should secure it in persistent stores such as databases and
configuration files, and during transit over the network. Only authenticated and authorized users
should be able to access the data that is specific to them. Access to system level configuration
data should be restricted to administrators.

Countermeasures to prevent disclosure of confidential data include:

 Perform role checks before allowing access to the operations that could potentially reveal
sensitive data.

 Use strong ACLs to secure Windows resources.

 Use standard encryption to store sensitive data in configuration files and databases.

10.2.3. Data Tampering

Data tampering refers to the unauthorized modification of data.

Countermeasures to prevent data tampering include:

 Use strong access controls to protect data in persistent stores to ensure that only
authorized users can access and modify the data.

 Use role-based security to differentiate between users who can view data and users who
can modify data.
96

10.2.4. Luring Attacks

A luring attack occurs when an entity with few privileges is able to have an entity with
more privileges perform an action on its behalf.

To counter the threat, you must restrict access to trusted code with the appropriate
authorization. Using .NET Framework code access security helps in this respect by authorizing
calling code whenever a secure resource is accessed or a privileged operation is performed.

10.3. Configuration Management

Many applications support configuration management interfaces and functionality to allow

operators and administrators to change configuration parameters, update Web site content,
and to perform routine maintenance. Top configuration management threats include:

 Unauthorized access to administration interfaces

 Unauthorized access to configuration stores

 Retrieval of plaintext configuration secrets

 Lack of individual accountability

 Over-privileged process and service accounts

10.3.1. Unauthorized Access to Administration Interfaces

Administration interfaces are often provided through additional Web pages or separate
Web applications that allow administrators, operators, and content developers to managed site
content and configuration. Administration interfaces such as these should be available only to
restricted and authorized users. Malicious users able to access a configuration management
function can potentially deface the Web site, access downstream systems and databases, or
take the application out of action altogether by corrupting configuration data.

Countermeasures to prevent unauthorized access to administration interfaces include:

 Minimize the number of administration interfaces.

 97

 Use strong authentication, for example, by using certificates.

 Use strong authorization with multiple gatekeepers.

 Consider supporting only local administration. If remote administration is absolutely

essential, use encrypted channels, for example, with VPN technology or SSL, because of
the sensitive nature of the data passed over administrative interfaces. To further reduce
risk, also consider using IPSec policies to limit remote administration to computers on
the internal network.

10.3.2. Unauthorized Access to Configuration Stores

Because of the sensitive nature of the data maintained in configuration stores, you should
ensure that the stores are adequately secured.

Countermeasures to protect configuration stores include:

 Configure restricted ACLs on text-based configuration files such as Machine.config and

Web.config.

 Keep custom configuration stores outside of the Web space. This removes the potential
to download Web server configurations to exploit their vulnerabilities.

10.3.4. Retrieval of Plaintext Configuration Secrets

Restricting access to the configuration store is a must. As an important defense in depth

mechanism, you should encrypt sensitive data such as passwords and connection strings.
This helps prevent external attackers from obtaining sensitive configuration data. It also prevents
rogue administrators and internal employees from obtaining sensitive details such as database
connection strings and account credentials that might allow them to gain access to other
systems.

10.3.5. Lack of Individual Accountability

Lack of auditing and logging of changes made to configuration information threatens the
ability to identify when changes were made and who made those changes. When a breaking
change is made either by an honest operator error or by a malicious change to grant privileged
98

access, action must first be taken to correct the change. Then apply preventive measures to
prevent breaking changes to be introduced in the same manner. Keep in mind that auditing and
logging can be circumvented by a shared account; this applies to both administrative and user/
application/service accounts. Administrative accounts must not be shared. User/application/
service accounts must be assigned at a level that allows the identification of a single source of
access using the account, and that contains any damage to the privileges granted that account.

10.3.6. Over-privileged Application and Service Accounts

If application and service accounts are granted access to change configuration information
on the system, they may be manipulated to do so by an attacker. The risk of this threat can be
mitigated by adopting a policy of using least privileged service and application accounts. Be
wary of granting accounts the ability to modify their own configuration information unless explicitly
required by design.

10.4. Sensitive Data

Sensitive data is subject to a variety of threats. Attacks that attempt to view or modify
sensitive data can target persistent data stores and networks. Top threats to sensitive data
include:

 Access to sensitive data in storage

 Network eavesdropping

 Data tampering

10.4.1. Access to Sensitive Data in Storage

You must secure sensitive data in storage to prevent a user—malicious or otherwise—

from gaining access to and reading the data.

Countermeasures to protect sensitive data in storage include:

 Use restricted ACLs on the persistent data stores that contain sensitive data.

 Store encrypted data.

 99

 Use identity and role–based authorization to ensure that only the user or users with the
appropriate level of authority are allowed access to sensitive data. Use role-based security
to differentiate between users who can view data and users who can modify data.

10.4.2. Network Eavesdropping

The HTTP data for Web application travels across networks in plaintext and is subject to
network eavesdropping attacks, where an attacker uses network monitoring software to capture
and potentially modify sensitive data.

Countermeasures to prevent network eavesdropping and to provide privacy include:

 Encrypt the data.

 Use an encrypted communication channel, for example, SSL.

10.4.3. Data Tampering

Data tampering refers to the unauthorized modification of data, often as it is passed over
the network.

One countermeasure to prevent data tampering is to protect sensitive data passed across
the network with tamper-resistant protocols such as hashed message authentication codes
(HMACs).

An HMAC provides message integrity in the following way:

1. The sender uses a shared secret key to create a hash based on the message payload.

2. The sender transmits the hash along with the message payload.

3. The receiver uses the shared key to recalculate the hash based on the received message
payload. The receiver then compares the new hash value with the transmitted hash value.
If they are the same, the message cannot have been tampered with.

10.5. Summary

 Brute force attacks rely on computational power to crack hashed passwords or other
secrets secured with hashing and encryption.
100

 Dictionary attack is used to obtain passwords.

 With Cookie Replay Attack, the attacker captures the user’s authentication cookie using
monitoring software and replays it to the application to gain access under a false identity.

 The disclosure of confidential data can occur if sensitive data can be viewed by
unauthorized users. Confidential data includes application specific data such as credit
card numbers, employee details, financial records and so on together with application
configuration data such as service account credentials and database connection strings.

 Data tampering refers to the unauthorized modification of data.

 A luring attack occurs when an entity with few privileges is able to have an entity with
more privileges perform an action on its behalf.

 Lack of auditing and logging of changes made to configuration information threatens the
ability to identify when changes were made and who made those changes.

 The HTTP data for Web application travels across networks in plaintext and is subject to
network eavesdropping attacks, where an attacker uses network monitoring software to
capture and potentially modify sensitive data.

 Data tampering is to protect sensitive data passed across the network with tamper-resistant
protocols such as hashed message authentication codes (HMACs).

10.6. Review Questions

1. Explain the top threats that exploit the authentication.

2. Write short note on Luring Attack.

3. What threats that exploit the configuration management?

4. Define Data Tampering with its countermeasures.

 101

10.7. Further Reading

 https://auth0.com/docs/security/common-threats

 https://tools.ietf.org/html/rfc6819

 http://projects.webappsec.org/w/page/13246940/Insufficient%20Authorization

 http://oaji.net/articles/2016/3207-1468388763.pdf

 https://pages.nist.gov/mobile-threat-catalogue/authentication.html

 https://www.coursera.org/lecture/cyber-threats-attack-vectors/authentication-based-
attacks-uxiNt

 https://www.okta.com/security-blog/2018/03/5-identity-attacks-that-exploit-your-broken-
authentication/

 https://www.upguard.com/blog/5-configuration-management-boss

 https://sequretek.com/innovation/transforming-with-sequretek/vulnerability-and-threat-
management/

 https://www.slideshare.net/ChristopherFurton/christopherfurtonconfigurationmgmt
componentofvulnerabilitymgmt
102

UNIT 11
SESSION MANAGEMENT

Learning Objectives

 In this chapter, the concept of threats in Session management, Cryptography, Parameter

manipulation is discussed.

 A learner will be able to understand the threats faced by various application vulnerabilities
with its countermeasures.

Structure
11.1 Session Management

11.2 Cryptography

11.3 Parameter Manipulation

11.4 Exception Management

11.5 Auditing and Logging

11.6 Summary

11.7 Review Questions

11.8 Further Reading

11.1 Session Management

Session management for Web applications is an application layer responsibility. Session

security is critical to the overall security of the application.

Top session management threats include:

 Session hijacking

 Session replay

 Man in the middle

 103

11.1.1 Session Hijacking

A session hijacking attack occurs when an attacker uses network monitoring software to
capture the authentication token (often a cookie) used to represent a user’s session with an
application. With the captured cookie, the attacker can spoof the user’s session and gain access
to the application. The attacker has the same level of privileges as the legitimate user.

Countermeasures to prevent session hijacking include:

 Use SSL to create a secure communication channel and only pass the authentication
cookie over an HTTPS connection.

 Implement logout functionality to allow a user to end a session that forces authentication
if another session is started.

 Make sure you limit the expiration period on the session cookie if you do not use SSL.
Although this does not prevent session hijacking, it reduces the time window available to
the attacker.

11.1.2. Session Replay

Session replay occurs when a user’s session token is intercepted and submitted by an
attacker to bypass the authentication mechanism. For example, if the session token is in plaintext
in a cookie or URL, an attacker can sniff it. The attacker then posts a request using the hijacked
session token.

Countermeasures to help address the threat of session replay include:

 Re-authenticate when performing critical functions. For example, prior to performing a

monetary transfer in a banking application, make the user supply the account password
again.

 Expire sessions appropriately, including all cookies and session tokens.

 Create a “do not remember me” option to allow no session data to be stored on the client.
104

11.1.3. Man in the Middle Attacks

A man in the middle attack occurs when the attacker intercepts messages sent between
you and your intended recipient. The attacker then changes your message and sends it to the
original recipient. The recipient receives the message, sees that it came from you, and acts on
it. When the recipient sends a message back to you, the attacker intercepts it, alters it, and
returns it to you. You and your recipient never know that you have been attacked.

Any network request involving client-server communication, including Web requests,

Distributed Component Object Model (DCOM) requests, and calls to remote components and
Web services, are subject to man in the middle attacks.

Countermeasures to prevent man in the middle attacks include:

 Use cryptography. If you encrypt the data before transmitting it, the attacker can still intercept
it but cannot read it or alter it. If the attacker cannot read it, he or she cannot know which
parts to alter. If the attacker blindly modifies your encrypted message, then the original
recipient is unable to successfully decrypt it and, as a result, knows that it has been
tampered with.

 Use Hashed Message Authentication Codes (HMACs). If an attacker alters the message,
the recalculation of the HMAC at the recipient fails and the data can be rejected as invalid.

11.2. Cryptography

Most applications use cryptography to protect data and to ensure it remains private and
unaltered. Top threats surrounding your application’s use of cryptography include:

 Poor key generation or key management

 Weak or custom encryption

 Checksum spoofing
 105

11.2.1. Poor Key Generation or Key Management

Attackers can decrypt encrypted data if they have access to the encryption key or can
derive the encryption key. Attackers can discover a key if keys are managed poorly or if they
were generated in a non-random fashion.

Countermeasures to address the threat of poor key generation and key management
include:

 Use built-in encryption routines that include secure key management. Data Protection
application programming interface (DPAPI) is an example of an encryption service provided
on Windows 2000 and later operating systems where the operating system manages the
key.

 Use strong random key generation functions and store the key in a restricted location—
for example, in a registry key secured with a restricted ACL—if you use an encryption
mechanism that requires you to generate or manage the key.

 Encrypt the encryption key using DPAPI for added security.

 Expire keys regularly.

11.2.2. Weak or Custom Encryption

An encryption algorithm provides no security if the encryption is cracked or is vulnerable

to brute force cracking. Custom algorithms are particularly vulnerable if they have not been
tested. Instead, use published, well-known encryption algorithms that have withstood years of
rigorous attacks and scrutiny.

Countermeasures that address the vulnerabilities of weak or custom encryption include:

 Do not develop your own custom algorithms.

 Use the proven cryptographic services provided by the platform.

 Stay informed about cracked algorithms and the techniques used to crack them.
106

11.2.3. Checksum Spoofing

Do not rely on hashes to provide data integrity for messages sent over networks. Hashes
such as Safe Hash Algorithm (SHA1) and Message Digest compression algorithm (MD5) can
be intercepted and changed. Consider the following base 64 encoding UTF-8 message with an
appended Message Authentication Code (MAC).

Plaintext: Place 10 orders.

Hash: T0mUNdEQh13IO9oTcaP4FYDX6pU=

If an attacker intercepts the message by monitoring the network, the attacker could update
the message and recompute the hash (guessing the algorithm that you used). For example,
the message could be changed to:

Plaintext: Place 100 orders.

Hash: oEDuJpv/ZtIU7BXDDNv17EAHeAU=

When recipients process the message, and they run the plaintext (“Place 100 orders”)
through the hashing algorithm, and then recompute the hash, the hash they calculate will be
equal to whatever the attacker computed.

To counter this attack, use a MAC or HMAC. The Message Authentication Code Triple
Data Encryption Standard (MACTripleDES) algorithm computes a MAC, and HMACSHA1
computes an HMAC. Both use a key to produce a checksum. With these algorithms, an attacker
needs to know the key to generate a checksum that would compute correctly at the receiver.

11.3. Parameter Manipulation

Parameter manipulation attacks are a class of attack that relies on the modification of the
parameter data sent between the client and Web application. This includes query strings, form
fields, cookies, and HTTP headers. Top parameter manipulation threats include:

 Query string manipulation

 Form field manipulation

 107

 Cookie manipulation

 HTTP header manipulation

11.3.1. Query String Manipulation

Users can easily manipulate the query string values passed by HTTP GET from client to
server because they are displayed in the browser’s URL address bar. If your application relies
on query string values to make security decisions, or if the values represent sensitive data
such as monetary amounts, the application is vulnerable to attack.

Countermeasures to address the threat of query string manipulation include:

 Avoid using query string parameters that contain sensitive data or data that can influence
the security logic on the server. Instead, use a session identifier to identify the client and
store sensitive items in the session store on the server.

 Choose HTTP POST instead of GET to submit forms.

 Encrypt query string parameters.

11.3.2. Form Field Manipulation

The values of HTML form fields are sent in plaintext to the server using the HTTP POST
protocol. This may include visible and hidden form fields. Form fields of any type can be easily
modified and client-side validation routines bypassed. As a result, applications that rely on form
field input values to make security decisions on the server are vulnerable to attack.

To counter the threat of form field manipulation, instead of using hidden form fields, use
session identifiers to reference state maintained in the state store on the server.

11.3.3. Cookie Manipulation

Cookies are susceptible to modification by the client. This is true of both persistent and
memory-resident cookies. A number of tools are available to help an attacker modify the contents
of a memory-resident cookie. Cookie manipulation is the attack that refers to the modification of
a cookie, usually to gain unauthorized access to a Web site.
108

While SSL protects cookies over the network, it does not prevent them from being modified
on the client computer. To counter the threat of cookie manipulation, encrypt or use an HMAC
with the cookie.

11.3.4. HTTP Header Manipulation

HTTP headers pass information between the client and the server. The client constructs
request headers while the server constructs response headers. If your application relies on
request headers to make a decision, your application is vulnerable to attack. Do not base your
security decisions on HTTP headers. For example, do not trust the HTTP Referer to determine
where a client came from because this is easily falsified.

11.4. Exception Management

Exceptions that are allowed to propagate to the client can reveal internal implementation
details that make no sense to the end user but are useful to attackers. Applications that do not
use exception handling or implement it poorly are also subject to denial of service attacks. Top
exception handling threats include:

 Attacker reveals implementation details

 Denial of service

11.4.1. Attacker Reveals Implementation Details

One of the important features of the .NET Framework is that it provides rich exception
details that are invaluable to developers. If the same information is allowed to fall into the hands
of an attacker, it can greatly help the attacker exploit potential vulnerabilities and plan future
attacks. The type of information that could be returned includes platform versions, server names,
SQL command strings, and database connection strings.

Countermeasures to help prevent internal implementation details from being revealed to

the client include:

 Use exception handling throughout your application’s code base.

 Handle and log exceptions that are allowed to propagate to the application boundary.

 Return generic, harmless error messages to the client.

 109

11.4.2. Denial of Service

Attackers will probe a Web application, usually by passing deliberately malformed input.
They often have two goals in mind. The first is to cause exceptions that reveal useful information
and the second is to crash the Web application process. This can occur if exceptions are not
properly caught and handled.

Countermeasures to help prevent application-level denial of service include:

 Thoroughly validate all input data at the server.

 Use exception handling throughout your application’s code base.

11.5. Auditing and Logging

Auditing and logging should be used to help detect suspicious activity such as footprinting
or possible password cracking attempts before an exploit actually occurs. It can also help deal
with the threat of repudiation. It is much harder for a user to deny performing an operation if a
series of synchronized log entries on multiple servers indicate that the user performed that
transaction.

Top auditing and logging related threats include:

 User denies performing an operation

 Attackers exploit an application without leaving a trace

 Attackers cover their tracks

11.5.1. User Denies Performing an Operation

The issue of repudiation is concerned with a user denying that he or she performed an
action or initiated a transaction. You need defense mechanisms in place to ensure that all user
activity can be tracked and recorded.

Countermeasures to help prevent repudiation threats include:

110

 Audit and log activity on the Web server and database server, and on the application
server as well, if you use one.

 Log key events such as transactions and login and logout events.

 Do not use shared accounts since the original source cannot be determined.

11.5.2. Attackers Exploit an Application without Leaving a Trace

System and application-level auditing is required to ensure that suspicious activity does
not go undetected.

Countermeasures to detect suspicious activity include:

 Log critical application level operations.

 Use platform-level auditing to audit login and logout events, access to the file system, and
failed object access attempts.

 Back up log files and regularly analyze them for signs of suspicious activity.

11.5.3. Attackers Cover Their Tracks

Your log files must be well-protected to ensure that attackers are not able to cover their
tracks.

Countermeasures to help prevent attackers from covering their tracks include:

 Secure log files by using restricted ACLs.

 Relocate system log files away from their default locations.

11.6. Summary

 Session management for Web applications is an application layer responsibility.

 Top Session management threats includes Session hijacking, Session replay and Man in
the middle.
 111

 A session hijacking attack occurs when an attacker uses network monitoring software to
capture the authentication token (often a cookie) used to represent a user’s session with
an application.

 Session replay occurs when a user’s session token is intercepted and submitted by an
attacker to bypass the authentication mechanism.

 A man in the middle attack occurs when the attacker intercepts messages sent between
you and your intended recipient.

 An encryption algorithm provides no security if the encryption is cracked or is vulnerable

to brute force cracking.

 Exceptions that are allowed to propagate to the client can reveal internal implementation
details that make no sense to the end user but are useful to attackers.

 Auditing and logging should be used to help detect suspicious activity such as footprinting
or possible password cracking attempts before an exploit actually occurs.

11.7. Review Questions

1. Explain the top threats in the session management.

2. Illustrate the threats faced by the application that uses cryptography.

3. Elaborate the threats in the parameter manipulation.

4. Write short note on cookie manipulation.

11.8. Further Reading

 https://www.netsparker.com/blog/web-security/session-hijacking/

 https://www.imperva.com/learn/application-security/session-hijacking/

 https://www.checkmarx.com/knowledge/knowledgebase/session-hijacking

 https://www.cgisecurity.com/owasp/html/ch11s04.html

 https://lonewolfonline.net/parameter-tampering-protect/

 https://owasp.org/www-community/Improper_Error_Handlingml
112

UNIT 12
MOBILE PLATFORMS

Learning Objectives
 In this chapter, the concept of mobile platforms is discussed along with its security issues.

 A learner will be able to understand about the mobile device attacks and things that need
to be considered for secure mobile application development. The learner will also get an
idea on various mobile platforms and its security.

Structure
12.1. Introduction
12.2. What is mobile device
12.3. Mobile device attacks
12.4. Secure Mobile Application Development
12.5. Android Security
12.6. IOS Security
12.7. Blackberry Security
12.8. Windows Security
12.9. Symbian OS Security
12.10. WebOS Security
12.11. Summary
12.12. Review Questions

12.13. Further Reading

12.1. Introduction

We rely on our phones to process and store reams of personal digital data. Our digital
activities - from checking bank balances to paying for a product with a tap of the screen, to
sending friends and family messages over social media, to accessing work emails remotely -
have turned our phones into a goldmine of personal information. It’s likely that by 2020, there will
be more than 6 billion smartphone users in the world.
 113

How secure is your mobile device? It’s easy to forget that your mobile phone is essentially
a pocket-sized computer and that, just as with any device that can connect to the Internet,
mobile phones are at risk of a cyberattack.

The good news is that mobile malware is still relatively uncommon, with the total rate of
infections standing at 8 percent. Mobile malware is outnumbered by PC attacks 40-1, as mobiles
operate on far more customized systems, and malware must be tailored to a specific system.

However, mobile malware has been increasing at an alarming rate. There was a 27 percent
increase in new mobile malware in the last quarter of 2017, according to McAfee. Securing
your mobile phone should be a top priority, both for personal and business use.

12.2. What is mobile device

Mobile device usually is a small, portable size computing device, which allows user to
input information through touchscreen or small keyboard on the device. Comparing with
conventional computer, mobile device is easily carried out but provides much computer
functionality, such as processing, communication, data storage. PDA and smartphone are the
two most popular mobile devices. Smartphone combines functionality of mobile phone and
PDA. This paper mainly focuses on analysis of security issues on smartphone. Smartphone
usually provides many computer’s services, such as web browser, video or audio player, video
call, GPS, Wi-Fi, and etc. The top three successful smartphone brands are Google Android,
Apple iPhone, and BlackBerry. The following sections will analyze and compare feature and
security issue of these three kinds of smartphone.

12.3. Mobile Device Attacks

Mobile Security has become a crucial aspect of protecting sensitive data and information.
Malicious attacks once focused on PC’s have now shifted to mobile phones and applications.
Mobile makers are aware of this fact and are investing heavily in security.

Mobile device attacks can be split into 4 main categories:

 OS Attacks: Loopholes in operating systems create vulnerabilities that are open to attack.
Vendors try to solve these with patches.
114

 Mobile App Attacks: Poor coding and improper development creates loopholes and
compromises security.

 Communication Network Attacks: Communications such as Bluetooth and Wi-Fi

connections make devices vulnerable.

 Malware Attacks: There has been a constant rise in malware for mobile devices. The
focus is on deleting files and creating chaos.

These categories are a generalization of the various types of attacks and now we’ll take a
closer look into the types of issues that are currently plaguing mobiles. This is not an exhaustive
list by any means, but one will begin to understand just how at risk mobile devices are.

Physical Security

Lookout Labs estimated that a mobile phone was lost in the USA every 3.5 seconds in
2011 – and that nearly all who found lost devices tried to access the information on the phone.
Now, I hope the “access” was an attempt to determine the owner, but who knows? Even
temporarily misplacing a phone can put sensitive data at risk.

Multiple User Logging

Mobile phones have come a long way, but they are still not versatile machines like
computers. Multiple users on mobile devices still have trouble in opening unique protected
accounts. Simply put, what one user does on a mobile device is hardly a private affair.
Customizable 3rd party solutions are available, but it’s much safer when phones are not shared.

Secure Data Storage

Mobile phones need good file encrypting for strong security. After all, who wants sensitive
corporate data to end up in the wrong hands? Without the proper encryption, not only are
personal documents up for grabs, but also passwords to bank, credit card and even business
apps. Encrypting sensitive data ensures would-be thieves gain a whole lot of nothing.
 115

Mobile Browsing

Perhaps one of the best features of mobile devices is the ability to browse the web on the
go, but this also opens up the mobile phones to security risks. The problem is that users cannot
see the whole URL or link, much less verify whether the link or URL is safe. That means that
users could easily browse their way into a phishing-related attack.

Application Isolation

There are mobile applications for just about everything, from social networking to banking.
Before installing any app that comes your way, be sure to read the application access request
for permission agreement. This often overlooked agreement contains valuable information
regarding specific permissions on how the app is to access your device.

Be mindful of what your application purports to do and what it is that it actually does.
Chances are a calculator application does not need access to the internet or your personal
information.

System Updates

People have a tendency to point fingers at mobile device vendors when it comes to security
mishaps, but they aren’t always to blame. Updates and patches designed to fix issues in mobile
devices are not quite as cut and dry as with PCs. Mobile devices vendors often release updates
and patches, but unfortunately carriers don’t always stream them due to commercial or
bureaucratic reasons.

Mobile Device Coding Issues

Sometimes developers make honest mistakes, inadvertently creating security

vulnerabilities via poor coding efforts. Many times there is bad implementation of encrypted
channels for data transmission or even improper password protection. Ineffective development
can lead to security weaknesses whether in PCs or mobile phones.
116

Bluetooth Attacks

As easy as Bluetooth is to use, it can be just as easy for attackers to gain access to one’s
phone and everything stored within. It’s fairly simple for a hacker to run a program to locate
available Bluetooth connections and Bingo – they’re in. It’s important to remember to disable
the Bluetooth functionality when not in use.

Malware on the Rise

As is the case with computers, malware is rather damaging to mobile phones. The news
does not get any better either. 2014 is projected to be far worse, leaving industry leaders and
mobile device users no choice but to become proactive about mobile protection. For example,
take the Android malware incident in January which impacted more than 600,000 phones.

Serious Threats in New Features

Newly added features and updates are serious risks too. The Neat Field Communication,
or NFC, technology is a prime example. NFC is designed to allow people to use their mobile
phones as a wallet to purchase products. Unfortunately, all one needs to do to take over the
mobile device is brush a NFC chip embedded tag over the phone.

It should not come as a surprise that security is such a problem considering the wide
variety of mobile devices and smartphones available today. Every phone and mobile OS has its
own unique security issues and one should always take precaution, especially as we are
becoming increasingly dependent on our mobile devices.

12.4. Secure Mobile Application Development

Mobile apps are subject to similar security considerations and risks as other applications,
thus general best practices for application development are also relevant to mobile apps
development. Due to varying use cases, usage patterns and various mobile platforms, mobile
apps developers should also take note of the remote web services, platform integration issues
and insecurity of mobile devices. Developer should consider the following areas as shwon in
Figure 12.1 to build a secure mobile app:
 117

Figure 12.1 : Areas to build a secure mobile app

12.4.1. General Considerations in Mobile App Development

 Adopt security in mind approach and apply adequate protection for sensitive data being
handled.

 Inform users on what information the app would access or upload, and for what purpose.

 Provide a personal information collection statement if personal information will be collected.

 Apply “least privilege” principle to run the app with the least amount of system privileges
and access rights.

 Develop and implement the app according to best practices.

 Design and provision an app to allow updates for security patches.

 Refuse executing the app or alerting users in case jailbreaking or rooting is detected if the
app would process critical / sensitive data.

 Validate all client provided data before processing with expected whitelist of data types,
data range, and data length.

 Inform users and obtain consent for any large data consuming app activities.
118

12.4.2. Authentication and Session Management

 Avoid solely using device-provided identifier (like UID or MAC address) to identify the
device, but rather leverage identifiers specific to the app as well as the device.

 Adopt appropriate authentication mechanism, consider two-factor authentication based

on risk assessment of the mobile app, such as processing sensitive or financial
transactions.

 Avoid storing passwords, wipe/clear memory locations holding passwords directly after
their hashes are calculated.

 Always make use of the latest security mechanism provided by mobile platform to protect
user credentials.

 Perform checking at the start of each activity/screen to see if the user is in a logged in
state. If not, switch to the login state.

 Discard and clear all memory associated with the user data, and any master keys used
to decrypt the data when an app’s session is timed out or user logout.

12.4.3. Data Storage and Protection

 Only collect and disclose data which is required for business use of the app.

 Classify data storage according to sensitivity and apply controls accordingly. Process,
store and use data according to its classification.

 Application data should not be stored in external storage unless appropriate security
measures (e.g., strong encryption) are applied.

 Use encryption with appropriate algorithm and key length when storing or caching sensitive
data to non-volatile memory and keep minimum necessary data for the use of mobile app
for the sake of data protection.

 Perform input validation and perform checking on related areas that the app can receive
data to prevent client-side code injection or screen hijack.
 119

 Discard and clear all sensitive data from memory when no longer needed.

 Adopt sandboxing technology to improve security by isolating an application to prevent

other applications from interacting with the protected app.

12.4.4. Communication Security

 Transmission of any sensitive data such as personal data or credit card information should
be protected with end-to-end encryption (e.g., TLS).

 Detect if the connection is not HTTPS with every request when it is known that the
connection should be HTTPS.

 When using TLS, the apps must enforce certificate validation functions and should not
accept self-signed and/or un-trusted certificates.

 Enable per-app VPN to secure access internal network resources from anywhere and on
any mobile devices.

12.4.5. Server Controls

 Assess backend services for mobile app for vulnerabilities and ensure that the backend
system is running with a hardened configuration with the latest security patches applied.

 Ensure sufficient logs or information are retained on the backend servers to detect and
respond to incidents and perform investigation.

 Review the code of the app to avoid unintentional data transfer between the mobile app
and backend servers.

12.4.6. On-line Payment

 Warn users and obtain consent for any cost implications for app behaviour.

 If paid-for resources are involved, security controls such as a whitelist model or re-
authentication for paid-for resources should be implemented to prevent unauthorised or
accidental access.
120

 Use secure mobile payment services if online payment is required. Use application
program interfaces (APIs)/templates provided by the official providers and follow closely
their guidelines for implementation.

 Inform user the minimum technical specifications that a mobile device must support for
the payment service (e.g., TLS supports).

 Adhere to the specific data security standard (e.g., PCI DSS) on developing a mobile app
with on-line mobile payment.

12.4.7. Code Obfuscation / Reverse Engineering

 Verify the app signature on start-up to ensure that the code has not been altered or
corrupted.

 Use obfuscation software to protect source code and hide the app details as far as possible
if it is not compiled to machine code format to prevent reverse engineering.

 Implement anti-debugging techniques (e.g., prevent a debugger from attaching to the

process) for apps containing sensitive data.

12.4.8. Use of Third-Party / Open Source Libraries

 Use reliable and/or official versions of software development tools (e.g., software
development kits, software libraries) to avoid introducing Trojan Horses or backdoors
unknowingly.

 Track third-party frameworks/ APIs used in the mobile app for security patches and perform
upgrades.

 Validate all data when received from and send to un-trusted third-party apps (e.g., ad
network) before incorporating their use in the mobile app.

12.5. Android Security

Android also provides application security through “sandbox” which isolates applications
from each other. Without permission, one application cannot access to other application’s data
or private information in the mobile device.
 121

Since Android is an open platform operating system, it provides more freedom to the
users to install their desire applications. However, it causes the system easier to be attacked at
the same time. There are some types of security issues as below.

Sometimes a flaw of software can cause significant matter. The common method to
solve the problem is that the developers recognize the flaws and provide update version of
software. For example, Skype once was truly careless to store username, contacts and some
other private information. Also in late 2010, a research found that there was a flaw in Android
that allowed attacker to download files on Secure Digital (SD) card through JavaScript or HTML.
The most recent one was that researchers found out that nearly all Android devices had a
security hole in their authentication token. It was possible to man-in-the-middle attack to the
Android devices. Now Google has already fixed this flaw.

The second type of security issue is that malicious applications can steal users’ private
data. Because some of applications may need user’s permission to access to SD card, send
messages, or access contacts, some malicious applications pretend to be innocent to access
and steal data. This may cause a serious damage to users, especially when the device stores
lots of confidential information. Although these sorts of malwares show up occasionally, Google
removes them quickly.

The third type of security issue is Root Trojans. Android default setup is to disable of
access root, but many users like to root their mobile device. This increases the potential of
being attack. Some malwares can steal users’ confidential information or even remotely control
the users’ device. Whenever Google finds out these bad applications, it will remove them quickly.
But still, this kind of Trojan does not stop, so it is better for users to ensure root safety by
themselves.

Here are some tips for users to improve the level of security for their Android phones.
First, the most simple and the most effective method are to set password of the device. Before
inputting corrects the password, attackers cannot access stored information. Fingerprint lock
is the most secure method. Since some user may concern about leakage of their biometric
information, setting up a password still can well protect the device.
122

Second, user should not change root Android device. Some users want to download
applications from unofficial third-party application store, so they choose to root their Android
device. This is a dangerous decision, because it will remove many restrictions and security
protections from default setting. Root Android phone also means to open their system-level
access, which allows many malware applications attack the device. So unless you are a master
of Android, it is a bad choice to root Android phone.

Third, although Google Android Market does not ensure that all their applications are free
of malwares, Google will remove that application from Market and remotely remove them from
devices if many users report a same malicious application. So downloading applications from
official Android Market ensures higher degree of security.

Fourth, there are some anti-virus applications available on the Market. Installing one of
popular anti-virus can help users scan bad applications and enhance the security.

Fifth, user should ensure the wireless connection is secured and turn off Wi-Fi when they
do not use it. Only connecting to familiar wireless network is also a good method to protect the
security of device.

12.6. IOS Security

According to the publication from Apple website, Apple considers the security of iPhone
for personal or business use from four aspects: device security, network security, data security
and application security.

For device security, it mainly focuses on preventing unauthorized use of device. It requires
each user to have a unique passcode to generate encryption key. This is used to protect the
private information stored on the iPhone. Also, company can set some specific settings or
restrictions when iPhone used in the business environment. The passcode policy provides
some specific requirements, such as passcode reuse history, minimum length and complex of
passcode, maximum failure attempts and so on. These polices can be enforced by install in
the configuration profiles, which are XML files. All the restrictions and polices, the authentication
credentials and other confidential information are written in configuration profiles. In order to
 123

prevent anyone from altering the setting and changing the contents of the profiles, these profiles
are signed and encrypted by Triple Data Encryption Algorithm (3DES) or Advanced Encryption
Standard 128 bits (AES-128). According to different needs of companies, iPhone supports
setting restrictions of the device. For example, it can restrict YouTube, camera, voice dialing
and etc. Through the above methods, Apple can control the device security.

For network security, Apple considers both authorized use and safe data transmission
through Wi-Fi or cellar data connection. IPhone uses standard X.509 digital certificates to
authentication which prevent unauthenticated access on confidential resource of the company.
IPhone integrates two-factor token, RSA SecurID and CRYPTO Card, to protect company’s
resource. In addition, iPhone supports many Virtual Private Network (VPN) technologies, such
as IPsec, L2TP, Cisco and PPTP. It also supports Secure Sockets Layer (SSL) VPN, which
provides a higher level of security to transmit data. In order to provide safe internet usage,
iPhone provides web traffic security through two approaches: SSL v3 and Transport Layer
Security (TLS) v1.0. It encrypts the internet communication. What’s more, iPhone supports
Remote Authentication Dial In User Service (RADIUS) and provides its wireless network security
though Wireless Application Protocol 2 (WAP). The AES encryption with counter mode provides
the highest security of wireless communication.

For data security, there are two kinds of data needed to be encrypted. One is transmitted
data and the other is stored data on the device. IPhone uses AES-256 to provide the hardware
encryption. Users can not disable this encryption. It also encrypts the data and back it up to the
iTunes. Through generating a strong key, iPhone can encrypt the transmission data. Passcode
also plays an important role in data protection, thus setting a strong passcode is critical. If
users accidentally lose the device, issuing a remote wipe command can deactivate the device
and erase all the information. In order to provide brute force passcode attempts, local wipe
command can also erase information after many failed attempts. The default attempts setting
by Apple are ten times. Of course, users can set different number by themselves.

For application security, a “sandboxed” approach prevents one application access data
of other applications. If an application wants to read other application’s data, it needs to use
application programming interface (APIs) whose services are supported by iOS. In order to
124

prevent application from being changed, all third-party providers need to use Apple issued
certification to sign their applications. The encrypted keychain ensures the security of storing
digital information. AES, RS4, or 3DES can be used to encrypt application data. AES encryption
and Secure Hash Algorithm 1 (SHA1) hashing can be use in iPhone to protect data too. What is
more, the hardware encryption can be also used to protect the application data.

Although Apple claims to provide high security of iPhone, new security holes still open up.
Recently German news showed that flaws in software running on the devices can be a serious
problem. After clicking an infected PDF file, the attacker can steal all the confidential data stored
on the device.

So some researchers give six tips to iPhone users to enhance the security. First, do
enable Auto-Lock. Although it is only a default feature which cannot specific assigned to a
security function, it includes passcode lock which is a good method of protection.

Second, do enable passcode lock, the four digit password preventing unauthorized access
to the device. This ensures the safety of the stored data.

Third, do use safety Wi-Fi. This ensures that personal Wi-Fi network is using wireless
security protocol. Enable the feature on asking to join networks function to choose network.
This limits the chance that users connect to an unsafe network. In addition, disconnect Wi-Fi
when users aren’t using it. This also reduces the chance to connect to unknown networks.

Fourth, do open mail securely. For corporate users, through Microsoft Exchange Server
to open corporate mail is much safer. For personal use, always ensuring open SSL protection
which encrypts mail information.

Fifth, do use Safari as web browser. Safari has some default security setting. Besides,
users can block pop ups on Safari setting. In addition, users can delete the cookies in a regular
time base to protect their private information. Sixth, people can use device to set specific
restrictions to their employee or their children.
 125

12.7. BlackBerry Security

BlackBerry Enterprise Solution provides industry-leading security on both stored data

and wireless transmitted data. It also provides some advanced security features for government
users.

For stored data, BES makes mandatory password authentication. After ten times of failed
attempts, all the memory on the device will be erased. All the messages, contact information,
tasks and schedules will be encrypted through AES and Password Keeper. Administrator can
remotely change the password. All local information can be locked or deleted by administrator
after receiving report of phone lost. Only authenticated command can be execute on the system
and only decrypted communication can be permitted. BES never stores users’ private data.
Only server and the users’ mobile device can decrypt data. This prevents unauthorized parties’
attack.

For wireless data, Blackberry Enterprise Solution uses both AES and 3DES to encrypt
the transmitted data. Each smartphone user has a secret key stored both on secure enterprise
account and on their device. This secret key can be regenerated by the user. BES and the
smartphone device use the secret key to encrypt or decrypt the transmitted data. Through the
whole transmission process, data is encrypted. If users want to access corporate intranets,
RSA SecurID provides two-factor authentication, both username and token care be request.
Both proxy mode and end to end mode of HTTPS communication are supported by BlackBerry.
Figure 4 shows wireless data transmission use HTTPS. In proxy mode, BEA and application
Server are connected by SSL or TLS. In end to end mode, smartphone and application server
are connected by SSL or TLS. Only trusted end points can choose the mode. Also BlackBerry
supports IBM Lotus Notes email encryption. All the third party applications are required to have
their developer’s sign. Corporation uses trusted certificate authority or self-signed certificate to
sign, e.g. Public Key Infrastructure X .509 standard.
126

Figure 12.2 : Wireless Data Transmission (Source: [SecurityFeature])

BlackBerry also provides advanced security features for government users. BlackBerry
provides devices which encrypt Federal Information Processing Standard 140-2 validation and
Secure/Multipurpose Internet Mail Extensions (S/MIME) and public key infrastructure. This meets
the requirement of Department of Defense. S/MIME provides a high level of smartphone security
and use private and public key to encrypt messages. PGP also aims to improve a high level of
security. BlackBerry Smart Card Reader allows users add more security feature to existing
security architecture. Through all above methods, BlackBerry provides a safety security
protection for users.

12.8. Windows Security

12.8.1. Malware Resistance

UEFI and Secure Boot. Rest easy that malware cannot be introduced during the boot
process (bootkits or rootkits). Only trusted, signed software is started and loaded during the
startup process. Coupled with UEFI, your devices will be less vulnerable to bootkits and rootkits.

Trusted Boot. When the boot process is secure, this feature helps ensure that all
operating system components and drivers are unmodified and free of malware. Any components
that have been tampered with will be unable to start on the device.

System and app integrity. This feature builds on Trusted Boot process security by
ensuring that all system software (such as Windows services) and apps on Windows Phone
are signed and tamper free.
 127

Windows Phone Store apps. Regardless of whether you use apps from the Windows
Phone Store or custom LOB apps, Windows Phone helps ensure that these apps are secure.
All Windows Phone Store apps are scanned for malware prior to being published in the store.

Internally developed LOB apps must be signed with the organization’s developer certificate,
ensuring that no malware can be introduced through unauthorized apps. You can even restrict
the apps that are available to users for installation from the Windows Phone Store or completely
disable access to the Windows Phone Store, if required by organizational or regulatory agency
guidelines.

AppContainer. All apps, and even some system components, on Windows Phone run
in an isolated sandbox called an AppContainer. Apps running within an AppContainer run with
least privilege and can only gain access to resources in a predefined, declarative manner. Apps
running in the AppContainer have limited to no access to the system, other apps, or data.

Vulnerability mitigations. Technologies like ASLR and DEP help ensure that malware
cannot be injected onto your devices through vulnerabilities that may be discovered later.

Internet Explorer. Browsers are one of the most targeted and common ways to spread
malware. Internet Explorer on Windows Phone helps protect the organization’s apps and data
from attack by using technologies such as AppContainers and SmartScreen.

12.8.2 Information Protection

Internal storage encryption. Confidential information in internal storage is encrypted

by industry-proven BitLocker encryption. Even if the device is lost or stolen and unauthorized
users have physical access, BitLocker helps keep your confidential information confidential.

Removable storage protection. Removable SD cards represent a potential risk for

unauthorized information disclosure. You can encrypt a partition on SD cards that contains
your organization’s apps and data. If the user loses the card or gives the card to an authorized
user, the unauthorized user cannot access the data on the encrypted partition. Need more
protection? You can completely disable the SD card usage to provide additional protection.
128

Information Rights Management. Limits data access within documents and email
messages to only authorized users within and outside of the organization. This feature brings
the same security strength of information protection as the full Windows 8.1 operating system
but on a smartphone.

S/MIME signing and encryption. Ensure that the user identity for email messages is
secure for messages sent within and outside the organization. Further protect email messages
by encrypting the message body and content so that only the designated recipients can read
the message’s contents. Managing the certificates used in S/MIME signing and encryption is
easy through your MDM system.

Communication encryption. Information sent between Windows Phone devices and

your services is protected through SSL or VPN connections. These technologies help ensure
that snooping or eavesdropping on network connections results in frustrated attackers and no
information loss.

12.8.3. Identity and Access Control

Device access. Ensure that only authorized users have access to your devices. In the
event that a device is lost or stolen, support personnel or the user can remotely wipe the device.
And, notwithstanding those levels of protection, if an unauthorized user enters the wrong
password over a specified number of time, the device automatically performs a wipe.

Assigned Access. One of the primary problems facing organizations is how to ensure
users are only using devices for intended purposes. With Assigned Access, you can help ensure
that users can only run the apps you desire.

Virtual smart cards. Multi-factor authentication (“MFA”) helps strengthen any identity
authentication system. Virtual smart cards provide users with 2FA that helps prevent
unauthorized users from compromising your identity and authentication systems.

Certificate authentication. Certificates have long been used as a method for providing
MFA for devices, especially for Wi-Fi connections. With Windows Phone and your MDM system,
you can automatically manage the certificates used for client authentication with minimal effort.
 129

This extra level of security helps ensure that only authorized devices can access your Wi-Fi
networks.

VPN identity and access. Users are able to seamlessly and securely access resources
on your organization’s private intranet with no user interaction by using auto-triggered VPNs.

Wi-Fi identity and access. Minimize concerns about unauthorized Wi-Fi access within
your organization’s private intranet by using EAP-TLS and EAP-TTLS authentication for Windows
Phone devices. These certificate-based authentication protocols help ensure that only authorized
Windows Phone devices can access your organization’s internal wireless networks.

12.8.4. Security Management

Software updates. You can rest assured that your devices and apps are always current
with the latest software updates.

Assigned access management. You can control which apps users can run on their
devices, down to a specific app publisher, a specific app, or a specific app for a specific publisher.

Device wipe management. In the event that a device is lost or stolen, you can remotely
wipe devices to help ensure that unauthorized users are unable to access your confidential
data.

Remote assistance management. Users will always receive the help they need in
locating a lost device, wiping a device (if they are unable to locate it), or resetting their password
(PIN) no matter where they are located.

Windows Phone Store and app management. Users will only be able to download
and install the apps that you want to run. You can even limit or disable user access to the
Windows Phone store.

Security-related policy settings. Feature-rich policies help ensure that you can
configure your Windows Phone devices and apps to comply with security policies established
by your organizations and any regulatory agencies. All of these policy settings can be centrally
configured so that you have total consistency of security policies and settings across all Windows
Phone devices.
130

Direct Push firewall configuration. Ensure your firewalls protect your digital assets
while ensuring that you can push updates directly to Windows Phone devices.

Exchange secure mail and authentication configuration. Protect more than just
the phone and the apps. Protect the network traffic between your devices and your Exchange
Server infrastructure. SSL encryption helps ensure that all your confidential information sent by
email stays confidential.

12.9. Symbian OS Security

12.9.1. Symbian OS Security Model

In this section we will introduce three important concepts in Symbian OS platform security:
three trust tiers, capabilities, and data caging.

Figure 12.3 : Three Trust Tiers

The first essential concept in Symbian OS platform security is the “three trust tiers” model,
shown in Figure 12.3. Figure 12.3 depicts a trusted computing platform comprising a Trusted
Computing Base (TCB), a Trusted Computing Environment (TCE), and Applications.

Trusted Computing Base (TCB): The heart of a trusted computer system is the
Trusted Computing Base (TCB), which contains all of the elements of the system responsible
 131

for supporting the security policy and supporting the isolation of objects (code and data) on
which the protection is based. TCB is the most trusted part of Symbian OS. It has three
components: the operating system kernel, the file server (F32), and the software installer. All of
them have been carefully checked to ensure that they behave properly and can be completely
trusted. The kernel has the responsibility for managing all the processes and assigning
appropriate privileges to them.The file server is used to load the code for running a process.
The software installer is used to install applications from files packages. It also checks the
digital signatures of the packages to validate the privileges requested for the program binaries,
so it is the “gatekeeper” for the mobile device.

Trusted Computing Environment (TCE): The next tier is the TCE, which is a set of
different system servers running with different privileges. TCE consists of trusted software
provided in the mobile phone by Symbian and others, such as the UI platform provider and the
mobile device manufacturer. The TCE usually implements a system server process and is
less trusted, and thus it has only limited privileges to perform a defined set of functions. With
this design, Symbian can ensure that failure of one server will not threaten the whole system,
and it is also impossible for a misbehaving system server to compromise the security of another
server, since it does not have access to the same APIs.

Applications: Third-party applications are the last tier in this trusted computing model.
As they are not highly trusted, they only have privileges to access the services that are unlikely
to pose a security risk, and they are not allowed to access critical low-level operations. There
are actually two kinds of applications: signed applications and unsigned applications. If a signed
application wants to use some service provided by TCE, it must request that TCE run the
service on its behalf. TCE will only accept the request if the application has been granted
enough privileges. The unsigned applications, however, can only perform some operations that
do not require privileges, or operations that may be allowed by the user. It is necessary to point
out that there are a lot of useful operations which can be performed by unsigned applications
and which do not require a signature because they are not security-relevant. A user may allow
some operations to be performed even if an application is not signed, via a user-prompt dialog.
An unsigned application, then, is not necessarily worthless software or malware: an application
should have a signature only when it is necessary.
132

12.9.2. Capabilities Determine Privilege

The second basic concept in the Symbian OS platform security model is capabilities. A
capability is an unforgeable ticket, which when presented can be taken as incontestable proof
that the presenter is authorized to have access to the object named in the ticket.

Figure 12.4 : Access Control Based on Capabilities

In Symbian OS, each process runs with a list of capabilities, and these capabilities
determine whether a given resource can be accessed by the process. As shown in Figure
12.4, process X (with capabilities A, B, and C) can access the resource Y, which requires
capabilities A and B, but cannot access the resource Z, which also requires capability D. The
concrete form used to access the resources is through APIs, and different APIs will require
different capabilities for the services they provide.

The Symbian OS uses capabilities to represent access privileges. Each live process
and its corresponding capabilities are listed and monitored by the system kernel. A process will
ask the kernel to check the capabilities of another process before deciding whether to carry out
a service on its behalf.
 133

Capability Rules

Figure 12.5 : Loadingof DLLS

There are two basic capability rules in the design of Symbian. The first rule is that every
process has a set of capabilities and its capability never changes during its lifetime. This rule is
included in Symbian OS for simplicity and security. The second rule states that a binary cannot
load any DLL that has fewer capabilities than itself. This prevents untrusted code being loaded
into sensitive processes. The capabilities of a DLL do not affect the capabilities of the process
that loads it; process capabilities are entirely defined by the capabilities of the EXE.

12.9.3. File Access Control System

The last essential principle in Symbian OS platform security architecture is the file access
control system. It is designed to protect the integrity and confidentiality of critical files. The
concrete solution is called “data caging” or “file caging.”

Basic Data Caging Principles

The original idea of data caging is simple: put the most important treasures into a coffer
and enforce strict access control to it, so that no one else can easily access the treasures
inside it. In Symbian OS, data caging is achieved by providing special directories that “lock
away” files in private areas. Data caging is a lightweight mechanism, as the access control of
the files only relies on their path; thus, it works without another access control list, which would
consume additional system resources.
134

Data caging also follows the Principle of Least Privilege, by which a process cannot
access these special directories unless it is authorized. If we take a close look at this aspect,
there are two special capabilities closely related with data caging: TCB and AllFiles. These are
enforced by the TCB. If these capabilities are granted, they will apply to all the files in the
system. So, they are really critical and should not be assigned to one specific application. In
Symbian, the solution for this problem is to provide several different system services with more
limited privileges such as ReadUserData, WriteUserData, and so on, so the access permission
is narrowed and divided.

Caged Paths in Symbian OS In Symbian OS, there are three caged top paths: \sys,
\resources, and \private. All their subdirectories are also access restricted. Only the processes
with TCB and AllFiles capability may access these directories.

\sys

There are two important subdirectories under \sys: \sys\bin and \sys\hash. \sys\bin is the
default path where all the binary files are stored. The preinstalled binaries are located at z:\sys\bin,
which is a path in the ROM; and add-on applications are under \sys\bin on some writable
devices. In Symbian OS, there are two rules defined for this path. First, only TCB can write new
executables into this path (via SWInstall) or execute the binaries under this path (via F32).
Second, only the binaries under this path are runnable; all the other paths will be ignored by the
loader. This ensures the security and integrity of the system, since only TCB, not malware, can
create a new process.

\sys\hash is used to check whether a binary on removable media can be launched. It is

managed by the software installer. The installer will check the presence and correctness of the
hash, and the hash entry for a binary will not be generated unless the installation has been
validated. This mechanism ensures the security of running a binary on removable media.

\resources

Similar to \sys, \resources exist in both ROM and writable storage. The files under
\resources are read-only for most of the applications, because this path is used to store the
 135

resource files, which will not be changed after installation. Only an application with TCB capability
(installer application) can modify the files under this path, ensuring that resources installed for
one application will not be destroyed by other applications.

\private

In Symbian, every EXE is assigned its own caged subdirectory under \private. The
subdirectory is open to its own process but is inaccessible to other normal processes.
Particularly, if two processes are loaded from the same EXE, they share the same subdirectory.
The subdirectory under \private is the default path to store the data of the process, but the
developer can also choose to store the data of their application in a public directory.

12.10. WebOS Security

WebOS is an LG-owned, Linux-based, smart TV operating system that is set up to allow

control and access of LG Smart TV’s more advanced features and connected devices through
a graphical user interface (GUI).

WebOS was developed by Palm as a mobile OS. The company released it in 2009 as
Palm webOS. Hewlett Packard acquired palm in April 2010. The operating system was used in
a number of Palm and HP smartphones before being modified for use in HP tablet PCs, such
as the TouchPad. After the TouchPad failed to gain market share, HP made webOS open
source. LG purchased webOS in February 2013 and modified it as a smart TV operating system.

Of particular interest to LG were webOS’s cloud integration and its easy adaptation to
LG’s Magic Motion remote. John I. Taylor, Vice President of Public Affairs and Communications
at LG Electronics, said LG intends to use webOS in other smart appliances. LG has not ruled
out future use in smartphones

UL’s 2900-1 Cybersecurity Assurance Program (CAP) tested webOS 3.5 Security Manager
for malware susceptibility and vulnerabilities, software weaknesses and security controls that
help protect users’ private information. UL assessed the effectiveness of each webOS 3.5
security layers by subjecting the software to a variety of virtual network penetrations and
vulnerability attacks – covered under CWE/SANS Top 25 vulnerabilities – on its applications
136

and system configuration center. UL’s 2900-1 tests measure application security, information
access control via authentication processes, engineer mode hacking protection and software
falsification protection.

12.11. Summary

 Mobile device usually is a small, portable size computing device, which allows user to
input information through touchscreen or small keyboard on the device.

 Android also provides application security through “sandbox” which isolates applications
from each other.

 Android default setup is to disable of access root, but many users like to root their mobile
device. This increases the potential of being attack.

 IOS requires each user to have a unique passcode to generate encryption key.

 BlackBerry provides devices which encrypt Federal Information Processing Standard

140-2 validation and Secure/Multipurpose Internet Mail Extensions (S/MIME) and public
key infrastructure.

 All apps, and even some system components, on Windows Phone run in an isolated
sandbox called an AppContainer.

 The first essential concept in Symbian OS platform security is the “three trust tiers” model.

 The heart of a trusted computer system is the Trusted Computing Base (TCB), which
contains all of the elements of the system responsible for supporting the security policy
and supporting the isolation of objects (code and data) on which the protection is based.

 Trusted Computing Environment (TCE) is a set of different system servers running with
different privileges.

 In Symbian OS, data caging is achieved by providing special directories that “lock away”
files in private areas.
 137

 WebOS is an LG-owned, Linux-based, smart TV operating system that is set up to allow

control and access of LG Smart TV’s more advanced features and connected devices
through a graphical user interface (GUI).

12.12. Review Questions

1. Explain the common mobile device attacks.

2. Elaborate the security in the android.

3. How malware resistance is done in the windows phone?

4. Illustrate the three trust tiers model in the Symbian platform.

5. Write short notes on WebOS.

12.13. Further Reading

 https://www.blackhat.com/presentations/bh-europe-05/BH_EU_05-deHaas.pdf

 https://docs.huihoo.com/symbian/s60-5th-edition-cpp-developers-library-v2.1/GUID-
35228542-8C95-4849-A73F-2B4F082F0C44/sdk/doc_source/guide/platsecsdk/index.html

 https://source.android.com/security

 https://us.norton.com/internetsecurity-mobile-android-vs-ios-which-is-more-secure.html

 https://study.com/academy/lesson/ios-security-architecture-layers-features.html

 https://www.cnet.com/news/ios-13-vs-android-10-which-os-is-more-secure/
138

UNIT 13
MOBILE SERVICES

Learning Objectives
 In this chapter, the concept of security in the mobile device is discussed.

 A learner will be able to understand the WAP, Mobile HTML, Bluetooth Security, SMS Security
in mobile device.

Structure
13.1 WAP and Mobile HTML Security

13.2 Bluetooth Security

13.3 SMS Security

13.4 Summary

13.5 Review Questions

13.6 Further Reading

13.1. WAP and Mobile HTML Security

Wireless Application Protocol (WAP) and Mobile HTML websites represent a growing
trend. As end users migrate to their mobile phone from traditional PC-based for Internet activities,
such as checking/sending e-mail, checking bank accounts/transferring money, and updating
the status of their social networking page, the more users will assume security has been built
in using rigorous standards. To address the current state of security, this chapter discusses
WAP and Mobile HTML security.

WAP - A web destination highly based on the Wireless Markup Language (WML) only.
Usually targeted for mobile devices that are not smartphones but rather regular mobile phones
that support text-based web destinations. WAP comes in two versions:

 WAP 1.0 - Heavily based on WML. Limited support of security rich content, including
encryption (WTLS only).
 139

 WAP 2.0 - Richer support than WAP 1.0, including xHTML, CSS, and full Transport
Layer Security (TLS) encryption.

Mobile HTML - Mobile HTML sites are usually slimmed-down versions of regular websites
for mobile use. The look and feel will be similar to the full-blown application.

13.1.1. WAP and Mobile HTML Basics

Wireless Application Protocol provides a method to access the Internet from mobile
devices. WAP architecture includes a few items, such as a WAP browser on the mobile device,
the destination application/HTTP web server, and a WAP gateway in between the mobile device
and the application/HTTP web server. A WAP gateway is an entity that acts much like a proxy
server between a mobile device and the HTTP server. Its job is to translate content from web
applications in a form readable by mobile devices, such as with the use of WML.

In the early days of WAP, which used WAP 1.0, Wireless Markup Language (WML) was
solely supported. WML was based on HTML, with limited to no support for cookies. WAP websites
heavily relied on WML to display content to users, but quickly ran out of all the bells and whistles
that users/developers desired. About four years later, WAP 2.0 was established. WAP 2.0
supported more items that make the web experience similar to the PC, such as xHTML, CSS,
TLS, and wider support for cookies. Furthermore, WAP 2.0 no longer required a WAP gateway,
which alleviated some security concerns with WAP 1.0. As the industry continued to evolve, so
did mobile devices. Nowadays, WAP 2.0 and Mobile HTML sites dominate mobile web
applications. Mobile HTML sites are slimmed-down versions of tradition web applications, but
viewable on devices with limited view screen and storage capacities (usually with a smartphone
or PDA).

Figure 13.1 : WAP Architecture

140

13.1.2. Authentication on WAP/Mobile HTML Sites

One of the many problems that WAP and Mobile HTML developers have with mobile
devices is the keyboard. PDA-style phones come with a mini-keyboard that looks similar to
traditional keyboards, containing letters A–Z and support for every number (0–9) and many
special characters by using a SHIFT-style key.

On the other hand, non-PDA phones have the traditional 0–9 keys only, with letters above
numbers 2–9 and special character support under number 1 or 0.

Although the use of PDA-style mobile phones is increasing every day, non-PDA mobile
devices are the most popular, which have the traditional 0–9 keys only. The limitation of the 0–
9 keys creates a significant challenge to WAP and Mobile HTML developers in terms of user
experience and authentication. For example, banking and e-commerce organizations want to
make authentication to their sites as easy and secure as possible, thus making the adoption
rate high.

Traditionally, strong passwords are often required for banking and e-commerce sites,
often requiring numbers, letters, and a special character. Although these standards are great
when a traditional keyboard is available, they become very difficult when only the 0–9 keys are
available on traditional handsets. For example, using the keyboard in Figure 9-2, the relatively
simply password of isec444 would only require selecting the letters i-s-e-c, selecting the SHIFT
key, and then selecting the number 4 three times, requiring a total of eight key presses. On the
flip side, the same password used with the keys shown in Figure 9-3 would require selecting
the number 4 key four times (to get to i), the number 7 key five times (to get to s), the number 3
key three times (to get to e), the number 2 key four times (to get to c), and then the number 4
key three times, for a total of 19 keypresses. The latter option requires more than double the
effort to enter a simple password and virtually kills the user sign-on experience.

In order to create a better and easier experience, mobile WAP/Mobile HTML sites have
introduced the use of a mobile PIN, which replaces the password; however, this also lowers the
security of the authentication process. For example, many WAP/Mobile HTML sites allow a
phone to be registered to an account. After a phone is registered via a web application, the
 141

mobile phone number can be used instead of a username, and a mobile PIN can be used
instead of a password. Unlike traditional passwords, the mobile PIN can only be numbers and
is usually four to eight values in length (with at least one major bank limiting PINs to only four
numeric values only). The use of a numeric-only value for the PIN increases the user experience
by significantly reducing the amount of keypresses to use the mobile device (the same idea
holds for the username, by the use of a numeric phone number instead of an alphanumeric
username). In either case, when the username is replaced with a phone number and the
password is replaced with a PIN, the user experience is improved, but security is reduced. In
this use case, a site that usually takes a unique username and strong password has just been
reduced to a phone number and numeric value. Although low tech, an attacker could simply
enter several phone numbers to see which ones are registered to use the WAP/Mobile HTML
site. Furthermore, most WAP/Mobile HTML sites give verbose error messages (again, for a
strong user experience but bad security practice), so entering the incorrect mobile number will
let the attacker know that a number has not been registered. The attacker can then enter the
next number on their list until they receive an error message that states the PIN is not correct
instead of an error message that says the phone number is unregistered. Once they have
identified a valid phone number that has been registered already, the attacker now has to brute-
force the PIN.

Admittedly, brute-forcing a weak PIN is not the full responsibility of the banking/e-commerce
site, but how many users will simply use “1234” if they are required to have numbers only and
four values? Further, how many users will simply use their seven-digit phone number as the
password, which still fits into the number-only restriction of four to eight values. The examples
could go on, but with a key space drastically reduced from A–Z, 0–9, and special characters to
0–9 only, the likelihood of an attacker hijacking a user’s account by brute force significantly
increases. A possible mitigation to brute-forcing weak PINs is for the organization to enforce a
password policy different from its online web application. For example, the organization could
mandate that the account is locked out after three failed attempts. It could also reject physical
keypad sequences such as 2580 and repeating numbers, and it could restrict certain numbers
such as the seven-digit phone number or the last four digits of the phone number. Each of
these steps would help reduce the basic brute-force attack from being successful.
142

It should be noted that some WAP/Mobile HTML sites provide limited functionality, often
just one or two functions with little account information available; however, the ability to buy/sell
items or transfer dollars is available in most of these sites, and this is likely to increase in
functionality rather than decrease (at least one major bank has full functionality with only a four-
digit number PIN). Regular PC-based banking/e-commerce websites had very limited capabilities
as well when they were first introduced and quickly blossomed into full-fledged web applications,
but the enforcement of strong authentication lagged behind here too.

Adding to the “user experience versus security tradeoff” theme, another avenue of exposure
is the crossover use of SMS and WAP/Mobile HTML applications. For example, some WAP/
Mobile HTML sites allow the use of SMS to retrieve sensitive information. The general idea
involves using a predefined destination number (registered earlier in the web application) and
sending messages with specific words in them, such as balance, transactions, history, status,
and accounts. The receiving entity then returns specific information back to the user, based on
the request. Obviously, the use of SMS is important if non-PDA phones are used because e-
mail is not really a strong option. After a mobile device is registered (that is, the user has
registered their mobile phone number and a correlating PIN using the regular web application),
the site allows the user to send SMS messages to a specific number and retrieve certain data,
such as account balances and transactions. During this process, a user is not challenged with
a user ID or password/PIN, but is simply verified with the caller ID value. For example, sending
an SMS message to a predefined number (assigned by the bank or e-commerce organization)
will return an account balance as long as the caller ID value is correct.

The key control here is the caller ID, which is thought of as a trusted value. However, a
simple search on spoofing/faking an SMS message will turn up a lot of results (this can also be
done using an Asterisk PBX). Hence, if a handset/phone number has been registered to receive/
send information using SMS, an attacker can simply spoof the caller ID, send an inquiry to the
known/predefined phone number, and then get the legitimate user’s sensitive information (such
as their bank balance). One might argue that a handset must be registered first, but that should
not be considered a protection layer because sending 20,000 SMS messages, where 10,000
are unregistered, does not affect a focused attacker much. Furthermore, any information that
is given to the user, whether it is an account balance or a trusted/unique URL, based on the
 143

caller ID value should be not considered trusted. For example, some organizations will give a
unique URL to every user that must be used with a valid PIN to access a WAP/Mobile HTML
site. Unlike with SMS, the PIN is required to enter the mobile site; however, the unique URL can
be obtained over SMS. Similar to the “balance” request, an attacker can send a request via
SMS for the unique URL for any victim. Once the attacker has the unique URL by spoofing the
caller ID, they can then begin the process of brute-forcing the PIN. Either way, using SMS to
identify a user is very difficult and should not be considered the most secure option.

13.1.3. Encryption

The use of Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS) is a critical
aspect of online security. SSL/TLS is used often by web applications to keep sensitive information
private over the Internet, bringing confidentiality and integrity to HTTP (via HTTPS). The need
for transport security, via SSL/TLS, between a user’s mobile device and its destination is equally
important, as a growing number of sensitive online activities take place on the mobile device
and not the PC. This section will review the use of encryption in both WAP 1.0 and WAP 2.0.

WAP 1.0

In the early days of the mobile WAP world (WAP 1.0), TLS was used, but not end to end.
WAP 1.0 used a three-tiered architecture, including the WAP mobile device, which in turn used
a WAP browser, a WAP gateway (also known as a WAP proxy server), and the web/application
server on the Internet. WAP 1.0 mobile devices mostly spoke Wireless Markup Language (WML),
which is similar to HTML. The WAP gateway would translate HTML from the web/application
server on the Internet to WML for the WAP browser on the mobile device. The use of the WAP
gateway was fairly important in the early days because it would encode/decode all the data to/
from application servers to fit the data, size, and bandwidth restraints of the mobile devices. In
terms of security, the WAP gateway also played an important role. Due to the limited horsepower
on mobile devices (including bandwidth, memory, battery, and CPU), full TLS connectivity
between the mobile device and the web/application server was not used. Instead, Wireless
Transport Layer Security (WTLS) was used between the mobile device and the WAP gateway,
and SSL/TLS was used between the WAP gateway and the web/application server (see Figure
13.2.).
144

Before we go further, we should pause and talk a bit about WTLS. WTLS is similar to TLS
and provides transport security between mobile clients and WAP gateways. It is based on TLS,
but is used for low-bandwidth data channels that would normally not be able to support a full-
blown TLS implementation. Similar to TLS, WTLS provides confidentiality and integrity using
standard block ciphers and MACs.

The WAP 1.0/WTLS architecture brought up several concerns for mobile users and
security professionals, due to the absence of full end-to-end security. The process of converting
communication between WTLS and TLS would occur at the WAP gateway (encrypting/
decrypting), making it an entity that performs a man-in-the-middle attack, although legitimately.
This meant that sensitive information was left in a plain-text format, either in memory or in
cache, or even written to disk, on the WAP gateway itself. Because the WAP gateway is an
entity that is owned and managed by an ISP, not by a bank or e-commerce institution, the ISP
would have access to plain-text data from any user using their gateway. Although trusting every
ISP in the world and their WAP gateways may have looked great on paper, the idea did not float
too well with many sending and receiving entities. This scenario—known in some circles as the
“WAP gap”—was not an acceptable option to many organizations because the ISP’s WAP
gateway could see all the decrypted information to/from the mobile device. Whether it is a
hostile ISP or simply bad practice, the idea of sensitive information being decrypted and then
reencrypted between two trusted entities did not sit well with many banking institutions and e-
commerce vendors.

Figure 13.2 : WAP 1.0 and transport encryption

 145

SSL and WAP 2.0

Due to the security concerns of the WAP gateway (WAP gap) and its legitimate use of a
man-in-the-middle attack, full end-to-end security was supported in WAP 2.0. In the WAP 2.0
world, the WAP gateway was no longer required and became an optional device. Full TLS end-
to-end encryption is supported between the mobile device and the web/application server, due
to HTTP 1/1 support. A WAP gateway could still be used, but for optional supporting purposes
such as optimization. Its role became more similar to a standard proxy-type device rather than
a required translation device. With the full end-to-end support of TLS between the mobile device
and web/application server, WTLS is no longer needed. Figure 13.3. shows an example of TLS
connections in the WAP 2.0 architecture.

Figure 13.3 : WAP 2.0 and transport encryption

13.1.4. Application Attacks on Mobile HTML Sites

Some of the first things many security professionals will want to know about Mobile HTML
sites are how much is new, how much is old, and what they should care about. The previous
two sections on authentication and encryption discussed what is new in the WAP world, and
this section will address what is new in the Mobile HTML world, specifically which traditional
web application attacks will work on mobile devices or mobile applications. The traditional web
application attacks discussed in this section are not exhaustive, but will cover the most popular
or pertinent attack classes currently in use.

Many traditional web application attacks will work on mobile browsers/devices supporting
WAP 2.x/Mobile HTML sites. Mobile devices with mini-browsers are not fully featured, but they
do contain the bare-bones necessities to function on most web applications or Mobile HTML
146

sites. The same items that are needed for bare-bones functionality, such as some type of
cookie support on the mobile device, are the same things attackers usually target. Overall,
there’s nothing really new in the Mobile HTML world—it has more of the same issues, but just a
different implementation of the attack classes.

13.2. Bluetooth Security

Bluetooth is designed to provide cable-free operation and interaction among a variety of

devices, many of which tend to be consumer electronic devices. Because of the variety of
devices in use and the situations for which Bluetooth is intended, no assumptions can be made
about either the Bluetooth device or the technical sophistication of the device’s user. Bluetooth
must be usable by novice consumers and on devices with limited or no visual display or input
capabilities (headsets, keyboards, and so on). So, a key factor that complicates Bluetooth
security is that many usage scenarios involve nontechnical users as well as devices that are
incapable of the security mechanisms a developer may wish to use.

It is important that these issues remain at the top of mind as mobile application developers
plan the design of their applications, as well as whether and how these applications will leverage
or rely on Bluetooth security.

13.2.1. Pairing

Pairing, the process whereby two Bluetooth devices establish a link and agree to
communicate, is critical to the overall security architecture of Bluetooth and is tightly integrated
with other Bluetooth security features. During the pairing process, the communicating devices
agree on and generate keys that are used to identify and reference relationships with other
devices. In addition to being used for these identification purposes, these keys are also used to
generate additional keys used for both device authentication and communication encryption.

13.2.2. Device Pairing Prior to Bluetooth v2.1 + EDR

In versions prior to Bluetooth v2.1 + EDR (released in July 2007), pairing between devices
is accomplished through the entry of a PIN or passkey with a maximum length of 128 bits.
There are two types of such passkeys: variable passkeys, which can be chosen at the time of
 147

pairing via some input mechanism, and fixed passkeys, which are predetermined (Bluetooth
Security, p. 29). The type of passkey used is typically determined by a device’s input and display
capabilities (for example, a Bluetooth-enabled phone with keyboard input and visual display
may use a variable passkey, whereas a Bluetooth-enabled mouse may use a fixed passkey
because it has neither input nor display capabilities to enter or verify a passkey).

13.2.3. Secure Simple Pairing with Bluetooth v2.1 + EDR

In Bluetooth v2.1 + EDR, a new method of pairing called Secure Simple Pairing was
introduced. The older method of pairing is supported when connecting to legacy devices, but
the use of Secure Simple Pairing is mandated for communications between Bluetooth v2.1 +
EDR devices.

From a user’s perspective, Secure Simple Pairing is meant to provide additional flexibility
and ease of use when pairing compatible devices that have far-ranging display and input
capabilities. However, from a security perspective, Secure Simple Pairing also improves security
through the introduction of Elliptic Curve Diffie-Hellman (ECDH) for key exchange and link key
generation.

Rather than relying on simple PIN/passkey entry and verification, Secure Simple Pairing
offers four different means for pairing compatible devices (known as association models):

Numeric Comparison This association model is designed for situations where both
communicating devices can display a six-digit number and have inputs that allow the user to
enter “yes” or “no.” A six-digit number from 000000 to 999999 is shown on both displays, and
the user is prompted to respond whether the numbers are the same on both devices. If “yes” is
entered on both devices, then the devices are paired successfully. Note that a primary difference
between Numeric Comparison and the PIN model used in legacy pairing is the displayed number.
In Numeric Comparison, this value is not used as an input to further key generation, so an
attacker who can observe the displayed number cannot use it to calculate other keys. With the
legacy PIN model, the PIN entered does factor into the generation of encryption keys, which
makes PIN disclosure a real risk to the security of the communications.
148

Just Works This association model is intended for scenarios involving at least one device
without the ability to display a six-digit number or to enter numbers. This mode uses the same
key agreement protocol as Numeric Comparison (with protections against passive
eavesdropping), but the actual method whereby the user accepts the Bluetooth connection is
determined by the product manufacturer. This association model does not provide protection
against man-in-the-middle attacks.

Out of Band This association model is intended for scenarios involving an out-of-band
(OOB) mechanism (that is, non-Bluetooth) that is used to both discover the Bluetooth devices
and exchange information during the pairing process. The actual OOB mechanism will vary,
but a commonly specified use case involving a Near Field Communication (NFC) OOB
mechanism is device “tapping.” This use case involves physically touching two devices
together. Subsequent to the devices being tapped together, the user is asked to confirm whether
the pairing request initiated by the tapping should be accepted. To provide security for the pairing
process, the OOB mechanism used should provide privacy protections, including resistance
to man-in-the-middle attacks.

Passkey Entry This association model is intended primarily for situations involving one
device with input capabilities but no display capabilities while the other device has display
capabilities. The device with a display presents a six-digit number from 000000 to 999999 on
the display. The user then enters this number on the device with the input capability. If the
values match, then the devices are paired successfully.

13.2.4. Traditional Security Services in Bluetooth

Developers and implementers are accustomed to having access to certain basic security
services in the technologies they employ. Such basic security services include authentication,
authorization, integrity, and confidentiality, among others. The availability of these services, the
soundness of their implementations, and the extent to which the developer or implementer can
customize these services for their unique requirements all help reveal the security capabilities
of a given technology.
 149

The Bluetooth specifications include a limited set of these basic security services, and as
such, the level of security that can be implemented with native Bluetooth features is limited.
The following security services are provided by the Bluetooth specification:

Authentication The ability to identify devices before and during connection and
communication is provided by Bluetooth.

Authorization The ability to provide selected access to resources based on permissions

is provided by Bluetooth.

Confidentiality The ability to protect communications during transmission over the

network is provided by Bluetooth.

Noticeably absent are integrity protections and nonrepudiation services. In addition, native
Bluetooth security services are provided at the device-to-device level; for instance, Bluetooth’s
authentication service only authenticates a Bluetooth device. There is no provision for user-
level authentication. Of course, this does not mean that user authentication services cannot be
provided over a Bluetooth connection; instead, the developer must implement this service by
other means at a different level in the communication stack. These limitations are important to
consider as mobile developers architect their applications and consider which security options
to employ.

Authentication

Bluetooth authentication is the process whereby one device verifies the identity of another
device. Bluetooth authentication is a one-way process, meaning that during any given
authentication procedure, only one device’s identity is verified. In use cases requiring mutual
authentication, this one-way process is simply repeated with the two devices’ roles reversed.

Bluetooth authentication involves the claimant device, which is the device that will have
its identify verified by the authentication process, and the verifier device, which is the device
that will verify the claimant’s identity. To perform this verification, a traditional challenge-response
mechanism is used. The verifier sends a random number (the “challenge”) to the claimant.
Upon receipt, the claimant generates a response to this challenge and returns the response to
150

the verifier. This response is generated based on a function involving the random number, the
claimant’s Bluetooth device address, and a secret key that was generated during device
pairing.

The Bluetooth authentication mechanism has a simple protection to prevent repeated

attacks in a limited timeframe. When an authentication attempt fails, the verifier will delay its
next attempt to authenticate the claimant. This delay interval will be increased exponentially for
each subsequent failed attempt.

Authorization

Authorization in Bluetooth allows for decision making about resource access and

connection configuration (that is, authentication and encryption requirements) to be made based

on the permissions granted a given Bluetooth device or service. Two of the primary means of
implementing authorization in Bluetooth are device trust levels and service security levels.

Device Trust Levels Bluetooth devices can have one of two trust levels in relation to

other Bluetooth devices: trusted or untrusted.

Trusted devices have previously been paired with the device, and will have full access to

services on the Bluetooth device.

Untrusted devices have not previously been paired with the device (or the relationship

has been otherwise removed), and will have restricted access to services.

Service Security Levels Bluetooth services (applications that use Bluetooth) have

one of three security levels:

Service Level 1 These services require device authentication and authorization. Trusted
devices will be granted automatic access to these services. Manual authentication and

authorization will be required before untrusted devices are granted access to these services.
 151

Service Level 2 These services require authentication, but do not require authorization.

Service Level 3 These services have no security and are open to all devices.

Although Bluetooth’s notions of device trust and service security levels are quite simple,
the architecture of Bluetooth does provide for the implementation of more complex security and
authorization policies.

Confidentiality

Confidentiality is important for private communications over wireless links because the
nature of wireless networking leaves the communication between nodes subject to
eavesdropping by unauthorized parties. Confidentiality of network communications in Bluetooth
is provided through the use of encryption, with the use of encryption being optional and determined
by the selection of one of three encryption modes during communication.

The Bluetooth specification outlines three specific encryption modes. These modes are
intended to limit encryption key ambiguity and speed processing of encrypted data in both
point-to-point and broadcast traffic situations. Bluetooth uses E0, a stream cipher, as the basis
for the encryption processing associated with these encryption modes. The defined modes
include:

Encryption Mode 1 No encryption. All traffic is unencrypted when Encryption Mode 1 is

used.

Encryption Mode 2 Traffic between individual endpoints (non-broadcast) is encrypted

with individual link keys. Broadcast traffic is unencrypted.

Encryption Mode 3 Both broadcast and point-to-point traffic is encrypted with the same
encryption key (the master link key). In this mode, all traffic is readable by all nodes in the
piconet (and remains encrypted to outside observers). Note that the notion of privacy in Encryption
Mode 3 is predicated on the idea that all nodes in the piconet are trusted because all nodes will
have access to the encrypted data.
152

Of importance to note is that when encryption is used in Bluetooth, not all parts of the
Bluetooth packet are encrypted. Because all members of a piconet must be able to determine
whether the packet is meant for them, the header of the message must be unencrypted. And, a
part of the packet called the access code must be available to all devices to allow the radio
signal to be acquired properly.

13.2.5. Bluetooth Security Modes

The Bluetooth Generic Access Profile details the procedures associated with the discovery
of Bluetooth devices and specifications related to device connection. In addition to these
discovery and connection details, the Generic Access Profile also defines four security modes
in which connectable Bluetooth devices may operate. The use of these various security modes
controls how Bluetooth’s basic security services are employed for any given connection:

Security Mode 1 In Security Mode 1, no security procedures are used. There is no

encryption or authentication, and devices in this mode will not use any controls to prevent other
devices from establishing connections.

Security Mode 2 In Security Mode 2, security is implemented after the Bluetooth link is
established. In this mode, security is enforced at the service level, so it is left to the Bluetooth
application or service to request security. This flexibility allows for granular and specific security
policies to be implemented that apply security selectively based on the services and applications
requested. This, of course, also opens the door for flaws in the implementation of these security
policies that could leave the device and data at risk.

Security Mode 3 In Security Mode 3, security is implemented when the Bluetooth link is
established. This is an “always-on” policy that provides security for all uses and reduces the
risks associated with faulty security policies and implementations. However, this will also increase
inconvenience and decrease flexibility because devices will be unable to connect without
authentication.

Security Mode 4 Security Mode 4 was defined in the v2.1 + EDR specification, and it’s
required between v2.1 + EDR devices (essentially making Modes 1 through 3 legacy modes
 153

once v2.1 + EDR becomes widespread). Like Security Mode 2, security in Security Mode 4 is
implemented after link setup. However, service security requirements must be identified as one
of the following:

Authenticated link key required

Unauthenticated link key required

No security required

Security “Non-Features”

In addition to reviewing the actual security features provided by Bluetooth, it is useful to

acknowledge and refute two characteristics of Bluetooth communications that may be claimed
as security features but do not provide any real protection:

Frequency hopping The frequency-hopping scheme that Bluetooth uses does not
provide any protection against eavesdropping. There is no secret used to create the sequence
of channels, and only 79 channels are used. Thus, using a series of receivers to monitor all
channels would make an offline attack possible.

Device proximity The limited range of Bluetooth radios (up to approximately 330 feet
with Class 1 radios) cannot be reliably used as a security feature. The supposed protection
provided by limited signal strength can and has been defeated by attackers’ high gain antennas.

13.2.6. Threats to Bluetooth Devices and Networks

Wireless networks (as a general class) are subject to various threats, such as
eavesdropping, impersonation, denial of service, and man-in-the-middle attacks. Bluetooth
devices and networks are also subject to these issues. In addition, Bluetooth systems face
additional threats, including:

Location tracking Because Bluetooth devices by their nature emit radio signals and
device addresses must be both unique and known to communicating parties, Bluetooth devices
are subject to location-tracking threats.
154

Key management issues Like many technologies that use cryptography for features
such as authentication and encryption, Bluetooth devices are subject to threats related to key
management, including key disclosure or tampering.

Bluejacking Bluejacking involves the sending of unsolicited messages to a victim’s

Bluetooth device. This can be leveraged as a social-engineering attack that is enabled by
susceptible Bluetooth devices.

Implementation issues As with any technology specification, the quality of security on

Bluetooth devices is determined to some degree by product-specific implementations.
Implementation flaws become threats when a product manufacturer incorrectly implements
the Bluetooth specification in its device, making the device or communications subject to security
issues that would not exist if the specification was implemented correctly. Implementation flaws
have been at the root of many well-known Bluetooth security issues, including:

Bluesnarfing This attack allows access to a victim Bluetooth device because of a flaw
in device firmware. Arbitrary data can be accessed through this attack, including the International
Mobile Equipment Identity (IMEI).

Bluebugging This attack allows an attacker to access data, place calls, and eavesdrop
on calls, among other activities. This attack is made possible by a firmware flaw on some
mobile phones.

Car whispering This attack allows an attacker to send or receive audio via a Bluetooth-
enabled hands-free automobile kit. This attack is made possible due to an implementation flaw
on these kits.

13.3. SMS Security

13.3.1. The Basics of SMS Security

The technical specifications for SMS are laid down in ETSI TS 03.485. Certain options in
the technical specification, such as the Security Parameter Index (SPI), the Ciphering Key
Identifier (KIc), and the Integrity Value (RC/CC/DS), provide specifications for available security
 155

parameters. A Redundancy Check (RC), Cryptographic Checksum (CC) or Digital Signature

(DS) might also be used for integrity verification of the data. However, these confidentiality and
integrity mechanisms are only specified as optional security measures that can be made
available, but they are not mandatory requirements for SMS system implementation. The
availability of SMS services may also be interrupted by the SMSC. Without proper implementation
of these SMS security options, everyday SMS messages transmitted on a network are only
protected by the communication network itself such as a GSM network.

In practical use, SMS messages are not encrypted by default during transmission. A
cyclic redundancy check is provided for SMS information passing across the signalling channel
to ensure short messages do not get corrupted. Forward error protection is also incorporated
using conventional encoding. Cryptographic protection on confidentiality and integrity is not
available for SMS messages. Each short message has a validity period whereby temporary
storage is provided by the SMSC if the SMS message cannot be delivered to the intended
recipient(s) successfully. The SMSC will delete stored SMS messages if they cannot deliver a
message within the validity period. After a message is deleted, the intended recipient(s) will not
be able to receive the original message. Usually this can happen if the recipient is not in the
SMS coverage area, such as during a business trip out of the country.

13.3.2. SMS Security Threats

Understanding the basics of SMS security opens the door to preventing some common
security threats in SMS usage and implementation: Message Disclosure Since encryption is
not applied to short message transmission by default, messages could be intercepted and
snooped during transmission.

In addition, SMS messages are stored as plain text by the SMSC before they are
successfully delivered to the intended recipient. These messages could be viewed or amended
by users in the SMSC who have access to the messaging system.

Spying programs such as FlexiSpy7 enable intruders to automatically record all incoming
and outgoing SMS messages and then upload the logs to a remote server for later viewing and
analysis.
156

Spamming While e-Marketers are using SMS as a legitimate marketing channel, many
people have had the inconvenience of receiving SMS spam. The availability of bulk SMS
broadcasting utilities makes it easy for virtually everyone to send out mass SMS messages.
Flooding / Denial of Service (DoS) Attacks Flooding or DoS attacks are made possible by
sending repeated messages to a target mobile phone, making the victim’s mobile phone
inaccessible. Studies also show that weaknesses in the SMS protocol could be exploited to
launch a DoS attack on a cellular phone network. For example, it was found that sending 165
text messages a second was enough to disrupt all the cell phones. SMS Phone Crashes Some
vulnerable mobile phones may crash if they receive a particular type of malformed short
message. Once a malformed message is received, the infected phone becomes inoperable.

SMS Viruses There have been no reports of viruses being attached to short messages,
but as mobile phones are getting more powerful and programmable, the potential of viruses
being spread through SMS is becoming greater. In addition, the ability of SIM application toolkits
that allows applications to access the dialling functions and phone book entries, might make
SMS suitable platform for spreading self-replicating virus.

SMiShing (SMS Phishing) SMiShing10 is a combination of SMS and phishing. Similar to

an Internet phishing attack using email, attackers are attempting to fool mobile phone users
with bogus text messages11. When users are taken in by a bogus text message, they may
connect to a website provided in the SMS message, and be tricked into download a malware
application into their mobile phones.

13.3.3. SMS Security Considerations

To avoid security threats to SMS, users are advised to follow the following common
precautions: Message Transmission When sending SMS messages via a web browser, security
protection should be in place to prevent message disclosure, such as using Secure Socket
Layer (SSL) to secure the transmission. For those applications that require secure transmission
of a message, such as mobile banking, end-to-end encryption is advisable between the sender
and the recipient. These transactional systems should have the end-to-end security built-in.
For person-to-person communications, products such as CryptoSMS12 are available to help
users encrypt SMS communications using strong encryption algorithms. This can help protect
 157

against possible SMS interception threats. Storage Protection In the case of large-scale SMS
broadcasts, customer mobile phone contact lists should be kept confidential and properly
protected from disclosure. As contact lists are considered personal data, proper protection
should be implemented in accordance with privacy laws and regulations. User authentication
User login IDs and passwords should be used to authenticate users on web-based SMS services
when sending short messages. User login IDs and passwords should not be disclosed to
others. For secure transactions, user authentication should be protected by SSL. Protection of
PCs for sending messages When sending short messages to an SMS gateway via the Internet,
it is not advisable to use a public Internet terminal. If desktop utilities are used to send out SMS
messages, the PC used to send the message should not be left unattended.

13.4. Summary

 WAP is a web destination highly based on the Wireless Markup Language (WML) only.
Usually targeted for mobile devices that are not smartphones but rather regular mobile
phones that support text-based web destinations. Dictionary attack is used to obtain
passwords.

 WAP 1.0 is heavily based on WML. Limited support of security rich content, including
encryption (WTLS only).

 WAP 2.0 is Richer support than WAP 1.0, including xHTML, CSS, and full Transport
Layer Security (TLS) encryption.

 Mobile HTML - Mobile HTML sites are usually slimmed-down versions of regular websites
for mobile use. The look and feel will be similar to the full-blown application.

 Bluetooth is designed to provide cable-free operation and interaction among a variety of

devices, many of which tend to be consumer electronic devices.

 Pairing, the process whereby two Bluetooth devices establish a link and agree to
communicate, is critical to the overall security architecture of Bluetooth and is tightly
integrated with other Bluetooth security features.
158

 In versions prior to Bluetooth v2.1 + EDR (released in July 2007), pairing between devices
is accomplished through the entry of a PIN or passkey with a maximum length of 128 bits.

 Bluejacking involves the sending of unsolicited messages to a victim’s Bluetooth device.

 Bluesnarfing attack allows access to a victim Bluetooth device because of a flaw in

device firmware.

 Bluebugging attack allows an attacker to access data, place calls, and eavesdrop on
calls, among other activities.

 Car whispering attack allows an attacker to send or receive audio via a Bluetooth-
enabled hands-free automobile kit.

13.5. Review Questions

1. Explain the encryption in WAP 1.0 and WAP 2.0.

2. Write short note on Bluetooth Security modes.

3. Elaborate the SMS security threats.

4. Define Bluebugging.

13.6. Further Reading

 https://www.synopsys.com/glossary/what-is-mobile-application-security.html

 https://www.arxan.com/resources/technology/mobile-app-security

 https://www.ptsecurity.com/ww-en/analytics/mobile-application-security-threats-and-
vulnerabilities-2019/

 https://people.eecs.ku.edu/~saiedian/710/Lectures/Readings/00-EECS710-Workshops/
24-mobile-app-sec-workshop.pdf

 https://sms.com/services-solutions/cyber-security/security-operations

 https://www.forbes.com/sites/kateoflahertyuk/2020/01/21/the-surprising-truth-about-sms-
security/#173101f67a25
 159

 https://www.electronics-notes.com/articles/connectivity/bluetooth/security.php

 https://electronics.howstuffworks.com/bluetooth4.htm

 https://www.webroot.com/au/en/resources/tips-articles/a-review-of-bluetooth-attacks-and-
how-to-secure-mobile-workforce-devices

 http://programming4.us/mobile/3650.aspx

 http://etutorials.org/Mobile+devices/mobile+wireless+design/Part+One+Introduction+
to+the+Mobile+and+Wireless+Landscape/Chapter+6+Mobile+and+Wireless+Security/
WAP+Security/
160

UNIT 14
GEO LOCATION AND MOBILE MALWARE

Learning Objectives

 In this chapter, the concept of Malwares, Geolocation, Penetration testing in the Mobile
devices is discussed.

 A learner will be able to understand how geo location works in mobile devices and various
malwares, threats in the mobile devices and penetration testing.

Structure
14.1 Geolocation Methods

14.2 Mobile Malware

14.3 Mobile Application Penetration Testing

14.4 Summary

14.5 Review Questions

14.6 Further Reading

14.1. Geolocation Methods

Geolocation on mobile devices has grown from being used solely for emergency and law
enforcement purposes to being an integral component of consumer mobile applications. Once
only performed by triangulation of cell towers, various modern mobile OS have expanded to
support retrieval of positional data via wireless survey or GPS systems, giving an enhanced
degree of precision and faster update times. Different methods have their own strengths and
weaknesses, along with variations in accuracy.
 161

14.1.1 Tower Triangulation

Accuracy: 50m–1,000m

Tower triangulation is the oldest widely used method of geolocation via cell phone. This
method uses the relative power levels of radio signals between a cell phone and a cell tower of
a known location—this of course requires at least two cell towers to be within range of the user.
This service is used for the E911 system in the United States, transmitting location data when
emergency calls are made. With user permission, however, the phone can be instructed to
transmit tower triangulation data to phone applications.

Because this requires that the user be near to multiple cells, and because signal strength
can be affected by many factors, tower triangulation is a fairly inexact method of positioning
(see Figure 14.1).

Figure 14.1 : Cell phone tower triangulation

14.1.2. GPS

Accuracy: 5m–15m

Using satellite signals instead of cell phone or wireless infrastructure, GPS service is
often available at times when other methods are not. However, satellite acquisition is generally
162

impaired when the user is indoors, making the use of GPS alone inadequate for some mobile
applications. Additionally, initial GPS location information can take several minutes to acquire.

An advantage of GPS is that it can provide continuous tracking updates, useful for real-
time applications, instead of just one-time lookups.

Assisted GPS works by providing an initial location obtained via another means (either
tower triangulation or 802.11) to the GPS receiver, to reduce satellite acquisition time and correct
for signal noise. This makes GPS somewhat more viable for indoor use; however, acquiring
positional data this way still takes upwards of 10 seconds, still making it a relatively slow method.

14.1.3. 802.11

Accuracy: 10m–200m (but potentially erroneous)

The iPhone was the first smartphone to add this additional method for geolocation, using
an API made available by Skyhook Wireless. This location method works by doing a survey of
any nearby 802.11 (Wi-Fi) wireless access points and then submitting data about them
(presumably MAC address and SSID) to a web service, which returns coordinates from what is
essentially a very large “wardriving” database. This allows for devices without GPS to provide
potentially highly accurate location data.

This approach has the advantage of being both faster and much more accurate than cell
tower triangulation, but has a couple of drawbacks. Because location data relies on specific
wireless APs, if those APs move, location data can be drastically wrong. For instance, the
company of one of the authors of this book relocated its offices about a mile away. Because the
wireless APs were listed in the Skyhook database, any attempt to use location services near
the offices reported the company as being in the previous location, making it difficult to find
places to go to lunch. A more extreme example is when attending a security conference in
Tokyo, one of the authors’ iPhone 2G reported being in Vancouver, B.C. (the last place the
conference APs were used).

The Skyhook software development kit (SDK) has also recently become available for
Android, but is not yet integrated in an official capacity. More recently, however, Google launched
 163

its “Latitude” service, which provides a newer implementation of Skyhook’s technology, combining
all of the preceding methods.

14.1.4. Risks of Geolocation Services

Although mobile geolocation services have resulted in some useful and convenient mobile
applications, these services expand the potential risks to both the end user and the remote
service providers making use of this data. Any tracking technology has the capacity to make
software more personalized, but this very personalization is what makes it attractive to law
enforcement and civil trial lawyers, as well as other malicious parties.

14.1.5. Risks to the End User

Positional data stored on remote servers, when it can be tied to an individual, introduces
a new avenue for data theft. Not only can a compromise of a sensitive service reveal personal
and credit card data, it can also reveal information about users’ historical whereabouts, potentially
over an extended timeframe. This is not only a breach of user privacy, but potentially provides
information that can be used against a user in court.

The classic example of this is a divorce court subpoena, in which a service provider is
obligated to provide positional information to prove or disprove that a party in a divorce case has
been carrying on a covert relationship. This occurs with some frequency with toll-pass systems
such as FasTrak and EZPass.

Even outside of adulterous activity, positional tracking records have been subpoenaed as
evidence of how much (or little) a person works, both in divorce courts and other civil cases.

Recently, it has become fashionable for services to track one’s location and broadcast
this to other users of the service. This raises a whole new set of security concerns, where
other users may use this information for stalking or harassment, in addition to all of the
aforementioned issues. Users must be extremely vigilant to ensure that services attempting to
use data for this purpose are protecting it appropriately.

Whatever the scenario, it’s a good idea to keep track of who’s keeping track of you. End
users of geolocation technologies should take the following into account:
164

Does the application/site have a privacy policy for positional information?

Is data retained or discarded/overwritten?

If data is retained, will records be handed over to law enforcement upon request, or is a
court order required?

NO T E

Remember in the past that institutions receiving a “National Security Letter” from the FBI
are prohibited from disclosing that they’ve even received a request, much less that data was
shared. As a user, this makes it even more important to determine what amount and type of
data is being retained.

Does the provider share location data with third parties or store data with them?

Are other users of the service privy to your location data?

Are you able to easily block users?

Is this data transferred over secure channels [that is, Secure Sockets Layer (SSL)]?

Is the data accessible via other means (such as via a website)? Is this site adequately
secured?

14.1.6. Risks to Service Providers

By maintaining extended positional records on users, service providers expose themselves

to the risk of negative publicity from a data breach, legal or congressional subpoenas, and
potential assistance to criminal acts by allowing third parties to track individual users. Often,
this data isn’t really necessary to provide the required functionality. In some places, you as a
provider will have a legal obligation to follow privacy guidelines. For example, in the UK, the
Data Protection Act requires that users are made aware of who is tracking them, the purposes
for which their personal data will be collected, and whether the data will be sent to a third party,
including information about data retention and storage. To sum up, positional data is “hot”—you
don’t want to store it if there is no compelling need to do so.
 165

14.1.7. Geolocation Best Practices

Here are a few best practices when handling geolocation services. Not only do they
increase the confidence of your users, but they prevent future loss of reputation, revenue, and
other hassles that might befall you, the service provider:

Use the least precise measurement necessary. If your application merely needs
to know the city in which the user is currently located, only request this degree of accuracy from
the location API. Where “coarse” permissions are available, use these.

Discard data after use. Unless data is explicitly needed over an extended period of
time, this data should be discarded. This means that either logging subsystems should not
receive the data in the first place or they should be immediately expunged. Some companies
take the approach of overwriting past positional data immediately when an update is received.

Keep data anonymous. If data does need to be retained, ensure that it cannot be
associated with other personal data. This includes ensuring that cookies are not used for tracking
mechanisms and that requests for location data go over secure channels.

Indicate when tracking is enabled. Users should be visually notified that their
whereabouts are being recorded. Systems such as the iPhone and Android have dialogs to
inform users about this explicitly, either on use or on install. On platforms that don’t have this
capability, be sure to notify the user yourself.

Use an opt-in model. All software using geolocation data should have this functionality
disabled until explicit confirmation from the user. Provide an interface to disable this at any
time. Wherever possible, give the user the ability to specify their location manually, as with a
ZIP code.

Have a privacy policy. Be able to provide guarantees to your users about how you use
their positional data, and what you’ll do with it if it’s requested in a civil or criminal case. It’s
important to have this ready before a request like this arrives.

Do not share geolocation data with other users or services. Allowing users to
access other users’ positional data is very risky territory. Avoid this technique if at all possible.
166

Familiarize yourself with local laws. Different countries and states have different
restrictions and requirements involving tracking information. Ensure that you’re aware of the
ones that apply to your target regions.

14.2. Mobile Malware

The types of mobile malware users may be exposed to be many and varying. Following
are some examples:

Mobile spyware: This form of malicious software can infiltrate seemingly benign
programs and secretly monitor your activity, record your location, and steal sensitive passwords.
You may even have inadvertently granted an app access to harvest this information when you
downloaded it.

Rooting malware: A particularly unsavory form of malware, these bugs gain root access
to a compromised device in order to provide hackers with administrative privileges and access
to users’ files. Some rooting malware, such as Ztorg, are able to embed themselves into the
system folders, so that even a factory reset won’t be able to remove them.

Mobile banking Trojans: As mobile banking grows in popularity, an increasingly grave

problem in the cybersecurity world is mobile banking viruses. In 2017, mobile banking
Trojans attacked close to 260,000 users across 164 countries. Attackers masquerade as a legitimate
banking app to lure users into installing it, only to steal their credentials.

SMS malware: This form of malware will manipulate a mobile phone to send premium-
rate text messages, often without the user noticing until they receive a shocking bill at the end
of the month.

14.2.1. A Tour of Important Past Malware

There are in fact a large number of mobile viruses and malicious programs, but few have
had much success in terms of infection rate. Arguably, some were never much of a threat to
begin with and mostly served the purpose of illustrating the potential for future attacks. What
follows is our hit parade of notable malicious mobile programs.
 167

Cabir

The first discovered mobile malware was designed for the Symbian OS in the form of the
Cabir worm, and was largely analogous to early PC viruses—the purpose was simple replication
or vandalism. Cabir spread over Bluetooth connections, prompting users within range to install
an application and asking repeatedly until the user accepted. The worm then made system
modifications and began to scan for other Bluetooth peers within range. Cabir never gained a
significant foothold, but set off a huge flurry of speculation as to what the future would bring.

Commwarrior

In March 2005, another Symbian worm surfaced that, in addition to replication over
Bluetooth, could send copies of itself via MMS. News of the worm was widely reported, and
some antivirus vendors used this as an opportunity to sow fear in users of mobile worms.
However, Commwarrior was not widely circulated. Currently, reputable antivirus vendors rate
Commwarrior as being very low risk. Many variants have appeared, but none has spread
extensively. Still, this worm illustrated yet another path that could be used to spread malicious
mobile software.

Beselo.B

The first worm of note to use supposed media files to spread was Beselo.B. This worm
sent either JPG, MP3, or RM files over Bluetooth and MMS. It also copied itself onto MultiMedia
Cards (MMC), where it would infect any other phone into which the card was inserted. Its
codebase is fairly similar to Commwarrior, but this worm illustrated the utility of encouraging
user assistance using media as a lure.

Trojan.Redbrowser.A

In February 2006, what has been reported as the first J2ME Trojan appeared, targeted at
Russian-speaking users. Redbrowser requests SMS sending capabilities, and repeatedly
attempts to send SMS messages to premium-rate numbers. However, because the user is
prompted for each message to be sent, the impact to the individual is fairly minimal. This does
illustrate, though, how crucial these capability and permission schemes are in preventing the
spread and impact of mobile malware.
168

WinCE/Brador.a

The Brador.a Trojan infected Windows Mobile 2003 devices, notifying the Trojan’s “owner”
of the compromise and then listening on a TCP port for remote instructions. Brador.a had
simple backdoor capabilities, allowing for uploading and downloading files, executing commands,
and sending directory listings. Aside from being a prominent Trojan on the Windows Mobile
platform, the new twist with this Trojan was that its client software was reportedly for sale on
underground markets.

WinCE/Infojack

The first Windows Mobile Trojan of real impact was Infojack. This code was distributed
bundled with malicious versions of a number of standard mobile applications. Besides replicating
itself to memory cards and protecting itself from deletion, the application disables installation
prompts for unsigned applications. It uses this to update itself silently, but also allows for silent
installation of future malware.

Infojack has been disarmed by a shutdown of the creator’s site by law enforcement, but
the exposure to other malware due to the removal of installation prompts remains for affected
devices.

SMS.Python.Flocker

In early January of 2009, Kaspersky discovered a novel approach to Symbian worms. As

the name suggests, Flocker was written in Python rather than C/C++. This was quite possibly
a first for a Symbian worm, but a poor choice, because it requires that a Python interpreter be
installed on the phone. It’s possible that Flocker was a simple proof of concept, but its functionality
indicated the intent to profit from the worm’s spread—it targeted a money-transfer feature
implemented by an Indonesian mobile phone provider, sending small transfers under US$1 to
numbers owned by the attackers.

Perhaps due to the poor design decision of using a non-native language for writing a
worm, a J2ME port soon appeared, named Trojan-SMS.J2ME.GameSat.a, which exhibited
almost identical behavior.
 169

Yxes.A

Yxes.A surfaced in February 2009, again on the Symbian platform, gaining significant
media attention. This worm gathered users’ phone numbers, IMSI (International Mobile
Subscriber Identity) and IMEI (International Mobile Equipment Identification) numbers, and other
local identifying data, sending it back to servers in China. This worm actually had a valid certificate,
signed by Symbian, allowing it to install cleanly on unmodified devices. The mode of transmission
between devices was sending URLs via SMS. Infections were reportedly primarily identified in
Asia, but very little data exists on how extensively Yxes.A spread.

Others

Due to its early popularity, Symbian has largely been the platform of choice for mobile
malware authors. Symbian still makes up over 45 percent of the mobile device market share. A
variety of different worms have been reported as being in the wild, such as Doombot, Skulls,
and Pbstealer. Some even target desktop PCs, dropping payloads to be run by systems synced
with the device. However, none thus far have gained a significant foothold. Although the threats
posed by many specific worms have been overhyped, it seems likely that a worm with real
impact will surface before long—and as the variety of mobile operating systems increases,
new techniques and prevention methods will surely be developed.

14.2.2. Threat Scenarios

Fake Firmware

In 2008, US-CERT warned users of an iPhone OS 1.1.3 firmware “prep” that contained a
Trojan circulating online. The threat turned out to be relatively small, but illustrated the potential
for malware spreading by targeting phone unlockers, and potentially normal users looking to
upgrade. Malicious firmware updates are a good method to gain extremely low-level control of
a device, but many modern mobile devices implement firmware-signing schemes that make
this method difficult—and certainly it can be more challenging to encourage users to install
trojaned firmware. However, the low-level control this vector gives over the target device could
make it an attractive option.
170

Classic Trojans

The most obvious and common attack on end users is through malicious software that
appears legitimate. As seen earlier, these Trojans can offer backdoor access to attackers,
gather information, update dynamically, and generally make life difficult. This vector is made
somewhat harder on some platforms (the iPhone being the prime example), because software
must make it through a review process before even being offered to users. This means that
programmers have to be at least skilled enough to make a marginally useful iPhone application,
and able to conceal time-delayed malware functionality.

Android, of course, has taken a different approach to vetting applications, relying on a

community reputational system, which does not require application review.

One troubling twist to the Trojan threat is that of Trojans installed by service providers
themselves. In 2009, the United Arab Emirates telco Etisalat pushed out a “performance-
enhancement patch” to its BlackBerry users. This was found to be spyware of U.S. origin,
designed to intercept e-mails and accept remote control messages.

Worms

We’ve discussed several instances of mobile worms. These can be spread by attempting
to force user approval, or they can potentially be spread completely silently, if exploiting a
vulnerability in a driver or networked system process. Other vectors include SMS, MMS, MMC,
Bluetooth, Wi-Fi, Edge/3G data connections, and frequently some combination thereof.

An aggressive and widespread worm could even use phone carriers’ resources and
infrastructures to such a degree that it would cause real performance degradation for the carriers
and their customers. Such software is likely to be the most troublesome mobile device affliction
in the future.

Ransomware

More than one instance has been found in the wild where a malicious program will disable
a device or sequester user data, usually encrypting it, and then demand payment in return for
decryption keys or a return to normal functionality. On a desktop, this may not always be
 171

successful—a user may not have much important data locally, instead storing it on web services.
The disabling of a mobile phone can be far more urgent to the user, increasing the odds they
might pay up.

In this scenario, the user’s data is encrypted with a symmetric key. The attacker then
informs the user they must either purchase a tool to decrypt it, purchase the symmetric key
directly, or send an SMS message which accrues charges. However, depending on the infection
vector and platform, application sandboxing may limit the amount of data which can be encrypted.

14.2.3. Mitigating Mobile Malware

So, what can be done about this situation before it worsens? Are we doomed to run
antivirus software on our phones, and click “Allow” constantly? A few different approaches
involving users, developers, and platform vendors can help curb the impact of mobile malware.

For End Users

Modern mobile platforms implement application signing, third-party verification, and/or

reputation systems to prevent malicious applications from being distributed to end users. It is
critical that users be educated as to the meaning of these, and made aware of the risks of
installing untrusted third-party software, opening unrecognized SMS/MMS messages, and
acquiring untrusted media files. These behaviours should be developed before the advent of
high-impact malware; at least in the mobile space, we have the advantage of advance warning.

In enterprise environments, administrators should use available platform facilities to restrict

permission sets and push policy updates.

For Developers and Platform Vendors

The App Store and Android Market offer an interesting contrast. The former relies on
manual vetting of applications by Apple, and the latter works on a community trust-based system.
Symbian implements signing mechanisms for different capabilities, and Windows Mobile
implements nothing. One thing that is crucial, regardless of platform, is that vendors pay serious
attention to security UI. Users can only be expected to be diligent about preventing the spread of
172

malware if prevention mechanisms are simple and easy enough to use and understand. This
has historically proven to be no simple task—even simple mechanisms such as the browser
Secure Sockets Layer (SSL) “lock” icon have had poor efficacy. And sadly, security UI often
relies on making actions difficult and annoying. Striking a balance takes careful attention and
testing.

Vendors can help by implementing usable capability systems to make applications adhere
to a principle of least privilege. Also, enabling exploit-prevention features such as nonexecutable
stack and heap can also help to prevent against the spread of malware via vulnerabilities in C
software.

14.3. Mobile Application Penetration Testing

The Mobile Application Penetration Testing Methodology is a form of security testing used
to analyze security from inside of a mobile environment. That built on OWASP mobile application
security verification standard. The mobile application penetration testing
methodology concentrates on client-side safety, file system, hardware, and network security.

By conducting penetration tests, the company can gain knowledge of vulnerabilities in the
mobile application, bottlenecks, loopholes, and attack vectors before delivering an app to the
user. As a result, the company can change the design, code, and architecture before release.
The cost of fixing the issue at this stage is less than addressing later when a breach or a flaw
gets discovered. The price at post-rollout step joins not only financial matters but also PR,
legal, and more.

14.3.1. Stages

The Mobile Application Security Testing divides into four stages:

 Preparation – requires the pentester to obtain information that is crucial in knowing events
that lead to the successful exploitation of mobile applications.

 Evaluation – analysis involves the penetration tester going through the mobile application
and recognizing potential entry points and vulnerabilities that can exploit.
 173

 Exploitation – penetration tester trying to exploit discovered vulnerabilities to take profit of

the mobile application in a manner not meant by the programmer initially didn’t expect.

 Reporting – it’s involves reporting and presenting the discovered results in a manner that
makes sense to management. That is also the stage that separates a penetration test
from an attack. A complete discussion of the four steps follows.

14.3.2. Preparation

Intelligence gathering is the most significant step in a penetration test. The ability to find
hidden cues that might shed light on the occurrence of vulnerability can be the difference within
a successful and unsuccessful pentest. Reconnaissance involves next steps:

1. The first stage is open-source intelligence(OSINT) gathering, which gives for a review of
publicly accessible information and resources. Pentester searches information about the
application in all possible sources. That can found on search engines and social networks,
leaked source code through version control systems, developer boards, or even on the
dark web.

2. Architecture understanding – penetration tester needs to understand the mobile application

architecture, also from an outside point of view, to aid in generating a threat model for the
application. The pentester brings into account the company following the app, its business
case, and relevant stakeholders. The internal structures and processes are also addressed
to account.

3. Client and server-side scenarios – penetration tester needs to be able to recognize the
type of application (native, hybrid, or web) and to manage test cases. The application
network interfaces, user data, communication with third party resources, session
management, jailbreaking/rooting detecting.

14.3.3. Assessment

The process of mobile assessment applications is different because it challenges the

penetration tester to compare the apps before and after installation. The evaluation techniques
that encountered within the mobile security include:
174

 File system analysis – pentester examines the local files written on the file system by the
application to assure that there are no breaches.

 Package analysis – unpack the application installation bundles for the Android and iOS
operating systems. An analysis should be done to assure that there are no changes in
configurations of the compiled binary.

 Reverse engineering – means transforming the compiled applications into human-readable

source code. The penetration tester analyzes the decompiled code to understand the
intuitive application functionality and hunt for vulnerabilities. Note: An android application
may be modified once changed and recompiled.

 Static analysis – penetration tester does not execute the application. The investigation is
doing on the provided files or decompiled source code.

 Dynamic analysis – pentester reviews the mobile application as it runs on the device or
emulator. Reviews done include a forensic examination of the file system, assessment of
the network communication between the application and server, and an evaluation of the
application’s inter-process communication (IPC).

Inter-Process Communication Endpoint Analysis – pentester reviews the different mobile

application IPC endpoints. Assessment performing on:

1. Content providers – these ensure that access to databases reached.

2. Intents – these are signals used to send messages between components of the android
system.

3. Broadcast receivers – these receive and act on intents received from other applications
on the android system.

4. Activities – these make up the screens or pages within the application.

5. Services – These run from the background and perform tasks regardless of whether the
main application is running.
 175

14.3.4. Exploitation

Penetrations testing engineer operates upon the information determined from the
information-gathering step to attack the mobile application. Entirely performed intelligence
gathering ensures a high possibility of a successful project.

This phase includes exercising all potential vulnerabilities recognized in the previous stages
of the assessment and trying to exploit them as an attacker would. Not only automatically
recognize vulnerabilities that exploited, but issues requiring hand-operated classification and
exploitation evaluated, as well. That involves business logic flaws, authentication/authorization
bypasses, direct object references, parameter tampering, and session management. Pentester
tries to exploit the vulnerability to gain sensitive information or perform malicious actions. Then
finally delivers privilege escalation to raise to the most privileged user (root) to not face any
restrictions on any actions that completed.

14.3.5. Reporting

Preparing reports

The output provided generally includes an executive-level paper and a technical report.
The executive-level paper is written for management consumption and covers a high-level
summary of assessment activities, scope, most critical vulnerabilities discovered, overall risk
scoring. The technical report, on the other hand, includes all vulnerabilities fixed individually,
with specifications on how to recreate the vulnerability, understand the risk, recommended
remediation operations, and helpful reference links.

14.3.6. Presentation

The final activity in any assessment being a presentation of all documentation to the
client. We walk the client within the information provided, make any updates needed, and address
questions regarding the assessment output. Following this activity, we’ll give new revisions of
documentation and schedule any formal retesting, if it is applicable.
176

Remediation testing

When client finishes with vulnerabilities penetration tester validates and approves it.

14.4. Summary

 Tower triangulation is the oldest widely used method of geolocation via cell phone.

 Using satellite signals instead of cell phone or wireless infrastructure, GPS service is
often available at times when other methods are not.

 An advantage of GPS is that it can provide continuous tracking updates, useful for real-
time applications, instead of just one-time lookups.

 Rooting malware: A particularly unsavory form of malware, these bugs gain root access
to a compromised device in order to provide hackers with administrative privileges and
access to users’ files.

 Mobile spyware: This form of malicious software can infiltrate seemingly benign
programs and secretly monitor your activity, record your location, and steal sensitive
passwords.

 The first discovered mobile malware was designed for the Symbian OS in the form of the
Cabir worm, and was largely analogous to early PC viruses—the purpose was simple
replication or vandalism.

 In March 2005, another Symbian worm surfaced that, in addition to replication over
Bluetooth, could send copies of itself via MMS.

 The first worm of note to use supposed media files to spread was Beselo.B.

 The Mobile Application Penetration Testing Methodology is a form of security testing used
to analyze security from inside of a mobile environment.
 177

14.5. Review Questions

1. Illustrate the penetration testing process in the mobile devices.

2. Write short note on Geo Location identification through 802.11.

3. List the malwares that affected the mobile devices.

4. Explain in detail on any one threat scenario in mobile devices.

14.6. Further Reading

 https://books.nowsecure.com/secure-mobile-development/en/sensitive-data/treat-
geolocation-data-carefully.html

 https://www.helpnetsecurity.com/2011/09/27/avoid-mobile-device-geolocation-risks/

 https://www.forcepoint.com/cyber-edu/mobile-malware

 https://www.zdnet.com/article/mobile-malware-attacks-are-booming-in-2019-these-are-
the-most-common-threats/

 https://threatpost.com/ransomware-mobile-malware-attacks-to-surge-in-2020/149539/

 https://securelist.com/mobile-malware-evolution-2019/96280/

 https://www.nowsecure.com/solutions/by-need/mobile-app-penetration-testing/

 https://www.nowsecure.com/solutions/by-need/mobile-app-penetration-testing/
178

UNIT 15
THREAT MODELLING

Learning Objectives

 In this chapter, the concept of threat modelling steps is discussed.

 A learner will be able to understand the and every step in the threat modelling in detail. And
the learner will also know about DREAD and the formula to calculate risk rating.

Structure
15.1 Threat Modelling

15.2 Identify Security Objectives

15.3 Create an application overview

15.4 Decompose your Application

15.5 Identify Threats

15.6 Document the Threats

15.7 Rate the Threats

15.8 Summary

15.9 Review Questions

15.10 Further Reading

15.1. Threat Modelling

Threat modelling is a structured approach to identifying, quantifying, and addressing

threats. It allows system security staff to communicate the potential damage of security flaws
and prioritize remediation efforts.

In threat modelling, we cover the three main elements:

 Assets: What valuable data and equipment should be secured?

 179

 Threats: What may an attacker do to the system?

 Vulnerabilities: What flaws in the system allow an attacker to realize a threat?

In an organization, there are different threats that are addressed to different layers of an
organization framework and environment. The three main layers of a threat target are:

 Network: The threat includes spoofed, malicious packets, etc.

 Host: The threat includes Buffer overflow, malicious file, etc.

 Application: The threat includes SQL injection, XSS, input tampering, etc.

15.2. Identify Security Objectives

Security objectives are goals and constraints related to the confidentiality, integrity, and
availability of your data and application. They include:

 Confidentiality. This includes protecting against unauthorized information disclosure.

 Integrity. This includes preventing unauthorized information changes.

 Availability. This includes providing the required services even while under attack.

Security-specific objectives are a subset of project objectives, and you should use them
to guide your threat modelling efforts. You may find it helpful to think of security objectives in
terms of constraints. Consider the question, “What do you not want to happen?” For example,
an attacker must not be able to steal user credentials.

By identifying your key security objectives, you can determine where to focus your efforts.
Identifying your objectives also helps you to understand the goals of potential attackers and
concentrate on those areas of your application that require closer attention. For example, if you
identify customer account details as sensitive data that needs protecting, you can examine
how securely the data is stored and how access to the data is controlled and audited.

To determine your security objectives, consider the following questions:

 What client data do you need to protect? For example, does your application use
user accounts and passwords, customer account details including personalization
180

information, financial history and transaction records, customer credit card numbers,
bank details, or travel itineraries?

 Do you have compliance requirements? Compliance requirements may include

security policy, privacy laws, regulations, and standards.

 Do you have specific quality of service requirements? Quality of service

requirements includes availability and performance requirements.

 Are there intangible assets that you need to protect? Intangible items include
your company’s reputation, trade secrets, and intellectual property.

The following are examples of some common security objectives:

 Prevent attackers from obtaining sensitive customer data, including passwords and profile
information.

 Meet service-level agreements for application availability.

 Protect the company’s online business credibility.

15.3. Create an Application Overview

In this step, you outline what your Web application does. Your goal is to identify your
application’s key functionality, characteristics, and clients. This will help you to identify relevant
threats during step 4.

Note Remember that threat modelling is an iterative process. Do not let this step block
your progress. Identify as much detail as you can and then add more detail as your design
evolves. For example, if you are in the middle of your design and have not tackled physical
deployment, you can still perform this step, although with less data. Itemize what you can as
soon as you can.

To create an application overview:

 Draw the end-to-end deployment scenario.

 Identify roles.
 181

 Identify key usage scenarios.

 Identify technologies.

 Identify application security mechanisms.

15.3.1. Draw the End-to-End Deployment Scenario

Use a whiteboard to draw the end-to-end deployment scenario. First, draw a rough diagram
that describes the composition and structure of your application, its subsystems, and its
deployment characteristics. Add details about the authentication, authorization, and
communication mechanisms as you discover them. Remember that you may not have all of
the details early in the design process.

Figure 15.1 is an example of an initial whiteboard diagram that shows the application
architecture with some details.

Figure 15.1 : Example whiteboard drawing depicting an application architecture

Your deployment diagram should generally include the following:

 End-to-end deployment topology. Show the layout of the servers and indicate intranet,
extranet, or Internet access. Start with logical network topologies, and then refine this to
show physical topologies when you have those details. You can add or remove threats
depending on your choice of specific physical topologies.
182

 Logical layers. Shows where the presentation layer, business layer, and data access
layers reside. Refine this to include physical server boundaries when you know them.

 Key components. Show the important components within each logical layer. Refine
this to include actual process and component boundaries when you know them.

 Key services. Identify any important services. Show these as processes when you
know them.

 Communication ports and protocols. Show which servers, components, and services
communicate with each other and how they do it. Show the specifics of inbound and
outbound information packages when you know them.

 Identities. Show the main identities used for the application and any relevant service
accounts if you have this information.

 External dependencies. Show the dependencies that your application has on external
systems. Later in the modelling process, this will help you identify vulnerabilities that can
arise if any assumptions you make about the external systems are false or if the external
systems change in any way.

Note As your design evolves, you should regularly revisit the threat model to add more
detail. For example, you might not know all of the components initially. Subdivide your application
as necessary to get enough detail to find your threats.

15.3.2. Identify Roles

Identify your application’s roles: that is, identify who can do what within your application.
What can your users do? What higher-privileged groups of users do you have? For example,
who can read data, who can update data, who can delete data?

Use role identification to determine both what is supposed to happen and what is not
supposed to happen.
 183

15.3.3. Identify Key Usage Scenarios

What are the important features of your application? What does it do? Use your
application’s use cases to derive this information. Identify the dominant application functionality
and usage, and capture the Create, Read, Update, and Delete aspects.

Key features are often explained in the context of use cases. They can help you and
others to understand how your application is intended to be used and how it can be misused.
Use cases help you identify data flows and provide focus when you identify threats later in the
modelling process.

Avoid attempting to list every possible use case. Instead, start by identifying the main use
cases that exercise the predominant Create, Read, Update, and Delete functionality of your
application.

For example, a self-service, employee human resources application might include the
following use cases:

 Employee views financial data.

 Employee updates personal data.

 Manager views employee details.

 Manager deletes employee records.

In these cases, you can look at the possibilities of the business rules being misused. For
example, consider a user trying to modify personal details of another user. You often need to
consider several use cases happening simultaneously to perform a complete analysis.

Also identify what scenarios are out of scope, and use your key scenarios to constrain
the discussion. For example, you might decide that operational practices, such as backup and
restore, are out of scope for the initial threat modelling exercise.

15.3.4. Identify Technologies

Where you can identify them, list the technologies and key features of the software and
technologies that you use. Identify the following:
184

 Operating systems

 Web server software

 Database server software

 Technologies used in the presentation, business, and data access layers

 Development languages

Identifying technologies helps you to focus on technology-specific threats later in the

threat modelling activity. It also helps you determine the correct and most appropriate mitigation
techniques.

15.3.5. Identify Application Security Mechanisms

Identify any key points that you know about the following:

 Input and data validation

 Authentication

 Authorization

 Configuration management

 Sensitive data

 Session management

 Cryptography

 Parameter manipulation

 Exception management

 Auditing and logging

The purpose of this effort is to identify interesting details and be able to add detail where
necessary, or to identify where you might need to learn more.

For example, you might know how your application is authenticated by the database or
how your users are authorized. You might know the other areas where your application performs
 185

authentication and authorization. You might also know certain details about how input validation
is to be performed. Highlight these and other key elements of your application security
mechanisms.

15.4. Decompose Your Application

In this step, you break down your application to identify trust boundaries, data flows, entry
points, and exit points. The more you know about the mechanics of your application, the easier
it is to uncover threats and discover vulnerabilities. To decompose your application:

 Identify trust boundaries.

 Identify data flows.

 Identify entry points.

 Identify exit points.

15.4.1. Identify Trust Boundaries

Identify your application’s trust boundaries to help focus your analysis on areas of concern.
Trust boundaries indicate where trust levels change. You can think of trust from the perspective
of confidentiality and integrity. For example, a change in access control levels in your application
where a specific role or privilege level is required to access a resource or operation would be a
change in trust level. Another example would be at an entry point in your application where you
might not fully trust the data passed to the entry point.

To help identify trust boundaries:

 Start by identifying your outer system boundaries. For example, your application can write
to files on server X, it can make calls to the database on server Y, and it can call Web
service Z. This defines your system boundary.

 Identify access control points or the key places where access requires additional privileges
or role membership. For example, a particular page might be restricted to managers. The
page requires authenticated access and also requires that the caller is a member of a
particular role.
186

 Identify trust boundaries from a data flow perspective. For each subsystem, consider
whether the upstream data flow or user input is trusted, and if it is not, consider how the
data flow and input can be authenticated and authorized. Knowing which entry points
exist between trust boundaries allows you to focus your threat identification on these key
entry points. For example, you are likely to have to perform more validation on data passed
through an entry point at a trust boundary.

Some example trust boundaries are:

 A perimeter firewall. The firewall is likely to be the first trust boundary. It moves qualified
information from the untrusted Internet to your trusted data centre.

 The boundary between the Web server and database server. Your database may or may
not be included in your application’s trust boundary. Often the Web servers act as a
second firewall to the databases. This significantly limits network access to the databases
and thereby reduces the attack surface. Describe the network topology within your data
centre. Do any other applications write to the database? If they do, do you trust those
applications? If you trust the applications that write to the database, you may still not want
to trust the database—is it protected?

 The entry point into a business component that exposes privileged data (data that should
be available to only particular users). In this case, you need an access check to ensure
that only the appropriate callers are allowed access. This is a trust boundary.

 The boundary between your application and a third-party service. Do you trust the service’s
identity? Can you trust the data returned from the service?

15.4.2. Identify Data Flows

Trace your application’s data input through the application from entry to exit. You do this to
understand how your application interacts with external systems and clients and how internal
components interact. Pay particular attention to data flow across trust boundaries and how that
data is validated at the trust boundary entry point. Also pay close attention to sensitive data
items and how these flow through your system, where they are passed over a network, and
where they are persisted.
 187

A good approach is to start at the highest level and then deconstruct the application by
analyzing the data flow between individual subsystems. For example, start by analyzing the
data flow between your Web application, your middle tier servers, and your database server.
Then consider page-to-page and component-to-component data flows.

15.4.3. Identify Entry Points

The entry points of your application also serve as entry points for attacks. Entry points
can include the front-end Web application listening for HTTP requests. This entry point is intended
to be exposed to clients. Other entry points, such as internal entry points exposed by
subcomponents across the layers of your application, may exist only to support internal
communication with other components. However, you should know where these are and what
types of input they receive in case an attacker manages to bypass the front door of the application
and directly attack an internal entry point. Additional levels of checking provides defense in
depth but may be costly in terms of money and performance.

Consider the trust levels required to access an entry point and the type of functionality
exposed by the entry point. Early in the threat modelling activity, focus your attention on entry
points that expose privileged functionality, such as administration interfaces.

15.4.4. Identify Exit Points

Identify the points where your application sends data to the client or to external systems.
Prioritize the exit points where your application writes data that includes client input or includes
data from untrusted sources, such as shared databases.

15.5. Identify Threats

In this step, you identify threats and attacks that might affect your application and
compromise your security objectives. These threats are the bad effects that could happen to
your application. To conduct this identification process, bring members of the development and
test teams together to conduct an informed brainstorming session. Use a whiteboard to identify
potential threats. Ideally, the team consists of application architects, security professionals,
developers, testers, and system administrators.
188

You can use two basic approaches:

 Start with common threats and attacks. With this approach, you start with a list of
common threats grouped by application vulnerability categories. Next, apply the threat list
to your own application architecture. While doing this, use the data you gathered. For
example, use the identified scenarios to review data flows, paying particular attention to
entry points and where trust boundaries are crossed. You will be able to eliminate some
threats immediately because they do not apply to your application and its use cases. Use
the “Cheat Sheet: Web Application Security Frame” as a starting point.

 Use a question-driven approach. A question-driven approach can help you identify

relevant threats and attacks. The STRIDE categorization includes broad categories of
threats, such as spoofing, tampering, repudiation, information disclosure, and denial of
service. You can use the STRIDE model to ask questions related to each aspect of the
architecture and design of your application. This is a goal-based approach, where you
consider the goals of an attacker. For example, could an attacker spoof an identity to
access your server or Web application? Could someone tamper with data over the network
or in a data store? Is sensitive information disclosed when you report an error message
or log an event? Could someone deny service?

While identifying threats, examine the application tier by tier, layer by layer, and feature by
feature. By focusing on vulnerability categories, you focus on the areas where security mistakes
are most frequently made. The threats identified at this stage do not necessarily indicate
vulnerabilities. Identify potential threats and the actions that an attacker might try to use to
exploit the application.

During this step, you perform the following tasks:

 Identify common threats and attacks.

 Identify threats along use cases.

 Identify threats along data flows.

 189

15.5.1. Identify Common Threats and Attacks

There are a number of common threats and attacks that rely on common vulnerabilities.
As a starting point, use the companion document, “Cheat Sheet: Web Application Security
Frame.” The cheat sheet will help you identify threats and attacks relevant to your application.

Web Application Security Frame

The following vulnerability categories were developed by security experts who have
examined and analyzed the top security issues across many Web applications. They have
been refined with input from Microsoft consultants, product support engineers, customers, and
Microsoft partners. This section identifies a set of key questions to ask for each category.

Authentication

Review authentication by asking the following:

 How could an attacker spoof identity?

 How could an attacker gain access to the credential store?

 How could an attacker mount a dictionary attack? How are your user’s credentials stored
and what password policies are enforced?

 How can an attacker modify, intercept, or bypass your user’s credential reset mechanism?

Authorization

Review authorization by asking the following:

 How could an attacker influence authorization checks to gain access to privileged

operations?

 How could an attacker elevate privileges?

Input and Data Validation

 Review input and data validation by asking the following:

 How could an attacker inject SQL commands?

 How could an attacker perform a cross-site scripting attack?

190

 How could an attacker bypass input validation?

 How could an attacker send invalid input to influence security logic on the server?

 How could an attacker send malformed input to crash the application?

Configuration Management

Review configuration management by asking the following:

 How could an attacker gain access to administration functionality?

 How could an attacker gain access to your application’s configuration data?

Sensitive Data

Review sensitive data by asking the following:

 Where and how does your application store sensitive data?

 When and where is sensitive data passed across a network?

 How could an attacker view sensitive data?

 How could an attacker manipulate sensitive data?

Session Management

Review session management by asking the following:

 Do you use a custom encryption algorithm, and do you trust the algorithm?

 How could an attacker hijack a session?

 How could an attacker view or manipulate another user’s session state?

Cryptography

Review cryptography by asking the following:

 What would it take for an attacker to crack your encryption?

 How could an attacker obtain access to encryption keys?

 Which cryptographic standards are you using? What, if any, are the known attacks on
these standards?
 191

 Are you creating your own cryptography?

 How does your deployment topology potentially impact your choice of encryption methods?

Parameter Manipulation

Review parameter manipulation by asking the following:

 How could an attacker manipulate parameters to influence security logic on the server?

 How could an attacker manipulate sensitive parameter data?

Exception Management

Review exception management by asking the following:

 How could an attacker crash the application?

 How could an attacker gain useful exception details?

Auditing and Logging

Review auditing and logging by asking the following:

 How could an attacker cover his or her tracks?

 How can you prove that an attacker (or legitimate user) performed specific actions?

15.5.2. Identify Threats along Use Cases

Examine each of your application’s key use cases that you identified earlier, and examine
ways in which a user could maliciously or unintentionally coerce the application into performing
an unauthorized operation or into disclosing sensitive or private data.

Ask questions and try to think as an attacker would. Examples of the types of question
you should ask include the following:

 How can a client inject malicious input here?

 Is data being written out based on user input or on unvalidated user input?

 How could an attacker manipulate session data?

192

 How could an attacker obtain sensitive data as it is passed over the network?

 How could an attacker bypass your authorization checks?

15.5.3. Identify Threats along Data Flows

Review the key use cases and scenarios, and analyze the data flows. Analyze the data
flow between individual components in your architecture. Data flow across trust boundaries is
particularly important. A piece of code should assume that any data from outside the code’s
trust boundary is malicious. The code should perform thorough validation of the data.

When identifying threats associated with data flows, ask the following questions:

 How does data flow from the front end to the back end of your application?

 Which components call which components?

 What does valid data look like?

 Where is validation performed?

 How is the data constrained?

 How is data validated against expected length, range, format, and type?

 What sensitive data is passed between components and across networks, and how is
that data secured while in transit?

Note Use existing documentation if you have it. For example, data flow diagrams (DFDs)
and Unified Modelling Language (UML) sequence diagrams can help you to analyze your
application and identify data flows.

15.5.4. Explore Additional Threats by Using Threat/Attack Trees

The previous activities have helped you to identify the more obvious and pervasive security
issues. You can now explore additional threats and attacks. Attack trees and attack patterns
are the primary tools that many security professionals use. They allow you to analyze threats in
greater depth, going beyond what you already know to identify other threat possibilities.
 193

The categorized lists of known threats only reveal the common, known threats. Additional
approaches, such as using threat/attack trees and attack patterns, can help you identify other
potential threats.

An attack tree is a way of identifying and documenting the potential attacks on your system
in a structured and hierarchical manner. The tree structure gives you a detailed picture of various
attacks that the attacker uses to compromise the system. By creating attack trees, you create
a reusable representation of security issues that will help to focus your threat and mitigation
efforts. Your test team can use the trees to create test plans that validate security design.
Architects or developer leads can use the trees to evaluate the security cost of alternative
approaches. Developers can use the trees to make informed coding decisions during
implementation.

Attack patterns are a formalized approach to capturing attack information in your enterprise.
These patterns can help you identify common attack techniques.

Creating Attack Trees

When creating an attack tree, assume the role of the attacker. Consider what you must
do to launch a successful attack and identify goals and sub-goals of the attack. You can use a
hierarchical diagram to represent your attack tree, or you can use a simple outline. What is
important is that you construct something that portrays the attack profile of your application.
Then you can evaluate security risks and use the appropriate countermeasures to mitigate
them, such as correcting a design approach, hardening a configuration setting, and other
solutions.

Start building an attack tree by creating root nodes that represent the goals of the attacker.
Then add the leaf nodes, which are the attack methodologies that represent unique attacks.
Figure 15.2 shows a simple example.
194

Figure 15.2 : Attack tree example

You can label leaf nodes with AND and OR labels. For example, in Figure 15.2, both 1.1
and 1.2 must occur for the threat to result in an attack.

Attack trees like the one in Figure 15.2 have a tendency to become complex quickly. They
are also time-consuming to create. An alternative approach is to structure your attack tree
using an outline, such as the following.

1. Goal One

1.1. Sub-goal one

1.2. Sub-goal two2

2. Goal Two

2.1. Sub-goal one

2.2. Sub-goal two

Note In addition to goals and sub-goals, attack trees include methodologies and required
conditions.
 195

The following is a more complete example of the outline approach.

Threat #1 Attacker obtains authentication credentials by monitoring the network

1.1 Clear text credentials sent over the network

AND

1.2 Attacker uses network-monitoring tools

1.2.1 Attacker recognizes credential data

15.5.5. Identify Vulnerabilities

In this step, you review the Web application security frame and explicitly look for
vulnerabilities. Focus on the vulnerability categories as you did while identifying threats in the
previous step. However, note that the sample questions presented in this section are designed
to help you identify vulnerabilities, not threats. A useful way of proceeding is to examine your
application layer by layer, considering each of the vulnerability categories in each layer.

Authentication

Identify authentication vulnerabilities by asking the following:

 Are user names and passwords sent in clear text over an unprotected channel? Is any ad
hoc cryptography used for sensitive information?

 Are credentials stored? If they are stored, how are they stored and protected?

 Do you enforce strong passwords? What other password policies are enforced?

 How are credentials verified?

 How is the authenticated user identified after the initial logon?

Review authentication by looking for these common vulnerabilities:

 Passing authentication credentials or authentication cookies over unencrypted network

links, which can lead to credential capture or session hijacking
196

 Using weak password and account policies, which can lead to unauthorized access

 Mixing personalization with authentication

Authorization

Identify authorization vulnerabilities by asking the following:

 What access controls are used at the entry points of the application?

 Does your application use roles? If it uses roles, are they sufficiently granular for access
control and auditing purposes?

 Does your authorization code fail securely and grant access only upon successful
confirmation of credentials?

 Do you restrict access to system resources?

 Do you restrict database access?

 How is authorization enforced at the database?

Review authorization by looking for these common vulnerabilities:

 Using over-privileged roles and accounts

 Failing to provide sufficient role granularity

 Failing to restrict system resources to particular application identities

Input and Data Validation

 Identify input and data validation vulnerabilities by asking the following:

 Is all input data validated?

 Do you validate for length, range, format, and type?

 Do you rely on client-side validation?

 197

 Could an attacker inject commands or malicious data into the application?

 Do you trust data you write out to Web pages, or do you need to HTML-encode it to help
prevent cross-site scripting attacks?

 Do you validate input before using it in SQL statements to help prevent SQL injection?

 Is data validated at the recipient entry point as it is passed between separate trust
boundaries?

 Can you trust data in the database?

 Do you accept input file names, URLs, or user names? Have you addressed
canonicalization issues?

Review input validation by looking for these common vulnerabilities:

 Relying exclusively on client-side validation

 Using a deny approach instead of allow for filtering input

 Writing data you did not validate out to Web pages

 Using input you did not validate to generate SQL queries

 Using insecure data access coding techniques, which can increase the threat posed by
SQL injection

 Using input file names, URLs, or user names for security decisions

Configuration Management

Identify configuration management vulnerabilities by asking the following:

 How do you protect remote administration interfaces?

 Do you protect configuration stores?

 Do you encrypt sensitive configuration data?

198

 Do you separate administrator privileges?

 Do you use least privileged process and service accounts?

Review configuration management by looking for these common vulnerabilities:

 Storing configuration secrets, such as connection strings and service account credentials,
in clear text

 Failing to protect the configuration management aspects of your application, including

administration interfaces

 Using over-privileged process accounts and service accounts

Sensitive Data

Identify sensitive data vulnerabilities by asking the following:

 Do you store secrets in persistent stores?

 How do you store sensitive data?

 Do you store secrets in memory?

 Do you pass sensitive data over the network?

 Do you log sensitive data?

Review sensitive data by looking for these common vulnerabilities:

 Storing secrets when you do not need to store them

 Storing secrets in code

 Storing secrets in clear text

 Passing sensitive data in clear text over networks

Session Management

Identify session management vulnerabilities by asking the following:

 How are session cookies generated?

 How are session identifiers exchanged?

 199

 How is session state protected as it crosses the network?

 How is session state protected to prevent session hijacking?

 How is the session state store protected?

 Do you restrict session lifetime?

 How does the application authenticate with the session store?

 Are credentials passed over the network and are they maintained by the application? If
they are, how are they protected?

Review session management by looking for these common vulnerabilities:

 Passing session identifiers over unencrypted channels

 Prolonged session lifetime

 Insecure session state stores

 Session identifiers in query strings

Cryptography

Identify cryptography vulnerabilities by asking the following:

 What algorithms and cryptographic techniques are used?

 Do you use custom encryption algorithms?

 Why do you use particular algorithms?

 How long are encryption keys, and how are they protected?

 How often are keys recycled?

 How are encryption keys distributed?

Review cryptography by looking for these common vulnerabilities:

 Using custom cryptography

 Using the wrong algorithm or a key size that is too small

 Failing to protect encryption keys

200

 Using the same key for a prolonged period of time

Parameter Manipulation

Identify parameter manipulation parameters by asking the following:

 Do you validate all input parameters?

 Do you validate all parameters in form fields, view state, cookie data, and HTTP headers?

 Do you pass sensitive data in parameters?

 Does the application detect tampered parameters?

Review parameter manipulation by looking for these common vulnerabilities:

 Failing to validate all input parameters. This makes your application susceptible to denial
of service attacks and code injection attacks, including SQL injection and XSS.

 Including sensitive data in unencrypted cookies. Cookie data can be changed at the client
or it can be captured and changed as it is passed over the network.

 Including sensitive data in query strings and form fields. Query strings and form fields are
easily changed on the client.

 Trusting HTTP header information. This information is easily changed on the client.

Exception Management

Identify exception management vulnerabilities by asking the following:

 How does the application handle error conditions?

 Are exceptions ever allowed to propagate back to the client?

 What type of data is included in exception messages?

 Do you reveal too much information to the client?

 Where do you log exception details? Are the log files secure?

Review exception management by looking for these common vulnerabilities:

 Failing to validate all input parameters

 Revealing too much information to the client

 201

Auditing and Logging

Identify auditing and logging vulnerabilities by asking the following:

 Have you identified key activities to audit?

 Does your application audit activity across all layers and servers?

 How are log files protected?

Review auditing and logging by looking for these common vulnerabilities:

 Failing to audit failed logons

 Failing to protect audit files

 Failing to audit across application layers and servers

15.6. Document the Threats

After you complete the threat modelling activity, do the following:

 If you capture your threat model in a document, keep the document lightweight and avoid
over-formatting so you can easily update it. Key content should include your security
objectives, key scenarios, protected resources, a threat list, and a vulnerability list.

 Use the vulnerabilities to help shape your security design and implementation. For example,
developers should notice anti-patterns related to the identified vulnerabilities and use
patterns to address the issues.

 Use the vulnerabilities to plan and scope your system testing. For example, testers should
test against the vulnerabilities to verify that the development team fixed or addressed all
vulnerabilities.

 Track and prioritize vulnerabilities in your work item tracking system.

 If you have high priority threats and you have no corresponding vulnerabilities, you need to
make a decision. Without a vulnerability to track and act on, the threat you identified can
be easily overlooked. Will you investigate it further to identify vulnerabilities or rule it out of
scope or accept the risk?
202

 Communicate the information you capture to relevant team members. This may include
your application development team, your test team, and your network and system
administrators.

15.7. Rate the threats

15.7.1. DREAD

DREAD, is about evaluating each existing vulnerability using a mathematical formula to

retrieve the vulnerability’s corresponding risk. The DREAD formula is divided into 5 main
categories:

 Damage - how bad would an attack be?

 Reproducibility - how easy it is to reproduce the attack?

 Exploitability - how much work is it to launch the attack?

 Affected users - how many people will be impacted?

 Discoverability - how easy it is to discover the threat?

DREAD formula is:

Risk Value = (Damage + Affected users) x (Reproducibility + Exploitability

+ Discoverability).

Then the risk level is determined using defined thresholds below.

15.7.2. Rank Risks

Risk Rating (RR) = Probability of Occurrence (OV) x Severity of Consequences Value

(CV)

Using risk matrix rank risks from most severe to least severe based on Means, Motive &
Opportunity. Below is a sample risk matrix table, depending on your risk approach you can
define different risk ranking matrix:
 203

 Risk Value: 01 to 12  Risk Level: Notice

 Risk Value: 13 to 18  Risk Level: Low

 Risk Value: 19 to 36  Risk Level: Medium

 Risk Value: 37 to 54  Risk Level: High

15.8. Summary

 The three main elements of thread modelling are Assets, Threats and Vulnerabilities and
the three main layer the threat targets are Network, Host and Application.

 Threat modelling is an iterative process.

 In decompose your application, you break down your application to identify trust
boundaries, data flows, entry points, and exit points.

 The entry points of your application also serve as entry points for attacks.

 While identifying threats, examine the application tier by tier, layer by layer, and feature by
feature. By focusing on vulnerability categories, you focus on the areas where security
mistakes are most frequently made.

 Attack trees and attack patterns, can help you identify other potential threats.

 DREAD, is about evaluating each existing vulnerability using a mathematical formula to

retrieve the vulnerability’s corresponding risk.

 DREAD formula is: Risk Value = (Damage + Affected users) x (Reproducibility +

Exploitability + Discoverability).

 Risk Rating (RR) = Probability of Occurrence (OV) x Severity of Consequences Value

(CV).
204

15.9. Review Questions

1. How to draw the End-to-End Deployment Scenario?

2. Explain the creation of attack trees.

3. List the steps in the Threat Modelling.

4. Elaborate how to document the threats.

5. Illustrate evaluating each existing vulnerability using a mathematical formula to retrieve

the vulnerability’s corresponding risk.

15.10. Further Reading

 https://owasp.org/www-community/Application_Threat_Modeling

 https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html

 https://securityintelligence.com/posts/what-is-threat-modeling-and-how-does-it-impact-
application-security/

 https://searchsecurity.techtarget.com/definition/threat-modeling

 https://threatmodeler.com/approaches-to-threat-modeling/

 https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/
 205

UNIT 16
CHECKLIST

Learning Objectives

 In this chapter, the concept of compliance and checklist are discussed.

 A learner will be able to understand about NIST compliance and what are the checklists
used.

Structure
16.1 NIST Compliance

16.2 OWASP Web Application Security Testing Checklist

16.3 Summary

16.4 Review Questions

16.5 Further Reading

16.1. NIST Compliance

The National Institute of Standards & Technology (NIST), a non-regulatory agency of the
U.S. Dept. of Commerce, is a measurement standards laboratory that develops the standards
federal agencies must follow in order to comply with the Federal Information Security
Management Act of 2002 (FISMA). By defining an information-security framework for U.S. federal
agencies (or contractors working for them), this Act (which is a federal law) aims to improve
computer and network security within the federal government. NIST’s standards and guidelines
(800-series publications) further define this framework.

FISMA originally required agencies to certify the security of their online systems with annual
inspections. However, a recent major update to FISMA requires agencies to continuously monitor
their networks in real-time for cyber vulnerabilities. The FISMA update mandates “automated
security tools to continuously diagnose and improve security.”
206

NIST’s 800-series publications (two of which are described below) contain detailed security
guidance and recommendations for federal agencies.

The general steps involved for checklist users are shown in Figure 16.1. For checklist
users, the steps are simple and straightforward:

In step one, users gather their local requirements (e.g., IT products, the operating
environment and associated security needs) and then acquire or purchase the IT product that
best suits their needs.

In step two, users browse the checklist repository to retrieve checklists that match the
user’s operational environment and security requirements. If a product is intended to be secure
out-of the-box (e.g., it was secured by the vendor using a security configuration checklist), it is
still important to check the repository for updates to that checklist.

Step three involves tailoring and documenting the checklist as necessary to take into
account local policies and functional requirements, testing the checklist, and providing any
feedback to NIST and the checklist developers.

Lastly, step four involves preparation for deploying the checklist, such as making
configuration or data backups, and then applying the checklist in production.

Figure 16.1 : Checklist for End-Users

 207

For developers, the process is composed of two stages. The first stage involves only
developer actions, whereas the second stage involves interactions between NIST, the developer,
and public reviewers. The first stage contains four steps,

 In step one, the developer becomes familiar with the procedures and requirements of the
checklist program and completes an agreement to participate in the program.

 In step two, the developer creates, tests, and refines the checklist.

 In step three, the developer documents the checklist according to the guidelines of the
program.

 In step four, the developer prepares a checklist submission package and submits it to
NIST

In stage two, NIST then performs the remaining four steps, with interaction from the
developer and public reviewers:

 In step five, NIST screens the checklist according to program requirements and addresses
any issues with the developer.

 The next step is a public review of the checklist, which typically lasts 30 to 60 days.
Comments submitted during the review are addressed as applicable by the developer
and NIST.

 For step seven, NIST posts the checklist on the repository and announces its presence.

 Lastly, step eight involves periodic updates to the checklist and issues of checklist archival.

A checklist – also known as a lockdown, hardening guide, benchmark, security guide or

security technical implementation guide (STIG) – can be used to ensure a product is configured
correctly, as well as identifying any unauthorized changes that could lead to security holes or
problems with implementation.

“Although the solutions to IT security are complex, one simple yet effective tool is the
security configuration checklist,” NIST writes. “The use of well-written, standardized checklists
can markedly reduce the vulnerability exposure of IT products.”
208

16.2. OWASP Web Application Security Testing Checklist

Information Gathering :

 Manually explore the site

 Spider/crawl for missed or hidden content

 Check for files that expose content, such as robots.txt, sitemap.xml,.DS_StoreCheck

 the caches of major search engines for publicly accessible sites

 Check for differences in content based on User Agent (eg. Mobilesites, access as a
Search engine Crawler)

 Perform Web Application Fingerprinting Identify technologies used

 Identify user roles

 Identify application entry points

 Identify client-side code

 Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)

 Identify co-hosted and related applications

 Identify all hostnames and ports

 Identify third-party hosted content

Configuration Management:

 Check for commonly used application and administrative URLs

 Check for old, backup and unreferenced files

 Check HTTP methods supported and Cross Site Tracing (XST) Test

 File extensions handling

 Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS)

 Test for policies (e.g. Flash, Silverlight, robots)

 Test for non-production data in live environment, and vice-versa

 Check for sensitive data in client-side code (e.g. API keys, credentials)
 209

Secure Transmission :

 Check SSL Version, Algorithms, Key length

 Check for Digital Certificate Validity (Duration, Signature and CN)

 Check credentials only delivered over HTTPS

 Check that the login form is delivered over HTTPS

 Check session tokens only delivered over HTTPS

 Check if HTTP Strict Transport Security (HSTS) in use

Authentication :

 Test for user enumeration

 Test for authentication bypass

 Test for brute force protection

 Test password quality rules

 Test remember me functionality

 Test for auto complete on password forms/input

 Test password reset and/or recovery

 Test password change process

 Test CAPTCHA

 Test multi factor authentication

 Test for logout functionality presence

 Test for cache management on HTTP (eg Pragma, Expires, Max-age)

 Test for default logins

 Test for user-accessible authentication history

 Test for out-of channel notification of account lockouts and successful password changes
210

 Test for consistent authentication across applications with shared authentication schema
/ SSO

Session Management :

 Establish how session management is handled in the application (eg, tokens in cookies,
token in URL)

 Check session tokens for cookie flags( http Only and secure)

 Check session cookie scope (path and domain)

 Check session cookie duration (expires and max-age)

 Check session termination after a maximum lifetime

 Check session termination after relative timeout

 Check session termination after logout

 Test to see if users can have multiple simultaneous sessions

 Test session cookies for randomness

 Confirm that new session tokens are issued on login, role change and logout

 Test for consistent session management across applications with shared session
management

 Test for session puzzling

 Test for CSRF and click jacking

Authorization:

 Test for path traversal

 Test for by passing authorization schema

 Test for vertical Access control problems (a.k.a. Privilege Escalation)

 Test for horizontal Access control problems(between two users at the same privilege
level)

 Test for missing authorization

 211

16.3. Summary

 The National Institute of Standards & Technology (NIST), a non-regulatory agency of the
U.S. Dept. of Commerce, is a measurement standards laboratory that develops the
standards federal agencies must follow in order to comply with the Federal Information
Security Management Act of 2002 (FISMA).

 A checklist – also known as a lockdown, hardening guide, benchmark, security guide or

security technical implementation guide (STIG) – can be used to ensure a product is
configured correctly, as well as identifying any unauthorized changes that could lead to
security holes or problems with implementation.

16.4. Review Questions

1. Explain the NIST check list for end user.

2. List the OWASP check list for web application session management.

16.5. Further Reading

 https://www.ftptoday.com/blog/complete-nist-800-171-checklist

 https://csrc.nist.gov/csrc/media/publications/sp/800-70/rev-4/draft/documents/sp800-
70r4-draft.pdf

 https://owasp.org/www-project-web-security-testing-guide/assets/archive/
OWASP_Web_Application_Penetration_Checklist_v1_1.pdf

 https://www.owasp.org/images/1/19/OTGv4.pdf
212

Model Question Paper

M.Sc. Cyber Forensics and Information Security

Second Year – Fourth Semester

Core Paper – XIII

Application Security

Time: 3 Hrs Max Marks: 80

PART - A - (10 x 2= 20 Marks)

Answer any TEN Questions each in 50 words each

1. Define DAC.

2. State the idea behind DREAD.

3. List the principles of TCB.

4. What is DOM XSS?

5. Differentiate Threat and Vulnerability.

6. List the elements of Host Security.

7. What is Luring Attack?

8. Expand STRIDE.

9. Define Trojan with its purpose.

10. What is Canonicalization?

11. What do you mean by Rooting Malware?

12. Define Bluesnarfing.

 213

PART - B (5 x 6= 30 Marks)
Answer any FIVE each in 250 words each

13. Categorize the threats by application vulnerability.

14. Write short notes on web application architecture.

15. Brief the principles of Security.

16. Elaborate in detail about Bluetooth security threats.

17. What are the key solutions for STRIDE threats?

18. Describe in detail about anatomy of an attack.

PART - C (3 x 10 = 30 Marks)
Answer any THREE each in 500 words each

19. Explain the security principles that need to be followed in an organization.

20. Elaborate the most top seen vulnerabilities of OWASP.

21. Illustrate the penetration testing process in the mobile devices.

22. Explain the NIST check list for end user.