Site Loader
Rock Street, San Francisco


This report will be a vulnerability
assessment for a race management website created for Elven Harriers Athletic
club. This website allows registered users to register for races. Once they
have signed up for a race, they can view and keep track of their results. The
races and members are divided by age and gender.

A simply threat modelling methodology will
be used for this report. It’ll start with a detailed description of the system
in question, followed by the threats found then the remediation methods. Two
vulnerability scanners will be used to identify threats as well as the
recommended action to take. The scanners are Vega and Zap.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now

Vega is chosen because of the program’s
ability to detect cross-site scripting whether reflected or stored. It is GUI
based and works with Windows. This program can also search for SSL security
settings. This program has two windows, proxy and scanner. The proxy windows
goes in-depth into the php codes.

Zap or Zed Attack Proxy is maintained by
OWASP. Not only can Zap search for vulnerabilities but it can also simulate
attacks. This program is also GUI based and works with windows. It is a popular
tool that penetration testers use for testing security.

Using two different vulnerability scanners
will help to verify the threats identified, especially if the same threat is
found by both scanners. But there will also be cases where one scanners finds
more threats then the other. Using two scanners will ensure the maximum number
of threats are found.

Structure of the Website

This website will be hosted via Xampp on
localhost. There are several pages found on the website there are three ways to
access the content. The first way is by signing in as administrator, the second
by member and the last is by visitor. The first two ways requires the user to
sign in, while the last way does not.

As a member of the website, the user can
sign up for races, edit their profile, view their own race results and even the
list of races they signed up for. While the administrator can add/delete users,
categories and races. The administrator has full control over the website.

While the
administrator login and member login are separated, it is clearly defined in
the header bar of the website. The pages accessible by administrator and
member/visitor are also separated.

When the database
is uploaded into Xampp, it can be noted that the passwords are all added in
cleartext which is a vulnerability in itself since passwords need to be
encrypted when inserting into the database.

The following
pages are found during scanning:



§  /admin






















§  /images

§  Aboutus.php

§  Allresults.php

§  Contactus.php

§  Elvenharriers.css

§  Faqs.php

§  Index.php

§  Login.php

§  Races.php

§  Registerrace.php

§  Registration.php

§  Result.php

§  Searchresult.php

§  Editpassword.php

§  Editprofile.php

§  Forgotpassword.php

§  Leftnav.php

§  Links.php

§  Logout.php

§  Message.php

§  Myraces.php

§  Search.php

§  Ulinks.php

§  Unregister.php

§  Userhome.php

§  Userleftnav.php

§  Viewresults.php

Threats Identified

Using Vega Vulnerability Scanner

After Vega scans the website, it sorts the
vulnerabilities by severity followed by type and lastly the path of the error.

Severity: High

One error of high severity is the Session Cookie Without HTTPOnly Flag. This
error happens when a cookie holding sensitive information is not marked with a
HTTPOnly Flag. Without this flag, the website or page is susceptible to
cross-site scripting. When the flag is set, the browser would not reveal the
contents of a cookie to a third-party via a client-side script which is what
happens during cross-site scripting.

The next vulnerability found is the Session Cookie Without a Secure flag.
Without the secure flag, cookies are sent in plaintext over a HTTP connection,
making it easy for attackers to initiate a man-in-the-middle attack. With the
secure flag, cookies will only be sent over a HTTPS connection.

This is the last vulnerability found of the
Highest Severity – SQL Injection.
SQL Injection is one of OWASPs Top 10 vulnerabilities detected for Websites. This
vulnerability can be found in a few pages of the website. It is a type of
injection attack where SQL commands are entered into a data field that could
alter existing SQL commands. Using this attack, attackers can read sensitive
information from the database and even delete or drop tables.

Severity: Medium

This next vulnerability is rated a medium
severity. It is called HTTP Trace
Support Detected. With this Trace method, the website is susceptible to
cross-site tracing. This attack makes use of cross-site scripting and HTTP
Trace. It allows the attacker to steal cookies even while the HTTPOnly Flag is
set in the browser.

This next vulnerability found indicates
information leakage where local filesystem could be found. The scanner
discovered filesystem paths in the code which is sensitive information. If the
attacker catches hold of this information, they will be able to derive the file
system layout. Such output should not be sent to client servers.

This is the last vulnerability of medium
severity which is similar to the previous error where sensitive information is
shown to the attacker. But instead of filesystem paths, php error codes are
found. System generated error messages shows more sensitive information as it
is meant to help the developer identify where the problem is from.

Severity: Low

This vulnerability is one of two with low
severity. It is another information leakage problem but one commonly linked to
misconfiguration. Though it could still prove useful to the attacker.

This last vulnerability is the displaying
of an email address on the website, where spambots could find and add it to
spam lists. The email address could also be used in Phishing attacks.

Using Zed Attack Proxy

Application Error Disclosure: This page
will hold error/warning messages that may reveal sensitive information like the
location of the file for example. This data can be used to launch more attacks
against the web application. But the alert could be a false positive if the
error message itself is found inside a documentation page.

Risk Level: Medium


