FINAL PROJECT REPORT

IDENTIFYING
SECURITY ISSUES IN
WEBSITES
2014/2015
BY: ABDUL SAMAD
UNIVERSITY OF WOLVERHAMPTON
BSC (HONS) INFORMATION TECHNOLOGY SECURITY

~ 1 ~
Student Name:
Abdul Samad
Student Number:
1204585
Module Code:
6CS007
Module Name:
Project and Professionalism
Project Title:
Identifying security issues in websites
Award Title:
BSc (Hons) Information Technology Security

~ 2 ~
Abstract
As the internet has grown there has been a huge increase in web applications, such as mail
services and online banking. In turn, web services can often bring with them security issues
or software bugs such as SQL injection, cross-site scripting, security misconfiguration and
broken authentication, and certain security vulnerabilities are open to being exploited
maliciously. In fact, studies have revealed that as much as 90% of all websites are leaving
themselves open to the threat of hacking and associated security breaches, frequently due to
inexperience or unwillingness to spend money on security.
Often, lack of experience, or more particularly, time constraints in developers either not fully
trained or not specialised, can lead to certain security concerns being overlooked.
Furthermore, previous research indicates that many vulnerabilities can remain undetected
even when using popular detection tools
This paper will evaluate common web application attacks, existing tools and approaches to
web security together with the issues faced, and assess potential means of better identifying
security issues in websites such as the implementation of penetration testing and targeting
SQL Injection vulnerabilities. These methods frequently achieve a much higher rate of
success than web security scanning techniques and can perform much better than traditional
commercially used tools.
Also referenced are sources in relation to common reasons for issues with website security,
and often implemented solutions.

~ 3 ~
Contents
Chapter 1 –Introduction.............................................................................................................7
1.1 Academicquestion.........................................................................................................7
1.2 Aims& objectives...........................................................................................................7
1.3 MinimumRequirements................................................................................................8
1.4 ProjectExtensions..........................................................................................................6
1.5 Methodology..................................................................................................................8
1.5.1 The Spiral Model ...........................................................................................9
1.5.2 The Waterfall Model......................................................................................9
1.5.3 ModifiedWaterfall Model..............................................................................9
1.5.4 Conclusionand adopted Methodology..........................................................9
Chapter 2 – Background Research..............................................................................................11
2.1 Overview........................................................................................................................11
2.2 VulnerabilityAssessment...............................................................................................11
2.3 The Basics of Hacking andPenetrationTesting..............................................................12
2.4 Commonwebsite securityattackmethods………………………………………………………………..12
2.4.1 SQL Injection..................................................................................................12
2.4.2 Cross-site scripting.........................................................................................13
2.4.3 Unvalidatedredirects.....................................................................................13
2.4.4 AutoSuggest..................................................................................................13
2.4.5 DirectoryListing.............................................................................................14
2.5 Common mistakes.........................................................................................................14
2.6 Evaluationof existingmaterial/methods......................................................................15
2.7 Summary........................................................................................................................19
Chapter 3 – Design Development...............................................................................................20
3.1 Overview........................................................................................................................20
3.2 Artefactdesignoverview...............................................................................................20
3.2.1 Homepage design...........................................................................................21
3.2.2 Scan Complete Design…………………………………………………………………………….….21

~ 4 ~
3.2.3 Port scanner page design…………………………………………………………………………..22
3.2.4 Port Scan Complete Page Design……………………………………………………………….22
3.2.5 About Page Design…………………………………………………………………………………….23
3.2.6 FAQ’s Page Design……………………………………………………………………………………..24
3.2.7 Contact Us Page Design……………………………………………………………………………..24
3.3 Activity diagram for vulnerability scanning……………………………………………………………....25
3.4 Activity diagram for scanning ports…………………………………………………………………………..26
Chapter 4 – Implementation / Tools..........................................................................................27
4.1 Overview……………………….………………………………………………………………………………………….27
4.2 Home page Implementation………………………………………………………………………………….....27
4.3 Web Crawler Implementation…………………………………………………………………………………..28
4.4 Http Banner Implementation…………………………………………………………………………………….28
4.5 Auto complete Implementation………………………………………………………………………………..30
4.6 SQL Injection Implementation…………………………………………………………………………………..31
4.7 Unvalidated Redirects……………………………………………………………………………………………….33
4.8 Tools Used…………………………………………………………………………………………………….............33
4.8.1 WAMP Server…………………………………………………………………………………………...33
4.8.2 Windows 8………………………………………………………………………………………………..33
4.8.3 Notepad ++……………………………………………………………………………………………….33
4.8.4 Google Chrome………………………………………………………………………………………...33
4.8.5 Internet Explorer……………………………………………………………………………………….34
4.8.6 Mozilla Fire Fox………………………………………………………………………………………...34
Chapter 5 – Testing………………………….........................................................................................35
5.1 Overview…………………………………………………………………………………………………………………..35
5.2 Testing the Artefact…………………………………………………………………………………………………..35
5.2.1 Test 1…………………………………………………………………………………………………………35
5.2.2 Test 2…………………………………………………………………………………………………………36
5.3.3 Test 3…………………………………………………………………………………………………………37
5.3.4 Test 4…………………………………………………………………………………………………………38
5.3.5 Test 5…………………………………………………………………………………………………………39
5.3.6 Test 6…………………………………………………………………………………………………………40

~ 5 ~
5.3.7 Test 7…………………………………………………………………………………………………………41
5.2.8 Test 8…………………………………………………………………………………………………………42
5.3.9 Test 9…………………………………………………………………………………………………………43
5.3 Testing for vulnerability detection………………………………………………………………………….…44
5.3.1 Test 1…………………………………………………………………………………………………………44
5.3.2 Test 2………………………………………………………………………………………………………..46
5.3.3 Test 3………………………………………………………………………………………………………..47
5.3.4 Test 4………………………………………………………………………………………………………..49
5.3.5 Test 5………………………………………………………………………………………………………..50
Chapter 6 – Evaluation…………………………...................................................................................52
6.1 Introduction …………………………………………………………………………………………………………….52
6.2 Effectiveness of Methodology…………………………………………………………………………………..52
6.3 Project management…………………………………………………………………………………………………52
6.4 Minimum Requirements Analysis……………………………………………………………………………..53
6.5 Possible Enhancements Analysis……………………………………………………………………………….54
6.6 Comparison to Other Solutions…………………………………………………………………………………54
6.7 Comparison against Original Plan……………………………………………………………………………..54
6.8 Future Developments……………………………………………………………………………………………….55
6.9 Summary…………………………………………………………………………………………………………………..56
Chapter 7 – Conclusion…………………………...................................................................................57
7.1 Answeringthe academicquestion……………………………………………………………………….……57
7.2 Self-reflection……………………………………………………………………………………………………….….58
7.3 Overall Evaluation…………………………………………………………………………………………………….58
References………………..…………………………...................................................................................59
Appendix…………………..…………………………...................................................................................62

~ 6 ~
Chapter 1
Introduction
In recent years, there has been a tremendous increase in online security threats as the internet
has become a part of everyday life for millions. The internet is used for many different
purposes, as there are websites where people shop, conduct banking, manage their healthcare,
pay insurance, and book travel. Yet internet security is becoming a major threat to not only
businesses but also users, as users may use a website to do some shopping and submit their
card details without considering if the website is secure. This also applies to businesses who
trade online and do not consider the security of their website as important or are just not
aware of how secure their website is.
Online security plays a crucial role for all types of websites. Those which hold confidential
information and even websites which don’t hold any confidential data can be at a huge risk.
The reason for this is that if the website security is weak and is subsequently hacked or
infected, it can bring the website down or can result in confidential data being leaked. This
problem can lead to massive losses either financially or by losing customers/users. It is a
legal requirement for businesses to ensure that any customer data collected must be kept
secure or the business (big or small) can be held liable. One such law in the UK which states
and enforces this is the Data Protection Act.
1.1 Academic question
The academic question this project will be answering is “Can an easy to use web application
be developed in order to detect common security threats in websites?”
1.2 Aims and Objective
The overall aim of this project is to design and develop a working prototype of a website
vulnerability scanner which allows users to scan their website and detect if the website is
secure or vulnerable. Also an important aim of this project is to provide the user with a report
with a description explaining what the detected vulnerability is while providing
recommendations on how to fix the vulnerability.
In order to achieve this aim, there are some important objectives which need to be followed:
 Research into different existing vulnerability scanners.
 Research into different methods of creating a vulnerability scanner.
 Work to design and develop a security scanning web app that uses open source
libraries.
 Work to create a web application to scan for common security threats.
 Work to provide the user with a feedback report.
 The finished artefact should be able to detect the following vulnerabilities:
 HTTP Banner
 SQL injection
 Unvalidated redirects
 Auto suggest
 Directory listing

