By Karl Voelker

The goal: to understand applications that

• use the stateless HTTP protocol,
• are rendered with HTML in web browsers,
• require server-side programming,
• and provide an "interactive" application for users.

Confusing parts of our example code will be explained.

HTTP is the protocol that web clients (browsers) use to communicate with web servers.

HTTP communication goes like this:

1. Client sends a complete request to server.
2. Server sends a complete response to client.
3. The end.

That was an ordinary web page.

Let's see a program the webserver can run that will produce the same web page:

That was pretty boring.

Let's spice it up with some user input.

Remember HTTP? The entire client request comes before the server response.

All user input must be included by the client in the request.

User input in the request consists of key-value pairs.

We hope the user knows what keys to provide.

Extracting the key-value user inputs is tricky.

Libraries exist for most languages that make it easy!

In Perl:

use CGI qw/param/;

Load the CGI library and import the param subroutine.

param('foo')

Get the user input value for key foo.

Our users would include the name key in their requests like this:

http://some.domain/hello.pl?name=Karl

But most users aren't that clever.

We need to make user input easier for users!

You've just seen a form.

A form contains named input controls.

When the form is submitted, a new HTTP request is made, and the values entered into the input controls are included!

The form tag encloses a form. It has these attributes:

method

Type of HTTP request to use on submit (GET or POST)

action

URL to request on submit (defaults to that of the current page)

Most input controls are created with the input tag, with these attributes:

name

Key to associate with the value entered into this input

type

Input type (text, hidden, checkbox, radio, submit)

value

Meaning varies by input type

The value attribute is the default value:

The hidden input is invisible. Use it for:

• Input values determined by JavaScript
• Pre-determined input values embedded in the page by the server

A set of checkboxes or radio buttons shares a single name, but each needs a unique value:

Bar:
Baz:

A submit input is a button that causes the form to be submitted when pressed.

The value is the text shown on the button.

Use select to create a menu of choices:

Bar Baz

Now let's add a good-bye page to our application.

We want the user to choose between our hello and good-bye pages.

How can we add our good-bye page?

• Create a new file, like goodbye.pl, accessed by its own URL, which produces the new page
• Have our existing script accept another input which determines which page we show

We will use the second approach.

Most interesting web applications remember some information that users can affect.

How can we do this?

In files

Good unless you need to search

In databases

The typical approach

In memory

If your program continues running between HTTP requests

What's the difference?

GET

Get something, but don't change anything.

POST

Change something.

This is an important distinction that affects caching and browser behavior.

Everyone loves logging in. You need:

• Server-side user and password data
• A way for the client to give a username and password, thus logging in
• A way for the client to remain logged in

The path to authentication is fraught with dangers.

This isn't too hard, until your server gets hacked and all the passwords are stolen.

You should store all passwords hashed.

A hashing function works like this:

hash(unique_input) -> unique_garbage

Also, you want a hash function for which this function doesn't exist or is impossibly slow:

unhash(unique_garbage) -> unique_input

It may not be obvious, but it is simple:

1. Get claimed password from client
2. Hash claimed password
3. Compare hash of claimed password to stored hash of correct password

There are many real-world hashing functions.

Attempting to break a hash function is a focus of security research.

MD5, SHA-1

Widely used, but recently broken

SHA-256, SHA-512

Theoretically similar to SHA-1, but not yet broken

To prevent interception of passwords, configure your webserver to use SSL or TLS (https).

To prevent bystanders from seeing a password, use instead of .

This is trickier than it sounds. Once the login request is done, how do you know which later requests are coming from which users?

The standard answer: cookies.

A cookie is a way to store data on the client.

On each request, the client's browser will include your cookie.

In some HTTP response, you include a special header containing cookie data.

In each subsequent HTTP request, the client includes a special header with that same data.

In our login scenario, we will set the cookie in response to the client's login request.

What could go in the cookie?

The client's username

Bad idea! Any client could make up a cookie containing someone else's username.

The client's username and password

Still risky! If the client's computer is compromised, so is their password.

Random garbage

Huh?

Here's what happens on a login:

1. Server makes up random garbage (call it X)
2. Server records X with the username that is logging in
3. Server responds with X as the new cookie value

The random garbage is like a password, but it's only valid until the user logs out (or the session times out).

Injection vulnerabilities typically appear when code is prepared with one language as a string, then executed or used elsewhere:

• SQL database commands
• Shell commands
• Filenames
• Regular expressions
• Response to client (HTML, JavaScript)

We will consider examples of all of these, and how to avoid them.

Suppose you want to let users look each other up by name.

You get input from the client and put it in $username.

You have a query to search for user information:

$query = "SELECT favorite_animal FROM users WHERE name = $username"

Now, if we search for this user:

'foo'; DELETE FROM important_data

The query becomes:

SELECT favorite_animal FROM users WHERE name = 'foo'; DELETE FROM important_data

Any good database library provides a way to make safe queries, usually called bind variables.

$query = "SELECT favorite_animal 
	FROM users WHERE name = ?";
$sth = $dbh->prepare($query);
$sth->execute($username);

The ? creates a bind variable.

Much like SQL injection, shell injection typically involves appending a malicious command.

If you don't actually need the shell, you should be running the other program directly instead.

Suppose your application creates a file in a directory, say /home/foo/web, for each user.

What happens when a user's name is ../../../something/important?

Suppose that you let users write a little about themselves:

What just happened? The attacker:

1. created an invisible frame,
2. sent the frame to an attacker-owned URL,
3. and included the cookie of the user viewing the page in the request to the attacker's URL.

The user's session has been stolen!

Questions?