Pattern based Web Security Testing

Paulo J. M. Ara

ujo

and Ana C. R. Paiva

1,2

Faculty of Engineering of the University of Porto, Rua Dr. Roberto Frias, s/n 4200-465 Porto, Portugal

INESC TEC, Rua Dr. Roberto Frias, s/n 4200-465 Porto, Portugal

Keywords:

Security Testing, Pattern based Testing, Pattern based Security Testing, Security Web Testing.

Abstract:

This paper presents a Pattern Based Testing approach for testing security aspects of the applications under

test (AUT). It describes the two security patterns which are the focus of this work (“Account Lockout” and

“Authentication Enforcer”) and the test strategies implemented to check if the applications are vulnerable or

not regarding these patterns. The PBST (Pattern Based Security Testing) overall approach has two phases:

exploration (to identify the web pages of the application under test) and testing (to execute the test strategies

developed in order to detect vulnerabilities). An experiment is presented to validate the approach over ﬁve

public web applications. The goal is to assess the behavior of the tool when varying the upper limit of pages

to visit and assess its capacity to ﬁnd real vulnerabilities. The results are promising. Indeed, it was possible to

check that the vulnerabilities detected corresponded to real security problems.

1 INTRODUCTION

To have quality today, a software application should

work ﬂawlessly and be safe. However, exposure of

applications to undesirable attacks is common and

brings new challenges. Developers are concerned

mainly to create applications that work properly and

sometimes they neglect the security of the application.

That is why testing the developed application is criti-

cal to ensure the quality and reliability of the product.

However, the test implementation requires time

and money which are limited resources. In recent

years, a number of testing tools based on different

methodologies have emerged to try making the test-

ing process faster and more systematic. One of these

methodologies is testing based on models/patterns

which have been increasingly accepted (Utting and

Legeard, 2007).

In a previous project called PBGT (Pattern Based

GUI Testing)

we developed several tools to test soft-

ware applications through their Graphical User Inter-

face (GUI) (Moreira et al., 2013), (Moreira et al.,

2017), (Paiva and Vilela, 2017). The main goal of

PBGT is the develop generic test strategies to test

common recurrent behavior that can be applied over

different applications after a conﬁguration step. This

is a black box testing approach with no access to the

source code of the applications under test. The test

https://www.fe.up.pt/˜apaiva/pbgtwiki/doku.php

cases are built from a model describing the testing

goals and afterwards the testing process is automated.

The research work presented in this paper extends

the concepts developed within the PBGT project for

testing the security aspects of the web applications,

i.e., it develops test strategies to test known security

patterns.

A survey about security issues and security pat-

terns served as the basis for the development of

generic test strategies to test security patterns on dif-

ferent web applications. This work presents the test

strategies deﬁned for two security patterns: “Authen-

tication Enforcer” and “Account Lockout”.

The remainder of this document covers state of the

art about security patterns in Section 2, presents the

contributions of the paper in Section 3, the validation

of PBST (Pattern Based Security Testing) through

case study is in Section 4 and ﬁnally some conclu-

sions in Section 5.

2 SECURITY PATTERS

Integrating security requirements at different stages

of the software development cycle is increasingly a

necessity and is a concern of both programmers and

stakeholders involved in the software development

process. However, there are still differences in how

security engineers and software engineers design the

472

Araújo, P. and Paiva, A.

Pattern based Web Security Testing.

DOI: 10.5220/0006606504720479

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 472-479

ISBN: 978-989-758-283-7

security requirements for a particular application.

There have been several methodologies that seek

to streamline and normalize the way to develop appli-

cations that require demanding quality requirements.

One of the most recent methodologies and one that

has an increasing number of adepts is the develop-

ment based on patterns.

Christopher Alexander (Alexander et al., 1977)

ﬁrst deﬁned patterns in architecture as a representa-

tion of the “current best guess as to what arrangement

of the physical environment will work to solve the

problem presented”. Generalizing this concept, one

can assert that a pattern is a recurring solution for a

recurring problem.

When considering security aspects (Heyman et al.,

2007a), security patterns can be deﬁned as reusable

solutions for security problems.

As Thomas et al. (Heyman et al., 2007b) said,

it is more reliable to use the security features already

known and tested than to invent ad-hoc solutions from

