Learning Environment For Security of Modern Web Applications...Facelet s, AngularJS and GWT . U...

Rok akademicki 2014/2015

Politechnika Warszawska

Wydział Elektroniki i Technik Informacyjnych

Instytut Informatyki

PRACA DYPLOMOWA MAGISTERSKA

Robert Rozmus

Learning Environment For Security of Modern Web

Applications

Opiekun pracy

dr inż. Jacek Wytrębowicz

Ocena: .....................................................

................................................................

Podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

Kierunek: Informatyka

Specjalność: Inżynieria Systemów Informatycznych

Data urodzenia: 25 maja 1990 r.

Data rozpoczęcia studiów: 29 września 2014 r.

Życiorys

Urodziłem się 25 maja 1990 r. w Warszawie. W 2009 r. rozpocząłem studia na Politechnice

Warszawskiej, wydziale Elektroniki i Technik Informacyjnych, na kierunku Inżynieria

Biomedyczna, które ukończyłem w lutym 2013 r. z tytułem inżyniera. W 2011 r. rozpocząłem

na tym samym wydziale studia równoległe na kierunku Informatyka, które ukończyłem w

czerwcu 2014 r. z tytułem inżyniera. W październiku 2014 r. rozpocząłem studia magisterskie

na kierunku Informatyka również na tym samym wydziale. Drugi semestr tych studiów

spędziłem na uczelni University of Southampton w Wielkiej Brytanii w ramach programu

Erasmus+.

.......................................................

Podpis studenta

EGZAMIN DYPLOMOWY

Złożył egzamin dyplomowy w dniu .................................................................................. 2015 r

z wynikiem ..................................................................................................................................

Ogólny wynik studiów: ...............................................................................................................

Dodatkowe wnioski i uwagi Komisji: .........................................................................................

......................................................................................................................................................

......................................................................................................................................................

SUMMARY

This thesis presents security problems of all layers of the TCP/IP model with an emphasis on

the application layer. The thesis describes the vulnerabilities appearing in the modern web

applications. As part of the work an interactive environment (called WebHiob) was created to

teach the web application security in Java. The environment consists of ten lessons presenting

the use of vulnerability, security description of the problem and how to solve it. The lessons

demonstrate the vulnerabilities, which are not shown in any of the three existing environments

(WebGoat, DVWA, HacmeBank). The WebHiob was made out in Java using the Spring MVC

framework and JPA technology. The lessons have been prepared in three view technologies –

Facelets, AngularJS and GWT. Usability has been taken into account whilst designing the

WebHiob, which will make it extremely easy to insert new lessons when required.

Keywords: web application security, interactive learning environment

Środowisko do nauki bezpieczeństwa nowoczesnych aplikacji internetowych

Niniejsza praca przedstawia problemy bezpieczeństwa wszystkich warstw modelu TCP/IP ze

szczególnym naciskiem na warstwę aplikacji. Opisuje podatności pojawiające się w

nowoczesnych aplikacji internetowych. W ramach pracy powstało interaktywne środowisko

(nazwane WebHiob) do nauczania bezpieczeństwa aplikacji internetowych napisanych w

języku Java. Środowisko zawiera dziesięć lekcji przedstawiających wykorzystanie

podatności, opis problemu bezpieczeństwa oraz sposób jego naprawy. Lekcje prezentują

podatności, których nie przedstawiono w żadnym z trzech istniejących środowisk (WebGoat,

DVWA, HacmeBank). WebHiob został wykonany w technologii Java wykorzystując szkielet

Spring MVC oraz specyfikacje JPA. Lekcje przygotowano w trzech technologiach

widokowych – Facelets, AngularJS oraz GWT. Środowisko zaprojektowano w taki sposób,

aby dodawanie kolejnych lekcji w dowolnej technologii widokowej było jak najprostsze.

Słowa kluczowe: bezpieczeństwo aplikacji internetowych, interaktywne środowisko do

nauczania

Składam serdeczne podziękowania Panu

dr. inż. Jackowi Wytrębowiczowi za

poświęcony czas i życzliwą pomoc przy

pisaniu niniejszej pracy

Contents

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Aim and scope of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Organisation of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Vulnerabilities of all layers of the TCP/IP model and of the user layer . . . . . 42.1. Data transport layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2. Data-Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1. The most popular vulnerabilities . . . . . . . . . . . . . . . . . . . . . . 132.2.2. Other vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3. User layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3. Web application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1. Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.1. EIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.2. Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.3. Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.1.4. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.1.5. Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.1.6. Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2. Authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.1. Spring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.2. Stateful and stateless authentication . . . . . . . . . . . . . . . . . . . . 48

4. Desired features of learning environment for security of web application . . . 504.1. Features important for a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2. Features important for a developer . . . . . . . . . . . . . . . . . . . . . . . . . 524.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5. Analysis of existing environments for teaching of web security . . . . . . . . . 545.1. WebGoat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2. DVWA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3. HacmeBank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6. Proposed lessons for the authorial environment . . . . . . . . . . . . . . . . . . 616.1. JSONP XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2. Spring MVC ModelView injection . . . . . . . . . . . . . . . . . . . . . . . . . . 656.3. Spring MVC data submission to non-editable fields . . . . . . . . . . . . . . . 686.4. JPQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.5. EL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.6. Session management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.6.1. Session Timeout with periodic Ajax request . . . . . . . . . . . . . . . . 74

Contents ii

6.6.2. Automatic redirection to the login page after the session expires . . . . 776.7. Authentication and authorization in Rich Internet Application . . . . . . . . . 79

6.7.1. Rich Internet Application security with cookie-based authentication . 796.7.2. Rich Internet Application security with token-based authentication . . 82

7. Project of the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.1. Functional and non-functional requirements . . . . . . . . . . . . . . . . . . . 867.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.2.1. Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.2.2. Resolving the view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.2.3. Used tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.3. Adding a new lesson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.4. Environment testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.5. User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

A. User manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.2. Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B. Contents of included CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Acronyms

ACAO Access-Control-Allow-Origin.

AJAX Asynchronous JavaScript and XML.

AOP Aspect-Oriented Programming.

API Application Programming Interface.

ARP Address Resolution Protocol.

ASCII American Standard Code for Information Interchange.

CORS Cross Origin Resource Sharing.

CRUD Create, Read, Update and Delete.

CSIS Canadian Security Intelligence Service.

CSRF Cross-Site Request Forgery.

CSS Cascading Style Sheets.

CTO Chief Technology Officer.

CVE Common Vulnerabilities and Exposures.

DAO Data Access Object.

DHCP Dynamic Host Configuration Protocol.

DNS Domain Name System.

DOM Document Object Model.

DoS Denial-of-Service.

DVWA Damn Vulnerable Web App.

ECS Element Construction Set.

EIS Enterprise Information System.

EL Expression Language.

ERP Enterprise resource planning.

FTP File Transfer Protocol.

GUI Graphical User Interface.

GWT Google Web Toolkit.

HSQLDB Hyper SQL Database.

HTML HyperText Markup Language.

Acronyms iv

HTTP Hypertext Transfer Protocol.

ICMP Internet Control Message Protocol.

IDE Integrated Development Environment.

IDS Intrusion Detection System.

IMDB In-Memory Database.

IoC Inversion of Control.

IP Internet Protocol.

IPS Intrusion Prevention Systems.

JAAS Java Authentication and Authorization Service.

JAX-RS Java API for RESTful Web Services.

JAX-WS Java Api for XML Web Services.

JCP Java Community Process.

JDBC Java Database Connectivity.

JEE Java Enterprise Edition.

JMS Java Message Service.

JMX Java Management Extensions.

JPA Java Persistence API.

JPQL Java Persistence Query Language.

JS JavaScript.

JSF JavaServer Faces.

JSON JavaScript Object Notation.

JSONP JSON with padding.

JSP JavaServer Pages.

JSR Java Specification Request.

JUG Java User Group.

JWS JSON Web Signature.

JWT JSON Web Token.

LDAP Lightweight Directory Access Protocol.

MAC Media Access Control.

MBean Managed Bean.

MD5 Message-Digest algorithm 5.

MITM Man-in-the-middle.

MTU Maximum Transmission Unit.

MVC model-view-controller.

NoSQL Not Only SQL.

Acronyms v

ORM Object-relational mapping.

OSI Open Systems Interconnection.

OVAL Open Vulnerability and Assessment Language.

OWASP Open Web Application Security Project.

PDF Portable Document Format.

POJO Plain Old Java Object.

RAD Rapid Application Development.

RAM Random Access Memory.

REST Representational state transfer.

RIA Rich Internet Application.

RPC Remote procedure call.

RSS Rich Site Summary.

SAM Security Account Manager.

SMTP Simple Mail Transfer Protocol.

SOA Service Oriented Architecture.

SOAP Simple Object Access Protocol.

SQL Structured Query Language.

SSL Secure Sockets Layer.

SVN Subversion.

TCP Transmission Control Protocol.

TDD Test-driven development.

TLD Top-level domain.

TTL Time to live.

TXT Text File.

UDP User Datagram Protocol.

UI User interface.

URL Uniform Resource Locator.

USB Universal Serial Bus.

W3C World Wide Web Consortium.

WS-Security Web Services Security.

WWW World Wide Web.

XML Extensible Markup Language.

XSS Cross-Site Scripting.

ZAP Zed Attack Proxy.

1. Introduction

Safety is one of the basic human needs. This word connotes primarily with

the physical security. Nowadays – in this respect, state administrations often

provide sense of security its citizens. From year to year more and more activities

takes place on the Internet, which causes, that the criminality progresses in that

way. According to the report of Canadian Security Intelligence Service (CSIS), cyber

crime costs the global economy up to $500 billion a year. If we compare this amount

with $600 billion associated with the drug trafficking, we will see how significant

it is [13]. The question is – if it could be avoided? According to the Open Web

Application Security Project (OWASP) Top Ten document [73], the most popular

attacks in 2013 were different kinds of injections. Many of them could be relatively

easy avoided, therefore as long as people do not start properly studying the web

security, this amount could even increase in the future.

1.1. Motivation

Security of web applications is very important, but it is frequently neglected

by the web developers [133]. There are many books, web pages, information

about web security, examples of attacks and solutions how to prevent them. The

learning process brings greater effects when the information are presented via

computer-based multimedia systems than the traditional classroom lectures [65].

Does it mean that only from books nobody can get extensive knowledge, that books

should be replaced by multimedia systems? Of course not. But if we want to get the

best solution, we should mix these both techniques of studying e.g. start from the

books and then test our new knowledge on something more interactive. Obviously

this proposition is not anything unique, therefore there are several applications

developed to teach about the web vulnerabilities. They include: WebGoat, Damn

Vulnerable Web App (DVWA) and HacmBank. Each one was written in different

programming language (respectively: Java, PHP and C#). Only the former is still

developed, the others are not supported since many years. The basic drawback

of all of these environments is fact, that they do not teach which code is directly

responsible for the vulnerability and how to improve the code to make the attack

impossible. The exceptions include some of the WebGoat ’s lessons, however most

1.2. Aim and scope of the thesis 2

of them do not explain these important information. Therefore the user interface of

these environments should be changed, to provide clearly separation between the

lesson, security problem and solution. This thesis is focused on Java technologies,

thus the only potentially suitable environment to change (instead of developing

own) is WebGoat.

The WebGoat environment is being developed since 2002, which results in using

rather historical technologies. The usage of JavaServer Pages (JSP) and scriptlets

makes, that the model layer is tightly coupled with the presentation layer, which

not only forecloses the automated tests, but also causes the source code repetition,

lack of possibilities of using the objective techniques or difficulties with debugging.

This results in the lack of interest among developers who have got knowledge

and some experience in web application security, but they are not prepared to

go through historical technologies and not very friendly architecture.

New possibilities of web attacks have become available with the appearance of

new technologies (Java Persistence API (JPA), Spring Web MVC, Facelets, Google

Web Toolkit (GWT), AngularJS). There is a possibility to add the new lessons

and even technologies to the existing version of WebGoat, however a mix of ten

years old and present technologies would be more effort than good. Therefore a

new environment with modern technologies could not only teach about modern

web security vulnerabilities, but also about modern architecture, clean code, and

automated tests, which should bring more volunteers for the further development.

For all of these reasons, I have decided to develop a custom version of the learning

environment for security of modern web applications called WebHiob.

1.2. Aim and scope of the thesis

The main aim of this thesis is to develop a learning environment for security of

modern web applications. The scope includes:

1. Reviewing the vulnerabilities of all layers of the Transmission Control Proto-

col/Internet Protocol (TCP/IP) model and of the user layer.

2. Description of the multi-layers web application architecture and vulnerabilities

involved with each layer.

3. Analysis of desired features of the environment for teaching web application

security.

4. Overview of the existing applications to teach web security.

5. Proposing the lessons for the authorial environment.

1.3. Organisation of the thesis 3

6. Project of the environment to teach web security (WebHiob. developed in modern

technologies (Spring MVC, JPA, Facelets, AngularJS, GWT).

1.3. Organisation of the thesis

Each chapter requires knowledge from previous, thus it is recommended to read

this thesis in proposed order. In chapter 2 there are described all layers of TCP/IP

model, the user layer, and connected with them vulnerabilities. On the grounds of

mainly topic of this thesis, the most emphasis has been placed on the application

layer. Chapter 3 introduces the (mainly Java) web technologies divided into layers

and connected with them vulnerabilities. Chapter 4 contains the desired features

of the environment to teach about web security. In chapter 5 is made the analysis

of the existing applications to teach web security in the context of the desired

features described in the previous chapter. Chapter 6 describes the proposed

lessons for the authorial environment with descriptions of the security problems

and solutions. Chapter 7 contains the project of the WebHiob environment and the

last one summarizes the whole thesis.

2. Vulnerabilities of all layers of the TCP/IPmodel and of the user layer

The theme title of this thesis concerns only a small fragment of the wide web

security issues. The aim of this chapter is to introduce the whole spectrum of web

security vulnerabilities to better understand the context of the realized subject.

This general introduction is convenient to do based on the TCP/IP model.

TCP/IP model is the computer networking hierarchical model defining how the

network devices and their applications must follow protocols (that have set of rules)

in order to communicate with each other. The model has became the foundation of

the structure of the Internet [124,131,132]. There are two versions of the TCP/IP

model: with four and five layers [131]. To provide more detailed description about

vulnerabilities, this chapter is based on the five layers version, which includes the

following layers (in the brackets there are examples of the protocols used by the

specified layer) [124,132]:

1. Physical (RS-232, IEEE 802.11, DSL, USB, Bluetooth).

2. Data-Link (ARP, MAC).

3. Network (IP, ICMP).

4. Transport (TCP, UDP).

5. Application (HTTP, FTP, DNS, DHCP).

Each layer plays different role and makes use of the different protocols. The

process of sending and receiving data contains three step [124,131,132]:

1. Data is prepared to send via the application layer and passed down until the

bottom physical layer.

2. Data is transmitted over the physical medium from the sender to receiver sys-

tem.

3. The receiver system backs up the stack with received data to the application

layer.

The TCP/IP model has been designed in such a way, that lower layers are

independent on the uppers. Briefly, the model ensures the abstraction of each

2.1. Data transport layers 5

layer, beyond what is needed to exchange data between the layers. This allows to

use various protocols in the same layer [128,132].

There are many vulnerabilities connected with each layer. Because system is

only as secure as its weakest part, should not be forgotten to understand the risk

connected with each layer and to provide a proper protect from it [128]. This thesis

is mainly focused on the vulnerabilities of the application layer, therefore these

connected with lower layers (data transport layers) are only briefly described. Al-

though the TCP/IP model has got fife layers, this chapter introduces the additional

layer known as the user (or people) layer. To make the Data transport layers section

more concise, vulnerabilities of each layer are summarized in Tables (2.1-2.4) with

the name and effect columns, but description and prevention are presented below

these Tables.

2.1. Data transport layers

Data transport layers contain the four lower layers of the TCP/IP model: phys-

ical, data-link, network and transport. They are responsible for transporting the

data over the network and caring about the data formatting, decoding/encoding

and transmission [60,124,131,132].

2.1.1. Physical

The physical layer is on the bottom of the TCP/IP model. Its role is to transmit

bit streams using electric signals, lights or radio transmissions. Devices typical for

this layer include: Ethernet cable, Bluetooth transceiver and repeater [124,132].

According to Michael Gregg1: „without physical security, you have no security

at all”. Basic examples of the vulnerabilities affecting the physical layer include:

loss of power, physical theft of hardware or even vagaries of physics. The ways

of protection include: video/audio surveillance, biometric authentication systems,

and data storage cryptography [70, 128, 138]. More sophisticated examples are

summarized in Table 2.1.

Table 2.1: Examples of the physical layer vulnerabilities [128,138]

Name Effect of abuse

Podslurping Copy of sensitive information is got in some wrong hands

Password insertion Login as any user with reset existed password

Password extraction Login as any user without changing existed password

1 Michael Gregg – security expert for more than 15 years, founder and Chief Technology Officer(CTO) of Superior Solutions Inc. (a risk assessment and security consulting firm).


Podslurping

Attack description

The attack relies on using iPod or other mass storage device to recursively

search all subdirectories of chosen computer to steal sensitive information (files

such as Portable Document Format (PDF), HTML, Text File (TXT) etc.) [138].

Prevention

To prevent from the Podslurping attack it is recommended to forbid to plug

Universal Serial Bus (USB) devices to the computer (on which there is access to

sensitive data) or/and disable possibility to mount discs in operating system (in

Linux system it is relatively simple task) [138].

Password insertion

Attack description

The attack relies on using programs such as NT Password – bootable application

allowing the attacker to change any user’s password on operating system after a

few steps can (reset a password and then set a new one) [128,138].

Prevention

To prevent from the Password insertion attack it is recommended to use of

encryption of the hard drive, where the operating system is installed [128,138].

Password extraction

Attack description

The attack relies on using a special bootable version of Linux (Knoppix) in

order to extract Security Account Manager (SAM) – database of Windows operating

system containing encrypted users’ passwords. Then the attacker moves extracted

files to a Windows system and use a program such as SAM-Inside, which allows

to extract passwords from the SAM. Finally, it is enough to load the extracted

passwords into a password recovery program like LCP [128,138].

Prevention

Prevention from the Password extraction attack is the same as from Podslurping

[128,138].

2.1.2. Data-Link

Data link layer there is over physical layer. During the movement down through

TCP/IP model, this layer is concerned with data packets encapsulation from net-

work layer to get frames compatible with standards (which are passed to physi-

cal layer). Data-Link layer adjusts work’s parameters of physical layer to reduce

transmission errors [128]. Devices typical for this layer include: switch, hub,


bridge [70, 128]. The most known vulnerabilities connected with this layer are


Table 2.2: Examples of the data link layer vulnerabilities [70,128]


MAC flooding Eavesdrop network communication

ARP spoofing Eavesdrop network communication

MAC flooding

Attack description

The attack is about flooding a switch with a lot of frames with faked source

address. After some time, table of Media Access Control (MAC) address is overflow,

which effects working switch like an hub (switch cannot properly send coming

frames and start to send them in a broadcast way) [128].

Prevention

To prevent from MAC flooding it is recommended to use modern switches, which

have got ability to reduce number of MAC address assigned to one port [128].

ARP spoofing

Attack description

This attack make use of Address Resolution Protocol (ARP) protocol allowing

to get MAC address based on Internet Protocol (IP) address. Example of attack’s

scenario includes the following steps [61,128]:

1. Alice sends ARP query to get MAC address of 10.0.0.2 IP (Bob’s device).

2. Attacker replies on this query and sends his MAC address.

3. Bob sends ARP query to get MAC address of 10.0.0.1 IP (Alice’s device).

4. Attacker replies on this query and sends his MAC address.

5. Alice and Bob update ARP table and bind the looking for IP with attacker’s MAC

address.

6. Attacker updates his ARP table with proper binding of MAC with IP addresses

of Alice and Bob’s devices.

7. All packages from Alice IP go through attacker, who sends them to Bob to not

arouse any suspicion (and vice-versa).

The attack is example of man in the middle attack. If the victim already has

got a proper MAC address of destination IP, the attacker can switch it by sending

a properly forged ARP reply. The reply will be accepted and victim’s ARP table

updated [61,128]. The results of this attacks is shown in Figure 2.1.


Figure 2.1: Results of ARP spoofing attack (image modified based on [61])

Prevention

To prevent from ARP spoofing it is recommended to use: static ARP entries,

ARP spoofing detection software (relying on certification or cross-checking of ARP

responses) or Operating System security (e.g. AnitARP providing Windows-based

spoofing prevention at the kernel level) [128].

2.1.3. Network

Network layer there is over data link layer. It is responsible for routing, which

aim is to choice which way a packet should be send to reach a final destination

over multiple possible data links and paths over enormous amount of intermediate

nodes. IP addresses (which identify nodes) and routing tables (which contain

next-hop address to the further pass packet) are used to achieve the goal. IP

and Internet Control Message Protocol (ICMP) are the most often used protocols.

IP is commonly known protocol providing routing and generally establishing the

Internet. ICMP is used as troubleshooting tool of the network. It allows to find

logical errors and their diagnosis. The most common example of ICMP tool is

ping, which provides echo request and response process. Router is a typical device

for this layer [70, 128]. Examples of vulnerabilities connected with this layer are



Table 2.3: Examples of the network layer vulnerabilities [70,128]


Evasion attack Bypass the Intrusion Detection System (IDS)

ICMP Echo Attacks/Smurf Attack Largely usage of the victim’s bandwidth

Evasion attack

Attack description

This attack takes advantage of the fact, that network packets have got limited

size (1500 B for Ethernet) defined in Maximum Transmission Unit (MTU) field.

Packets bigger than MTU size are fragmented and sent in parts. The receiving

system of fragmented packets has got a timeout, after which will not receive the

next part. Assume that system IDS has got this timeout set on 15 s, and target

computer set on 30 s. The attacker sends first packet not arousing any suspicion,

which goes through IDS and reaches to the target computer. The packet starts

both timeouts (15 s and 30 s). After 1 s, the attacker sends a malicious fragment,

which will be detected and stopped by IDS refreshing its timeout on 15 s. After

16 s, the attacker sends the next malicious fragment, which will not be caught by

IDS (its timeout has passed) and will reach to the target computer. In this way, the

attacker bypasses the IDS [128].

Prevention

To prevent from evasion attack the timeout parameter must be set to the same

value on the target host as on IDS [128].

ICMP Echo Attack/Smurf Attack

Attack description

This attack takes advantage of the ICMP Echo Request message containing data

packet for the host and request to send it back as the ICMP Echo Reply message.

The aim of this attack is to flood the target with ping traffic in order to make use

of all available bandwidth. It could be done by sending a ICMP Echo Request

message with forged source address (set to the victim’s address) to the broadcast

server address. It causes that the server sends packets to all clients, who reply

with the ICMP Echo Reply message to the victim’s address. In this way, the victim’s

computer is flooded by the network traffic, which is shown in Figure 2.2 [128].


Figure 2.2: ICMP Echo Attack

Prevention

To prevent from this kind of attack it is recommended to change configuration

of hosts and routers to not respond to ICMP requests and make that routers will

not forward packets directed to broadcast addresses [128].

2.1.4. Transport

This is first full logical layer of already described, which means that there is

no special device to use it protocols. It is responsible for communication between

appropriate application processes on the host computers. Port number is used to

differentiate running processes on the host [128]. The most known vulnerabilities

connected with this layer are summarized in Table 2.4.

Table 2.4: Examples of the transport layer vulnerabilities [14,15,77,100,136]


Passive fingerprinting Recognize operating system to prepare more sophisti-cated attack connected with specific system’s version

Active fingerprinting as above

SYN flood Fully fledged users cannot connect to system, whose re-sources are used up

Passive fingerprinting

Attack description

This attack relies on capturing and examination of the packet sent from the

remote system. Based on some fields of the frame (such as URG, ACK, RST, SYN,

FIN), there is a possibility to determine the operating system of the remote host,


because every operating system implements its own idiosyncrasies. To perform

this attack can be useful programs such as Siphon, Ettercap and p0f [14,136].

Prevention

The passive fingerprinting attack cannot be detected by an IDS, therefore there is

no simple way to prevention. One option is to modify some TCP fields of the packet,

but certain idiosyncrasies behaviours are not customizable (to change it, will be

necessary to recompile operating system’s kernel) e.g. the option ordering in a

packet. Besides, manual modifications involve a high risk to open other possibility

of attacks. However, there is an application (IP Personality), which help to fool some

network scanners to make them think that the host’s system is e.g. printer, but it

stops only the least engaged attackers [77,136].

Active fingerprinting

Attack description

This attack relies on sending idiosyncratic formatted TCP packets. It results in

different response depends on operating system of the remote host. The analysis

of responses results in recognizing the operating system. Therefore this attack is

very similar to the passive version, but it gives more effectiveness [14,136].

Prevention

The active fingerprinting attack be detected by IDS, which makes it less prob-

lematic than passive version. Programs such as Snort has got base of known active

fingerprinting scans and use them to compare with incoming packets [136].

SYN flood

Attack description

This attack is possible because of 3-way handshake establishing a TCP connec-

tion, which works in three steps (as shown in Figure 2.3) [15]:

1. Client sends a TCP packet with SYN flag ON and generated initial sequence

number to the server.

2. Server replies by sending a TCP package with SYN and ACK flags ON, it gener-

ated initial sequence number and initial sequence number of client incremented

by one to the client.

3. Client checks if it initial sequence number is incremented by one and replies

with a TCP packet with ACK flag ON and initial sequence number of server

incremented by one.

2.2. Application layer 12

Figure 2.3: Data transmission through OSI layers (modified based on [100])

When attacker sends a lot of SYN packets and never sends ACK packets, ses-

sions start by server leave in limbo. In results, the system of being attacked stop

accepting new connection [15].

Prevention

To prevent from SYN flood attacks it is recommended to filter incoming packets,

reduce SYN-RECEIVED timeout, and recycling the oldest half-open TCP connec-

tions. [100].

2.2. Application layer

Application layer is the top-end of TCP/IP stack. This layer is responsible

for establishing and coordinating a session [124]. Additionally it provides the

network access to applications and treat lower layers as a black box, which allows

to a stable network connection [128]. The layer includes the protocols which

a lot of applications use to provide end-user services (e.g. Hypertext Transfer

Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP))

and administrative protocols (e.g. Dynamic Host Configuration Protocol (DHCP),

Domain Name System (DNS)) [101].

Application layer is currently the most vulnerable layer. This is happening due

to the belief that that firewalls, IDS and Intrusion Prevention Systems (IPS) are

enough to protect from web attacks. Many companies rely only on them, thus is

very important to sensitize people on these problems. Firewalls secure the internal


network perimeter, and the IDS/IPS do not analyse contents of packets. They

are needed, but to secure lower layers than the application [26, 117]. Why using

firewall is not enough to secure application layer, is shown in Figure 2.4.

Figure 2.4: Why using firewall is not enough to secure application layer [74]

2.2.1. The most popular vulnerabilities

The most popular vulnerabilities are introduced in the „OWASP Top Ten 2013”

[73]. This document apart from list of the ten most critical web application security

risks, contains also: a description, example vulnerabilities, attacks, and a guidance

on how to avoid the security risks [75]. The reason of choosing the OWASP when

it comes to trustworthy research of the most popular vulnerabilities is fact, that

this organisation is worldwide, focused on improving security of web applications

and includes over 42,000 participants with hundreds of security experts from

all around the world [72]. The most critical web application security risks with

exploitability, prevalence, detectability and technical impact are summarized in

Table 2.5.


Table 2.5: The most critical web application security risks [73]

Name Exploitability Prevalence Detectability Impact

Injection easy common average severe

Broken Authentication andSession Management

average widespread average severe

Cross-Site Scripting (XSS) average widespread easy moderate

Insecure Direct Object Ref-erences

easy common easy moderate

Security Misconfiguration easy common easy moderate

Sensitive Data Exposure difficult uncommon average severe

Missing Function Level Ac-cess Control

easy common average moderate

Cross-Site Request Forgery(CSRF)

average common easy moderate

Using Components withKnown Vulnerabilities

average widespread difficult moderate

Unvalidated Redirects andForwards

average uncommon easy moderate

Injection

Attack description

Injection attack relies on using a bug in application causing processing invalid

data. Attacker make use of an executable code/script to introduce it into a com-

puter program to change the course of execution. [122]. There are many varieties

of injection attacks. Depending on a place, where is it possible to insert some

data there are: Structured Query Language (SQL), JavaScript Object Notation

(JSON), Object-relational mapping (ORM), Lightweight Directory Access Protocol

(LDAP), Not Only SQL (NoSQL), etc. injection. All of them are possible because,

that data input from user come out of the data context and are interpreted as a

command [135].

Example of attack

Assume that, there is a login page with username and password fields and the

application contains the code responsible for login, that is shown in Listing 2.1.

1 boolean loginUser(String username, String password) {String query ="SELECT id FROM users WHERE username=’" + username + "’ AND "

+ "password =’" + password + "’";Statement st = connection.createStatement();

5 ResultSet res = st.executeQuery(query);return res.next();

}

Listing 2.1: Example of code vulnerable to SQL injection


The code from Listing 2.1 allows to use the SQL injection attack. If the attacker

types in the username field: ’ OR 1=1 - -, it will perform the following query allowing

to login without password:

SELECT id FROM users WHERE username=’’ OR 1=1 −− AND password=’’’’

Two hyphens (- -) indicate the comment in most databases (such as "\\" in C, C++,

Java), which means that everything further is ignored.

Prevention

To protect from injection there is one simple rule – keep untrusted data separate

from commands and queries. Depends on kind of injection, this means that

different chars (sequences of chars) should be allowed or forbidden. To provide

this, the following instruction should be helpful [73]:

1. Use a safe Application Programming Interface (API) which makes all of necessary

work, but be careful and better test them on your own.

2. If it is impossible use safe API, it is recommended to escape special characters

(such as comments chars).

3. Remember to use the white list2 validation instead of the black list3 (almost

always it is better not allow the proper user to access, than to permit the

attacker).

Effect of abuse

The effects include [73]:

• data access without a proper authorization e.g. access to sensitive data through

bypassing the login page;

• permanent modification of database e.g. delete all card indexes of criminals;

• Denial-of-Service (DoS)4 attacks e.g. consumption of every database memory

resource, so it cannot support the valid users.

• insertion of a web worm (which changes user password).

Broken Authentication and Session Management

Attack description

This security risk concerns authentication and session management, which

are often not implemented correctly, especially when developers implement these

mechanisms on their own, instead of use some well-tested framework/library [73].

This topic is involved with very wide issue which are session management and

2 White list – list of chars, commands, user, etc., considered to be valid.3 Black list – list of chars, commands, user, etc., considered to be not valid.4 Denial-of-service (DoS) attack – making a machine or network resource unavailable to its

intended users [128].


authentication process. HTTP is stateless protocol, which means that developers

need to provide a proper session management [74]. There are two well-known kind

of attacks connected with session [87,88]:

• session fixation – steal a user’s session by enforcing the user to login into the

server using prepared by attacker session ID;

• session hijacking – steal a user’s session by stealing or predicting a valid user’s

session ID.

Example of attack

There are many ways to perform session fixation (e.g. using Uniform Resource

Locator (URL) rewriting, XSS, attacking user’s DNS server etc. [87]) and session

hijacking (predictable session token, session sniffing, XSS, Man-in-the-middle

(MITM) etc. [88]).

The progress of session fixation is shown in Figure 2.5. It contains the following

steps [87]:

1. The Attacker logs in to the server such as typical user.

2. The server sends him the session ID (1234).

3. The Attacker sends to the user a properly prepared hyperlink containing at-

tacker’s session ID and tries to encourage the user to click on it.

4. The cleverly encouraged user clicks on the link, which opens the server’s login

page.

5. The server seeing session ID parameter in URL, assumes that, for this user

session already exists and there is no need to create a new one.

6. The attacker has got access to the user’s account.

Figure 2.5: Session fixation via URL rewriting [87]


The progress of the session hijacking is shown in Figure 2.6. It contains the

following steps [88]:

1. The victim is already logged in to the sever and has got session ID.

2. The attacker sniffing a valid user’s session e.g. via stealing cookies due to

physical access to the user’s machine.

3. The attacker using stolen session ID has got access to the user’s account.

Figure 2.6: Session hijacking via sniffing [88]

Prevention

To provide a proper authentication and session management there are many

roles to follow. The most important include [89,135]:

1. protect user authentication credentials using hashing or encryption.

2. disable URL rewriting.

3. Set session token timeout.

4. Invalidate session token after logout.

5. Change session token after changing permission e.g. after successful login.


6. User encrypted connections (e.g. through Secure Sockets Layer (SSL) protocol).

7. After particularly important operation, require again authentication

8. Use flags for cookies:

a) secure – cookie will not be sent with request if connection is unencrypted;

