Common Injection Attacks and countermeasures

1. INJECTION ATTACKS
ADAMU MUHAMMAD, NIGERIAN DEFENCE ACADEMY.
NOVEMBER,2021

2. ABSTRACT
Web applications typically interact with a back-end database to retrieve persistent data and then present
the data to users as dynamically generated output, such as HTML web pages. This interaction is usually
done by means of low-level Application Programming Interface (API) by dynamically constructing a query
string within general purpose programming languages such as java. This interaction does not take account
of the output language and treats inputs as isolated lexical entities which if not sanitized can render the
application vulnerable to Injection Attacks which make the application generate unintended outputs. This
study provides an understanding of common injection attacks taking account of the mechanisms of the
attacks and prevention mechanisms to minimize their occurrence and impact.

3. INTRODUCTION
Injection attacks involve attackers supplying or injecting untrusted inputs to web applications. The input
then gets processed by an interpreter as part of a command or query ultimately altering the program's
execution. Injections are amongst the oldest and most dangerous attacks aimed at web applications. They
can lead to data theft, data loss, loss of data integrity, denial of service, as well as full system compromise.
The primary reason for injection vulnerabilities is usually insufficient user input validation (Muscat I,
2019).
What makes injection vulnerabilities particularly scary is that the attack surface is enormous (especially for
cross-site scripting (XSS) and SQL Injection vulnerabilities). Furthermore, injection attacks are a very well
understood vulnerability class. This means that there are many freely available and reliable tools that allow
even inexperienced attackers to abuse these vulnerabilities automatically.
BACKGROUND ON INJECTION ATTACKS
Injection attacks pose a serious security threat to Web applications: they allow attackers to obtain
unrestricted access to the underlying applications and to the potentially sensitive information these
applications contain and process. Intuitively, an Injection Attack occurs when an attacker changes the
intended effect of a script or query by inserting new keywords or operators into the script or query.
INJECTION MECHANISMS
Injection through user input
Suitably crafted user inputs are used in this case. The way a web application handles user inputs vary with
the application's environment. A common method is from form's submissions sent to the web application
via HTTP GET or POST methods. Web applications are generally able to access the user input contained
in these requests as they would access any other variable in the environment.
Injection through cookies
Cookies are files that contain state information generated by Web applications and stored on the client
machine. When a client returns to a Web application, cookies can be used to restore the client’s state
information. Since the client has control over the storage of the cookie, a malicious client could tamper with
the cookie’s contents. If a Web application uses the cookie’s contents, an attacker could easily submit an
attack by embedding it in the cookie.
Injection through server variables

4. Server variables are a collection of variables that contain HTTP, network headers, and environmental
variables. Web applications use these server variables in a variety of ways, such as logging usage statistics
and identifying browsing trends. If these variables are logged to a web server without sanitization, this
could create an injection vulnerability. Because attackers can forge the values that are placed in HTTP and
network headers, they can exploit this vulnerability by placing scripts directly into the headers. When the
method to log the server is executed, the attack in the forged header is triggered.
Second-order injection
In second-order injections, the attacker plants malicious inputs into a system or database to indirectly trigger
an injection attack when that input is used at a later time. The objective of this kind of attack differs
significantly from a regular (i.e., first-order) injection attack. Second-order injections are not trying to cause
the attack to occur when the malicious input initially reaches the system. Instead, attackers rely on
knowledge of where the input will be subsequently used and craft their attack so that it occurs during that
usage.
COMMON INJECTION ATTACKS, THEIR VULNERABILITIES & POSSIBLE
TARGETS
Injection attacks are classified into various categories as below:
Code Injection:
Code injection is one of the most common types of injection attacks. These types of attacks are possible on
the application that lacks input data validation. This attack introduces a malicious code into the application,
which 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. A code injection
to any application can lead to a full system compromise, causing a Plague to the system.
SQL Injection:
This type of injection refers to an attack where the attacker executes a malicious Payload (malicious SQL
statements) that control a web application database server. This is one of the oldest vulnerabilities as all the
websites or web applications use SQL-based databases. By leveraging SQL Injection vulnerability, given
the right circumstances, an attacker can use it to bypass a web application’s authentication and authorization
mechanisms and retrieve the contents of an entire database.