scratch. From the article “Measuring the level of se-

curity introduced by security standards” (Fern

andez

et al., 2010) we can also conclude that the use of stan-

dards brings signiﬁcant improvements in the ﬁnal se-

curity of the developed system.

Different authors present different ways of clas-

sifying security patterns according to their points of

view, and a good classiﬁcation of a pattern facilitates

the correct selection later.

Security patterns, according to Eduardo et al.

(Fernandez et al., 2008), can be grouped into the fol-

lowing categories: identiﬁcation and authentication,

access control and authorization, registration, encryp-

tion and intrusion detection.

J. Yoder and J. Barcalow (Yoder and Barcalow,

1998) present a collection of seven security patterns:

single access point; check point; roles; session; full

view with errors; limited view; secure access layer.

Darrel et al. (Kienzle et al., 2006) show a reposi-

tory of 26 patterns and 3 mini patterns, that are orga-

nized in two groups: structural patterns, and procedu-

ral patterns.

Other authors present collections of patterns

grouped/classiﬁed in different forms (Anand et al.,

2014), (Heyman et al., 2007a), (Slavin et al., 2012).

As Ina Schieferdecker et al (Schieferdecker et al.,

2012) state, security testing is intended to validate that

in an application the following security properties are

guaranteed: conﬁdentiality (guarantees the secrecy

of data), integrity (guarantees that data is not mod-

iﬁed in an unauthorized way), authenticity (be sure

about the identity of a person), availability (means

that data/services are available) and non-repudiation

(ensure that a transferred message has been sent and

received by the parties claiming to have sent and re-

ceived the message).

It is therefore necessary to test the application us-

ing white-box tests to discover code faults written by

the developers and also to use black-box tests, that

is, to try to act as an attacker by attempting to pen-

etrate the system and observing how the Application

behaves in the face of such attempts to intrude and/or

tamper with the data.

The research work described in this paper is based

on the work developed by the authors Munawar Haifz

et al. (Adamczyk et al., 2007), (Haﬁz et al., 2012)

which present the patterns organized by the STRIDE

threat model (developed by Microsoft). STRIDE

means Spooﬁng, Tampering, Repudiation, Informa-

tion Disclosure, Denial of Service, and Elevation of

Privileges.

• Spooﬁng is an attempt to gain access to any ap-

plication or system using a fake identity in which

a vulnerable system will give unauthorized access

to sensitive data.

• Tampering consists of tampering with data dur-

ing communication where data integrity is com-

promised.

• Repudiation arises when a user refuses to ac-

knowledge that he or she is the participant of a

particular transaction.

• Information Disclosure arises when conﬁdential

data is exposed or lost unintentionally.

• Denial of Service is to cause failures in system

availability.

• Elevation of Privileges arises when a user is able

to exploit a vulnerability and access data and re-

sources for which the same user does not have ac-

cess privileges.

For each of these aspects, the authors deﬁne a set

of security patterns. As an example, for Spooﬁng we

have: Account Lockout; Assertion Builder; Authen-

tications Enforcer; Brokered Authentication; Creden-

tial Tokenizer; Intercepting Web Agent; Message Re-

play Detection, and Network Address Blacklist.

As already mentioned, many of the patterns are

common among several approaches of different au-

thors. In the web page that is maintained by one of

the authors (SPC, 2017), one can obtain more de-

tails about each one of the patterns, the relationships

among them, as well as the totality of the patterns pro-

posed by them.

However, most of these patterns are frequently

disregarded in software development.

In recent years there has been an increase in the

number of security testing tools available, with tools

Pattern based Web Security Testing

473

focused on only one or a few vulnerabilities, and

others that seek to cover as many known vulnera-

bilities as possible. Some examples are Acunetix

(Acunetix, 2017), BeEF (BeEF, 2017), Burp Suite

(portswigger, 2017), Iron Wasp (ironwasp, 2017),

NetSparker (netsparker, 2017), SQLMap (sqlmap,

2017), Sqlninja (sqlninja, 2017), Vega (Vega, 2017),

W3af (w3af, 2017), Wapiti (wapiti, 2017), ZAP (ZAP,

2017).

However, as far as we know, none of them is or-

ganized by security patterns. That is why developing

a generic testing approach that is able to detect if the