b) HttpOnly – content of cookie will not be available for JavaScript (not sup-

ported by all browsers).

Effect of abuse

To the effects belong [73]:

• stealing the session – attacker can do anything the victim could do, included

administrators’ privileges;

• steal the user’s credentials – knowing logins, passwords and mails belonging

to many users, attacker can try log in to the different servers to steal other

information.

Cross-Site Scripting (XSS)

Attack description

Cross-Site Scripting relies on interpreting served data as HTML code. It is kind

of injection attack, that allows attacker to execute malicious code in the user’s

browser [119]. It involves standard web browsers and browsers embedded in a

software (WinAmp, Rich Site Summary (RSS) reader, email client.). It is usually

used with JavaScript, but may be also extend to VBScript, ActiveX, Flash, in a

nutshell – any browser-supported technology [120].

JavaScript was developed to run in a restricted environment, which means that

it has got very limited access to the user’s operating system or even his files.

However, the possibility of damages caused by this „innocent” script become more

clear, when you notice that JavaScript [119]:

• has access to cookies and thus e.g. session ID;

• can send HTTP request using Ajax;

• can modify current page using Document Object Model (DOM) manipulation

methods.

There are three types of XSS attacks [119]:

• stored (persistent) XSS – malicious script comes from the website’s database;

• reflected (non-persistent) XSS – malicious script comes from the victim’s re-

quest;

• DOM-based XSS – variant of both persistent and reflected XSS, where malicious

script appears, when legitimate script has been just executed.


Example of attack

Undermentioned examples are focused on JavaScript malicious code causing

sending the user’s cookie to the attacker’s server.

Persistent XSS is shown in Figure 2.7 and contains the following steps [119]:

1. The attacker sends a malicious code through website’s form (e.g. by commenting

something) into the website’s database.

2. The victim requests a page (e.g. to see the comments) through his browser.

3. The website sends response including malicious code.

4. The victim’s browser executes the malicious script, which causes sending the

victim’s cookies to the attacker’s server.

Figure 2.7: Stored XSS attack example [119]

Reflected XSS is shown in Figure 2.8 and contains the following steps [119,120]:

1. The attacker prepare a URL containing a malicious script and sends it to the

victim. Script-part of URL is often encode to do not create a suspicion and looks

often like http://website/search?keyword=%3C%73%63%72%69%70 . . . .

2. The victim encouraged by the attacker, clicks the link causing sending a request.

3. The website sends the response including the malicious script.




Figure 2.8: Reflected XSS attack example [119]

Figure 2.9: DOM-based XSS attack example [119]

DOM-based XSS is shown in Figure 2.9 and contains the following steps [119]:

1. The attacker prepares a URL containing a malicious script and sends it to

the victim. Script-part of URL is often encode (each char is changed to


its American Standard Code for Information Interchange (ASCII) represen-

tation in hexadecimal system) to do not arouse a suspicion and looks like

http://website/search?keyword=%3C%73%63%72%69%70 . . . .

2. The victim encouraged by the attacker, clicks the link causing sending a request.

3. The website sends the response NOT including the malicious script.

4. The victim’s browser executes harmless script, which causes inserting malicious

script into the page (malicious is only the request parameter).



Prevention

XSS is kind of injection, which means that to there are the same ways to prevent

from XSS as from the general injection attacks. They includ [119]:

• encoding – making that the browser interprets the user input only as

data, not as code (e.g. encoded version of <script>...</script> looks like:

<script>...<script>);

• validation – making that the browsers interpret the user input as code, but

without malicious commands (e.g. after filtering some HTML elements will be

allowed such as <strong> and some will be disallowed such as <script>).

Effect of abuse


• cookie theft – sending the user’s cookie to attacker’s sever;

• keylogging – sending the user’s keystrokes to attacker’s server;

• phishing – sending the user’s sensitive information to attacker’s server by a

fake login form inserted into the legal (but not properly secured) web page using

DOM manipulation.

Insecure Direct Object References

Attack description

Insecure Direct Object References concerns direct access to the objects based on

input provided by the user. This vulnerability allows to bypass the authorization,

get some sensitive data, and even perform some operations in the system [73,102].

Example of attack

Assume that in program code there is a fragment like shown in Listing 2.2.

Anyone who uses the following link, can see data of someone’s account:

http://example.com/app/accountInfo?acct=notmyacct.


1 String query = "SELECT ∗ FROM accts WHERE account = ?";PreparedStatement pstmt = connection.prepareStatement(query , ... );pstmt.setString(1, request.getParameter("acct"));ResultSet results = pstmt.executeQuery( );

Listing 2.2: Example of code vulnerable to Insecure Direct Object References [73]

Prevention

To prevent from this kind of attack, it is required to protect each object accessi-

ble by the user, which can be some filenames, object numbers ect. and follow the

rules [73]:

1. Use per user or session indirect object references – instead of using direct

database key, prepare a drop down list of some numbers being the keys in a

map, which values represents actual resource, which should be available to the

user, e.g. user chooses URL with „acct” parameter with value 1, which then is

used as a key for a map associated with this user via session, to get the value

1234, which is actual index of account in database;

2. Check access – each direct object reference from an untrusted source must be

preceded guarantee, that the user is authorized for the requested object.

Effect of abuse


• accessing to sensitive information – retrieve a database record;

• performing an operation in the system (that should not be available for the

attacker);

• accessing to a file system resource – retrieve confidential image or document;

• accessing to the application functionality.

Security Misconfiguration

Attack description

Security Misconfiguration risk concerns not appropriate configuration defined

and deployed for an applications, framework, web server, database server and so

on, which can cause unauthorized access to some system data or functionality [73].

Many applications contains some extra features, which are helpful when de-

bugging, but are unsafe when it comes to running on the „open” Internet. Default

installations often includes well-known usernames and passwords, hard-coded ac-

counts etc., which can be used as a backdoor by the attackers. Application-based

configuration files contain connection strings to database in a clear text, thus when

they are not properly locked down, the attacker can get access to the sensitive

information [7].


Servers also has got a default configuration, which are not safe and provide

a possibility to bypass the authentication methods. Servers also may include

well-known usernames and passwords. In addition, misconfigured SSL certificates

and encryption settings cause a huge security risk [86].

Example of attack

This kind of vulnerability concerns more general problem with configuration

rather than specific attack, thus to better understand, there are introduced some

different scenarios of attacks [7,73]:

• The administration console of the application server is automatically installed

and default usernames and passwords are not changed. The attacker finds

administration page, logs in with default passwords and takes control over the

server.

• The application server contains some pre-installed applications, that are not

uninstalled. These application contain many security flaws, which attacker uses

to compromise the server.

• The PHP server configuration file – php.ini includes variable expose_php, which

is by default set to on. In resulting, a specific version of PHP is exposed in the

server header/footer, which can be used to prepare the attack appropriate to

specified PHP version.

Prevention

To protect from this security flow, it is recommended to [73]:

• change/remove hard-coded/default usernames and passwords;

• uninstall all unnecessary applications from server;

• check all configuration connected with security at least twice;

• keep up to date all applications, framework, servers etc.;

• provide a strong application architecture permitting secure separation between

components;

• periodically running the security scans and doing audits.

Effect of abuse

To the effects belong [7,73,86]:

• unauthorized access to sensitive data;

• compromising the server;

• preparing more sophisticated attack based on the specific server’s version.


Sensitive Data Exposure

Attack description

Sensitive Data Exposure risk concerns not properly protect sensitive data, such

as user’s authentication credentials. Secret information should be stored and

exchanged using encryption, because otherwise, they can by simple stolen by the

attacker.

Example of attack

This kind of vulnerability concerns more general problem of data exposure

rather than specific attack, thus to better understand, there are introduced a few

different scenarios of attacks [73]:

• Website does not use SSL for all authenticated pages, thus the attacker can

simply monitor network traffic and steal the user’s session ID, which can caused

access to the user’s private data.

• Passwords are stored using unsalted hashes, thus after capturing a file with

passwords, the attacker can use a rainbow table5 to expose passwords.

• Using automatic database encryption means, that data are „safe” in database.

However, when they are retrieved, they are automatically decrypted, which

causes a possibility to get sensitive data in a clear way using e.g. SQL injection.

Prevention


• do not store unnecessary sensitive information – just remove them if are not

longer required;

• use strong cryptography algorithms and keys;

• do not store password in a clear way – use algorithm designed for the password

protection (e.g. bcrypt, PBKDF2);

• disable autocomplete mechanism on forms containing sensitive data;

• do not forget to use SSL for all authenticated pages.

Effect of abuse

To the effects belong [73,85]:

• compromising sensitive data such as: personal data, credit cards, etc.;

• serious impact on the company’s reputation.

5 Rainbow table – a precomputed table used for reversing cryptographic hash functions, whichis ineffective against one-way hashes including large salts.


Missing Function Level Access Control

Attack description

Missing Function Level Access Control relies on access to executing sensitive

function without a proper control. Many web application, if some functions should

not be available to the user, just hide access to them in the User interface (UI).

Of course, this is not enough to provide right level access control, because the

attacker is able to forge request and get then access without authorization [73].

Example of attack

This kind of vulnerability concerns more general problem of function level access

control rather than specific attack, thus to better understand, there are introduced

a few different scenarios of attacks [64,73]:

• After authenticating the attacker can read information in his secret diary at

www.diary.example.com?user=josh, but he is also able to read someone else

information by changing the URL to www.diary.example.com?user=emma.

• The website provides the action POST parameter to specify the function being

invoked, but mechanism on the server-side do not check if the user’s request

agrees to his role, thus after changing the POST parameter, the attacker is able

to execute a function, which he should not.

Prevention

To protect from this security flow, it is recommended to [64,73]:

• be aware that just hiding links will not pose an effective way to provide the

access control – ensure to have a proper mechanism on server-side before

executing sensitive function;

• deny all access to sensitive data by default and prepare a white-list mechanism

to make available them for specific user’s roles.

Effect of abuse

To the effects belong all damages, that the attacker can cause with unauthorized

access to some sensitive functionality. Administrative functions are the most

desired and can do the biggest damages [64,73].

Cross-Site Request Forgery (CSRF)

Attack description

Web browser send a cookie (often containing the session ID) from all of opened

windows/tabs with a request to the server from comes the cookie. Cross-Site

Request Forgery attack takes advantage of this behaviour of web browsers, which

allows to force the victim’s browser to send the forgery request to the vulnerable


application, which will treat it such as aware request from the legitimate user

[73,130,134].

Example of attack

Assume that some bank’s web application requires login. After that, the user

can see his account and make a money transfer. The user sets the destination

account number and amount to the transfer and then he clicks on the link such

as http://example.com/app/transferFunds?amount=1500&destinationAccount=

4673243243. This link does not contain any confidential information and causes

the making the money transfer for the logged in user. The progress of CSRF attack

is shown in Figure 2.10 and contains the following steps [73,130,134]:

1. The user logs in to the web application e.g. a bank.

2. The website sends a session ID to the user.

3. The attacker sends to the user a prepared link and somehow encourage the user

to click on it (or just send an email, which the user opens). This causes sending

a request to the attacker’s server.

4. The attacker’s server response with an image, which has got

width and height set to 0, but contains a source set to

src="http://example.com/app/transferFunds?amount=1500&

destinationAccount=attackersAcct”.

5. The user’s browser sends a request with user’s session ID, causing the making

the transfer of the user’s money to the attacker’s account.

Figure 2.10: CSRF attack example (based on [118])


Prevention


• use the unique form nonce – include unpredictable token (a securely generated

random nonce) in each HTTP request, which can be send in a hidden filed (better

option) or as a URL parameter (greater risk to compromise) and check before

sensitive operation if it agrees with that, which has been sent;

• require the user to reauthenticate whenever performing a sensitive operation.

Effect of abuse

To the effects belong all damages, that the attacker can cause having access to

the authorized user such as [73]:

• updating the account’s details;

• making purchases;

• performing the logout/logon.

Using Components with Known Vulnerabilities

Attack description

Using Components with Known Vulnerabilities concerns components, such as

libraries, frameworks, etc., which usually run with full privileges. When attackers

discover a vulnerability with some known component and the victim uses this

component, there is a potential risk, that victim’s application will be successful

attacked despite of the other protection [73].

Example of attack

This kind of vulnerability concerns more general problem of components with

known vulnerabilities rather than specific attack, thus to better understand, there

are introduced a few different scenarios of attacks, which are the real-life examples

[73,109]:

• Spring Remote Code Execution – permit to use Expression Language injection in

Spring framework, which allowed attackers to execute arbitrary code (this issue

was fixed soon after discovered, however, it is estimated that about 30 millions

download contained this security flaw);

• Apache CXF Authentication Bypass – attackers could invoke any web service

with full permission, because of the bug with providing an identity token.

Prevention


• identify all versions of used components;


• keep all components up to date – usually vendors do not create patches for old

version components;

• follow forums and producer’s site to be aware of existing vulnerabilities.

Effect of abuse

To the effects belong the range of the effects depending on the discovered

component vulnerability – from minimal to complete host takeover and compromise

sensitive data. To achieve this goal the attacker can use some of attacks already

described such as injection, XSS, ect. [73,109].

Unvalidated Redirects and Forwards

Attack description

Unvalidated Redirects and Forwards concerns redirects and forwards often used

by web applications, which are not proper validated. This enables to redirect

the user to the attacker’s site or get access to execute protected methods via

forwarding [73,108].

Example of attack

This kind of vulnerability concerns more general problem of unvalidated redi-

rects and forwards rather than specific attack, thus to better understand, there are

introduced a few different scenarios of attacks [73,108]:

1. Unvalidated redirect – assume that there is the redirect.jsp web page taking the

url GET parameter. The attacker prepares a malicious link, which causes the

