Switch branches/tags
Nothing to show
Find file History
Latest commit b401e51 May 7, 2018
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
public Adds P6 May 3, 2018
views Adds P6 May 3, 2018
.submit Adds .submit file May 3, 2018
Gemfile Adds P6 May 3, 2018
README.md Adds P6 May 3, 2018
controller.rb Adds P6 May 3, 2018
data.db Adds P6 May 3, 2018
main.rb Avatar fix May 7, 2018
pack_submission.sh Adds P6 May 3, 2018
submit.jar Adds P6 May 3, 2018
submit.rb Adds P6 May 3, 2018

README.md

Project 6: Introduction to Cybersecurity

CMSC 330, Spring 2018 (Due May 9, 2018)

Ground Rules

This is an individual assignment. You must work on this project alone.

Introduction

Congratulations! You've just been hired by EPSILON a social media startup that looks suspiciously like Twitter. Through some miracle, the founders have managed dupe investors into funding the company. Using the site, it becomes abundantly clear that there are massive security issues. Since this is a startup, of course they can't afford to hire an expert in cybersecurity. You're a novice, but it's your job now!

Running the Project

Locally

  • Run bundle install in the project root directory. If you get a permissions error run with sudo.
  • Run ruby main.rb (or ruby main.rb -o $IP on Cloud9).
  • Open http://localhost:8080/ (or to your workspace-specific URL on Cloud9). You should see the site.

Remember to restart main.rb after changing controller.rb. Otherwise, changes won't show up. Depending on your local configuration you may have to do some of the following:

  • If you don't have bundler, use gem install bundler (on Bash for Windows 10 you need to specify the full path when you call bundle which can be found with gem which bundler).
  • If you don't have SQLite3, use sudo apt-get install sqlite3.
  • If you're getting an issue where Ruby headers cannot be found run sudo apt-get install ruby-dev.
  • If you're getting an issue where sqlite.h is missing run sudo apt-get install libsqlite3-dev.
  • If bundler can't continue when installing SQLite3 and you're using macOS, upgrade your version of Ruby (we recommend using RVM).
  • If bundler can't continue when installing SQLite3 and you're using Linux, try sudo apt-get install build-essential patch followed by sudo apt-get install ruby-dev zlib1g-dev liblzma-dev.

Grace

