2808ICT-Assignment2-2022

Loc Khuu s5088787 - Quoc Hoan Hoang s5245648

TEAM
RED BLOOD – YELLOW SKIN
 1. Build Project Containers in Docker
1.1 Docker file storage
Create a repository called dockerfiles to store the 4 Docker files that are used to build the 4 required
images to implement the full-stack project, then for each Docker file create a repository with name
that corresponds to what they will do.

1.2 Dockerfiles
Each Docker file will be named appropriately to corresponds to what they will do.

Dockerfile.app is responsible for building the front-end application

Dockerfile.mongodb is responsible for building the backend-database of application

Dockerfile.mongoexp is responsible for building the graphical interface for the backend-database of
application

Dockerfile.proxy is responsible for building the proxy to allow secure https connections for the
project.
1.3 Dockerfiles Content
1.3.1 dockerfile.app

1.3.2 dockerfile.mongodb

1.3.3 dockerfile.mongoexp

1.3.4 dockerfile.proxy
 1.4 Build docker image
1.4.1 frontend application
Using the command sudo docker build -f dockerfiles/application/Dockerfile.app -t frontend . to
build the image for the frontend application

1.4.2 backend-database build

Using the command sudo docker build -f dockerfiles/mongodb/Dockerfile.mongodb -t backend-
db . to build the image for the frontend application

1.4.3 backend-graphical interface build

Using the command sudo docker build -f dockerfiles/mongoexp/Dockerfile.mongoexp -t backend-
gi . to build the image for the frontend application
 1.4.4 proxy build
Using the command sudo docker build -f dockerfiles/proxy/Dockerfile.proxy -t proxy . to build
the image for the frontend application

1.5 Docker images

After building the images from the dockerfiles, by using docker images command to view the built
images

1.6 Building the containers

1.6.1 front end container
Using the command docker run -d -p 3000:3000 --name frontend-application frontend to build
the frontend-application container using the frontend image we have created in section 1.4

1.6.2 backend-db container

Using the command docker run -d -p 3000:27107 --name backend-DB backend-db to build the
backend datebase container using the frontend image we have created in section 1.4

1.6.3 backend-gi container

Using the command docker run -d -p 3000:8081 --name backend-GI backend-gi to build the
graphical interface of backend datebase container using the frontend image we have created in section
1.4

1.6.4 proxy container

Using the command docker run -d -p 3000:80 --name https-proxy proxy to build the proxy
container using the frontend image we have created in section 1.4
1.7 Containers

2. Automate Project Build using Docker Compose

2.1: Docker-compose.yml:
Create a docker-compose file in the main file with command: nano docker-compose.yml
After that, added content to the file:

2.1.1: Application
For the Application service, the container is named by the content inside the READFILE,
“nodejs-shop”. The image is “frontend”, which just made by Dockerfile.app in Task 1.
Ports for this service is, “3000:3000”. To make docker-compose wait for
MongoDB container to be ready before starting a dependent docker application container, using
command “depends_on: mongo”.
2.2.2: Mongo-express
The container has been named, “mongo-express”, with the image “backend-gi” which just
made by Dockerfile.mongoexp. To keep the app secure and flexible, some environments has
been added:
- ME_CONFIG_MONGODB_SERVER=mongo
- ME_CONFIG_MONGODB_PORT=27017

To persisting data generated by and used by Docker containers, volumes has been added, and
in this case, volumes is stored at: mongodata:/data/db. The ports for mongo-express is,
“8081:8081”.

2.2.3: Mongodb
For service mongo, the steps of setting are kind of similar to mongo-express but missing the
environments. The image used for “mongo” service is “backend-db” which just made by
Dockerfile.mongodb. Container name is “mongo” and ports at “27017:27017”. Volumes is
stored at: “mongodata:/data/db”
2.2: Automate build
After finish setting up the docker-compose.yml file. The automate build process is the next
process. To automate build the multiple containers from the docker-compose, run
command: sudo docker-compose up.

The docker-compose will automate build the application, to be success, whatever happen
as following are expected:
To check has the program success or not, access to the link, “localhost:3000”. If it works as
following that mean the automate has been success.
3. Automate Security Testing with ZAP
3.1 Automated testing
Start automated scan with adding localhost:3000 after build docker-compose. The program
will automate scan by OWASP ZAP.

Pic 3.1 & 3.2: Starting to automate scan.

Pic 3.3: The program was scanning the app.

Pic 3.4: The Scan progress of the active scan.

Pic 3.5: 4 type of Alerts found after scan were:

- SQL Injection
- Content Security Policy
- Cookie without SameSite Attribute
- Loosely Scope Cookie.
Pic 3.6: The SQL Injection in detail.

Pic 3.7: The Content Security Policy in detail.

Pic 3.8: The Cookie without SameSite Attribute in detail.

Pic 3.9: The response for Cookie without SameSite Attribute.

Pic 3.10: The Loosely Scope Cookie in detail.

 3.2 Manual testing