X-Frame-Options Header Not Set: The X-Frame-Options
header is not incorporated in the HTTP response to protect against “ClickJacking”
attacks. “ClickJacking” otherwise known as the “UI Re-dressing” attack happens
when an attacker hijacks the “clicks” done on a page to re-route the users to
their own page.

Risk Level: Medium


Cookie No Http Only Flag: A cookie set
without the HttpOnly flag, can be reached
by JavaScript. So, if a malicious script is activated on this page, then the
cookie can be retrieved and sent to another place. This allows for the session
hijacking attack if the cookie is a session cookie.

Risk Level: Low


Cross Domain JavaScript Source File Inclusion: The page consists of one or more script files from a third-party which
is not in the jurisdiction of the application. This means that the files added
might include functions that we are unaware of.

Risk Level: Low


Password Autocomplete in Browser: The
AUTOCOMPLETE attribute is not disabled on an HTML password field. With this,
passwords are stored on the browser and thus can be retrieved.

Risk Level: Low


Private IP Disclosure: A private IP
Address or an Amazon private is found in the body of a HTTP response. This
particular detail might prove essential for further attacks involving internal

Risk Level: Low


X-Content-Type-Options Header Missing: The
AntiMIME-Sniffing header X-Content-Type-Options was not set to “nosniff”. Thus allowing older versions of
internet browsers to perform MIME-Sniffing. MIME-Sniffing or Content Sniffing
as it is known, is the practice where the response body is read to deduce the
format of the data. Once the format is deduced, the attacker could alter the
format to show a different format.

Risk Level: Low

Counter-Measures for Identified

Application Error Disclosure:

Implement generic error pages.

Consider enforcing a procedure
to assign a unique error reference to the browser while taking down the details
on the server side and not exposing them to the user.

X-Frame-Options Header Not Set:

Most of the current Web
browsers support the X-Frame-Options HTTP header.

Make sure it’s set on all web
pages returned by your site.

Session Cookie with No Http Only Flag:

Ensure that the HttpOnly flag
is set for all cookies

Only load JavaScript source
files from trusted sources, and do not allow the sources to be controlled by
the end users of the application.

Session Cookie with Secure Flag:

Ensure the Secure flag is set
when making cookies

Cross Domain JavaScript Source File Inclusion:

Ensure JavaScript source files
are loaded from only trusted sources, and the sources can’t be controlled by
end users of the application.

Password Autocomplete in Browser:

attribute in forms or separate input elements with password inputs.

Private IP Disclosure:

Remove the private IP address
from the HTTP response body.

For comments, use JSP/ASP/PHP
comment instead of HTML/JavaScript comments as these comments can be viewed by
the client browser.

X-Content-Type-Options Header Missing:

Ensure that the application/web
server sets the Content-Type header appropriately, and that it sets the Options
portion to “nosniff” for all web pages.

If possible, make sure that the
end users are using a modern web browser that does not perform MIME-sniffing.

Disable Support for HTTP TRACE:

Ensure that support for HTTP
Trace has been disabled for all servers.

Use of parameterized statements:

Ensure all input is checked and
sanitized before being added into SQL statements

All variable string types have
to be checked for escape characters while All variable numeric types are
checked for validity.

Email address exposure:

Obfuscate or filter email
addresses in the website to avoid unintended exposure

Appendix: Vulnerability

CWE-1004: Sensitive Cookie
Without ‘HttpOnly’ Flag

Cookie stores sensitive
information but is not marked with the HTTPOnly flag

Exploits Confidentiality and

CWE-614: Sensitive Cookie in
HTTPS Session Without ‘Secure’ Attribute

Secure attribute for sensitive
cookies in session is not set so cookies might be sent in plaintext in a HTTP

Exploits Confidentiality

CWE-89: Improper Neutralization
of Special Elements used in an SQL Command (‘SQL Injection’)

Incorrect neutralization of
special characters that could change an intended SQL Command.

Exploits Confidentiality,
Access Control and Integrity

CWE-749: Exposed Dangerous
Method or Function

Code includes a dangerous
method or function not completely restricted.

Exploits Confidentiality,
Access Control, Integrity and Availability

CWE-79: Improper Neutralization
of Input During Web Page Generation (‘Cross-site Scripting’)

Incorrect neutralization of
user input before it is used as an output to a webpage for other users.

Exploits Confidentiality,
Access Control, Integrity and Availability

CWE-209: Information Exposure
Through an Error Message

Error Message generated
includes sensitive information about its environment and users.

Exploits Confidentiality


Many vulnerabilities are found by the two
scanners, most of them the same and resulted from a missing attribute or
incomplete sanitization. All inputs and outputs have to be checked before being
used when displaying a webpage to an end user, more so when the data has to be
added to the database.

Not to mention, ensuring all error messages
have to be properly altered so as not to reveal sensitive information about the
filesystem behind the website to the end user. Since all these information
could be used by the attackers to perform successful attacks.

All these could be changed by just adding
flags or lines that check the inputs properly, ensuring it does not change the
SQL statements. Small things but they have to be done during the development of
the website.

Post Author: admin


I'm Eunice!

Would you like to get a custom essay? How about receiving a customized one?

Check it out