5. SQL Injection can also be used to add, modify and delete records in a database, affecting data integrity.
Effects of SQL Injections are Authentication Bypass, Information Disclosure, Data Loss, Data theft, and
Data Integrity loss, Denial of service and at times System Compromise.
Cross-site scripting (XSS):
In a Cross-site scripting attack, malicious scripts are injected into a web page, and are executed when that
page is visited by a user. XSS attacks occur when an attacker uses a web application to send malicious code,
generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to
succeed are quite widespread and occur anywhere a web application uses input from a user within the output
it generates without validating or encoding it.
XPath Injection:
This is similar to SQL injection attacks; XPath Injections attack is possible when a web application uses
information provided by a user to build an XPath query for XML data. An attacker can enquire detailed
information on how the XML data is structured, or access data that is not normally accessible by sending
malformed information to the website. Apart from this, these vulnerabilities can also elevate the attacker’s
privileges on the web site if the XML data is being used for authentication (such as an XML based user
file).
Template Injection:
In this type of Injection attack, the attacker submits malicious code that is executed when the application
takes user-supplied input and transforms it into a file according to a template, such as generating a custom
welcome page for a new user.
CRLF Injection:
The term CRLF signifies, carriage return Line feed, usually denoting termination of a Line. A CRLF
Injection attack occurs when a user manages to submit a CRLF into an application which is most commonly
done by modifying an HTTP parameter or URL. CRLF injection is a software application coding
vulnerability that occurs when an attacker injects a CRLF character sequence where it is not expected.
When CRLF injection is used to split an HTTP response header, it is referred to as HTTP Response
Splitting. CRLF injection vulnerabilities result from data input that is not neutralized, incorrectly
neutralized or otherwise un-sanitized.
Email header injection:

6. Most of the time a contact form sends SMTP headers such as From and Reply-to to make it easy for the
recipient to treat communication from the contact form just like they would any other email rather than
sending email to an intended recipient of the message by a legitimate user. Unless the user’s input is
validated before being inserted into SMTP headers, the contact form might be vulnerable to Email Header
Injection (also referred to as SMTP header injection). This is because an attacker may be able to inject
additional headers into the message, thereby instructing the SMTP server to carry out different instructions
than intended. Such attacks usually lead to Information disclosure and Spam Relay.
Host Header Injection:
The host header specifies which website or web application should process an incoming HTTP request and
the web server uses the value of this header to dispatch the request to the specified website or web
application. As a common practice of hosting several websites and web applications on the same IP address,
most web servers are configured to pass the unrecognized host header to the first virtual host in the list.
Therefore, it’s possible to send requests with arbitrary host headers to the first virtual host. Another way to
pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations this header will
rewrite the value of the Host header. Manipulation of the host header is commonly related to PHP
applications, although it can also be done with other web development technologies. Host header attacks
work as enablers for other typical types of attacks. Such as web-cache poisoning. Its consequences could
include the execution of sensitive operations by the attackers, for example, password resets.
LDAP Injection:
Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and
manipulating X.500 directory services. The root problem that allows for LDAP injection attacks is
improperly validated user input. An attacker alters the construction of an LDAP statement, when a web
application fails to properly sanitize user-supplied input. When an attacker is able to modify an LDAP
statement, the process will run with the same permissions as the component that executed the command.
(E.g., Database server, Web application server, Web server, etc.). This can cause serious security problems
where the permissions grant the rights to query, modify or remove anything inside the LDAP tree. The
same advanced exploitation techniques available in SQL Injection can also be similarly applied in LDAP
Injection. These injections target authentication bypass and privilege escalation.
OS command injection:

7. OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker
to execute arbitrary operating system (OS) commands on the server that is running an application, and
typically fully compromise the application and all its data. Very often, an attacker can leverage an OS
command injection vulnerability to compromise other parts of the hosting infrastructure, exploiting trust
relationships to pivot the attack to other systems within the organization. These attacks can be prevented
by a system administrator, by limiting the system access level of the web applications running on a server.
COUNTERMEASURES TO INJECTION ATTACKS
Validate User Inputs
A common first step to preventing SQL injection attacks is validating user inputs. First, identify
the essential SQL statements and establish a whitelist for all valid SQL statements, leaving
unvalidated statements out of the query. This process is known as input validation or query
redesign.
Additionally, you should configure inputs for user data by context. For example, input fields for
email addresses can be filtered to allow only the characters in an email address, such as a required
“@” character. Similarly, phone numbers and social security numbers should only be filtered to
allow the specific number of digits for each.
While this action alone won’t stop SQLi attackers, it is an added barrier to a common fact-finding
tactic for SQL injection attacks.

