ADVANCED PROGRAMMING COURSE WORK 3
Cross-site Scripting
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into
trusted websites. 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. (OWASP-KirstenS)
Programming 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.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser
has no way to know that the script should not be trusted, and will execute the script. Because it
thinks the script came from a trusted source, the malicious script can access any cookies, session
tokens, or other sensitive information retained by the browser and used with that site. These scripts
can even rewrite the content of the HTML page.
Types of Cross-Site Scripting.
1. Server XSS
Server XSS occurs when untrusted user supplied data is included in an HTTP response generated by
the server. The source of this data could be from the request, or from a stored location. As such, you
can have both Reflected Server XSS and Stored Server XSS.
In this case, the entire vulnerability is in server-side code, and the browser is simply rendering the
response and executing any valid script embedded in it.
2. Client XSS
Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe
JavaScript call. A JavaScript call is considered unsafe if it can be used to introduce valid JavaScript
into the DOM. This source of this data could be from the DOM, or it could have been sent by the
server (via an AJAX call, or a page load).
Example:
The most common example can be found in bulletin-board websites which provide web based
mailing list-style functionality.
The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to
the user.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
The code in this example operates correctly if eid contains only standard alphanumeric text. If eid
has a value that includes meta-characters or source code, then the code will be executed by the web
browser as it displays the HTTP response.
The danger is that an attacker will create the malicious URL, then use e-mail or social engineering
tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly
reflect the malicious content through the vulnerable web application back to their own computers.
This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
OS command Injection.
The software constructs all or part of an OS command using externally-influenced input from an
upstream component, but it does not neutralize or incorrectly neutralizes special elements that
could modify the intended OS command when it is sent to a downstream component.
(cwe.mitre.org, 2006). This could allow attackers to execute unexpected, dangerous commands
directly on the operating system. This weakness can lead to a vulnerability in environments in which
the attacker does not have direct access to the operating system, such as in web applications.
Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify
commands that normally would not be accessible, or to call alternate commands with privileges that
the attacker does not have.
Examples:
The following simple program accepts a filename as a command line argument and displays the
contents of the file back to the user. The program is installed setuid root because it is intended for
use as a learning tool to allow system administrators in-training to inspect privileged system files
without giving them the ability to modify them or damage the system.
Example Language: C
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}
Cross-site Request Forgery (CSRF).
When a web server is designed to receive a request from a client without any mechanism for
verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into
making an unintentional request to the web server which will be treated as an authentic request.
This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or
unintended code execution. (OWASP, 2022)
Example:
Alice wishes to transfer $100 to Bob using the bank.com web application that is vulnerable to CSRF.
Maria, an attacker, wants to trick Alice into sending the money to Maria instead. The attack will
comprise the following steps:
Building an exploit URL or script
Tricking Alice into executing the action with Social Engineering
GET scenario
If the application was designed to primarily use GET requests to transfer parameters and execute
actions, the money transfer operation might be reduced to a request like:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Maria now decides to exploit this web application vulnerability using Alice as the victim. Maria first
constructs the following exploit URL which will transfer $100,000 from Alice’s account to Maria’s
account. Maria takes the original command URL and replaces the beneficiary name with herself,
raising the transfer amount significantly at the same time:
http://bank.com/transfer.do?acct=MARIA&amount=100000
SQL Injection.
Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL
query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be
used to alter query logic to bypass security checks, or to insert additional statements that modify the
back-end database, possibly including execution of system commands. (cwe.mitre.org, 2022)
SQL injection has become a common issue with database-driven web sites. The flaw is easily
detected, and easily exploited, and as such, any site or software package with even a minimal user
base is likely to be subject to an attempted attack of this kind. This flaw depends on the fact that SQL
makes no real distinction between the control and data planes.
SQL injection attack occurs when:
 An unintended data enters a program from an untrusted source.
 The data is used to dynamically construct a SQL query
The main consequences are:
 Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a
frequent problem with SQL Injection vulnerabilities.
 Authentication: If poor SQL commands are used to check user names and passwords, it may
be possible to connect to a system as another user with no previous knowledge of the
password.
 Authorization: If authorization information is held in a SQL database, it may be possible to
change this information through the successful exploitation of a SQL Injection vulnerability.
 Integrity: Just as it may be possible to read sensitive information, it is also possible to make
changes or even delete this information with a SQL Injection attack.
Risk Factors
The platform affected can be:
Language: SQL
Platform: Any (requires interaction with a SQL database).
Example.
This example examines the effects of a different malicious value passed to the query constructed
and executed in the previous example.
If an attacker with the user name wiley enters the string
name'; DELETE FROM items; -for itemName, then the query becomes the following two queries:
Example Language: SQL
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name';
DELETE FROM items;
--'
Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions
in performing authentication. The adversary is able to steal or manipulate an active session and use
it to gain unathorized access to the application. (CAPEC(Common Attack Pattern Enumeration and
Classification), 2021; CAPEC(Common Attack Pattern Enumeration and Classification), 2021)
Such a scenario is commonly observed when:
A web application authenticates a user without first invalidating the existing session, thereby
continuing to use the session already associated with the user.
An attacker is able to force a known session identifier on a user so that, once the user authenticates,
the attacker has access to the authenticated session.
The application or container uses predictable session identifiers. In the generic exploit of session
fixation vulnerabilities, an attacker creates a new session on a web application and records the
associated session identifier. The attacker then causes the victim to associate, and possibly
authenticate, against the server using that session identifier, giving the attacker access to the user's
account through the active session.
The session token could be compromised in different ways; the most common are:





