What is SQL?

SQL Meaning: it is a domain-specific language. It is used in application development

language to enable a programmer to work with the data. The data is stored in a relational
database. To manage this data, we have relational database management systems like SQL
Server, MySQL, MS Access, etc. that use SQL as a standard database language.

What Is a Database?
A database is a well-organized collection of data that is stored in an electronic format. To be
more specific, a SQL database is an electronic system that allows users to easily access,
manipulate, and update the data.

What Is a Database Management System?

Consider a School SQL Database which has a record of the present students and the
previously studied students in the Student Details table. Similarly, it may contain Faculty
Details, Management Details, Staff Details, and many more depending on the school’s
requirement. As the data is in huge amounts, to manage it we need a database management
system.

Almost all modern databases are managed by a Database Management System (DBMS).
Basically, it is a system software used for creating data in a systematic way and managing
databases.
How Does SQL Database Manage Data?

DBMS provides, for both users and programmers, a fundamental way to create, retrieve,
update, and manage data.

Consider a scenario where a student XYZ wants to change his address. The DBMS searches
the details of XYZ in the table ‘Student Details’ from the database ‘School Database’ and
displays it for the user, and then the user edits it.

Types of Databases
The databases are classified into various databases depending upon the usage requirements.

• Centralized database.
• Distributed database.
• Personal database.
• End-user database.
• Commercial database.
• NoSQL database.
• Operational database.
• Relational database.
• Cloud database.
• Object-oriented database.
• Graph database.

Types of SQL Commands

SQL commands are traditionally divided into four categories:

• Data Query Language (DQL Commands in SQL)

• Data Definition Language (DDL Commands in SQL)
• Data Manipulation Language (DML Commands in SQL)
• Data Control Language (DCL Commands in SQL)
Data Query Language (DQL Commands in SQL)

Data Query Language comprises only one command ‘select.’ This command can be
accompanied by many other clauses to compose queries.

Data Definition Language (DDL Commands in SQL)

Data Definition Language is power for SQL, which allows a user to create and restructure
database objects. The basic DDL commands in SQL are Create Tables, Alter Tables, and
Drop Tables.

CREATE TABLE It creates a new table

DROP TABLE It deletes the ENTIRE table.

ALTER TABLE Modifies the existing table

Data Manipulation Language (DML Commands in SQL)

Data Manipulation Language is used to manipulate data within the tables. The basic DML
commands in SQL are Insert, Update and Delete.

SELECT Retrieve information from the database

INSERT Add new information to a database

UPDATE Modifies the information currently stored in a database

DELETE Delete information from the database

Data Control Access Language (DCL Commands in SQL)

And finally, we have Data Control Access which allows the user to control access to data
within the database. These DCA commands are generally used to control the distribution of
privileges among users and create objects related to user access. The basic DCL commands in
SQL are Grant and Revoke.

This brings us to the end of the Introduction to SQL. Here we have learned what is SQL, SQL
full form, SQL Database, all basic SQL commands, and their types – DDL, DCL, DML, and
DQL with examples.

How to Use SQL

With SQL, we can create databases, tables, functions, etc. the following are the SQL
commands you need to learn to work in a database.

• CREATE DATABASE – for creating a database

• CREATE TABLE – for creating tables
• SELECT – for finding/extracting some data from a database
• UPDATE – for making adjustments and edit data
 • DELETE – for deleting some data

What is SQL injection (SQLi)?

SQL injection is a web security vulnerability that allows an attacker to interfere with the
queries that an application makes to its database. It generally allows an attacker to view data
that they are not normally able to retrieve. This might include data belonging to other users,
or any other data that the application itself is able to access. In many cases, an attacker can
modify or delete this data, causing persistent changes to the application's content or behavior.

In some situations, an attacker can escalate an SQL injection attack to compromise the
underlying server or other back-end infrastructure, or perform a denial-of-service attack.

What is the impact of a successful SQL injection attack?