8. Sanitize Data by Limiting Special Characters
Another component of safeguarding against SQL injection attacks is mitigating inadequate data
sanitization. Because SQLi attackers can use unique character sequences to take advantage of a
database, sanitizing data not to allow string concatenation is critical.
One way of doing this is configuring user inputs to a function such as MySQL’s
mysql_real_escape_string(). Doing this can ensure that any dangerous characters such as a single
quote is not passed to a SQL query as instruction. A primary method of avoiding these
unauthenticated queries is the use of prepared statements.
Enforce Prepared Statements and Parameterization
Sadly, input validation and data sanitization aren’t fix-all. It’s critical organizations also use
prepared statements with parameterized queries, also known as variable binding, for writing all
database queries. By defining all SQL code involved with queries, or parameterization, you can
distinguish between user input and code.
While dynamic SQL as a coding technique can offer more flexible application development, it can
also mean SQLi vulnerabilities as accepted code instructions. By sticking with standard SQL, the
database will treat malicious SQL statements inputted like data and not as a potential command.
Use Stored Procedures in The Database
Similar to parameterization, using stored procedures also requires variable binding. Unlike the
prepared statements approach to mitigating SQLi, stored procedures reside in the database and are
called from the web application. Stored procedures are also not immune to vulnerabilities if
dynamic SQL generation is used.
Organizations like OWASP say only one of the parameterized approaches is necessary, but neither
method is enough for optimal security. Crafting parameterized queries should be done in
conjunction with our other recommendations.

9. Actively Manage Patches and Updates
Vulnerabilities in applications and databases that are exploitable using SQL injection are regularly
discovered and publicly identified. Like so many cybersecurity threats, its vital organizations stay
in tune with the most recent news and apply patches and updates as soon as practical. For SQLi
purposes, this means keeping all web application software components, including database server
software, frameworks, libraries, plug-ins, and web server software, up to date.
If your organization struggles to consistently patch and update programs, a patch management
solution might be worth the investment.
Raise Virtual or Physical Firewalls
We strongly recommend using a software or appliance-based web application firewall (WAF) to
help filter out malicious data.
Firewalls today, including NGFW and FWaaS offerings, have both a comprehensive set of default
rules and the ease to change configurations as needed. If a patch or update has yet to be released,
WAFs can be handy.
A popular example is the free, open-source module ModSecurity, available for Apache, Microsoft
IIS, and nginx web servers. ModSecurity provides a sophisticated and ever-evolving set of rules
to filter potentially dangerous web requests. Its SQL injection defenses can catch most attempts to
sneak SQL through web channels.
Harden Your OS And Applications
This step goes beyond mitigating SQL injection attacks in ensuring your entire physical and virtual
framework is working intentionally. With the big news of supply chain compromises in 2020,
many are looking to NIST and other industry-standard security checklists to harden operating
systems and applications.
Adopting application vendor security guidelines can enhance an organization’s defensive posture
and help identify and disable unnecessary applications and servers.

10. Reduce Your Attack Surface
In cybersecurity, an attack surface refers to the array of potential entry points for attackers. So, in
the context of SQLi attacks, this means disposing of any database functionalities that you don’t
need or further safeguarding them.
One such example is the xp_cmdshell extended stored procedure in the Microsoft SQL Server.
This procedure can spawn a Windows command shell and pass a string for execution. Because the
Windows process generated by xp_cmdshell has the same security privileges as the SQL Server
service account, the attacker can cause severe damage.
Establish Appropriate Privileges and Strict Access
Given the power SQL database holds for an organization, it’s imperative to enforce least privilege
access policies with strict rules. If a website only requires the use of SELECT statements for a
database, there’s no reason it should have additional INSERT, UPDATE, or DELETE privileges.
Further, your database should only be accessed with admin-level privileges when necessary, never
mind granting others access. Using a limited access account is far safer for general activity and
ultimately limits an attacker’s access if the less-privileged credential is compromised.
Limit Read-Access
Connected to the principle of least privilege for SQL injection protection is configuring read-
access to the database. If your organization only requires active users employing read-access, it’s
undoubtedly easier to adopt. Nevertheless, this added step is imperative for stopping attackers from
altering stored information.
Encryption: Keep Your Secrets Secret
It’s best to assume internet-connected applications are not secure. Therefore encryption and
hashing passwords, confidential data, and connection strings are of the utmost importance.
Encryption is almost universally employed as a data protection technique today and for a good
reason. Without appropriate encryption and hashing policies, sensitive information could be in
plain sight for an intruder. While only a part of the security checklist, Microsoft notes encryption,
“transforms the problem of protecting data into a problem of protecting cryptographic keys.”