redirection to his page (http://www.example.com/redirect.jsp?url=evil.com) and

sends it via mail to the user. The link looks like trusted for a typical user, be-

cause it starts with trusted domain such as www.example.com. The encouraged

user clicks on the link, which redirects him to the attacker’s page, which has got

the look-and-feel of the trusted page. The user enters his sensitivity information

such as login and password, clicks submit button and all these data are sent to

the attacker.

2. Unvalidated forward – the web application uses the fwd GET parameter

to route the request between different pages belonging to the application.

The attacker prepares a malicious link, which causes the redirection to

the part of the application, which he should not have got access such as

http://www.example.com/page.jsp?fwd=admin.jsp. This link forwards the at-

tacker to the administrative page causing the attacker treatment as an admin-

istrator.


Prevention


• avoid using redirects and forwards;

• avoid using user’s parameters in calculating the destination;

• do not use request parameter to indicate destination URL – instead of that,

request parameter should contain some value, which can be translate (via a

map on the server-side) to the destination URL after checking if the user is

authorised and has got required privileges.

Effect of abuse

To the effect belong [73,108]:

• unvalidated redirects – gaining the sensitive user’s data or even installing the

malware;

• unvalidated forwards – bypassing the access control and gaining administrator’s

power.

2.2.2. Other vulnerabilities

The most popular vulnerabilities concern the weakness of the web applications,

however there are also vulnerabilities of the application layer not caused by the

web application, but by the weakness of the Domain Name System (DNS) servers.

DNS is a hierarchical distributed database holding the information for mapping

the host names to IP addresses. Each domain name on the Internet has a DNS

server providing access to this mapping [128]. Among DNS servers there are:

• Root server – name server for the root zone of DNS; first step in resolving the

host names into IP addresses, returning a list of the authoritative name servers

for the top-level domain (e.g. IP address of the com Top-level domain (TLD)

server).

• Top-level domain (TLD) server – the highest level in the hierarchical DNS (for

all domains it is the last part of the fully qualified domain name e.g. com in

www.example.com); second step in resolving the host names into IP addresses,

returning a list of the authoritative name servers for the lower level domain (e.g.

IP address of the example.com name server).

• Lower-level name server – third step (and further) in resolving the host names

into IP addresses, returning a list of the authoritative name servers for the lower

level domain or the complete IP address (e.g. IP address of the example.com

name server).


There are two kinds of queries to the DNS server [128]:

• recursive – returning the IP address from the cache or recursively asking the

DNS servers to resolve it, which means that this kind of query always returns

the IP address of the hostname if it exists;

• non-recursive – returning the IP address from the cache or a list of DNS servers,

whose can be further asked to resolve the address (but this query does not ask

them).

Assume that the user want to visit www.google.com and enters this address

into the browser. Resolving the IP address of the host name is shown in Figure

2.11 and include the following steps [21,40]:

1. Checking the system’s hosts file, whether it contains the „hard-coded” IP ad-

dress of the looking domain name (almost always it do not).

2. If hosts file does not contain the searched address, the browser asks a DNS

resolver, which can be a local service or an external public resolver received by

the organisation such as Google. The resolver has got a cache, where it stores

the last searched addresses, and if the expected address is there, the resolver

finishes its work and returns it.

3. If the resolver has not got the searched address in its cache (because it has

never been asked for that domain or the address has been removed from the

cache due to exceed expiration time), it sends an appropriate request to the root

server, that responses with the address to the TLD server (in this example –

com).

4. The resolver sends the same request (asking for the IP address of

www.google.com) to the TLD server, which responses with the address to the

lower level name name server (in this example – google.com).

5. The resolver sends the same request (asking for the address IP of

www.google.com) to the lower level name name server, which responses with

the IP address of the looking for server (in this example – www.google.com).

6. The resolver finally response to the client (browser) with expected IP address.

In this chapter there are described two types of attacks on DNS server: DNS

Cache Poisoning and DNS Cache Snooping.


Figure 2.11: DNS lookup resolution process (based on [20])

DNS Cache Poisoning

Attack description

DNS spoofing concerns the entering the incorrect IP address to the cache of

DNS server. DNS server responses with the data from its cache to increase the

performance. This attack causes that, DNS server instead of sending the right,

sends the spoofed IP address [128].

Example of attack

The progress of DNS spoofing attack is shown in Figure 2.12 and contains the

following steps [16,40,128]:

1. The attacker adds DNS record for www.agency.gov.au to the DNS resolver’s

cache, that mapping this host name to the IP address of 203.6.114.66 instead

of 192.0.32.10. It is possible due to the following steps:

a) The attacker sends a large number of recursive requests to the resolver

asking for the IP address of www.agency.gov.au.

b) The resolver asks servers and finally sends requests to the lowel-level name

server of www.agency.gov.au.

c) The resolver expects to receive a large number of replies from the name server

of www.agency.gov.au. Before they appear, the attacker floods the resolver

with a large number of packets with a spoofed source IP address, thus the

resolver caches the wrong IP address.


2. The client sends request for the IP address of www.agency.gov.au to the DNS

resolver.

3. DNS resolver responses to the client with the 203.6.114.66 IP address.

4. The client connects to the attacker’s site instead of expected

www.agency.gov.au.

Figure 2.12: DNS spoofing attack example (based on [16])

Prevention


• keep the resolver private and protected – if you use your own resolver, its

functionality should be restricted to users from your network;

• use UDP source port randomization (UDP SPR) – instead of using default UDP

port 53, use randomly chosen port from the entire range of UDP ports, which

makes it harder to prepare a correct query;

• use secure modes for DNS servers – some DNS servers provide secure mode of

operation such as switching to a TCP connection when the potential attacks are

discovered.

Effect of abuse


• redirection the user to the attacker’s server, where can be used more sophisti-

cated and dangerous attacks;

• setting the Time to live (TTL) filed of the malicious records to a long period such

as weeks/moths, which gives the attacker more time for attacking the user

successfully.


DNS Cache Snooping

Attack description

DNS cache snooping concerns the determining whether a given mapping of

hostname to IP record is present in a cache. It provides possibility to find out

which sites are often visit by the user of DNS server, which can be useful for the

attacker to get knowledge about clients of the target website [17,18,128].

Example of attack

There are two kinds of DNS Cache Snooping attack [17,128]:

• when non-recursive queries are enabled – knowing the specification of

non-recursive queries it should be obvious, that in this situation sending this

kind of query is enough to perform the attack, because if there is looking for

IP address for given hostname in the resolver’s cache – the server sends the

address, otherwise sends the data, that it could not find it;

• when non-recursive queries are disabled – these conditions are not as opportune

as described above, but still it is possible to perform the attack, even in two

ways:

◦ by checking the time that takes the query to process – if the query time

is comparable to the time that it takes to send the packet to the server, it

probably means, that requested address has been already in a cache; to

measure these times there are available tools such as ping (to measure time

of sending packets to the server and receiving responses) and dig (to measure

time of sending the DNS query to the DNS server);

◦ by checking the TTL filed when querying a vulnerable DNS server as opposed

to another root DNS server – TTL response’s value of the DNS query should

be relativity low if the looking for address has been already in a cache (to

check TTL value can be used tools such as nslookup).

Prevention


• forbid to answer on non-recursive query – this allows attack only using recursive

query, which do not provide so effective results;

• add some entropy to TTL while adding entry to cache – it provides theoretically

impossibility to perform this attack.

Effect of abuse

This kind of attack provides the possibility to deduction if the DNS server’s

owner and its users have recently visited a specific site, thus to the effects can

belong [19,128]:

2.3. User layer 34

• accessing to sensitive (e.g. what vendor, bank, etc. are used by DNS server’s

users);

• gather statistical information (e.g. at what time DNS server’s users usually login

into theirs bank account, to be able prepare more sophisticated attack.

2.3. User layer

Providing the network security is essential at every layer of the TCP/IP model to

protect the company. However this model does not include one more existing layer

– the user layer, where users interact with the technology. This layer emphasises

significant role of the network security. Because all of TCP/IP layers become more

advanced and thus it is more and more difficult to perform an attack, attackers

have started to use social engineering to exploit people. It should not be surprising,

because according to estimates – 80% of corporation’s knowledge are located in the

heads of working there people [59,79,128,137].

Attack description

Social engineering is the art of manipulation. It concerns a non-technical

kind of intrusion and making use of humans’ weakness, curiosity, and need of

an acceptance. Social engineers relies on the natural helpfulness of people often

asking to a possibility to use a computer due to the sudden incident [90]. Typically

they use at least one of the following techniques [128,137]:

• Authority – people are prone to execute requests from person with some au-

thority such as a policeman, a politician, etc. Although it might seem correct

behaviour, the dangerous thing is that people do this request even without a

verification (e.g. someone who phoned them and introduced as a policeman,

will be treated as a policeman).

• Liking – when someone appears likeable, most people will react to him in a

pleasurable way and even allow him to more than others.

• Reciprocation – when someone gives us a present or do us a favour, we often

feel indebted and want to repay.

• Social validation – many people want to be accepted by others. To achieve it,

they usually try to be like others. This behaviour can be used to manipulate a

person to do something due to 80% other people already have done it.

• Scarcity – people want things as soon as it possible and do not like to not miss

the chance (even if the chance is not valuable for them), therefore adding the

time limitation to make the decision, could encourage them to do something

against themselves.

2.3. User layer 35

Examples of attack

Bringing away the sensitive information

The attacker is often considered as a person from outside of the company, but

it is not always true. Sometimes the attacker is an employee who wants to bring

away the sensitive information. According to Ponemon Institute – 59% employees

do it [79]. This number do not concern only employees who are asked to leave,

but also theses who want to change the job and do not want to lose the knowledge

acquired during the work. [79].

Spear phishing

Phishing in general concerns the attempting to obtain sensitive information (e.g.

usernames, passwords, credit card details) by personating as an authentic entity in

an electronic communication. Spear phishing is more directly personal-oriented.

Spear phishers do not stop on preparing the email with look-and-feel like that

coming from a valid organisation (e.g. a bank). They make more effort to prepare a

personal email. They look for personal information such as name, postal address,

employer, etc. to compel a trust, which increasing the probability of effective

attack [91–93].

According to [92] – 91% of attacks between February and September 2012

involved spear phishing. This kind of attack contains three steps [92]:

1. Research target – find as many personal information as it possible.

2. Find their email address – nowadays it is very easy obtainable from the web.

3. Send malicious email designed to infect the target’s computer or network – 94%

phishing emails contain malicious file attachments (e.g. pdf, docx, xls).

Spear phishing emails usually contain:

• direct phrase such as Hi, Bob! instead of Dir Sir;

• reference to a mutual friend;

• information about your last on-line purchase;

• provocation with sexual context.

Prevention

To prevent from attacking the user layer it is recommend to [91,93,128,137]:

• provide a security training – employees should be aware of potential risk con-

nected with social engineering, thus it is important to educate them properly;

beyond knowledge about security risk, employee should have a response plan –

clear idea of what to do when they strike an attempt of attack (e.g. suspicious

mail);

2.3. User layer 36

• provide a security policy – this document should clearly and succinctly intro-

duce, what mechanisms of protection should achieve; the top of the organization

should be a starting point from the policy enforcement flows, but what is the

most important – even the best policies and procedures are not effective unless

they will be efficiently taught by the employees;

• keep records of attacks – store all materials of attack in them original form,

which will help the law enforcement the official help if they will be called upon

later (e.g. when it comes to spear phishing it could be done by storing the

electronic copies of all emails on a DVD-ROM and making a paper copies of their

headers, which can sensitise the employees on some typical forms of headers);

• to protect from spear phishing consider the following statements:

◦ hide all private information (e.g. family member, friends) on a social network

site – this information help the attacker to prepare the more personalized

malicious email;

◦ do not use just one password (or easy to figure out variations on it) to all

accounts – if attacker somehow gets our password to one account, he can

easy break into others;

◦ verify the identity of any email asking for some sensitive information (e.g.

passwords) – call them or just send email direct to them to confirm theirs

request.

Effect of abuse

To the effects of the attacking the user layer belong a very wide range of damages

including [59,79,128,137]:

• revealing a sensitive information;

• installing a malicious software (e.g. keylogger, that loggs and sends to the

attacker user’s keystrokes and screen captures);

• gathering the user’s credentials to prepare more sophisticated attack.

3. Web application architecture

Web application architecture is a very wide term. There are many frameworks

in many programming languages (Java, C#, Ruby, Python, PHP). The aim of this

chapter is to introduce the concepts of web application architecture and focusing

on web technologies used to developed the WebHiob environment. WebHiob is

mainly developed in Java, therefore this chapter describes web technologies mostly

in this programming language.

Web application architecture is almost always multi-tiers. This issue is extended

in the section 3.1. Although multi-tiers architecture, there are functionalities, that

cross all layers such as security. This question is important in the point of this

thesis’ view, thus there is a detached section dedicated to this problem (3.2).

To write professional web application in Java, it is recommended to use Java

Enterprise Edition (JEE), which is the standard in community-driven enterprise

software. Java Community Process (JCP)1 keeps guard on developing of JEE. JEE

comprises a lot of specifications (Java Specification Request (JSR)) set by JCP. Each

JEE technology is a JSR with a specific number e.g. JSR 372 concerns the Java

Server Faces 2.3 [48].

The most common architecture for web application is a model-view-controller

(MVC) design pattern. It assumes isolation between business logic and UI, because

mixing them makes the application much harder to maintain and less scalable.

Relations between model, view and controller are shown in Figure 3.1. The model

represents the state of the application and provides the actions to modify it. It

is usually used by the view to get state and by the controller to change it. The

view is a kind of representation of the model, but it should not modify the model.

The view collects the user inputs and can them initially validate. The Controller

processes the user input from the HTTP requests and manages the model providing

the change of its state or performing some operations. The Controller selects the

view and return the HTTP response to the client (typically a browser) [127].

1 Java Community Process (JCP) – mechanism for developing standard technical specificationsfor Java technology. This community has got contributions from industry experts, commercial andopen source organization, Java User Group (JUG) and a lot of individuals [47,48].

3.1. Layers 38

Figure 3.1: Typical MVC architecture for web applications (based on [127])

3.1. Layers

Typical web application consists of the three basic tiers [111]:

1. Presentation – Graphical User Interface (GUI); the main function is to tasks and

results to something that the user is able to understand (this tier is used by a

web browser).

2. Logic – coordinates the application, performs logical decision and evaluation,

moves data between presentation and data tiers (this tier is used by a web

application server).

3. Data – stores and returns data (this tier is used by a database).

More specified Java-oriented enterprise web application architecture is shown

in Figure 3.2. This diagram is based on [135], but I have extended it in order to

better explain which technologies fit to the MVC architecture. Most technologies

contained in Figure 3.2 are only briefly described in this chapter due to their

amount. More attention is given to technologies used in WebHiob developing.

3.1. Layers 39

Figure 3.2: Java-oriented multi-tiers web application architecture (based on [135])

3.1.1. EIS

Description

Enterprise Information System (EIS) layer consists of database servers, legacy

data sources and Enterprise resource planning (ERP)2 systems [24,49]. Almost all

web applications need to store some data, thus a database server is an indispens-

able element. WebHiob uses In-Memory Database (IMDB)3 version of Hyper SQL

Database (HSQLDB). Nowadays the most common used databases are relational

(e.g. Oracle, MySQL) and NoSQL (e.g. MongoDB, Cassandra) [63]. Readers more

interested in this layer could read more about the relational database ( [81,129]),

NoSQL ( [66,67]), and a short comparison between them ( [2,82]).

2 Enterprise resource planning (ERP) – business management software helping out managementof corporations. The software in the main consists of a suite of integrated applications, which handleall facets of enterprise including product planning, development, sales, marketing, etc [25].

3 IMDB – database management system primarily relying on main memory of computer (RandomAccess Memory (RAM)) [41].

3.1. Layers 40

Vulnerabilities

Vulnerabilities connected with the EIS layer belong primarily to the security

misconfiguration category. To protect this layer it is recommended to check ad-

ministrative configuration and provide a proper data encryption (to avoid MITM

attacks).

3.1.2. Back-end

Description

Back-end performs operations on data from EIS. To get access to a database

from Java code level, it is required to use the Java Database Connectivity (JDBC)

library. Each database vendor provides a JDBC driver allowing to use of his

database.

The pros of using JDBC include [51]:

• clean SQL processing – full control over each SQL query provides easy debugging

possibility;

• good performance – relativity ease to impact on performance due to full control

of the SQL query (allowing e.g. to reduce the number of joins).

The cons of using JDBC include [51]:

• lots of code to write – providing transaction and concurrency, handling con-

nections and resulting errors on your own, additional there is need to map the

query results to object and vice-versa;

• problems with changing database during project – if an application was devel-

oped with some database, it is really difficult to change a database provider;

• no SQL logging mechanism – to log which and when SQL queries are executed

it is required to implement this functionality on your own.

To avoid problems with pure JDBC, often the JPA technology is used. This is an

ORM API, which is based on JDBC „under the hood” [51]. JPA configuration file is

called persistence.xml and contains basic informations required to proper working

the technology (e.g. persistence-unit name, URL connection, login and password

to database, JDBC driver, entity classes) [139].

The basic principle of the ORM is shown in Figure 3.3. Plain Old Java Object

(POJO) class with a few annotations is an objective equivalent of a table in a

database. Only two annotations are required to provide the default mapping:

@Entity and @Id. The others annotations provide the special possibilities and

3.1. Layers 41

configurations – under the principle of convention over configuration4 (e.g. using

@Column annotaion there is a way to change the name of mapped table’s column to

a property in Java class as it is shown in Figure 3.3).

Figure 3.3: Example of simple ORM mapping [135]

JPA is an ORM interface. Ihe most popular implementations include: Hibernate,

Eclipse Link, TopLink [51]. The former is used in WebHiob. All of JPA implemen-

tations allow to use the Java Persistence Query Language (JPQL) query language,

which is very similar to SQL. The pros of using JPA include [51]:

• no need to deal with the database implementation – you can freely change

database vendor without bigger changes in code;

• less code to write – SQL statements are replaced with simpler JPQL statements;

• simple configuration – one configuration file and some annotations;

• concurrency, transactions management and automatic key generation;

• build in SQL logging mechanism;

• build in cache mechanism – two levels of caching significantly increases perfor-

mance.

The cons of using JPA include [51]:

• complicated query with many joins can have negatively impact on performance;

• changing JPA implementation is not so simple – JPA is a specification rather

than a product, which causes that difference vendor extends it on their own.

4 Convention over configuration (also known as coding by convention) – a software designparadigm which assumes, that there is implemented default configuration and if this conventiondoes not fit in a particular situation, we can change it by a configuration (typical via annotations orXML configuration file).

3.1. Layers 42

Vulnerabilities

The most common vulnerabilities connected with back-end layer are injection

variations (especially SQL and JPQL injection). WebHiob provides a lesson about

JPQL injection, therefore more information can be found in section 6.4.

3.1.3. Logic

Description

Logic layer agrees to the model part in the MVC architecture. As shown in

Figure 3.2, there are many possibility to represent the Model. The most basic

approach is to use a POJO. The POJO is a Java object which does not required any

restrictions such as extending specified classes, implementing specified interfaces

or containing any annotations [78].

The other way to represent the model is to use a Managed Bean (MBean). They

are POJO classes with the specified annotation and are automatically created by

the framework managing them. MBean has a lifetime depending on its scope (e.g.

request, session, application scopes) [62]. All technologies belonging to the model

layer shown in Figure 3.2 beyond the POJO are the MBean. In WebHiob there

are used JSF and Spring beans. JSF bean is used to get access to the object’s

properties from the Facelets view technology (see View layer description). Example

usage of Spring bean in WebHiob is to provide an object involved to the user’s

session.

Vulnerabilities

Because of the passive nature of the model layer, there is no vulnerabilities

directly connected with this layer. The indirect security flaws may include the not

properly performed validation in managed beans (e.g. using black-list instead of

white-list validation may cause the access to some function by an unauthorized

user).

3.1.4. Middleware

Description

Middleware layer agrees to the controller in the MVC architecture. To this

layer come the user’s requests, which are handled and then the responses are

returned. All technologies shown in Figure 3.2 in the middleware layer beyond the

Servlet, include the MVC frameworks. All of them are build on the top of Servlet

technology and extend the front controller design patter. This pattern relies on

providing a centralized entry point (a front controller) for handling requests. The

3.1. Layers 43

front controller delegates requests to a proper controller [123]. The flow of this

process is shown in Figure 3.4 based on the Spring MVC architecture.

Servlet is available since the beginning of JEE (version 1.0 in 1997) and is

still supported (version 3.1 in 2013). Servlet is a Java interface and the class

implementing it, provides the handle of HTTP requests and responses, mainly

through methods called doXXX, where XXX can be almost all HTTP methods [3].

Figure 3.4: Spring MVC architecture as example of the front controller design patter(modified based on [98])

Two web frameworks, that have dominated the others when it comes to the

usage, include Spring MVC and JavaServer Faces (JSF) (respectively with 40% and

21%) [105]. The WebHiob environment uses Spring MVC framework.

JSF is the web application specification, whose the goal is to make development

easier and faster by supporting user interface components in the Rapid Application

Development (RAD) approach. This approach allows to build HTML pages using

specified components (even by drag-and-drop interface) instead of native HTML

tags. There are many vendors and open source implementations of JSF specifica-

tion (e.g. Apache MyFaces).

Spring is a framework for building Java applications (and also .NET –

Spring.NET). Unlike many other frameworks, Spring is not limited to web appli-

cations. Spring architecture provides many desirable features [125]:

3.1. Layers 44

• Inversion of Control (IoC) container (from the core part);

• JDBC support and transaction management (from the Data Access Object (DAO)

part);

• AspectJ integration (from the Aspect-Oriented Programming (AOP) part);

• lots of ORM tools integration e.g. Hibernate (from the ORM part);

• Web MVC framework – from the web part providing integration with many view

technologies (e.g. JSP, Tiles, Velocity) and supporting the internationalization,

Asynchronous JavaScript and XML (AJAX), pagination, file uploading, etc;

• possibility the use many of JEE specifications (e.g. Java Management Exten-

sions (JMX), Java Message Service (JMS)).

Vulnerabilities

There are many kinds of vulnerabilities with this layer (or rather MVC frame-

works). The Common Vulnerabilities and Exposures (CVE) system provides a

reference-method for publicly known information about vulnerabilities for many

vendors and products. The Open Vulnerability and Assessment Language (OVAL)

definitions define what should be done to verify a vulnerability and what patch to

install to protect from them. On the page [110] there are listed CVE identifiers and

links to OVAL definitions for the Spring framework. Each vulnerability is directly

explained with an indication to the affected versions of Spring.

To known Spring MVC vulnerabilities belongs: Data Submission to

Non-Editable Fields and ModelView Injection [96, 106]. Both are contained in

WebHiob lessons, therefore they are described in detail in other chapter, respec-

tively in sections 6.2 and 6.3. When it comes to JSF, there are some security bugs

that have been fixed in next versions e.g. token included to view, to protect from

CSRF attack, was too easy to guest, thus it does not protect (it was fixed in JSF

2.2 [44]).

3.1.5. Web services

Description

Web services represent the most popular form of Service Oriented Architecture

(SOA). SOA is an abstract concept, an architectural style, and the web services is

the most often technology used to realization this concept. Web services provide

communication between different platforms e.g. Java application can invoke .NET

web service method. Therefore many companies provide access to their data

via web service. There are main two approaches of realization the web services:

3.1. Layers 45

Simple Object Access Protocol (SOAP) and Representational state transfer (REST)

[122,142].

The SOAP web service is built and defined in Extensible Markup Language

(XML). To use it in Java EE there is the Java Api for XML Web Services (JAX-WS)

specification [127]. To simplify relatively heavy SOAP specification, the REST was

introduced. Create, Read, Update and Delete (CRUD) operations corresponding to

the HTTP methods are summarized in Table 3.1 [142].

The most common technologies to use REST in Java web application include:

Java API for RESTful Web Services (JAX-RS) and Spring MVC Rest. The latter is

used in WebHiob to provide communication with server from AngularJS and GWT

view technologies using JSON format.

Table 3.1: HTTP methods and according to them CRUD operations

HTTP method CRUD operation

POST Create

GET Read

PUT Update

DELETE Delete

Vulnerabilities

There are many vulnerabilities connected with web services. They include the

varied kinds of injections (e.g. XML, XPath, XQuery injection, where XPath and

XQuery are query languages for XML documents). To secure SOAP web services,

there were introduced the Web Services Security (WS-Security) standard. More on

securing the SOA can be read in [142].

3.1.6. Front-end

Description

Front-end provides the GUI for the user. Technologies such as HyperText

Markup Language (HTML), Cascading Style Sheets (CSS), JavaScript (JS) and AJAX

have become the standards, which every professional web page uses. JSP is a

front-end technology dynamically generates the web pages on the server side. JSP

page is compiled to servlet and allows to use Expression Language (EL) giving

access to Java beans. Although JSP provides a template approach, they have

appeared some template engines (e.g. Velocity, Freemaker, Thymeleaf) making the

programming easier. JSP allows to use scriptlet (a piece of Java-code embedded in

the page) making the code very hard to tests and maintain.

3.2. Authentication and authorization 46

Facelets is the recommended (server side) view technology for JSF. It has got

built-in template engine, allows to use the EL, and is still supported against to

JSP [48]. Due to this features, the Facelets was chosen as a server side view

technology in WebHiob. Nowadays the Rich Internet Application (RIA)5 and RESTful

approach become more popular. The frameworks making easier to implement RIA

application include, among others: GWT and AngularJS (both used in WebHiob).

GWT is a development toolkit for building complex RIA applications. Its goal is

to enable productive development without the developer having to be an expert

in JavaScript and browser quirks. GWT SDK provides the Java API libraries,

compiler, and development server. It allows to develop client-side applications in

Java and deploy them as JavaScript using included Java to JavaScript compiler.

GWT allows to call server methods from client side using GWT-RPC framework6,

however WebHiob uses the newer RESTful approach and uses only client side of

GWT and communicates with the server side using JSON format [32,121].

AngularJS is a JavaScript framework based on the MVC pattern. The views are

specified using HTML + AngularJS’s attributes. The models and controllers are

specified via JavaScript objects and functions. The useful feature of AngularJS is

data-binding, that provides an automatic way of updating the view whenever the

model changes, as well as updating the model whenever the view changes. This

feature eliminates the need of DOM manipulation on your own [5,126].

Vulnerabilities

The vulnerabilities connected with front-end layer are caused mainly by treating

the user input data as command. They include, among others: XSS and other kind

of injections (e.g. EL injection which is the subject of one of the WebHiob lesson

described in section 6.5).

3.2. Authentication and authorization

Many web pages require login to get access to their content. This process

contains of two steps [122,140]:

5 Rich Internet Application (RIA) – web application providing rich and dynamicone-screen-application interface, which is common used in desktop applications. Thereby allcommunication with server is done by AJAX avoiding in this way multiple re-downloading of wholepages [83].

6 GWT RPC framework – framework providing the exchange of Java objects over HTTP betweenclient and server components. The implementation of a Remote procedure call (RPC) service is basedon the servlet architecture. GWT handles the serialization of the Java objects passing back andforth [33].


1. Authentication – the process of ensuring, that the user is really the person who

he/she claims to be.

2. Authorization – the process of ensuring, that the authenticated user has got a

proper privileges to perform requested action.

To provide this functionality it is recommended to use well-tested and known

framework instead of developing it on one’s own. Java platform provides an

API for authentication and authorization processes – Java Authentication and

Authorization Service (JAAS). There is also a Java framework especially designed

for this purpose – Spring Security [97], which overlaps mainly with JAAS. The

Spring Security is more powerful and flexible, therefore in this thesis (and in

WebHiob) all issues connected with authentication and authorization are solved

with its help [140].

3.2.1. Spring Security

Spring Security is highly customizable authentication and access-control frame-

work. It provides integration with Spring Web MVC and protection against many

attacks (e.g. session fixation, clickjacking, CSRF) [97, 140]. The basic operating

principle is shown in Figure 3.5. After starting the application, the Context Listener

loads Spring Security configuration and all filters. All requests satisfying the de-

fined in configuration file the URL path, will go through security filters, which is

shown in Figure 3.5(a). Filters decide if the access should be granted according to

the rules shown in Figure 3.5(b) [140].

To secure the web application, the Spring Security framework uses filter chain

model, which is built on top of the standard servlet filter functionality. The filter

chain preprocesses and postprocesses all the HTTP requests. Filter gives the

possibility to perform some special action before or after the primary functionality

of the web application. There are many filters in Spring Security, but there is a

possibility to add the custom filter in three ways: before, after or instead of already

existing [140].


(a) Spring Security from load up to first request (b) Filters at work

Figure 3.5: The principle of operation of the Spring Security framework [140]

3.2.2. Stateful and stateless authentication

There are two different ways of implementing the server side authentication:

stateful and stateless. The most commonly used is the stateful approach using

the cookie-based authentication, which uses the HTTP session object. The server

generates an object, which is identified by session id. This id is sent to the browser

and stored in the cookie. When the browser sends the request, it includes the

session id in the request header. The server finds the session object based on the

id and checks if it is still valid.

There are two kinds of the stateless authentication approach: basic access

authentication and token-based authentication. The former is the oldest way of

dealing with authentication. It relies on sending the username and password

encoded using the variant of Base647 with every request. It means that this method

is only safe with the secure SSL/HTTPS connection [42,99].

7 Base64 – binary-to-text encoding scheme representing binary data in an ASCII string format,that could be easy decoded [103].


Token-Based authentication is the newer approach, which relies on a signed

token that is sent to the server with each request (such as the session id). Server

generates the token and signs it (e.g. using the digest function and secret key) and

then sends to the browser. The browser sends back the token with each request

to the server, which checks its correctness by comparing signatures: received and

just calculated [99]. The benefits of using this approach include: [9]:

1. Stateless (server side scalability) – there is no need to store a session, because

a validation of token can be calculated with every request.

2. Decoupling – the token can be generated anywhere.

3. Mobile ready – token-based approach simplifies a lot work with secure API on

the mobile platforms.

4. CSRF – token could be stored in local or session storage instead of cookies,

therefore it is impossible to perform the CSRF attack.

4. Desired features of learning environment forsecurity of web application

Teaching in general is a challenge itself. There is no the best way to teach

someone anything. Effects of the learning depend on many dimensions such as

the branch of science, primary knowledge, age of the learner, etc. There are many

books and web sites concerning web security. Part of web sites (e.g. [112]) allows

to exercise the hacking, but you cannot see the source code on the server side

and cannot change the source code to protect from the attack. It causes that

other solution is necessary i.e. an external application for teaching security of web

applications. As mentioned in the Introduction chapter, the interactive approach

allowing to make use of a vulnerability, see the vulnerable source code and fix the

vulnerability, is the best approach for the effective learning about web application

security.

An application for teaching web security should provide a nice user experience

to encourage students to use it and to make the learning process more comfortable.

The application should be designed with a view to a long-range development,

therefore there is also very important to provide a well-designed architecture to

also encourage others to adding new lessons. Due to these reasons, this chapter

describes a set of features of the ideal application for teaching web security divided

into two parts – from the point of the view of an user and a developer extending the

environment.

4.1. Features important for a user

Features important for a learning environment user could be divided into func-

tional and non-functional. When it comes to the latter, the environment should

work on the most popular operating systems (Windows, Linux and Mac OS). It

should support internationalization (at least English and German languages). The

other basic and important feature is ease to launch. Web application needs a web

server to run, therefore the best solution for the user is to provide a launching

script and already configured web server. The environment should also provide a

4.1. Features important for a user 51

user manual or an interactive help explaining how to take advantage of the environ-

ment. The help is not often needed, if the user interface is properly designed and

self-explanatory. The GUI should be properly displayed in all of the most popular

browsers (Chrome, Firefox, Internet Explorer, Safari). The environment should be

able to work offline due to security risks involved with vulnerabilities. Source code

displayed by the environment (e.g. in case of explaining how to prevent from the

attack) should provide a proper syntax highlighting. Lessons should be interest-

ing, what could be achieved by the modern UI and introduction to the lessons in a

curious way.

When it comes to the functional features, the environment should provide the

lessons divided into categories (the division could be based on the OWASP Top Ten

document [73]). Apart from the typical lessons focused on one specific attack, the

environment should provide a challenge section gathering knowledge from a couple

of lessons. Users should have a possibility to store the state of executed lessons,

see statistics and be clear the state of chosen lesson (or the all history).

Some attacks need more knowledge to understand than others, thus good idea

is to mark the difficulty level of the lesson. This could help beginner students

to choose easier lessons at the beginning and then, with some experience, to

better understand more difficult lessons. Lesson should have also marked view

technology in which it has been developed. This could help the user to choose the

lesson if this lesson has been developed in more than one view technology. Each

lesson should provide a proper introduction explaining how to take advantage of

the lesson and what is the aim of it. An integral part of lesson should be the security

flaw description and the solution how to prevent it. This is the most important for

the learning process, that the user exactly understands why the specified attack

is possible, which code is responsible for this and how to improve the code. The

environment should provide some tips how to solve the lesson. It will be useful if

a user tries to do a lesson without looking at the entire solution and encounters

some difficulties. The amount of tips should depend on complexity of the lesson.

The user should have possibility to quick look at source code of the lesson from

GUI. However it could be replaced by the list of files involved with the lesson,

because Integrated Development Environment (IDE) allows to read code in much

easier ways. Therefore the user can easily find these files and take advantage of

the IDE features such as a quick look at the documentation of some functions.

4.2. Features important for a developer 52

4.2. Features important for a developer

The ideal environment for teaching security should be continuously developed.

To achieve this goal, the application should provides some features important for

developers extending the environment. First of all there should be a documentation

containing at least simple architecture diagram with description of important and

not obvious decision of implementation and recommendation how to provide the

consistent programming style. The next desirable trait is a clean code. The code of

poor quality could provide many difficulties with finding new bugs. Developing the

unit tests much helps to maintain a clean code. To provide the high percentage

of the coverage of unit tests, useful may find the Test-driven development (TDD)

approach, however with web applications, it could turn out very difficult and

time-consuming. Notwithstanding this fact, the web application should have at

least unit and integration tests covering the most important functionality. The

architecture of the environment should fit the MVC pattern. This means that at

least the view and model should be strictly separated. The application should be

built using the automation tool not requiring any special IDE. The recommended is

the newest tool – Gradle, combining declarative and imperative approach, however

still the most popular is Maven, therefore it could be also used.

The learning environment should allow to develop a new lesson in more than

one view technology. This possibility would be useful for some developers who feel

themselves good in some technologies and badly in the others. The environment

should be prepared to extend it with technologies other than already integrated.

Many students do not want to learn about old technologies, thus the learning envi-

ronment should use modern ones to encourage to development. The environment

should provide ease adding of a new lesson. Source code of the web application

should be available on a public repository with the system control version, which

could be useful to revert previous version and make the developing by many pro-

grammers easier.

4.3. Summary

The considerations included in this chapter are enumerated below. Features

of the ideal learning environment for security of web application from the point of

users view:

1. Non-functional features:

a) Multi-platform application.

b) Internationalization.

