Code Injection

Code injection is the malicious injection or introduction of code into an application. The code
introduced or injected is capable of compromising database integrity and/or compromising
privacy properties, security and even data correctness. It can also steal data and/or bypass
access and authentication control. Code injection attacks can plague applications that depend
on user input for execution.

Code Injection differs from Command Injection. Here an attacker is only limited by the
functionality of the injected language itself. For example, if an attacker is able to inject PHP
code into an application and have it executed, he is only limited by what PHP is capable of.

Code injection vulnerabilities range from easy to difficult-to-find ones. Many solutions have been
developed for thwarting these types of code injection attacks, for both application and
architecture domain. Some examples include input validation, parameterization, privilege setting
for different actions, addition of extra layer of protection and others.

Example:
When a developer uses the PHP eval() function and passes it untrusted data that an attacker
can modify, code injection could be possible.
Cross Site Scripting (XSS)
Cross Site Scripting (XSS) is a vulnerability in a web application that allows a third party to
execute a script in the user’s browser on behalf of the web application. Cross-site Scripting is
one of the most prevalent vulnerabilities present on the web today. The exploitation of XSS
against a user can lead to various consequences such as account compromise, account
deletion, privilege escalation, malware infection and many more.

In its initial days, it was called CSS and it was not exactly what it is today. Initially, it was
discovered that a malicious website could utilize JavaScript to read data from other website’s
responses by embedding them in an iframe, run scripts and modify page contents. It was called
CSS (Cross Site Scripting) then. The definition changed when Netscape introduced the Same
Origin Policy and cross-site scripting was restricted from enabling cross-origin response
reading. Soon it was recommended to call this vulnerability as XSS to avoid confusion with
Cascading Style Sheets(CSS). The possibility of getting XSSed arises when a website does not
properly handle the input provided to it from a user before inserting it into the response. In such
a case, a crafted input can be given that when embedded in the response acts as a JS code
block and is executed by the browser. Depending on the context, there are two types of XSS –

1. Reflected XSS: If the input has to be provided each time to execute, such XSS is called
reflected. These attacks are mostly carried out by delivering a payload directly to the
victim. Victim requests a page with a request containing the payload and the payload
comes embedded in the response as a script. An example of reflected XSS is XSS in the
 search field.

2. Stored XSS: When the response containing the payload is stored on the server in such
a way that the script gets executed on every visit without submission of payload, then it
is identified as stored XSS. An example of stored XSS is XSS in the comment thread.

There is another type of XSS called DOM based XSS and its instances are either reflected or
stored. DOM-based XSS arises when user-supplied data is provided to the DOM objects without
proper sanitizing. An example of code vulnerable to XSS is below, notice the variables firstname
and lastname :
<?php

if(isset($_GET["firstname"]) && isset($_GET["lastname"]))

$firstname = $_GET["firstname"];

$lastname = $_GET["lastname"];

if($firstname == "" or $lastname == "")

echo "<font color=\"red\">Please enter both

fields...</font>";

else

echo "Welcome " . $firstname. " " . $lastname;

}
 }

?>

User-supplied input is directly added in the response without any sanity check. Attacker an input
something like –

<script> alert(1)
</script>

and it will be rendered as JavaScript. There are two aspects of XSS (and any security issue) –

1. Developer: If you are a developer, the focus would be secure development to avoid
having any security holes in the product. You do not need to dive very deep into the
exploitation aspect, just have to use tools and libraries while applying the best practices
for secure code development as prescribed by security researchers. Some resources
for developers are –

a). OWASP Encoding Project : It is a library written in Java that is developed by the
Open Web Application Security Project(OWASP). It is free, open source and easy to
use. b). The “X-XSS-Protection” Header : This header instructs the browser to activate
the inbuilt XSS auditor to identify and block any XSS attempts against the user. c). The
XSS Protection Cheat Sheet by OWASP : This resource enlists rules to be followed
during development with proper examples. The rules cover a large variety of cases
where a developer can miss something that can lead to the website being vulnerable to
XSS. d). Content Security Policy : It is a stand-alone solution for XSS like problems, it
instructs the browser about “safe” sources apart from which no script should be executed
from any origin.

2. Security researchers: Security researchers, on the other hand, would like similar
resources to help them hunt down instances where the developer became lousy and left
an entry point. Researchers can make use of –

a). CheatSheets – 1. XSS filter evasion cheat sheet by OWASP. 2. XSS cheat sheet by
Rodolfo Assis. 3. XSS cheat sheet by Veracode.

b). Practice Labs – 1. bWAPP 2. DVWA(Damn vulnerable Web Application) 3.

prompt.ml 4. CTFs

c). Reports – 1. Hackerone Hacktivity 2. Personal blogs of eminent security researchers

like Jason Haddix, Geekboy, Prakhar Prasad, Dafydd Stuttard(Portswigger) etc.
SQL Injection
SQL injection is a technique used to extract user data by injecting web page inputs as
statements through SQL commands. Basically, malicious users can use these instructions to
manipulate the application’s web server.

