{% extends 'introduction/base.html' %} {% block content %} {% block title %} SQL Injection {% endblock %}

Sql Injection

An application is vulnerable to attack when:
1. User-supplied data is not validated, filtered, or sanitized by the application.
2. Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
3. Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
4. Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.

Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections. Automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs is strongly encouraged. Organizations can include static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to identify introduced injection flaws before production deployment.
A SQL injection is a famous Injection attack that consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

SQL injection errors occur when: Data enters a program from an untrusted source. The data used to dynamically construct a SQL query The main consequences are:

This lab helps you to exploit the common type of sql injection vulnerability, caused due to the lack of input validation and directly exposing input into the query.
The user on accessing the lab is given a log in page . The user has to try to login in as admin. SQL Injection vulnerability can be identified by injecting a ' in any of the fields. If it results in an SQL error, SQL injection vulnerability is identified
Exploiting SQL Injection Vulnerability

  • Enter the user name as admin
  • Enter the password as anything' OR '1' ='1
  • This should log you in as admin, without knowing the admins password.

Understanding the Exploit

The website logs a user in by checking the entered username and password against the ones stored in the database. If they match, the user is logged in. Lets first analyse the sql query used to compare the username and password in the database.
"SELECT * FROM introduction_login WHERE user='"+name+"'AND password='"+password+"'"
The name and password parameters are the ones you give as input, which is directly inserted into the query.

Why the error?

When we inserted a ' in the input it threw an error , this is because the sql query was not balanced and it threw an error.
SELECT * FROM introduction_login WHERE user='admin' AND password='''
The query quotes in the password field are unbalanced, this can be balanced by adding another quote to it.

Lets just plug our payload into the query and see what it looks like.
SELECT * FROM introduction_login WHERE user='admin' AND password='anything' OR '1' ='1'
Now the query means select username = admin where password is anything OR '1'='1' .
'1'='1' will always result in TRUE and the query fetches the user with name admin and password=TRUE.
Thus allowing us to login in as admin.


{% endblock %}