11. Deny Extended URls
Another tactic by SQLi attackers is sending excessively long URLs causing the server to fail at
logging the complete request. In 2013, eSecurityPlanet reported on how attackers exploited Foxit
by sending users long URLs that would trigger a stack-based buffer overflow.
Microsoft IIS, as another example, is built to process requests over 4096 bytes long. However, the
web server software fails to place the contents of the request in the log files. Attackers can then go
undetected while performing queries. To avoid this, set a limit of 2048 bytes for URLs.
Don’t Divulge More Than Necessary in Error Messages
SQL injection attackers can learn a great deal about database architecture from error messages,
ensuring that they display minimal information. Use of the “RemoteOnly” customErrors mode (or
equivalent) can display verbose error messages on the local machine while ensuring that an
external attacker gets nothing more than the fact that his or her actions resulted in an unhandled
error. This step is critical in safeguarding the organization’s internal database structure, table
names, or account names.
No Shared Databases or User Accounts
Shared databases by multiple websites or applications can be a recipe for disaster. And the same
is true for user accounts that have access to various web applications. This shared access might
provide flexibility for the managing organization or administrator, but it also unnecessarily poses
a more significant risk.
Ideally, any linked servers have minimal access to the target server and can only access the
mission-critical data. Linked servers should have distinct logins from any process on the target
server.
Enforce Best Practices for Account and Password Policies
While it might go without saying, organizations must follow the best account and password
policies for fool proof security. Default and built-in passwords should be changed upon receipt
and before usage, with regularly scheduled password updates. Suitable passwords in length and
character complexity are essential for all SQL server administrator, user, and machine accounts.

12. Continuous Monitoring of SQL Statements
Organizations or third-party vendors should continually monitor all SQL statements of database-
connected applications for an application, including documenting all database accounts, prepared
statements, and stored procedures. With visibility into how SQL statement’s function, it’s much
easier to identify rogue SQL statements and vulnerabilities. In this continued review, admins can
delete and disable unnecessary accounts, prepared statements, and stored procedures.
Monitoring tools that utilize machine learning and behavioural analysis like PAM and SIEM can
be excellent add-ons to your network security.
Perform Regular Auditing and Penetration Testing
Regular audits of your database and application security are becoming increasingly necessary,
including auditing logs for suspicious activity, group and role memberships privileges, and
variable binding terms.
Just as crucial as auditing for malicious behaviour is conducting penetration tests to see how your
defences respond to an array of potential attacks, including SQLi. Most penetrating testing
companies can find threats such as cross-site scripting, retired software, unpatched vulnerabilities,
injections, and insecure passwords.
Code Development & Buying Better Software
In the vast market of software solutions, there’s certainly a hierarchy of solutions. While enterprise
organizations can cover the cost of expensive third-party solutions and might even develop the
software further in-house, smaller organizations rightfully work with less or consider free, open-
source tools.
Though, to a great extent, vendor code writers are ultimately responsible for flaws in custom
applications for a client. Organizations considering vendors must be keen on this and ensure the
contract terms reflect this code review duty.

13. REFERENCES
Gaurav S. K, Keromytis A. D & Prevelakis V.(2003). Countering code-injection attacks with
instruction-set randomization. CCS '03: Proceedings of the 10th ACM conference on
Computer and communications security. https://doi.org/10.1145/948109.948146
Halfond W.G.J, Viegas J. & Orso A.A Classification of SQL Injection Attacks
and Countermeasures. Georgia Institute of Technology.
LLC, L. (2020, April 24). Injection Attacks Explained. LIFARS, Your Cyber Resiliency Partner.
https://lifars.com/2020/04/injection-attacks-explained/
Muscat I (2019). "What are injection attacks?". Acunetix.
https://www.acunetix.com/blog/articles/injection-attacks/
Rubens P. (2021). How to prevent SQL injection attacks. Esecurityplanet
https://www.esecurityplanet.com/threats/how-to-prevesnt-sql-injection-attacks/
9 Popular Web Application Injection Attack Types. (2020, February 10). Geekflare.
https://geekflare.com/web-application-injection-attacks/