Sunday, November 27, 2011

EllisLab xss_clean Filter Bypass - ExpressionEngine and CodeIgniter

EllisLab ExpressionEngine 2.2.2 ( and CodeIgniter 2.0.3 ( were recently found vulnerable to XSS attacks (MVSA_11_013). Due to design&implementation flaws affecting CI_Security class, the built-in XSS protection provided by xss_clean filter can be easily bypassed as detailed below.

Successful bypass of xss_clean filter was shown on a custom PHP application built using CodeIgniter PHP framework version 2.0.3. No user input validation rules were implemented/enabled, and global_xss_filtering was set to TRUE.

Test environment: Apache HTTP Server 2.2.16, PHP 5.3.3, MySql 5.1.49

1. _remove_evil_attributes function flaws

As implemented for ExpressionEngine 2.2.2 and CodeIgniter 2.0.3, _remove_evil_attributes function of CI_Security class allows detection and removal of 'evil' on* event attributes (e.g. onmouseover, onfocus, etc) from any HTML tag submitted as a parameter of GET or POST requests. In most of the cases, this works fine - except when it doesn't, as detailed below

1.1 on* event attributes submitted outside an HTML tag are not filtered out

1.2 on* event attributes submitted as part of an HTML tag are removed

XSS payload: <a href=”#” onclick=”alert(1)”>

xss_clean filtered output: <a href=”#”>

Thus, the 'evil' on* event attribute is removed from the HTML tag containing it. However, the character preceding the on* event attribute is also removed, which leads to crafting the following payload:

XSS payload: <a href=”#”onclick=”alert(1)”>

xss_clean filtered output: <a href=”#>

When there is no space between the value of a previous attribute (enclosed by double_quotes) and the injected on*event attribute, the double quotes closing the value of preceding
attribute (
href in our example) is removed together with the 'evil' on* attribute.

xss_clean function flaw

2.1 unsafe usage of HTML entities

xss_clean function includes functionality to replace any detected ( and ) characters with the corresponding HTML entities, as shown below:

-- code from
xss_clean function EE 2.2.2 / CI 2.0.3 - start --
* Sanitize naughty scripting elements
* Similar to above, only instead of looking for
* tags it looks for
PHP and JavaScript commands
* that are disallowed. Rather than removing the
* code, it simply converts the parenthesis to entities
* rendering the code
* For example:
eval('some code')
* Becomes:
eval('some code')
str = preg_replace('#(alert|cmd|passthru|eval|exec|expression|system|fopen|fsockopen|file|file_get_contents|readfile|unlink)(\s*)\((.*?)\)#si', "\\1\\2(\\3)", $str);

-- code from
xss_clean function EE 2.2.2 / CI 2.0.3 - end --

This works fine when the code to be sanitised (e.g. alert(), event(), etc) is not located as part of any attribute (including on* event attributes) of the HTML tag (e.g.
<script> alert&#40;0&#41; </script>).

When the code to be sanitised is part of an attribute of an HTML tag (e.g.
<;img onmouseover="alert&#40;111&#41;">), the CI_Security code above does little (if anything) to protect against XSS attacks.

Putting it all together

When we combine the flaws detailed in sections 1 and 2, we can successfully bypass XSS filtering provided by xss_clean function, as shown below.

XSS payload:
<a href="#"onclick="alert(1)">" onclick="alert(2)">aa</a>

xss_clean 'filtered' output:
<a href="#>" onclick="alert&#40;2&#41;">aa</a>

Exploitation of the above flaws also allowed bypassing additional XSS prevention rules provided by xss_clean filter, including the usage of document.cookie as part of injected XSS payloads:

onmouseover="var a=eval&#x28'do'+'cument'+'.'+'coo'+'kie'&#x29;;alert&#x28;a&#x29;"

Additionally, exploitation of the flaws identified in xss_clean filter allowed compromising the provided CSRF protection as well.

Based on the feedback I received from
EllisLab on this matters, improved xss_clean filtering is provided in the latest versions of ExpressionEngine and CodeIgniter products.

Sunday, June 12, 2011

OWASP AppSec EU 2011

OWASP AppSec EU 2011 ( was held in Dublin, Ireland between 7th and 10th of June. With a great selection of international presenters and with a good mix of IS professionals and developers, I can say (and I am not the only one) the conference was a success.

As for any major AppSec event, there is only a limited number of events you can effectively participate to. Between Defend, Prevent and Attack series of presentations, I followed the latter one as briefly summarized below.

Designing, Building and Testing Secure Application on Mobile Devices
training session held by Dan Cornell from Denim Group on 8th of June was a great introduction to security for mobile and smartphone applications. Dan introduced a threat model for smartphone applications which was used to analyze security of iOS and Android applications. A variety of open source tools were used as part of the hands-on applications analysis. While the course introduced techniques for analyzing mobile applications, it also provided recommendations on avoiding known security issues as part of the development of new smartphone applications. I guess there were not many design considerations discussed, this might be included in the next version of the course. Overall, an excellent course which will hopefully contribute to an increased awareness on building secure smartphone application. Highly recommended.

The plenary sessions started on 9th of June. Brad Arkin, senior director of product security and privacy at Adobe opened the session by presenting on various aspects of Adobe's security program - The Adobe Security Product Lifecycle. An interesting presentation, especially on the green/brown/black belt approach to certifying expertise of security engineers, and their responsibilities inside the company.

While I was looking forward for the first session of presentations (including Practical Browser Sandboxing on Windows with Chromium and Building a Robust Security Plan), I took the opportunity instead to catch up with some of the conference organizers (Eoin Keary and Fabio Cerullo), as well as having a quick chat with Tom Brennan about OWASP Security Baseline
project (details available below).

Back in the presentation room for the Attack track, Joe Basirico from Security Innovation had an entertaining presentation on Web Applications fuzzing - The Buzz About Fuzz: an enhanced approach to finding vulnerabilities. Pros and cons of common automated testing for Web applications were discussed, as well as the benefits of fuzz testing. Very well presented topic, with practical examples and testing tools.

Giles Hogben, secure services programme manager at ENISA discussed information risks, opportunities and recommendations for smartphone security - Current State of Application Security. He also introduced the work on mobile developer guideline project done in collaboration with OWASP, as well an on-going initiative on threat analysis of app store security. Finally, security implications of HTML5 and other related standards were discussed.

The Attack series of presentations continued with Intranet Footprinting: Discovering resources from outside presentation done by Javier Marcos De Prado and Juan Galiana Lara from IBM. Relying on exploitation of common Web applications vulnerabilities including Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and HTTP Response Splitting, several custom modules for BeEF (Browser Exploitation Framework) were introduced. Such custom BeEF modules allow browser-based port scanning, internal DNS discovery, OS detection, etc using known approaches based on JavaScript code and CSS. An excellent presentation.

Janne Uusilehto, head of Nokia product security started the second day of plenary sessions with a talk on software security engineering - Software Security is about coding securely, or is that all? Some key points discussed - security is a process, not a product & difficulty to ensure reasonable expectations towards software security. An interesting presentation.

The Attack series of presentations resumed with An Introduction to OWASP Zed Attack Proxy done by Simon Bennetts. A great tool for developers looking for a quick automated security assessmnet of Web applications. With his software development background, I think Simon has a good chance to make ZAP tool a worthy successor of Paros Proxy. Looking forward for ZAP updates - excellent work.

Testing Security Testing: Evaluating Quality of Security Testing presented by Ofer Maor from Seeker Security discussed various aspects of security testing, with an emphasis on what could determine the quality of security testing - good and bad security testing.

After this, I had a go with my own presentation A Case Study on Enterprise E-mail (in)Security Solutions. In an effort to increase the awareness on the necessity to secure enterprise anti-spam and anti-virus solutions, I briefly introduced various e-mail security solutions ranging from software, hardware/software appliances, virtual appliances and cloud-based services (SaaS and IaaS). While most of existing solutions rely on Web applications for remote administration and end-user quarantined e-mail management, exploitation of common vulnerabilities could allow internal and external attackers to gain access and maintain control to various internal resources. Various case studies on identified vulnerabilities in products/services from Google, Symantec, IBM, Barracuda Networks, Astaro and Marshal were discussed as well as some attacks which could exploiting such vulnerabilities. Finally, in the context of benchmarking enterprise e-mail security solutions, I took the opportunity to announce OWASP Security Baseline project, as an independent way to benchmark security of various enterprise solutions (including the security ones as well).

OWASP Security Baseline call for participation is now open, drop me a line for more details and if interested to contribute: marian dot ventuneac at

The next keynote was delivered by Alex Lucas, principal security develpoper manager at Microsoft - Science, SDL & Openness. A good insight into what is being done to secure various Microsoft products, including automated fuzzing and how this lead to improved product security and available materials and tools to support secure development and testing.

The Dark Side: Measuring and Analyzing Malicious Activity on Twitter introduced the audience to recent research on analyzing and profiling suspicious/malicious Twitter accounts, lots of stats, trends, etc. Although the current percentage of malicious attacks identified by Barracuda Networks on Twitter is small (I think it was 1% of the analyzed data), such research has the potential to allow timely identification any (hopefully) prevention of any significant increases of such attacks.

And finally, Practical Crypto Attacks Against Web Applications presented by Justin Clarke from GDS Security described practical techniques on exploiting crypto weaknesses as identified in ASP .NET framework allowing oracle padded attacks against common Web applications - an excellent presentation.

While high expectations were for Ivan Ristic's presentation closing the AppSec EU conference, unfortunately he was not able to attend. However, Arian Evans from WhiteHat Security did a great job on reminding us once again that we (as an industry) failed on delivering the great promise on building secure software - and came with some useful suggestions. Hopefully it is not a lost battle - I believe OWASP greatly contributes to increasing awareness on application security, and OWASP AppSec EU 2011 conference proves this once again.

Congratulations to all conference organizers, this was an excellent AppSec event! I am looking forward for the next one.

Tuesday, May 10, 2011

Apache Struts 2, XWork, WebWork ... Reflected XSS Vulnerabilities

The recently released Apache Struts 2.2.3 framework includes fixes for two reflected XSS vulnerabilities.

User provided data is not
properly escaped before being included in XWork generated errors, thus allowing successful reflected XSS attacks as described in MVSA-11-006 security advisory.

NOTE: Other open source projects and commercial products relying on XWork framework could be vulnerable to attacks similar to the ones described in this post.

WebWork framework released by OpenSymphony ( was already confirmed as vulnerable to reflected XSS attacks using similar vectors.

1. XSS payload injected in the name of the requested Struts actions


  • no declarative error handling rule is defined in struts.xml using <global-exception-mappings> tag
Test case:

HTML source code for the error displayed (HTTP response Content-Type is text/html):

There is no Action mapped for namespace / and action name login<img>.

This allows successful reflected XSS attacks by injecting malicious scripting code into the name of requested Struts actions.

2. Reflected XSS vulnerabilities in with DMI enabled


  • no declarative error handling rule is defined in struts.xml using tag
  • Dynamic Method Invocation is enabled (this is enabled by default)
  • bash syntax is used in JSP via tag for calling Struts actions and methods
  • the requested method is not matching an existing one already defined in the Struts action implementation class
  • the requested action is not matching an existing one already defined in struts.xml
Example of <s:submit> tag usage with JSP:

<form name="loginform" id="loginform" method="post" action="">
<s:submit action="login" method="cantLogin" name="cantlogin" key="cantlogin" />

2.1 Test case - XSS payload is injected in action attribute of
<s:submit> tag

HTML source code for the error displayed (HTTP response Content-Type is text/html):

There is no Action mapped for namespace / and action name login<script>alert(document.cookie)</script>.

NOTE: Without proper output escaping for the invoked action (which is controlled by the user), the injected malicious scripting code is executed by the browser (the HTTP response's content-type header is set to text/html).

This allows successful reflected XSS attacks using <s:submit> tag.

2.2 Test case - XSS payload is injected in method attribute of
<s:submit> tag!login:cantLogin

HTML source code for the error displayed (HTTP response Content-Type is text/html):


NOTE: Without proper output escaping for the invoked method (which is controlled by the user), the injected scripting code will be executed by the browser (the HTTP response's content-type header is set to text/html).

This allows successful reflected XSS attacks using <s:submit> tag.

UPDATED (2011-05-18): The returned error also exposes internal paths for the Java class implementing the action for which we manipulate the method to be called (LoginAction in this case).
This issue is documented by MVSA-11-007 security advisory.

WebWork framework seems to be vulnerable to similar attacks. However, since the project is not actively maintained (being replaced by Apache Struts 2), there might be an option to look into building the project from source and to include similar fixes to those suggested for XWork
com.opensymphony.xwork2.DefaultActionProxy class patched in Struts 2.2.3 (details available at

Wednesday, September 15, 2010

Testing Google Message Security SaaS

NOTE: all the vulnerabilities discussed in this article were responsible disclosed to Google back in January 2010.

While driving an initiative on 'Testing the Enterprise Security Infrastructure', I've been looking sometime at the beginning of the year to assess some SaaS (Software-as-a-Service) enterprise e-mail security solutions. Thus, I came across Google Message Security (powered by Postini). Bundled with Google Apps Premiere, you can easily get your hands on the Google e-mail security services for 50$/year - a real bargain :)

After setting my Google Apps Premiere account, there it was. From the Apps account, two Google Message Security services were available: the Security Console (Admin console) - used to manage the organization resources (domains, users, filtering rules, etc), and the Message Center - used by the end-user to manage the quarantined e-mails and filtering settings. The Message Center comes in two flavors: Message Center II is the latest version (set by default for end-users). However, the older user interface known as Message Center Classic was still accessible to an authenticated user (after tweaking the URL a bit).

The original plan was to refresh an older security test plan I used for assessing various products from Barracuda Networks and Symantec. However, I quickly realized that I got much more that I bargained for. The Google Message Security SaaS was vulnerable to various security vulnerabilities, including multiple persistent and reflected Cross-Site Scripting (XSS), improper error handling, and the most interesting of all, SQL Injection.

And here they are!

A. Multiple XSS vulnerabilities in Security Console

First, a persistent XSS vulnerability identified to affect /exec/admin_orgs resource allows injecting and persistently storing malicious scripting code via
setconf-neworg parameter.


The attack persisted malicious scripting code into the name of a new organization. When queried for details, the malicious scripting code successfully executed in the client's browser.

Multiple reflected XSS vulnerabilities were also identified for /exec/admin_list and /exec/admin_auth resources:

- in ORGS and USERS > Organization

- in ORGS and USERS > Users”><>&Search=Search

- in ORGS and USERS > Authorization

POST /exec/admin_auth?action=display_summary HTTP/1.1

... and so on.

B. Multiple reflected XSS in Message Center Classic

Following the submission of incorrectly formatted e-mails for Approved and Blocked senders lists, injected malicious code was included in the

invalid e-mail format error messages displayed to the user.

POST /exec/MsgSet?action=change_MsgSettings HTTP/1.1

The result is shown below:

C. Reflected XSS in Message Center II

Manipulation of source_uri parameter of /msgctr/message_display resource allowed reflected XSS attacks. 2%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

D. Improper Error Handling in Security Console

Manipulation of beg_date and end_date parameters of /exec/adminRep resource returned the following error:

There was a problem processing your request. Please click the Back button and try again.

If you continue to see the problem, please report it to your system administrator or support contact with the following information.

Time: Thu Jan 21 23:53:08 2010 GMT Request ID: 20593BC6-06E8-11DF-93DD-E3695903FD3E

Request URL: /exec/adminRep?action=displayReport&targetorgid=100059876&cat=out_virus&report=sender&beg_date=20100120%27&end_date=20100120&org_agg=orgh


Message: function(): not a valid date at /product/build/folder1/folder2/component line 137.


The returned error disclosed details about the component implementing the functionality, it's location on the server, and technology being used. It could be handy for devising further attacks ;)

E. SQL Injection in Message Center II

Manipulation of sort_direction parameter of /junk_quarantine/process and /trash/process resources allowed successful SQL Injection attacks against Message Center II service.

Content-Type: multipart/form-data; boundary=---------------------------26418279386900
Content-Length: 1351
Content-Disposition: form-data; name="_submitted_junk_quarantine_form"
Content-Disposition: form-data; name="range_menu"
Content-Disposition: form-data; name="sort_menu"
Content-Disposition: form-data; name="sort_direction"

The extra apostrophe used for the initial test caused the following system error:

Apart of providing details on the database engine used, error type and middleware settings, the returned error confirmed the service was vulnerable to SQL Injection. Additional test cases were devised to confirm the issue.

As confirmed by Google Security Team, such vulnerabilities were affecting Google Message Security release 6_24 (January), 6_25 (Feb), 6_26 (March) and 6_27 (April). Additional details are available in MVSA-10-001, MVSA-10-002 and MVSA-10-003 security advisories.


Wednesday, April 7, 2010 vulnerable to persistent XSS injected in published articles

...or 'When re-publishing app security material helps discovering vulnerabilities in the publisher's Web application'... published on 6th of April an article which describes 'meta-information XSS' (see 'Researcher Details New Class of Cross-Site Scripting Attack', available at").

The original article included a classic XSS test case, namely <script>alert(1)</script>. As a result of an existing XSS vulnerability in the web site, the XSS test case above turned out to be inadvertently a successful one, as shown below:

Following a brief notice I sent today to Timothy Wilson (editor at, he confirmed the issue, also mentioning that it is now fixed.

The HTML code from the original post (including the cited XSS test case):
a DNS TXT record that contains the value "<script>alert(1)</script>" and a service

The HTML code for current version of the article:
a DNS TXT record that contains [a certain value] and a service

With the same article being reproduced by a significant number of online publications, it could be interesting to see how many other are also affected.