COMP 20: Web Programming
Lab: Security and Privacy Assessment of Ride-Hailing Service
- Perform a security assessment of a potentially vulnerable system.
You have been hired as a security consultant to document and resolve the security and privacy issues of a ride-hailing service. The source code and
package.json files are provided to you:
Your goal is to find as many security and privacy problems as you can. You must find at least three (3) vulnerabilities in the system. You are also allowed to use tools such as Burp Suite and curl.
It is not necessary for you to use any of the tools listed above but a good idea nonetheless. The only deliverable for this portion of the assignment is a security assessment document in HTML5 format in your private GitHub repository:
security/index.html. Your document must have the following sections:
- Introduction - Provide a description of the product and what you were hired to do
- Methodology - Describe your methodology pen testing the system, including the tools that you used
- Abstract of Findings - Provide an overview of all the security and privacy issues you identified. This section should be written for non-technical managers who do not have technical expertise and do not have time to read the entire document. Write this section using lay language.
- Issues Found - For each issue that you find, document:
- Issue (e.g., database injection, really bad programming practice)
- Location / page where issue was found
- Severity of issue (e.g., low, medium , or high). Justify your answer.
- Description of issue. How did you find it? A screenshot of problem is excellent.
- Proof of vulnerability. Screenshots are important.
- Resolution. Make recommendation(s) on how issue can be resolved. Show code if possible.
- Conclusion - You can also list future considerations and recommendations with costs.
A live version of
server-vuln.js is now running and is available at https://hans-moleman.herokuapp.com/. Happy hacking!
- You can identify multiple instances of a security and privacy issue in your document (i.e., it will count as two issues). Example: Cross-Site Scripting (XSS) on two different sections of the system.
- It is important that you read the source code
README file that describes the work. This description must:
- Identify what aspects of the work have been correctly implemented and what have not.
- Identify anyone with whom you have collaborated or discussed the assignment.
- Say approximately how many hours you have spent completing the assignment.
- Be written in either text format (thus
README.txt) or in Markdown (thus
README.md). No other formats will be accepted.
This lab is worth 10 points. I will be assessing your document based on its breadth and depth:
- (1 point) - Introduction
- (1 point) - Methodology
- (2 points) - Abstract of findings
- (3 points) - Issues found and technical analysis of issues found
- (1 point) - Conclusion
- (1 point) - Grammar, spelling, style (e.g., must be in HTML format)
- (1 point) -
README document exists; report is named
index.html in folder named
security in your private GitHub repository under the
Submitting the Lab
Push all your changes to the private repository in GitHub that I created for you in a folder named
security under the
master branch. Say that your private repository in GitHub is named
comp20-mchow, make sure all the files are pushed to
Frequently Asked Questions
Q: Are we supposed to read the source code in order to make our attacks on the site we are attacking? Or should we try to do it without going through the source code?
A: Two step process:
- First, perform attacks WITHOUT reading the source code. This is also known as "black box" testing.
- Then, perform a manual code review of it, and document for your findings. If you find anything glaring, then go back and attack it. This is also known as "white box" testing. For example, after you read the source code and you are suspicious that you can perform a Cross-Site Scripting attack, go ahead an try it out.
Q: Is it necessary to use all the programs listed above?
Q: I'm using a scanning tool and it returned a number of possible vulnerabilities. Does it mean that the vulnerabilities actually exist?
A: It could also be a false positive. You have to check in the database, if it went through. That is, your job is to validate the finding(s).