For this exercise, you will be attempting to apply your knowledge of security holes in web applications. I'm counting this exercise for double-points because it might take longer, and because I think it's important.

1. Have a look at the extremely simple personal information manager (PIM) application that I have created. Accounts have been created with usernames “user1” through “user4”. In each case, the password is the same as the username.

   The system's functionality is essentially:

   • A user can create “contacts”. Each contact has a first name, last name, email address, phone number, and notes about them.
   • A user can select other users as “friends” and share his/her contact list with that person.
   • When that other person logs in, they can see all of that user's contacts.

   It's not exactly advanced, but it will do.

2. I originally created a system that I thought was reasonably secure, but then went back and introduced several security holes. Your task for this homework is to find any security holes in the system. [See the notes and hints below.]

3. In and email, document each security hole you find. That is, indicate what the problem is (where it can be found, how to trigger it, etc), the type of security hole, and the impact of the flaw. It shouldn't take more than a sentence or two to describe each one: don't write an essay.

4. Send your results in an email to zju.webdev@gmail.com with the subject “Homework #5 & 6”. Be sure to include your student number in the body of the email.

Hints

Here is the general list of security holes I know about:

• 1 × XSS possibility
• 2 × insufficient authentication/permissions not checked/inappropriately trusted input
• 1 × SQL injection (which I know theoretically is there, but haven't been able to exploit myself)
• 2 × CSRF possible
• 1 × other inappropriately-trusted input
• 1 × other general deficiency

You certainly don't have to find all of these to get full marks for the homework: do your best to explore the system, and revisit after I post the solutions.

Notes

• The database for the system is reset to its initial state every hour, on the hour. So, you can add and delete information without worrying about causing permanent damage. But, please remember that others are using the system, and be nice with the information you add/delete. Also, try not to give things away to somebody else exploring the system.
• The hourly database refresh will log everybody out of the system.
• If you stumble across a security hole that can cause serious damage, be polite and just document it without leaving the system unusable for others. Any damage you can cause should be repaired along with the hourly database reset.
• Please, no denial-of-service attacks, brute-forcing, or anything else that will make the SFU tech staff yell at me.