Close Menu
  • Home
  • Articles
    • Attacks
      • BEC
      • Data Breach
      • DDoS
      • Evasion Attacks
      • Injection
      • Malware
      • MITM
      • Phishing
      • Ransomware
      • RCE
      • Social Engineering
      • Spoofing
      • Spyware
    • Business and Policy
      • BCP and DRP
      • GRC
      • Regulations
    • Data Protection
      • DLP
      • DRM
      • Encryption
      • IAM
    • Future, Trends and Insight
      • AI
      • Events & Community
      • Emerging Tech
      • Expert Panel
      • Interviews With Experts
      • Insights
      • Study & Research
    • Resources
      • Guides
      • Tools
      • Training & Education
    • Security
      • API
      • Apps
      • Cloud
      • Critical Infrastructure
      • Endpoint
      • Hardware
      • IoT
      • Mobile
      • Network
      • OT
      • Port Security
      • Security Architecture
      • Software Development
      • Supply Chain
      • Zero Trust
    • Threats and Vulnerabilities
      • Emerging Threats
      • Insider Threats
      • Risk Management
      • Threat Intelligence
      • Zero Day
  • News and Exclusives
    • Latest News
    • ISB Exclusive
    • Positive News
  • Who We Are
    • About Us
    • Information Security Buzz Expert Panel​
    • Write for Us
    • Media Pack
  • Contact Us
  • Newsletter
Facebook X (Twitter) LinkedIn
Facebook X (Twitter) LinkedIn
Information Security BuzzInformation Security Buzz
  • Home
  • Articles
    • Attacks
      • BEC
      • Data Breach
      • DDoS
      • Evasion Attacks
      • Injection
      • Malware
      • MITM
      • Phishing
      • Ransomware
      • RCE
      • Social Engineering
      • Spoofing
      • Spyware
    • Business and Policy
      • BCP and DRP
      • GRC
      • Regulations
    • Data Protection
      • DLP
      • DRM
      • Encryption
      • IAM
    • Future, Trends and Insight
      • AI
      • Events & Community
      • Emerging Tech
      • Expert Panel
      • Interviews With Experts
      • Insights
      • Study & Research
    • Resources
      • Guides
      • Tools
      • Training & Education
    • Security
      • API
      • Apps
      • Cloud
      • Critical Infrastructure
      • Endpoint
      • Hardware
      • IoT
      • Mobile
      • Network
      • OT
      • Port Security
      • Security Architecture
      • Software Development
      • Supply Chain
      • Zero Trust
    • Threats and Vulnerabilities
      • Emerging Threats
      • Insider Threats
      • Risk Management
      • Threat Intelligence
      • Zero Day
  • News and Exclusives
    • Latest News
    • ISB Exclusive
    • Positive News
  • Who We Are
    • About Us
    • Information Security Buzz Expert Panel​
    • Write for Us
    • Media Pack
  • Contact Us
  • Newsletter
Subscribe
Information Security BuzzInformation Security Buzz
Home - Articles - XSS: Still The Easiest Way To Hack Your Website In 2014
Articles

XSS: Still The Easiest Way To Hack Your Website In 2014

ISBuzz TeamBy ISBuzz TeamNovember 21, 2014Updated:July 8, 20249 Mins Read
Share LinkedIn Twitter Facebook Copy Link Email
Linux worm targeting Routers, Set-top boxes and Security Cameras with PHP vulnerability
Share
Facebook Twitter LinkedIn Email Copy Link
Quick AI Summary
ChatGPTClaudeGeminiGrokPerplexityDeepSeekCopilot

Today, there is no need to convince people that XSS (Cross-Site Scripting) was, is and probably will be the most popular web application vulnerability. However, many people, including security engineers, team leaders and web developers, still seriously underestimate the impact of Cross-Site Scripting vulnerabilities and their consequences.

Ignorance of XSS vulnerabilities is also indirectly confirmed by the “XSSPosed.org” website, an open Internet archive of web vulnerabilities. The website contains about 6,000 XSS vulnerabilities, including vulnerabilities on Google PR 10 websites, Alexa Top-100 websites, websites of security companies, governmental and media websites. Many of the vulnerabilities are still unpatched.

In this blog post, we will to reveal the most commonly ignored characteristics of XSS and try to dispel some misunderstandings about XSS. The research data comes from:

– ImmuniWeb® on-demand web application penetration testing SaaS

– High-Tech Bridge Security Research Lab

– Ongoing computer forensics projects performed by High-Tech Bridge.