security patterns were taken into account during de-

velopment and are well implemented may be useful.

3 PATTERN BASED SECURITY

TESTING

The purpose of this work is to test security patterns

following a black-box testing approach. The goal is

to deﬁne and implement generic test strategies that

are able to detect if security patterns were taken into

account during the development and, ultimately, con-

tribute for better software.

The security patterns that the PBST (Pattern

Based Security Testing) tool developed in this work is

able to test now are “Account Lockout” and “Authen-

tication Enforcer” as described in (Adamczyk et al.,

2007), (Haﬁz et al., 2012).

Account Lockout is intended to protect accounts

from automatic attacks based on the “guessing” of

passwords. When implementing a limit number of at-

tempts followed with wrong passwords for the same

user prevents or at least hampers the task of hackers.

To protect the systems against this attack one can lock

the account after N incorrect attempts.

Authentication Enforcer is responsible for authen-

ticating and verifying user identity. One way to pre-

vent impostors from accessing the system is by cre-

ating a single point of access where all requests to

enter the system are checked and apply an authenti-

cation protocol to verify the identity of the agent. On

successful authentication, create a proof of identity of

the agent (Haﬁz et al., 2012).

In order to check if these security patterns were

well implemented, a test strategy was deﬁned and will

be explained in more detail in subsection “Tester”.

The goal is to identify possible vulnerabilities that

report that a security pattern is not well implemented.

So, we started by grouping known vulnerabilities

around security patterns and afterwards deﬁned a set

of test strategies to detect those vulnerabilities.

3.1 Tool

The PBST testing tool has four main components:

Graphical User Interface, Explorer, Tester, Report

generator.

3.1.1 Graphical User Interface

The Graphical User Interface (GUI) establishes the

interaction with the testers / users. The main menu

of the tool is shown in Figure 1.

Figure 1: Menu of the PBST tool.

3.1.2 Explorer

The PBST tool starts by exploring the web application

under test trying to ﬁnd all its web pages.

For each discovered page it is necessary to collect

all the useful information available. Within this in-

formation there is, for example, the information con-

tained in the meta, script, link and form tags. In ad-

dition to the tags, we can also read comments that

may exist in the source code of the page in search

of possible keywords forgotten by the programmers

such as: query, password and user. Other information

to collect is the headers sent in the server response and

the cookies. The implementation needed to obtain the

cookies is not implemented in the current state of the

tool.

For each URL that is discovered by the explorer

process one or two accesses are made to the server,

ﬁrst without authentication and, in case of failure, an-

other one using the credentials provided to authenti-

cate. This procedure besides allowing to obtain infor-

mation of both public accessed pages also allows to

obtain information of pages of restricted access and

to catalog the pages like being of public access or of

private access.

Several threads were used to make this tracking

process as efﬁcient as possible. In order to not over-

load the system, only with this application, the num-

ber of threads thrown take into account the number

of processors, with as many threads as possible being

created in the processors on the computer where the

application is running.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

474

The search is performed using BFS (Breadth-First

Search) width lookup. Departing from the provided

URL (seed / root), all URLs achievable from it are

placed in a FIFO (First In, First Out) queue. For each

new URL of the web application found, we search

all URLs achievable from it and so forth. All the new

URLs found are placed at the end of the queue (only if

not yet explored). To know which URLs were already

explored (ensure that the same URL is not queued

twice), we maintain an auxiliary control list with all

already explored URLs. The search ends when the

queue is empty (when there are no more URLs to ex-

plore).

In addition, each analyzed URL is added to a list

to be tested by the attack and analysis (tester) compo-

nent. Two URLs are equal if they have the same base

URL, i.e., if they differ only in the arguments they are

considered the same.

The upper limit of URLs explored is deﬁned by

the tester.

3.1.3 Tester

After exploration, each page selected for testing is

tested according to the security patterns selected by

the tester. After the test is ﬁnished, information about

the success or failure of the test / attack is saved.

Although the application tests security patterns, in

reality what is done is to check whether or not the

application has a particular vulnerability related to a

security pattern. These vulnerability tests are grouped

around security patterns in order to ensure that a par-

ticular security pattern is present and whether or not

vulnerabilities related to that pattern are present. If no

vulnerabilities are detected in any of the tests selected

