A cross site scripting (XSS), or arbitrary script injection, vulnerability exists in TinyMCE due to the fact that the bbcode plugin violates the explicit security policy of TinyMCE. If the bbcode plugin is enabled, but encoding is enabled using the "encoding" directive, or sanitizing is enabled using the "valid_elements" attribute, these mechanisms fail to function as expected.
An overview of cross site scripting (XSS) prevention functions provided in the PHP language, including discussion of suitable uses and guidance for approach to untrusted user input sanitizing. Arbitrary script injection flaws are widespread and pernicious among web applications. Understanding and appropriately utilizing built in language controls to prevent XSS is critical in removing this class of vulnerability from your web application.
Drupal Ctools prior to 6.x-1.10 contains an XSS vulnerability
The Drupal OM Maximenu module, prior to versions 6.x-1.44 and 7.x-1.44, contains suffers from a number of vulnerabilities, including several arbitrary script injection (XSS) flaws. The module also gives users with permission to "Administer OM Maximenu" the ability to execute arbitrary PHP with no indication of the power of this privilege. This could allow attackers who gain access to accounts with this permission to compromise the host web server, attack other users, and more.
The Drupal Inf08 theme, prior to versions 6.x-1.10, contains a XSS vulnerability due to the fact that it fails to properly sanitize taxonomy terms before display. This could allow attackers who have the ability to create taxonomy terms to perform arbitrary script injection attacks via persistent cross site scripting.
Cross Site Scripting (originally CSS but the acronym was changed to XSS to avoid confusion with Cascading Style Sheets), also known as an arbitrary script injection flaw, is a pernicious vulnerability in web applications. Noted in the OWASP Top 10 most common web application vulnerabilities XSS is an often misunderstood and overlooked. XSS can allow an attacker to take control of a victim web browser, often without leaving any trace of their attack. XSS targets web application users rather than the application server, as is the case in attacks leveraging SQL injection, authentication bypass, or code execution vulnerabilities. Because XSS vulnerabilities affect site users, rather than application infrastructure, it is often overlooked by developers or security officers. However, as the browser becomes closer to a complete operating system for many users it is becoming an increasingly attractive target, and platform, for attack.
The Drupal HotBlocks module contains a persistent cross site scripting (XSS), or arbitrary script injection, vulnerability due to the fact that it fails to sanitize user supplied data before display. The HotBlocks module also suffers from a denial of service vulnerability due to a user triggered infinite code loop.
About XSSCross site scripting (XSS) is a pervasive problem in Drupal because the development team takes the approach that data should be sanitized upon display rather than input. The rational for this decision is to maintain data integrity despite translation or manipulation. This is a somewhat non-standard approach in web application circles and leads to no small amount of confusion about "trusted" data sources and the display of data. In general, all user supplied data must be filtered upon display. Drupal provides several useful API calls to facilitate this transformation. These include, but are not limited to, filter_xss(), check_plain(), and the t() function. Drupal output sanitization functions must be used carefully and properly, however, especially the t() function as misuse can introduce unexpected vulnerabilities.
e107 is a PHP/MySQL based content management system. e107 versions prior to 0.7.23 suffer from cross site scripting and cross site request forgery vulnerabilities.
Cross site scripting (XSS) vulnerabilities can have an incredibly damaging effect on a Drupal site. In addition to introducing malware, redirecting users, or other nefarious interactions, arbitrary script on a Drupal site can actually interact with the system allowing an XSS vulnerability to escalate into an account compromise or even a site compromise. Finding XSS vulnerabilities in Drupal modules can be a tricky task, but there are some general guidelines you can follow to ease the task.
Magento (http://www.magentocommerce.com/) is an eCommerce platform written in MySQL and PHP. Magento contains numerous serious cross site scripting (XSS) vulnerabilities.
The Drupal security team recently released SA-CORE-2009-002 (http://drupal.org/node/372836) which is an advisory that warns that many CCK (http://drupal.org/project/cck) based modules contain Cross Site Scripting (XSS) vulnerabilities that can be exploited by users with 'administer content types' permissions (some examples include the Links module (http://secunia.com/Advisories/33835/), the ImageField module (http://secunia.com/Advisories/33757/) and the Viewfield module(http://www.lampsecurity.org/node/20)) and the . The Drupal security team's rather disappointing advice to rectify this situation was not to fix the vulnerabilities in the module code in question, but rather to limit the scope of users granted 'administer content types' privileges. This response is flawed in several ways.
The Drupal Node2Node module was recently flagged by the Drupal security team as insecure and unmaintained (http://drupal.org/node/572852). The module was subsequently unpublished by Drupal, removing it from the main site downloads. This means that the module is no longer supported by Drupal. The Drupal security team announcement did not specify what vulnerabilities were contained within the Node2Node module, but a quick glance at the code and some testing quickly reveals a cross site scripting (XSS) vulnerability in the Node2Node module. To exploit the vulnerability simply follow the proof of concept steps below:
The Drupal Download Count module (http://drupal.org/project/download_count) is designed to keep track of file downloads on Drupal sites. This module contains multiple cross site scripting (XSS) vulnerabilities due to the fact that it fails to sanitize user supplied input before display.
Recently the Drupal team released a security upgrade to the Drupal core to versions 6.21, 6.22, 7.1 and 7.2. These updates fixed several security flaws, the most commonly exploitable of which is a flaw in the core color module that allowed an attacker who could gain access to the color picker widget (for instance through the theme administration) to perform cross site scripting (XSS) attacks. This flaw resulted in a persistent XSS vulnerability in the Drupal core.
The Drupal Taxonomy Theme module version 5.x-1.1 suffers from a cross site scripting vulnerability.
There have been quite a few Cross Site Scripting (XSS) vulnerabilities discovered in Drupal modules recently. Many people scoff at XSS and even argue that it's a low threat vulnerability. In many cases this is certainly true, however XSS can be used as an element in an attack that leverages other security weaknesses to devastating consequence. A case in point is the password changing option in Drupal. Drupal does a wonderful job in preventing against Cross Site Request Forgery (XSRF or CSRF) by placing tokens in forms to validate posts. Drupal provides a token in the id "edit-user-edit-form-token" in the edit user form (found at ?a=user/X/edit where X is the user id number). A sample value contained in this hidden form field is "5545a410de3662f1844af7ee6f1ee770" - a value sufficiently long and random that an attacker would have great difficulty in guessing the value. However, the Drupal account page doesn't require users to enter the current account password in order to change the password to a new value. This flaw, combined with a well crafted XSS attack, could be used to change a user's password to an arbitrary value. What's worse, Drupal uses session cookies by default that can keep users logged into the site for days. This means that a user could be the victim of a password changing attack and not even realize their password had been changed for some time (until their session cookie timed out or they logged out of the site) when they were forced to log back in to the site. The user would still be able to request a password reset via e-mail, so they would not be locked out of the site, but they might have their account hijacked for some time in the interim.
This is the first in a series of training articles that goes hand in hand with a test site that should be downloaded and installed by the reader. The training is designed to help you gain experience with methods used by attackers to compromise web applications so you can build better applications and learn to defend your applications more successfully. This initial lesson covers Cross Site Scripting (XSS) attacks and includes instructions on downloading and installing the test application.
A cross site request forgery leverages the fact that many popular web sites use session authentication, but don't follow up by verifying the session. The problem is that sessions are handled by cookies, and relying on the cookie alone isn't enough to validate the source of data. A cross site request forgery uses a cookie that has been generated by a session to validate a request (usually a form post) from a third party web site.