Cyber security project report

Cyber security project report

Cyber Security Base - Course Project I

I made a web application to which users can register and login to submit comments.
Logged in users can logout, view their own profile, delete their own comments and
delete their account as well as create new comments.
The application includes five different security flaws from the OWASP’s 2013 10 Most Critical Web Application Security Risks
list (https://www.owasp.org/index.php/Top_10_2013-Top_10). The flaws are as follows:

A2 - Broken Authentication and Session Management
A3 - Cross-Site Scripting (XSS)
A4 - Insecure Direct Object References
A8 - Cross-Site Request Forgery (CSRF)
A9 - Using Components with Known Vulnerabilities

The project is created on the base of the Cyber Security Base - Course Project I
starter code that is provided here: https://github.com/cybersecuritybase/cybersecuritybase-project. 

A2 - Broken Authentication and Session Management

The application works so that when the user accesses the application, they are assigned a session ID,
the session ID can be specified in the code within a Tomcat Context Customizer class.
With the following line of code the session ID can be set to two characters:

context.getManager().getSessionIdGenerator().setSessionIdLength(1);

WIth the session ID being two characters long it is enough to match the
“A2-Broken Authentication and Session Management” risk,
as it makes the session ID fairly easily guessable. 

The cookies HTTPOnly flag has been turned off with the following line of code,
also within the Context Customizer class:

context.setUseHttpOnly(false);

This means that the cookie can be accessible via JavaScript,
so if a malicious script can submitted to the website and run, the cookie’s can be compromised.
This also means that the session will be compromised.

The cookie’s HTTPOnly flag can also be set via the application.properties
file located in the /src/main/resources folder, the flag can be set with the following
line as described in the Spring’s Common Application Properties here
https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html:

Server.session.cookie.http-only

This flaw can be identified with the following steps.
Issue: Broken Session Management, cookie HTTPOnly flag false
Steps to reproduce:
1. Open OWASP ZAP
2. Run a Quick Start attack on the following address http://localhost:8081
3. View the Alerts section
4. “Cookie No Http Only Flag” can be seen

Steps to fix:
Remove either the following line from the appropriate controller:
context.setUseHttpOnly(false);

or remove the following line from the application.configuration:
Server.session.cookie.http-only

Issue: Broken Session Management, short session ID
Steps to reproduce:
1. Open the web application at http://localhost:8081
2. (On Windows & Chrome) CTRL + Shift + I 
3. Navigate to Application -> Cookies
4. View the cookie named “cookie” and the value which is 2 characters long

Steps to fix:
Remove the following line from the appropriate controller:
context.getManager().getSessionIdGenerator().setSessionIdLength(1);

A3 - Cross-Site Scripting (XSS)

The application doesn’t validate or escape any input that users might put into the comments they make.
This makes it possible for the possible attacker to make a CSRF attack or input JavaScript
code into their comments to view e.g. the cookie data. 

Issue: A3 Cross-Site Scripting (XSS), show cookie data
Steps to reproduce:
1. Open the web application at http://localhost:8081
2. Create an account and log in
3. Write a comment like <SCRIPT>alert(document.cookie);</SCRIPT>
4. When the comment is submitted an alert window with the cookie data is shown

Steps to fix:
Thymeleaf escapes input by default, but the escaping can be easily added by changing the following line in the main.html

<span th:utext="${comment.username}">username</span> <span th:utext="${comment.comment}">999</span>

To

<span th:utext="${comment.username}">username</span> <span th:utext="${comment.comment}">999</span>

A4 - Insecure Direct Object References
Users can view their profile by navigating to http://localhost:8081/profile/username,
this is an insecure direct object reference, as the user profile is only meant for a certain user.
Within the user profile page it’s possible to delete the user’s comments, there is no verification
in the back end about who is clicking the delete button.

Issue: A4 - Insecure Direct Object References, view another user’s profile
Steps to reproduce:
1. Open the web application http://localhost:8081
2. Create an account named X and log in
3. Add a comment
4. Logout
5. Create another account and log in
6. Go to http://localhost:8081/profile/X
7. Delete the comment

Steps to fix:
Instead of having direct reference to the user in the URL, another way to do it would be to simply have the path
http://localhost:8081/profile/ which then would check the logged in user and populate the page with their data.

A8-Cross-Site Request Forgery (CSRF)
Because there are XSS flaws within the web application, it’s possible to conduct a very simple
cross-site request forgery. A way to do this is to use the delete account function with which 
a user’s account and comments can be deleted.

Issue: A8-Cross-Site Request Forgery, user profile deletion
Steps to reproduce:
1. Open the web application http://localhost:8081
2. Create an account and log in
3. Add the following comment: <a href="/delete">View my profile!</a>
4. Log out
5. Create another account and log in
6. Click on the “View my profile” link
7. The “You’ve deleted your account” page opens

Steps to fix:
Once again, simply fixing the input escaping would solve this particular issue.
Another way to do it would be to add another step to verify that the deletion of the
profile is actually what the user wants to do.

A9 - Using Components with Known Vulnerabilities
The web application is based on the Spring Boot Starter version 1.4.1.RELEASE 
which doesn’t have any known security issues. The application uses Tomcat version
8.0.21 which was released March 2015. Because of this outdated server,
there are multiple known vulnerabilities within the web application.

The list of the vulnerabilities can be found from the automatically
generated report dependency-check-report.html by the Maven Dependency check. The file is on the project root.

Issue: A9-Using Components with Known Vulnerabilities, outdated Tomcat version
Steps to reproduce:
1. On terminal navigate to the project root
2. Run the following command:
a. mvn dependency-check:check -X
3. View the automatically generated report at either /target/ or on the console

The dependency check should result in the following issues:
CVE-2016-0763, CVE-2016-0714, CVE-2016-0706, CVE-2015-5351, CVE-2015-5346 and much much more.

Steps to fix:
Remove the following line from the pom.xml:
<tomcat.version>8.0.21</tomcat.version>
Removing the line will result in the Tomcat version being defaulted to match the Spring Boot default.