~ 7 ~
1.3 Minimum Requirements
The minimum requirements are:
1. To produce a working prototype of a website vulnerability scanner which will provide the
user with a report that will explain the vulnerabilities, show the risk level
(high/medium/low) and provide the user with a viable solution.
2. The finished prototype should have the following pages:
 Home
 About
 FAQ’s
 Contact us
3. Finished artefact should be able to detect the following vulnerabilities:
 HTTP Banner
 SQL injection
 Auto suggest
 Port scanning
1.4 Possible extensions are:
1. To detect more vulnerabilities such as:
 Username enumeration
 Remote code execution
 DoS attacks
2. To create more web pages which will help users understand security and the importance
of security in the cyber world. Also the creation of a webpage which will give users tips
on how to improve their website security and accessibility.
1.5 Methodology
To ensure the project is completed successfully and meets the set deadline a firm plan must
be created and followed, therefore it is essential a software development methodology is
adopted. A software development methodology is basically a structure of different phases of
a life cycle as it helps define aims and objectives of each phase and makes it clear to the user
what must be completed before moving on to the next phase. The aim of a methodology is to
advance the progress and quality of the system it is applied to. Once the correct mythology is
adopted and followed it will help ensure a number of things such as:
 The project meets user requirements
 The project is efficiently produced
 The project meets set deadlines
However by adopting a software development methodology does not guarantee the success of
the project but can improve the chances of the projects success if it is followed properly. The
following two methodologies

~ 8 ~
1.5.1 The Spiral Model
The spiral model is a systems development lifecycle model which is used for developing
systems. The spiral model includes a combination of features from the prototyping model &
the waterfall model. This model is commonly used for big, expensive and high risk projects.
A typical Spiral model has four phases:
1. Define the objectives, alternatives and constraints.
2. Risk analysis and evaluation of alternatives.
3. Execution of that phase of development.
4. Planning the next phase.
1.5.2 The Waterfall Model
The waterfall model is a very common and a widely used methodology, this was developed
for software development. This mythology is commonly used for smaller projects and can be
very beneficial towards a project as each phase of the model must be complete before
proceeding to the next phase which allows the developer to detect any problems in each
phase however, due to the restrictions on the model it prevents the developer from going back
a stage to revise any problems detected later in the project. The typical stages of a waterfall
model are:
1 Requirement analysis
2 System design
3 Implementation
4 Testing
5 Deployment
6 Maintenance
1.5.3 Modified Waterfall Model (Sashimi)
The Sashimi waterfall model is a modified version of the original Waterfall model. This
model consists of the same stages of the original however it has a lot more flexibility as it
allows the developer to revisit stages and make adjustments also it allow the developer to
overlap stages if needed which means it is not strict however because of less restrictions it
become harder to manage the project.
1.5.4 Conclusion and adopted Methodology
Due to the size of the project being relatively small, the software development methodology
that will been adapted for this project is the modified Sashimi Waterfall model, the reason for
this is because it is pre-set with phases that should take place when a system is being built
also the simplicity of following the waterfall model is also an advantage as there is a
progressive order to each step which allows the user to re-visit previous stages from any stage
this makes the Waterfall model very flexible, shown in Figure 1-1. The Sashimi Waterfall
model will allow for a better flow through the project, and allow for clear feedback

~ 9 ~
throughout. Even though the spiral model does offer flexibility it is generally made for bigger
projects and would not be suitable for this project.
Figure 1-1 Waterfall Model

~ 10 ~
Chapter 2
Background Research
2.1 Overview
This chapter includes all the background work and research that was done in order to
complete this project. This chapter also includes research in the common threats, tools which
help detect threats also similar existing products on the market.
2.2 Vulnerability Assessment
Analysing security issues with websites, also known as vulnerability assessment, involves a
system of identifying, classifying and rectifying the security breaches and vulnerabilities in
any computer or network. Using this vulnerability analysis we can also evaluate any proposed
methods to counter the breach in security, in addition to assessing actual effectiveness after
security changes are implemented.
As the internet has now become such an integral part of everyday life, internet security is
imperative with the vast amount of shopping, banking, and trade conducted online. This is
important not only for those who retail or trade online but also for those who shop and
purchase via these websites, as card transactions are made often without consideration of the
security of the website.
Approximately 90% of online shops are subject to break-ins. As Pune Mirror, (2014) stated:
“A recent study, conducted by a city-based cyber security consulting firm revealed that 90
per cent of the sites doing online business are vulnerable to threats from hackers and as small
businesses are reluctant to spend on securing their websites, they face the risk of exposing
details of their customers to hackers”(Pune Mirror, 2014).
Small businesses are especially susceptible. As Grossman (2014) wrote, “Small business
owners are often lulled into a false sense of security, thinking that only major retailers, banks
and healthcare companies are at risk. For example, the Heartbleed Bug, disclosed in April of
2014, left nearly half a million secure web servers vulnerable to attack including those used
by thousands of small business owners,” (Grossman, 2014).
This journal explains how to reduce the risk of a cyber-security breach has helped me widen
my understanding of reducing risk of hacking and can be used to implement in this project to
help ensure the artefact can be efficient and to aim it to reduce the risk of hacking by
scanning for all the major known vulnerabilities.
Vulnerability analysis is conducted via the following:
1. Identifying and classifying relevant network or system resources
2. Assigning specific levels of importance to the resources
3. Identifying any potential threats to each resource
4. Developing a strategy to deal with serious potential breaches in security foremost, and
implement methods to lessen any consequences of potential attacks

~ 11 ~
5. Vulnerability analysis is often performed using ethical white hat hacking techniques,
whereby using this method to assess any vulnerabilities, security experts would
deliberately test and probe a network or system in order to discover its weaknesses.
Using this process enables guidelines for the development of suitable
countermeasures to prevent a genuine attack.
2.3 The Basics of Hacking and Penetration Testing
Engebretson 2013 states, “Penetration testing can be defined as a legal and authorized attempt
to locate and successfully exploit computer systems for the purpose of making those systems
more secure. The process includes probing for vulnerabilities as well as providing proof of
concept attacks to demonstrate the vulnerabilities are real. Proper penetration testing always
ends with specific recommendations for addressing and fixing the issues that were discovered
during the test. On the whole, this process is used to help secure computers and networks
against future attacks. The general idea is to find security issues by using the same tools and
techniques as an attacker. These findings can then be mitigated before a real hacker exploits
them...” (Engebretson, 2013).
This book helped understand the basics of penetration testing to test against hacking in a
website or programs, and how to address issues regarding hacking and different
vulnerabilities. As Engebretson outlines the different techniques to help tackle hacking he has
given a greater understanding of penetration testing which is very useful to this project as it is
based on testing websites for common security threats.
2.4 Common website security attack methods
Here I will discuss the common attack methods that threaten website security.
“This article looks at five common Web application attacks, primarily for PHP applications,
and then presents a case study of a vulnerable Website that was found through Google and
easily exploited. Each of the attacks we'll cover are part of a wide field of study, and readers
are advised to follow the references listed in each section for further reading. It is important
for Web developers and administrators to have a thorough knowledge of these attacks. It
should also be noted that that Web applications can be subjected to many more attacks than
just those listed here.
While most of the illustrated examples in this article will discuss PHP coding due to its
overwhelming popularity on the Web, the concepts also apply to any programming language.
The attacks explained in this article are:
 SQL Injection
 Cross Site Scripting (XSS)
 Unvalidated Redirects
 Auto Suggest
 Directory Listing
2.4.1 SQL Injection
Injection flaws result from a classic failure to filter dubious input. It can occur when you pass
unfiltered data to the SQL server, to the browser, to the LDAP server (LDAP injection), or in
fact anywhere else. The attacker can inject direct commands resulting in loss of data and
subsequently hijacking clients’ browsers.

~ 12 ~
Therefore anything that your application gets from untested or unknown sources should be
filtered, and this should preferably be filtered according to a whitelist. You should hardly
ever use a blacklist, as getting that right is very hard and usually it’s easy to bypass. Antivirus
software products typically provide prime examples of failing blacklists.
2.4.2 Cross-site scripting
A fairly common input sanitization failure is Cross Site Scripting (XSS) where an attacker
can give your web application JavaScript tags on input. When this input is returned to the
user un-sanitised then the user’s browser executes it. It can be as simple as crafting a link and
persuading a user to click it or it can be something much more deep and troublesome. On
page load the script runs and could be used be used to post your cookies to the attacker.
“By exploiting a Cross-site scripting vulnerability the attacker can hijack a logged in user’s
session. This means that the malicious hacker can change the logged in user’s password and
invalidate the session of the victim while the hacker maintains access.”(Netsparker, 2014).
2.4.3 Unvalidated redirects
According to (Owasp, 2014) “Unvalidated redirects and forwards are possible when a web
application accepts untrusted input that could cause the web application to redirect the
request to a URL contained within untrusted input. By modifying untrusted URL input to a
malicious site, an attacker may successfully launch a phishing scam and steal user
credentials”. This article proves the importance of being able to detect if websites are
vulnerable to unvalidated redirects.
2.4.4 Auto Suggest
According to (Hackavoid, 2013) “Many websites have a login form where users provide
username and password. The default behaviour for browsers is to allow users to store these
credentials locally in the browser. Thereby, the next time a similar form appears, the
username and password are already populated as seen in Figure 1. This is easy for the user
but not secure.
Figure 2.1: Auto Suggest (Hackavoid, 2013)
First of all it is very easy to retrieve the password in clear-text. You can try to go to a page
where you may have stored a username and password. In most browsers you can right-click
on the password field and select “Inspect element”. This brings up some of the HTML source
code. There is an attribute named “type” with the value “password”. Replace the value with
“text” and you will see the password in clear-text”. This article explains how easy it can be
for a hacker to retrieve passwords when auto suggest is not configured correctly, this is a very
common vulnerability which most website can vulnerable to and don't know it”.

