> 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://jorgectf.gitbook.io/awae-oswe-preparation-resources/by-vulnerability/sql-injection/summary.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.