In total, during the last 24 months we have pen-tested over 1,000 high-profile live websites, audited more than 150 well-known web applications (used on average by 5,000 live websites [per application]), and investigated over a dozen of high-profile web hacks targeting several millions of users.

Some existing facts and figures about XSS

XSS vulnerabilities have been actively exploited by cyber-criminals for almost a dozen of years already. OWASP describes XSS as “the most prevalent web application security flaw“, security companies and organizations frequently mention XSS as the most common/popular web vulnerability:

– Trustwave’s Spiderlabs estimates that “82% of web applications are vulnerable to XSS”.

– WhiteHat Security report says that “XSS regained the number one spot for being the most common vulnerability”.

– Cenzic confirms that “XSS leads the [most popular vulnerabilities] list in terms of frequency of occurrence”.

– CWE by MITRE warned about the problem in 2011 saying that “XSS is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications”.

Since Q1 2012, High-Tech Bridge Security Research Lab has released 169 security advisories covering 161 well-known software products, 56% (91) of which contained XSS vulnerabilities. 96% of the vulnerabilities were patched by vendors thanks to our efforts and assistance, but XSS vulnerabilities are often live for a long time before being identified or patched.

XSS: great hacking opportunities, ignored risks, and compromised web applications

In this section we will briefly overview the most common properties of XSS attacks and the opportunities they give to attackers, many of which exist since years but are still seriously underestimated or even ignored by the web developers community.

XSS does not require much social engineering or interaction with humans

Yes, unlike SQL injections for example, XSS is only exploitable if the attacker can trick a user into opening a malicious link to trigger the vulnerability. Many people think that hackers send you a 200-character URL with the XSS payload inside that any antivirus will block, and that an experienced user will never ever think to open.

In fact, XSS vulnerability can be exploited by making the victim visit any page of any website where the attacker can place an XSS exploit. AJAX functions allow attackers to steal cookies (or perform any other XSS exploitation) from any website the attacker controls, the victim doesn’t need to open the vulnerable website in a browser window. Of course, the attacker needs to have a write access to the website with the XSS exploit, but today it’s pretty easy to compromise one famous website among the dozens or even hundreds that the victim regularly visits and trusts.

It’s enough to make small change to the index page of the website [controlled by the attacker] in such a manner that if IP address of a visitor belongs to the victim’s subnet (e.g. network of a bank) the index page will automatically inject an XSS exploit among other HTML content. Such attacks are extremely difficult to detect, and even IT security professionals can be easily compromised via such technique.

Another pattern that we regularly see on the market is using XSS vulnerabilities (especially stored ones) to deliver malware to the victim, instead of just stealing credentials. By clicking what appears to be a trustworthy link the victim becomes not only a victim of data theft via XSS, but is also entirely compromised.

Quick facts:

– Seven out ten web investigations performed by High-Tech Bridge involved XSS usage aimed at infecting users with malware.

– Over 90% of XSS vulnerabilities can be exploited in such a manner that even advanced users and IT people will not suspect anything.

– The structure and architecture of over 70% of web applications allows creation of a sophisticated XSS exploit that will perform several fully-automated consecutive actions, giving full administrative access to the attacker at the end.

– More than 95% of XSS vulnerabilities can be used to perform sophisticated drive-by-download attacks infecting users who just open a harmless-looking URL they trust.

– SSL certificate and HTTPS connection to the website have absolutely no impact on web application security and can never prevent XSS attack.

XSS on a subdomain puts the entire web application at risk

Many large companies install expensive web application firewalls (WAF) and regularly conduct penetration testing for their main, most critical website. At the same time they ignore security on numerous subdomains that they consider “less important” for business continuity. The problem is that in many cases, for the sake of simplicity, usability and compatibility, cookies installed on the main website (e.g. www.site.com) will be valid for any subdomain like (education.site.com or jobs.site.com). This means that an XSS vulnerability on a test, or forgotten, subdomain may be easily used to steal cookies from the main website, or from the other subdomains (e.g. e-banking.site.com that also sets cookies for *.site.com), even if they are located on completely different servers in different datacenters. Quite often, particularly in large companies, different departments have their own websites and subdomains for testing reasons which are not designed to be secure, but their presence endangers the entire web infrastructure of the company. We are not even talking about the case when test area is located directly on the main website (e.g. www.site.com/secr3t/beta1/) but can be found by Google search.

Quick facts:

– Over 80% of websites set cookies in such a manner that they are accessible for several, or even all subdomains.

– Over 90% of large and reputable websites have subdomains with XSS vulnerabilities.

A WAF does not protect against XSS vulnerabilities anymore