A successful SQL injection attack can result in unauthorized access to sensitive data, such as
passwords, credit card details, or personal user information. Many high-profile data breaches
in recent years have been the result of SQL injection attacks, leading to reputational damage
and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an
organization's systems, leading to a long-term compromise that can go unnoticed for an
extended period.

SQL injection examples

There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise
in different situations. Some common SQL injection examples include:

• Retrieving hidden data, where you can modify an SQL query to return additional
results.
 • Subverting application logic, where you can change a query to interfere with the
application's logic.
• UNION attacks, where you can retrieve data from different database tables.
• Examining the database, where you can extract information about the version and
structure of the database.
• Blind SQL injection, where the results of a query you control are not returned in the
application's responses.

Retrieving hidden data

Consider a shopping application that displays products in different categories. When the user
clicks on the Gifts category, their browser requests the URL:

https://insecure-website.com/products?category=Gifts

This causes the application to make an SQL query to retrieve details of the relevant products
from the database:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

This SQL query asks the database to return:

• all details (*)

• from the products table
• where the category is Gifts
• and released is 1.

The restriction released = 1 is being used to hide products that are not released. For unreleased
products, presumably released = 0.

The application doesn't implement any defenses against SQL injection attacks, so an attacker
can construct an attack like:

https://insecure-website.com/products?category=Gifts'--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

The key thing here is that the double-dash sequence -- is a comment indicator in SQL, and
means that the rest of the query is interpreted as a comment. This effectively removes the
remainder of the query, so it no longer includes AND released = 1. This means that all products
are displayed, including unreleased products.

Going further, an attacker can cause the application to display all the products in any
category, including categories that they don't know about:

https://insecure-website.com/products?category=Gifts'+OR+1=1--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

The modified query will return all items where either the category is Gifts, or 1 is equal to 1.
Since 1=1 is always true, the query will return all items.

Subverting application logic

Consider an application that lets users log in with a username and password. If a user submits
the username wiener and the password bluecheese, the application checks the credentials by
performing the following SQL query:

SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

If the query returns the details of a user, then the login is successful. Otherwise, it is rejected.

Here, an attacker can log in as any user without a password simply by using the SQL
comment sequence -- to remove the password check from the WHERE clause of the query. For
example, submitting the username administrator'-- and a blank password results in the following
query:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

This query returns the user whose username is administrator and successfully logs the attacker
in as that user.

Retrieving data from other database tables

In cases where the results of an SQL query are returned within the application's responses, an
attacker can leverage an SQL injection vulnerability to retrieve data from other tables within
the database. This is done using the UNION keyword, which lets you execute an additional
SELECT query and append the results to the original query.

For example, if an application executes the following query containing the user input "Gifts":

SELECT name, description FROM products WHERE category = 'Gifts'

then an attacker can submit the input:

' UNION SELECT username, password FROM users--

This will cause the application to return all usernames and passwords along with the names
and descriptions of products.

Examining the database

Following initial identification of an SQL injection vulnerability, it is generally useful to
obtain some information about the database itself. This information can often pave the way
for further exploitation.
You can query the version details for the database. The way that this is done depends on the
database type, so you can infer the database type from whichever technique works. For
example, on Oracle you can execute:

SELECT * FROM v$version

You can also determine what database tables exist, and which columns they contain. For
example, on most databases you can execute the following query to list the tables:

SELECT * FROM information_schema.tables

Blind SQL injection vulnerabilities

Many instances of SQL injection are blind vulnerabilities. This means that the application
does not return the results of the SQL query or the details of any database errors within its
responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the
techniques involved are generally more complicated and difficult to perform.

Depending on the nature of the vulnerability and the database involved, the following
techniques can be used to exploit blind SQL injection vulnerabilities:

• You can change the logic of the query to trigger a detectable difference in the application's
response depending on the truth of a single condition. This might involve injecting a new
condition into some Boolean logic, or conditionally triggering an error such as a divide-by-
zero.
• You can conditionally trigger a time delay in the processing of the query, allowing you to
infer the truth of the condition based on the time that the application takes to respond.
• You can trigger an out-of-band network interaction, using OAST techniques. This technique
is extremely powerful and works in situations where the other techniques do not. Often, you
can directly exfiltrate data via the out-of-band channel, for example by placing the data into a
DNS lookup for a domain that you control.

