st27_ExploitWeekIntro.md

# Introduction to Exploit Week.

This week we are going to examine some common web based exploits. You
will also get the opportunity to put the theory into practice in the
lab and do some hacking.

> This is a pretty hardcore week, we will be looking at (and
> performing) real exploits of vulnerable services.  However, you
> won't need any specialist tools or knowledge, just a web browser and
> a bit of thought.  Some of this may be challenging to digest as you
> navigate through the material; however, rest assured, we'll explore
> the practical side of this content in the lab session

## Intro to the Exploits

The exploits we are going to be doing are in the most commonly found
issues with websites.  In the first week we looked at the OWASP
top 10.  These are based on a survey of the most common security
issues found on web services.

The two web based exploits we are going to look at are featured in the OWASP Top 10:

 - SQL Injection
 - Cross Site Scripting

These are very common issues, that could affect you when you visit web
sites.  We will discuss why they happen, how you can test for them,
and methods that web site developers can use to protect against them.

## Why these Exploits Happen

As we have moved from static web pages to the 'wonders' of Web2.0,
with its responsive content and use of dynamic technologes such as
javascript, we have needed ways of getting users to interact with a
website. While this has let us do many amazing things, it has also
been the primary cause of insecurity in web apps (and just about any
other type of application).

The main problem here is that allowing users a way of arbitrarily
adding input, means that they will do unexpected things. Therefore we
get to **RULE #1: NEVER trust user input**.  This is the root cause of
many web based (and non web based) security flaws, and occurs in
topics such as: 

-   Form Validation: Checking the information that the users have
    submited to programs, to ensure that no malicious code can be
    executed
-   Buffer overflows: A prgramming flaw where we are able to overwrite
    a programs memory, changing its behavour.
-   Remote Command Execution: Where a system allows remote users to
    run commands on a server.
-   Users Breaking our lovely program by being idiots (**RULE #2: The second
    you make something "Idiot proof", they will release an upgraded
    version of Idiot**)


When it comes to validating user input we could spend some time
 discussing the merits of Whitelisting versus Blacklisting

-   **Blacklisting** (filtering bad content) means we attempt to get rid of
    malicious input before using the result
-   **Whitelisting** (allowing only good input) means we only allow a set of pre-defined inputs to be used

Both cause headaches, as they need to be well-designed to catch all the
shenanigans that the user is likely to input, and in general this is
impossible.

Personally, I lean towards blacklists (stopping the worst inputs), as
whitelists don't tend to deal with Rule #2 (all users are idiots) quite
so well.

Unfortunately there are no foolproof methods where filtering is involved, as it can
often be bypassed by a bit of thinking. All we can do is remember that
trusting the user is a BadThing(TM) and try our best to consider all the
possible scenarios in advance.

Forms are (one of) the ways HTML deals with user input.

While the mechanics of forms, their input types, and their attributes
could be another course, there are several interesting attributes of
forms we need to consider as penetration testers.


### A typical HTML Form
[LD comment: This could be another step?]()


Let's consider the following password change form:

~~~ html
<form action="processor.php" method="post">
    <input type="password" class="form-control" id="password" name="password" placeholder="Password">
    <input type="password"class="form-control" id="password2" name="password2" placeholder="Repeat Password">
    <input type="hidden" name="user" value="dang42">

    <button type="submit" class="btn btn-primary">Submit</button>
  </div>
</form>
~~~

Looks good, right? Let's pick it apart a bit.

-   The form sends a POST request to the **processor.php** page

-   We have a few inputs:

    -   Two inputs of the type "Password". These by default will be
        obscured when data is entered. The **name** field is the part
        passed in the HTTP request.
    -   A **hidden** field, containing a pre-set value
    -   The Submit button

The hidden field will not be displayed to the user, and is used by the
web application to store some form of state.

Remember that HTTP is a stateless protocol, so each request is treated
as an independent transaction (more on this when we get to Cookies). We
can assume that this application is not using other forms of session
management, so the user that the password change is applied to is the
user specified in the hidden user field.

### What can possibly go wrong here?

Lots, but predominately credential hijacking. The developer is guilty of
three key mistakes:

-   Security Through Obscurity
-   Trusting user input
-   Performing all authentication on the client side

Security through obscurity is a very BadThing(TM); controlling whose
password gets changed with a hidden field is a terrible idea.

As l337 HaX0R d00dZ we should know about the mechanics behind the
protocols we are testing. "Use the Source" and this should stick out
like a sore thumb.

We also trust the user input (partially from above). This is bad because its
easy it is to modify HTTP requests, so it is trivial to change the **user**
field to someone else and take control of their password.

Finally, there is no authentication performed. This is probably the
worst offence, as just asking for the current password (and performing a
check against it) would stop both of the above attacks working.


> So to exploit this we:
>
> 1.  Login as a user we know
> 2.  Send a POST request with our target user and whatever password we
>     require.


### Client side form validation

Client side form validation is where the form input is checked in the browser before being sent to the server.
This allows us to do things like checking if the input type is as expected (for example, is that really an e-mail address).  In the general case client side form validation is a good thing, because we can parse the form using HTML5/JavaScript and stop
bad requests from being sent to (and rejected by) the server.

However, relying on this to clean up the user input is also a
BadThing(TM)

-   We can turn JS off, and avoid client side validation
    -   HTML5 is a bit trickier but.....
-   We can send whatever we want anyway (via requests)

If client side validation is used it is important that it is repeated on
the server side (remember Rule #1)

# Summary

A lot of web based exploits come from trusting the user to do what we
expect them to do.  Allowing them to add arbitrary input to any
interactive components of a website, can lead to a toehold that we can
then expand into a fully fledged exploit.

For the rest of this week we will look at two common web based
exploits in detail, and show how we can either steal data or
authenticate as another user.