CS 651 Spring 2020 Homework 9

HTTP, Requests, and Servers

Dr. Greg M. Bernstein

Due Monday, April 20th, 2020 by 11:59PM, 50 points.

General Instructions

Security, Cookies, Sessions, and Protecting Interfaces

Create and Use a new Branch hw9

We will create a new git branch called hw9 for use in this assignment. The branch you create must exactly match the one I’ve given you for you to receive any credit for this homework.

Prior to creating this new branch make sure your working directory is “clean”, i.e., consistent with the last commit you did when you turned in homework 8. Follow the procedures in GitHub for Classroom Use to create the new branch, i.e., git checkout -b hw8. Review the section on submission for using push with a new branch.

Use README.md for Answers

You will modify the README.md file to contain the answers to this homework.


Question 1. (10 pts) Securing User Passwords

For this question you will need the mock user data I generated: clubUsers2.json. Put all work in your clubServer directory.

(a) Hash user passwords

To emulate server side storage of user information including passwords, write a Node.js program that reads in the clubUsers data from JSON, hashes the password field with bcrypt, and saves the data to a new file clubUsersHash.json.

Hint you can use the following code to get you started if you like.

Show your code here along with a couple of entries from the clubUsersHash.json file.

(b) bcrypt work

By changing the “rounds” parameter to bcrypt we can make it harder (in terms of computation) to compute the password hash and thus increase our defenses a bit. Using the program from part (a) increase the number rounds (default is 10) parameter to bcrypt until it takes at least 15 seconds to run. Take a screen shot of the timing results. I get something like:

bcryptjs timing for 40 users
bcryptjs timing for 40 users

Question 2. (10pts) Basic Login Interface and Test

Now we are going to start adding login capabilities to the “Club Server” from homework #8. Read in the clubUsersHash.json (or whatever you called the file in problem 1) file to act as a “database” of users. Your server must not use the JSON file with the un-hashed passwords!!!!!

(a) Login interface and handler

Add a server API with path /login and method POST to your clubServer.js code. This API receives a JSON message of the form: {"email": "user@email.com", "password": "Not123456!!!"}

If the email and hash of the password correctly you will return the user information (not including password hash) in JSON format. If either the password is incorrect or the user is not in the “user database” your will respond with the code “401” and a JSON message of the form: {"error": true, "message": "User/Password error" }

After you have finished testing this API in part (b) put the code for just this addition to your server here.

(b) Test Login Interface

Create a Node.js program file called loginTest.js within your tourServer directory. Have it perform the following login tests in order. Pick any user from the usersTour.json file to test with.

  1. Good email, good password

  2. Bad email (user not found)

  3. Good email, incorrect password

Show your test code here and a screen shot of the output. I get something like:

Test results screenshot
Test results screenshot

Question 3. (15 pts) Sessions/Login

(a) Add express-session to your clubServer

Modify the SessionID cookie name to have it start with your NetID, and also modify cookie signing secret. Create session state initialization middleware code with initial session state session.user = {role: "guest"}. Hints: see course slides, don’t forget express-session installation. Show additional code you added to your server for sessions here.

(b) Test Session Cookies

To verify that sessions are working visit your site and take a screenshot when you visit the /activities path showing the cookie the session middleware sent to the browser. My screenshot looks like:

Screenshot with cookie
Screenshot with cookie

(c) Update login POST route

Update the login POST rout to use the session functionality (generate new session Id on change of role). Show your updated login code here.

(d) Create a logout GET path

As in the course slides.

(e) Testing login, logout, and cookies

To test our login interface along with session functionality we need to be able to store cookies in between “request” calls, see request course slides for example code. Update your tests from problem 2 to include cookies as follows:

  1. Test 1: Good Login
    1. Visit your /activities interface, print out cookies
    2. Perform a good login via POST to /login, show result and cookies. Verify that your session ID cookie changed after login.
    3. Perform a logout via GET to /logout, show result and cookie?
  2. Test 2: Bad Email
    1. Visit your /activities interface, print out cookies
    2. Try to login with a bad email show result and cookies Did the cookie change?
  3. Test 3: Bad Password
    1. Visit your /activities interface, print out cookies
    2. Try to login with a good email and bad password, show result and cookies Did the cookie change?

Show your updated testing code here and take a screenshot of you test output at the console. My screenshot looks like:

Login test output
Login test output

Question 4. (10 pts) Protect Add Activity Interface

(a) Create and Insert Protection Middleware

Create middleware that checks for the “admin” role and if it doesn’t find it returns a “Forbidden” code and JSON error message. Add that middleware to the POST handler for adding tours. Show the code for that middleware here.

(b) Testing Protected Interface

Create/update your add activity test file and conduct the following tests:

  1. Test 1: Admin Login, Add Activity
    1. Login as admin user, show result and cookies
    2. Check the number of activities
    3. Add a activity, show number of activities and cookies
    4. Logout
  2. Test 2: Member Login, Try to Add activity
    1. Login as a member, show result and cookies
    2. Check the number of activities
    3. Try to add a activity, show result and cookies
    4. Logout
  3. Test 3: Guest User, Try to Add activity
    1. Check the number of activities
    2. Without logging in, try to add a activity, show result and cookies.

Show your test code here and a screenshot of its output. My screenshot looks like:

Protected interface tests
Protected interface tests

Question 5. (5 pts) Protected Get Users Interface

(a) Create /users Interface

Create a GET interface to return information about all the users, but not their password hashes. Only “admins” should be able to use this interface. Show code for just this interface here.

(b) Test Protected /users Interface

In a new test file, getUsersTest.js test the protected get users interface in a manner similar to that of Problem 4(b), i.e., the protected “add activity interface” of Problem 4 tests. Show a screenshot of your tests, mine looks like:

Protected user interface tests
Protected user interface tests