~ 13 ~
2.4.5 Directory Listing
Directory listings may disclose information about the web application and its environment
that was not intended to be public. While browsing web pages, most of us expect to see only
the pages offered. However sometimes we come upon what looks like a listing of files that
we might see in Windows Explorer as opposed to a web page. This is called a directory
listing. It is sometimes used to offer files easily on the internet, but if unintended, it can allow
an attacker to gain valuable information about your site.
2.5 Common mistakes
This project is a web application which will allow users to scan their websites, and by
scanning their website it will be checking their site mainly to assess how strong or weak the
level of security is. After it has completed the scan it will provide feedback by showing ways
of improving security and showing you any errors in the website, the main goal is to create a
simple interface which a user can interact with and use efficiently, but without causing
confusion and problems as do several programs that are available to buy on the market...
Security misconfiguration is another common problem with web servers and applications
with many more having been misconfigured than those that have been configured correctly.
Common mistakes pertaining to this are:
 Running the application with debug enabled in production.
 Having directory listing enabled on the server, which leaks valuable information.
 Running outdated software including plugins.
 Having unnecessary services running on the machine.
 Not changing passwords or default keys and passwords
 Revealing error handling information to the attackers, for example, stack traces.
 Top of Form
 Bottom of Form (Red hat, 2014)
There are many other common mistakes which, if more attention were given at the beginning,
would make the issue of website security that much simpler. Examples of this include
Missing Function Level Access Control, which is basically an authorisation failure. Cross
Site Request Forgery (CSRF) where the browser is tricked by another party into misusing its
authority. Unvalidated redirects and forwards, which more often than not lead to pages
infected with malware waiting to be dropped on you. And of course, using components with
known vulnerabilities.
To summarize, the majority of website security issues can be attributed to the following:
1. Unvalidated parameters: Many attackers often exploit this vulnerability and achieve
access to back-end components. Here we can see that information from Web requests
is not validated before being used by a Web application.
2. Broken access control: An exploit to this flaw could give an outsider access to user
accounts, sensitive files or functions. Here, restrictions on what actions users may
take are not enforced.
3. Broken account and sessionmanagement: Attackers exploiting this hole can access
passwords, keys, session cookies and other tokens to gain account credentials.
4. Cross-site scripting (XSS) flaws: A cracker may exploit one of these flaws to use a
Web application to transport an attack to a user's browser. This flaw can expose a
local machine or enable an attacker to spoof content.

~ 14 ~
5. Buffer overflows: Overrunning a buffer in a Web application could enable an
attacker to take control of processes like CGI, libraries, drivers and Web application
server components.
6. Command injection flaws: Attackers exploit this flaw by injecting malicious
commands via a Web application. As the application passes parameters while
accessing an external system or local operating system, those systems may be fooled
into executing the malicious commands.
7. Error-handling problems: Error conditions that happen during normal use are not
handled properly by a Web application. An attacker may cause an error to occur and
create a denial-of-service condition.
8. Insecure use of cryptography: Web cryptography fails to protect information and
credentials.
9. Remote administration flaws: Attackers may exploit weak remote administration
functions to gain root access to a Web site.
10. Web and application server misconfiguration: Server configuration is weak out-of-
the-box and administrators need to secure Web applications manually. (Michael, 2003)
2.6 Evaluation of existing material/ methods
Vulnerability scanner
“A vulnerability scanner relies on a database that contains all the information required to
check a system for security holes in services and ports, anomalies in packet construction, and
potential paths to exploitable programs or scripts. Then the scanner tries to exploit each
vulnerability that is discovered. This process is sometimes called ethical hacking” (Rouse,
2014)
An ideal vulnerability scanner has capabilities such as the following:
 Maintenance of an up-to-date database of vulnerabilities.
 Detection of genuine vulnerabilities without an excessive number of false positives.
 Ability to conduct multiple scans simultaneously.
 Ability to perform trend analyses and provide clear reports of the results.
 Recommendations for countermeasures to eliminate discovered vulnerabilities.”
“Vulnerability scanning programs are designed for the purpose of identifying network holes
and weaknesses. The scanners include features that assist with repairing the vulnerability
before hackers have the chance to exploit them. There hundreds of vulnerability scanners on
the market from free versions to commercial versions. They scan your network from the
outside like a hacker would do when trying to identify network vulnerabilities. The only
difference is vulnerability scanners will not only identify the vulnerability but often offer
advice on how to repair the vulnerability.” (Laws, 2014).
This article also explains how a vulnerability scanner works and the basics of what it should
aim to do.
“Vulnerability scanning typically refers to the scanning of systems that are connected to the
Internet but can also refer to system audits on internal networks that are not connected to the
Internet in order to assess the threat of rogue software or malicious employees in an
enterprise.” (Street, 2014).

~ 15 ~
Google Releases OpenSource Tool for Testing Web App Security Scanners
“Google today released an open source tool called “Firing Range” which is designed as a test
bed for Web application security scanners that provides coverage for a wide variety of cross-
site scripting (XSS) and other vulnerabilities on a massive scale.” (Donohue, 2014)
This new article explains how Google has released a tool for testing web application security
scanners this is could be helpful for my project as it can be used in this to test the end artefact
and evaluate how reliable and effective it is. Also it is open source, which is beneficial as it
can be used without any problem to analyse my end artefact.
Web Application Attack and Audit Framework
“W3af is a Web Application Attack and Audit Framework. The project’s goal is to create a
framework to help you secure your web applications by finding and exploiting all web
application vulnerabilities.” (W3af.org, 2014)
This website is a Web Application Attack and Audit Framework which basically tests web
applications to check if they are secure or vulnerable to attacks. This is a live example of
something similar to what this project aims to create, so by analysing this framework it has
helped understand how a vulnerability scanner should operate.
Attack Model BasedPenetration Test for SQL Injection Vulnerability
“We propose a model based penetration test method for the SQL injection vulnerability in
which the penetration test case generation is divided into two steps:
1. Building model for the penetration test case
2. Instantiating the model of penetration test case. Our method can generate test case
covering more types and patterns of SQL injection attack input to thoroughly test the
blacklist filter mechanism of web applications. Experiments show the penetration test
case generated by our method can effectively find the SQL injection vulnerabilities
hidden behind the inadequate blacklist filter defense mechanism thus reduce the false
negative and improve test accuracy.” (Tian et al, 2012)
This has helped increase knowledge of SQL injection and how websites are vulnerable to the
SQL injection attacks also how to detect these attacks and how to detect vulnerability of SQL
injection. This is useful as it can be used for this web app to detect SQL injection.
Path sensitive static analysis of web applications for remote code execution vulnerability
detection
“Remote code execution (RCE) attacks are one of the most prominent security threats for
web applications. It is a special kind of cross-site-scripting (XSS) attack that allows client
inputs to be stored and executed as server side scripts. RCE attacks often require coordination
of multiple requests and manipulation of string and non-string inputs from the client side to
nullify the access control protocol and induce unusual execution paths on the server side. We
propose a path - and context-sensitive interprocedural analysis - to detect RCE
vulnerabilities. The analysis features a novel way of analysing both the string and non-string
behaviour of a web application in a path sensitive fashion. It thoroughly handles the practical
challenges entailed by modelling RCE attacks. We develop a prototype system and evaluate it
on ten real-world PHP applications.” (Zheng and Zhang, 2013)
This has helped increase knowledge of Remote code execution and how websites are
vulnerable to the Remote code execution attacks. Also how to detect these attacks and how to