to test the security pattern in question then it is possi-

ble to say that it is not vulnerable (at least within the

vulnerabilities known at the moment and tested).

For the ”Account Lockout” standard only a test is

necessary. The goal is to try invalid login (username

and password) several times to check if the access is

blocked. This test strategy is detailed in Section “Ex-

periment”.

To validate the correct implementation of the “Au-

thentication Enforcer” security pattern, several tests

are necessary but only four

are developed related to

the following vulnerabilities: Clickjacking; Transport

Credentials; SQL Injection; Default Credentials. We

explain these vulnerabilities in more detail in the se-

quel.

• Clickjacking – This is when an attacker uses mul-

tiple transparent or opaque layers to fool a user.

So the attacker is to ”hijack” clicks to your page

www.owasp.org

and forward them to another page, probably be-

longing to another application, domain or both.

• Transport credentials – Testing the transport of

credentials means verifying that the user’s authen-

tication data is transferred through an encrypted

channel to avoid being intercepted by malicious

users. The analysis simply focuses on trying to

understand whether the data travels unencrypted

from the web browser to the server, or if the Web

application takes appropriate security measures

using a protocol such as HTTPS.

• SQL injection – It consists of the insertion or

“injection” of a partial or complete SQL query

through data entry or transmitted from the client

(browser) to the web application.

• Default credentials – Nowadays, it is common for

software applications to use popular open source

or commercial software that can be installed on

servers with minimal conﬁguration or customiza-

tion by the server administrator. In addition, many

hardware devices (for example, network routers

and database servers) offer web-based conﬁgu-

ration or administrative interfaces. Often, this

reused software/applications, once installed, is

not conﬁgured correctly and the default creden-

tials provided for initial authentication and conﬁg-

uration are never changed These default creden-

tials are well known to penetration testers and, un-

fortunately, also by malicious attackers who can

use them to gain access to various types of appli-

cations.

To identify the presence of these vulnerabilities,

we developed generic test strategies for each of the

them. When one of these vulnerabilities is detected

by the tests, it is possible to say that the application

under test has an incorrect implementation of the “Au-

thentication Enforcer” pattern.

Clickjacking

To test the clickjacking vulnerability, the headers of

the AUT are scanned to see if the “x-frame-options”

option is present. If this header is not present the ap-

plication is potentially vulnerable to clickjacking un-

less other mechanisms are implemented that prevent it

from being able to place the application inside a frame

of another application (malicious application).

Transport Credentials

In order for an application not to be vulnerable while

sending the access credentials to the server, they must

be sent using the POST method and the transport

Pattern based Web Security Testing

475

channel must be secure, so the HTTPS protocol must

be used. In this way, to validate whether or not an ap-

plication has this vulnerability, an analysis is made of

the authentication form in order to check which pro-

tocol is used to send the credentials to the server.

SQL Injection and Default Credentials

The security tests of SQL Injection are tests that at-

tempt to log in via SQL sent, as access attempts, in

the username and password. For this test, we used

the list of possible strings to input as username and

password shown in Figure 2.

Figure 2: Strings used in SQL Injection for username and

password ﬁelds.

The security tests of Default Credentials attempt

to log in via default words sent as access attempts in

the username and password. Default words are used,

for instance, in test environments and, several times,

forgotten going to production which allows improper

accesses to the software in production. To test if it

is possible to log in with default credentials the list

of strings shown in Figure 3 was used (the quotation

marks are not part of the string):

Figure 3: Default values used in username and password

ﬁelds.

The tool tests all the combinations of username

and password shown in Figure 3 and also repetition

of the same word, e.g., adminadmin, which are also

common as default words.

Account Lockout

To test the “Account Lockout” pattern, it is only nec-

essary to perform a test. This test consists of trying to

enter a wrong login data three times (the same login

with different wrong passwords). After three invalid

attempts, a correct access with the correct credentials

is done. If the access is successful then we already

know that the application does not block after three

invalid attempts. In this case, the test is repeated, but

this time with ﬁve invalid attempts followed by the

sixth attempt with the correct credentials. In this case,

if the sixth access is successful then we can consider

that the application has vulnerabilities in the pattern

“Account Lockout”, because the security pattern ad-

vises to block the application after three or ﬁve invalid

attempts.

