Month: July 2019

Moving functionality

KUP_Gatehouse – removed functionality from checking http_headers to an interceptor class. The same for VERB checker

Need to move authenticationManager to the gatehouse and away from the accountManager as it a better fit as a filter/ interception class

Changing Class names naming scheme

Renamed some of the classes e.g KUP_Assessements so they fit normal naming conventions e.g KupAssessments

Introducing Interfaces

AccountsDatabase should be an interface to allow different database types to be used. Renamed AccountDatabase to IaccountDatabase.

Refined Class Diagram

●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.

●Cryptographic module– Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.

●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

Sanitise html using https://github.com/OWASP/java-html-sanitizer

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.

iInputCheckFilter

All input is limited to an appropriate size limit

Single Responsibility Principle

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.

Interface segregation principle & Dependency inversion principle

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.