~ 16 ~
detect vulnerability of Remote code execution. This is useful as it can be used as information
for the web app to detect Remote code execution.
A Rule-based Security Auditing Tool for Software Vulnerability Detection
“We can use information and software of various forms without being restricted for place and
time if a ubiquitous computing age comes. However, its reverse function is causing security
problems such as outflow of personal information, hacking, diffusion of virus, etc.
Especially, dissemination of software that has malicious purpose in a ubiquitous computing
environment causes serious damage. We have studied about malicious code detection and
software vulnerability detection tools to prevent this, but, existent detection tools are not
suited to general software because they are limitative in the specification area. The proposed
auditing tool can construct a secure ubiquitous computing environment because it will be
used by a common software audit tool that detects malicious codes and software
vulnerabilities at the same time.” (Moohun Lee et al., 2006)
This article explains how a vulnerability scanner works and the basics of what it
should aim to do. This has helped me understand how a vulnerability scanner operates and
this information is really useful as it will help developing a vulnerability scanner.
A Taxonomy of SQL Injection Detection and Prevention Techniques
“SQL injection attacks are classified under seven main categories:
 Tautologies,
 Illegal/Logically Incorrect Queries
 Union Query
 Piggy-Backed Queries
 Stored Procedures
 Inference
 Alternate Encodings
Currently wide ranges of detection and prevention techniques are proposed and used by
developers and application owners.” (Sadeghian, Zamani and Manaf, 2013)
10 Important Facts about Website Security and How They Impact Your Enterprise
“Websites are now the number one target of choice for attackers by hackers. Their attacks
have moved from well defended network layer to the more accessible web application layer
that people use every day to manage their lives and transact business. The sites where
consumers shop, bank, manage, their healthcare, pay insurance, book travel and apply to
college are now under a near-constant barrage of attacks intent upon stealing their credit card
numbers and other personal / private information.
The 2010 verzion data breach investigation report confirms that the majority of breaches and
almost 95% of the data stolen in 2009 was perpetrated by remote organized criminal groups
hacking servers and applications…”(Anon, 2014)
This article explains how website security is important for businesses. It also explains why
businesses should make sure that their website is secure, and why it is important their
websites are audited to ensure they are secure and safe to use.
Static Analysis Tool for Detecting Web Application Vulnerabilities
A short paper entitled “Static Analysis Tool for Detecting Web Application Vulnerabilities”
(Jovanovic, unknown) by Nenad Jovanovic, Christopher Kruegel, and Engin Kirda from the
Technical University of Vienna explores “Pixy”, the first open source tool for statically

