KUP Assessments – Bash scripts to test endpoints

Posted on February 5, 2024 by Robert Worrall

For integration testing and the testing of endpoints I have previously indicated I am going to use a bash script of curl commands to achieve this. The first iteration of the script is given below:

#!/bin/sh

#URI's
baseURI="http://localhost:8080/kupassessments/"
create="account/create/"

#test the index url
responseIndexPage=$(curl --write-out "%{http_code}\n" --silent --output /dev/null $baseURI) 2>/dev/null
#test the creation of an account
responseAccountCreation=$(curl --write-out "%{http_code}\n" --silent --data "username=Boot&email=boot@r-a-w.org" --output /dev/null $baseURI$create) 2>/dev/null
echo Bash Script Test of KUPassessments
#result of testing the index page
echo Index Page response: $responseIndexPage
echo Create AccountResponse: $responseAccountCreation

The resulting output is:

Bash Script Test of KUPassessments
Index Page response: 200
Create AccountResponse: 404

The 404 is because the query does not contain any data. I also will have run a an SQL script to reset the database.

The database is cleared using the following script ClearAccountTestingData.sql

delete from accounts where username='boot';

This needs to be run each time the bash script starts to ensure that the database is in a state that is expected for the tests. However this needs the location of the script to be included. So it may be best to execute the the SQL from the testing bash script.

Now I have noticed that the second error is not, in fact due to the data already existing but the fact that the request is incorrect. From searching round the request needs to be rewritten so it sends the request in json.

resources:

https://www.shellhacks.com/mysql-run-query-bash-script-linux-command-line/

KUP Assessment Implementation Diary – Connecting up and dependency injection

Posted on January 13, 2020 by Robert Worrall

Here is a question. when do you inject. Tools like Grice do this for you. But if you are to do it manually, when do you do it? how far do you inject.

We could use the KUP assessments class as an injector class however this would break the single responsibility principle so it would be better to have a separate injector class (KupInjector). Then I simply ask it for various services leaving the configuration of the services to IkupInjector. The classes to be injected shall have a mix of setter and interface injection. This reflects the use of both classes and interfaces used in the structure of the system.

My first implementation of the IkupInjector shall use a properties file to retieve the string class names of the classes to be created. This is then placed in the base directory of the server to which can be edited as needed and the service restarted. The first test in the bash script has been created to test the URI for the index page and and account creation. Using curl is something I am definitely need to work on as it took me a significant amount of time to do even the simplest command.

Sources:

RAW Rota – Convert Requirements into specific test cases

Posted on July 1, 2019July 1, 2019 by Robert Worrall

irotaFactory

Produces X number of proposed rotas for a specified time period

Irota

A collection of shifts and events for staff
fitness score that was generated at creation time can be retrieved
fitness score is final
events can be amended
staff can be amended
Staff can be added to the rota so events and clinics can be allocated to them
Staff can be removed
Staff cannot be removed if they are allocated shifts or events.
Shift can be amended
Change Istaff
Change date
Change period

Istaff

Holds Name
Holds Staff referrence number

Holds Role

Event

Holds Name of event
Holds period of event

IrotaRule

holds staff ref
Takes a rota and provides a fitness score of how well the rule fits

IstaffDatabase

Holds Istaff

IrotaDatabase

Holds Irota

IruleDatabase

Holds IrotaRule

IrotaMediator

Formerly the RotaCoordinator class, the IrotaMediator interface follows the mediator pattern this lously couples the classes encapsulating the communication. between them. It is ultimatly is where the requirements list is forfilled.

KUP Assessments Security Checklist

Posted on June 26, 2019June 5, 2019 by Robert Worrall

• Risk Assessment and ongoing risk tracking.

The following risks are immediately identified:

1. Single developer

2. Lack of experience

In light of the above I shall adopt a concept from the martial arts world, referred to as the ‘economy of movement’ This means to strip out non essentials and take the most direct route to implementing the software. This does not mean to cut corners but to optimise the time spent developing essentials not superfluous elements of the system. e.g Artwork, fancy GUI interfaces etc.

3. The use of ‘Basic Authorisation’ and SSL

There must be some monitoring of any new threats/ compromises to this method of authentication. The issue of caching the usernames and passwords must be tackled. Initial solutions include offering an option of sending a request that sends a username and password of clear which the system then returns code such as 203 – Non-Authoritative Information

