## Cybersecurity Pre-work: Malicious Input

> All required challenges should be completed in Security Shepherd (more information below)

### Pre-work overview [Returning Tech Fellow]
The pre-work is a taste of one of the more difficult subjects covered as part of the Cybersecurity course taken from Spring 2019's Unit 2 lab. As a returning TF it's imperative that the more complex concepts can be explained and solved by returning tech fellows like you.

In the next step, you'll create a Security Shepherd account, this is the platform we use for labs. To complete the pre-work you will complete the challenges in the **Unit 2 Section** of the Security Shepherd platform. The bonus challenges are optional however we encourage you to give them your best shot! Once you've completed the challenges, you'll submit a gif to serve as proof of work to the application dashboard. Since our courses have rolling admissions, finishing your pre-work as soon as possible will increase your chances of being admitted.

### Create a Security Shepherd Account
If you haven't already, **create a Security Shepherd Account:** Go to https://security.codepath.com to register an account:
- Username: **Your GitHub Username** (Should match the GitHub username you use to log into the CodePath Course Portal)
- Email Address: **The Email you registered with CodePath** (This is the address you receive emails from us at)
- Class: **2019 Cybersecurity University TFMs**

### Code Injection - The Hacker's Royal Road
Learning about the various methods, tactics, and exploits used by hackers can be overwhelming at first. Simply the sheer variety of these methods (to say nothing of the ingenuity and sophistication that are often at play) can be daunting to grapple with. It's useful to understand the broader patterns at work and how different types of attacks are categorized.

One of the most predominant of these patterns is **Code Injection** with the goal of **Remote Code Execution** or **Arbitrary Code Execution**: the exploitation of a software vulnerability used by attackers to introduce (or "inject") code into target software and change the course of its execution. Successful code injection unlocks a world of possibilities for the attacker, resulting in a compromise which can be catastrophic to the targeted system.