4.3. Summary 53

c) Ease launching.

d) User manual or interactive help.

e) Self-explanatory user interface.

f) Working offline.

g) Properly working in all of the most popular browsers.

h) A proper syntax highlighting for source code displayed in the GUI.

i) Interesting lessons.

2. Functional features:

a) Involved with all lessons:

i. Lessons divided into categories.

ii. Challenge section requiring the knowledge from a couple of lessons.

iii. Storing the state of executed lessons and the possibility to clear the

history.

b) Involved with a single lesson:

i. Marked difficulty level.

ii. Marked view technology.

iii. Introduction.

iv. Security problem description.

v. Description how to solve the lesson.

vi. Description how to protect from the attack.

vii. General advices connected with the attack.

viii. Tips how to solve the lessons (not entire solution).

ix. Quick look at the source code of the lesson from the GUI.

Features of the ideal learning environment for security of web application from

the point of developers view (all non-functional features):

1. Involved with the general engineer approach:

a) Developers documentation.

b) Clean code.

c) Unit tests.

d) Architecture MVC.

e) Automated build tool.

2. Involved with the approach focused on the learning environment:

a) Possibility to develop a lesson in more than one view technology.

b) Possibility to easy integrate other view technologies then already integrated.

c) Using modern technologies to encourage students to development.

d) Ease adding a new lesson.

e) Source code on a public repository.

5. Analysis of existing environments forteaching of web security

The existing environments to teach web security include:

1. WebGoat

2. DVWA

3. HacmeBank

However only WebGoat is still developed and concerns the Java technologies.

The others have been written respectively in PHP and .NET technologies.

5.1. WebGoat

WebGoat is a deliberately insecure web application developed by the OWASP

organization. The aim of it is to teach web application security through interactive

lessons [116]. WebGoat project has got also Github’s web page [114] containing a

short documentation. From this page could be downloaded the application.

During writing this chapter the newest version is 6.0.1, which according to the

project’s web page [116], it is the beta release with a major modernization of the UI

and framework (the new UI is shown in Figure 5.1). This version was released on

26 September 2014, almost two years later than previous version (5.4 – 9.09.2012),

however the first one was released in 2008 [113]. The source code is available on

Github repository [115]. All information in this chapter are written based on the

version 6.0.1.

WebGoat contains 28 lessons, four standard labs (not requiring the source

code), and four developer labs (requiring the source code). Labs are lessons, which

rely on improving the existing code to make the attack impossible. There are two

distributions of WebGoat:

• Easy-run package – a platform-independent executable jar file requring Java

Runtime Environment (JRE) at least in version 1.6 (because of the lack access

to the source code, there is impossible to complete the four developers labs);

5.1. WebGoat 55

• Source distribution – allowing to modify the source code of WebGoat, which is a

standard Maven project requiring Java Development Kit (JDK) at least in version

1.6 and Maven at least in version 3.

Figure 5.1: WebGoat 6.0.1 – screenshot of the DOM Injection lesson

WebGoat was written using Java EE technologies, therefore because of Java

virtual machine (JVM), the application is multi-platform. Description of the most

lessons plans is available in three languages (English, Germany and Russian),

however there is no possibility to change language from the application or change

language of other part of the application (lesson solution, tips). Launching WebGoat

is very easy for two distributions – easy-run package requires only the jar file to run

and the developer version requires to run the maven install goal. WebGoat provides

the self-explanatory interface and contains the useful introduction serving as the

user manual.

WebGoat’s lesson are divided into categories (e.g. Cross-Site Scripting, Injection

Flaws, Authentication Flaws). Each category contains at least one lesson. Eight

of them contains labs lessons. It means that WebGoat does not shown how to

protect from each vulnerability. When it comes to interesting lesson – only a few

lessons are eye-catching such as Multi Level Login (as example of Authentication

Flaws category), which shows similar situation to a bank application, where there

are login, password and tokens. However even in this very important vulnerability,

there is no indication how to make the attack impossible or which part of codes

are responsible for the vulnerability. Unfortunately, this approach makes that, the

user can solve all of lessons and still has got a little idea how to write the secure

code and how to improve insecure one.

Each lesson has got description how to solve the lesson, however lessons have

not got marked the difficulty level. Apart from the entire solution, there are avail-

able useful tips for the most of lessons. The interesting features is the Challenge

5.2. DVWA 56

lesson, which requires knowledge from a couple of lessons and has not got a solu-

tion. The useful possibility is to quick look at source code of the lesson. However

even if the lesson contains two part: Java class and JSP file, the user is able to

see only the Java class. User interface for lessons have been developed in Java

using Element Construction Set (ECS) – retired Jakarta subproject. ECS abstracts

away the HTML text and treats HTML as set of Java objects [141]. This approach

makes structure of lesson hard to maintain, test and understand, especially, when

long JavaScript code is hard-coded in Java class through ECS. Therefore lessons

shows attack on the abstract layer rather than a specific (using in a „real world”)

web technology. In this way there are hidden specific traits of existing web tech-

nologies. Using ECS as main source of the lesson code has got impact on the clean

code of WebGoat.

The WebGoat has been developed since 2008 and is still maintained. Since then

the Spring core and Spring MVC has been partiality added, but still old-fashioned

Servlets acts as a custom front controller pattern. Also JSP and scriptlets are

used, which prevent good MVC architecture and possibility to test driven approach.

Old-fashioned technologies (Servlets, JSP with scriptlets), in the newest version

(6.0.1), are mixed with modern technologies (Spring MVC, AngularJS and Boot-

strap). Due to using Spring, there is a possibility to integrate other view technolo-

gies (e.g. Velocity).

WebGoat has got a little developer documentation, where there is explained

how to configure Tomcat server, run application, add a new lesson (which is very

simple). There is no explanation of the application’s structure, thus it is difficult

to understand how it exactly works (excluding adding a new lesson which is really

simple).

5.2. DVWA

Damn Vulnerable Web App (DVWA) is an application similar to WebGoat. It

was also written deliberately insecure to provide interactive lessons about web

security [22]. DVWA has been created by RandomStorm [80] and is no more

developed.

The project was created in 2008 and the newest released was in 2013 (1.0.8),

however the biggest change compared to the previous version (1.8, released in

2011) was versioning change – number 1.8 has been changed to 1.0.8. The source

code is on the Github repository [23]. All information in this chapter are written

based on the newest version 1.0.8.

5.2. DVWA 57

DVWA was written using PHP, thus it works on every server World Wide Web

(WWW) supporting this script language. Because of script language, term of build-

ing tool is not applicable. The application does not support internationalization.

Launching DVWA is not as easy as WebGoat – it must be ensured, that MySQL

database and server WWW with PHP are installed. Additionally, it must be checked,

that MySQL connection and password parameters are configured properly. Af-

ter all it is enough to copy the folder with DVWA to right folder of server WWW.

DVWA folder contains documentation in PDF file. Although the documentation

concerns version 1.3 from 2010, it is still useful and provides instruction of the

installation, description of all lessons and troubleshooting section. DVWA has got

self-explanatory interface, which is shown in Figure 5.2.

Figure 5.2: DVWA 1.0.8 – screenshot of the Command Execution lesson

DVWA’s lessons are not divided into categories. None of them shows how to

make the attack impossible. Each lesson has got description and partial solution

how to solve it. Access to this functionality is possible through the View Help

button, which opens a new small window. Lessons are not eye-catching – almost

all of them rely on writing characters to the form’s fields (example of Command

Execution’s lesson is shown in Figure 5.2). The useful possibility is to quick look

at source code of the lesson, however it opens another new window, which is

inconvenient.

DVWA has been developed since 2008 and the quality of the code is not on the

high level. DVWA does not use PHP classes and there are no unit tests. DVWA

5.3. HacmeBank 58

has not got any developers documentation, where are explained application’s ar-

chitecture or even how to add a new lesson. For people how know PHP, it should

not be very difficult, however at least this information should be included in the

documentation.

5.3. HacmeBank

HacmeBank is an another deliberately insecure web application. It has been

created by the Foundstone company in 2006, however OWASP has made a fork of

the original HacmeBank and now there is a possible to download it through the

OWASP’s Subversion (SVN) [23]. The project page is located under the link [35].

HacmeBank have been written in the ASP.NET technology, thus it can be run on

every environment supporting .NET, which practical means only Windows system.

The application does not support internationalization. Launching HacmeBank is

similar unbearable as DVWA – it requires .NET framework version 1.1, Microsoft

IIS and either Microsoft SQL Server 2000 or MSDE 2000. Fortunately, there is a

documentation describing the installation steps.

The idea of HacmeBank is different than in the others environments – there are

no directly separated lessons, instead, there is a typical web application with a lot

of vulnerabilities. Information about lessons are available via the documentation,

which contains every step needed to complete the lesson. The SQL injection lesson

is shown in Figure 5.3.

Figure 5.3: HacmeBank – screenshot of the SQL Injection lesson

5.4. Summary 59

Due to the different approach, in HacmeBank there is no possibility to quick

look at source code from the application or to see solution of the lesson. There are

no direct lessons, because it is a typical web application similar to a bank.

HacmeBank has been developed since 2006, thus is uses old technologies.

ASP.NET does not provide a good MVC architecture and making unit tests is

very difficult in this technology. There is no developers documentation, where

are explained the application’s architecture or even how to add a new lessons.

5.4. Summary

All of environments from this chapter have been tested in the point of desired

features from chapter 4. The results are summarized in three tables marking the

functional and non-functional features important for a user (Table 5.2 and 5.1) and

a developer extending the environment (Table 5.3).

Table 5.1: Summary of functional features of existing applications to teach security fromthe point of the user’s view

Feature WebGoat DVWA HacmeBank

Involved with all lessons

Lessons divided into categories Yes No No

Challenge section requiring the knowledge from acouple of lessons

Yes No No

Storing the state of executed lessons and possibilityto clear history

Yes No No

Involved with a single lesson

Marked difficulty level No No No

Marked view technology No No No

Introduction Yes Yes in manual

Security problem description Part No No

Description how to solve the lesson Yes Part Yes

Description how to protect from the attack Part No No

General advices connected with the attack No No No

Tips how to solve lessons Yes No No

Quick look at the source code of the lesson from theGUI

Yes Yes No

5.4. Summary 60

Table 5.2: Summary of non-functional features of existing applications to teach securityfrom the point of the user’s view


Multi-platform application Yes Yes No

Internationalization Part No No

Ease launching Yes Part Part

User manual or interactive help Yes Yes Yes

Self-explanatory user interface Yes Yes Part

Working offline Yes Yes Yes

Properly working in all of the most popular browsers Yes Yes Yes

A proper syntax highlighting for source code dis-played in the GUI

No N/A N/A

Interesting lessons Part No Part

Table 5.3: Summary of non-functional features of existing applications to teach securityfrom the point of the developer’s view


Involved with the general engineer approach

Developers documentation Part No No

Clean code Part No No

Unit tests Part No No

Architecture MVC Part No No

Automated build tool Yes N/A No

Involved with the approach focused on the learning environment

Possibility to develop a lesson in more than one viewtechnology

No No No

Possibility to easy integrate other view technologiesthen already integrated

Part No No

Using modern technologies to encourage studentsto development

Part No No

Ease adding new lessons Yes Part No

Source code on a public repository Yes Yes Yes

6. Proposed lessons for the authorialenvironment

The authorial environment provides ten lessons. Two lessons present the same

topic, but have been develop in two view technologies (JSONP XSS lesson in GWT

and AngularJS), thus there are nine lessons about different security problems.

None of these vulnerabilities was not a subject of any of the lessons in already ex-

isting environments (WebGoat, DVWA, HacmeBank). List of the lessons of WebHiob

with categories and view technologies, in which they have been developed, are


Table 6.1: List of lessons of WebHiob with categories and view technologies in which theyhave been developed

Lesson Category View technology

JSONP XSS XSS GWT and AngularJS

Spring MVC data submission tonon-editable fields

Parameter tampering Facelets

Spring MVC ModelView InjectionUnvalidated redirects andforwards

Facelets

EL injection Injection Facelets

JPQL injection Injection GWT

Session Timeout with periodic Ajaxrequest

Broken Authenticationand Session Management

Facelets

Automatic redirection to login pageafter session timeout


Facelets

RIA security with Cookie-Based Au-thentication


AngularJS

RIA security with Token-Based Au-thentication


AngularJS

On successful completion of each lesson a user will be able to test and secure

the web applications for the specified attack. To take advantage of the lesson, the

user should proceed the following steps steps:

1. Read the content of the lesson’s tab and try to find security problem and solution

on his own.

6.1. JSONP XSS 62

2. If the user will not be able to find the security problem, he should read the

content of the Security problem tab, perform the attack, localize each described

vulnerable code fragment in WebHiob, and ensure that he understands why

the attack is possible (if he was able to find the security problem on his own,

he should also read this content to ensure that he has understood everything

right).

3. If the user will not be able to find the solution how to protect WebHiob, he

should read the content of the Solution tab, protect WebHiob based on the read

solution and ensure that the attack is no more possible (if he was able to find

the solution on his own, he should also read this content to ensure that he has

done everything right).

The content of all tabs could also contain more generic description (not only directly

related to the technologies used by WebHiob), therefore anyway it is valuable to

read it. The WebHiob platform and all described in this chapter lessons are for

the educational purposes only. The user should not try to attempt the learnt

techniques on the Internet without the authorization, because it is against to the

law. To avoid repeating in each description of how to complete the lesson, the part

that the user should find the vulnerable code fragment and then protect WebHiob,

is omitted. The content of the lesson’s tab contains the introduction explaining

what the user should do in the specified lesson. These information are written

in this chapter by the way of the lesson description, therefore all screenshots of

WebHiob lessons contain only fragment of the lesson (ignoring the introduction).

6.1. JSONP XSS

JSON is a lightweight, text-based data-interchange format [53]. It is usually

used in the browser with AJAX requests. These requests allows to get data in an

asynchronous way, however web site can receive a response only if the destination

side has got the same origin as a requested side (Same-Origin Policy [84]). This

restriction was introduced to reduce the security risks e.g. to prevent a malicious

web site from reading sensitive data from the other web site [84].

There are two solutions to perform a cross-domain communication from the

browser. The newest one is to use Cross Origin Resource Sharing (CORS) – the

World Wide Web Consortium (W3C) specification that allows that [10]. To take

advantage of CORS, it is enough to add the Access-Control-Allow-Origin (ACAO)

header to the server response, where can be specified who should be able to

receive the response e.g. sever may response with an Access-Control-Allow-Origin:

