CO4509 - Comprehensive Security Analysis of WidgetsInc Web System

This report presents a security evaluation of a web-based store developed for WidgetsInc. The investigation involved various security testing methodologies, including password cracking, SQL injection, input validation, cross-site scripting, insecure cryptographic storage analysis, error handling assessment, buffer overflow vulnerability testing, OS command vulnerability tests, website cookie testing, and API abuse/failed authentication testing. The results revealed weak authentication mechanisms with vulnerabilities to password hacking and weak encryption, poor session management practices with sensitive user data stored in cookies, and other security flaws. The report proposes security enhancements to address each identified issue, aiming to strengthen the overall security posture of the web system. Desklib offers a platform to explore this and other solved assignments for student learning.

WEB BASED SYSTEM SECURITY.
NAME
UNIVERSITY/AFFLIATION

Introduction.
Web based applications allow the user to access the services provided through the web
browser installed on their mobile phones or personal computers. The web apps have become
the new inventions driving businesses, health, agriculture and government functions ahead.
They include webmail, online shops, online banking and e-services, (Su, Z., & Wassermann,
G.,2016). These web apps eliminate the need for local installation of applications and regular
updates. Integrating cloud computing, web based applications are used to provide interfaces
through the software as a service interface.
Due to the rising functionality of the use of web based applications, this has become a hot
cake for attackers and hackers for malicious reasons such as stealing and data access,
modification and deletion. Therefore, the process of securing the web apps through the web
application security becomes a necessity,( Garrett, J. J.,2015). The processes, practices and
procedures of securing web apps utilizes the same principles and solutions for securing the
internet and web systems such as authentication, encryption, application security, firewall,
intrusion detection and prevention systems, secure gateways and protocols and computer
access control.
To strengthen the security of the web apps, security testing is performed to access the
vulnerabilities, threats and risks in the web system and the internet. The tests are performed
in two categories, static and dynamic analysis,( Wassermann, G., & Su, Z.,2014). These tests
include manual tests and automatic tests using testing tools. Performing tests on a running
web application is called dynamic analysis. Static analysis is performed on the application’s
source code for vulnerabilities.
According to (Hope, P. and Walther, B., 2008),Dynamic analysis is an effective way of
regularly assessing the application’s security when running since the process is quick. This
dynamic process does not check the application’s source code but analyses the internal state
of the application through the requests and responses generated by the web service.
Types of Web application security testing.
To determine the possible way to secure the web applications, they have to be tested in a
virtual attack environment to identify the vulnerabilities, threats and risks within the apps
during running or in the source code. Therefore, several testing procedures, principles and
practices have been designed and deployed to assist the experts,( Livshits, V. B., & Lam, M.

S.,2015). The testing and exploitation tools are related and certified for corporate use and
meet the requirements for policies, financial auditing, compliance requirements and other
international standards such as HIPAA.
The testing tools generate the vulnerability and evidence of the security flaw and allows the
developers to redesign the application fixing the security loophole. Security testing is a
crucial step in software, networking and computer development, it is regularly performed
within the course of the use of the components over time. The process of security testing
includes the testing for penetration, reviewing the code and analysing the architecture for any
security loopholes,( Allen et al 2009).
As a quality and assurance verification procedure, security testing is mandatory before public
use of any developed web application. The following are the types of security testing:
1. Static application security testing.
Also called white box testing, SAST analyses the source code of the application for security
vulnerabilities, threats and risks. The SAST tools examines the application layer and views
the security of the web app from an inside out perspective. Employed in the software
development steps and phases of the lifecycle, SAST does not require the application to be
running. Several white list testing tools are available on the market with the ability to scan
pre-compiled codes and find vulnerabilities. This ability saves the developer time of
identifying bugs when the application is compiled and executed, (Huang et al 2013).
The white list testing tools provide the developer with the security flaws in the codes during
the initial development phase and thus saves them the time to develop applications prone to
attacks and hackers.
The strengths of the SAST include the high scalability with the ability to be run on multiple
codes within the pre-deployed versions of the web app such as official nightly and produces a
reliable report with the evidence of the security flaws in the source code lines, numbers and
subsections through useful testing tools that find SQL injection loopholes, buffer overflows
and other vulnerabilities, (Tappenden et al 2015).
However, the white list testing tools have several shortcomings in that they cannot find
security vulnerabilities such as configurations that are not embedded in the source code, some
of the tools generate a lot of false positives and request and response issues such as
encryption, authentication, firewall and access control.