3.1.4 Report Generator

Figure 4 shows a report generated after a test per-

formed to a website with only six pages. The report

shows the URL of the AUT, the number of pages clas-

siﬁed as public or private, the number of URLs se-

lected for testing and tested, part of the list of security

patterns “Not tested”, the result of the test for the web

pages tested and the details about the vulnerabilities

detected for each of the tested patterns. In this Fig-

ure 4, it can be seen that for the TdinApp both tested

patterns are identiﬁed as vulnerable and regarding the

“Account Lockout” pattern, all vulnerabilities tested

for this pattern were detected.

Finally, it is also possible to see that, right now, all

security patterns except “Account Lockout” and “Au-

thentication Enforcer” are not yet implemented and

because of that “Not tested”.

4 CASE STUDY

The goal of this case study is to validate the PBST

testing approach, namely:

• Assess how the PBST tool behaves when varying

the upper limit of web pages to explore;

• Assess if the PBST tool is able to detect vulner-

abilities and if the ones detected are actually real

vulnerabilities (true positives).

Current Restrictions of the PBST Tool

At this point in time, the application only tests web

pages containing forms, without using JavaScript, and

pages where the authentication mechanism is done

only by the use of username and password. Because

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

476

Figure 4: Report generated.

of these limitations, the explorer phase selects only

the pages that meet these requirements for testing.

4.1 Subjects

In order to validate the testing approach developed,

we selected ﬁve web applications public available:

• SIGARRA – is the information system of the Uni-

versity of Porto and was selected because it is a

large application that presents the authentication

form on many of its web pages.

• jigsawplanet – this application was selected after

an Internet search for free applications and it was

referenced on a page that advertises various appli-

cations.

• TdinApp – this application was created in a

project of the discipline of Distribution and Inte-

gration Technologies. Since we had access to the

source code, this application was useful to check

if the results obtained by the PBST tool were al-

tered if a vulnerability was removed. This appli-

cation was only available on localhost.

• acunetix – this application was selected because

it was created with the purpose of being used to

validate test tools or for the training of security

testing specialists (e.g., testasp). This application

contain several security vulnerabilities. There is a

blog where you can ﬁnd this and other test pages.

• testﬁre – this application was selected because the

same reasons as acunetix above.

4.2 Experiment

The experiment was divided in three phases:

• the ﬁrst phase aimed to test the explorer compo-

nent;

• the second phase aimed to test the explorer and

the testing of the two patterns: “Authentication

Enforcer” and “Account Lockout”;

• the third phase aimed to test the overall process.

4.2.1 First Phase

The tests in this phase are intended to verify how

the application behaves when varying the number of

pages to test (the upper limit of pages to visit is a pa-

rameter deﬁned by the tester). We used three of the

subjects. During this experiment, we extracted met-

rics such as time and quantities of pages selected for

testing (according to the actual restrictions of the tool

already mentioned). The results are in Figure 5.

Figure 5: Time taken in seconds.

Figure 6 shows the number of pages that were se-

lected for testing within the search limit.

Figure 6: Pages selected for test.

4.2.2 Second Phase

During this phase we tested the “Authentication En-

forcer” and the following vulnerabilities: “clickjack-

ing”, “credentials transport”, “SQL Injection” and

“default credentials”.

To verify that the application actually detects the

“clickjacking” vulnerability, a script has been created

Pattern based Web Security Testing

477

Figure 7: Script to conﬁrm clickjacking vulnerability.

to run manually and to make sure the result of the test

was correct (Figure 7).

Within the group of pages marked, by the PBST

application, as containing the “clickjacking” vulnera-

bility, we selected some to verify if with the auxiliary

script it was possible to place the application within

a frame. All the pages checked by this process con-

ﬁrm that the result of the test was correct. Indeed, the

pages marked as vulnerable were in fact vulnerable.

We also checked if the result of the test was correct

for the pages marked has not vulnerable. Indeed, for

these pages it was not possible to place them inside a

frame so, the result of the test was correct.

When the PBST detects a vulnerability regarding

SQL injection it provides information about the string

used that allowed the detection of the vulnerability.

In case of the “testﬁre” such string was ’ or’ ”&’. In

the case of the “Default Credentials” vulnerability, the

application also provides the strings used for the user-