6.1. JSONP XSS 63

http://www.foo.com header and only side with origin from http://www.foo.com

will be able to get a result (excepting the requests from the same origin). The URL

in the header, can be replaced with a wildcard (*), which means that everyone can

receive the data [84].

Not every server supports CORS. If it does not, the data could be loaded from

the server by the browser using the <script> tags such as all JS libraries (e.g.

<script type="text/javascript" src="//code.jquery.com/jquery-1.11.1.js"></script>).

This method has no security restriction and is used by a JSON with padding

(JSONP) technique. JSONP relies on dynamically adding a <script> tag using

JavaScript. JSONP requires a callback function. Server instead of returning a

typical JSON response e.g. {date:"17:11:36"}, returns a JSONP response, which is

a JSON response surrounded by a function name with the brackets and ended with

a semicolon e.g. callbackFun({date:"17:11:36"});. After loaded the response, the call-

backFun JS function is called by the browser. The JSONP request should have the

callback URL parameter e.g. http://example.com/data?callback=callbackFun [56].

In this lesson the user has got two buttons to get a JSONP response:

• prepared request - request to the WebHiob server with the following URL return-

ing the JSONP response with an XSS attack:

◦ for GWT – /facelets/jsonpGWT/insecure?callback=JSON_CALLBACK;

◦ for AngularJS – /facelets/jsonpAngular/insecure?callback=JSON_CALLBACK;

• custom request - request to any url to check JSONP XSS attack, however in

AngularJS version it is required to add the callback URL parameter with the

JSON_CALLBACK name (there is no need of adding this parameter in GWT

version if the name of its is callback).

The user will see the JSONP response below the buttons or error message in the

case of error. To complete this lesson the user should press the prepared request

button and see the results of the attack and response. Additionally the user can

test any other URL providing the JSONP XSS attack (e.g. from web pages teaching

about JSONP attacks). The UI of this lesson in AngularJS view technology is shown

in Figure 6.6 (version for the GWT view technology is very similar).

Figure 6.1: The UI fragment of the JSONP XSS lesson in AngularJS view technology

6.1. JSONP XSS 64

This lesson has been developed in two view technologies, which allows to notice,

that the response provided by the AngularJS binding mechanism, get rid of the

part, whose is not able to convert to the valid JSON data. The results are visible in

Figure 6.6. For comparison, the response for the same request in the GWT version

is as follows:

{"date":"09:04:49", "attack":null}

Security problem

Using the JSONP technique requires trust, that a data provider sends a valid

data without any malicious part. Unlike to CORS request, after receiving the

results, there is no way to validate a data, therefore an attacker can provide any

XSS attack. The method from WebHiob returning the malicious JSONP response is

shown in Listing 6.1 (from the JsonpXSSController class).

1 @RequestMapping(value = "/insecure")public String insecureJsonp(@RequestParam(value = "callback") String callback) {

return callback + "({date:\"09:04:49\", attack:alert(\"JSONP XSS\")});";}

Listing 6.1: The method from WebHiob returning the malicious JSONP response (fromthe JsonpXSSController class)

This method symbolises the method from the external server, which source

code is not public disclosed (thus there is no way to change this method). JSONP

response from this server is shown below:

CALLBACK({date:"09:04:49", attack:alert("JSONP XSS")});

Second part of the returned JSON (attack:alert("JSONP XSS")) will be interpreted

as a JavaScript command and executed. In this example the user will only see an

alert message, but attacker can provide much more complex XSS attack [55].

Solution

There is no way to provide a JSONP response data validation on the client side,

therefore the only solution to protect from JSONP XSS attack is to load the data

by own server, provide a validation and then send back the data to the browser. It

makes that the own server will be more loaded, but it provides the safety [55].

The proposed solution for this security problem is to make a typical JSON

request to the own server (with the same origin) with the callback parameter

and the URL parameter, whose value specifies where the user want to make a

cross-origin request. Server downloads the potentially malicious data and makes

a validation. However these data are not dangerous for the server, because it does

6.2. Spring MVC ModelView injection 65

not evaluate any JavaScript commands. After validation the server returns the safe

data as a JSONP response to the browser. The method performing these tasks is

shown in Listing 6.2.

1 @RequestMapping(value = "/secure")public String secureJsonp(@RequestParam(value = "url") String url,

@RequestParam(value = "callback") String callback) throws IOException {String secureJsonp;

5 URL insecureUrl = new URL(url + "?callback=" + callback);

try (InputStream inputStream = insecureUrl.openStream();BufferedReader in = new BufferedReader(new InputStreamReader(inputStream))) {

String jsonpResponse = "";10 String inputLine;

while ((inputLine = in.readLine()) != null) {jsonpResponse += inputLine;

}secureJsonp = Parser.jsonpToSafeJsonParser(jsonpResponse);

15 secureJsonp = callback + "(" + secureJsonp + ");";}return secureJsonp;

}

Listing 6.2: The method providing soultion for the JSONP XSS lesson

The jsonpToSafeJsonParser method of the Parser class (from Line 14 of Listing

6.2) uses the JsonSanitizer class from the OWASP JSON Sanitizer library provid-

ing a JSON validation [71]. The result of using the method from Listing 6.2 after

performing the same JSONP XSS attack, is shown below:

CALLBACK({"date":"09:04:49","attack":"alert","JSONP XSS":null});

The alert function and parameter have been divided and the brackets have been

removed, therefore the attack is no more possible.

6.2. Spring MVC ModelView injection

Spring MVC requires a view resolver to prepare a proper HTML response based

on the view file. Spring controller should provide a method that will be called based

on the request mapping. This function returns a view, which should be sent to the

browser (it can be a simple string with a view file name). To make that Spring can

resolve a proper view, it is needed to define a view resolver in a Spring configuration

file. There is no one view resolver prepared for Facelets by Spring, therefore the

WebHiob environment uses the basic one – UrlBasedViewResolver with a custom

view class providing a rendering the required response. UrlBasedViewResolver

adds two extra options to control the execution flow: redirect and forward, which

is shown in Listing 6.3 [107].


1 protected View createView(String viewName, Locale locale) throws Exception {...

// Check for special "redirect:" prefix.if (viewName.startsWith(REDIRECT_URL_PREFIX)) {

5 String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length());RedirectView view = new RedirectView(redirectUrl,

isRedirectContextRelative(),isRedirectHttp10Compatible());

return applyLifecycleMethods(viewName, view);10 }

// Check for special "forward:" prefix.if (viewName.startsWith(FORWARD_URL_PREFIX)) {

String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length());return new InternalResourceView(forwardUrl);

15 }...}

Listing 6.3: Fragment of the method responsible for creating a view based on namefrom the UrlBasedViewResolver class

In this lesson the user can see four players of one of three football’s team: FC

Barcelona, Juventus and Manchester United. After clicking on one of team’s name,

he will see that the request URL contains view parameter (which is used to resolve

a Facelets view).

To complete this lesson the user should change the URL to get the content of

the web.xml file under the WEB-INF directory, to which access is default disabled.

The UI of this lesson is shown in Figure 6.2.

Figure 6.2: The UI fragment of the Spring MVC ModelView Injection lesson

Security problem

Using UrlBasedViewResolver (or any of its subclasses) brings a potential se-

curity risk – it allows to bypass a security restriction and get access to files under

the WEB-INF directory, which should not be accessible directly be the user (the

good practice is to put files under the WEB-INF directory to hide them from direct

access [46]). Theses files should be accessible only indirectly – through the con-

troller, that decides, which files should view the user. If the application uses the


user’s data to directly resolve the view, the application is vulnerable to the Spring

MVC ModelView Injection attack [107]. The vulnerable method from WebHiob is

shown in Listing 6.4 (from the ModelViewInjectionController class).

1 @RequestMapping()public ModelAndView getPlayers(@RequestParam("view") String view,

@RequestParam(value = "team", defaultValue = "") String team) {ModelMap map = addPlayersToMapBasedOnTeamName(team);

5 return new ModelAndView(view, map);}

Listing 6.4: The method vulnerable to Spring MVC ModelView injection from theModelViewInjectionController class

If the user replaces the value of the view parameter as follows:

forward:/WEB-INF/web.xml (providing the following request:

http://localhost/facelets/model_view_injection?view=forward:/WEB-INF/web.xml),

he will see the web.xml file. This file contains the sensitive configuration of the

application e.g. if the application uses Spring Security and stores passwords in the

configuration file, then based on the web.xml file, the attacker can find out what is

the path to the security configuration file and after accessing it in the same way,

he can see all usernames and passwords.

Solution

To protect from Spring MVC ModelView Injection attack it is recommended to

never allow, that user’s input data are used directly to resolve any view [107]. If it

is required, that user has got an impact to resolving the view, then the user’s input

should be a number used by the server as a key in a map providing the proper

mapping (number to view name used by the view resolver). The protected method

and required variables with initialization are shown in Listing 6.5.

1 private final String DEFAULT_VIEW = "model_view_injection/index";private Map<Integer, String> viewMapping = new HashMap<>();

@PostConstruct5 public void init() {

viewMapping.put(1, DEFAULT_VIEW);}@RequestMapping()public ModelAndView getPlayers(@RequestParam("view") int view,

10 @RequestParam(value = "team", defaultValue = "") String team) {String viewName = viewMapping.get(view);if (viewName == null) {

viewName = DEFAULT_VIEW;14 }15 ModelMap map = addPlayersToMapBasedOnTeamName(team);

return new ModelAndView(viewName, map);}

Listing 6.5: Fragment of the controller protected from Spring MVC ModelView injection

6.3. Spring MVC data submission to non-editable fields 68

If the user tries again to make the same request to get the content of the web.xml

file, he will see the response with 400 code because of the syntactically incorrect

request (due to the unsuccessful casting the value of the view parameter to an

integer). If he tries to pass other view id than there is a value in the map, he will

get the default view due to Line 13 of Listing 6.5.

6.3. Spring MVC data submission to non-editable fields

Spring MVC provides an auto-binding feature, that causes, that the sent re-

quest’s parameters are automatically bound to the chosen object [107]. For this

lesson the WebHiob environment provides:

• a form with two inputs – allowing to post the new name and daily limit (shown

in Listing 6.7);

• the Account class – the class with properties with the same name as names of

inputs from the form (shown in Listing 6.6);

• the update method – the method receiving the request’s parameters from the

form (shown in Listing 6.8).

Instead of reading each request’s parameter separately and setting the value

to the object’s property, the auto-binding feature makes that automatically. To

take advantage of it, the method’s parameter has to have the @ModelAttribute

annotation in the request mapping function, what is shown in Line 2 of Listing 6.8.

This method belongs to the DataSubmissionToNonEditableFieldsController

class, that stores the Account object in the session).

1 public class Account {private String login;private String name;private int dailyLimit;

5 }

Listing 6.6: The Account class used to show the auto-binding feature of Spring MVC

1 <form action="#{request.contextPath}/facelets/data_submission_to_non_editable_fields/lesson"method="post">

<input type="text" name="name"/><input type="text" name="dailyLimit"/>

5 <button type="submit"/></form>

Listing 6.7: Form allowing to use the auto-binding feature of Spring MVC (to increasereadability all tags and attributes responsible for the appearance have been removed)

6.3. Spring MVC data submission to non-editable fields 69

1 @RequestMapping(method = RequestMethod.POST)public ModelAndView update(@ModelAttribute Account account) {

3 accountManager.update(account);String login = account.getLogin();

5 ModelMap map = new ModelMap();map.addAttribute(accountParameterName, accountRepository.find(login));map.addAttribute("confirmation", login + " account has been successfully edited");return new ModelAndView(viewName, map);

}

Listing 6.8: Method from DataSubmissionToNonEditableFieldsController classallowing to auto-bind parameters from request to properties of the Account object

In this lesson the user’s login is hacker. The login of another user is victim, her

name is Ela and her daily limit is 2000. To complete this lesson the user has to

change the daily limit of victim ’s account. The UI of this lesson is shown in Figure

6.3.

Figure 6.3: The UI fragment of the Spring MVC data submission to non-editable fields lesson

Security problem

WebHiob takes advantage of the auto-binding feature for the Account class as it

is shown in Listing 6.8. Instance of this class is stored in the session context, which

means that after calling the update method, the application will bind properties to

the already existing object. Based on Listing 6.7, it could be inferred, that only

two fields will be bound, (name and dailyLimit) leaving the login field untouched.

However if the attacker changes the body of the request (e.g. using Zed Attack

Proxy (ZAP) [76]) and adds the login field with some value e.g. login=victim, then

the auto-binding feature sets the new value also to the login field. In this way, the

attacker can change the daily limit of the victim’s account [107].

Solution

Spring MVC is prepared for this security issue and provides the following meth-

ods for the data binder: setAllowedFields and setDisallowedFields [107]. It is

always recommended to provide a white-list validation, however if only one field

should not be bound, then it is more convenient to use the setDisallowedFields

6.4. JPQL injection 70

method. In this lessons only the login filed should not be bound, therefore the

latter method is a good choice. The code providing the security is shown in Listing

6.9. It should be used in the DataSubmissionToNonEditableFieldsController

class.

1 @InitBinderpublic void initBinder(WebDataBinder binder) {

binder.setDisallowedFields("login");}

Listing 6.9: The method protecting the DataSubmissionToNonEditableFieldsControllercontroller from the Spring MVC data submission to non-editable fields vulnerability

6.4. JPQL injection

JPQL is a query language used in JPA. It is more detailed discussed in section

3.1.2. In this lesson a user can search the database to find information about the

employee, whose name is written in the search box, using two buttons:

• Search via JPQL – the query will be performed by JPQL;

• Search via SQL – the query will be performed by SQL provided by native JPA

query).

To complete this lesson the user should:

1. Get the city of one of existing employees (e.g. for Bob) using JPQL and SQL

queries;

2. Get all cities of all employees using JPQL Injection;

3. Get all passwords of all employees using SQL Injection.

This lesson allows to search the employee by name using the JPQL and SQL

queries, view the full query that has been performed and see the results of the

query in the table. The UI of this lesson is shown in Figure 6.6.

Figure 6.4: The UI fragment of the JPQL injection lesson

6.4. JPQL injection 71

Security problem

The function returning a list of employees based on the name parameter using

JPQL in WebHiob is shown in Listing 6.10 (from EmployeeRepositoryImpl class).

1 public List<Employee> getJPQLEmployeeByName(String nameParameter) {String q = "SELECT e FROM Employee e WHERE e.name = ’" + nameParameter + "’";TypedQuery<Employee> query = entityManager.createQuery(q, Employee.class);return query.getResultList();

5 }

Listing 6.10: Example of function returning a list of employees based on name param-eter using JPQL

Although JPQL looks very similar to SQL, it does not allow to perform the same

injections’ techniques. To see the difference, this lesson allows to make the same

query using JPQL and SQL provided by the JPA native query (respectively by the

Search via JPQL and Search via SQL buttons shown in Figure 6.6). The function

responsible for the SQL results in WebHiob is shown in Listing 6.11 (from the

EmployeeRepositoryImpl class).

1 public List<Employee> getSQLEmployeeByName(String nameParameter) {String q = "SELECT e.id, e.name, e.password, e.city FROM Employee e WHERE " +

"e.name= ’" + nameParameter + "’";Query nativeQuery = entityManager.createNativeQuery(q, Employee.class);

5 return nativeQuery.getResultList();}

Listing 6.11: Example of function returning list of employees based on name parameterusing native SQL

The user has got a text field, where he types a name parameter. If he enters

Jan, the JPQL query will return the details of Jan and it will look as follows:

SELECT e FROM Employee e WHERE e.name= ’Jan’

If he types: ’ or 1 = 1 or e.name = ’, the JPQL query will return all employees

(doing the same by SQL query is a bit easier – ’ or 1 = 1 - -’) and it will look as

follows:

SELECT e FROM Employee e WHERE e.name= ’’ or 1 = 1 or e.name = ’’

JPQL does not support comments and UNION keyword, thus it does not allow

to perform more sophisticated injection attacks. Example of injection using UNION

can be performed by entering in the field the following chars: ’ UNION SELECT

e1.id, concat(e1.name, ’ ’, e1.password ), e1.name, e1.name FROM Employee e1 - -,

which causes sending the query returning all employees’ passwords and looking as

follows:

6.5. EL injection 72

SELECT e.id, e.name, e.password , e.city FROM Employee e WHERE e.name= ’’UNION SELECT e1.id, concat(e1.name, ’ ’, e1.password ), e1.name, e1.name

FROM Employee e1 −−’

Solution

To protect from JPQL and SQL injections, the query has to be parametrized. It

means that instead of the direct use of the user’s input into the query, there should

be used a query parameter. The method secured from the JPQL injection is shown

in Listing 6.6.2 (version for the SQL query is analogous).

1 public List<Employee> getJPQLEmployeeByName(String nameParameter) {String q = "SELECT e FROM Employee e WHERE e.name = :name";TypedQuery<User> query = entityManager.createQuery(q, User.class);query.setParameter("name",nameParameter);

5 return query.getResultList();}

Listing 6.12: Protected from the JPQL injection version of the getJPQLEmployeeByNamemethod

6.5. EL injection

Expression Language (EL) allows the web pages to communicate with the man-

aged beans. EL is used by JSF and JSP technology [27,28]. Assume that there is

a JSP page containing the following code:

<spring:message code="${param.msg}" />

The Spring message tag provides the internationalization support [95]. The part

${param.msg} provides an access to the request parameter with the msg name. The

example of the controller’s method making use of this tag is shown in Listing 6.13.

1 @RequestMapping(value="/")String index() {

if ( hasErrors() ) {return "redirect:/error?msg=error.message";

5 } else {return "index";

}}

Listing 6.13: Example of the controller’s function making use of the Spring message tag

If there is an error while accessing the home page, the index method will return

to the browser the error page and set the msg parameter with the error.message

value, that will be translated into a message in a specified language [29].

6.5. EL injection 73

EL injection is not more possible since Spring Framework 4.0. Due to the many

applications that still use earlier versions and to do not make the same security

mistakes in new technologies, it is good to know about some typical historical

issues (Spring 4.0 was released in 12/2013, therefore it is not a very old-time

vulnerability [1]). To complete this lesson the user should figure out how to set

value of the admin session attribute to true using EL Injection, however he will not

be able to perform this attack in WebHiob.

Security problem

If the attacker sends the HTTP request with the following URL:

http://www.example.com/error?msg=${param.test}&test=INJECTION,

he will see the similar message as follows):

No message found under code ’INJECTION’ for locale ’en_US’.

This happens due to the double resolving an EL expression – user’s code is inter-

preted as an EL expression and evaluated (first resolving), then this new value is

passed to the message tag in the JSP page and evaluated (second resolving). This

example does not cause any security issue, however it explains the principle of

operation of EL injection. More dangerous example provides the request with the

following value of the msg parameter:

${pageContext.request.getSession().setAttribute("admin",true)}.

This request sets the session attribute about administration’s privileges to true,

which causes that if any other code anywhere checks this attribute and makes

a decision about sending sensitive data based on it, the attacker will receive the

data [29].

Solution

WebHiob uses the currently newest Spring version – 4.1.6.RELEASE, therefore

there is no way provide a lesson vulnerable to the EL injection attack, thus this

lesson is not interactive.

The Spring versions affected to EL injection attack include [30]:

• 3.0.0 to 3.0.5;

• 2.5.0 to 2.5.6.SEC02 (community releases);

• 2.5.0 to 2.5.7.SR01 (subscription customers);

• Earlier versions may be also affected.

To fix this security issue the Spring framework has introduced a new context

parameter – springJspExpressionSupport, which set to false disable the double

resolving issue [28–30]. However this parameter is only available in the following

versions [30]:

6.6. Session management 74

• 3.0.6 onwards;

• 2.5.6.SEC03 onwards (community releases);

• 2.5.7.SR02 (subscription customers).

For others versions it is recommended to provide an input validation to avoid

that user’s data will be interpreted as another EL expression [29].

6.6. Session management

Many pages requires login to see some information. These pages often provide

some information, which are constantly updated via a periodic Ajax request. As it is

written in chapter 2.2.1 in section Broken Authentication and Session Management,

a proper session management should provide a timeout, after which the session will

be no more valid. Usually the timeout is set on much bigger value than the period of

the Ajax request. Session Management, authentication and authorization are very

important and prone to errors processes. Thus it is not recommended to develop

theses mechanisms on one’s own, but use instead the well-tested framework e.g.

Spring Security. More on this framework is written in chapter 3.2.1.

6.6.1. Session Timeout with periodic Ajax request

Assume that the access should be protected from the unauthenticated users to

the resource under the following URLs:

• /facelets/session_timeout_with_periodic_ajax_request/lesson;

• /facelets/session_timeout_with_periodic_ajax_request/secret.

To achieve this, the Spring Security is used, whose configuration is shown in

Listing 6.14).

1 <http auto−config="true" use−expressions="true"><intercept−url pattern="/facelets/session_timeout_with_periodic_ajax_request/lesson"

access="isAuthenticated()"/><intercept−url pattern="/facelets/session_timeout_with_periodic_ajax_request/secret"

5 access="isAuthenticated()"/><form−login

login−page="/facelets/session_timeout_with_periodic_ajax_request/login"authentication−failure−url=

"/facelets/session_timeout_with_periodic_ajax_request/login?error=true" />10 <remember−me user−service−ref="userDetailsService"/>

</http>

Listing 6.14: The Spring Security configuration protecting the specified resources fromthe unauthenticated users


Additionally, the current server time is received by the periodically (every 500

ms) Ajax request. Session timeout is set to one minute by the session-timeout tag

in the web.xml configuration file.

To get to the lesson page, the user has to log on with the credentials given in

the login page. After the successful log in the user will see:

• the countdown timer set to one minute (equals to the session timeout);

• the Go to the secret page link (looking like a button) redirecting the to the secret

page, whose content should be visible only for the authenticated users;

• the analog clock, whose time is received from the server by the periodically (every

500 ms) Ajax request.

To complete this lesson the user should click on the Go to the secret page link

after one minute (after the session should expire) and view the content of the secret

page (during this time, the user should not click on anything). The UI of this lesson

is shown in Figure 6.6.

Figure 6.5: The UI fragment of the Session Timeout with periodic Ajax request lesson


Security problem

Leaving the Spring Security configuration from Listing 6.14 without any changes

will make, that the session will never expire. It could seem impossible, because

the session timeout is set to one minute. However to the server are coming the

requests every 500 ms (through Ajax). The default Spring’s filters do not make

any difference if the request is through Ajax or not. Therefore every 500 ms the

session is refreshed, which causes that finally the session will never expire. Thus

to complete this lesson the user does not have to do anything special – just click

on the link after one minute and view the secret page, which will be sent the the

browser, because the session will be still valid.

Solution

To solve this security problem, it is required to provide a custom filter (the filter

term is explained in section 3.2.1) by adding the custom-filter tag (with a reference

to the custom filter class) to the Spring Security configuration as a child of the

http tag (view Listing 6.14). The custom filter class proposed by WebHiob extends

GenericFilterBean and overrides the doFilter method. This overriding is shown

in Listing 6.15.

1 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)throws IOException, ServletException {

HttpServletRequest httpRequest = (HttpServletRequest) request;

5 if ( ! ClickUtils.isAjaxRequest(httpRequest)){chain.doFilter(new SessionAccessAwareRequest(httpRequest), response);

7 return;}boolean expired = false;

10 HttpSession session = httpRequest.getSession(false);11

if (session == null) {13 expired = true;

} else {15 Long lastAccessTime = (Long) session.getAttribute(

SessionAccessAwareRequest.LAST_ACCESS_SESSION_ATTR);if (lastAccessTime == null ||

lastAccessTime + SESSION_TIMEOUT_IN_MS < System.currentTimeMillis()) {19 session.invalidate();20 expired = true;

}}

if ( ! expired) {25 chain.doFilter(request, response);

}}

Listing 6.15: Overriding of the doFilter method providing the solution for the SessionTimeout with periodic Ajax request lesson


The custom filter divides the requests into two categories: Ajax and

non-Ajax requests. If a request is non-Ajax, the request is wrapped by the

