1 Purpose

The purpose of this assignment is to allow you to demonstrate that you have acquired the knowledge and skills necessary to design and construct secure "WWW apps".

2 Part 0

For Part 0 you must find or create a high-quality list of concerns that is appropriate for a code inspection of this project. Your checklist must include vulnerabilities that might lead to confidentiality, integrity, and availability attacks at an appropriate level of detail for a formal inspection. (Note: The fact that a checklist has been published/posted does not, in and of itself, make it high-quality. You are responsible for ensuring the quality.)

Though you will not be submitting your list of concerns until you use it to complet Part 2, you will be well-served to complete it before you start working on Part 1 (so that you can use it to ensure that your implementation is secure).

3 Part 1

For Part 1 you must design and construct a "WWW app" named WellAppointed, a simple appointment reservation system. The following documents exist describing WellAppointed.

In addition, your implementation must satisfy the following course-related requirements:

1. The structure of the GUI must be written in HTML.
2. The form/presentation/layout of the GUI must be written in CSS.
3. Code for client-side processing must be written in JavaScript.
4. Code for server-side processing must be written in PHP.
5. The completed system must be deployed on stu and must be in a directory named wwwproject (under your www directory). You may use subdirectories.
6. The system must have a "landing page" named index.html (written in HTML) that contains information about how to use the system (and any links that you think would be convenient).
7. The system must have some form of authentication, but it can be rudimentary (e.g., the password is always the username in reverse). In a real deployment, the system would use JMU's authentication system but you must not do so (or attempt to do so) for this assignment.
8. You may maintain session state across multiple page requests if you want, but it is not necessary. Your implementation may require authentication for each page request.
9. You must use "normal" file I/O (in PHP) on the server, not a database management system.
10. You must write all of the code yourself. You must not use any existing frameworks or libraries. (While this will not result in the most secure code possible, it will help you learn the material. Also, it will ensure that any vulnerabilities in the product were introduced by you.)

4 Part 2

For Part 2 you must "critique" the implementation of another student. That is, you must conduct a code review and write a report that documents any concerns that you have (using the list of concerns you created for Part 0). If the code includes vulnerabilities your report should, if possible, include a demonstration exploit.

Since you faced some constraints in Part 1, some aspects of the system are "out of bounds" (i.e., should not be considered during the review).

1. Your review must not consider the authentication "algorithm" but may consider other aspects of the authentication process (e.g., transmitting usernames and passwords in the query string of a URL).
2. Your review must not consider the requirement that the system use the file system and not a database management system. It may, however, consider the way the file system is used.
3. Your review must not consider the "visual aesthetics" of the system. It may, however, consider interaction issues that are directly related to security.

5 Hints

You may want to consider the following before you start working on Part 1.

1. Remember, you should think of stu as the production environment, not the development environment. If you are not already doing so, you should use the HTTP server that is included with PHP for development and early testing.
2. If you are not already doing so, you should start using appropriate tools (see the course "Tools" page). Most importantly, you should start using a debugger (both Chrome and Firefox have a built in debugger, and Firebug is available as an add-on).
3. Your PHP scripts have write access to a directory with your eID that is located under /scratch (e.g., /scratch/bernstdh). Note that, when executing, your PHP scripts are not running under your username (since they are running inside of the HTTP server).

   To make this directory seem to be under your www directory, you may want to create a softlink to it. For example:

   # Create a softlink that points to the scratch location on w3stu. 
   # (Note: This link will appear broken on any other machine.)
   ln -s /scratch/bernstdh /cs/www/stu/bernstdh/projectdata
   

   Then, you can use your browser to see what's in that directory and/or curl to GET files in that directory. For example, to use curl to get the file named appointments.txt:

   # Use curl to GET the file named appointments.txt
   curl http://w3stu.cs.jmu.edu/bernstdh/projectdata/appointments.txt
   

   You can also easily write (or borrow -- there are many on the WWW) a PHP program that will allow you to upload files to that folder (e.g., to /scratch/bernstdh).

   I would like you to be able to get your code working on stu, so I would like you to be able to figure this out. However, if you can get your code working on your own "server" but not on stu it's not a big problem.

4. HTTP has a Basic Authentication (BA) mechanism (using headers) that is supported by most WWW browsers and servers. When the following page is loaded by a WWW browser the user will be prompted to enter a username and password.

   <html>
   <body>
   <?php
   $ok = false;
   
   $user      = $_SERVER['PHP_AUTH_USER'];
   $password  = $_SERVER['PHP_AUTH_PW'];
   if (isset($user) && isset($password) && ($password === "secret")) $ok = true;
   
   
   if ($ok)
   {
     // The contents of the page that the user will see if she/he
     // is authenticated.
     print("<p>Authenticated.</p>");
   
     $_SERVER['PHP_AUTH_USER'] = null;
     $_SERVER['PHP_AUTH_PW']   = null;
   }
   else
   {
     header('WWW-Authenticate: Basic realm="Registered Users"');
     header('HTTP/1.0 401 Unauthorized');
   
     // The contents of the page that the user will see if she/he
     // cancels the authetication process.
     print("<p>You clicked [Cancel] when asked for your password.</p>");
     exit;
   }
   ?>
   </body>
   </html>
   

   The browser will then cache the credentials (for an indeterminate amount of time).

5. You may use any process you want, but I would suggest working on one feature at a time. In other words, get one feature working in a secure fashion before moving onto another. I'd suggest starting with the features required for "View Schedule". Then, I'd move on to "Cancel Reservation" because it requires interaction, but of the simplest kind. Next, I'd work on "Reserve Block" and finally I'd work on "Edit Schedule". (This is probably a good idea from a grading perspective as well. It will be better to have a secure and defect-free product with limited functionality than to have an insecure and defect-laden product with more functionality.)
6. You should implement schedule-locking only after everything else is working. A simple way to lock a schedule is to create a specially-named file (e.g., monday.lock) when the file is locked and delete that file when it is unlocked. The biggest shortcoming of this approach is that a user might leave a page before the schedule she/he was using was unlocked. You may want to use a JavaScript unload handler to remedy this.
7. Students must be able to format the purpose of the reservation, but your system does not have to support complicated formatting. It must support bold, italics, and code; it need not support the ability to apply multiple formats to the same word/words (e.g., bold and italic).
8. Your implementation may be something that you want to include in your "portfolio" and show to other people. Nonetheless, you should not spend too much time on "visual aesthetics" until after everything else is complete.

You may want to consider the following before you start working on Part 2.

1. As a reviewer, your job is to identify concerns, if they exist, even though the code was written by another student (with whom you might be friendly). Remember that reviewers will be anonymous and that the quality of your review will be assessed and be a factor in your grade.
2. Note that this project is intentionally long, in part so that you would are forced to deal with the real-world conundrum of trading-off security for features (or vice versa). With that in mind, during your review, you should look for situations in which the designer/programmer got "sloppy" because they were facing time pressure. For example, look for situations in which the implementation in one part of the system is secure but in another, very similar part of the system, they were not. In other words, don't assume that because the "right" decision was made in one location it was made everywhere.

6 Submission

For Part 1, you must have a working version of the code on stu. In addition, you must have a file named part1.zip in the wwwproject directory (under the www directory) on stu that contains all of your files/directories so that the students conducting reviews have access to everything that they need.

For Part 2, you must submit the results of the code review that you performed. It must be in a PDF file named eid.pdf (where eid is the JMU electronic ID of the student who wrote the code). Do not include any information that would identify you as the reviewer. (In other words, reviewers are to remain anonymous.)

7 Visibility

Your deliverables will be public (i.e., available to both other students in the course and the general population).