If you're using macOS, run the project locally. Grace won't work.

  • Log into Grace using ssh -Y <username>@grace.umd.edu.
  • Run bundle install --path ~/.gem in the project root directory.
  • Run chrome &. You will be able to access the site from this browser window. (If Chrome is giving a core dump, try the following: open the file ~/.cshrc.mine, comment out limit maxproc 20 by putting a # in front of the line, save the file, logout and log back in.)
  • To run the web server, run ruby main.rb. You'll notice in the output that "Sinatra has taken stage on PORT_NUMBER_HERE".
  • Take that port number and direct the Chrome window to http://localhost:PORT_NUMBER_HERE/.

Remember to restart main.rb after changing controller.rb. Otherwise, changes won't show up.

Files

There is only one source code file that you will need to make changes to: controller.rb. This file contains the core back-end logic and it is also where the web application's vulnerabilities may be found and fixed. You will also be required to interact with and modify the database (which is stored in data.db), but you will do this through the database's top-level sqlite3.

  • Ruby file (you should edit)
    • controller.rb: All your modifications should be made to this file.
  • Database file (you will edit via the SQLite top-level)
    • data.db: The database is housed in this file.
  • Provided files (no need to edit, changes will be overwritten!)
    • public/: This directory contains all the resources the front-end needs to run.
    • views/: This directory contains all the HTML files.
    • main.rb: This is the driver file that runs the web server.
    • Gemfile: This file contains a list of project dependencies (the server, the database, etc.). These all happen to be Ruby "gems," and bundling them into a "Gemfile" allows us to install them all at once by simply running the command bundle install in the same directory.
  • Submission Scripts and Other Files
    • submit.rb: Execute this script to submit your project to the submit server.
    • submit.jar and .submit: Don't worry about these files, but make sure you have them.
    • pack_submission.sh: Execute this script to zip your project for web submission.

Part 0: Preliminaries

The application is separated into three components:

  • The front-end which consists of all the HTML and CSS required for rendering the page. You won't have to worry about this at all.
  • The back-end which handles all HTTP requests. You will mainly be working on this component.
  • The database which persistently stores information. You will also makes some modifications to this.

When a user requests a page (HTTP GET), main.rb will display the appropriate page and request all necessary data from controller.rb. When a user submits a form (HTTP POST), methods in controller.rb will be invoked to modify the database.

This project's back-end (written in Ruby in the file controller.rb) is vulnerable to exploitation. Your job is to identify and fix as many of the vulnerabilities as possible. Identifying these issues will require recalling some of the vulnerabilities discussed in class, as well as using your own common sense. This will require playing with the site, thinking like an attacker, and trying as hard as possible to break things. Of course, you're also expected to fix the issues once you've found them.

The only code you will be modifying is in controller.rb. If you're interested in how the application works, you may check out main.rb, but this is not necessary. You will also be modifying data.db through the sqlite3 top-level.

Part 1: Password Hashing

Keeping passwords safe is critical for any application. Unfortunately, our application stores passwords in plaintext. You must rectify this.

  1. Use the sqlite3 top-level to augment the "Users" table in data.db with a column named "Salt".
  2. Modify the application to utilize hashing and salting. You must store the hash in the password column, using the Digest::SHA256.hexdigest function, computing your hashes by concatenating the plaintext password and salt together (in that order).
  3. Migrate your existing users so their passwords are secure too.

Below are some useful SQL commands. You can see this SQL cheatsheet for more commands.

  • SELECT * FROM table;
    • Description: Returns all records in a table.
    • Example: SELECT * FROM Users;
  • ALTER TABLE table ADD COLUMN column type options;
    • Description: Adds a column to a table.
    • Example: ALTER TABLE Students ADD COLUMN Hometown varchar(20);
  • UPDATE table SET column1 = value1, column2 = value2, ... columnk = valuek [WHERE condition(s)];
    • Description: Updates data in a table.
    • Example: UPDATE Students SET LastName = 'Jones' WHERE StudentID = 987654321;

Part 2: Patching Exploits

In the real world, no one will tell you what vulnerabilities are present in your application. So neither will we. However, here is some advice:

  1. Play with the site. Spend a good bit of time just interacting with it and understanding the pages and how it works.
  2. Walk through the code. Since we've written most of the application you need to understand what's already there. Make sure you understand all the methods in controller.rb and how they fit within the site. The inline documentation should help with this.
  3. Try breaking things. Wreak havoc! Be destructive! You will find some rather obvious issues, but also some more subtle ones. Remember the types of exploits discussed in class and discussion. Make note of your findings. Your knowledge of controller.rb should be helpful in finding possible exploits.
  4. Start fixing. Enough said.

Here is an index of the vulnerabilities we've learned about either in class or discussion. This is not meant to be exhaustive, nor does it mean that all of these exploits are relevant to this project. It's just to refresh your memory.

Project Submission and Grading

This project will be graded out of 100 points.

  • Semi-public Tests (20 points). You can submit as many times as you want, but are not provided with the test cases.
  • Release tests (80 points). Instead of the usual 3, you will be given 5 tokens which regenerate daily.

You can submit your project in two ways:

  • Submit your files directly to the submit server as a zip file by clicking on the submit link in the column "web submission". Where to find the web submission link Then, use the submit dialog to submit your zip file containing all of your source files directly. Where to upload the file Select your file using the "Browse" button, then press the "Submit project!" button. You will need to put it in a zip file since there are several component files. We provide a script pack_submission.sh which you can run to make a zip file containing all of the necessary files.
  • Submit directly by executing a the submission script on a computer with Java and network access. Included in this project are the submission scripts and related files listed under Project Files. These files should be in the directory containing your project. From there you can either execute submit.rb or run the command java -jar submit.jar directly (this is all submit.rb does).

No matter how you choose to submit your project, make sure that your submission is received by checking the submit server after submitting.

Academic Integrity

Please carefully read the academic honesty section of the course syllabus. Any evidence of impermissible cooperation on projects, use of disallowed materials or resources, or unauthorized use of computer accounts, will be submitted to the Student Honor Council, which could result in an XF for the course, or suspension or expulsion from the University. Be sure you understand what you are and what you are not permitted to do in regards to academic integrity when it comes to project assignments. These policies apply to all students, and the Student Honor Council does not consider lack of knowledge of the policies to be a defense for violating them. Full information is found in the course syllabus, which you should review before starting.