~ 17 ~
detecting XSS vulnerabilities in PHP 4 code by means of data flow analysis. PHP was chosen
as a target language since it is widely used for designing Web applications and a substantial
number of security advisories refer to PHP programs. Their prototype is aimed at the
detection of XSS flaws but it can also be applied to other taint-style vulnerabilities such as
SQL injection or command injection. Summarize the results of our experiments. Working in
three applications, they reconstructed 36 known vulnerabilities with 27 false positives (FP's).
In three other applications they discovered 15 previously unknown vulnerabilities with 16
false positives. Pixy also reported a few programming bugs not relevant for security, such as
function calls with too many arguments. Since those bugs had no influence on a program's
security properties they were counted neither as vulnerabilities nor as false positives. Their
results showed that analysis is capable of ending novel vulnerabilities in real-world
applications.
Much of their research will be of assistance to this project in the development of the web app.
As present there are a limited selection of cost effective ways to deal with static detection of
web application vulnerabilities. Huang et al (Huang 2004) were the first to address this in the
context of PHP applications by using a lattice-based analysis algorithm derived from type
systems and type-state. Approximately 8% of PHP files in their experiments were rejected
due to problems with the applied parser. It should now be possible to parse the full PHP
language.
Large-scale Security Analysis of the Web
(Van Goethem, 2014) Tom van Goethem, Ping Chen, Nick Nikiforakis, Lieven Desmet, and
Wouter Joosen Large reported on security aspects of a huge sample of 22,000 websites in
their paper (also in book format) entitled “Large Scale Security Analysis of the Web:
Challenges and Findings. “As many applications become resistant to most prevalent attacks,
adversaries may be tempted to move to easier, unprotected targets which still hold sensitive
user data. In this paper, we report on the state of security for more than 22,000 websites that
originate in 28 EU countries. We first explore the adoption of countermeasures that can be
used to defend against common attacks and serve as indicators of “security consciousness”.
Moreover, we search for the presence of common vulnerabilities and weaknesses and,
together with the adoption of defense mechanisms, use our findings to estimate the overall
security of these websites. Among other results, we show how a website’s popularity relates
to the adoption of security defense and we report on the discovery of three, previously
unreported, attack variations that attackers could have used to attack millions of users.
Interestingly, they state that for organisations like government and supervisory organizations
to assess a website's security externally - especially when the assessment needs to be done at
a larger scale, such an assessment may be desirable since the citizens of each country depend
more and more on certain web applications for their daily lives. They investigate the
feasibility of external security evaluations through a large-scale security analysis of the web.
In particular, evaluating the security stance of popular websites in the European Union (EU),
and investigate the differences among countries.
One way to secure web applications is to have tools and approaches that look for attacks
against web applications in the inbound web traffic. There are many approaches in this area,
but most of them involve first creating a model of the normal behaviour of the web
application. Then, after this model is created, a monitoring/detection phase starts which
analyses inbound web application traffic looking for anomalous web requests which signify
an attack. Depending on the anomaly detection system, the request can be blocked or

~ 18 ~
prevented at that time. Anomaly detection systems are good for preventing unknown exploits
against the web application. However, the effectiveness of the anomaly detection depends on
the creation of the web application model and the presence of extensive attack-free traffic. In
practice, it is difficult to automatically create extensive attack-free traffic Modern web
application can use anomaly detection systems in production environments as a defense-in-
depth approach.
2.7 Summary
Vulnerability analysis can be defined as the task of unearthing vulnerabilities in software.
The task is to discover these vulnerabilities either before an application is utilised or prior to
an attacker discovering any vulnerability you may have. We can define manual vulnerability
analysis as when an individual or team manually analyse an application for any apparent
vulnerabilities. These manual vulnerability analyses are quite often called “pentesting”, and
the usual method is to utilise the services of a team of experts to seek out the vulnerabilities
in a software system. Unfortunately, an expert’s time is very expensive, and usually - due to
this fact - a company will very rarely do an external “pen test” of its web applications. On the
other hand, vulnerability analysis tools are automated methods to find vulnerabilities in
software. The target of this type of software is to discover all the possible vulnerabilities in
any individual application. Because vulnerability analysis tools are automated, they can
therefore be utilised against a variety of applications, and also they are significantly less
costly than hiring a full team of human experts - therefore they can be used much more
frequently.

~ 19 ~
Chapter 3
Design development
3.1 Overview
The artefact design phase is an important part of the creation of the end working artefact. In
order to create clear visual designs which show all detail of how the user interface of the
website should appear, Microsoft office PowerPoint was used. Overall, eight pages were
designed in order to meet the aims and objectives of the project. The designs also include
what information will be added in to each page and how the layout should be. Every page
will include a header and footer. The header will consist of buttons which will link to each
page and the footer will consist of a copyright logo with the name of the website. Both header
and footer will remain consistent throughout the website as this will help the website become
presentable, professional and easily accessible. The eight pages designed are the following:
 Homepage
 Scanning page
 Scan complete page
 About page
 FAQ’s page
 Contact us page
 Port scan page
 Port scan complete page
3.2 Artefact design overview
Figure 3: Designs Overview

~ 20 ~
3.2.1 Homepage design
Figure 3-1: Homepage Design
Homepage design consists of an image representing a scanner followed by a URL bar which
users can enter the target URL and proceed to the next step by clicking “start scan now”
button. This homepage is a simple design which allows users to start the scan straight away
also does not require high level of computing knowledge to access and navigate around the
page.
3.2.2 Scan Complete Design
Figure 3-2: Scan Complete Design

~ 21 ~
The above is the scan complete page. This page displays to the user the outcome of the scan.
This page displays the name of the website scanned, and the number of URL’s scanned,
followed by each vulnerability the website has detected .It will display a tick next to each
vulnerability that hasn’t been detected and a warning sign next to the vulnerability detected.
This page also presents a report for each vulnerability, which states the name of the
vulnerability followed by the level of risk. (For example “high” or “low”) The report also
describes the vulnerability and how it can affect the website. Finally it will display the
solution which explains to the user how the vulnerability can eliminated. This page will also
have a button which will enable users to directly print out the vulnerability report.
3.2.3 Port scanner page design
Figure 3-3: Scan Ports Page Design
This is the port scanning page design, which will allow the user to scan ports, as this will help
the user discover any open ports which is an example of a vulnerability. The design for this
page is simple, as it consists of a title “Port Scanner” followed by three fields which require
to be completed in order to proceed with the scan. “Target IP” is the first field required,
followed by “starting port” and “ending port”.
3.2.4 Port Scan Complete Page Design

~ 22 ~
Figure 3-4: Port Scan Complete Page Design
This is the port scan complete page. This will display the IP address that was scanned and
also display the open ports that were detected during the scan, followed with a warning sign
if open ports are detected.
3.2.5 About Page Design
Figure 3-5: About Page Design

~ 23 ~
This is the “About” page design This page will provide information for users about what “site
scanner” is and what vulnerabilities it is capable of detecting, while also explaining each
vulnerability and how it can be a risk to a website. This will be beneficial to the user as it will
help expand their understanding of the vulnerabilities.
3.2.6 FAQ’s Page Design
Figure 3-6: FAQ’s Page Design
This is the “FAQ’s” page design. This will consist of questions that will help answer some of
the user’s questions that are not covered in other areas of the website.
3.2.7 Contact Us Page Design

~ 24 ~
Figure 3-7: Contact Page Design
This is the “contact us” page design. This will provide users with contact details for inquiries
such as:
 Phone number
 Email address
 Business address
 Map locating the business
3.3 Activity diagram for vulnerability scanning
Figure 3-8: vulnerability scanning Activity diagram

~ 25 ~
3.4 Activity diagram for scanning ports
Figure 3-9: Port Scanning Activity Diagram

~ 26 ~
Chapter 4
Implementation / Tools
4.1 Overview
This chapter aims to discuss how the each vulnerability is detected in order to meet the
minimum requirements, aims and objectives. The chapter will begin with an outline of the
tools used to enable the implementation process. Due to the limitations on the size of this
report it is not possible to cover all areas of the implementation process of the project for this
reason only the implementation areas of how vulnerabilities are detected will be included
instead of including how webpages where created etc.
4.2 Home page Implementation
Index.Php – Home page where user will enter the URL to scan
Checkvulnerability.php – result page where the results of vulnerability is shown.
An Ajax call is fired from Checkvulnerability.php for the below:
Figure 4.1: Checkvulnerability.php page

~ 27 ~
Figure 4.2: results page
4.3 Web Crawler Implementation
Obtaining the link structure of websites can be attained by using a function called web
crawler, as a script is used to read the content of a web page, and extract the list of hyperlinks
from the content. The webs crawler can then extract a hyperlink list of each webpage. The
Crawl function in this case is used to crawl a website and find the number of valid URLs to
test the various vulnerabilities:
1. Http Banner disclosure
2. Unvalidated redirects
3. Autosuggest component disabled or not in the input fields
4. Directory listing
5. SQL injection
4.4 Http Banner implementation:
In order to detect Http banner vulnerabilities an Ajax call is fired from
“Checkvulnerability.php” page.
In “Scanner. Php” if the request type is “httpbandis” then testHttpBannerDisclosure
function is called from testHttpBannerDisclosure. Php
Check for type of error returned while executing the below statement
$error=$http->GetRequestArguments ($urlToCheck, $arguments);

~ 28 ~
All key header information is already stored in a predefined array.
Server Header:
 Apache
 Win32
 mod_ssl
 OpenSSL
 PHP
 mod_perl
 Perl
 Ubuntu
 Python
 mod_python
 Microsoft
 IIS
 Unix
 Linux
X-Pow-by-header
 PHP
 ASP
 NET
 JSP
 JBoss
 Perl
 Python
If no error is returned, check for the header information exposed for two header sections
1. Server 2. X-powered-by as above.
When compared if the test then the result is displayed in the browser that the site is
vulnerable for Http Banner Disclosure, providing the details of what is being disclosed,
risk of disclosure and recommendations to avoid this vulnerability.
Figure 4.3: shows vulnerabilities

~ 29 ~
4.5 Auto complete implementation :
An Ajax call is fired from Checkvulnerability.php
In Scanner.php if the request type is “autocomp” then testAutoComplete function is called
from testAutoComplete.php
Autocomplete is checked for each of the URLs found.
Check if the URL is a valid URL & no error returned in output
If it is a valid URL and response received, the contents of html is retrieved.
$html = file_get_html ($urlToCheck);
For each of the input field within the page check whether the autocomplete attribute is set for
the password type fields.
If (isset ($input->attr['autocomplete']))
{
$inputAutoComplete = $input->attr ['autocomplete'];
if(strcasecmp($inputAutoComplete, 'off') != 0)
$vulnerabilityFound = true;
}
else
$vulnerabilityFound = true;
If autocomplete is turned ‘on’ for the password type input fields then the site is vulnerable.
A message is displayed in the output to say that the website is vulnerable for Autocomplete &
explaining the risk & recommendations to remove the autocomplete vulnerability from the
website.

~ 30 ~
Figure 4.2: checking or SQL injection
4.6 SQL Injection implementation:
In order to detect SQL injection vulnerability an Ajax call is fired from
Checkvulnerability.php
In Scanner.php if the request type is “sqli” then testForSQLifunction is called from
testForSQLi.php
SQL Injection is checked for each of the URLs found.
Check if the URL is a valid URL & no error returned in output
If it is a valid URL and response received, the contents of html is retrieved.
$html = file_get_html ($urlToCheck);
Initialise all the common SQL warnings and errors that will come when a database is
accessed as these warnings can expose some serious vulnerable information about the
database.
For example:
 supplied argument is not a valid MySQL
 mysql_fetch_array
 on MySQL result index
 You have an error in your SQL syntax
 You have an error in your SQL syntax near
 MySQL server version for the right syntax to use

~ 31 ~
 Column count doesn't match
Define the payloads for SQL injection
For example:
 ‘
 “
 ;
 )
 (
 .
 --
For each URL passed to the function submit a payload to check if any error/warning received
so that it can be compared with stored warnings/error in the program.
Frame the query parameters for SQL injection
$newQuery = str_replace($para, $currentPayload, $query);
$query = $newQuery;
$testUrl = $scheme . '://' . $host. $path . '?' . $query;
$error=$http->GetRequestArguments ($testUrl,$arguments);
Check whether the predefined SQL warnings/errors are seen by parsing the entire page
received by firing the query above.
$regularExpression = "/$arrayOfSQLWarnings[$warningIndex]/";
if(preg_match($regularExpression,$body))
A message is displayed in the output to say that the website is vulnerable for SQL injection &
explaining the risk & recommendations to remove the SQL injection vulnerability from the
website.
Figure 4.5: risks & recommendations

~ 32 ~
4.7 Unvalidated redirects:
An Ajax call is fired from checkvulnerability.php
In Scanner.php if the request type is “unvalredirect” then testUnvalidatedRedirects
function is called from testUnvalidatedRedirects
4.8 Tools used
4.8.1 WAMP Server
Wamp Server is a web development environment for Windows. This allows the user to create
web applications with:
 Apache2
 PHP
 MySQL database
 PhpMyAdmin allows easy database management
The reason why Wamp server was used is because:
 Allows user to manage Apache and MySQL services
 Allows user to switch server online/offline
 Allows user to Install and switch Apache, MySQL and PHP releases
 Allows user to manage servers settings
 Allows user to access logs
 Create alias
4.8.2 Windows 8
Windows 8 is the operating system used during this project, the reason why Windows 8
operating system was used because firstly that was the pre-installed operating system on the
laptop used also the author is familiar with the operating system also the operating system
supports Wamp server and notepad ++.
4.8.3 Notepad ++
Notepad++ is basically a source code editor and Notepad++ supports several different
programming languages. Notepad++ runs in the MS Windows environment, this was used to
write up the code for the artefact.
4.8.4 Google chrome
Google chrome is a web browser, this was used in order to test the artefact to ensure it is
compatible with this browser as it is a very common and widely used.

~ 33 ~
4.8.5 Internet Explorer
Internet explorer is a web browser, this was used in order to test the artefact to ensure it is
4.8.6 Mozilla fire fox
Mozilla fire fox is a web browser, this was used in order to test the artefact to ensure it is

~ 34 ~
Chapter 5
Testing
5.1 Overview
This chapter provides an overview of how the artefact was tested, the main purposes of
testing is to first check that that it meets the requirements and second is to identify errors in
the artefact.
5.2 Testing the Artefact
5.2.1 Test 1
Website tested: Artefact
What is being tested?
In this test the “Start scan now” button in the “Home” page in the artefact is being tested.
How is it going to be tested?
This will be tested by loading up the artefact in a browser and navigating to the “Home” page
then entering a URL (e.g. http://www.google.com) into the search box and clicking the “Start
scan now” button.
What is expected?
It is expected the artefact will load up correctly without any problems and to be able to
navigate the “Home” page and once the URL is entered and “Start scan now” button is
clicked the scan should start.
What is the outcome?

~ 35 ~
After loading up the “Home” page in the browser and entering the URL into the search box,
once “Start scan now” button was clicked the scan started instantly without any delays.
Does it meet aims and objectives?
This test does meet my aims and objectives as this is part of my original designs and it is
essential the button functions correctly as this button starts the scan.
Were there any problems, and if so how were they overcome?
There was no problems noticed in this test as this test was successful.
5.2.2 Test 2
In this test I am testing the “Print” button in the “check vulnerability” page in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “Home”
page then entering a URL (e.g. http://www.google.com) into the search box and clicking the
“Start scan now” button. Once the scan is complete I will attempt to print using the “Print”
button.
What is expected?
I am expecting my artefact to load up correctly without any problems and to be able to
navigate the “Home” page and once the URL is entered and “Start scan now” button is
clicked the scan should start and once it is complete and the “Print” button is clicked it should
allow the user to print the page.
After loading up my artefact and starting a scan, once the scan was complete the “Print”
button was clicked, and this displayed the print preview page.

~ 36 ~
essential the button functions correctly as this button allows users to print out their scan
report.
Where there any problems, and if so how were they overcome?
5.3.3 Test 3
In this test I am testing the “Port scanner” in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “scan ports”
page and attempt to scan my local host as I will deliberately open port 80 for this test in order
to test if the port scanner can successfully detect the open port also I will be looking out for:
 Delays in loading page
 Errors on page
 Grammar errors
What is expected?
navigate the “Scan Ports” page and for the page to load without any delays and errors,
following the scanner to successfully detect the open port.
After loading up the “scan ports” page in the browser, there were no delays in loading time
and no errors in the page. Once started scan and completed scan the result was as expected
and the port scanner did successfully detect port 80 as opened.

~ 37 ~
essential the page loads without any errors and difficulties.
5.3.4 Test 4
In this test I am testing the map in the “contact us” page.
This will be tested by loading the website in both Internet Explorer and Google Chrome to
see if the map loads up correctly.
What is expected?
I am expecting the map in the “contact us” page to be able to load correctly in both browsers
without any problems.
1. Internet explorer
2. Google chrome

~ 38 ~
After loading up the “contact us” page in both browsers there was no problem with the map
loading. Also there was no delay in the map loading time.
This test does meet my aims and objectives as it is important that the website is compatible
with most browsers. This ensures that my artefact is efficient and accessible.
Where there any problems if so how were they overcome?
There were no problems noticed in this test. This test was successful.
5.3.5 Test 5
In this test I am testing the “About” page in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “About”
page. I will be looking out for
 Errors on page
 Grammar errors
What is expected?
navigate the “About” page and for the page to load without any delays. It will also check for
Grammar errors.

~ 39 ~
After loading up the “About” page in the browser there were no delays in loading time and no
errors in the page.
There were no problems noticed in this test as this test was successful.
5.3.6 Test 6
In this test I am testing the “FAQ’s” page in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “FAQ’s”
 Errors on page
 Grammar errors
What is expected?
navigate the “FAQ’s” page, and for the page to load without any delays. It will also check for
Grammar errors.

~ 40 ~
After loading up the “FAQ’s” page in the browser there were no delays in loading time and
no errors in the page.
5.3.7 Test 7
In this test I am testing the “Contact Us” page in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “Contact
Us” page. I will be looking out for
 Errors on page
 Grammar errors
What is expected?
navigate the “Contact Us” page and for the page to load without any delays. It will also check
for Grammar errors.

~ 41 ~
After loading up the “Contact Us” page in the browser there were no delays in loading time
and no errors in the page.
Where there any problems, if so how were they overcome?
5.2.8 Test 8
In this test I am testing the “Home” page in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “Home”
 Errors on page
 Grammar errors
What is expected?
navigate the “Home” page and for the page to load without any delays. It will also check for
Grammar errors.

~ 42 ~
After loading up the “Home” page in the browser there were no delays in loading time and no
errors in the page.
5.3.9 Test 9
In this test I am testing the “Scan ports” page in my artefact.
I will be testing this by loading up my artefact in a browser and navigating to the “Scan
ports” page. I will be looking out for
 Errors on page
 Grammar errors
What is expected?
navigate the “Scan ports” page and for the page to load without any delays. It will also check
for Grammar errors.

~ 43 ~
After loading up the “Scan ports” page in the browser there were no delays in loading time
and no errors in the page.
There was no problems noticed in this test as this test was successful
5.3 Testing for vulnerability detection
5.3.1 Test 1
Website tested: http://www.musixmatcch.com/lyrics
TEST 1
Vulnerability Unvalidated
directs
Auto
suggest
Directory
Listing
SQL
injection
Http
Banner
SECURE   
VULNERABLE  
TIME TOOK TO
COMPLETE SCAN
34 MINUTES

~ 44 ~
In this test I am testing to see if the artefact can successfully scan and detect vulnerabilities
on a random website.
I will be testing this by pasting the link to the website in to my artefact and scanning it, then
my artefact will scan the website for the following vulnerabilities:
 Auto suggest
 SQL injections
 Http Banner
The vulnerabilities detected are the following:
 Auto suggest
 Http banner
The max scanning time set for testing this website is 45 minutes
What is expected?
I am expecting my artefact to be able to successfully scan for vulnerabilities in the website,
and also for it to display the report which shows the following details:
 Name of vulnerabilities
 Risk - High/Medium/Low
 Description
 Recommendations
After completing the scan the outcome of the scan was that the vulnerabilities detected are
the following:
 Auto suggest
 Http banner
This test does meet my aims and objectives as the artefact did successfully detect the
vulnerabilities in this website.

~ 45 ~
5.3.2 Test 2
TEST 2
directs
Auto
suggest
Directory
Listing
SQL
injection
Http
Banner
SECURE    
VULNERABLE 
TIME TOOK TO
COMPLETE SCAN
10 MINUTES
In this test I am testing to see if the artefact can successfully scan and detect vulnerabilities in
a random website.
I will be testing this by pasting the link to the website in to my artefact and scan it, my
artefact will scan the website for the following vulnerabilities:
 Auto suggest
 SQL injections
 Http Banner
What is expected?
I am expecting my artefact to be able to successfully scan for vulnerabilities in the website
also for it to display the report which shows the following details:
 Description
 Recommendations

~ 46 ~
After completing the scan the outcome of the scan was that the vulnerabilities detected is the
following:
 Http banner
It took 10 minutes for the scan to complete, once the scan is complete a report is displayed
which explains the vulnerabilities, the risk level e.g. medium or high and finally displays the
solution.
5.3.3 Test 3
Website tested: http://socialfinanceforum.marsdd.com/sff/
TEST 3
directs
Auto
suggest
Directory
Listing
SQL
injection
Http
Banner
SECURE   
VULNERABLE  
TIME TOOK TO
COMPLETE SCAN
17 MINUTES

~ 47 ~
a random website.
 Auto suggest
 SQL injections
 Http Banner
What is expected?
I am expecting my artefact to be able to successfully scan for vulnerabilities in the website
also for it to display the report which shows the following details:
 Description
 Recommendations
After completing the scan the outcome of the scan was that the vulnerabilities detected is the
following:
 Http banner
It took 17 minutes for the scan to complete, once the scan is complete a report is displayed
which explains the vulnerabilities, the risk level e.g. medium or high and finally displays the
solution.

~ 48 ~
5.3.4 Test 4
Website tested: http://www.google.com
TEST 4
directs
Auto
suggest
Directory
Listing
SQL
injection
Http
Banner
SECURE ? ? ? ? ?
VULNERABLE
TIME TOOK TO
COMPLETE SCAN
45 MINUTES
a very popular, busy and secure search engine.
 Auto suggest
 SQL injections
 Http Banner
What is expected?
I am expecting my artefact to be able to successfully attempt to scan for vulnerabilities
however I am not expecting my artefact to complete the scan as this may take over 45
minutes to do.

~ 49 ~
After completing the scan the outcome of the scan was as expected. There were no
vulnerabilities detected as the website is too big and the server has many restrictions which
prevents the scanner from crawling into the pages and scanning, the max scanning time set
for testing was 45 minutes this scan was taking too long to detect vulnerabilities once reached
maximum time (45 minutes) the test was terminated.
This test does meet my aims and objectives as the artefact did attempt however due to the
server having many restrictions which prevents the scanner from crawling into the pages and
scanning my artefact was unable to complete the scan in time.
5.3.5 Test 5
Website tested: http://mi-linux.wlv.ac.uk/~in1345/xss/guestbook
TEST 5
directs
Auto
suggest
Directory
Listing
SQL
injection
Http
Banner
SECURE    
VULNERABLE 
TIME TOOK TO
COMPLETE SCAN
10 MINUTES
In this test I am testing for SQL injection vulnerability. The website I will be testing is known
to be vulnerable to SQL injection.

~ 50 ~
I will be testing this by pasting the link to the website in to my artefact and scanning it, my
 Auto suggest
 SQL injections
 Http Banner
What is expected?
I am expecting my artefact to detect SQL injection vulnerability, and also for it to display the
report which shows the following details:
 Description
 Recommendations
After completing the scan, the outcome of the scan was not what I had expected. My artefact
detected only one vulnerability which was HTTP Banner. Also the report was displayed,
however it did not detect SQL injection vulnerability.
This test does not meet my aims and objectives as detecting SQL injection vulnerabilities is
an important aim for my artefact as SQL injection is a very widespread vulnerability and it is
important for my artefact to detect this vulnerability.

~ 51 ~
Chapter 6
Evaluation
6.1 Introduction
This chapter evaluates the project, by evaluating the solution produced for the problem also
evaluating the success of achieving the aims & objectives, minimum requirements, possible
extensions and future developments. A section of the evaluation will also include comparison
of other solutions and effectiveness of methodology. Lastly a brief summary will be included
in this chapter which will conclude the main points of the evaluation.
6.2 Effectiveness of Methodology
The methodology which was followed throughout the project was the modified Sashimi
waterfall model, this had a very positive affect on the success of the project as it ensured the
planning of each phase of the project while ensuring each phase meets the requirements, aims
and objectives. Throughout the project there were several changes that needed to be made,
the main changes needed to be made after completing system design phase, this is where the
Sashimi waterfall model benefited the project as it allows flexibility in the project and allows
the developer to go back to an already completed phase and make changes. However when
project is towards the final stages of the waterfall model such as testing it can be difficult to
go back several phases and make changes as this can have knock on affect and result in
making changes in all the phases. Overall the adopted methodology was very beneficial for
the project as it helped create and follow a clear plan for the project.
6.3 Project management
In order to manage the project the main tool used was the Gantt chart, which was produced to
show the schedule of the project. The original project schedule was produced once the
methodology was chosen. To create the project Microsoft Office Project was used as this
helped create a clear plan and follow it. The schedule was altered halfway through the project
but the change was kept track of using the Gantt chart.
Additional tools that were used in order to successfully manage the project were project
log book of meetings with the supervisor, having weekly meetings with the supervisor was
beneficial and played an important role in the success of the project. Even though some
meetings were missed contact was always kept with the supervisor via email, the supervisor
helped positively guide the project through each stage which highly contributes to the success
of the project.

~ 52 ~
6.4 Minimum Requirements Analysis
1. The artefact should produce a report which will explain the vulnerabilities.
This requirement has been achieved successfully as the artefact (refer to Appendix A)
is able to explain each vulnerability that has been detected from the scan, the artefact
produces a report once the scan is complete and describes the vulnerability so the user
can understand the problem and from that explanation can get a brief idea of the
problem in the users website.
2. The artefact should show the risk level (high/medium/low) of each vulnerability.
This requirement has been achieved (refer to Appendix B) the artefact is able provide
the user with a risk level for each vulnerability detected from the scan, this will help
indicate to the user how serious each vulnerability is, which will allow the user to
prioritise and get an idea of which vulnerability to eliminate first.
3. The artefact should provide a solution for each vulnerability detected.
This requirement has been achieved (refer to Appendix C) the artefact can
successfully provide the user with a solution for each vulnerability detected from the
scan, this give the user a brief explanation of how to resolve the issue.
4. The finished prototype should have the following pages:
 Home
This requirement has been achieved successfully, (refer to Appendix D) the home
page matches the design requirement and works correctly and is consistent with all
other pages in the artefact.
 About
This requirement has been achieved, (refer to Appendix E) the about page matches the
design requirement and has all the information that the user will find useful when
using this tool and achieve a better understanding of what to expect.
 FAQ’s
This requirement has been partially achieved, (refer to appendix F) the FAQ page
does meet the design requirements as the structure and layout is consistent with all
other pages however the information in the page is not complete due to time
constraints the answers to the questions have not been complete.
 Contact us
This requirement has been achieved successfully, (refer to Appendix G) the contact us
page matches the design requirement and works correctly and is consistent with all
other pages in the artefact.
5. Finished artefact should be able to detect the following vulnerabilities:
 HTTP Banner
 SQL injection
 Unvalidated directs

~ 53 ~
 Auto suggest
 Port scanning
This requirement has also been fully achieved, (refer to Appendix I) the artefact is
able to effectively detect all the above vulnerabilities and present to the user clearly
which vulnerabilities are detected. Port scanning has also been achieved, (refer to
Appendix H) a separate page has been made for this to ensure clarity to the user and is
able to detect all open ports in the targeted IP address.
6.5 Possible Enhancements Analysis
1 To detect more vulnerabilities such as:
 Username enumeration
 Remote code execution
 DoS attacks
This possible enhancement was not achieved, the reason for this is because of time
constraints the focus of the project was to meet the minimum requirements of the
project before moving on to possible enhancements. Prioritising was important in this
project and the above possible enhancements was not a priority.
2 To create more webpages that will help users understand security and the importance of
security in the cyber world also a webpage which will give users tips on how to improve their
website security and accessibility.
This possible enhancement was also not achieved, the reason for this is because of
time constraints the focus of the project was to meet the minimum requirements of the
project before moving on to possible enhancements. Prioritising was important in this
project and the above possible enhancements was not a priority.
6.6 Comparison to Other Solutions
Research indicated that other current solutions for this problem that existed were complex to
use and for users with low knowledge on security or coding may not understand how to
operate the tools. One online based tool which is similar to the solution, the tool is called
“Acunetix” this tool is able to detect many different types of vulnerabilities including:
 SQL Injection
 HTTP Banner
 Cross-site scripting
 DOM
“Acunetix” is very similar to the solution as it does detect most of the vulnerabilities that this
project is capable of detecting and is much more advanced as it is more powerful the reason
for this because it has a greater library of vulnerabilities it detects against and is constantly

~ 54 ~
being updated also is able to make fixes for the user whereas the solution is not able to make
any fixes it is only able to provide the user with directions of how to rectify the problem.
While “Acunetix” shows to be more powerful than the solution it is not able to scan for open
ports this is a weakness of the tool as open ports is also a very common vulnerability,
whereas the solution allows the user to detect for open ports. Lastly in order to use
“Acunetix” the user must sign up and pay to use the tool and depending on the reason of use
this can be very costly however the solution is free to use as it is open source and uses open
source libraries and does not require the user to sign up.
6.7 Comparison against Original Plan
The first plan that was created (refer to Appendix J) was slightly altered (refer to Appendix
K). The original schedule was followed till the Christmas holidays when it was recognised
that more time was needed to focus on other university modules and exams. Also then
became clear that more time was needed for implementation and testing than originally
expected for this reason changes were made to my schedule and more time was devoted to
the implementation phase and the testing phase ensuring each phase had enough time to be
completed and to go over once again towards the end of the phase to double check to ensure
requirements are being met. Although in the schedule sufficient time was allowed for the
project write up, the completion of this report did take longer than expected. The reason for
this was because of other University exams, coursework and deadlines the completion of this
report was slightly delayed however due to this being the final stage and having no more
tasks left for this project the delay is not a big problem.
6.8 Future Developments
As with any project there is always potential for further developments. There are many
different developments that can be made to this project in the future that can further enhance
the project, the following are some future developments that can be made:
1 Detect more vulnerabilities
One future development for this project could be increasing the number of
vulnerabilities the solution is able to detect, this may benefit the project as there are
many more common vulnerabilities that users would like to know if there website is
secure against. Also ensuring regular updates are made as new threats to websites
emerge on a daily rate the vulnerability library must be constantly updated to stay up
to date.
2 Improve detail of vulnerability report
Another future development is improving the detail and structure of the vulnerability
report. By improving the detail and structure of the report it will allow users with less
knowledge of security or IT to clearly understand the vulnerability and how to fix the
issues, also by displaying a graph in the report which clearly shows all detected
vulnerabilities, in order from the highest threat to the lowest threat this will improve
the clarity in the report.
3 Create additional web pages

~ 55 ~
A future development could be to create more webpages that will help users
understand security and the importance of security in the cyber world also a webpage
which will give users tips on how to improve their website security and accessibility.
This was originally part of the possible enhancement requirements however due to the
lack of time this was not started.
4 Create a user log in page
Creating a user log in page is another future development which can highly benefit the
project and user. This would require the user to create an account and allow the user
to save the scan which will let the user come back at a later time or to amend the
vulnerabilities and compare the level of security to certain time in the past to view the
progress. Also functionality could be added to allow the user to set up automatic
regular scans which can notify the user if any new vulnerabilities are detected.
6.9 Summary
After evaluating each part of the project and artefact it can be concluded that the project is a
success, even though the possible extensions where not completed it does not affect the
success of the project as they were not priority. The project has effectively produced a
solution to the problem and fulfilled its minimum requirements. The adopted methodology
helped manage stages of the project to ensure nothing is missed out and constantly refer back
to the requirements. The future development from this stage also presents real value but may
need some simple additions of increased functionalities such as from the possible
enhancements.

~ 56 ~
Chapter 7
Conclusion
7.1 Answering the academic question
Academic Question: Can an easy to use web application be developed in order to detect
common security threats in websites?
After completing background research on this topic it was clear that the most common
security threats found in websites are:
1. SQL injection,
2. Unvalidated redirects,
3. Directory listing
4. HTTP banner,
5. Auto suggest
6. Open ports
Once some common vulnerabilities were known the next stage of research was looking to
find out if there are any existing web applications which can detect security threats in live
websites, after some research it was discovered that there are some similar applications
however most are not easy to use and quite expensive.
Next step in research was to find out how to detect each of the above vulnerabilities, this was
a difficult stage however after allot of research in to existing similar applications and
techniques used, it was clear this is not as difficult as it seems and there are many existing
open source libraries which are available which can help detect some of the common
vulnerabilities.
This project answers the academic question, a working prototype has been successfully built
and tested and is able to detect the common vulnerabilities and can also detect open ports.
Also it is very easy to use as it does not require the user to have high knowledge in IT
security as the design is simple, consistent and the web application includes information
about the application. Another factor which makes the artefact easy to use and easy to
understand is once the scan is completed and if any vulnerabilities are detected the artefact
displays a definition of the vulnerability, a risk level and a solution for each vulnerability so
the user can get a better and clear understanding of the problem and how to resolve it.

~ 57 ~
Self-reflection
By completing this project I have learnt many things and has helped strengthen many of my
week areas. During this project I have improved on:
 Being organised, as this project helped realise the importance of being organised and
staying up to date.
 Throughout this project I have greatly sharpened my critical analysis skills.
 I have improved in carrying out thorough research which is related to the topic.
 This project has also helped improve coding, as this project forced me to create a
more professional looking prototype then I have done before which made the coding
more difficult however after allot of time spent practising I have successfully
overcome this.
 I have improved on my management skills as this project was based on the Waterfall
methodology which meant I had to follow a set plan also having a deadline meant
that following the set plan was crucial in the success of this project.
Even though I have improved on many things there some weaknesses that remain, my main
weakness I believe is getting distracted also I still lack in confidence while carrying out a
presentation however I believe with some more practice I should be more confident and
overcome this issue.
Overall I am happy with the outcome of this project, as this project was a success and gaining
and improving my skills also after many setbacks I am happy with my performance towards
this project as I have successfully completed this project on time and to the best of my
ability.
7.3 Overall Evaluation
The main aim of this project was to design and build a fully working web application which
is able to detect vulnerabilities in other websites, which is easy and simple to use even for
people with very low IT security knowledge.
The development always focused on the minimum requirements, aims and objectives of the
project as it was important that the artefact met the aims and objectives that were set
originally to ensure the success of the project. There were some features that were not
essential however they were part of the possible extensions of the project however due to the
lack of time, as this was not priority it does not affect the success of the project.
In order to ensure the artefact was fully functioning testing was carried out, testing was a
crucial part of the project this tests every main feature of the artefact which includes testing
every page link, all buttons and ensuring vulnerabilities are detected. Once testing was
complete it was discovered there were some minor issues however they were quickly
rectified. As the prototype currently stands it is fully functioning and can easily be put live
and ready to be used.
Overall the project development went according to plan, and the report was completed before
the deadline, this proves time was managed correctly as time management played a crucial

~ 58 ~
part in the success of this project. To conclude the overall project was a success with its aims,
objectives and minimum requirements met.
References
1. Anon, (2014). 1st ed. [eBook] Available at:
http://www.idgtechnetwork.com/design/dev/whitehat/pdf/WP10facts0111.pdf
[Accessed 21 Nov. 2014].
2. Donohue, B. (2014). Google Releases Open Source Tool for Testing Web App
Security Scanners. [Online] Threatpost - English - Global - threatpost.com. Available
at: http://threatpost.com/google-releases-open-source-xss-web-app-scanner/109445
[Accessed 21 Nov. 2014].
3. Engebretson, P. (2013). The basics of hacking and penetration testing. Amsterdam:
Syngress, an imprint of Elsevier.
4. Grossman, L. (2014). How to reduce your risk of a cyber-security breach - The
Business Journals. [Online] The Business Journals. Available at:
http://www.bizjournals.com/bizjournals/how-to/technology/2014/11/how-to-reduce-
your-risk-of-a-cyber-security-breach.html?page=all [Accessed 21 Nov. 2014].
5. Huang,Y.W, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo. (2004) Securing
web application code by static analysis and runtime protection. In WWW '04:
Proceedings of the13th International Conference on World Wide Web, 2004.
6. Jovanovic, Nenad, Christopher Kruegel, and Engin Kirda. (date unknown) Technical
University of Vienna Secure Systems Lab. [online]. http://infsec.uni-
trier.de/download/teachingSS2009/IT-Sicherheit-II/literatur/pixy.pdf.
7. Laws, s. (2014). Vulnerability Testing: How Vulnerability Scanning Works. [Online]
Spamlaws.com. Available at: http://www.spamlaws.com/how-vulnerability-scanning-
works.html [Accessed 21 Nov. 2014].

~ 59 ~
8. Montoro. Rodrigo (2014).Quick Analysis of a DoS Attack Using SSDP. [Online]
http://blog.sucuri.net/2014/09/quick-analysis-of-a-ddos-attack-using-ssdp.html
9. Moohun Lee, Sunghoon Cho, Changbok Jang, Heeyong Park, and Euiin Choi,
(2006). A Rule-based Security Auditing Tool for Software Vulnerability Detection.
2006 International Conference on Hybrid Information Technology. [Online] Available
at: http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=4021258 [Accessed 15 Nov.
2014].
10. Netsparker Web Application Security Scanner, (2014). Cross-Site Scripting (XSS)
Web Application Vulnerability Explained. [Online] Available at:
https://www.netsparker.com/web-vulnerability-scanner/vulnerability-security-checks-
index/crosssite-scripting-xss/ [Accessed 14 Nov. 2014].
11. Pune Mirror, (2014). 90% e-shopping sites are prone to break-ins - Pune Mirror -.
[Online] Available at: http://www.punemirror.in/pune/others/90-e-shopping-sites-are-
prone-to-break-ins/articleshow/45170487.cms [Accessed 21 Nov. 2014].
12. Rouse, M. (2014). What is vulnerability scanner? - Definition from WhatIs.com.
[online] Searchsoftwarequality.techtarget.com. Available at:
http://searchsoftwarequality.techtarget.com/definition/vulnerability-scanner [Accessed
21 Nov. 2014].
13. Sadeghian, A., Zamani, M. and Manaf, A. (2013). A Taxonomy of SQL Injection
Detection and Prevention Techniques. 2013 International Conference on Informatics
and Creative Multimedia. [Online] Available at:
http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=6702782 [Accessed 21 Nov. 2014].
14. Street, q. (2014). What Is Vulnerability Scanning? - A Security Definition from
Webopedia. [Online] Webopedia.com. Available at:

~ 60 ~
http://www.webopedia.com/TERM/V/vulnerability_scanning.html [Accessed 21 Nov.
2014].
15. Sumit. Siddharth, 2010). Five common Web application vulnerabilities [online].
Available at: http://www.symantec.com/connect/articles/five-common-web-
application-vulnerabilities
16. Tian, W., Yang, J., Xu, J. and Si, G. (2012). Attack Model Based Penetration Test for
SQL Injection Vulnerability. 2012 IEEE 36th Annual Computer Software and
Applications Conference Workshops. [Online] Available at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6341640&queryText%
3DSQL+Injection+Vulnerability [Accessed 11 Nov. 2014].
17. Van Goethem. Tom, Ping Chen, Nick Nikiforakis, Lieven Desmet, and Wouter
Joosen (2014). Large-scale Security Analysis of the Web: Challenges and Findings
(online).
https://vagosec.org/papers/eusec_trust2014.pdfhttps://vagosec.org/papers/eusec_tru
st2014.pdf
18. W3af.org, (2014). w3af - Open Source Web Application Security Scanner. [Online]
Available at: http://w3af.org/ [Accessed 21 Nov. 2014].
19. Zheng, Y. and Zhang, X. (2013). Path sensitive static analysis of web applications for
remote code execution vulnerability detection. 2013 35th International Conference on
Software Engineering (ICSE). [Online] Available at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6606611&queryText%
3DRemote+code+execution+Vulnerability+detection [Accessed 21 Nov. 2014].

~ 61 ~
Appendix
AppendixA
AppendixB
Risk level is shown in the vulnerability reportthis shows the level of risk for each vulnerability,the risks
are put in to three categories:
 High, Medium, Low

~ 62 ~
AppendixC
AppendixD
The above shows the vulnerability reportcreated and highlights the explanation of each vulnerability.
The above shows the vulnerability reportcreated and highlights the solution of each vulnerability.

~ 63 ~
AppendixE
AppendixF
The above shows the home page created for the artefact.
The above shows the about page created for the artefact.

~ 64 ~
AppendixG
The above shows the frequently asked questions page created for the artefact.
The above shows the contact us page created for the artefact.

~ 65 ~
AppendixH
Appendix I
The above shows the scan ports page created for the artefact.
The above shows the vulnerabilities thatthe artefact has the ability to detect.

~ 66 ~
Appendix H
The above shows the original plan for the project.

~ 67 ~
Appendix K
The above shows the plan that was followed for the project.

FINAL PROJECT REPORT

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (7)

Similaire à FINAL PROJECT REPORT

Similaire à FINAL PROJECT REPORT (20)

FINAL PROJECT REPORT