SessionAccessAwareRequest, that extends HttpServletRequestWrapper (Line

6) and then the method ends. Thereby when the Spring Security filter tries to get

or create session for the non-Ajax request, the application will add (or update) the

LAST_ACCESS_SESSION_ATTR attribute telling about the last accessing time to

the session. Fragment of the SessionAccessAwareRequest class responsible for

adding this attribute is shown in Listing 6.16. If there is an Ajax request, the filter

will get the session (without creating one if there is no session – argument false at

line 10). If the session exists, the LAST_ACCESS_SESSION_ATTR parameter is read

and compared to the current time increased by the session timeout (lines 12-18).

If the session currently lasts more than timeout, it is invalidated (line 19). If the

session should not expire, the request and response are added to to chain of the

filter and then further performed by other filters, otherwise the expected response

will not be sent the to browser.

1 public HttpSession getSession(boolean create) {HttpSession session = super.getSession(create);

if (session != null) {5 session.setAttribute(LAST_ACCESS_SESSION_ATTR, System.currentTimeMillis());

}return session;

}

Listing 6.16: Fragment of the SessionAccessAwareRequest class showing how theLAST_ACCESS_ATTR parameter is added to the session

6.6.2. Automatic redirection to the login page after the session expires

Assume that there is a bank web page, where a user can view his private

information about his money transfers. The session timeout is set to one minute

and the configuration of the Spring Security framework looks very similar to the

one used in the Session Timeout with periodic Ajax request lesson (the url of the

protected resource and to the login page have been changed).

In this lesson the user will see his money transfer history and the countdown

timer set to one minute, which equals the session timeout, To complete this lesson,

the user has to wait one minute till the session expires and notice, that he will not

be redirected to the other page, that makes his private information still visible. The

UI of this lesson is shown in Figure 6.6.


Figure 6.6: The UI fragment of the Automatic redirection to the login page after the sessionexpires lesson

Security problem

Assume that one day the user forgets to log out from the bank’s web page. After

the session expires, there is no way to make a new request and get a valid response,

because after a new request the Spring Security filter redirects to the login page.

However without sending any new requests the information on the page will be still

visible, which can cause, that someone unauthorized will see them.

Solution

To solve this security problem, it is required to provide an automatic redirection

to the login page after the session expires. The server cannot send any notification

to the browser without being requested. Therefore to provide the automatic redi-

rection, the browser has to periodically ask the server (via Ajax requests) and react

on its responses.

It is again required to provide a custom filter for the Spring Security configu-

ration. This time, the filter will look almost the same as in Listing 6.15. The only

difference is the condition at the end of the doFilter method. The following condition

from Listing 6.15:

if (!expired) {chain.doFilter(request, response);

}

has to be extended with the else part:

else {int sessionExpiredCode = 901;HttpServletResponse httpResponse = (HttpServletResponse) response;httpResponse.sendError(sessionExpiredCode);

5 }

6.7. Authentication and authorization in Rich Internet Application 79

In this way, when the session expires, the 901 error code is sent to the browser.

It could be any code, however it have been chosen the 901 number to distinguish it

from the HTTP codes. The function responsible for sending the periodically (every

second) requests from the browser is shown in Listing 6.17. This function reacts

on the response’s status code and if it equals 901, the function redirects to the

login page, which is shown in Lines 7-12.

1 setInterval( function() {$.ajax({

type: ’GET’,url: "/facelets/automatic_redirection_after_session_timeout/time",

5 dataType: "json",success: function (data) {},statusCode: {

8 901: function(response) {window.location.replace

10 ("/facelets/lesson/automatic_redirection_after_session_timeout");}

}13 });

}, 1000);

Listing 6.17: Function responsible for sending a periodically request from the browserand redirecting to the login page the after the session expires

6.7. Authentication and authorization in Rich Internet Application

Rich Internet Application (RIA) uses a dynamic one-screen-application inter-

face (commonly used in desktop applications). Authentication and authorization

provided by Spring Security framework ideally fit to the typical multi-pages web

application, due to the possibility to easy redirect to the login page. However it

does not mean, that this framework is useless in RIA application, which is proved

by the lessons from this section.

6.7.1. Rich Internet Application security with cookie-based authentication

In this lesson there are two tabs:

• public – containing the not protected message, that is available under the

request to the /facelets/riaCookie/public URL;

• secret – containing the secret message, that is available under the request to the

/facelets/riaCookie/secret URL (the content is visible only for the authenticated

users).

If an unauthenticated users click on the secret tab, he will see the empty content

instead of the secret message, due to using the Spring Security configuration, that


is shown in Listing 6.18. Please be aware, that protected is only the message from

the server (not the entire content of the tab).

1 <http auto−config="true" use−expressions="true"><intercept−url pattern="/facelets/riaCookie/secret" access="isAuthenticated()"/><remember−me user−service−ref="userDetailsService"/>

</http>

Listing 6.18: Spring Security configuration from the RIA security with Cookie-BasedAuthentication lesson

To complete the lesson, the user has to provide, that after clicking on the

secret tab, an unauthenticated person will see the login page (available under the

/angularjs/#/RIASecurityCookieBased/lesson/loginTab URL) instead of the empty

content. The UI of this lesson is shown in Figure 6.7.

Figure 6.7: The UI fragment of the Automatic redirection to the login page after the sessionexpires lesson

Security problem

The Spring Security configuration from Listing 6.18 uses the cookie-based au-

thentication (more on this approach in section 3.2.2). RIA communicates with the

server using Ajax requests to avoid multiple re-downloading the whole pages. After

sending the request as an unauthenticated user, the Spring Security sends a redi-

rect response with the 302 HTTP code and URL to the login page. With non-Ajax

requests, the browser automatically redirects to the given page. After sending an

Ajax request through the function from the AngularJS or jQuery library, the re-

sponse HTTP code will be 200 and the received data will be the HTML source code

of the current page [39]. It means that without a special effort, the user will not

see the login page.

Solution

The simplest way to solve this problem could be using the same approach as

introduced in the solution of the Automatic redirect to the login page after session

expires lesson (6.6.2). However if the application has got many places requiring the

access to the secured content, it will be very inconvenient to handle the codes

of the responses in all places. However the AngularJS framework provides a


solution to this problem – an interceptor, that allows to the global errors handling,

pre-processing of requests or postprocessing of responses [6].

The default Spring Security configuration uses the stateful (cookie-based) ap-

proach. All requests from AngularJS are through Ajax, therefore there is no need

to distinguish between kinds of the requests. It allows to use a simpler approach

than shown in the solution of the Automatic redirection to the login page after the

session expires lesson – there is no need to use a filter. To solve this lesson, the

function sending the Ajax request and receiving the response has to recognize if the

response code means redirection. It is not possible to handle the HTTP redirect code

(302) through JavaScript from the browser, however it is enough to change the re-

sponse code sending by the Spring Security filter, when there is a problem with the

authentication. It could be done using a filter, but also by adding the entry-point-ref

attribute to the http tag in the Spring Security configuration. The value of this at-

tribute has to point to the class implementing the AuthenticationEntryPoint in-

terface. This interface contains only one method (commence), which is called when

an authentication exception is detected. Proposed implementation of this method

making that the custom error code will be sent, has got the following one-line body:

response.sendError(901);

The main AngularJS file of WebHiob (\src\main\webapp\angularjs\js\main.js)

requires adding an interceptor, that redirects to the login page in the case of the

authentication error (901). Proposed implementation of the interceptor is shown in

Listing 6.19. The code checks the response status and redirects to the login page

(line 5) if the server responses with the 901 code (line 6).

1 $httpProvider.interceptors.push(function ($q, $rootScope, $location) {return {’responseError’: function (rejection) {

var status = rejection.status;5 if (status == 901) {6 $location.path("/RIASecurityCookieBased/loginTab");7 }

return $q.reject(rejection);}

10 };});

Listing 6.19: AngularJS interceptor providing the redirection to the login page in thecase of an authentication error

After providing the described above solution for this lesson and clicking on the

secret tab as an unauthenticated user, the user should see the login page as it is

shown in Figure 6.8.


Figure 6.8: The UI fragment of the Automatic redirection to the login page after the sessionexpires lesson after providing the described solution

6.7.2. Rich Internet Application security with token-based authentication

The idea of this lesson is similar to the Rich Internet Application security with

cookie-based authentication. In this lesson there is one more tab – Administrator

tab containing the message from server only for a person with the administrator

role. There is already prepared Spring Security configuration file looking similar

to the 6.18 (with different url patterns). To complete this lesson, the user has

to provide the same functionality as in the previous lesson, but this time, the

authentication should be token-based (more on this approach in section 3.2.2) and

the authorization should be taken into account (access to the Administrator tab

only for the user with the specified role).

Security problem

The security problem is the same as in the Rich Internet Application security

with cookie-based authentication lesson. The additionally problem, that this lesson

tries to solve it to prepare the server side for the scalability in the future. To

make it possible, one of the task, that should be done is to provide a stateless

authentication.

Solution

The Spring Security configuration providing the stateless authentication is

shown in Listing 6.20. The auto-config="true" attribute used in all previous lessons

is removed, because this solution uses the custom authentication (default value is

false). The create-session="stateless" attribute provides that Spring Security filter

will not create any session and will not use the session even if it is already created.

In all of the previous lessons using Spring Security, the access to the resources

was based only on the authentication (the role of the person has not been taken

into account). The configuration from Listing 6.20 provides, that the access to the

resource under the /api/riaToken/secret URL have got only authenticated users


(Line 7), but to the resource under the /api/riaToken/admin URL – only users with

the ADMIN role (Line 8). The value of the entry-point-ref attribute points to the

implementation of the AuthenticationEntryPoint interface to provide a custom

error code (403 in this solution) in the case of authentication or authorization error

(the same mechanism as in the solution of the Rich Internet Application security

with token-based authentication lesson).

1 <http pattern="/facelets/riaToken/∗∗"use−expressions="true"create−session="stateless"

4 entry−point−ref="unauthorizedTokenEntryPoint"5 authentication−manager−ref="authenticationManager">

<custom−filter ref="authenticationTokenProcessingFilter" position="FORM_LOGIN_FILTER"/>7 <intercept−url pattern="/facelets/riaToken/secret" access="isAuthenticated()"/>8 <intercept−url pattern="/facelets/riaToken/admin" access="hasRole(’ROLE_ADMIN’)"/>9 </http>

Listing 6.20: Stateless Spring Security configuration proposed as solution of the RIAsecurity with Token-Based Authentication lesson

Token-based authentication is introduced in section 3.2.2. To provide a token,

there are some libraries implementing the standard of JSON Web Token (JWT).

JWT is a relatively new token format which allows to transfer a message encoded

as a JSON object, that is digitally signed using JSON Web Signature (JWS) [9,

54]. In some libraries implementing JWT have been found some vulnerabilities

allowing attackers to bypass the verification step [12]. Because of that and to better

understand how the token-based authentication works, this solution explains the

custom implementation of the token. Additionally this approach has got a better

didactic value then using a library.

Listing 6.21 contains the most important methods of the TokenUtils class, that

are responsible for the token creation and validation. The custom token format is

the following: username:expiration_time:signature. The createToken method creates

the token based on the username and passwords (from the UserDetails interface).

The computeSignature method calculates the digest (using the Message-Digest al-

gorithm 5 (MD5) function) based on the user details, expiration time and secret

key [99]. The validateToken method validates the token, which contains the follow-

ing steps:

1. Splitting the received string based on the : separator;

2. Checking if the expiration time is greater than the current time and if it is, than

calculating the signature using the same methods as to create token’s signature.

3. Returning the result of the comparison of the calculated and received signatures

or returning false, if the expiration time is less than the current time.


The username and expiration time from the token are very easy to forge, however

it will not cause any danger, because of the necessity that, the received and

calculated signatures must be in accordance. The signature is not easy to forge,

because to calculate it, the MD5 digest and secret key have been used.

1 public static String createToken(UserDetails userDetails) {long expiresTime = calculateExpirationTime();String token = userDetails.getUsername() + SEPARATOR +

expiresTime + SEPARATOR +5 TokenUtils.computeSignature(userDetails, expiresTime);

return token;}

private static String computeSignature(UserDetails userDetails, long expires) {10 MessageDigest messageDigest = getMD5Digest();

String signature = userDetails.getUsername() + SEPARATOR +expires + SEPARATOR +userDetails.getPassword() + SEPARATOR +TokenUtils.SECRET_KEY;

15 byte[] signatureInBytes = signature.getBytes();byte[] digest = messageDigest.digest(signatureInBytes);return new String(Hex.encode(digest));

}

20 public static boolean validateToken(String authToken, UserDetails userDetails) {boolean valid = false;String[] parts = authToken.split(SEPARATOR);long expires = Long.parseLong(parts[1]);String signature = parts[2];

25

if (expires >= System.currentTimeMillis()) {valid = signature.equals(TokenUtils.computeSignature(userDetails, expires));

}return valid;

30 }

Listing 6.21: The most important methods of class TokenUtils responsible for creationand validation the token

This lesson requires a custom filter to provide a proper authentication and

authorization based on the token. Proposed implementation of the doFilter method

is shown in Listing 6.22. The method reads the token from the request header (line

4) and takes the username from the token (line 5). The username allows the get

user details and validate the token (lines 8-9). If the token is valid, the filter adds

the user’s authorities to the context of this request. Other filters will check the

user’s authorities and will deny or will grant the access to the requested resource.

If token is not valid, the authentication details will not be set and other filters will

deny the access.

Token can be stored in the local storage in the browser (feature of HTML5),

which means that is not automatically sent by the browser such as cookies. This is

safer solution, because it make impossible the CSRF attack, however it causes,


that this token must be added in each request on one’s own. The AngularJS

requests interceptor can simplify this task modifying the request before sending.

Proposed implementation of this interceptor adding the X-Auth-Token header with

the token as a value is shown in Listing 6.23. At the end, the user should create the

response interceptor to provide a redirection to the login page in case of the 403

response code (similar as in the solution of the Rich Internet Application security

with token-based authentication lesson).

1 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)throws IOException, ServletException {

HttpServletRequest httpRequest = (HttpServletRequest) request;String authToken = httpRequest.getHeader("X−Auth−Token");

5 String userName = TokenUtils.getUserNameFromToken(authToken);6

if (userName != null) {UserDetails userDetails = userDetailsService.loadUserByUsername(userName);

9 if (TokenUtils.validateToken(authToken, userDetails)) {10 Collection<? extends GrantedAuthority> authorities = userDetails.getAuthorities();

UsernamePasswordAuthenticationToken authentication =new UsernamePasswordAuthenticationToken(userDetails, null, authorities);

authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(httpRequest));SecurityContextHolder.getContext().setAuthentication(authentication);

15 }}chain.doFilter(request, response);

}

Listing 6.22: Example of the controller’s function making use of Spring message tag

1 $httpProvider.interceptors.push(function ($q, $rootScope, $location, $window) {return {’request’: function (config) {

var authToken = $window.localStorage.token;5 if (authToken != "undefined") {

config.headers[’X-Auth-Token’] = authToken;}return config || $q.when(config);

}10 };

});

Listing 6.23: Requests interceptor in AngularJS adding the X-Auth-Token header withtoken as a value before sending

7. Project of the environment

WebHiob is developed mainly in Java. It uses the Spring Web MVC framework

and JPA technology. WebHiob allows to develop a new lesson in one of three view

technologies: Facelets, AngularJS and GWT. It provides ten lessons that have been

developed in theses technologies. While running WebHiob the user’s machine will

be vulnerable to attack, therefore the user should disconnect from the Internet

while using the environment.

7.1. Functional and non-functional requirements

This chapter contains functional and non-functional requirements of imple-

mented WebHiob. Most of them are taken from section 4.3 (presenting features

of the desired environment).

Functional requirements

WebHiob provides many functional features from the 4.3 section. The imple-

mented functional features are converted to the requirements directly related to

WebHiob:

1. Application should display all lessons in tree view with the category as a node

and the lessons in the specified category as children.

2. Lessons inside each category and all categories should be displayed in the

alphabetical order (except of the Introduction category that should be displayed

first).

3. After double clicking on lesson category in the Facelets and AngularJS view

technology and single clicking in GWT, the application should expand the list of

lessons belonging to the clicked category.

4. After clicking on chosen lesson (even from different view technology) the appli-

cation should highlight a proper lesson in the tree and expand the category, to

which belongs this lessons.

5. Each name of the lesson displayed in the tree should end with the name of the

view technology, in which the lesson has been prepared, in the brackets.

6. Each lesson should contain three tabs with a relevant content: lesson, security

problem and solution.

7.2. Architecture 87

7. After clicking on each lesson’s tab, the content associated with the tab should

be displayed.

8. Application should provide the Introduction category with three lessons: About

WebHiob, Adding A Lesson, and Working with WebHiob.

9. The About WebHiob lesson should be the default web page.

Non-functional requirements

WebHiob provides the most non-functional features from section 4.3. The ex-

ception include the fact, that the source code of the current version of WebHiob is

not available on any public repository. WebHiob provides only source distribution

version requiring a web server and servlet container (recommended Tomcat 7 or 8)

to run. There is no standalone version in executable file, because the way of learn-

ing from WebHiob relies on analysing and changing the source code by the user

and checking how each change impacts on the web application security. Working

with the source code should bring more benefits and it requires different activities

than only reading a solution. WebHiob in the current version does not support the

internationalization (it uses English).

7.2. Architecture

The sever side of WebHiob is developed in MVC architecture using the front

controller design pattern (discussed in section 3.1.4). It is reached by Spring

framework and its Web MVC part. WebHiob provides an initialization method (in

the InitClass class), which is called once after the starting of the application. The

afterPropertiesSet method from this class scans all classes representing the lessons

(implementing Lesson interface) located in the com.webhiob.shared.lessons.lesson

package. Next, this method creates the instances of the found classes representing

lessons and adds them to the list of lessons. To simplify adding a new lesson, there

is prepared the AbstractLesson class, which implements two methods:

• getName – returning the name of the class with spaces between words in the

CamelCase notation e.g. for the JQPLInjection class, the method returns JPQL

Injection;

• getViewName – returning the name of the class.

Next facilitations in adding a lesson are classes AngularJSLessonAdapter,

GWTLessonAdapter and FaceletLessonAdapter providing the implementation

for getTechnology and getUrl methods depending on view technology. It means

that to add custom class representing lesson it is enough to extend one of this


adapter and implement only one method – getCategory (as it does the classes

JQPLInjection and ELInjection shown in Figure 7.1). However there is always

possibility to change the inherited method by overriding it (as it does the class

RIASecurityCookieBased shown in Figure 7.1). The class hierarchy of the classes

mentioned above is shown in Figure 7.1. LessonCategory and LessonTechnology

are enum, which means that to extend WebHiob with new category/technology it is

required to provide a new value for the enum.

URL to each lesson contains a specific beginning depending on the view tech-

nology. These dependencies are shown in Table 7.1. It is recommended to follow

this convention while extending the WebHiob environment.

Table 7.1: Dependencies of view technology for lesson’s URL address used in WebHiob

View technology URL to lesson

Facelets http://localhost:<port>/facelets/lesson/<lesson_view_name>

AngularJS http://localhost:<port>/angularjs/#/<lesson_view_name>/lesson

GWT http://localhost:<port>/GWT/index.html#/<lesson_view_name>

Figure 7.1: Class diagram of classes implementing Lesson interface


7.2.1. Directory structure

Directory structure of WebHiob has been designed keeping certain conventions

allowing to quickly find any file. The directories in the src directory include:

• main/java – java files;

• main/resources – configuration files;

• main/webapp – web application files such as (X)HTML, JavaScript, CSS;

• test/java – automated tests.

Contents of the main/java and main/webapp directory are divided into four

packages/directories:

• angularjs – files directly related to the AngularJS view technology;

• Facelets – files directly related to Facelets view technology;

• GWT – files directly related to GWT view technology;

• shared – shared files for all technologies containing e.g. security filters (in the

java directory) or JavaScript and CSS files (in the webapp directory).

All Spring controllers directly related to the lessons there are in the lesson-

controller package, which is in the package, whose name is connected with the

specified view technology.

7.2.2. Resolving the view

All technologies use the tree view to show the lessons organized into the cat-

egories. GWT uses the widget provided by this technology, however Facelets and

AngularJS use the jsTree plugin1. All technologies retrieve the list of the lessons

through AJAX request in the JSON format. jsTree requires the specified data for-

mat, therefore to provide the cohesion among all view technologies, GWT also uses

this format. Fragment of JSON used in WebHiob is shown in Listing 7.1. Having

this data each view technology finds the view in a different way. The meaning of

the fields is the following:

• id – URL to the lesson;

• text – the name shown in the tree view;

• name – name used as a lesson title;

• viewName – name used to find view file connected with lesson;

• technology – view technology in which the lesson has been developed;

• category – category to which belongs the lesson.

1 jsTree – open source jQuery plugin providing the interactive tree view for web browsers [57].


1 [{

"text": "Unvalidated Redirects And Forwards","category" :"UnvalidatedRedirectsAndForwards",

5 "children": [{

"id": "/facelets/lesson/model_view_injection","text": "Spring MVC ModelView Injection (Facelets)","name": "Spring MVC ModelView Injection",

10 "viewName": "model_view_injection","technology": "Facelet"

},{

/∗ next lesson ∗/15 }

]},{

/∗ next category with lessons ∗/20 }

]

Listing 7.1: Fragment of JSON response containing the lessons list

Facelets

The Facelets view technology uses the server side view resolver to find the

view file based on the lesson view name from URL, that is name after last slash

in the URL (e.g. for the /facelets/lesson/model_view_injection URL, the lesson

view name is model_view_injection). Spring does not support the Facelets view

technology by default, therefore it has been used the UrlBasedViewResolver class

with the custom view class (FaceletsView), which supports Facelets as a view.

LessonController (Spring controller) uses the lesson view name from the URL to

find the lesson, which will be used by the view resolver to prepare the HTML page.

Main view (\src\main\webapp\facelets\index.xhtml) is a template, which uses a

JSF bean to provide the lesson name and paths to the security problem description

and solution HTML pages. LessonController initializes this bean with the proper

values for the specified lesson.

AngularJS

AnuglarJS uses its extension – angular-route-segment to provide the tree-like

nested view and advanced flow handling [4]. It makes easier to develop the web

pages with many tabs and tabs inside each tab (Webhiob takes advantage of this

feature in the session management lessons developed in AngularJS). This extension

is also used to resolve a view based on the lesson view name, which is a name after

first slash after hash (#) in URL (e.g. for the /angularjs/#/JsonpXSS/lesson URL,

the view name is JsonpXSS). Based on the view name, WebHiob provides a name of


the lesson controller and paths to security problem description and solution HTML

pages. Main AngularJS controller (\src\main\webapp\angularjs\js\main.js) ini-

tializes the jsTree view and takes care of displaying the correct name of the lessons

above the lesson tab.

GWT

WebHiob finds a proper lesson class in GWT view technology using the lesson

