CS5331 Submission

.gitignore

@@ -0,0 +1,2 @@
+venv/
+*.pyc

Dockerfile

@@ -5,6 +5,8 @@ RUN apt-get install -y apache2
 RUN pip install -U pip
 RUN pip install -U flask
 RUN pip install -U flask-cors
+RUN pip install flask-sqlalchemy
+ENV FLASK_APP app.py
 RUN echo "ServerName localhost  " >> /etc/apache2/apache2.conf
 RUN echo "$user     hard    nproc       20" >> /etc/security/limits.conf
 ADD ./src/service /service

README.md

@@ -49,7 +49,6 @@ sudo docker run hello-world
 
 sudo ./run.sh
 ```
-
 (Docker CE installation instructions are from this
 [link](https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository).)
 
@@ -84,60 +83,118 @@ If a response is received, you're good to go.
 **Please replace the details below with information relevant to your team.**
 
 ## Screenshots
-
-Please replace the example screenshots with screenshots of your completed
-project. Feel free to include more than one.
-
-![Sample Screenshot](./img/samplescreenshot.png)
+### Login
+![Login](./img/login.png)
+### Register
+![Register](./img/register.png)
+### Public entries
+![Public entries](./img/publicposts.png)
+### Authenticated user's entries with delete and change permissions
+![My entries](./img/myposts.png)
+### Create entry
+![Create](./img/create.png)
 
 ## Administration and Evaluation
 
-Please fill out this section with details relevant to your team.
-
 ### Team Members
 
-1. Member 1 Name
-2. Member 2 Name
-3. Member 3 Name
-4. Member 4 Name
+1. Chai Ming Xuan
+2. Tan Yi Yan
+3. Tan Wee Chen William
 
 ### Short Answer Questions
 
 #### Question 1: Briefly describe the web technology stack used in your implementation.
 
-Answer: Please replace this sentence with your answer.
+Answer:
+
+On the backend, we used the Flask microframework for the web application,  SQLite as the database and Flask-SQLAlchemy as the database ORM.
+
+As for the frontend, we mostly used basic HTML, Python Jinja2 for templating, Materialize CSS for styling, and JavaScript libraries such as jQuery and handlebars.
 
 #### Question 2: Are there any security considerations your team thought about?
 
-Answer: Please replace this sentence with your answer.
+Answer: 
+
+**Storing password hashes**
+Instead of storing the password of the the user in plaintext, we stored a hash of the password.
+
+**Protection against SQL injection**
+Our web application is not vulnerable to SQL injection attacks as we chose to use SQLAlchemy that provides automatic quoting of special characters such as semicolons and apostrophes. 
+
+**Protection against XSS**
+In addition, our web application is also not vulnerable to Cross Site Scritping (XSS) as we enabled Jinja2 to auto escape all values loaded in our web applications' pages.  
+
+**Protection against user enumeration**
+When a user submits a wrong username or password when logging in, the server gives a general authentication error message instead of specific messages. This prevents attackers from finding out if they have submitted a non-existent username or a wrong password. They cannot find out if a user exist or not through the login page.
+
+**CSRF** 
+A side-effect of not using HTTP Cookies for authentication is that the application is not vulnerable to traditional CSRF, since the session token is not automatically sent, unlike a cookie. We do acknowledge that storing the session token in Local Storage does not automatically make it any more secure than cookies, and comes with its own downsides.
 
 #### Question 3: Are there any improvements you would make to the API specification to improve the security of the web application?
 
-Answer: Please replace this sentence with your answer.
+Answer: 
+
+There are a few areas that we can improve on, such as 
+- Password strength
+- Expiring the password token
+- Salting the password
 
+**Password strength**
+There are curently no restrictions on the password length and complexity. A user can use an extremely weak password such as `password1` and still be allowed to register. 
+
+**Expiring tokens**
+Currently, the server does not expire a token unless it is explictly told to do so via the `/users/expire` API. This may not be ideal as any stolen token will be valid until a `/users/expire` request is sent. To mitigate the damages that can be caused by a stolen token, the server can expire a token automatically after a fixed period of time e.g. after 5 days. 
+
+**Salting the password**
+Passwords can be salted before they are hashed in order to defend against dictionary attacks.
+
 #### Question 4: Are there any additional features you would like to highlight?
 
-Answer: Please replace this sentence with your answer.
+Answer: 
+
+**Checking user authentication** 
+When an unauthenticated user tries to access pages that require authentication, they get redirected back to the login page. Similarly, when an authenticated user tries to access access the login and registration page, they get redirected to the public diary entries page.
 
 #### Question 5: Is your web application vulnerable? If yes, how and why? If not, what measures did you take to secure it?
 
-Answer: Please replace this sentence with your answer.
+Answer: 
+
+Yes. Our web application is vulnerable in the following ways: 
+- Brute-force attacks 
+- Spamming user registration 
+- Unencrypted traffic in HTTP  
+- Token stored in plaintext
+
+**Brute-force attacks**
+Attackers can send as many requests as they want to the server, and the number of requests per unit time is not limited. If they know the username of a user, they can make as many password attempts as they want to the server. This is because we have not implemented a feature to throttle requests to a server.
+
+**Spamming user registration**
+Attackers can use bots to spam user registrations and fill our database with fake users. This is because we did not implement any mechanisms to verify whether the user is a human or not, such as CAPTCHA. 
+
+**Unencrypted traffic in HTTP**
+The web application is served on the HTTP protocol that does not provide confidentiality and integrity. Since all HTTP traffic is unencrypted, a network attacker is able to sniff sensitive data such as passwords and session tokens because all data is sent in the clear. In addition, since there are no integrity checks in HTTP, an attacker can easily modifiy the data sent between the server and the client. 
+
+**Token stored in plaintext**
+In the event that the database gets compromised, the attacker will have access to all the tokens stored in the database. Having access to the tokens is equivalent to getting the login credentials of a user. Storing the hash of a password becomes pointless. By hashing the tokens, the attacker will not be able to log into any user's account using the hash of their token.
 
 #### Feedback: Is there any other feedback you would like to give?
 
-Answer: Please replace this sentence with your answer.
+Answer: 
+- It was good to have the freedom of choice for our tech stack. 
+- It was challenging to use Docker. 
+- API specification was very clear. 
 
 ### Declaration
 
 #### Please declare your individual contributions to the assignment:
 
-1. Member 1 Name
-    - Integrated feature x into component y
-    - Implemented z
-2. Member 2 Name
+1. Chai Ming Xuan
+    - Implemented the Users and some of the Diary APIs
+    - Wrote the front-end code
+2. Tan Yi Yan
+    - Implemented some of the Diary API 
+    - Wrote the front-end code
+3. Tan Wee Chen William
+    - Setup the database and designed all its schema 
     - Wrote the front-end code
-3. Member 3 Name
-    - Designed the database schema
-4. Member 4 Name
-    - Implemented x
-

run.sh

@@ -1,12 +1,17 @@
 #!/bin/bash
 
 if [ "$EUID" -ne 0 ]
-  then echo "Please run as root"
-  exit
+    then echo "Please run as root"
+    exit
 fi
 
-TEAMID=`md5sum README.md | cut -d' ' -f 1`
+cp -R -u -p test.db /tmp/test.db
+
+# Tears down any running containers
 docker kill $(docker ps -q)
 docker rm $(docker ps -a -q)
+
+# Builds web application image and runs webapp container
+TEAMID=`md5sum README.md | cut -d' ' -f 1`
 docker build . -t $TEAMID
-docker run -p 80:80 -p 8080:8080 -t $TEAMID
+docker run -v /tmp/test.db:/tmp/test.db -p 80:80 -p 8080:8080 -t $TEAMID