CS 142: Web Applications (Winter 2014)

CS142 Project #8: Ajax and SQL Injection Attack

Problem 1: Photo Searching With Ajax (30 points)

In this project you will extend your work on Project #7 by implementing a search mechanism for photos. Here is a rough description of the new feature:

• The main page ( /users/index ) should contain an entry where users can type a search string.
• As users type in text, thumbnail-size versions of all matching photos should be displayed under the text entry. Use Ajax to update this display automatically whenever the search string changes.
• Thumbnails should be "hot": if the user clicks on one, switch to the page for that photo's user (/photos/index). If the user has a large photo collection, make sure that the selected photo is visible.
• A photo matches the search string if (a) the text of the search string is a substring of any comment on that photo or (b) the search string is a substring of either the first or last name of any user tagged in the photo. Your comparisons should be case insensitive (a search string of "bARa" matches "Barack").

To get started, create a new directory project8, and copy the directory tree from project7 to a new subdirectory named project8/p1. Do all of your work for this project in the new directory.

The remaining details of the design and implementation are up to you, except for the following requirements:

• You may not use jQuery or any other libraries to implement Ajax support in the browser; you must write Javascript code that creates XMLHttpPRequest objects and responds to their events (we want you to learn about the low-level details of Ajax).
• In order to receive full credit for this project, your implementation must include a reusable Ajax mechanism that could potentially be used for other purposes, not just a special-purpose implementation that works only in this one situation. It is up to you to decide on the form this mechanism should take. Create a file README in the project8/p1 directory that describes which part(s) of your solution are reusable; give an example or two of other situations in which it might be used.
• As always, your Web pages should designed so that they are reasonably attractive and easy to use.

Hints for Problem 1

• Use the GET method for your Ajax requests, not POST. If you use POST, then Rails will require an authenticity token in the request (to prevent CSRF attacks just as for form posts) and will reject any Ajax requests that don't include the token.
• You may find the Javascript method encodeURIComponent useful: this method will perform URL encoding on the name or value for a query value.

Problem 2: Injection Attack (25 points)

Netslip, the high-flying new entrant in the Internet DVD rental business, was rapidly taking market share from NetFlix when it was struck by an SQL injection attack. A band of Internet criminals from South Hackland extracted details of more than 200,000 credit cards from the Netslip database, resulting in thousands of identity thefts and millions of dollars in fraudulent purchases. Faced with a class-action lawsuit and (even worse) bad publicity, Netslip was forced to shut down.

Fortunately, we were able to obtain a few fragments of the original Netslip Web site for this project. Download netslip.zip and extract its contents into a directory named netslip. This directory contains a Rails-based application that you can run in the usual Rails fashion (you may need to invoke "bundle update" to install Ruby Gems needed by the application). Start up the application and go to the URL http://localhost:3000/movies/selectGenre. From this URL you can explore the remains of the Netslip Web site. It may also be useful to look through the Rails code that implements the site. The site contains several features designed to thwart attacks, but unfortunately it also contains a gaping loophole. Your first task is to identify that loophole.

Once you have identified the loophole, create a new directory project8/p2 and write a Ruby program cardInfo.rb in that directory that exploits the loophole to extract credit card information from the site. Your program should connect to the site via HTTP, extract the data using normal HTTP requests, and print out the following information for each credit card stored in the database:

• The name of the cardholder.
• The credit card number.
• The expiration date (month and year).
• The three-digit security code.

You should print the above information in a legible form, with labels; dumping the raw HTML to the output is not sufficient. You should not make any modifications to the Web site while creating your attack. We will test your solution with a "clean" server: we will stop the server and invoke

rake db:migrate:reset

to clear and reload the database (which will also clear any existing sessions). Then we will restart the server and invoke the following command:

ruby cardInfo.rb

You may find the following information useful when writing your program:

• A Ruby statement like the following can be used to open a connection to the server:

  require 'socket'
  ...
  s = TCPSocket.open(host, port)

  In this example host is a string containing the host name and port is the desired port number. The require line must be at the top of your Ruby file.
• Once the socket has been opened you can use ordinary Ruby I/O methods such as printf, puts, gets, and read to read and write the socket.
• You must include a Content-Length: header in each HTTP request. The value of this header must be the length in bytes of the request body (everything after the blank line that terminates the header section). Without this header the server may reject the request.
• Be sure to include a blank line ("\r\n") between the header and body of each HTTP request.
• You will also need to include a Host: header in each HTTP request, whose value is the host name from the URL. Without this header the server may reject the request.
• You should also specify the header Connection: close; if you omit this header then the server will keep the connection open an extra 30 seconds after sending its response. Keeping the connection open is a good idea in normal use by the browser, since it allows the browser to make additional requests (e.g., for images) without the overhead of opening a new connection for each item. However, for this project keeping the connection open will cause a 30 second delay in your program unless you write extra code to collect all of the output without waiting for the server to close the connection.
• The Netslip server employs some of the security protections that have been discussed in lecture; you will need to understand those protections and work around them in order to exploit the loophole.
• If you are having trouble debugging your program, you might find it useful to print out everything that comes back from the server in each HTTP response. In many cases this will be an error page generated by the Web server; you can save this information into a .html file and then load that file into your browser to read the error messages it contains.

In writing your program you may not use any existing packages or programs for implementing the HTTP protocol, managing cookies, etc., such as the Net::HTTP Ruby library. You must implement the protocol yourself using only generic I/O methods such as puts and gets. However, you may use the method CGI::escape to URL-encode data, if that is useful.

Problem 3: The Fix (5 points)

Modify the Netslip server to eliminate the loophole that you have exploited. Look for the simplest possible change that eliminates the problem in a safe fashion. Copy any files that you changed into the project8/p2 directory.

Style Points (15 points)

10 style points will be awarded for Problem 1. The most important criterion for these points is whether your Ajax mechanism is reusable. In addition, your Javascript must be clean (appropriate use of classes, no global variables). We will also consider the usual issues of MVC decomposition, Rails conventions, validation, overall cleanliness of your code and templates, and the appearance and convenience of your Web pages.

5 style points will be awarded for Problem 2 if your Ruby code is clean and readable, and if your credit card output is easy to understand.

Deliverables

Use the standard class submission mechanism to submit everything in the project8 directory, including both the p1 and p2 subdirectories (clean up the p1 directory in the usual way before submitting). Be sure to include the file p1/README with information about your reusable Ajax mechanism. In addition, make sure your p2 subdirectory contains copies of any files that you changed in Problem 3. Lastly, include a file p2/README that contains a brief explanation of the security loophole and how you fixed it.