### Attack of the Week
* [SQL Injection](https://guides.codepath.org/websecurity/SQL-Injection)


In this week's lab, we'll be working with one very common form of a code injection attack: **SQL Injection**, in which the attacker is able to insert nefarious instructions into a plain-text SQL statement that are then executed by a database process. This is typically accomplished by manipulating input intended to be persisted in such a way that the database interprets the input not as data but as part of the SQL statement itself. Due to the ubiquity of database-backed applications using SQL, this method is as tried and true as they come--but that also means that there are many tried and true methods of preventing this type of attack. Because SQL is used not just to manipulate a database's instance data but also its structure and storage systems, an improperly-protected database can literally be wiped out using SQL injected via just one unprotected input.

### Prerequisites
This lab assumes that you are familiar with a few concepts:

* **Basic SQL**
* Statement types:`SELECT` especially, but also `INSERT`, `UPDATE`, and `DELETE`
* Syntax: delimiters, comments, groups, wildcards, and global statements
* Clauses: `FROM`, `WHERE`, `UNION`, and `JOIN`
* Operators: `AND` and `OR`
* **Form Input**
* Validation
* Sanitization

As this lab focuses on SQL injection, you'll need a basic understanding of what SQL is, how it works, and at least be familiar with the specific aspects of SQL listed above.

**New to SQL?** If you're not familiar with SQL, start with the basics so you can understand how these attacks work.

SQL is a plain-text language that is usually interpreted directly by a database, containing instructions for manipulating data: querying, inserting, updating, and deleting records in the database.
SQL is also used to manipulate the database's structure, or schema: creating, altering, dropping tables, columns, and stored procedures.

There's more to SQL than we can cover here, but here are some resources for learning more:

* **Reading Material**
* [Intro to SQL: Querying and managing data](https://www.khanacademy.org/computing/computer-programming/sql)
* [Introduction to Databases and SQL Querying](https://www.udemy.com/introduction-to-databases-and-sql-querying/)
* **Interactive Practice Exercises**
* [Introduction to SQL](https://sqlbolt.com/lesson/select_queries_introduction)

### Look, ma, no tools!


Imagine picking a lock with a paperclip, or breaking into a bank by squeezing in through an air vent. You won't be using any specialized tools for these challenges --- it will just be you, your keyboard, and the browser, and you'll be limited to using plain text input to compromise the target.

The target for all of these challenges is a remote database that is on a protected server, and, as would be the case in a real-world scenario, you won't have much if any information about the database you're trying to compromise. Your only way in will be via HTML form inputs --- some of them protected, some not --- whose values are processed via SQL statements. Your mission is to bypass any protections, fooling the application into passing your instructions directly to the database.

##### General Tips:

* ***Keep trying different things until you find something that works!*** Trial and error is the name of the game, not just for this lab, but often for hacking in general. A good hacker will not give up until convinced there is no way in.
* ***Keep track of what works and build on that.*** You'll see the same few bits of SQL work over and over again, often with minor variations. Keep track of these snippets; think of them as a set of picks for locks. Here are some very common ones:
* SQL Delimiters (`;` is the most common) signal the end of a statement
* SQL Comments (`--`, often followed by a trailing space) cause the rest of the statement to be ignored.
* SQL String Literals can use either single quotes `('`) or double-quotes (`"`) and quote characters can be escaped using a backslash (`\'`)
* SQL *Operators* such as `OR` and `AND` can affect the result of an expression such as a `WHERE` clause. For example, a WHERE clause which ends with `OR '1'='1'` will always evaluate to true
* `UNION` and `JOIN` clauses can follow a WHERE clause to return more data from other tables.
* ***Try to imagine the SQL statement that wraps your input.*** Knowing the form inputs get plugged into a SQL statement, try to imagine the probable forms of that statement and the places within them you have access to.

To access the following challenges, sign into https://security.codepath.com and navigate to the Week 2 section on the sidebar

### Challenge 0 - SQL Injection
Be sure to read the intro for this challenge, as it contains vital hints about how to solve it:

* The part of the SQL statement you're targeting
* The operator you can use to change its evaluation

Remember: ***keep trying***. The challenge will offer an additional hint after a few attempts, but one solution will use a combination of comment, delimiter, and an OR statement that always evaluates to `true`

### Challenge 1 - SQL Injection 1
Very similar to the previous challenge with a minor variation. Hint: try using different quotes for string literals, mixing and matching.

### Challenge 2 - SQL Injection 2
By now you're familiar with the difference between an unprotected input, whose data isn't validated (checking that the input matches a pattern) or sanitized (filtering out or escaping invalid input), and one that is. Yet even validated fields can be vulnerable if the format of the input is flexible enough.

For example, validations that greatly restrict input are generally harder to defeat. A form input that only allows digit characters and nothing else, not even spaces, would be very difficult if not impossible to manipulate in this case.

But the input for this challenge checks for a valid email address, which is much more complex. We're all familiar with the basic [e-mail] email, but there are `many, many unusual examples of valid email addresses`. Any engineer who's ever implemented a custom email validation routine quickly discovers that it's a lot more complicated than you'd think.

That brings up another issue: there are also many, many different email validation routines out there, and a lot of them are incorrect, outdated, or broken. There's no way to know in advance how robust or restrictive the one we're dealing with is, and this is really true for any form validation you'll encounter.

So here's a big hint for this challenge: valid emails can have spaces inside of quoted strings. So `"my email"@gmail.com` is a valid email address.

### Challenge 3 - SQL Injection Escaping
The giveaway hint for this challenge is contained in the introduction on the challenge page, which tells you the method the developer used to prevent injection attacks. You can use this same method to defeat it. Hint: quote characters are escaped in SQL by a preceding backslash.

### Challenge 4 - SQL Injection 3
The challenges get more difficult from here forward, requiring a lot more experimentation, the combination of techniques, and guessing.

To solve this challenge you need to devise a hack that will get you to the goal (getting Mary Martin's credit card number) from the starting point: a rudimentary customer name search function.

#### What do we know?

There's a database containing customer information, including the customer's name and a credit card number
Only the name is searchable
Searching for `Mary Martin` returns one result
Searching for `Mary` returns zero results
As it's a search function, the input is probably plugged into a SQL statement's WHERE clause

#### What do we *not* know?

The names of any tables or columns involved
Whether the credit card number is stored in the same table or a separate one
Whether the input is validated or sanitized
Whether the page will display all data returned by the query or just the name

#### There's only one way to find out: hack it. Start with the simplest assumptions proceed accordingly:

* Assume there's only one table with both name and credit card number
* The search doesn't support partial matching, so assume there's only one column that contains the full name as displayed
* Guess the names of the tables and columns based on what we know. Most DBAs and engineers will choose names for tables and columns that make sense and are obvious
* Assume the input isn't sufficiently sanitized and that some additional SQL can be inserted
* Assume the page is dumb enough to display whatever the query returns

Hint: try using a `UNION SELECT` clause to pull in the credit card number to the query.

### Stretch Challenges - Advanced SQL Injection
The remaining ***optional*** challenges are increasingly difficult, requiring combinations of all the techniques so far and a good amount of trial-and-error, including guesswork. This means they will generally take a lot more time than the previous challenges, and, as such, they're optional for this lab, but if you've made it this far and want to test your ***skills***, we encourage you to try them, in the order listed:

* SQL Injection 4
* SQL Injection 5
* SQL Injection Stored Procedure
* SQL Injection 6
* SQL Injection 7

### Cheat Sheets
* [SQL Injection Cheat Sheet](https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/)
* [SQL Injection Attacks by Example](http://www.unixwiz.net/techtips/sql-injection.html)
* [Basic SQL Injection with Login](http://zerofreak.blogspot.com/2012/01/chapter2-basic-sql-injection-with-login.html) - contains lots of examples