Web Application Firewalls are a common way to protect sensitive web applications. However, a WAF should never be used as the sole security measure to keep web applications secure. Web applications continually evolve: new features and functions are being regularly added and updated, while HTML5 brings new functionality. All these factors cause WAF rulesets to become outdated quite quickly and allow hackers to bypass them. Particular attention should be given to the web applications where user-supplied input is being inserted into JS code: it gives the attackers unlimited opportunities to obfuscate the XSS payload and thus to bypass any WAF.

Quick facts:

– Over 70% of existing WAF rulesets can be bypassed via XSS obfuscation techniques.

– Around 30% of XSS are XSS inside JS code, and therefore cannot be blocked by WAF.

Insecure session management, cookies accessible via JS and server misconfigurations make XSS attacks very easy

The majority of web applications, that use sessions in cookies to identify users, rely on insecure mechanism for session creation and management. The session is not bound to a unique user identifier, such as his IP address for example, and if the session is stolen via XSS attack – it may be reused by the attacker to get into the system under the user’s account. Web developers tend to ignore best practices, such as using httpOnly cookies that cannot be accessed via JavaScript. Of course, httpOnly cookies do not prevent all vectors of XSS exploitation, but significantly reduce the risk of data theft stored in cookies. However, even the httpOnly cookies are useless if the web server supports the HTTP TRACE method, which allows attackers to read httpOnly cookies bypassing the restriction. Insufficient session expiration is another big problem today that is also listed among the OWASP Top 10. It simplifies XSS attacks a lot: even when the user logs out from the system, his session will remain valid and allow hackers to surf under the victim account until the victim comes back. But remember that in the case of fully-automated XSS exploit usage, a dozen of seconds may be perfectly enough to get total control over the victim’s account.

Quick facts:

– 85% of websites do not bind user sessions to user IP addresses, nor do they conduct proper session management.

– 80% of websites do not use httpOnly cookies.

– 40% of websites with httpOnly cookies allow the HTTP TRACE method.

A single XSS vulnerability renders CSRF protection mechanisms useless

Almost any web application gives great access and privileges to its administrator: from arbitrary SQL command execution to arbitrary file upload and arbitrary code execution. Administrative interfaces usually don’t have the numerous security mechanisms that are present in the standard user interface, as the administrator is commonly considered as a trusted party that won’t harm his own website. Modern web applications have cross-site request forgery (CSRF) protection in order to prevent malicious usage of sensitive website functionality in the case of a CSRF attack. However, a single XSS can bypass CSRF protection in the majority of cases and allow a remote attacker not just to steal sensitive data, but also to act as a privileged user or even administrator of vulnerable web applications – significantly increasing the impact of XSS attack.

Quick facts:

– Over 95% of CSRF protection mechanisms can be bypassed via XSS vulnerability on the same site.

– Architecture of over 70% of websites gives almost unlimited functionality to administrator that can be used by hackers to compromise the entire website and even the web server.

ISBuzz Team
  • ISBuzz Team
    Air Canada Data Breach: BianLian Extortion Group Claims A Massive Heist Contrary To Airline’s Earlier Statement
  • ISBuzz Team
    Unprecedented DDoS Attack Rocks The Web: Tech Giants Reveal A Digital Tsunami
  • ISBuzz Team
    CISA Flags High-Severity Adobe Acrobat Reader Flaw Amid Active Exploits
  • ISBuzz Team
    Curl Security Alert: Patching A Critical Bug Averting Potential Cyber Catastrophe

The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.

Share. Facebook Twitter LinkedIn Email Copy Link

Related Posts

Exploited Faster, Patched Slower: Verizon DBIR 2026 Shows Security Teams Losing Ground

May 20, 20265 Mins Read

Security’s Blind Spot: The Threats Hiding in “Low-Severity” Alerts

May 6, 20265 Mins Read

AppSec is dead, long live AI security

April 29, 20265 Mins Read
ISB-Bora-Side-Bar

No se ha podido establecer conexión. Error 404

 
ISB-Bora-Side-Bar
Black ISB Logo

Information Security Buzz is an independent resource that provides the experts’ comments, analysis, and opinion on the latest Cybersecurity news and topics

X (Twitter) LinkedIn Facebook RSS

Working With Us

  • About Us
  • Advertise With Us
  • Contact Us

Write For Us

  • How To Contribute

The Pages

  • Privacy Policy
  • Cookie Policy
  • AI Policy
  • Terms & Conditions
  • Copyright Notice

Information Security Buzz and all its contents are copyright © 2014-2025. All rights reserved. All third-party trademarks are recognized.

Type above and press Enter to search. Press Esc to cancel.

Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
View preferences
  • {title}
  • {title}
  • {title}