Surname 1

Name

Professor

Course

Date

SDEV 460 Homework 3

In modern system applications, it is a common practice to use role-based authentication

in managing access to system resources. However, in some cases, there may be challenges in

role-based authentication due to poor setting up of roles, poor log in procedures, poor

CAPTCHA usage, and poor encryption of security credentials (F. OWASP). This homework

discussion provides a series of test cases, test results and description of major challenges

involved during the authentication process. Additionally, the discussion will outline basic control

mechanisms for the encountered challenges.

Test Role Definitions

The roles listed in the application include manager, administrator, staff and customer. To

test these roles, I logged in with the provided credentials, accessed the files (to determine the

read permission). I tried to modify the files to determine the write, update permissions. These

roles are documented in the roles matrix below:

Role Object Permission to Action Constraint

Manager Customer file Read, update, Can only access and
manipulates objects
that fall in their
functional units only.
Administrator (Admin) Customer files Read, update, write, delete Admin has all
permissions on the
customer class
 Surname 2

Staff Customer file Read Can read customer

records that are
assigned to them by
the manager
Customer (normal user) Customers Read and update User can read and
files update their own
record

Test User Registration Process

This test involves performing various test cases that aim at evaluating the processing of

authenticating users to the system. This test is important because it helps to verify the accuracy,

appropriateness and validity of the process of adding a new user to the application. It also helps

to verify that the requirements for adding a user to the system comply with the security and

business requirements (F. OWASP).

Answer to OWASP testing guide:

 Can anyone register for access? Yes, any user can access the registration panel and enter

their details for registration. The screenshot below shows the panel for login for all

guests:
 Surname 3

 Are registrations vetted by a human prior to provisioning, or are they automatically

granted if the criteria are met? The access is granted automatically after the application

determines that the criteria has been met.

 Can the same person or identity register multiple times? No

 Can users register for different roles or permissions? Yes

 What proof of identity is required for a registration to be successful? The system

application does not have any proof for identity.

 Are registered identities verified? No

Additionally, the following are the answers to the validation process questions in the

OWASP testing guide:

 Can identity information be easily forged or faked? Yes, no validation for email input.

 Can the exchange of identity information be manipulated during registration? No

To improve the user registration process, there is need to implement the following

recommendations:

 Identity verification: users should enter their emails and be asked to login to their emails

to verify their emails. This step will avoid using invalid personal identities like emails

and phone numbers (F. OWASP).

 Verify the registration: users should have limited access to resources before their

registration is approved by other roles like manager and administrators. This would

prevent robots from registering.

 Surname 4

 Form validation for all fields is also necessary to avoid entry of wrong formats of input.

For example, the system should avoid entry of passwords less than six characters or input

of letters for phone numbers rather than numbers only.

Testing for Credentials over an Encrypted Channel

The importance of this test is to ensure verification of the users’ authentication

information passes through an encrypted media to avoid interception and access by unauthorized

persons (Sedek et al.). This test is therefore to ensure proper encryption of the channel for

transmitting authentication data.

The OTG-AUTHN-001 test mitigates threats like account hijacking and information loss

threat. Without proper encryption, an attacker can access user credentials and steal information

from the application or hijack the account for illegal gains.

Recommendations: Since the available websites in the root directory do not use HTTPS,

the following are the recommendations to rectify the situation:

 Implementing social media platforms for authentication. Users could authenticate using

Facebook, Twitter or LinkedIn.

 Using security questions alongside the normal passwords and username authentication.

This could ensure that the MD5 and other encryption methods help to convert the security

questions to encrypted strings for verification of identity (Sudhodanan et al.).

 Sending the user input through a HTTP channel from the HTTP website.

Testing for Default Credentials

 Surname 5

Default credentials testing is important in ensuring that the system administrators

customized the default login credentials to prevent threats of password cracking and brute force

attacks. Most of the application have a default password and user accounts that some

administrators with low security concern may use in production environment hence making it

easier to attack the accounts by predicting these default credentials. This test aims at testing for

such credentials that are easy to predict (Sudhodanan et al.). The screenshot below shows the

input for username = “admin” password = “admin1234”