1. SQL injection is a code injection technique that can compromise your database.
2. SQL injection is one of the most common web hacking techniques.
3. SQL injection is the injection of malicious code into SQL statements via web page input.

The Exploitation of SQL Injection in Web Applications

Web servers communicate with database servers anytime they need to retrieve or store user
data. SQL statements by the attacker are designed so that they can be executed while the web
server is fetching content from the application server. It compromises the security of a web
application.

Example of SQL Injection

Suppose we have an application based on student records. Any student can view only his or her
own records by entering a unique and private student ID.

Suppose we have a field like the one below:

Student id: The student enters the following in the input field: 12222345 or 1=1.

Query:

SELECT * from STUDENT where

STUDENT-ID == 12222345 or 1 = 1

Now, this 1=1 will return all records for which this holds true. So basically, all the student data is
compromised. Now the malicious user can also delete the student records in a similar fashion.
Consider the following SQL query.

Query:

SELECT * from USER where

USERNAME = “” and PASSWORD=””

Now the malicious can use the ‘=’ operator in a clever manner to retrieve private and secure
user information. So instead of the above-mentioned query the following query when executed
retrieves protected data, not intended to be shown to users.

Query:

Select * from User where

(Username = “” or 1=1) AND

(Password=”” or 1=1).
Since 1=1 always holds true, user data is compromised.

Impact of SQL Injection

The hacker can retrieve all the user data present in the database such as user details, credit
card information, and social security numbers, and can also gain access to protected areas like
the administrator portal. It is also possible to delete user data from the tables.

Nowadays, all online shopping applications and bank transactions use back-end database
servers. So in case the hacker is able to exploit SQL injection, the entire server is compromised.

Preventing SQL Injection

● User Authentication: Validating input from the user by pre-defining length, type of input,
of the input field and authenticating the user.
● Restricting access privileges of users and defining how much amount of data any
outsider can access from the database. Basically, users should not be granted
permission to access everything in the database.
● Do not use system administrator accounts.

SQL in Web Pages

SQL injection typically occurs when you ask a user for input, such as their username/user ID,
instead of their name/ID, and the user gives you an SQL statement that you execute without the
knowledge about your database.

txtUserId = getRequestString("UserId");

txtSQL = "SELECT * FROM Users

WHERE UserId = " + txtUserId;

SQL Injection Based on Batched SQL Statements

 1. Most databases guide batch SQL statements.
2. A batch of SQL statements is a collection of two or more square statements separated
by using semicolons.

The SQL declaration underneath will return all rows from the “users” desk after which delete the
“Employees ” table.

Query:

SELECT * FROM Users;

DROP TABLE Employees

Look at the following example:

Syntax:

txtEmpId = getRequestString("EmpId");

txtSQL = "SELECT * FROM Users

WHERE EmpId = " + txtEmpId;

The valid SQL statement would look like this:

Query:

SELECT * FROM Users WHERE EmpId = 116;

DROP TABLE Employees;

Usefull Links
Difference between Natural join and Cross join Self Join and Cross Join in MS SQL Server
in SQL

Difference between Natural join and Inner Join Difference between Inner Join and Outer
in SQL Join in SQL

SQL Injection – FAQs

1. What is SQL injection?

SQL injection is a technique used to extract user data by injecting web page inputs
as statements through SQL commands. It allows malicious users to manipulate a
web application’s web server by injecting malicious code into SQL statements via
web page inputs.

2. How common is SQL injection as a hacking technique?

SQL injection is one of the most common web hacking techniques, posing a
significant threat to web applications and databases.

3. How does SQL injection exploit web applications?

Web servers communicate with database servers to retrieve or store user data.
Attackers craft SQL statements that can execute while the web server fetches
content from the application server, compromising the security of the web
application.

4. Can you provide an example of SQL injection?

Certainly. Let’s say there’s an application for student records. An attacker enters
“12222345 or 1=1” into a student ID field, which modifies the SQL query to retrieve
all student records. This compromises all student data. Similar manipulations can
delete records or gain unauthorized access to data.

5. What are the impacts of SQL injection?

The impact can be severe. Attackers can retrieve user data such as details, credit
card information, and social security numbers, as well as access protected areas
like administrator portals. It’s also possible to delete user data. If successful, the
entire server can be compromised.

6. How can SQL injection be prevented?

 To prevent SQL injection, you should:

● Use user authentication to validate input and define input field

characteristics.
● Restrict user access privileges to limit database access.
● Avoid using system administrator accounts.
● For more details, refer to the “How to Protect Against SQL Injection
Attacks?” article.

7. When does SQL injection typically occur in web applications?

SQL injection typically occurs when a user provides input like a username or user
ID, and the application executes it as an SQL statement without proper validation or
knowledge of the database structure.