SECURE PROGRAMMING
A.A. 2018/2019
SQL INJECTION
SQL INJECTION
SQL injection is a code injection technique, used to
attack data-driven applications, in which nefarious SQL statements are inserted into an entry field for execution
üexploit can read sensitive data from the database,
ümodify database data (Insert/Update/Delete) e.g. voiding transactions or changing balances,
üexecute administration operations on the database (such as shutdown the DBMS),
ürecover the content of a given file present on the DBMS file system (or dump the database contents to the attacker)
üdestroy the database
üin some cases issue commands to the operating system.
SQL INJECTION
SQL Injection is very common with PHP and ASP
(abbandonato) applications due to the prevalence of older functional interfaces.
Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections.
DESCRIPTION
SQL injection errors occur when:
üData enters a program from an untrusted source.
üThe data 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)
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.
Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before.
üThis flaw depends on the fact that SQL makes no real distinction between the control and data planes.
EXAMPLE 1
In SQL:
select id, firstname, lastname from authors where fistname = $input1 and lastname = $input2
$input1: evil'ex
$input2: Newman
The query becomes:
select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'
Incorrect syntax near il' as the database tried to execute evil.
EXAMPLE 2
In C#
...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = "'" + userName + "' AND itemname = '" + ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt); ...
SELECT * FROM items WHERE owner =
AND itemname = ;
if an attacker with the user name wiley enters the string name' OR 'a'='a
SELECT * FROM items WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';
SELECT * FROM items;
EXAMPLE 3
If an attacker with the user name hacker enters the string "name'); DELETE FROM items; --"
SELECT * FROM items WHERE owner = 'hacker' AND itemname = 'name';
DELETE FROM items;
--'
Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch- execution of statements separated by semicolons
OTHER EXAMPLES
http://www.unixwiz.net/techtips/sql-injection.html
https://www.cs.montana.edu/courses/csci476/topics/sql_i njection.pdf
MITIGATION
One traditional approach to preventing SQL injection
attacks is to handle them as an input validation problem and
üeither accept only characters from a whitelist of safe values üor identify and escape a blacklist of potentially malicious
values.
OWASP prevention cheat sheet (4 ways to protect)
ühttps://github.com/OWASP/CheatSheetSeries/blob/master/c heatsheets/SQL_Injection_Prevention_Cheat_Sheet.md
REFERENCES
The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software.
Wiki at
ühttps://www.owasp.org/index.php/Main_Page
DEFENSE OPTION 1: PREPARED STATEMENTS The use of prepared statements with variable binding
(aka parameterized queries) is how all developers should first be taught how to write database queries.
Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later.
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker.
DEFENSE OPTION 1
Java EE – use PreparedStatement() with bind variables
.NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
PHP – use PDO with strongly typed parameterized queries (using bindParam())
Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
SQLite - use sqlite3_prepare() to create a statement object
DEFENSE OPTION 1
String custname = request.getParameter("customerName"); // This should REALLY be validated too
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );
OTHER EXAMPLE WITH ASP
ASP NET
Note that parameters are represented in the SQL statement by a @ marker.
The SQL engine checks each parameter to ensure that it is correct for its column and are treated literally, and not as part of the SQL to be executed.
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = @0";
db.Execute(txtSQL,txtUserId);
STILL ASP
One more example
txtNam = getRequestString("CustomerName");
txtAdd = getRequestString("Address");
txtCit = getRequestString("City");
txtSQL = "INSERT INTO Customers
(CustomerName,Address,City) Values(@0,@1,@2)";
db.Execute(txtSQL,txtNam,txtAdd,txtCit);
DEFENSE OPTION 2: STORED PROCEDURE
SQL code for a stored procedure is defined and stored in the database itself, and then called from the application The following code example uses a CallableStatement, Java's implementation of the stored procedure interface
String custname = request.getParameter("customerName");
try { CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}"); cs.setString(1, custname);
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) { // … logging and error handling
DEFENSE OPTION 3: WHITE LIST INPUT VALIDATION
Parameter values should be mapped to the
legal/expected table or column names to make sure unvalidated user input doesn't end up in the query
String tableName;
switch(PARAM):
case "Value1": tableName = "fooTable";
break;
case "Value2": tableName = "barTable";
break; ...
default : throw new InputValidationException("unexpected value provided for table name");
DEFENSE OPTION 4: ESCAPING ALL USER-SUPPLIED INPUT
This technique should only be used as a last resort, when none of the above are feasible.
White List Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations.
Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the
developer, thus avoiding any possible SQL injection vulnerabilities.
OWASP
The OWASP Enterprise Security API (ESAPI) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk
applications.
ühttps://www.owasp.org/index.php/Category:OWASP_Enterpri se_Security_API
The two Database specific codecs are OracleCodec, and MySQLCodec.
Codec ORACLE_CODEC = new OracleCodec();
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID")) + "' and user_password = '" + ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd")) +"'";
PHP
PHP it is usual to escape parameters using the function mysqli_real_escape_string(); before sending the SQL query
This function prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a (EOF).
$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND
Password='%s'", $mysqli->real_escape_string($username), $mysqli->
real_escape_string($password));
$mysqli->query($query);
OTHER LANGUAGES
PHP has similar functions for other database systems such as pg_escape_string() for PostgreSQL.
The function addslashes(string $str) works for escaping characters, and is used especially for querying on
databases that do not have escaping functions in PHP.
üIt returns a string with backslashes before characters that need to be quoted in database queries, etc. These
characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte)
ADDITIONAL DEFENSES
Still from OWASP suggestions
Beyond adopting one of the four primary defenses, we also recommend adopting all of these additional
defenses in order to provide defense in depth. These additional defenses are:
üLeast Privilege
üWhite List Input Validation
LEAST PRIVILEGE
To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges
assigned to every database account in your environment.
Do not assign DBA or admin type access rights to your application accounts.
Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away.
HOW TO
Make sure that accounts that only need read access are only granted read access to the tables they need access to.
If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table.
Rarely, if ever, grant create or delete access to database accounts.
MULTIPLE DB USERS
Different DB users could be used for different web applications.
üThat way, the designer of the application can have good granularity in the access control
üEach DB user will then have select access to what it needs only, and write-access as needed
As an example, a login page requires read access to the username and password fields of a table, but no write access of any form (no insert, update, or delete).
However, the sign-up page certainly requires insert privilege to that table;
This restriction can only be enforced if these web apps use different DB users to connect to the database.
VIEWS
You can use SQL views to further increase the granularity of access by limiting the read access to specific fields of a table or joins of tables.
For example, suppose that the system is required (perhaps due to some specific legal requirements) to store the
passwords of the users, instead of salted-hashed passwords.
The designer could use views to compensate for this
limitation; revoke all access to the table (from all DB users except the owner/admin) and create a view that outputs the hash of the password field and not the field itself. Any SQL injection attack that succeeds in stealing DB information will be restricted to stealing the hash of the passwords (could even be a keyed hash), since no DB user for any of the web applications has access to the table itself.
INPUT VALIDATION
In addition to being a primary defense when nothing else is possible, input validation can also be a secondary
defense used to detect unauthorized input before it is passed to the SQL query.
HowTo
ühttps://www.owasp.org/index.php/Input_Validation_Cheat_Sh eet
…validated data is not necessarily safe to insert into SQL queries via string building
XSS
CROSS-SITE SCRIPTING
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise
benign and trusted web sites.
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.
DESCRIPTION
Cross-Site Scripting (XSS) attacks occur when:
üData enters a web application through an untrusted source, most frequently a web request.
üThe data is included in dynamic content that is sent to a web user without being validated for malicious content.
The malicious content sent to the web browser often
takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute.
USUALLY USED FOR
The variety of attacks based on XSS is almost limitless, but they commonly include
ütransmitting private data, like cookies or other session information (passwords), to the attacker,
üredirecting the victim to web content controlled by the attacker, or
üperforming other malicious operations on the user's machine under the guise of the vulnerable site.
• Keylogging on events
FIRST CASSIFICATION
XSS attacks can generally be categorized into three categories: stored, reflected, and DOM-based.
STORED XSS
Stored attacks are those where the injected script is permanently stored on the target servers, such as in a
database, in a message forum, visitor log, comment field, etc.
The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type- I XSS.
REFLECTED XSS ATTACKS
Reflected attacks are those where the injected script is reflected off the web server, such as in an error message,
search result, or any other response that includes some or all of the input sent to the server as part of the request.
Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site.
When a user is tricked into clicking on a malicious link,
submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser.
The browser then executes the code because it came from a
"trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.
DOM-BASED
“DOM Based Cross Site Scripting or XSS of the Third Kind” (WASC writeup), Amit Klein, July 2005
ühttp://www.webappsec.org/projects/articles/071105.shtml
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is
executed as a result of modifying the DOM
“environment” in the victim’s browser used by the original client side script, so that the client side code runs in an
“unexpected” manner.
DOM
The Document Object Model (DOM) is a cross-platform and language-independent
application programming
interface that treats an HTML, XHTML, or XML document as a tree structure wherein each
node is an object representing a part of the document.
When a web page is loaded, the browser creates a Document Object Model of the page, which is an object oriented representation of an HTML document, that acts as an interface between JavaScript and the document itself and allows the
creation of dynamic web pages.
A DIFFERENT CLASSIFICATION
According to the first classification, Stored, Reflected, and DOM are three different types of XSS, but in reality, they overlap.
You can have both Stored and Reflected DOM Based XSS.
You can also have Stored and Reflected Non-DOM Based XSS too
Starting about mid 2012, the research community proposed and started using two new terms to help organize the types of XSS that can occur:
üServer XSS üClient XSS
SERVER SIDE
Server XSS occurs when untrusted user supplied data is included in an HTML 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.
CLIENT SIDE
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).
The ultimate source of the data could have been from a request, or from a stored location on the client or the
server.
üAs such, you can have both Reflected Client XSS and Stored Client XSS.
SECOND CLASSIFICATION
David Wichers seeking to reclassify DOM XSS more strictly as CLIENT SIDE XSS
JAVASCRIPT
One of the most common JavaScript
security vulnerabilities is Cross-Site Scripting (XSS).
EXAMPLE
Suppose the following code is used to create a form to let the user choose his/her preferred language. A default language is also provided in the query string, as the parameter “default”.
… Select your language:
<select><script>
document.write("<OPTION
value=1>"+document.location.href.substring(
document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select> …
EXAMPLE
The page is invoked with a URL such as:
http://www.some.site/page.html?default=French
An attack against this page can be accomplished by sending the following URL to a victim:
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
EXAMPLE
When the victim clicks on this link, the browser sends a request for:
/page.html?default=<script>alert(document.cookie)</script>
to www.some.site.
The server responds with the page containing the above Javascript code.
The browser creates a DOM object for the page, in which the document.location object contains the string:
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
END OF THE EXAMPLE
The original Javascript code in the page does not expect the default parameter to contain HTML markup, and as such it simply echoes it into the page (DOM) at runtime.
The browser then renders the resulting page and executes the attacker’s script:
alert(document.cookie)
QUESTION
What type of attacks is this?
Reflected Client XSS
Note that the HTTP response sent from the server does not contain the attacker’s payload. This payload manifests itself at the client-side script at runtime, when a flawed script accesses the DOM variable document.location and assumes it is not malicious.
CLIENT REFLECTED
SERVER XSS
Stored server XSS
COOKIES
But also adv banners
With a cookie I can log to that website…
Some websites will save your login information on
cookies. When you visit a website and check a box that says something like, "Remember me", the website will save your login information, such as your username and password or just your username, on a cookie.
ühttps://support.mozilla.org/en-US/kb/where-are-my-logins- stored
ADVANCED ATTACKS
In the example before, while the payload was not
embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request
üThus the attack could be detected at the server side.
The technique to avoid sending the payload to the server hinges on the fact that URI fragments (the part in the URI after the “#”) is not sent to the server by the browser.
http://www.some.site/page.html#default=<script>alert(document.cookie)</script>
XSS AND ACROBAT
In December 2006, Stefano Di Paola and Giorgio Fedon described a universal XSS attack against the Acrobat PDF plugin.
üThis attack applied the fragment variant of DOM based XSS to PDF documents.
ühttp://events.ccc.de/congress/2006/Fahrplan/attachments/11 58-Subverting_Ajax.pdf
The researchers discovered that a PDF document
served to the browser, when rendered by the Acrobat plugin, may end up executing part of the fragment as Javascript.
http://www.some.site/somefile.pdf#somename=javascript:attackers_script_here
MITIGATION
Blueclosure (https://www.blueclosure.com)
BlueClosure can analyse any codebase written with
JavaScript frameworks like Angular.js, jQuery, Meteor.js, React.js and many more.
BlueClosure Detect uses an advanced Javascript Instrumentation engine to understand the code. BC
engine can inspect any code, no matter how obfuscated it is.
BlueClosure technology can automatically scan an entire website. This is the fastest way to scan and analyse BIG enterprise portals with rich Javascript content as a tester would with his browser
PENTEST TOOLS
Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.
Nikto
ühttps://cirt.net/Nikto2
Nessus (OpenVAS)
ENCODING AND VALIDATION
For a web developer, there are two fundamentally different ways of performing secure input handling:
üEncoding, which escapes the user input so that the browser interprets it only as data, not as code.
üValidation, which filters the user input so that the browser interprets it as code without malicious commands.
IMPORTANT
While these are fundamentally different methods of preventing XSS, they share several common features that are important to understand when using either of them:
üContextSecure; input handling needs to be performed differently depending on where in a page the user input is inserted.
üInbound/outboundSecure: input handling can be
performed either when your website receives the input
(inbound) or right before your website inserts the input into a page (outbound).
üClient/serverSecure: input handling can be performed
either on the client-side or on the server-side, both of which are needed under different circumstances.
CONTEXT
There are many contexts in a web page where user input might be inserted. For each of these, specific rules must be followed so that the user input cannot break out of its context and be interpreted as malicious code.
This could be prevented by simply removing all quotation marks in the user input, and everything would be fine—
but only in this context. If the same input were inserted into another context, the closing delimiter would be
different and injection would become possible.
INBOUND/OUTBOUND INPUT HANDLING
User input can be inserted into several contexts in a page. There is no easy way of determining when user input arrives which context it will eventually be inserted into, and the same user input often needs to be inserted into different contexts.
Outbound input handling should be your primary line of defense against XSS, because it can take into account the specific context that user input will be inserted into
CLIENT/SERVER
In most modern web applications, user input is handled by both server-side code and client-side code.
üIn order to protect against traditional XSS, secure input
handling must be performed in server-side code. This is done using any language supported by the server.
üIn order to protect against DOM-based XSS where the server never receives the malicious string, secure input
handling must be performed in client-side code. This is done using JavaScript.
XSS PREVENTION CHEAT SHEET
https://github.com/OWASP/CheatSheetSeries/blob/mast er/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_
Sheet.md
Many organizations may find that allowing only Rule #1 and Rule #2 are sufficient for their needs.
RULE #0 - NEVER INSERT UNTRUSTED DATA EXCEPT IN ALLOWED LOCATIONS
The first rule is to deny all - don't put untrusted data into your HTML document unless it is within one of the slots defined in Rule #1 through Rule #5.
<script>...NEVER PUT UNTRUSTED DATA HERE...</script> directly in a script
<!--...NEVER PUT UNTRUSTED DATA HERE...--> inside an HTML comment
<div ...NEVER PUT UNTRUSTED DATA HERE...=test /> in an attribute name
<NEVER PUT UNTRUSTED DATA HERE... href="/test" /> in a tag name
<style>...NEVER PUT UNTRUSTED DATA HERE...</style> directly in CSS
RULE #1 - HTML ESCAPE BEFORE INSERTING UNTRUSTED DATA INTO HTML ELEMENT CONTENT
Rule #1 is for when you want to put untrusted data
directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc. Most web
frameworks have a method for HTML escaping for the characters detailed below.
<body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>
<div>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</div> any other normal HTML elements
#RULE1
Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec.
& --> &
< --> <
> --> >
" --> "
' --> ' ' not recommended because its not in the HTML spec
' is in the XML and XHTML specs.
/ --> / forward slash is included as it helps end an HTML entity
RULE #2 - ATTRIBUTE ESCAPE BEFORE INSERTING UNTRUSTED DATA INTO HTML COMMON ATTRIBUTES
Rule for putting untrusted data into typical attribute
values like width, name, value, etc. This should not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover.
<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div> inside UNquoted attribute
<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content</div> inside single quoted attribute
<div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content</div> inside double quoted attribute
RULE #3 - JAVASCRIPT ESCAPE BEFORE INSERTING UNTRUSTED DATA INTO JAVASCRIPT DATA VALUES
It concerns dynamically generated JavaScript code - both script blocks and event-handler attributes
<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script> inside a quoted string
<script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script> one side of a quoted expression
<div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div> inside quoted event handler
RULE #4 - CSS ESCAPE AND STRICTLY VALIDATE BEFORE INSERTING UNTRUSTED DATA INTO HTML STYLE
PROPERTY VALUES
When you want to put untrusted data into a stylesheet or a style tag. CSS is surprisingly powerful, and can be
used for numerous attacks.
<style>selector { property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...; } </style> property value
<style>selector { property : "...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE..."; } </style> property value
<span style="property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">text</span> property value
LIMITATION OF ENCODING
Even with encoding, it will be possible to input malicious strings into some contexts. A notable example of this is when user input is used to provide URLs, such as in the example below:
Although assigning a value to the href property of an anchor element automatically encodes it so that it
becomes nothing more than an attribute value, this in itself does not prevent the attacker from inserting a URL beginning with "javascript:".
When the link is clicked, whatever JavaScript is embedded inside the URL will be executed.
document.querySelector('a').href = userInput
VALIDATION
Encoding must be completed with validation.
Validation is the act of filtering user input so that all malicious parts of it are removed, without necessarily removing all code in it. One of the most recognizable
types of validation in web development is allowing some HTML elements (such as <em> and <strong>) but
disallowing others (such as <script>).
FEATURES OF VALIDATION
Classification
üBlacklisting (complexity and staleness): “javascript:”
“Javascript””, or “javascript:”
üWihitelisting (simplicity and longevity)
Validation outcome
üRejection: The input is simply rejected, preventing it from being used elsewhere in the website.
üSanitisation: All invalid parts of the input are removed, and the remaining input is used normally by the website.
MITIGATION
Always update the browser/javascript engine
OTHER RESOURCES
https://excess-xss.com