The result for the above login attempt is as shown below:

 Surname 6

I was not able to guess the default usernames and passwords for the account for customer.

However, the information stored is not encrypted in the users’ database where the application

keeps the user emails and passwords.

Testing for Lockout Mechanisms

This test is important because it helps determine whether attackers can perform brute

force attacks by using several combinations of passwords and usernames. It tests whether the

accounts locks after some number of unsuccessful login attempts (F. OWASP).

The application in the SDEV unit locks after three unsuccessful attempts. Without this

lockout mechanism, then the application is at risk of brute force attacks. The following log.txt

file shows my login attempts:

 Surname 7

Testing for Weak Password Policy

This test aimed at ensuring that the user account passwords are strong enough to avoid

brute force attacks or even social engineering. The passwords used for the account are weak

because they contain less than six characters. However, the website rejects some passwords

formats like empty password as show below:

Recommendations: there is need to implement a policy that requires the password to

have more than six characters long, include both uppercase and lowercase letters. There is also

need to ensure that the users change their passwords change their credentials at least once after
 Surname 8

every three months (Sedek et al.). Creation of passwords based on the usernames, family names,

and any word in English, jargon or any other dialect is not recommended.

NIST policy for password security requires that all passwords be at least 6 characters

long.

Testing Directory Traversal Include

This test seeks to ensure that users cannot access files that they do not have permission to

access. The application may contain poor Access Control Lists (ACL) thus allowing users access

other files that they do not have permission to access. This test control risks like account

hijacking, stealing of critical information and even denial of services.

I was able to access a different user account by visiting the customer profile and changing

the user id at the URL from “user/2/edit” to “user/1/edit”. To fix this, there is need to implement

access control list in a more effective way. This include using middleware for each object hence

allowing users to view object

Testing for Bypassing Authorization Schema

For the logged out users, it is not possible to access the admin or manager panel.

Logged in users could also not access the admin panel even after changing the URL from

“…user/profile/” to “…/admin/profile” to access the administrator profile. Therefore, it is

conclusive that one cannot obtain the admin rights through the modification of the path or URL

(Sedek et al.).
 Surname 9

Testing for Cookies Attributes

This test is important because it checks the ability of the site to protect the cookies that it

uses to provide information to users. The test aims at determining the security of the cookies,

expiry period, domain, path and Http only that forms the major attributes of cookies

(Sudhodanan et al.). This test mitigates attacks like cross-site scripting where attacks can use

cookies to store malicious information in sites JavaScript files and later execute them to exploit

the application.

Cookies were present in the site and they do are not expired. They can be used in other

browsers to authenticate the users. However, the HttpOnly is set set at the HttpOnly target. The

cookies are easy to guess because the path is set at the root of the web server “/”.

Testing for Logout Functionality

This test is important because it ensures that the site has a logout button on all the web

pages, the session terminates upon clicking the logout button and that the invalidation is proper

for the session state (F. OWASP). It helps to mitigates social engineering threats, forgery of

cross site requests, and cross site scripting (XSS).

 Surname 10

Users cannot logout their session in a proper way and the logout button is not available

on all the pages visited. To improve these functionalities, there is need to:

 Setting the session timeout to a certain duration (approximately 30 minutes of inactivity).

 Adding the logout button at all pages to allow users logout manually (Sudhodanan et al.).

 Setting the session routes to have an authentication middleware thus making users to log

in before accessing these routes.

 Surname 11

Works Cited

OWASP. “OWASP Zed Attack Proxy Project.” OWASP Zed Attack Proxy Project (2016): n.

pag. Print.

OWASP, Foundation. “OWASP Testing Guide v3.0.” OWASP Foundation (2008): 349. Web.

Owasp, From. “Testing Guide Introduction.” owasp 2014: 1–16. Print.

Sedek, K a et al. “Developing a Secure Web Application Using OWASP Guidelines.” Computer

and Information Science 2.4 (2009): 137–143. Print.

Sudhodanan, Avinash et al. “Attack Patterns for Black-Box Security Testing of Multi-Party Web

Applications.” Ndss February (2016): 21–24. Web.