IT360 Lab 11 Database Security


DUE: April 11, 2013, before 1159 (paper copy due BEFORE start of lab next day)


This lab is a collection of database security concepts.  You will see how to give others access to your data, ensure that passwords are encrypted, and use session variables for secure access to your web site.  Open a document and call it yourlastname_yourfirstname_Lab11.txt.  You will place all your answers to the lab questions in this document. 




Part 1 Database Security: Granting Privileges


As a database user, you currently have a username (mxxxxxx), password, and you have the rights (permissions) to a particular database (mxxxxxx) where you can create tables, insert into them, etc. Assume now that you are a database administrator, and you are the one giving permissions to users to use the database. For security reasons, you should restrict access to your database as much as possible, and only give permissions that are really needed in order to accomplish the task. We'll accomplish this through the use of the SQL GRANT statement.

GRANT <permissions>
[ON <table(s)>]
TO <user>


For example, GRANT INSERT ON mydatabase.AppUsers to mxxxxxx; , will allow the user mxxxxxx to insert data into the AppUsers table in the database called mydatabase.


Now, let's take a closer look at the GRANT statement line-by-line. The first line, GRANT <permissions>, allows us to specify the specific permissions we are granting. These can be either table-level permissions (such as SELECT, INSERT, UPDATE and DELETE) or database permissions (such as CREATE TABLE, DROP TABLE, ALTER DATABASE, GRANT, etc). More than one permissions can be granted in a single GRANT statement, but table-level permissions and database-level permissions may not be combined in a single statement.

The second line, ON <table>, is used to specify the affected table for table-level permissions. Use the format databaseName.tableName(s). This line is omitted if we are granting database-level permissions.


The third line specifies the user that is being granted permissions.

For this part of the lab, you will need a partner. Please work with a colleague to accomplish and test the tasks below. Write all answers to yourlastname_yourfirstname_Lab11.txt


1.     Ask your partner to connect to cardhu using MySQL Workbench and then select all songs from your songs11 table: SELECT * FROM mxxxxxx.songs11; where xxxxxx is your alpha. What is the answer?


2.     Write a GRANT statement to grant SELECT privileges on your songs table to your partner (use the GRANT syntax given above).


3.     Ask your partner to run again the SELECT * FROM mxxxxxx.songs11; where xxxxxx is your alpha. What is the answer this time? If your partner gets the same answer as before, try to logout and log back in to MySQL Workbench.


4.     What happens when your partner tries to INSERT a new song into your database by using the following statement: INSERT INTO mxxxxxx.songs11(Title, Artist) VALUES('Your Favorite Song', 'Your Favorite Artist')? Why?


5.     Now that you saw how you can grant privileges using the GRANT command, revoke the privileges that you granted to your partner: REVOKE SELECT ON mxxxxxx.songs FROM myyyyyy; where yyyyyy is your partner's alpha.



Part 2 Application Security: Protecting Passwords


I have provided a basic userPage.php and in the zip file downloaded from the course calendar. The userPage.php is a basic login page. We will add to that functionality next.


SHA Hashing: 


  1. Modify userPage.php downloaded from the course calendar to add and process an “add user” button. When clicked, the “addUser” function in should be invoked with the appropriate parameters (similar with the add product in Lab 9).


Test your add user button by inserting a few users. Check that users were indeed inserted by using the MySQL Workbench, SELECT * FROM users11;

  1. Add a line in addUser function in to hash the password received and insert the hashed password into the database, instead of the plain text password. To hash a password, you can use the PHP sha1 function. For example,


            $hashed = sha1("some string here");

returns the hashed version of the "some string here".  


Insert a new user by invoking userPage.php from a browser and check your MySQL database and see that the passwords are now hashed. 


8.     Now modify the “validate” function in to check against this new sha1 value. 


9.     How does the hashing change the response to a user’s question: I forgot my password, can you tell me what it is?



Part 3 Application Security: Session Variables

Remember the song website we started to create in class. With the new userPage.php in place, I would like to only allow valid users to access the songPage.php. The code currently in the userPage.php sets a session variable for the valid users and redirects them to songPage.php, so everything seems fine if users invoke userPage.php first. Only valid users should be able to see the list of songs, but try to access the songPage.php without logging in (without going to userPage.php first). 


  1. What happened?  Why?  Although you may not think that this is a big deal, what if it was a list of your accounts and account numbers instead of a bunch of songs? 


  1. Modify the file songPage.php to ensure that only valid users (ie. those who have logged in properly and have had the $_SESSION['name'] session variable set) will be able to see the page content.


Part 4 Application Security: SQL Injections


  1. a) Write a simple SQL Injection attack for any of the pages used for this lab. Anything that would change in any way the intended functionality of any of the pages is OK (ex. Get to display error messages that reveal the database schema, or display more information than intended).

b) What are the effects of your attack?


  1. How should the code be modified for the page that was attacked in order to prevent future attacks of the same type? (you do not have to actually modify the code, just say what needs to be done).


Extra credit: Real SQL Injections


  1. Search the web and give an example of a real world attack that used SQL injection. Provide a link to the article mentioning such attack.


Extra credit: Secure Sockets Layer: Many people use online banking.  Go to the homepage for Navy Federal Credit Union at  Note that the text boxes on the left are similar to the login screen that you used in this lab (userPage.php). Use any resource you would like and research how the server and client communicate during the session set up process for SSL (Chapter 18 in the “PHP and MySQL Web Development” book, your networks class, or discussion on SSL from IT350 might help). 


  1. Consider your knowledge of networking and Internet programming and describe what happens when you enter your login information in these text boxes and press the “Sign on” key. 


  1. What would be the address in the browser’s address bar to invoke your userPage.php using a secure connection (SSL)?


Finally: Make sure you incorporate these “best practices” into your project.  This means adding the appropriate test cases for SQL injects, checking session variables before page displays and saving all passwords as hashed values.  We will not be using SSL for this course, but in the real world, you would also make sure to use SSL for appropriate secure transactions (ie, logins and passing of account information).


Turn in (BOTH electronic and paper submissions are required):

Electronic (due before 2359 on April 11, 2013):

  1. Upload yourlastname_yourfirstname_Lab11.txt with all your answers, and your version of the files userPage.php,, and songPage.php to the Lab 11 assignment on the Blackboard.


Hard-copies (due before start of lab on April 12, 2013):

  1. The completed assignment coversheet. Your comments will help us improve the course.
  2. A hard copy of your yourlastname_yourfirstname_Lab11.txt containing the answers for each exercise, and hard copies for your modifications in userPage.php,, and songPage.php