---
title: "SENG 426 - Group 13 - Delivery 5"
date: July 16, 2020
output: pdf_document
geometry: margin=3cm
---
# SENG 426 - Group 13 - Delivery 5
> Delivery 4: Performance & Scalability Testing
>
## Threat Modeling
### Use Case Diagram
https://app.diagrams.net/#G1c26RJNXOV7tLydGts8iHcrcdq5I67jIq

### Misuse Case Definitions
- **Bypass Registration**: By changing the url of the webpage to `http://localhost:4080/registersuccessfull` an attacker is able to bypass account creation/registration.
- **Personal Info Tampering**: Without proper escaping of user entries, an attacker can input a SQL command such `select * from ...` to user data from a file upload. Such attacks can occur from media file metadata as well as files such as text or script files <sup>[[1](https://ackcent.com/blog/testlink-1.9.20-unrestricted-file-upload-and-sql-injection/)]</sup>. In the Personal Info Tampering Case, this allows an attacker with an account to modify other user's data using this method.
- **Manager Approval**: With a similar attack vector as above, this misuse case instead modifies the attacker's own data, allowing them to mark account features as approved when such approval should come from a staff member.
- **Fraudulant Bank Account**: This misue case acts similar to above, allowing a attacker to inject an approved account into the DB system without proper staff approval. It can also make use of an XSS attack vector by running scripts via the url such as modifying `http://localhost:4080/entity/customer?page=1&sort=state,desc` to run a script like `http://localhost:4080/entity/customer?<script type ...> ... </script> `
### Misuse Case Diagram and Mitigations
https://drive.google.com/file/d/16Az0JvB452QzN5HpLj5QvFQM2zAbcQc-/view?usp=sharing

https://drive.google.com/file/d/10wDG0lqFV2Y8FgkLrz8NoY9BQQu2KYjR/view?usp=sharing

### Threat/Vulnerability Matrix
| Threat Identified | Use Case(s) | Vulerabilities | Mitigation | Verification | Test Status |
| ----------------------------------------------- | ----------- | -------------- | ---------- | ------------------------------------ | ----------- |
| Bypass registration | Registration | Directory traversal | Input validation | Ensure that no unregistered users are able to view the site | Untested |
| Leak/Tamper with Personal Info | Upload documents, approve new bank account, view logs, manage users, view database | SQL Injection | Prepared statements, multifactor authentication in the case of viewin database and managing user | Ensure that site has no exploitable SQL injection inputs | Untested |
| Gain Unautheorized Document Approval | Upload Document | XSS | Input validation and output encoding | Ensure that all pages are loaded with encoded outptu and all inputs have input validation. | Untested |
| Gain Unauthorized Approval For New Bank Account | Request new bank account | XSS | Input validation and output encoding | Ensure that all pages are loaded with encoded outptu and all inputs have input validation. | Untested |
| Hijack Session | Edit news and updates | Open redirect, XSS | Input validation and output encoding | Ensure that all pages are loaded with encoded outptu and all inputs have input validation. | Untested |
| Expose More Vulnerablilities | View system configuration | Unautherized access | Multi-factor authentication when viewing config | Ensure configuration page is password protected | Untested |
| Gain Unauthorized System Privilages | Edit account details | SQL Injection, XSS | Input validation, output encoding. prepared statements | Ensure that site has no command injection vulnerabilities | Untested |
| Steal Money | Transfer money | SQL injection, XSS | Input validation, output encoding, prepared statements | Ensure that site has no command injection vulerabilities | Untested |
| Bypass Login | Login | Open redirect | Input validation | Ensure the no user can access a page without being logged in | Untested |
| Sniff and Replay | Login | Password exchange in clear text or with weak cryptosystem | Using SSL and Multifactor authentication | Use a sniffer to capture and analyze traffic to see if cryptosystem meets standard practice | Unstested |
| Online Password Cracking | Login | Weak passwords made by users | Ensure users create strong passwords by having a password stength checker | Ensure that no weak password is able to be created | Untested |
| Leak Password Hashes | Login | Directory traversal | Input validation | Ensure no directory traversal can be achieved | Untested |
## Static Code Analysis with SonarQube
Using SonarQube to statically analyze the codebase, possible vulnerabilities were identified. Initially, 42 vulnerabilities were detected as shown in the following figure.


The group has assessed the severity, commented on the specific issue and offered a possible method of correction for each vulnerability. Severity of the vulnerability was set based on the recommended default by SonarQube based on the vulnerability type as shown in the following figure. 
Group members left comments on vulnerabilities with initial thoughts, diagnosis and possible mitigation strategies.

## Penetration Test
https://drive.google.com/file/d/1tPFJW9yYC81QpE0KchTD9HuNmkbLK9Bc/view?usp=sharing
To perform the penetration test on the site, many features of ZAP were used to identify vulnerabilities. The first method of finding vulnerabilities was to set up the proxy and manually go through the site. The proxy was set to be used in the firefox preferences section where the url and port were set to the zap proxy. After the proxy was set up, the site was navigated with each type of user to their respective accessible tabs and windows.
The site was then automatically scaned. First using the active scanner, which injected a large amount of know vulnerabilities into different requests. We then used a ZAPs spiders to try and find new urls and exploit them. Then, finally, we used the forced browsing to try and find any hidden URLs that we couldn't find with the spiders or the active scan.
After found all of teh vulnerabilities that ZAP had alerted us about, we then confirmed the major ones using the information that ZAP had indicated to us.
### ZAP Testing Severity
| vulnerability Location | Type | ZAP Flag | Team Rating | Reasoning For Team Rating |
|-----------------------|---------------------------------------|----------|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| POST /authenticate | SQL Injection | High | High | Well known type of vulnerability, no code escaping done |
| GET /transactions | Error Disclosure | Medium | HIgh | Easy to reach, high if other errors not mitigated, though error is of type NumberFormatException |
| GET / | Wildcard Directive | Medium | Non-vulnerability | Seems to be a false flag with Jhipster 404 code |
| GET /app | Wildcard Directive | Medium | Non-vulnerability | Seems to be a false flag with Jhipster 404 code |
| GET /v2 | Wildcard Directive | Medium | Non-vulnerability | Seems to be a false flag with Jhipster 404 code |
| GET /v2/api-docs | Wildcard Directive | Medium | Non-vulnerability | Seems to be a false flag with Jhipster 404 code |
| GET / | unsafe-inline | Medium | Low | Allows for editing of page through xss to display fake links if accessed through browser, but may be outside of our scope as part of Jhipster |
| GET /app | unsafe-inline | Medium | Low | Allows for editing of page through xss to display fake links if accessed through browser, but may be outside of our scope as part of Jhipster |
| GET /v2 | unsafe-inline | Medium | Low | Allows for editing of page through xss to display fake links if accessed through browser, but may be outside of our scope as part of Jhipster |
| GET /v2/api-docs | unsafe-inline | Medium | Low | Allows for editing of page through xss to display fake links if accessed through browser, but may be outside of our scope as part of Jhipster |
| GET /content | X-Frame Options Header not Set | Medium | Non-vulnerability | Attacker could in theory have an iframe display the error popup for jhipster and have some nefarious link cover it. However this seems like a exteamly low attack chance |
| GET /content/css | X-Frame Options Header not Set | Medium | Non-vulnerability | Attacker could in theory have an iframe display the error popup for jhipster and have some nefarious link cover it. However this seems like a exteamly low attack chance |
| GET /content/images | X-Frame Options Header not Set | Medium | Non-vulnerability | Attacker could in theory have an iframe display the error popup for jhipster and have some nefarious link cover it. However this seems like a exteamly low attack chance |
| GET /api/news | XSS Weakness in JSON Response | Low | Non-vulnerability | Already mitigated by "Content-Type: application/problem+json" |
| GET /app | X-Content-Type-Options Header Missing | Low | Medium | May be exploited for MIME-sniffing on older browser, as site features user uploaded content, easy fix |
| GET /content | X-Content-Type-Options Header Missing | Low | Medium | May be exploited for MIME-sniffing on older browser, as site features user uploaded content, easy fix. |
## Post Fix
### SonarQube and ZAP Retests
### Post-Fix SonarQube


No vulnerabilities were found via SonarQube after the required security fixes were made.
#### Post-Fix ZAP Results

| vulnerability Location | Type | ZAP Flag | Team Rating |
|-----------------------|---------------------------------------|----------|------------------|
| GET / | Wildcard Directive | Medium | Non-vulnerability |
| GET /v2/api-docs | Wildcard Directive | Medium | Non-vulnerability |
| GET / | unsafe-inline | Medium | Low |
| GET /v2/api-docs | unsafe-inline | Medium | Low |
| GET /app | X-Content-Type-Options Header Missing | Low | Medium |
| GET /content | X-Content-Type-Options Header Missing | Low | Medium |
In this second test, the Header Missing error locations were narrowed down, showing them to be outside of scope, as they were part of Jhipster's code.
With this, we can see that all remaining vulnerabilities are rated Low by the team.
### Tool Comparison
ZAP in it's current form as a standalone product made it both slightly easier to run locally than SonarQube, but in the long-term, SonarQube presents a better implementation into the Git development flow. This increases with the paid versions of SonarQube that are better for forked flow, as this would automatically scan branched code to allow for developer confidence. However, there is a GitHub action for running automatic ZAP tests, meaning that if the project was switched to be hosted via GitHub, implementation of ZAP tests could be made simpler.
### Improvement of Future Testing
For the future of improvement of testing, if implemented into a larger org, the testing process could be more defined such as having designated people handle certain operations to ensure consistency. For example, having leads for testing that had more of final say could help steer and prioritize fixes and focuses of testing.
One feature that could be implemented in the future could also be the formalization of ranking vulnerabilities, such as using the Common Vulnerability Scoring System. This would allow the team to have a standardized and more precise method of rating vulnerabilities, and when more are found, allowing for better prioritization of code fixes based off easy of attack and ease of fixing.
Finally, testing in the future implementation could have more impact on the development cycle of future releases, such as delaying releases if too many critical errors or blockers were found, as to ensure a insecure product was not released.