The requirements for the white list testing tool was selected basing on the programming
language of the website, accuracy, ability to run on binary, libraries, code or frameworks,
ease of use and licence costs.
2. Dynamic application security testing.
DAST is the testing of testing the web app for security vulnerability while the application is
running. Its suitable for evolving projects to determine security flaws in the industry
compliance web applications and web systems. This vulnerability scanning tools examines
the web applications from the interface and does not involve the checking of the source code
or application layer, (Apfelbaum et al 2011).
This security testing tools interacts with the web applications through the web pages checking
for security flaws in the way in which the application runs through proper cross examination
of inputs, outputs, requests and responses of the web applications.
The DAST offers a variety of testing protocols such as black box testing, penetration testing
and vulnerability scanning. The penetration testing involves the manual mimicking of an
attacker by a software expert or developer and by use of the knowledge or exploitation tools,
try to access with authorization the contents of the web app and note the possible security
flaws. This penetration testing modality is sourced from registered third party security firms
by the companies or individuals with little know-how.
This offers a variety of advanced advantages such as being very fast offering the ability to
regularly test the application, flexible and scalable with the ability to be integrated into user
security strategies without developer involvement.
The DAST produces a lot of false negatives thus reducing the efficiency of the testing tools
since the deeply embedded security vulnerabilities within the source code are easily not
detected.
3. Interactive application testing.
Combines both the SAST and DAST to reduce the disadvantages and increase the efficiency.
However, the integration of the two testing modalities is not simple and thus has not been
well developed. Meanwhile, the different modalities are run and the security vulnerabilities
assessed and solved, (Tian-yang et al 2011).

Methodologies.
1. Password cracking.
The first security test carried out on the website.
The testing was carried out through 3 methods.
I. The security password requested was checked and examined on the amount and
character of digits and simplicity of the passphrase requested.
II. Several password attempts were made on the website in attempt to log in through
correctly guessing the passwords using the possible texts that the user could use.
III. The computer application Hashcat was used to try and generated the password hashes
that could be analysed by the WinMD5 tool to automate the password cracking
process. In method, the hashcat was downloaded from the official website, a text
containing many possible passwords used on the internet over years was downloaded
and renamed to “rockyou.text”. to generate the hashes, the WinMD5 program was
used and the different hashes stored in the hashcat directory used to attempt to access
the website log in page.
2. SQL injection.
This vulnerability was tested using both the manual and automated method. The automated
method was using the application CAST AIP.
The website URL was opened on the web browser. An error base technique was used to
check for vulnerability to SQL injection in the website by addition of a zero. Then the order
by keyword was “Lomondo” was used to sort the records and the details of the user profile
generated, (Qian et al 2013).
The automated method was conducted using the CAST AIP tool, that generated a list of
possible vulnerabilities in the website.
3. Input validation testing.
The ability of the website to detect and use or not use input from external sources was tested
using the input validation testing functionality provided by the CAST AIP tool.

4. Cross site scripting.
A way to hack a website or web application is to make it generate malicious output. This is
made possible by a security vulnerability in the cross site scripting that allows testing for
whether it is possible to change and use third party inputs into the website to generate the
required data.
The application Progpilot was used to analyse the source code of the website for any XSS and
SQL vulnerabilities.
Other input vulnerabilities tested under this step included LDAP, ORM, XML, XPath,
SMTP, code and SSI injections.
5. Insecure cryptographic storage.
The process of encryption of the files provided by the website was tested using the automated
tool Xanitizer. The tools targeted and identified the bad algorithms used in the source code,
bad ways of storing files and encryption keys, the type and importance of the encrypted data
and the type of cypher used to encrypt the data.
6. Error handling and information leakage.
To test the quantity of data returned by the website after an input request, the error handling
process and capabilities of the website were assessed.
The automated method using CAIT AIP tool was used to generate a report on the error
handling method of the website and how the flaw could be utilized to form an attack.
7. Buffer overflow vulnerability testing.
Inputs that are larger than expected for the website are supplied and determining whether a
pointer exchange takes place after the process of heap management has been initialized.
A tool called the OLllyDbg was used to debug the heap and stack overflow vulnerabilities in
the website.

8. OS command vulnerability tests.
Using the web browser interface, the OS command test was attempted to execute the
command on the web server to access passwords stored on the database. The operating
system executable commands applied were random and directed towards the website content.
9. Website cookie testing.
The location of the cookies generated while the browser is in session was determined. The
invalidation and termination process of the browser was determined by closing the browser
abruptly as in power loss and the cookies location re-checked.
The quantity and quality of data stored in the cookies generated by the website was tested
using the Cookie Tester application to determine whether the website’s usernames and
passwords are stored in the cookies and the type of encryption applied.
10. API abuse and failed authentication testing.
The behaviours of the client and server during requests and response patterns to authenticate
the users before data sharing and information transfer was tested by requesting for using an
improper chroot () command to try and break the access control policy.
Results.
1. Weak authentication.
The website has an authentication mechanism that is not strong enough to protect the quality
of data stored within the web based server. The authentication mechanism also is also risky
and vulnerable to password hacking techniques such as brute forcing and dictionary hacking.
The website does not enforce a strong password policy allowing use of dictionary words for
passwords with a less than 6-character length.
The website is assigning a similar identification number for each attempted log in session.
The ID provided exposes the website from remote access by a third party malicious
individual that can access the private data contained within the application, (Vieira, Antunes
and Madeira 2009).
Additionally, the authentication process of the website is not secured enough with
vulnerabilities in the hashing process of storing passwords and a weak encryption RC4
cypher is used.