view name from URL, which is a name after the hash (#) in the URL (e.g. for the

/GWT/index.html#JPQLInjection URL, the lesson view name is JPQLInjection). To

display a proper lesson, WebHiob has to create a classes representing lessons’ UI.

GWT uses the view name to create an instance of the proper class. WebHiob uses

only client side GWT. WebHiob gets all lessons through AJAX request and then

builds the Tree view. The LessonsComposite class provides the view template.

The LessonTabPanel class takes care of providing displaying a proper lesson name

and tabs containing the proper content of the lesson and the security problem de-

scription and solution HTML pages. Based on the view name from JSON response,

different lesson class is used to display in the lesson tab.

7.2.3. Used tools

Developing WebHiob there were used many tools, technologies and libraries. The

external applications used in development include:

• IntelliJ IDEA 14.1.3 – intelligent Java IDE for enterprise, mobile and web devel-

opment [45] (main tool used to develop WebHiob);

• IBM Rational Software Architect 9.1.1 – integrated designing and programming

platform simplifying the architecture modelling [43] (used to create the class

diagram 7.1);

• Zed Attack Proxy – tool allowing to intercept HTTP requests and responses [76]

(used in debugging the Spring MVC data submission to non-editable fields lesson

6.3);

• Gradle 2.3 – enterprise build automation system [31] (used to build WebHiob);

• Tomcat 8.0.23 – web server and servlet container [104] (used as a server where

WebHiob is deployed);

• HSQLDB 2.3.2 – relation database used as the IMDB [41] (used to provide a

database for the JPQL injection lesson 6.4).

The Java frameworks/libraries used in WebHiob include:

• Hibernate 4.3.8.Final – implementation of JPA [36] (used to provide the JQPL

and SQL queries for the JPQL injection lesson 6.4);


• Spring (with Web MVC part) 4.1.4.RELEASE – framework for web application

development [94] (used to provide the modern web server side with the MVC

architecture);

• Spring Security 3.2.5.RELEASE – framework providing authentication and au-

thorization [97] (used to provide the lessons in the Broken Authentication and

Session Management category);

• JUnit 4.12 – framework to write automated tests [58] (used to provide the unit

and integration tests);

• OWASP JSON Sanitizer – library providing a valid JSON [71] (used to provide a

secure JSONP response in the solution of the JSONP XSS lesson 6.1)

• JSF 2.2.11 – Oracle’s implementation of the JSF 2.2 Specification [69] (used to

provide the lessons in the Facelets view technology);

• GWT 2.7.0 [32] – framework to build RIA in Java language, whose client side is

compiled to JavaScript (used to provide the lessons in the GWT view technology).

The JavaScript libraries used in WebHiob include:

• AngularJS 1.3.14 [5] (used to provide the lessons in the AngularJS view tech-

nology) and its extension – angular-route-segment 1.4.0 [4] (used to provide a

nested views for the Broken Authentication and Session Management lessons

developed in the AngularJS view technology);

• jQuery 2.1.4 (feature-rich JavaScript library [52] used in lessons developed in

the Facelets view technology) and its plugins:

◦ jsTree 3.1.1 – plugin providing the interactive trees [57] (used to provide the

lessons tree view for the AngularJS and Facelets view technologies);

◦ countdown 2.1.0 – plugin to render the countdowns [11] (used to provide a

session countdown for the Broken Authentication and Session Management

lessons in the Facelets view technology);

• Bootstrap 3.3.4 – the most popular HTML, CSS, and JS framework for develop-

ing the responsive and mobile first web projects [8] (used to provide a layout for

the AngularJS and Facelets view technologies);

• highlight.js 8.6 – code syntax highlighter [37] (used to provide a proper syntax

highlighting for the code displayed in WebHiob);

• Old School Clock – clock used in the Session Timeout with periodic Ajax request

lesson [68].

7.3. Adding a new lesson 93

7.3. Adding a new lesson

Adding a new lesson follows the convention over configuration principles. It

means that if the rules are followed, then the lesson will be automatically config-

ured. It makes the adding the new lesson very easy. To add a lesson, the designer

should create at least the four files:

1. Class representing the lesson.

2. View file for the lesson.

3. HTML file for the security problem description.

4. HTML file solution description.

Adding a class representing a lesson

To add a class representing a lesson, the designer has to create a class im-

plementing the Lesson interface and provide the implementation for all meth-

ods. However it is recommended to extend one of already prepared adapters

for each view technology – classes AngularJSLessonAdapter, GWTLessonAdapter

and FaceletLessonAdapter. To provide a new category it is enough to create a

new value in the LessonCategory enum.

Adding view files for the lesson

Depending on the view technology, the designer should provide some different

view files and put them into the different directories. The architecture of WebHiob

takes care of adding the name of the lesson (the value returned by the getName

method from class representing the lesson) for each view technology.

For each technology, the designer should create the directory with the same

name as the value returned by the getViewName method from the class represent-

ing the lesson. Inside this directory should be the file with the index name and html

for AngularJS or xhtml extension for Facelets (no lesson view files for GWT inside

this directory). For GWT the designer should create a Java class with the name

created with the rule described above, however in the different directory. Paths

where to put the view files depending on the view technologies for the lesson with

the ExampleLesson view name are shown in Table 7.2.

Table 7.2: File paths for views depending on technologies used in WebHiob

View technology File path

AngularJS \src\main\webapp\angularjs\lesson\ExampleLesson\index.html

Facelets \src\main\webapp\Facelets\lesson\ExampleLesson\index.xhtml

GWT \src\main\java\com\webhiob\GWT\lesson\ExampleLesson.java

\src\main\java\com\webhiob\GWT\lesson\ExampleLesson.ui.xml


AngularJS

To create a view in this technology the designer should provide the following

files:

1. the AngularJS controller.

2. the index.html file.

The AngularJS controller has to have the name starting with the view name of

the class representing lesson and ending with Controller. Designer can put new

controller in the already existing \src\main\webapp\angularjs\js\app.js file or

he can create a new file (\src\main\webapp\angularjs\js\controller is the rec-

ommended path for the new file), however then designer has to add an addi-

tional script tag with reference to this file in the end of the head tag in the

\src\main\webapp\angularjs\index.html file. Example of an empty controller for

the lesson with the ExampleLesson view name is shown below:

app.controller(’ExampleLessonController’, function () { /∗ body of controller ∗/ }

The lesson file (index.html) has to provide the div tag with the ng-controller

directive. Example of an empty lesson file is shown below:

<div ng−controller="ExampleLessonController"> <!−− lesson UI here −−> </div>

Facelets

To create a view for this technology it is enough to create the index.xhtml file

with the content shown in Listing 7.2.

1 <?xml version="1.0" encoding="UTF−8"?><!DOCTYPE html PUBLIC "−//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1−transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"

5 xmlns:ui="http://java.sun.com/jsf/facelets">

<ui:composition template="../../index.xhtml"><ui:define name="content">

<!−− lesson UI here −−>10 </ui:define>

</ui:composition></html>

Listing 7.2: Example of the index.xhtml file with an empty lesson

GWT

To create a view in GWT the designer should provide the following files:

1. XML file representing the GWT UI.

2. Java class extending the Composite class, implementing the GWTLesson inter-

face and associated with the XML file.


XML file (ExampleLesson.ui.xml) should have content shown in Listing 7.3.

1 <ui:UiBinder xmlns:ui=’urn:ui:com.google.gwt.uibinder’xmlns:g="urn:import:com.google.gwt.user.client.ui">

<g:VerticalPanel>

5 <!−− lesson UI here −−>

</g:VerticalPanel></ui:UiBinder>

Listing 7.3: Example of ExampleLesson.ui.xml file with empty lesson

Java class associated with this XML file should have the content shown in

Listing 7.4.

1 public class ExampleLesson extends Composite implements GWTLesson {

interface ExampleLessonUiBinder extends UiBinder<Widget, ExampleLesson> {}

5 private static ExampleLessonUiBinder uiBinder = GWT.create(ExampleLessonUiBinder.class);

public ExampleLesson() {initWidget(uiBinder.createAndBindUi(this));

10 /∗ lesson content ∗/}

}

Listing 7.4: Example of the ExampleLesson class (associated with the ExampleLes-son.ui.xml file) with an empty lesson

HTML files for the security problem description and solution

For each technology the designer should provide the HTML files for the security

problem (security.html) and solution (solution.html) with the names and extensions

given in the brackets. These files can contain only the content of the typical body

tag, which means that the simple example of the whole solution.html file could be

the following:

<div> here is solution </div>

To take advantage of the code syntax highlighter in the GWT view technology it

is required to provide an HTML page with the following content:

<html><head>

<link rel="stylesheet" href="../../../shared/highlight/styles/default.css"/><script src="../../../shared/highlight/highlight.pack.js"></script>

5 <script>hljs.initHighlightingOnLoad();</script></head><body>

<!−− security problem description or solution −−></body>

10 </html>

7.4. Environment testing 96

Paths where to put these files depending on the view technologies for the lesson

with the ExampleLesson view name are shown in Table 7.3.

Table 7.3: Paths where to put the solution.html and problem.html files depending on theview technologies

View technology Path where to put solution.html and problem.html

AngularJS \src\main\webapp\angularjs\lesson\ExampleLesson\

Facelets \src\main\webapp\facelet\lesson\ExampleLesson\

GWT \src\main\webapp\GWT\lesson\ExampleLesson\

7.4. Environment testing

Code testing is very important issue. WebHiob was tested using the automated

and manual tests. Additionally because of the fact, that the application is a

learning environment, it was tested by the others students in the context of the

reasonableness of the prepared lessons. All tests have used the IntelliJ IDEA 14.1

to run the WebHiob environment.

Automated testing

WebHiob provides six automated tests developed using the JUnit library. Two of

them (from NameParserTest class) belong to the unit tests and the others belong to

the integration tests, because they require loading the Spring application context.

WebHiob contains three classes providing automated tests:

• NameParserTest – unit test of the correctness of the getWordsFromCamelCase-

Name method inside the NameParser class containing two tests methods:

◦ testCorrectnessOfParserForSimpleCamelCaseName – testing if the method re-

turns the correct words for a simple CamelCase name (AutomaticAjaxRedi-

rectAfterSessionTimeout);

◦ testCorrectnessOfParserForNameWithAcronym – testing if the method returns

correct words for the CamelCase name with an acronym (RIASecurity);

• AuthorizationTest – integration test of the authorization process containing

two tests methods:

◦ testValidRole – testing if the user with expected role has got access to the

protected resource;

◦ testInvalidRole – testing if the user without expected role has got access to

the protected resource;

• CommunicationTest – integration test of the communication with server con-

taining two tests methods:

7.4. Environment testing 97

◦ testGetAllLessonsResponseCodeOk – testing if the request of all lessons re-

turns the HTTP code 200;

◦ testPublicTabResponseContent – testing if the request of the public tab in RIA

security with Cookie-Based Authentication lesson returns expected content.

Manual testing

The majority of testing was based on manual testing checking the whole func-

tionality. The manual tests have been performed using the Goggle Chrome 43.0

browser while the WebHiob environment was running on the Tomcat 8.0.23 web

server. The tests consisted of checking the operation:

• related to single lesson:

◦ displaying the proper name of the lesson;

◦ the proper content for all tabs in the lesson (e.g. if the solution tab loads the

proper soluton.html file);

◦ the correctness of the lesson’s introduction, security problem and solution

descriptions (e.g. if the lesson contains expected vulnerability and provides

the correct solution);

• related to the tree view containing all lessons:

◦ the correctness of the transitions between all lessons;

◦ checking if the double click on the lesson category for Facelets and AngularJS

and single click for GWT expands the list of lessons from clicked category;

◦ checking if after clicking on the chosen lesson (even from different view

technology), the proper lesson in the tree view is selected and the category,

to which belong these lessons, is expanded.

Testing by users

The main aim of the environment is to teach, therefore that kind of application

should be also tested by some potential users. My three colleagues, who also study

the computer science, have tested the environment. Thanks to their comments

I was able to improve WebHiob to make lessons more affordable. I have mainly

changed some of lessons’ introductions and solution descriptions, to make the

lesson easier to understand for students less familiar with web application secu-

rity issues. The students were very pleased with provided by WebHiob lessons,

especially due to the fact, that each lesson has got a very clear solution how to

improve the code to make the attack impossible. Additionally they have praised all

lessons from the Broken Authentication And Session Management category, because

of their huge usefulness (almost all web application has to keep the conversation

state between the client and server).

7.5. User interface 98

7.5. User interface

User interface of WebHiob is self explanatory. Each lesson contains three tabs:

lesson, security problem and solution. Each tab’s content provides description,

therefore the user should not have any problem using WebHiob.

The WebHiob environment provides a user manual inside Introduction category

(the Working with WebHiob and Adding A Lesson lessons). The example of lesson in

the Facelets view technology displaying the content of the Lesson tab is shown in

Figure 7.2. The example of lesson in the AngularJS view technology displaying the

content of the Security problem tab is shown in Figure 7.3. The example of lesson

in the GWT view technology displaying the content of the Solution tab is shown in

Figure 7.4.

7.5

.U

serin

terface

99

Figure 7.2: Example of the lesson in the Facelets view technology displaying the content of the Lesson tab

7.5

.U

serin

terface

100

Figure 7.3: Example of the lesson in the AngularJS view technology displaying the content of the Security problem tab

7.5

.U

serin

terface

101

Figure 7.4: Example of the lesson in the GWT view technology displaying the content of the Solution tab

8. Conclusions

The main aim of this thesis was to prepare an interactive learning environment

providing the lessons about web application security. The target has been achieved

and its realization has contributed to the creation of the WebHiob environment,

whose main features include:

• ten interactive lessons divided into categories with introduction, security prob-

lem description and solution;

• ease of adding the new categories and lessons in one of the three view technology

– Facelets, AngularJS, and GWT ;

• possibility to extend the environment with other view technologies (e.g. Velocity).

WebHiob provides the clearly separation between the lesson, security problem

description pointing which code is directly related to the vulnerability, and solu-

tion how to improve the code to make the attack impossible. In this way it has

eliminated the biggest disadvantage of the existing environments of this type (We-

bGoat, DVWA and HacmeBank) – the lack of indication how to protect from the

attack. WebHiob changes the conception of lessons – the lesson does not end with

performing the successful attack (how it is with the other environments), but it

ends when the user protect the application from the attack. The approach used

in WebHiob allows to better understand how the vulnerabilities work, how to test

the application for safety, why the application is not secure and what is the most

important – how to secure the modern web application.

WebHiob consists of ten lessons divided into five categories: Unvalidated Redi-

rects and Forwards, Injection, XSS, Parameter Tampering, and Broken Authentica-

tion and Session Management. The latter affects the largest number of existing web

applications – almost all application provides a session management. WebHiob

teaches how to protect the application using mechanisms built in the Spring Se-

curity framework, how to configure them providing the custom implementation of

the security filters. Additionally, it teaches how works the token-based authenti-

cation and how to implement the custom mechanism supporting this method of

authentication.

8. Conclusions 103

WebHiob has been developed using the modern web technologies (Spring with

Web MVC part and Spring Security, when it comes to the server side). The user

interface of the lessons have been developed in three view technologies (Facelets,

AngularJS, and GWT ), what is a new in comparing with the existing environments

of this type. This approach used in WebHiob should encourage more people to

extend the environment with the new lessons. Apart from lessons, there are

many different ways for extending WebHiob such as adding the internationalization

support, marking the difficulty level of the lessons or saving the state of already

solved lessons. The latter could be more useful with the bigger amount of lessons.

The another advantage of WebHiob is its architecture, which has been designed in

that way, that adding a new lesson is very simple. All code was prepared applying

the „clean code” principles. This makes that understating the code is relatively

easy and it provides a possibility to write many automated tests. Six of them have

been already prepared as an example.

All issues addressed in this thesis are highly topical. The amount of web

applications grows by the year. The issues of web security are and will be very

important. Thus environments such as WebHiob are in high demand. Every

student of web security should learn not only from books or lectures, but should

also has got a possibility to „touch” the problem by himself. Therefore I would like

to recommend WebHiob to all student of computer science and people who wants

to extend/check their knowledge about security of modern web applications.

Bibliography

[1] Announcing Spring Framework 4.0 GA Release. https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release. last accessed:26/04/2015.

[2] ACID vs. BASE: The Shifting pH of Database Transaction Processing. http://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/. last accessed: 23/10/2014.

[3] An Invitation to Servlets. http://www.novocode.com/doc/servlet-essentials/chapter1.html. last accessed: 1/11/2014.

[4] angular-route-segment home page. http://angular-route-segment.com. lastaccessed: 27/05/2015.

[5] AngularJS home page. https://angularjs.org. last accessed: 27/05/2015.[6] AngularJS interceptors documentation. https://docs.angularjs.org/api/ng/

service/$http. last accessed: 26/04/2015.[7] Application Misconfiguration description. http://projects.webappsec.org/w/

page/13246959/Server%20Misconfiguration. last accessed: 23/10/2014.[8] Bootstrap home page. http://getbootstrap.com. last accessed: 27/05/2015.[9] Cookies vs Tokens. Getting auth right with AngularJS. https://auth0.com/

blog/2014/01/07/angularjs-authentication-with-cookies-vs-token. lastaccessed: 26/04/2015.

[10] CORS documentation. http://www.w3.org/TR/cors. last accessed: 26/04/2015.[11] Countdown plugin home page. http://rendro.github.io/countdown/. last ac-

cessed: 27/05/2015.[12] Critical vulnerabilities in JSON Web Token libraries. https://auth0.com/blog/

2015/03/31/critical-vulnerabilities-in-json-web-token-libraries. lastaccessed: 26/04/2015.

[13] Cyber crime costs. http://www.foxbusiness.com/technology/2013/07/22/report-cyber-crime-costs-global-economy-up-to-1-trillion-year. lastaccessed: 23/10/2014.

[14] Description of passive fingerprinting. http://old.honeynet.org/papers/finger.last accessed: 23/10/2014.

[15] Description of SYN flooding attacks. http://www.thegeekstuff.com/2012/01/tcp-sequence-number-attacks/. last accessed: 23/10/2014.

[16] DNS attacks description. http://www.asd.gov.au/publications/csocprotect/dns_security.htm. last accessed: 23/10/2014.

[17] DNS cache snooping description. http://resources.infosecinstitute.com/dns-cache-snooping/. last accessed: 23/10/2014.

[18] DNS cache snooping description. http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf. last accessed: 23/10/2014.

[19] DNS cache snooping description. http://support.simpledns.com/kb/a153/what-is-dns-cache-snooping-and-how-do-i-prevent-it.aspx. last accessed:23/10/2014.

[20] DNS Lookup process schema (source of the figure). https://www.fir3net.com/Networking/Protocols/dns-nslookup-how-to-find-the-root-servers.html. last accessed: 23/10/2014.

[21] DNS resolution process description. http://thelazyadmin.com/2006/02/dns-tips-15-dns-resolution-explained/. last accessed: 23/10/2014.

https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release

https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release

http://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/



http://www.novocode.com/doc/servlet-essentials/chapter1.html

http://www.novocode.com/doc/servlet-essentials/chapter1.html

http://angular-route-segment.com

https://angularjs.org

https://docs.angularjs.org/api/ng/service/$http

https://docs.angularjs.org/api/ng/service/$http

http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration

http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration

http://getbootstrap.com

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token

http://www.w3.org/TR/cors

http://rendro.github.io/countdown/

https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries

https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries

http://www.foxbusiness.com/technology/2013/07/22/report-cyber-crime-costs-global-economy-up-to-1-trillion-year

http://www.foxbusiness.com/technology/2013/07/22/report-cyber-crime-costs-global-economy-up-to-1-trillion-year

http://old.honeynet.org/papers/finger

http://www.thegeekstuff.com/2012/01/tcp-sequence-number-attacks/

http://www.thegeekstuff.com/2012/01/tcp-sequence-number-attacks/

http://www.asd.gov.au/publications/csocprotect/dns_security.htm

http://www.asd.gov.au/publications/csocprotect/dns_security.htm

http://resources.infosecinstitute.com/dns-cache-snooping/

http://resources.infosecinstitute.com/dns-cache-snooping/

http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

http://support.simpledns.com/kb/a153/what-is-dns-cache-snooping-and-how-do-i-prevent-it.aspx

http://support.simpledns.com/kb/a153/what-is-dns-cache-snooping-and-how-do-i-prevent-it.aspx

https://www.fir3net.com/Networking/Protocols/dns-nslookup-how-to-find-the-root-servers.html



http://thelazyadmin.com/2006/02/dns-tips-15-dns-resolution-explained/

http://thelazyadmin.com/2006/02/dns-tips-15-dns-resolution-explained/

Bibliography 105

[22] DVWA project page. http://www.dvwa.co.uk. last accessed: 30/11/2014.[23] DVWA’s Github repository. https://github.com/RandomStorm/DVWA. last ac-

cessed: 30/11/2014.[24] EIS definition. http://www.techopedia.com/definition/24327/enterprise-

information-system-tier-eis. last accessed: 23/10/2014.[25] ERP definition. http://www.webopedia.com/TERM/E/ERP.html. last accessed:

23/10/2014.[26] Explanation of why network firewall protecion is not enough. http:

//www.computerworlduk.com/white-paper/it-security/5723/network-firewall-protection-is-not-enough/. last accessed: 23/10/2014.

[27] Expression Language in The Java EE 6 Tutorial. http://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html. last accessed: 26/04/2015.

[28] Expression Language Injection description. http://support.springsource.com/security/cve-2011-2730. last accessed: 26/04/2015.

[29] Expression Language Injection description. https://www.owasp.org/index.php/Expression_Language_Injection. last accessed: 26/04/2015.

[30] Expression Language Injection description. https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US. last accessed: 26/04/2015.

[31] Gradle home page. https://gradle.org. last accessed: 27/05/2015.[32] GWT home page. http://www.gwtproject.org. last accessed: 27/05/2015.[33] GWT RPC description. http://www.gwtproject.org/doc/latest/tutorial/

RPC.html. last accessed: 27/05/2015.[34] GWT SKD download page. http://www.gwtproject.org/download.html. last

accessed: 27/05/2015.[35] HacmeBank’s project page. https://www.owasp.org/index.php/HacmeBank. last

accessed: 30/11/2014.[36] Hibernate home page. http://hibernate.org. last accessed: 27/05/2015.[37] highlight.js home page. https://highlightjs.org/. last accessed: 27/05/2015.[38] How DNS cache poisoning works. http://www.networkworld.com/article/

2277316/tech-primers/how-dns-cache-poisoning-works.html. last accessed:23/10/2014.

[39] How to Handle HTTP Redirects with Jquery and Django. http://hunterford.me/how-to-handle-http-redirects-with-jquery-and-django. last accessed:26/04/2015.

[40] How to prevent DNS attacks. http://www.esecurityplanet.com/network-security/how-to-prevent-dns-attacks.html. last accessed: 23/10/2014.

[41] HSQLDB home page. http://hsqldb.org. last accessed: 27/05/2015.[42] HTTP Basic Auth description. https://luckymarmot.com/paw/doc/HTTP_Basic_

Auth. last accessed: 10/05/2015.[43] IBM Rational Software Architect home page. http://www-03.ibm.com/software/

products/en/ratisoftarch. last accessed: 27/05/2015.[44] includeViewParameters re-evaluates param/model values as EL expressions.

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-869. last ac-cessed: 11/11/2014.

[45] IntelliJ IDEA home page. https://www.jetbrains.com/idea. last accessed:27/05/2015.

[46] InternalResourceViewResolver documentation. http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/web/servlet/view/InternalResourceViewResolver.html. last accessed: 26/04/2015.

[47] Java Community Process official site. https://www.jcp.org/. last accessed:23/10/2014.

[48] Java EE at a Glance. http://www.oracle.com/technetwork/java/javaee/overview/index.html. last accessed: 23/10/2014.

http://www.dvwa.co.uk

https://github.com/RandomStorm/DVWA

http://www.techopedia.com/definition/24327/enterprise-information-system-tier-eis

http://www.techopedia.com/definition/24327/enterprise-information-system-tier-eis

http://www.webopedia.com/TERM/E/ERP.html

http://www.computerworlduk.com/white-paper/it-security/5723/network-firewall-protection-is-not-enough/



http://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html

http://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html

http://support.springsource.com/security/cve-2011-2730

http://support.springsource.com/security/cve-2011-2730

https://www.owasp.org/index.php/Expression_Language_Injection

https://www.owasp.org/index.php/Expression_Language_Injection

https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US



https://gradle.org

http://www.gwtproject.org

http://www.gwtproject.org/doc/latest/tutorial/RPC.html

http://www.gwtproject.org/doc/latest/tutorial/RPC.html

http://www.gwtproject.org/download.html

https://www.owasp.org/index.php/HacmeBank

http://hibernate.org

https://highlightjs.org/

http://www.networkworld.com/article/2277316/tech-primers/how-dns-cache-poisoning-works.html

http://www.networkworld.com/article/2277316/tech-primers/how-dns-cache-poisoning-works.html

http://hunterford.me/how-to-handle-http-redirects-with-jquery-and-django

http://hunterford.me/how-to-handle-http-redirects-with-jquery-and-django

http://www.esecurityplanet.com/network-security/how-to-prevent-dns-attacks.html

http://www.esecurityplanet.com/network-security/how-to-prevent-dns-attacks.html

http://hsqldb.org

https://luckymarmot.com/paw/doc/HTTP_Basic_Auth

https://luckymarmot.com/paw/doc/HTTP_Basic_Auth

http://www-03.ibm.com/software/products/en/ratisoftarch

http://www-03.ibm.com/software/products/en/ratisoftarch

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-869

https://www.jetbrains.com/idea

http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/web/servlet/view/InternalResourceViewResolver.html



https://www.jcp.org/

http://www.oracle.com/technetwork/java/javaee/overview/index.html

http://www.oracle.com/technetwork/java/javaee/overview/index.html

Bibliography 106

[49] Java EE tiers. http://docs.oracle.com/javaee/5/firstcup/doc/gcrky.html.last accessed: 23/10/2014.

[50] Java SE Development Kit 7 Downloads. http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html. last accessed:27/05/2015.

[51] JDBC vs ORM. http://community.actian.com/w/files/4/44/JDBCvsORM.pdf.last accessed: 23/10/2014.

[52] jQuery home page. https://jquery.com. last accessed: 27/05/2015.[53] JSON documentation. https://tools.ietf.org/html/rfc7159. last accessed:

26/04/2015.[54] JSON Web Token official page. http://jwt.io. last accessed: 26/04/2015.[55] JSONP attack example. http://erlend.oftedal.no/blog/?blogid=97. last ac-

cessed: 26/04/2015.[56] JSONP description. http://json-p.org. last accessed: 26/04/2015.[57] jsTree plugin home page. http://www.jstree.com. last accessed: 27/05/2015.[58] JUnit framework home page. http://junit.org. last accessed: 27/05/2015.[59] Layer 8 description. https://www.damballa.com/downloads/d_pubs/WP%

20Layer%208%20(2008-11).pdf. last accessed: 23/10/2014.[60] Lower and higer layers of the OSI model. http://www.tcpipguide.com/free/

t_OSIReferenceModelNetworkingLayersSublayersandLayer-2.htm. last ac-cessed: 23/10/2014.

[61] Man in the middle attacks. https://voer.edu.vn/m/man-in-the-middle/a674d643. last accessed: 23/10/2014.

[62] Managed beans: what they are + how to create them. http://www.ovalbusinesssolutions.co.uk/thoughts/managed-beans-what-they-are-how-to-create-them. last accessed: 1/11/2014.

[63] Market Share of RDBMS. http://www.mysql.com/why-mysql/marketshare/. lastaccessed: 23/10/2014.

[64] Missing Function Level Access Control description. http://blog.credera.com/technology-insights/open-source-technology-insights/top-ten-web-security-risks-missing-function-level-access-control-7/. last accessed:23/10/2014.

[65] Multimedia and learining. http://www.medvet.umontreal.ca/techno/eta6785/articles/multimedia_and_learning.pdf. last accessed: 23/10/2014.

[66] NoSQL Databases Defined and Explained. http://planetcassandra.org/what-is-nosql/. last accessed: 23/10/2014.

[67] NoSQL databases types with examples. http://blog.monitis.com/2011/05/22/picking-the-right-nosql-database-tool/. last accessed: 23/10/2014.

[68] Old School Clock with CSS3 and jQuery. https://css-tricks.com/css3-clock.last accessed: 27/05/2015.

[69] Oracle’s Implementation Of The JSF 2.2 Specification. http://mvnrepository.com/artifact/com.sun.faces/jsf-impl. last accessed: 27/05/2015.

[70] OSI vulnerabilities. http://www.sans.org/reading-room/whitepapers/protocols/applying-osi-layer-network-model-information-security-1309. last accessed: 23/10/2014.

[71] OWASP JSON Sanitizer home page. https://www.owasp.org/index.php/OWASP_JSON_Sanitizer. last accessed: 27/05/2015.

[72] OWASP organization. https://www.owasp.org. last accessed: 23/10/2014.[73] OWASP Top Ten document. http://owasptop10.googlecode.com/files/OWASP%

20Top%2010%20-%202013.pdf. last accessed: 23/10/2014.[74] OWASP Top Ten presentation. https://www.owasp.org/images/8/85/OWASP_

Top_Ten.ppt. last accessed: 23/10/2014.[75] OWASP Top Ten Project description. https://www.owasp.org/index.php/

Category:OWASP_Top_Ten_Project. last accessed: 23/10/2014.

http://docs.oracle.com/javaee/5/firstcup/doc/gcrky.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

http://community.actian.com/w/files/4/44/JDBCvsORM.pdf

https://jquery.com

https://tools.ietf.org/html/rfc7159

http://jwt.io

http://erlend.oftedal.no/blog/?blogid=97

http://json-p.org

http://www.jstree.com

http://junit.org

https://www.damballa.com/downloads/d_pubs/WP%20Layer%208%20(2008-11).pdf

https://www.damballa.com/downloads/d_pubs/WP%20Layer%208%20(2008-11).pdf

http://www.tcpipguide.com/free/t_OSIReferenceModelNetworkingLayersSublayersandLayer-2.htm

http://www.tcpipguide.com/free/t_OSIReferenceModelNetworkingLayersSublayersandLayer-2.htm

https://voer.edu.vn/m/man-in-the-middle/a674d643

https://voer.edu.vn/m/man-in-the-middle/a674d643

http://www.ovalbusinesssolutions.co.uk/thoughts/managed-beans-what-they-are-how-to-create-them



http://www.mysql.com/why-mysql/marketshare/

http://blog.credera.com/technology-insights/open-source-technology-insights/top-ten-web-security-risks-missing-function-level-access-control-7/



http://www.medvet.umontreal.ca/techno/eta6785/articles/multimedia_and_learning.pdf

http://www.medvet.umontreal.ca/techno/eta6785/articles/multimedia_and_learning.pdf

http://planetcassandra.org/what-is-nosql/

http://planetcassandra.org/what-is-nosql/

http://blog.monitis.com/2011/05/22/picking-the-right-nosql-database-tool/

http://blog.monitis.com/2011/05/22/picking-the-right-nosql-database-tool/

https://css-tricks.com/css3-clock

http://mvnrepository.com/artifact/com.sun.faces/jsf-impl

http://mvnrepository.com/artifact/com.sun.faces/jsf-impl

http://www.sans.org/reading-room/whitepapers/protocols/applying-osi-layer-network-model-information-security-1309



https://www.owasp.org/index.php/OWASP_JSON_Sanitizer

https://www.owasp.org/index.php/OWASP_JSON_Sanitizer

https://www.owasp.org

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf

https://www.owasp.org/images/8/85/OWASP_Top_Ten.ppt

https://www.owasp.org/images/8/85/OWASP_Top_Ten.ppt

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Bibliography 107

[76] OWASP ZAP project. https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project. last accessed: 26/04/2015.

[77] Passive fingerprinting prevention. http://searchsecurity.techtarget.com/feature/Passive-fingerprinting-Applications-and-prevention. last ac-cessed: 23/10/2014.

[78] Plain old Java objects example. http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jst.ejb.doc.user%2Ftopics%2Fcpojosandee5.html.last accessed: 1/11/2014.

[79] Protecting the weakest link in your security chain – the USER. http://www.ipdata.pl/upload/File/cyberoam/prezentacje/pr_cyberoam_layer8_en.pdf. last accessed: 23/10/2014.

[80] RandomStorm web page. https://www.randomstorm.com. last accessed:30/11/2014.

[81] RDBMS Concepts and Oracle 8i. http://www.msuniv.ac.in/RDBMSConceptsandOracle8i.pdf. last accessed: 23/10/2014.

[82] RDBMS vs. NoSQL: How do you pick? http://www.zdnet.com/rdbms-vs-nosql-how-do-you-pick-7000020803/. last accessed: 23/10/2014.

[83] Rich Internet Application definition. http://searchsoa.techtarget.com/definition/Rich-Internet-Application-RIA. last accessed: 26/04/2015.

[84] Same-Origin Policy description. http://www.w3.org/Security/wiki/Same_Origin_Policy. last accessed: 26/04/2015.

[85] Sensitive Data Exposure – A Nightmare To All Business Enterprises. https://www.indusface.com/blog/?p=395. last accessed: 23/10/2014.

[86] Server Misconfiguration description. http://projects.webappsec.org/w/page/13246914/Application%20Misconfiguration. last accessed: 23/10/2014.

[87] Session fixation description. http://www.acrossecurity.com/papers/session_fixation.pdf. last accessed: 23/10/2014.

[88] Session hijacking description. https://www.owasp.org/index.php/Session_hijacking_attack. last accessed: 23/10/2014.

[89] Session managenet cheat sheet. https://www.owasp.org/index.php/Session_Management_Cheat_Sheet. last accessed: 23/10/2014.

[90] Socian engineering definition. http://searchsecurity.techtarget.com/definition/social-engineering. last accessed: 23/10/2014.

[91] Spear phishing description. http://searchsecurity.techtarget.com/tip/Spear-phishing-Dont-be-a-target. last accessed: 23/10/2014.

[92] Spear phishing description. http://www.firmex.com/blog/spear-phishing-whos-getting-caught/. last accessed: 23/10/2014.

[93] Spear phishing description. http://us.norton.com/spear-phishing-scam-not-sport/article. last accessed: 23/10/2014.

[94] Spring framework home page. http://projects.spring.io/spring-framework.last accessed: 27/05/2015.

[95] Spring MessageTag documentation. http://docs.spring.io/spring/docs/1.2.9/taglib/tag/MessageTag.html. last accessed: 26/04/2015.

[96] Spring MVC Known Vulnerabilities and Issues. http://support.springsource.com/security/spring-mvc. last accessed: 11/11/2014.

[97] Spring Security framework. http://projects.spring.io/spring-security. lastaccessed: 26/04/2015.

[98] Spring Web MVC framework. http://docs.spring.io/spring-framework/docs/2.5.6/reference/mvc.html. last accessed: 1/11/2014.

[99] Stateless Spring Security Part 2: Stateless Authentication. http://blog.jdriven.com/2014/10/stateless-spring-security-part-2-stateless-authentication. last accessed: 26/04/2015.

[100] SYN flooding attacks prevention. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html. last accessed:23/10/2014.

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

http://searchsecurity.techtarget.com/feature/Passive-fingerprinting-Applications-and-prevention

http://searchsecurity.techtarget.com/feature/Passive-fingerprinting-Applications-and-prevention

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jst.ejb.doc.user%2Ftopics%2Fcpojosandee5.html

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jst.ejb.doc.user%2Ftopics%2Fcpojosandee5.html

http://www.ipdata.pl/upload/File/cyberoam/prezentacje/pr_cyberoam_layer8_en.pdf



https://www.randomstorm.com

http://www.msuniv.ac.in/RDBMSConceptsandOracle8i.pdf

http://www.msuniv.ac.in/RDBMSConceptsandOracle8i.pdf

http://www.zdnet.com/rdbms-vs-nosql-how-do-you-pick-7000020803/

http://www.zdnet.com/rdbms-vs-nosql-how-do-you-pick-7000020803/

http://searchsoa.techtarget.com/definition/Rich-Internet-Application-RIA

http://searchsoa.techtarget.com/definition/Rich-Internet-Application-RIA

http://www.w3.org/Security/wiki/Same_Origin_Policy

http://www.w3.org/Security/wiki/Same_Origin_Policy

https://www.indusface.com/blog/?p=395

https://www.indusface.com/blog/?p=395

http://projects.webappsec.org/w/page/13246914/Application%20Misconfiguration

http://projects.webappsec.org/w/page/13246914/Application%20Misconfiguration

http://www.acrossecurity.com/papers/session_fixation.pdf

http://www.acrossecurity.com/papers/session_fixation.pdf

https://www.owasp.org/index.php/Session_hijacking_attack

https://www.owasp.org/index.php/Session_hijacking_attack

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

http://searchsecurity.techtarget.com/definition/social-engineering

http://searchsecurity.techtarget.com/definition/social-engineering

http://searchsecurity.techtarget.com/tip/Spear-phishing-Dont-be-a-target

http://searchsecurity.techtarget.com/tip/Spear-phishing-Dont-be-a-target

http://www.firmex.com/blog/spear-phishing-whos-getting-caught/

http://www.firmex.com/blog/spear-phishing-whos-getting-caught/

http://us.norton.com/spear-phishing-scam-not-sport/article

http://us.norton.com/spear-phishing-scam-not-sport/article

http://projects.spring.io/spring-framework

http://docs.spring.io/spring/docs/1.2.9/taglib/tag/MessageTag.html

http://docs.spring.io/spring/docs/1.2.9/taglib/tag/MessageTag.html

http://support.springsource.com/security/spring-mvc

http://support.springsource.com/security/spring-mvc

http://projects.spring.io/spring-security

http://docs.spring.io/spring-framework/docs/2.5.6/reference/mvc.html

http://docs.spring.io/spring-framework/docs/2.5.6/reference/mvc.html

http://blog.jdriven.com/2014/10/stateless-spring-security-part-2-stateless-authentication



http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html

Bibliography 108

[101] TCP/IP model. http://www.tcpipguide.com/free/t_TCPIPArchitectureandtheTCPIPModel-3.htm. last accessed: 23/10/2014.

[102] Testing for Insecure Direct Object References. https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004).last accessed: 23/10/2014.

[103] The Base16, Base32, and Base64 Data Encodings. https://tools.ietf.org/html/rfc4648. last accessed: 10/05/2015.

[104] Tomcat home page. http://tomcat.apache.org. last accessed: 27/05/2015.[105] Top 4 Java Web Frameworks Revealed: Real Life Usage Data of Spring MVC,

Vaadin, GWT and JSF. http://zeroturnaround.com/rebellabs/top-4-java-web-frameworks-revealed-real-life-usage-data-of-spring-mvc-vaadin-gwt-and-jsf/. last accessed: 1/11/2014.

[106] Two Security Vulnerabilities in the Spring Framework’s MVC. http://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf. last accessed: 11/11/2014.

[107] Two Security Vulnerabilities in the Spring Framework’s MVC. https://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf. last accessed: 26/04/2015.

[108] Unvalidated Redirects and Forwards description. http://blog.ippon.fr/2014/01/29/owasp-top-10-a10/. last accessed: 23/10/2014.

[109] Using Components with Known Vulnerabilities description. http://blog.credera.com/technology-insights/java/top-10-web-security-risks-using-components-known-vulnerabilities-9/. last accessed: 23/10/2014.

[110] Vulnerability Statistics of Spring. http://www.cvedetails.com/vendor/9664/Springsource.html. last accessed: 11/11/2014.

[111] Web architecture. http://queens.db.toronto.edu/~papaggel/courses/csc309/docs/lectures/web-architectures.pdf. last accessed: 23/10/2014.

[112] Web site allows to exercise hacking. http://webhacking.kr. last accessed:11/11/2014.

[113] WebGoat relases history. https://github.com/WebGoat/WebGoat/releases. lastaccessed: 30/11/2014.

[114] WebGoat’s github page. http://webgoat.github.io/. last accessed: 30/11/2014.[115] WebGoat’s Github repository. https://github.com/WebGoat/WebGoat. last ac-

cessed: 30/11/2014.[116] WebGoat’s project page. https://www.owasp.org/index.php/Category:OWASP_

WebGoat_Project. last accessed: 30/11/2014.[117] Website Security Tests Protect Against Application Vulnerabilities. http://www.

gamasec.com/pdf/websitesecuritytests.pdf. last accessed: 23/10/2014.[118] XSRF example image. http://digilib.tes.telkomuniversity.ac.id/images/

stories/artkel2/yz-april/Ilustrasi%20Serangan%20XSRF.JPG. last ac-cessed: 23/10/2014.

[119] XSS description. http://excess-xss.com/. last accessed: 23/10/2014.[120] XSS description. http://projects.webappsec.org/w/page/13246920/Cross%

20Site%20Scripting. last accessed: 23/10/2014.[121] J. Essington A. Tökke A. Tacy, R. Hanson. GWT in Action. Manning, second edition,

2013.[122] Anirban Chakrabarti et al. Abhijit Belapurkar. Distributed Systems Security: Issues,

Processes, and Solutions. Wiley, 2009.[123] Dan Malks Alur Deepak, John Crupi. Core J2EE Patterns: Best Practices and Design

Strategies. Sun Microsystems Press, second edition, 2003.[124] Marshall Wilensky Candace Leiden. TCP/IP For Dummies. Wiley Publishing, Inc.,

6th edition, 2009.[125] Rob Harrop Chris Schaefer, Clarence Ho. Pro Spring. Apress, 4th edition, 2014.[126] Adam Freeman. Pro AngularJS. Apress, 2014.[127] Antonio Goncalves. Beginning Java EE 7. Apress, 2013.

http://www.tcpipguide.com/free/t_TCPIPArchitectureandtheTCPIPModel-3.htm

http://www.tcpipguide.com/free/t_TCPIPArchitectureandtheTCPIPModel-3.htm

https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)

