CROSS SITE SCRIPTING(XSS)

Cross Site Scripting is still a serious issue in many websites available on the internet as it will modify
the source code of the website when an attacker injects java scripts and html tags easily through the
browser.

DESCRIPTION

XSS can be carried out by an attacker directly through a browser, he simply injects malicious
java scripts into a website in a user input session where the script will be stored in the websites
source code and executes when a user with that link opens it. It will show alerts, steal cookies, steal
sessions much more sensitive information which that site have access to depending on the intention
of the script injected.

TYPES OF XSS

 Reflected XSS
 Stored XSS
 DOM Based XSS

Reflected XSS

Reflected XSS are non-persistent which are executed in the victim’s browser when
the victim clicks on the infected link which will give sensitive information to the attacker like cookies
and session ID, an attacker will have the full control over that session whatever the session maybe
even if it was a logged in users web application account he can view modify and do whatever the
user can do.

The attacker simply injects a java script which pops up an alert when the user clicks
the infected link, this is called reflected XSS.

Stored XSS

Stored XSS are persistent because an attacker will inject a script into a public blog
post or any other means of input which will be displayed in a website publicly. The script will be
stored in the database of that webpage because a public comment must be shown to everyone who
access that blog, the malicious script has been stored in a form of comment. Whenever someone
access that blog executes the injected script and are exposed to that attacker, the attacker will
receive sensitive information from that user.
DOM-BASED XSS

DOM XSS stands for Document Object Model-based XSS. A DOM-based XSS attack is
possible if the web application writes data to the Document Object Model without proper
sanitization. The attacker can manipulate this data to include XSS content on the web page,
for example, malicious JavaScript code.

The Document Object Model is a convention used to represent and work with
objects in an HTML document (as well as in other document types). All HTML documents
have an associated DOM that consists of objects, which represent document properties from
the point of view of the browser. When a client-side script is executed, it can use the DOM
of the HTML page where the script runs. The script can access various properties of the page
and change their values.

MITIGATION

 To keep your web application safe, everyone involved in building the web application must
be aware of the risks associated with XSS vulnerabilities. You should provide suitable
security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by
referring them to this page.
 Treat all user input as untrusted. Any user input that is used as part of HTML output
introduces a risk of an XSS. Treat input from authenticated and/or internal users the same
way that you treat public input.
 Use an appropriate escaping/encoding technique depending on where user input is to be
used: HTML escape, JavaScript escape, CSS escape, URL escape, etc. Use existing libraries for
escaping, do not write your own unless absolutely necessary.
 If the user input needs to contain HTML, you cannot escape/encode it because it would
break valid tags. In such cases, use a trusted and verified library to parse and clean HTML.
Choose the library depending on your development language, for example, HtmlSanitizer for
.NET or Sanitize Helper for Ruby on Rails.
 To mitigate the consequences of a possible XSS vulnerability, set the HttpOnly flag for
cookies. If you do, such cookies will not be accessible via client-side JavaScript.
 To mitigate the consequences of a possible XSS vulnerability, also use a Content Security
Policy (CSP). CSP is an HTTP response header that lets you declare the dynamic resources
that are allowed to load depending on the request source.
 XSS vulnerabilities may be introduced by your developers or through external
libraries/modules/software. You should regularly scan your web applications using a web
vulnerability scanner.