> For the complete documentation index, see [llms.txt](https://jorgectf.gitbook.io/awae-oswe-preparation-resources/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jorgectf.gitbook.io/awae-oswe-preparation-resources/by-vulnerability/sql-injection/summary.md).

# Summary

To exploit this kind of vulnerability, the query must be appended an `unsanitized (or not completely sanitized) user-controlled parameter.`

For example, let's imagine this background: `($id being a user-supplied GET/POST parameter without previous sanitization)`

```sql
SELECT id, user, password FROM user_table WHERE id = '$id';
```

In an everyday situation, this query would consist of a different set of `numbers`.

```sql
SELECT id, user, password FROM user_table WHERE id = '1';
```

```sql
SELECT id, user, password FROM user_table WHERE id = '999';
```

```sql
SELECT id, user, password FROM user_table WHERE id = '56';
```

However, as the user controls the variable, a query can't also supply an intended id but `more characters` to make the query longer and `extract data`.

```sql
SELECT id, user, password FROM user_table WHERE id = '2' OR user = 'admin';
```

In this example, the injected query would return rows whose `id` equals `2` `OR` whose `user` equals `admin`. I can't think of an environment where this injections makes sense, but let's think about `this one`.

```sql
SELECT id, user, password FROM user_table WHERE user = '$supplied_user' AND password = '$supplied_password';
```

#### On the backend, there's a line checking whether the query returns `>0` rows. If it does, the login is `successful` because there's a user that fits our input.

An query that would be returning the `intended` result:

```sql
SELECT id, user, password FROM user_table WHERE user = 'jorge' AND password = 'hunter2';
```

However, as seen before, user or password fields can contain `more characters`.

```sql
SELECT id, user, password FROM user_table WHERE user = 'jorge' AND password = 'hunter2' OR 1=1;
```

Here's where the most common injection occurs. *The famous* `OR 1=1`. Can you think of what's actually happening here? Well, the thing is that `the first query` would return `jorge's row` if a user with that user and password existed. `In the second one`, it will return `the entire database`, as **1 will always equal 1**, and an `OR operator` is being used.

```sql
SELECT id, user, password FROM user_table WHERE user = 'jorge' AND password = 'hunter2';
# Hey database, give me the id, user and password from the table 'user_table' whose user equals 'jorge' and password 'hunter2'.
# + Ooookay, Im afraid there's no user with such information! My bad.
# No probs, good job on that.


SELECT id, user, password FROM user_table WHERE user = 'jorge' AND password = 'hunter2' OR 1=1;
# Hey database, give me the id, user and password from the table 'user_table' whose user equals 'jorge' and password 'hunter2'.
# + Ooookay, Im afraid there's no user with such information! My bad.
# No probs, shall I add one more requirement?
# + Yeah, alright.
# Thanks, so here it is. Give me the id, user and password from the table 'user_table' when 1=1.
# + Hmm okay, 1 equals 1 so here you have! (700 rows).
```

This is not the only occasion where an injection might be successful. As **SQL** has lots of methods, this injections can be **(non)stacked**, and in `clauses` such as `INSERT, UPDATE, SELECT, WHERE, ORDER BY, etc.`

#### Stacked queries

This queries allow using `;`, so more than one query can be executed.