https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)



http://tomcat.apache.org

http://zeroturnaround.com/rebellabs/top-4-java-web-frameworks-revealed-real-life-usage-data-of-spring-mvc-vaadin-gwt-and-jsf/



http://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf



https://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf



http://blog.ippon.fr/2014/01/29/owasp-top-10-a10/

http://blog.ippon.fr/2014/01/29/owasp-top-10-a10/

http://blog.credera.com/technology-insights/java/top-10-web-security-risks-using-components-known-vulnerabilities-9/



http://www.cvedetails.com/vendor/9664/Springsource.html

http://www.cvedetails.com/vendor/9664/Springsource.html

http://queens.db.toronto.edu/~papaggel/courses/csc309/docs/lectures/web-architectures.pdf

http://queens.db.toronto.edu/~papaggel/courses/csc309/docs/lectures/web-architectures.pdf

http://webhacking.kr

https://github.com/WebGoat/WebGoat/releases

http://webgoat.github.io/

https://github.com/WebGoat/WebGoat

https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

http://www.gamasec.com/pdf/websitesecuritytests.pdf

http://www.gamasec.com/pdf/websitesecuritytests.pdf

http://digilib.tes.telkomuniversity.ac.id/images/stories/artkel2/yz-april/Ilustrasi%20Serangan%20XSRF.JPG

http://digilib.tes.telkomuniversity.ac.id/images/stories/artkel2/yz-april/Ilustrasi%20Serangan%20XSRF.JPG

http://excess-xss.com/

http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting

http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting

Bibliography 109

[128] Michael Gregg. Hack the Stack: Using Snort and Ethereal to Master The 8 Layers ofAn Insecure Network. Syngress, 2006.

[129] Jennifer Widom Hector Garcia-Molina, Jeffrey D. Ullman. Database Systems: TheComplete Book. Prentice Hall, second edition, 2008.

[130] Paco Hope and Ben Walther. Web Security Testing Cookbook: Systematic Techniquesto Find Problems Fast. O’Reilly, first edition, 2008.

[131] Imad Daou. Why We Should Understand TCP/IP and OSI Models? http://www.ccnahub.com/ip-fundamentals/understanding-tcp-ip-and-osi-models. lastaccessed: 28/05/2015.

[132] Keith W. Ross James F. Kurose. Computer Networking: A Top-Down Approach.Pearson, 6th edition, 2013.

[133] Joe Stangarone. 10 security mistakes web application developers shouldnever make. http://www.mrc-productivity.com/blog/2013/12/10-security-mistakes-web-application-developers-should-never-make. last accessed:23/10/2014.

[134] Caleb Sima Joel Scambray, Vincent Liu. Hacking Exposed Web Applications: WebApplication Security Secrets and Solutions. The McGraw-Hill Companies, Inc., thirdedition, 2011.

[135] Jakub Koperwas. Materials to the lecture „Design and Implementation of Modern Weband Enterprise Applications”. semester 14L.

[136] Michael Gregg. Active and passive fingerprinting. http://searchnetworking.techtarget.com/tip/OSI-Securing-the-Stack-Layer-4-Fingerprinting.last accessed: 23/10/2014.

[137] Michael Gregg. Layer 8 description. http://searchnetworking.techtarget.com/tip/OSI-Securing-the-Stack-Layer-8-Social-engineering-and-security-policy. last accessed: 23/10/2014.

[138] Michael Gregg. Physical layer vulnerabilities. http://searchnetworking.techtarget.com/tip/OSI-Securing-the-stack-Layer-1-Physical-security-threats. last accessed: 23/10/2014.

[139] Merrick Schincariol Mike Keith. Pro JPA 2. Apress, second edition, 2013.[140] Carlo Scarioni. Pro Spring Security. Apress, 2013.[141] Jason Hunter William Crawford. Java Servlet Programming. O’Reilly Media, second

edition, 2001.[142] Kamil Zych. Problemy bezpieczenstwa w architekturze zorientowanej na usługi,

master thesis. 2010.

http://www.ccnahub.com/ip-fundamentals/understanding-tcp-ip-and-osi-models

http://www.ccnahub.com/ip-fundamentals/understanding-tcp-ip-and-osi-models

http://www.mrc-productivity.com/blog/2013/12/10-security-mistakes-web-application-developers-should-never-make

http://www.mrc-productivity.com/blog/2013/12/10-security-mistakes-web-application-developers-should-never-make

http://searchnetworking.techtarget.com/tip/OSI-Securing-the-Stack-Layer-4-Fingerprinting

http://searchnetworking.techtarget.com/tip/OSI-Securing-the-Stack-Layer-4-Fingerprinting

http://searchnetworking.techtarget.com/tip/OSI-Securing-the-Stack-Layer-8-Social-engineering-and-security-policy



http://searchnetworking.techtarget.com/tip/OSI-Securing-the-stack-Layer-1-Physical-security-threats



A. User manual

A.1. Installation

To run WebHiob it is required to provide:

1. Java SE Development Kit 7 [50];

2. Gradle [31];

3. an IDE supporting Gradle (recommended InteliiJ IDEA 14.1 [45]);

4. Tomcat (version 7 or 8) [104];

5. GWT SDK [34].

The easiest way to run WebHiob is to import the project based on build.gradle

file in IntelliJ IDEA application and follow the steps:

1. Press the File->Settings -> Build, Execution, Deployment -> Compiler -> Annotation

Processors tab and check the Enable annotation processing checkbox;

2. Press the View->Tool Windows->Gradle tab and in Gradle view press Refresh All

Gradle Projects button.

3. Press the Run->Edit Configurations. . . ; tab and the Tomcat 7 or 8 inside this

view.

4. Press the Run->Run ’name of the configuration’ tab.

5. Default web browser should be automatically run with the initial WebHiob page

(manually it could be done by typing in the browser http://localhost:<port>

address).

Similar configuration could be done in other IDE (e.g. Eclipse). To be able to

take advantage of all lessons it is recommended to install Zed Attack Proxy [76] (or

similar tool allowing to intercept HTTP requests and responses).

A.2. Manual

User interface of WebHiob is self explanatory. Each lesson contains three tabs:

lesson, security problem and solution. Each tab’s content provides description,

therefore the user should not have any problem using WebHiob.

The WebHiob environment provides user manual inside Introduction category

(Working with WebHiob and Adding A Lesson lessons).

A.2. Manual 111

Warnings

While running WebHiob your machine will be vulnerable to attack, therefore you

should disconnect from the Internet while using it.

The WebHiob environment is for educational purposes only. You should not try

to attempt these techniques on the Internet without authorization, because it is

against to the law.

B. Contents of included CD

The CD includes:

• RobertRozmus.pdf file – this thesis;

• WebHiob.zip file – compressed project ready to import using the build.gradle file

containing source files in the src directory including the following directories:

◦ main/java – java files;

◦ main/resources – configuration files;

◦ main/webapp – web application files such as (X)HTML, JavaScript, CSS;

◦ test/java – automated tests.

Learning Environment For Security of Modern Web Applications...Facelet s, AngularJS and GWT . U...

Documents

Transcript of Learning Environment For Security of Modern Web Applications...Facelet s, AngularJS and GWT . U...