Predictable session token;
Session Sniffing;
Client-side attacks (XSS, malicious JavaScript Codes, Trojans, etc);
Man-in-the-middle attack
Man-in-the-browser attack
Example:
The following example shows a snippet of code from a J2EE web application where the application
authenticates users with a direct post to the <code>j_security_check</code>, which typically does
not invalidate the existing session before processing the login request.
Example Language: HTML
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password">
</form>
Mitigation against OS Command Injection
Architecture and Design: If at all possible, use library calls rather than external processes to recreate
the desired functionality.
 Run your code in a "jail" or similar sandbox environment that enforces strict boundaries
between the process and the operating system. This may effectively restrict which
commands can be executed by your software.
Examples include the Unix chroot jail and AppArmor. In general, managed code may provide
some protection.
This may not be a feasible solution, and it only limits the impact to the operating system; the
rest of your application may still be subject to compromise.

For any data that will be used to generate a command to be executed, keep as much of that
data out of external control as possible. For example, in web applications, this may require
storing the command locally in the session's state instead of sending it out to the client in a
hidden form field.
 Use languages, libraries, or frameworks that make it easier to generate properly encoded
output.
Examples include the ESAPI Encoding control.
Implementation: Properly quote arguments and escape any special characters within those
arguments. If some special characters are still needed, wrap the arguments in quotes, and escape all
other characters that do not pass a strict whitelist. Be careful of argument injection (CWE-88).
 If the program to be executed allows arguments to be specified within an input file or from
standard input, then consider using that mode to pass arguments instead of the command
line.
 If available, use structured mechanisms that automatically enforce the separation between
data and code. These mechanisms may be able to provide the relevant quoting, encoding,
and validation automatically, instead of relying on the developer to provide this capability at
every point where output is generated.
Mitigation against CSRF



Add a per-request nonce to the URL and all forms in addition to the standard session. This is
also referred to as “form keys”. Many frameworks (e.g., Drupal.org 4.7.4+) either have or are
starting to include this type of protection “built-in” to every form so the programmer does
not need to code this protection manually.
Add a hash (session id, function name, server-side secret) to all forms.
For .NET, add a session identifier to ViewState with MAC (described in detail in the DotNet
Security Cheat Sheet).
Checking the referrer header in the client’s HTTP request can prevent CSRF attacks. Ensuring
that the HTTP request has come from the original site means that attacks from other sites
will not function. It is very common to see referrer header checks used on embedded
network hardware due to memory limitations.
Mitigation against XSS





Proper validation of all input should be performed to prevent this type of attack. This
involves identifying all user-supplied input and testing all output.
Use r web vulnerability scanner such as Netsparker and Acunetix Web Vulnerability Scanner
to find XSS.
Never present static values that the web browser and the user don’t need to see. Instead,
this data should be implemented within the web application on the server side and retrieved
from a database only when needed.
5 Filter out <script> tags from input fields
Disable detailed web server and database-related error massages if possible.
Mitigation against SQL Injection.



Use proper input validation.
Use blacklisting or whitelisting of special characters.
Use parameterized queries in ASP.Net and prepared statements in Java to perform escaping
of dangerous characters before the SQL statement is passed to the database.

Use Web Access Fire Walls(WAFS) which applies rules set to an HTTP Conversation. It can be
implemented as an appliance or as a server plug-in.
Mitigation against Session Hijacking

Encode heuristic information, such as IP addresses, into session IDs. (Charles P .Pfleeger,
Shari Lawrence Pfleeger, 2015)
 Use Secure Session Module. It modifies each session ID by appending a hash to the ID. The
hash or MAC is generated from the session ID, the network portion of the IP address, the
User Agent header in the request, and a secret key stored on the server. Secure Session
Module uses this value to validate each request for a session cookie.
 Use proper input validation.
 Block NetBIOS on your Windows server by preventing these TCP ports from passing through
your network firewall or personal firewall:
 139 (NetBIOS sessions services)
 445 (runs SMB over TCP/IP without NetBIOS)
 Disable File and Printer Sharing for Microsoft Networks in the Properties tab of the
machine’s network connection for those systems that don’t need it.
References
CAPEC(Common Attack Pattern Enumeration and Classification). (2021, OCTOBER 21). CAPEC-593:
Session Hijacking. United states of America. Retrieved June 08, 2022 from
https://capec.mitre.org/data/definitions/593.html
Charles P .Pfleeger, Shari Lawrence Pfleeger. (2015). Security In Computing Fifth Edition. Prentice
Hall. Retrieved June 08, 2022
cwe.mitre.org. (2006, June 22). CWE-78: Improper Neutralization of Special Elements used in an OS
Command ('OS Command Injection'). United states of America. From
https://cwe.mitre.org/data/definitions/78.html
cwe.mitre.org. (2022, June 08). CWE-89: Improper Neutralization of Special Elements used in an SQL
Command ('SQL Injection'). United states of America. From
https://cwe.mitre.org/data/definitions/89.html
OWASP. (2022, August 25). Cross Site Request Forgery (CSRF). United Kingdom. From
https://owasp.org/www-community/attacks/csrf
OWASP-KirstenS. (n.d.). Cross Site Scripting (XSS). United States of America. Retrieved June 08, 2022
from https://owasp.org/www-community/attacks/xss/