Challenge: Injecting HTML code onto the given applications.
Target: Locally hosted web application over Apache Web Server and IIS Web Server.
Topic: Create Web Application and Inject HTML code into the web-page code context.
Hack: The primary objective of this topic and the challenges is to create a sample web application both
on PHP and on ASP to show how client side injections are possible with insecure coding practices. In this
document, I will also demonstrate here how to properly audit the code to look for client side injections
and apply ‘validation’ to the code in order to prevent client side injection attacks. When we talk about
Injection attacks, there are different categories to which we might classify these ‘attacks’ as.
A very deep perspective to classify ‘injection’ attacks could be classified in accordance to the following
a) Client Side Injection Attacks
b) Server Side Injection Attacks
This document specifies ‘server side code injection’ attacks and its one variant which is ‘HTML Injection’.
Similarly, there are numerous other variants of this same classification such as Persistent Cross Site
Scripting Attacks, Non-persistent Cross Site Scripting Attacks, DOM-based Cross Site Scripting Attacks,
BHO (Browser Helper Objects) Injection and much more. Since this document is scoped for HTML
Injection which is yet to follow, the attack payload documented here are directed and intended towards
changing web page presentation via manipulating the client side HTML code. This is something which
was not originally intended by the web-developers, and hence a ‘hack’ of its kind.
Server Side Injection Attacks could be SQL Injection, LDAP Injection, XML Injection, JSON Injection or
code ‘injections’ which affect the ‘data-tier’ discussed in my other document very briefly and involves
server side processing of the payload. Such attacks which could also lead to ‘data exfiltration’ are
termed as ‘Server Side Injection Attacks’. There are much more than these variants. The concept is that
these server side injection attacks occur due to user input being trusted and hence not properly
checking the inputs or sanitizing and then validating them. It’s not about only ‘input sanitization’ but
also ‘output validation’ and integrity checks. This would be later demonstrated in other documents
which talk about ‘Server Side Injection’. This document goes through HTML Injection which is processed
by a ‘server’ and then the malicious ‘payload’ leads to a ‘code injection’ which is caught by the user
agent being used which are primarily the browsers. Since the data which is input is from the user, and
this data is taken for further processing by the server, the interpreted final result of the payload can
differ and hence be represented by the browsers in a different way and lead to unintentional rendering
of content which was originally not intended by the web developers. All of the user input is went
through server side processing and the browser interpreter is hence involved. The browser interpreter
could be different depending upon the browser engine, which could be ‘Webkit’, ‘Gecko’ or ‘Presto’ to
name a few of them. Other user-agents have their own engine and might had been named.
All of these could be a sub-class of ‘Interpreter Injection’ because both ‘client side injection’ and ‘server
side injection’ use ‘interpreters’ to deploy attacks based on that particular ‘interpreter’. If someone who
reads this document has no previous idea on what ‘interpreters’ are in computer terms, refer here to
read more. We are not talking about specific targeted ‘interpreter’ injection attack yet but barely
scratching the surface of ‘injection’ attacks which possibly might be on the client side or server side.
Based on what payload are performed by an attacker and on which ‘interpreter’ which parses this
payload, the repercussions of such an attack variant is termed as ‘Interpreter Injection Attacks’.
Somehow, both client side injection attacks and server side injection attacks use ‘interpreters’, and
hence are sub-sets of ‘Interpreter Injection Attacks’.
This paper is about ‘code injection’ which occurs after being processed by various server technologies
such as PHP and ASP and others such as API’s, and Python based API. Because the processing is done by
the server, all of the HTML Injection listed here are server side HTML Injection rather than ‘Client Side
Code Injection’ attacks. A client side Injection attack would differ from a server side injection attack and
has more subsets like Cross Site Scripting attacks which again has ‘persistent’, ‘non-persistent’ or DOMBased.
All of such Cross Site Injections could be both client side and server side depending upon the
‘processing’ of the user input data. The ‘processing’ determines if a ‘code injection’ or any other attack
variants are client side or server side. It’s very important that the concept of server side attack and client
side attack is dealt with before I make the reader go through the actual demonstrations. So in a very
straight way, we have two types of ‘Injection Attacks’, the one I had documented here is termed ‘Code
Injection’ attacks which leads to HTML Injection, the two types are:
1. Server Side Code Injection Attacks
2. Client Side Code Injection Attacks
Any ‘Server Side Code Injection’ attack requires user input data to be processed by the server and then
accordingly prepare the HTML response which the user in his/her browser could render. The HTML is
rendered by the browser interpreter but the processing was done by the server, and hence it is server
side code injection attack rather than client side code injection attack.
In contrary to server side code injection attacks, there is yet another variant of ‘Interpreter Injection’
is a script ‘code’ here which is being injected into the client side script and no processing from the server
is necessary and hence termed as ‘Client Side Code Injection’ attacks rather than server side code
because these attacks are generated by manipulating the ‘scripts’ at client side. But this does not mean
generate an equivalent rendering which means the HTML web-page is generated by the server and
hence leads to ‘Server XSS’. And therefore we have two sets ‘Server XSS’ and ‘Client XSS’. The paper
introduces to server side code injection leading to HTML Injection by web-pages getting maintained by
the web-server rather than the client side. The client side rendering engine however uses its own
interpreter to render the HTML page served by the web-server. Abstract of this document is defined.