I had a raspberry pi zero from a failed back up server project and an old usb sound card. This card is a creative 24 live 5.1 surround sound blaster. I decided I would set up a bluetooth receiver to feed audio into my old 5.1 surround sound system. I also like to listen to music when I am gaming. I don’t do this very often but I would like to be able to control the music from my phone including its volume. Sending it via bluetooth into the audio in (the spdif in this case) on the PC seems like a flexible way of doing this. So I thought I would put the two together and get a little more use out of the sound card. So the receiver should:
Accept audio from my phone at the highest quality possible.
Push audio via the analog out to amp and my PC (via an audio splitter)
There are plenty of guides out there for bluetooth speakers, audio recievers which use Raspbian. The issue with most of these is that they don’t appear to use the HD audio. The ones that do either require you to create an account such as with Balena . I didnt particularly didn’t want to do that I wanted to see if I could set up a high quality audio myself. Further investigation I found plenty of guides for bluetooth speakers however I could not see they supported HD audio just pushing the audio through pulse. Although one of the guides was useful for managing the bluetooth pairing.
I eventually found a site that recommended pipewire and pipeplumber which supports HD audio out of the box. This is the method I settled on. However Wireplumber is not easily accessible from Raspbian. It requires a back port and I could not get it to work. So I tried the Ubuntu server and these libraries were available. (although It created additional steps later)
The sites I used can be found at the end this article.
Install
I installed Ubuntu server from using the Raspberry Pi Imager with SSH, wifi login etc. Then I updated and upgraded Ubuntu:
sudo apt update && sudo apt upgrade
From reference 1 in the resources section I installed the pipewire and wireplumber
Now I did follow the rest of the guide to get pairing up and running but it didn’t seem to work. so I installed bluetooth
sudo apt install bluetooth
Then I ran bluetooth (type bluetoothctl) from the command line select pair from my bluetooth menu on my phone requested paring and then in the terminal accepted the paring when prompted. I then entered trusted into the terminal and then exited bluetooth by typing exit in the terminal. Trusted means no passcode required next time you pair the phone to the pi.
I tested the audio by plugging in a headphone and played some music on my phone. This worked however the volume was low. Some searches found the archwiki page for Pipewire which had the solution . I had to install the ASLA utilities to get the alsa mixer up so I could increase the volume and save it. This was done by:
sudo apt-get install alsa-utils
Then open the mixer by typing alsamixer. Then amend the volume and type
sudo alsactl store
This will store the volume after reboot. Or it should have done. The volume kept resetting so I had to do follow the guidance here.
Unattended updates
Now I won’t be logging in often in over SSH. If only to pair other devices. So I set unattended updates:
I have been running this set up for the last 3 months. What has been the biggest surprise was the sound quality. Now for years I have always read if you can use a digital output you should it is always better. However this setup using the analog outputs to my Denon receiver has much better sound quality than when I have used the Denon’s optical input. I am not an expert in this area but I know what I like. So why is this the case. It could be that optical or spdif output is outdated but I think it is more than this. Again I am not an expert but I can only speculate. So I think what is happening is the DAC on the creative sound card is much better that the DAC in the Denon receiver. I tried the same with the PC connecting the PC’s Asus card to the Denons external 7.1 inputs the result was again improved quality. Dialog in TV was clearer, I hear notes on music I didn’t know were there.
So I guess the lesson is to not always take everything at face value.
The next few posts are going to be more like diary entries than posts on specific topics. They will have show my train of thought and therefore will be full of assumptions.
Last year I did a course of TDD with Jpassion.com. It was a useful course and allowed me to also refine and expand on many of my projects. However it did not cover when starting projects you start creating tests. My first instinct was to start straight away however it meant an a lot of mocking and from my searches of the net, there are mixed feelings regarding mocking.
So I have settled on a actual sql database for building the account database as I can also be assured that the SQL statements work. I have had a quandary of refactoring. Consider the following statements:
public Boolean createAccount(String username, String email) throws StoringAccountException, AccountAlreadyExistsException{ connect(); if (checkAccountAlreadyExists(username)) { close(); throw new AccountAlreadyExistsException(); } try { conn.prepareStatement(generateNewAccountSQLStatement(username, email)).execute(); close(); return true; } catch (SQLException e) { e.printStackTrace(); close(); throw new StoringAccountException(); } }
Now I could refactor these as there is a some repetition here. However, some of the methods throw specific exceptions. How do I refactor and keep the exceptions? Or is the issue that some of methods throw exceptions and some don’t. A lack consistency in the interface. Should all the methods throw an exception which may make it easier to refactor? These crud methods however may change further and refactoring could complicate adding the functionality. I will have to return to this issue later and see if I can refactor once other functionality e.g SQL injection prevention is included. I can of course use a finally clause to tidy up the code.
This requirement relates to the following classes with associated test cases:
KupGatehouse
Authentication Manager
KupFacade
KupAssessments
AccountManager
AccountDatabase
HTTP_HeaderChecker
Additionally there is a bash script to test from the frontend of a working system.
Changing Names to Suit Interfaces.
A number of interfaces have altered their names, slightly to reflect that they are interfaces. e.g AccountDatabase has become IaccountDatabase.
Database choice – MySQL
The first implementation of the IaccountsDatabase will be an MySQL database. this is because of the support that is available for MySQL and for not for speed or ideological reasons. I just want it to work.
Database setup
The initial database, which is not embedded so there is flexibility in where the database is located, is set up using a sql scipt. The login details for the AccoundDatabaseSQL class uses to access the database is kept in a properties file on the server. I do worry over the security issues for this but for lack of finding a better solution and the fact that if someone able to access the file, there will be greater problems that just the accounts database being compromised. This will require revisiting later.
IAccount Class creation
My first thoughts are to use a factory pattern for the creation and submission of accounts. The problem is I would be restricted to what the data structure of the concrete account classes would be. Behavior of course would be malleable, but what if there was a method of a class reveal structure a run time. e.g revealDataStructure() it would be up to the IaccountDatabase to store this in its database. The database would also need to be able to handle the structure. In the case of MySQL database this is completely reasonable. so how do I get the factory to insert the data structure. Well I could instead use a method for Iaccount such as loadDataStructure(Map aMap) the class would then wire up its data structure itself. It could also have getDataStructure() which would return a map which it’s keys and values (Strings) could be iterated through to store its data structure. Or should I be creating a IAccount class at all. It is only going to be flattened into a xml or json structure anyway? No. For simplicity of the interface between components, the Iaccout being passed around would be better.
Will accept password if it is within the most 10000 but not
the most 1000 the response will contain a warning and an option to
change the password. – The response will not echo the password.
Encourage passphrases. By warning if the password is
shorter than 10 characters in length, but will not warn if longer
than 15 or the password has 2 or more special characters in it such
as {}[]@:~!”£$%^&*()_+=-¬`|\/?><
Enforce case changing in the password. Mix of upper and
lower case.
●Access Control– A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
●Address
Space Layout Randomization (ASLR)– A
technique to help protect against buffer overflow attacks.
●Application Security– Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
●Application
Security Verification– The
technical assessment of an application against the OWASP ASVS.
●Application Security Verification Report– A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
●Authentication–
The
verification of the claimed identity of an application
user.●Automated
Verification– The
use of automated tools (either dynamic analysis tools, static
analysis tools,or both) that use vulnerability signatures to find
problems.
●Back
Doors– A
type of malicious code that allows unauthorized access to an
application.
●Blacklist– A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
●Cascading Style Sheets(CSS) – A style sheet language used for describing the presentation semantics of document written in a markup language, such as HTML.●Certificate Authority(CA) – An entity that issues digital certificates.
●Communication Security– The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
●Component– a self-contained unit of code, with associated disk and network interfaces that communicates with other components.
●Cross-Site Scripting(XSS) – A security vulnerability typically found in web applications allowing the injection of client-side scripts into content.
●Denial
of Service (DoS) Attacks– The
flooding of an application with more requests than it can handle.
●Design
Verification– The
technical assessment of the security architecture of an application.
●Dynamic Verification– The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
●Easter
Eggs– A
type of malicious code that does not run until a specific user input
event occurs.
●External
Systems– A
server-side application or service that is not part of the
application.
●FIPS 140-2– A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules●Globally Unique Identifier(GUID) – a unique reference number used as an identifier in software.OWASP Application Security Verification Standard 3.064
●HyperText Markup Language (HTML)- The main markup language for the creation of web pages and other information displayed in a web browser.
●Hyper Text Transfer Protocol(HTTP) – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web.
●Input Validation– The canonicalization and validation of un-trusted user input.
●Lightweight Directory Access Protocol (LDAP)– An application protocol for accessing and maintaining distributed directory information services over a network.
●Malicious Code– Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
●Malware– Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
●Open Web Application Security Project(OWASP) – The Open Web Application Security Project (OWASP)is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security “visible,” so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
●Output encoding– The canonicalization and validation of application output to Web browsers and to external systems.
●Personally Identifiable Information(PII) – is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.
●Positive
Validation–
See
whitelist.
●Security Architecture– An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
●Security Configuration– The runtime configuration of an application that affects how security controls are used.
●Security
Control– A
function or component that performs a security check (e.g. an access
control check)or when called results in a security effect (e.g.
generating an audit record).
●SQL Injection (SQLi)– A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point.
●Static Verification– The use of automated tools that use vulnerability signatures to find problems in application source code.
●Target of Verification (TOV)– If you are performing application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the“Target of Verification” or simply the TOV.
●Threat Modeling- A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
●Transport Layer Security– Cryptographic protocols that provide communication security over the Internet OWASP Application Security Verification Standard 3.065
●URI/URL/URL fragments– A Uniform Resource Identifier is a string of characters used to identify a name or a web resource. A Uniform Resource Locator is often used as a reference to a resource.
●User acceptance testing (UAT)– Traditionally a test environment that behaves like the production environment where all software testing is performed before going live.
●Verifier-
The person or team that is reviewing an application against the OWASP
ASVS requirements.
●Whitelist– A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.
●XML–
A
markup language that defines a set of rules for encoding documents
The following specific test cases were developed concurrency during the above development process. Additionally KUP_Gatehouse had functionality removed to new classes checking http_headers (interceptor class). The same for VERBchecker
Resources and Private Pages – I.e tested from
outside the application using a bash script and curl
Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of complete mediation).
Verify all authentication controls are enforced on the server side. – Curl and bash script & Unit test on components.
Verify all authentication controls fail securely to ensure attackers cannot log in – Unit tests with exceptions.
Client and authentication manager to inform encourage and discourage passwords using the following given in the post KUP Assessments Password Schema.
KUP_Gatehouse
Sets up filters and interceptors
for incoming requests and outgoing responses
When username and password are
both set to clear return 203 – Non-Authoritative Information
HTTP_HeaderChecker
All sensitive data is sent to the server in the HTTP
message body not the headers
Any requests containing data other than that defined by the
system in the header is rejected with a 400 response
X-XSS-Protection:
1; mode=block header is in place
Sets
appropriate anti-caching headers as per the risk of the application,
such as the following: Expires: Tue, 03 Jul 2001 06:00:00
GMTLast-Modified: {now} GMTCache-Control: no-store, no-cache,
must-revalidate, max-age=0Cache-Control: post-check=0,
pre-check=0Pragma: no-cache
Verb_Checker
Only
accept standard crud HTTP verbs (GET, POST, PUT, DELETE)
RequestThrottler
Log if limits are reached
Must be an combination of IP address and username for authoring and IP address, browser and resource requested.
IP addresses – 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.
return 429 status code and advice in header
Is there an existing Throttling library?
KUP_Facade
URL endpoints
Base URL: /KUPassessments/
account/create/
account/update/
account/assessment/create/
account/assessment/{assessmentid}
account/assessment/update/
account/assessment/delete/
participant/assessment/{assessmentid}
Every HTTP response contains a content type header specifying a safe-character set (e.g., UTF-8, ISO 8859-1).
HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
all API responses contain X-Content-Type-Options:nosniffandContent-Disposition:attachment;filename=”api.json”(or other appropriate filename for the content type).
URL redirects and forwards only allow white listed destinations, or show a warning when redirecting to potentially untrusted content.
ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not used as authentication tokens
Same encoding style is used between the client and the server
URIsanitiser
intercepts all parameters in the
uri’s for os command injection attacks and returns a 406 error if
any are found. Commands include chaining with “&”,
“&&”, “|”, “||”,
Intercepts
file inclusion attacks by stopping calls that have .txt .php or any
file extension and return a 406 error.
Intercepts
Local File Inclusion (LFI)
attacks by looking for ../
in a uri and returning a 406 error
KUP_Assessments
Acts a the link with the rest of
the application
PasswordRecovery
Sends an email to account with code and link that stays alive for
5 minutes.
When post request received must have live reset code/soft token
with new password and confirmed new password.
When the response to new password is
sent it does not contain any account identifiable information or
password data (old or new). Either in successful response or failure
Verify that the changing password
functionality includes the old password, the new password, and a
password confirmation.
When the response to updated password
is sent it does not contain any account identifiable information or
password data (old or new). Either in successful response or failure.
Client Application
Verify that all password fields do not
echo the user’s password when it is entered. ie. echo is set to
false.
Client asks for a token with the
details of the request. Before sending POST, PUT or DELETE requests.
Request must provide type of request, length of request
all forms containing sensitive
information have disabled client side caching, including autocomplete
features.
data stored in client side storage – such as HTML5 local storage, session storage, Indexed DB, regular cookies or Flash cookies – does not contain sensitive or PII).
Do not use Flash, Active-X,
Silverlight, NACL, client-sideJava or other client side technologies
not supported natively via W3C browser standards.
ID values stored on the device and
retrievable by other applications, such as the UDID or IMEI number
are not used as authentication tokens.
sensitive data is not stored
unprotected on the device, even in system protected areas such as key
chains.
same encoding style is used between the
client and the server
AuthenticationManager
Returns true if username and password is correct.
Locks account after 3 attempts (throw an exception)
It does not reset lost passwords
administrative interfaces are not accessible to un-trusted parties.
authors can only amend their own
assessments
authors can only add assessments in
their own name.
Failures in authentication should be returned with access blocked, not with any reference to PAD or MAC errors, software/ framework versions and personal information
Exceptions should return with access
blocked.
Any error/exception results in a
refused access to requested service.
The time for authentication to fail
should be the same I.e 5 seconds.
Asks a HMAC service for a token when a post, put or delete request
is to be made. This is returned to the client. Request must provide
type of request, length of request.
Content Security Policy V2 (CSP) is in
use in a way that either disables inline JavaScript or provides an
integrity check on inline Java Script with CSP noncing or hashing.
Only Management accounts can access all
assessments with full control to create, edit and delete assessments
and accounts.
iAccountCreator
Creates accounts with username, password and email address for resetting lost password.
PasswordSchema
Password schema should enforce the password conditions identified in the resources and privacy pages unit tests.
Any error/ exception must cause the result in a rejected password
HMACservice
compares a token with what has been sent and see if they are the
same. Returns true if so, otherwise returns false. The token is a
double (2) nested hash e.g a json web token.
Any exception/error causes a refusal to issue a token.
ID values stored on the device and
retrievable by other applications, such as the UDID or IMEI number
are not used as authentication tokens
IMACbuilder
Creates a token using HMACs construction based on a request that
is expected. It takes a request type, length of message and returns a
token
decrypts a received token
Should use GMC, CCM or EAX standards (Minimum FIPS 140-2) to encrypt which uses the HMACservice to build the MAC
AssessmentValidator
Verify that input
validation routines are enforced
Checks the input
of participant and author and performs input validation, failures
result in request rejection and are logged.
Rejects any
assessment containing SQL queries, HQL, OSQL, NOSQL, Xpath query
tampering, XML External Entity attacks, and XML injection attacks in
submitions from participants, authors and search requests. This
includes the assessment itself and any strings embedded in an
assessment
Any exception or
failure in an AssessmentValidator returns a failed or invalid
assessment and no further processing can take place.
Content Security
Policy V2 (CSP) is in use in a way that either disables inline
JavaScript or provides an integrity check on inline Java Script with
CSP noncing or hashing.
un-trusted file data submitted to the application is not used directly with file I/O command, particularly to protect against path traversal, local file include, file mime type, and OS command injection vulnerabilities.
No binary data is
allowed.
Only system schema
and components are used
does not execute
uploaded data obtained from untrusted sources
iSanitiser
SQL queries, HQL, OSQL, NOSQL, Xpath query tampering, XML External Entity attacks, and XML injection attacks in submissions from participants, authors and search requests. This includes the assessment itself and any strings embedded in an assessment reports true or false if a given string contains a what the sanitiser is looking for.
AssessmentManager
Assessment instantiation is only done
after the assessment has been validated. Asks the assessmentValidator
Assess the assessment based on components in the assessment it instantiates the components based on component name which implements an IassessmentComponent interface. Once the assessment is built the assess command is sent and an AssessmentResult is returned with a copy of the submitted assessment.
KUP_FACADE filters events and provides access to all the endpoints. This should be changed to classes KUP_Facade KUP_Gatehouse and KUP_Assessments. Created accountCreator interface iAccountCreator that removes the responsibility of creating an account from authentication manager to a seperate class. Added interface iAuthenticationRules. HMAC service has a iMACbuilder interface that builds the MACs whereas the HMAC service requests MACS from the builder and varifies any received MAC matches what is expected. Added interface ISanitiser that is a collection of text sanitisers that an assessmentValidator can use to find e.g any QL queries, HQL, OSQL, NOSQL, Xpath query tampering, XML External Entity attacks, and XML injection attacks in submissions from participants. IinputFilterDatabase has been introduced to limit the size of the templates to a suitable size limit. The filters and interceptors have been changed to classes as they already implement the filter and interceptor interfaces and used at the KUP_Gatehouse.
Open-Closed Principle
Classes eyed to obey this principle are AssessmentManager, AccountManager, AuthenticationManager. Also moved the AssessmentCreator to be directly accessed from KUPAssessments this way the AssessmentManager can be passed directly from within AssessmentCreator and assessmentParticipant ,once wrapped in an AssessmentLibrarian Interface.
Liskov substitution principle
Inheritance is to be generally avoided and interfaces shall be
preferred.
Although I cannot see any interfaces to separate out at this stage. I have identified that AccountDatabase, CredentialsDatabase and AssessmentDatabase should be interfaces which allows flexibility if these are injected. Assessments have been changed to a class with build-able components that follow the IassessmentComponent. The IAssessment should also follow the open closed principle.
Some while ago I recorded how I refined some old projects. One of these was the WhitestarMediaLibrary. I recently found an old Javafx (script) for a media player. So I have decided to bring these into a new project WhitestarMediaCentre. This project will not have as much emphasis as the other projects currently running (Kup Assessments and RAW Rota). The main aim for the project is to provide music playback and a game library for my legacy game system.
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
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.
• 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.
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.
2.32 Verify that administrative interfaces are not accessible to untrusted parties
This is to be achieved via a bash script and unit test on authentication manager
3.1 Verify that there is no custom session manager, or that the custom session manager is resistant against all common session management attacks.
There are no sessions in the planned service.
3.2 Verify that sessions are invalidated when the user logs out.
There are no sessions in the planned service. However there is a dummy resource where passwords in a browser can be clear out of cache using username and password of 203 – Non-Authoritative Information. This has been added to the unit tests for authentication manager.
3.3 Verify that sessions timeout after a specified period of inactivity.
There are no sessions in the planned service.
3.5 Verify that all pages that require authentication have easy and visible access to logout functionality.
There are no sessions in the planned service. However there is a dummy resource where passwords in a browser can be clear out of cache using username and password of 203 – Non-Authoritative Information. This has been added to the unit tests for authentication manager.
3.6 Verify that the session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
There are no sessions in the planned service.
3.7 Verify that all successful authentication and re-authentication generates a new session and session id.
There are no sessions in the planned service.
3.11 Verify that session ids are sufficiently long, random and unique across the correct active session base.
There are no sessions in the planned service.
3.12 Verify that session ids stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes.
There are no sessions in the planned service.
3.16 Verify that the application limits the number of active concurrent sessions.
There are no sessions in the planned service. There will be throttling provided and added to use case for RequestThrottler.
3.17 Verify that an active session list is displayed in the account profile or similar of each user. The user should be able to terminate any active session.
There are no sessions in the planned service.
3.18 Verify the user is prompted with the option to terminate all other active sessions after a successful change password process.
There are no sessions in the planned service.
4.1 Verify that the principle of least privilege exists – users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
Added to the unit test for authentication manager.
4.4 Verify that access to sensitive records is protected, such that only authorized objects or data is accessible to each user (for example, protect against users tampering with a parameter to see or alter another user’s account).
Added to unit test of authentication manager.
4.5 Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
Should be managed by hosting service.
4.8 Verify that access controls fail securely.
Added to the authentication manager unit tests.
4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side.
Implemented in the password schema, password recovery and authentication managers via unit tests.
4.13 Verify that the application or frame work uses strong random anti-CSRFtokens or has another transaction protection mechanism.
This introduces a HMACsevice interface that take responsibility for generating tokens.
4.16 Verify that the application correctly enforces context-sensitive authorisation so as to not allow unauthorised manipulation by means of parameter tampering.
On unit test list for authentication manager and HMACservice
5.1 Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.
The java language has some protection as it is strongly typed, automatic bound checks and automatic memory management. Additionally account to OWASP.org java/j2ee is not affected as long as native methods or system calls are not invoked.
5.3 Verify that server side input validation failures result in request rejection and are logged.
Created new interface AssessmentValidator which checks the input of participant and author. Added to unit tests for AssesmentValidator .
5.5 Verify that input validation routines are enforced on the server side.
Added to AssessmentValidator unit test
5.10 Verify that all SQL queries, HQL, OSQL, NOSQL and stored procedures, calling of stored procedures are protected by the use of prepared statements or query parameterization, and thus not susceptible to SQL injection
Added to assessmentValidator interface unit tests
5.11 Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.
The system will not be using LDAP for user credentials or search filters.
5.12 Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.
Create JAX-RS filter or interceptor that filters all parameters in the uri’s Interface URIsanitiser created and added to unit test list. Additionally the service will not invoke Runtime.exec in order to call operating system commands
5.13 Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used that is a path to a file.
The URI sanitiser has added unit test that will not allow file extensions to proceed.
5.14 Verify that the application is not susceptible to common XML attacks, such as Xpath query tampering, XML External Entity attacks, and XML injection attacks.
Added to assessment validator unit tests
5.15 Ensure that all string variables placed into HTML or other web client code is either properly contextually encoded manually, or utilize templates that automatically encode contextually to ensure the application is not susceptible to reflected,stored and DOM Cross-Site Scripting (XSS) attacks.
The OWASP java-html sanitiser shall be used: https://github.com/OWASP/java-html-sanitizer if it is decided html will be used when submitting new assessments and submitting assessments. This shall be used as a composit part of the assessementValidator.
5.22 Make sure untrusted HTML from WYSIWYG editors or similar are properly sanitized with an HTML sanitizer and handle it appropriately according to the input validation task and encoding task.
Added the the AssessmentValidator interface.
7.2 Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable oracle padding.
Added unit tests to the passwordschema, HMACservice and athenticationManager. There will be no error for PAD error or MAC error returned to the user (added to unit test for authenticationManager). Timing attacks shall be countered by failing attacks to always take 5 seconds or other arbitatary length of time. Ref: https://www.youtube.com/watch?v=evrgQkULQ5U
7.7 Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard.
Added to unit tests for athentication manager.
8.1 Verify that the application does not output error messages or stack traces containing sensitive data that could assistan attacker, including session id, software/ framework versions and personal information.
Added to unit test for authentication manager and bash script using curl
9.1 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.
Added to unit test for Client side application
9.3 Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used to send sensitive data).
Added to the unit test for KUP_Facade
9.4 Verify that the application sets appropriate anti-caching headers as per the risk of the application, such as the following: Expires: Tue, 03 Jul 2001 06:00:00 GMTLast-Modified: {now} GMTCache-Control: no-store, no-cache, must-revalidate, max-age=0Cache-Control: post-check=0, pre-check=0Pragma: no-cache
Added to the unit test for KUP_Facade
9.9 Verify that data stored in clientside storage – such as HTML5 local storage, session storage, Indexed DB, regular cookies or Flash cookies – does not contain sensitive or PII).
Added to client application unit test
10.1 Verify that a path can be built from a trusted CA to each Transport Layer Security(TLS) server certificate, and that each server certificate is valid.
Added to bash script using curl
10.3 Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.
Added to bash script using curl
10.11 Verify that HTTP Strict Transport Security headers are included on all requests and for all subdomains, such as Strict-Transport-Security:max-age=15724800; includeSubdomains
Added to bash script using curl
10.13 Ensure forward secrecy cipher share in use to mitigate passive attackers recording traffic.
Bash script and curl to ensure elipitic curve or diffi-hellman key when exchanging keys during TLS – check with service provider
10.14 Verify that proper certification revocation, such as Online Certificate Status Protocol (OSCP) Stapling, is enabled and configured.
Bash script and curl – check with service provider
10.15 Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of yours elected certifying authority.
Bash script and curl – check with service provider
10.16 Verify that the TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure.
Bash script and curl – check with service provider
11.1 Verify that the application accepts only a defined set of required HTTP request methods, such as GET and POST are accepted, and unused methods(e.g.TRACE,PUT,and DELETE) are explicitly blocked.
Added to unit test for KUP_Facade and bash script using curl
11.2 Verify that every HTTP response contains a content type header specifying a safecharacter set (e.g., UTF-8, ISO 8859-1).
Added to the unit test for KUP_facade
11.5 Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
Added to Bash script using curl and unit test for KUP_facade
11.6 Verify that all API responses contain X-Content-Type-Options:nosniffandContent-Disposition:attachment;filename=”api.json”(or other appropriate filename for the content type).
Added to KUP_facade unit test
11.7 Verify that the Content Security Policy V2 (CSP) is in use in a way that either disables inline JavaScript or provides an integrity check on inline Java Script with CSP noncing or hashing.
Added to KUP_facade and assessment validator unit tests
11.8 Verify that the X-XSS-Protection: 1; mode=block header is in place.
Added to KUP_facade unit test and bash script using curl
16.1 Verify that URL redirects and forwards only allow white listed destinations, or show a warning when redirecting to potentially untrusted content.
Added to KUP_facade unit test
16.2 Verify that untrusted file data submitted to the application is not used directly with file I/O command, particularly to protect against path traversal, local file include, file mime type, and OS command injection vulnerabilities.
Added to assessmentValidator
16.3 Verify that files obtained from untrusted sources are validated to be of expected type and scanned by antivirus scanners to prevent upload of known malicious content.
No files to be uploaded to the system only formatted text. Added to unit test for assessmentValidator
16.4 Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local file inclusion vulnerabilities.
Only assessmentValidator can instantiate assessments which is only done from classess only in the sourcecode of the server and not defined by the text entered into the assessment. The assessment instantiation is only done after the assessment has been validated. Added to assessmentManager unit tests.
16.5 Verify that untrusted data is not used within cross-domain resource sharing (CORS) to protect against arbitrary remote content.
Only system schema and components implimenting the assessment interfaces are used – added to assessmentValidator.
16.8 Verify the application code does not execute uploaded data obtained from untrusted sources.
Added to unit test for assessmentValidator.
16.9 Do not use Flash, Active-X, Silverlight, NACL, client-sideJava or other client side technologies not supported natively via W3C browser standards.
Added to unit test for client application.
17.1 Verify that ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not used as authentication tokens.
Added to unit test for HMAC service, Client application and KUP_Facade
17.2 Verify that the mobile app does not store sensitive data on to potentially unencrypted shared resources on the device (e.g. SD card or shared folders).
No App planned at this time.
17.3 Verify that sensitive data is not stored unprotected on the device, even in system protected areas such as key chains.
Added to client unit test
17.7 Verify that the application sensitive code is laid out unpredictably in memory(Forexample ASLR).
Using the JAVA platform negates this threat.
17.9 Verify that the app does not export sensitive activities, intents, content providers etc., for other mobile apps on the same device to exploit.
This is to be browser based and not needed at this time.
17.11 Verify that the app’s exposed activities, intents, content providers etc. validate all inputs.
This is to be browser based and not needed at this time.
18.1 Verify that the same encoding style is used between the client and the server.
Added to unit test for Client Application and KUP_Facade
18.2 Verify that access to administration and management functions within the Web Service Application is limited to web service administrators.
Added to athenticationManager unit tests
18.3 Verify that XML or JSON schema is in place and verified before accepting input.
Managed by JAX-RS
18.4 Verify that all input is limited to an appropriate size limit.
Added to new interface InputCheckFilterInterface
18.5 Verify that SOAP based web services are compliant with Web Services – Interoperability (WS-I) Basic Profile at minimum.
Not applicable for this project.
18.6 Verify the use of session – based authentication and authorization. Please refer to sections 2, 3 and 4 for further guidance. Avoid the use of static “API keys” and similar.
No sessions are to be used in this project. (REST)
18.7 Verify that the REST service is protected from Cross-Site Request Forgery.
HMAC already added to unit tests
19.1 All components should be up to date with proper security configuration(s) and version(s). This should include removal of unneeded configurations and folders such as sample applications, platform documentation, and default or example users.
A monthly review of security reports should be undertaken so new exploits can be mitigated or resolved.
For a list of terms (Glossary) please see post (KUP Assessments – Glossary)
Unit testing features of security
See the unit test post for resulting unit tests.
Independent review by a 3rd party. e.g a IT Security consultant.