4. Ensure singleton for resources such as creating accounts, assessments is truly singleton

ref: https://www.oracle.com/technetwork/articles/java/singleton-1577166.html

• Separate databases

The databases are already account and assessment. If we added authentication with its own manager this would allow usernames and passwords to be separated from account and assessment. This also has the benefit of decoupling the authentication from the accounts in the system later moves to another authentication method .e.g OAuth2.

• Salted Hashes of Passwords, user data etc.

Hashing should not use MD5 but SHA256 from the java security library ref: https://www.youtube.com/watch?v=hNKfEwTO3AQ Salts should be kept in a separate database away from the password database. Salts should be kept in a separate database away from the password database.

• Create reusable security controls I.e dependency injection.

• Security controls should be vetted and standardised

• Build training, testing and other activities around the security controls.

• Use OWASP Security Verification Standard (V3).

The basic level of standard shall be used. The system should not hold more information other than security questions, email address, username & password and assessments authored. This will also simplify GDPR legislation. If the amount of personal information changes then this the checklist should be reviewed in case further level of requirements need to be implemented.

1.1 Verify that all application components are identified and are known to be needed.

All the components would have been identified in the development process.

2.1 Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of complete mediation).

Added to checklist for creating unit tests

2.2 Verify that all password fields do not echo the user’s password when it is entered

Added to the client testing checklist

2.4 Verify all authentication controls are enforced on the server side.

To be added as unit tests for the KUPfacade interface. And a set of tests using curl using a bash script.

2.6 Verify all authentication controls fail securely to ensure attackers cannot log in.

Added to unit tests for components requiring authentication.

2.7 Verify password entry fields allow,or encourage,the use of passphrases, and do not prevent long passphrases/highly complex passwords being entered.

Create a scheme that is enforced or encouraged by the client for minimum requirements there shall be a unit test to ensure the authentication manager enforces this. The is kept in the related post (KUP Assessments – Password Schema)

2.8 Verify all account identity authentication functions (such as update profile, forgot password, disabled/ lost token, help desk or IVR) that might regain access to the account are at least as resistant to attack as the primary authentication mechanism.

The project initially thinking it would use security questions. I have now decided that security questions are too weak a process and an email recovery service should be employed using the JavaMail API.

2.9 Verify that the changing password functionality includes the old password, the new password, and a password confirmation.

Added to unit test for authentication manager.

2.16 Verify that credentials are transported using a suitable encrypted link and that all pages/ functions that require a user to enter credentials are done so using an encrypted link.

This is completed using a bash script and curl.

2.17 Verify that the forgotten password function and other recovery paths do not reveal the current password and that the new password is not sent in clear text to the user.

Added to unit test for password recovery and authentication manager.

2.18 Verify that information enumeration is not possible via login,password reset, or forgot account functionality.

This shall be controlled by the hosting service and has been added to the ongoing threat assessment/ management.

2.19 Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).

Shall be blocked by the password scheme in the system – common passwords.

2.20 Verify that request throttling is in place to prevent automated attacks against common authentication attacks such as brute force attacks or denial of service attacks.

This to be done by limiting bandwidth or another resource. Rate limit everything that could slow down or break the application. Use a simple counter kept in a quantised bucket

Decide on limit

Should not be too aggressive. Log if limits are reached and amend limits if required.

Bursting should not be required. Simple but different levels of limitting when authoring to participating

Decide identifier for limit

Must be an combination of IP address and username for authoring and IP address, browser and resource requested

Decide on exceptions for rules

Dynamic rating – all users. In this project no.

IP addressees – have exceptions for any monitoring tools or datacentre ranges (addresses that end web consumers should not be using). Also no limiting of yahoo, google etc.

Source: https://www.youtube.com/watch?v=Q53eR7mFsRo

2.22 Verify that forgotten password and other recovery paths use a soft token, mobile push, or an offline recovery mechanism.

Added to PasswordRecovery unit test.

2.24 Verify that if knowledge based questions (also known as “secret questions”) are required, the questions should be strong enough to protect the application

Secret questions are not used in this application.

2.27 Verify that measures are in place to block the use of commonly chosen passwords and weak passphrases.

Added to passwordschema unit test from general resource and privacy tests.

2.30 Verify that if an application allows users to authenticate, they use a proven secure authentication mechanism.

Basic authentication and ssl is to be used.