name and for the password. In the case of “testﬁre”

such strings were admin and admin.

Considering the whole set of applications tested,

the only one that did not present any of the vulnerabil-

ities of the pattern “Authentication Enforcer” was the

application “jigsawplanet”. For all the others some

vulnerabilities were detected. In particular, the ap-

plication testﬁre had all the vulnerabilities associated

with this test can be seen in Figure 4.

4.2.3 Third Phase

At this phase the exploration and testing of the two

patterns were tested. This phase is necessary and

complements the previous one because the lockout

test can only be performed after all the rest is ﬁnished.

Regarding the application “jigsawplanet”, it is se-

cure for “Authentication Enforcer” but vulnerable for

“Account Lockout”.

In order to check if the “Account Lockout” pat-

tern was well detected, we manipulated the applica-

tion “TdinApp”. We obtained results according to the

manipulation which conﬁrms the correctness of the

testing strategy.

5 CONCLUSIONS

This paper presented a new approach to test secu-

rity aspects of web applications organized by secu-

rity patterns. The patterns implemented right now are

the “Authentication Enforcer’ (which checks vulner-

abilities related to clickjacking, transport credentials,

SQL Injection and Default Credentials) and “Account

Lockout” (which checks if the application blocks af-

ter three or ﬁve invalid login attempts).

Grouping vulnerability testing into security pat-

terns can be an asset to a test application in that it

is thus possible to assert that at the time the test was

performed and for known vulnerabilities at that time,

the application is either “safe” / “well implemented”

or “Not safe” / “Not well implemented” regarding a

certain security pattern. This structure may help the

programmers to identify which aspects they have to

improve in order to ﬁx the problems detected. An-

other advantage is that it may be a requirement for

a particular application to have certain security pat-

terns, but at the same time there may be others that are

irrelevant, so that having the tests grouped by patterns

allows an easily selection of the group of vulnerabili-

ties that are necessary to test.

This paper explains how the PBST tool works and

presents a case study to validate the overall approach.

From the experiments performed, it is possible to state

that PBST is able to identify vulnerabilities success-

fully. Of course, the application still needs a lot of de-

velopment to extend the number of security patterns

tested and be a really useful tool.

During the validation phase we tested the PBST

tool over ﬁve applications and the results were

promising. We detected vulnerabilities and conﬁrmed

that the vulnerabilities detected corresponded to real

problems.

Excluding Sigarra application and according to

the experiments, it is possible to say that the time

spent with the exploration increases linearly with the

upper limit of pages to visit. Of course, this time is

also inﬂuenced by other factors such as the process-

ing capacity of the computer, the Internet connection

and the speed of response of the Server where the ap-

plication is hosted.

As future work we aim to extend the set of security

patterns to test because, at this point in time, some

vulnerabilities may be undetected.

The exploration needs also improvements since

we have restrictions regarding the web pages we are

able to test right now which need to be overcome.

Right now the exploration stops when the tester

presses a button for that or when the exploration

reaches the upper limit of pages to visit. In the fu-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

478

ture it may the helpful to have time limit.

Finally, we aim to test the overall approach over

more web applications.

REFERENCES

Acunetix (2017). Advanced penetration testing tools

included. http://www.acunetix.com/vulnerability-

scanner/penetration-testing/. [Accessed on

12/7/2017].

Adamczyk, P., Haﬁz, M., and Johnson, R. E. (2007). Orga-

nizing security patterns. IEEE Software, 24:52–60.

Alexander, C. W., Ishikawa, S., Silverstein, M., and Jacob-

son, M. (1977). A Pattern Language: Towns, Build-

ings, Construction. Oxford University Press, New

York, New York, USA, 1 edition.

Anand, P., Ryoo, J., and Kazman, R. (2014). Vulnerability-

based security pattern categorization in search of

missing patterns. In Proceedings of the 2014 Ninth

International Conference on Availability, Reliability

and Security, ARES ’14, pages 476–483, Washington,

DC, USA. IEEE Computer Society.

BeEF (2017). The browser exploitation framework project.

//beefproject.com/. [Accessed on 27/7/2017].

Fernandez, E. B., Washizaki, H., Yoshioka, N., Kubo, A.,

and Fukazawa, Y. (2008). Classifying Security Pat-