2. Poor session management.
The website creates cookies for the sessions containing user data than is considered sensitive
such as profile name, passphrase and session ID. On testing, by abrupt closing of the web
browser, the cookies are not invalidated and the website uses the same cookie for the
subsequent sessions, (Nelson et al 2008).
In such an instance, the session on the computer can be assessed by a third party malicious
individual like attacker.
The improper session timeout and termination process is vulnerable to attack since third
parties can use the same computer to authenticate another session.
The website’s URL contains the session id hence can be hacked and be used perform
unauthorized access to the user account details.
3. Cross site scripting.
The website source code is vulnerable to XSS and SQL input modifications to interfere with
the output. In the report from Progpilot, a cross site request can be forged by an attacker to
mimic the request as sent from the authenticated user’s computer or device and hence
perform malicious activities such as unauthorized purchases.
The forged cross site request makes the user’s web application to send a fake HTTP request
including private information that allows modification of the user profile, change password or
create new user.
4. Insecure data link layer protection.
The website uses weak algorithm and invalid certificates that do not support SSL protocol to
send and receive confidential information such as passwords. This unprotected
communication is vulnerable to man-in-the-middle data attacks where an attacker can steal or
access sensitive data simply through network monitoring and cookie stealing, (Bau et al
2010).
5. Direct traversal vulnerability.
The website allows an attacker to view protected folders on the server through executable
commands that can be added on the URL since the process of validation and filtering is

broken. Located in the application code, the vulnerability allows an attacker to send a URL to
the server requesting to retrieve a protected file.
The application code vulnerability offers a little filtering to prevent execution of commands,
however, trial and error escape codes added to the URL allow the attacker to retrieve the
specified files.
6. Insecure storage encryption.
The data stored within the server and accessed from the website is not categorized correctly
and not encrypted properly too with the correct algorithms and recommended cryptographic
cypher. In the source code, the data stored within the server is presumed to be accessed by the
normal user. The data includes registry files, temporary user data and user databases with
unencrypted data and hidden files. Using tools exploiting direct object access, an attacker is
able to access the data, decrypt the weak algorithms used and modify the data or registry
files, (Bozic et al 2013).
Solutions.
Vulnerability. Mitigations and prevention.
Weak authentication. Use of a strong password policy and
imposing the use to all users in all web
applications that contains at least uppercase,
lowercase letters, a numerical digit and a
character.
Use of at least a two factor authentication
system in securing the web based services.
To reduce password cracking;
Increasingly delay the response time in case
of continuous password attempts.
Introduction and use of CAPTCHAs to
compliment the passphrase plus username
log in credentials.
Use of additional security mechanisms such
as confirmation codes, security questions
and account validation processes in case of

multiple failed password attempts.
Use of 3rdparty outsourced standard tools to
improve authentication such as database
authentication of PHP apps or the open
authentication framework.
Poor session and cookie management. Cookies should be invalidated as soon as the
web applications process is terminated
through log out, log off or sudden
termination.
Cookies should not be generated in large
numbers.
Web applications to be configured not to
allow cookies and limit the number of
websites generating cookies.
The cookies generated should not be used to
store sensitive information.
User credentials should not be included as
part of the website URL.
Cross site scripting Provider user education and training on the
security of their own transactions and
sensitive actions to avoid being agents of an
attack unaware.
Implement additional authorization
mechanisms such as use of CAPTCHA,
request tokens, passwords or confirmation
codes and re-authentication while
performing sensitive actions.
Insecure data link layer protection. Use of secure data link protocols such as the
TLS only for transmission of sensitive
information.
Regularly update authentication certificates
and ensure validity.
Direct traversal. User inputs from the web browsers should

be validated to ensure that the attackers do
not use commands in the URLs to access
privileged functions or directories.
Filters should be utilized in the coding and
development process to block any malicious
URLs and escape codes upon detection.
Patching the web based software and
websites with latest security features offers
more protections.
Insecure storage encryption. Detection of insecure methods of data
storage encryption by use of scanning tools.
Following the best practices of data storage
security and encryption according to the
scope of the web app, data confidentiality
and business type.
Identification and encryption of sensitive
data on hard drives.
Protection of sensitive data and information
from being overwritten.
Categorizing the different users and
assigning data access privileges to control
who views and who does not view the data
depending on the user status.
Sensitive data that has been deleted or is no
longer is use should be overwritten with
random data to avoid recovering the data by
third parties.
Conclusion.
Web based applications and software as a service cloud based apps are the next technological
frontiers in driving the implementation and utilization of Information Technology in

delivering online services to human beings such as education, medicine, business, banking
and government. The technology integrates the use of mobile devices and therefore due to the
widespread use and amount of sensitive data generated, transmitted and stored, becomes a
primary target for attackers. Therefore, the practices, principles and activities of securing the
web apps is not a onetime event rather a process that requires close monitoring, assessment,
analysis and regular updates and security patches.