In Workspace Window, choose Manual Explore. Input URL : HTTP://localhost: 3000, and
choosing Enable HUD, then click Lauch Browser.

Pic 3.11: Set up URL for Manual Explore

Pic 3.12: ZAP HUD interface.

 Pic 3.13.1 & 3.13.2 & 3.13.3 & 3.13.4: The Alerts in the begging.

Pic 3.14: Cart Page.

 - After checking the Alerts in the beginning, I started to open everything single tab, so the
sites could be record in the scan system. If there is any problem, the alert must be comes
up.

Pic 3.15: Order Page.

Pic 3.16: Admin Products Page.

Pic 3.17: Add Product page.

- This picture showing the process of adding item to the website.

Pic 3.19: Adding Item Error happened. System Recorded new Issue.
Pic 3.20: Run spider the site after checking everything.

Pic 3.21: New Alerts has been Recorded after Spider the site.
 Pic 3.22: As the final, 14 type of Alerts have been recorded, they are:
- SQL Injection
- CSP: WildCard Directive
- Content Security Policy (CSP) Header Not Set
- Cross-Domain Misconfiguration
- Missing Anti-clickjacking Header
- Application Error Disclosure
- Cookie without SameSite Attribute
- Server Leaked Information vit “X-Powered-By” HTTP Response Header Fields(s)
- Timestamp disclosure -Unix
- X-content Type Options Header Missing
- Information Disclosure -Sensitive Information in URL
- Information Disclosure -Suspicious comments
- Loosely Scoped Cookie
- Re-examine Cache-control directives
 Pic 3.23.1 & 3.23.2: SQL Injection in detail.

- Pic 3.24.1 & Pic 3.24.2: CSP: WildCard Directive in detail.

Pic 3.25.1 & Pic 3.25.2: Content Security Policy (CSP) Header Not Set in detail.

Pic 3.26.1 & Pic 3.26.2: Cross-Domain Misconfiguration in detail.

Pic 3.27.1 & Pic 3.27.2: Missing Anti-clickjacking Header in detail.

Pic 3.28.1 & Pic 3.28.2: Application Error Disclosure in detail.

Pic 3.29.1 & Pic 3.29.2: Cookie without SameSite Attribute in detail.

Pic 3.30.1 & Pic 3.30.2: Server Leaked Information vit “X-Powered-By” HTTP Response
Header Fields(s) in detail.
Pic 3.31.1 & Pic 3.31.2: Timestamp disclosure -Unix in detail.

Pic 3.32.1 & Pic 3.32.2: X-content Type Options Header Missing in detail.
Pic 3.33.1 & Pic 3.33.2: Information Disclosure -Sensitive Information in URL in detail.

Pic 3.34.1 & Pic 3.34.2: Information Disclosure -Suspicious comments in detail.
Pic 3.35.1 & Pic 3.35.2: Loosely Scoped Cookie in detail.
 Pic 3.36.1 & Pic 3.36.2: Re-examine Cache-control in detail.

4. Analysis of Code Issue:

4.1 Analysis of Code Issue 1:
Code Issue Number: 01

Code Sample and Location: reset-password.ejs

Issue Type/Class: SQL rejection

Description: The parameter “email” will be easily exploited to insert the wrong parameter values.
Bad guys can take advantage of this vulnerability, to manipulate parameter data. When bad guys
take advantage of this vulnerability, parameter values will not be returned as the original.

Verification: SQL Injection – CWE ID:89

Impact: Modify the back-end database, possibly including execution of system commands.

Proposed Remediation: use CallableStatement with parameters passed by “?”.

4.2 Analysis of Code Issue 2:

Code Issue Number: 02

Code Sample and Location: login.ejs

Description: All the login, sign up and the reset password pages have this error since fields
modification are not disabled which allows attackers to modify these fields and trigger the error and
saves the users email and password.
Verification: CWE 200- Exposure of Sensitive Information to an Unauthorized Actor

Impact: Confidential information of user leak to attackers or non-authorized users

Proposed Remediation: CSRF token can be included in the meta tag, all the calls in the page can
extract the CSRF token from the meta tag. <meta name="csrf-token"
content="{{ csrf_token() }}">

4.3 Analysis of Code Issue 3:

Code Issue Number: 03

Code Sample and Location: admin.js

Description: No CSP layer is added to protect the page from attacks such as XSS, data injections and
many others.

Verification: CWE 693 – Protection Mechanism Failure

Impact: Data theft, distribution of malware and website defacement

Proposed Remediation: setting a proper default-src, for example, Content-Security-Policy: default-src

<source> <source>

4.3 Analysis of Code Issue 3:

Code Issue Number: 04

Code Sample and Location: admin.js

Description: The response appears to contain suspicious comments which may help an attacker

Verification: WASC –13: INFORMATION LEAKAGE

Impact: Leak of sensitive, contextual, information such as server directory structure, SQL query
structure, and internal network information.

Proposed Remediation: Remove all comments that return information which can help attacker and
fix any underlying problem they refer to.