terns, pages 342–347. Springer Berlin Heidelberg,

Berlin, Heidelberg.

Fern

andez, E. B., Yoshioka, N., Washizaki, H., and Van-

Hilst, M. (2010). Measuring the level of security in-

troduced by security patterns. In ARES 2010, Fifth

International Conference on Availability, Reliability

and Security, 15-18 February 2010, Krakow, Poland,

pages 565–568.

Haﬁz, M., Adamczyk, P., and Johnson, R. E. (2012). Grow-

ing a pattern language (for security). In Proceedings

of the ACM International Symposium on New Ideas,

New Paradigms, and Reﬂections on Programming and

Software, Onward! 2012, pages 139–158, New York,

NY, USA. ACM.

Heyman, T., Yskout, K., Scandariato, R., and Joosen, W.

(2007a). An analysis of the security patterns land-

scape. In Third International Workshop on Software

Engineering for Secure Systems, SESS 2007, Min-

neapolis, MN, USA, May 20-26, 2007, page 3.

Heyman, T., Yskout, K., Scandariato, R., and Joosen, W.

(2007b). An analysis of the security patterns land-

scape. In Proceedings of the Third International

Workshop on Software Engineering for Secure Sys-

tems, SESS ’07, pages 3–, Washington, DC, USA.

IEEE Computer Society.

ironwasp (2017). Iron web application advanced secu-

rity testing platform. //ironwasp.org/. [Accessed on

27/7/2017].

Kienzle, D. M., Elder, M. C., D, P., D, P., Tyree,

D., and Edwards-hewitt, J. (2006). Security pat-

terns repository, version 1.0. http://www.scrypt.

net/celer/securitypatterns/repository.pdf. [Accessed

on: 12/7/2017].

Moreira, R., C.R. Paiva, A., and Memon, A. (2013). A

pattern-based approach for gui modeling and test-

ing. In 2013 IEEE 24th International Symposium on

Software Reliability Engineering, ISSRE 2013, pages

288–297.

Moreira, R. M. L. M., Paiva, A. C. R., Nabuco, M., and

Memon, A. (2017). Pattern-based GUI testing: Bridg-

ing the gap between design and quality assurance.

Softw. Test., Verif. Reliab., 27(3).

netsparker (2017). Netsparker web application security

scanner. //www.netsparker.com/. [Accessed on

27/7/2017].

Paiva, A. C. R. and Vilela, L. (2017). Multidimensional test

coverage analysis: PARADIGM-COV tool. Cluster

Computing, 20(1):633–649.

portswigger (2017). Automated crawl and scan. //portswig-

ger.net/burp/. [Accessed on 27/7/2017].

Schieferdecker, I., Grossmann, J., and Schneider, M. A.

(2012). Model-based security testing. In Proceedings

7th Workshop on Model-Based Testing, MBT 2012,

Tallinn, Estonia, 25 March 2012., pages 1–12.

Slavin, R., Shen, H., and Niu, J. (2012). Characteriza-

tions and boundaries of security requirements pat-

terns, pages 48–53.

SPC (2017). Security Pattern Catalog. http://munawarhaﬁz.

com/securitypatterncatalog/index.php. [Accessed on:

12/7/2017].

sqlmap (2017). Automatic sql injection and database

takeover tool. //sqlmap.org/. [Accessed on

27/7/2017].

sqlninja (2017). A sql server injection and takeover tool.

//sqlninja.sourceforge.net/. [Accessed on 27/7/2017].

Utting, M. and Legeard, B. (2007). Practical Model-Based

Testing: A Tools Approach. Morgan Kaufmann Pub-

lishers Inc., San Francisco, CA, USA.

Vega (2017). vega vulnerability scanner. //sub-

graph.com/vega. [Accessed on 27/7/2017].

w3af (2017). w3af. //w3af.org/. [Accessed on 27/7/2017].

wapiti (2017). Wapiti – the web-application vulnerabil-

ity scanner. //wapiti.sourceforge.net/. [Accessed on

27/7/2017].

Yoder, J. and Barcalow, J. (1998). Architectural patterns for

enabling application security.

ZAP (2017). The owasp zed attack proxy (zap).

//www.zaproxy.org/. [Accessed on 27/7/2017].

Pattern based Web Security Testing

479