How to detect SQL injection vulnerabilities

The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp
Suite's web vulnerability scanner.

SQL injection can be detected manually by using a systematic set of tests against every entry
point in the application. This typically involves:

• Submitting the single quote character ' and looking for errors or other anomalies.
• Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry
point, and to a different value, and looking for systematic differences in the resulting
application responses.
• Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the
application's responses.
• Submitting payloads designed to trigger time delays when executed within an SQL query, and
looking for differences in the time taken to respond.
• Submitting OAST payloads designed to trigger an out-of-band network interaction when
executed within an SQL query, and monitoring for any resulting interactions.
How and Why Is an SQL Injection Attack Performed
To make an SQL Injection attack, an attacker must first find vulnerable user inputs within the
web page or web application. A web page or web application that has an SQL Injection
vulnerability uses such user input directly in an SQL query. The attacker can create input
content. Such content is often called a malicious payload and is the key part of the attack.
After the attacker sends this content, malicious SQL commands are executed in the database.

SQL is a query language that was designed to manage data stored in relational databases. You
can use it to access, modify, and delete data. Many web applications and websites store all
the data in SQL databases. In some cases, you can also use SQL commands to run operating
system commands. Therefore, a successful SQL Injection attack can have very serious
consequences.

• Attackers can use SQL Injections to find the credentials of other users in the database.
They can then impersonate these users. The impersonated user may be a database
administrator with all database privileges.
• SQL lets you select and output data from the database. An SQL Injection vulnerability
could allow the attacker to gain complete access to all data in a database server.
• SQL also lets you alter data in a database and add new data. For example, in a
financial application, an attacker could use SQL Injection to alter balances, void
transactions, or transfer money to their account.
• You can use SQL to delete records from a database, even drop tables. Even if the
administrator makes database backups, deletion of data could affect application
availability until the database is restored. Also, backups may not cover the most
recent data.
• In some database servers, you can access the operating system using the database
server. This may be intentional or accidental. In such case, an attacker could use an
SQL Injection as the initial vector and then attack the internal network behind a
firewall.

How to Prevent SQL Injections (SQLi) – Generic Tips

Preventing SQL Injection vulnerabilities is not easy. Specific prevention techniques depend
on the subtype of SQLi vulnerability, on the SQL database engine, and on the programming
language. However, there are certain general strategic principles that you should follow to
keep your web application safe.

Step 1: Train and maintain awareness

To keep your web application safe, everyone involved in building

the web application must be aware of the risks associated with SQL
Injections. You should provide suitable security training to all your
developers, QA staff, DevOps, and SysAdmins. You can start by
referring them to this page.
 Step 2: Don’t trust any user input

Treat all user input as untrusted. Any user input that is used in an
SQL query introduces a risk of an SQL Injection. Treat input from
authenticated and/or internal users the same way that you treat
public input.

Step 3: Use whitelists, not blacklists

Don’t filter user input based on blacklists. A clever attacker will

almost always find a way to circumvent your blacklist. If possible,
verify and filter user input using strict whitelists only.

Step 4: Adopt the latest technologies

Older web development technologies don’t have SQLi protection.

Use the latest version of the development environment and language
and the latest technologies associated with that
environment/language. For example, in PHP use PDO instead of
MySQLi.

Step 5: Employ verified mechanisms

Don’t try to build SQLi protection from scratch. Most modern

development technologies can offer you mechanisms to protect
against SQLi. Use such mechanisms instead of trying to reinvent the
wheel. For example, use parameterized queries or stored procedures.

References:
https://www.acunetix.com/websitesecurity/sql-injection/

https://portswigger.net/web-security/sql-injection#subverting-application-logic

https://intellipaat.com/blog/tutorial/sql-tutorial/introduction-to-sql/