IBM Application Security Insider

Microsoft Anti-XSS Library Bypass (MS12-007)

2012-01-19T11:27:01+02:00

Introduction

Microsoft Anti-XSS Library is used to protect applications from Cross-Site Scripting attacks, by providing methods for input sanitization.

Vulnerability

Microsoft Anti-XSS Library 3.0 and 4.0 are vulnerable to an attack in which an attacker is able to create a specially formed CSS, that after passing through the GetSafeHTML or GetSafeHTMLFragment methods, contains an expression that triggers a JavaScript call in Internet Explorer.

The following ASP.NET code demonstrates the vulnerability:

1. string data = Microsoft.Security.Application.Sanitizer.GetSafeHtml("<html>a<style></style><div>b</div></html>");

2. string data = Microsoft.Security.Application.Sanitizer.GetSafeHtmlFragment("<div style=\"font-family:Foo,Bar\\,'a\\a';font-family:';color:expression(alert(1));y'\">aaa</div>");

Explanation

The string value can be broken down as follows:

div{

font-family:Foo,Bar\,'a\a';

font-family:';color:expression(alert(1));y'

}

A bug in the Anti-XSS library causes the closing apostrophe in the first CSS rule to be dropped. Because of the string not being properly terminated, Internet Explorer now renders this CSS in a different way, which triggers a javascript call:

div{

font-family:Foo,Bar\,'a\a;font-family:';

color:expression(alert(1));

}

Impact

Every application that relies on either GetSafeHTML or GetSafeHtmlFragment to sanitize user supplied data is vulnerable to XSS.

Remediation

Microsoft has issued a the Anti-XSS library 4.2 to address this issue.

References

http://www.securityfocus.com/bid/51291
http://technet.microsoft.com/en-us/security/bulletin/ms12-007

Testing RESTful Services with AppScan Standard

2012-01-15T13:36:09+02:00

As much as I love SOAP web services (not!), it seems like RESTful web services really caught on and became a de-facto standard these days – you see them everywhere, in the cloud, in AJAX or Web 2.0 applications, mobile applications and so forth.

Unlike SOAP services, RESTful services are lightweight. They are extremely easy to understand and also to develop. Nevertheless, there seem to be a million different definitions as to what they really are, but I think the simplest way to understand them is by using the following four definitions, which I’ve found in this DeveloperWorks article:

RESTful services use HTTP methods explicitly
RESTful services are stateless
RESTful services expose directory structure-like URIs
RESTful services transfer XML, JSON or both

Simple right?

As much as RESTful services are simple for humans to understand, they are actually a nightmare for automated web application scanners. Why? Because classic HTTP requests usually include parameters either in the Query or Body part of the request. On the other hand, RESTful services usually pass them as what looks like directories (see rule #3 above). For example – the following HTTP request will return the details for a user named Bob:

GET /data/users/Bob/ HTTP/1.1

Host: www.some.site

Connection: close

If this was a standard HTTP request, I would tell you that there’s a good chance you’re looking at a web server that contains 3 directories under its virtual root /data/, /users/, and /Bob/, but that’s not the case. This request, tells the RESTful service to retrieve (GET) the account information for user Bob, which is a part of the /users/ list in our data repository.

When an automated scanner crawls the web application, there’s a good chance that out-of-the-box, it won’t figure out that we’re looking at a RESTful service here, and it will consider these parts of the URL as directories. This means a few things:

Directory-level tests will be sent to the wrong places – potential false positives
Parameter-level tests will not be sent to the right places – potential false negatives

IBM's AppScan Standard enables you to train it to cope with RESTful services, using one of two options – Manual or Automatic configuration. Let’s start with the manual option.

Custom Parameters

By default, AppScan automatically recognizes parameters in standard HTTP & HTML formats, but if parameters are in other formats (for example within the Path or within another parameter), you need to define them manually, so that AppScan would be able to recognize, follow and manipulate them during scanning. This is done from the Custom Parameters definition, which you can find under Scan Configuration -> Parameters and Cookies -> Advanced: Customer Parameters.

In order to create a new type of custom parameter definition, you have to click the “+” button, which opens the following screen:

Let’s see a step by step process of adding a definition that will properly parse and test our “users” parameter in the example above.

We’ll start by giving this custom parameter definition the Reference Name RESTful_Path_Parameter
In the Pattern field, we’ll enter the regular expression /data/([\d\w\s%]+)/([\d\w\s%]+)/ - This pattern includes two match groups, i.e. /data/group1/group2/, group1 denotes the parameter’s name, and group2 the parameter’s value
Since the name of the parameter is the first match group, we will define the Name group index as “1”, and since the value of the parameter is the second match group, we will define the Value group index as “2”. This tells AppScan to extract the name of the parameter from group1, and the value of the parameter from group2. If you are dealing with a Path that only includes a parameter value (i.e. nameless parameters), you can set the Name group index to an empty value, and only mark a single value group
Our RESTful service uses Path based parameters, so we’ll set the Location to “Path”. In general, you can set it to either “Body”, “Path”, or “Query”.
In our scenario, we’ll leave the Condition Pattern empty. This pattern helps us to limit the behavior of the custom parameter definition, by setting another pattern match on the Location. For example, we could’ve defined the Condition pattern to be: ^/data/, and then our pattern parameter definition would only be relevant for Paths that actually begin with /data/.
In addition, in our scenario, we will leave the Response Pattern empty. Just as an FYI - this pattern helps us to teach AppScan how to track the values of our custom parameter in scenarios where the application treats it as a session ID. In such cases, the application might not only embed new values in Paths (e.g. in web links), but also in other places in subsequent responses, such as XML elements, for example: <newSessionID>12345678</newSessionID> - In this case, we would have defined the following Response Pattern:
<newSessionID>([0-9]+)</newSessionID> - this tells AppScan that even though in the HTTP request, the parameter is called users, it should extract new values from an XML element in subsequent responses, that is called newSessionID. Tricky, complex but nevertheless useful!

That’s it. Once we have our custom parameter definition in place, we can let AppScan crawl and test the application normally. After the Explore phase, you can have a peek in the Data view, and look at the Script Parameters table:

As you can see above, each new RESTful parameter that is extracted and analyzed by AppScan is given a special name in the following format:

__patternParameter__[REFERENCE_NAME]_[NAME_GROUP]__INDEX

In our case, AppScan detected the users parameter with 2 values – Bob and Jane, and the books parameter with two values Bobs Biography and Janes Biography.

The INDEX part of the custom parameter is helpful if the regular expression that we created, caught on the same Path more than once. For example, consider the following Path:

/data/users/Bob/data/phone/areacode/

our pattern would actually match twice on this Path - the first match (index = 0) would set the parameter name to be users and its value to be Bob, and the second match (index = 1) would set the parameter name to be phone and the its value to be areacode. In such case, the name of the custom parameter would appear as:

__patternParameter__RESTful_Path_Parameter__phone__1

Explore Optimization Module

Mastering AppScan’s custom parameters definition could be a daunting task, but this feature is extremely powerful and will allow you to create complex definitions that could parse non-standard HTTP messages of any type and form. If you are in a hurry, lazy, or simply hate regular expressions, there’s an automated way to detect custom parameters by using AppScan’s Explore Optimization Module, which is available through the Tools->Extensions->Explore Optimization Module (Configure or Run):

This extension runs a smart algorithm that will statistically detect URL rewriting rules, such as those that are heavily used by RESTful web applications to generate its directory structure-like URLs. For example, given enough URLs of the format /data/users/VALUE/... this module will automatically generate a custom parameter definition for you.

How much is “enough URLs”? This depends on the configuration of the module and specifically on its Switch Complexity Limit, which by default is set to 50, meaning that you must have 50 different values for the /users parameter.

If you want this module to automatically kick in during scans, you can enable it by going to: Tools->Extensions->Explore Optimization Module: Configure, and checking the box next to Always run automatically during scans. The module will start working once AppScan has crawled 1,000 URLs. You can increase or decrease this default threshold through the Minimum links to start module configuration. If you suspect that your application is using RESTful services, and the module was disabled when you first scanned it, you can always simply run it by going to: Tools->Extensions->Explore Optimization Module: Run

After the module ran, AppScan’s scan log will include special messages related to this module, for example:

There you go. All I had to do was to let AppScan crawl the application for a few minutes, then Run the module, and it automatically created a custom parameter definition with the regular expression users/([^/]+)

In general, the more URLs you have, the better this module will behave.

It is also iterative - if you continue scanning the application after it created the first round of definitions, and once it hit the threshold again, or once you clicked on Run, it will refine these rules and create new ones where needed. Simple and elegant, albeit less accurate and powerful than the manual option mentioned earlier. That's it.

This post was a bit long, you probably need a REST now.

Through the Looking-Glass

2011-11-16T12:32:29+02:00

In recent years, I've heard many industry luminaries lament the untimely death of black box web application security assessment tools. Most of them did so, on the basis that white box tools (static analysis code scanners) will eventually rule the world and bring order to our galaxy.

The top three rants against black box testing tools were usually –

Application coverage (or lack thereof)
Scan results inaccuracies (false positives, negatives, and non-exploitable issues)
Lack of code-level information for issues reported (mainly, vulnerable line of code)

Regardless of these problems, many still consider black box testing tools to be more accurate, practical and mature tools. Issues reported by black box scanners are usually real and exploitable, and they are less prone to generate noisy results than white box testing tools (taint analysis covers all code paths, which can be a double-edged sword)

Our team has been working extremely hard to remediate these shortcomings, and find creative ways to make automated black box testing more efficient, accurate and to make our customers more successful in securing their web applications. Our latest innovation was dubbed Glass box testing. Actually, it's not such a new idea - this is something that we have been toying around with for many years (we eventually filed the patent back in Feb. 2008)

Finally, it is here.

One of the main drawbacks of black box testing is the fact that the tester (or tool) is completely oblivious to the inner workings of the tested application it is facing. It is unaware of the programming language, the operating system, database server and so forth. The entire process of issue validation in black box testing relies solely on how the application reacts to certain HTTP requests. For example - you send a SQL injection test and then expect to see a SQL syntax error sent back in a subsequent response. Sadly, many of the most critical issues may never reflect back in some scenarios.

Glass box testing, avoids the classic black box pitfalls, by deploying a server-side agent, which gleans critical application information in runtime, and sends it back to the black box scanner. The type of information relies on the type of agent being used, and the location at which it operates, within the application or near it.

For example, imagine a glass box agent, which performs code instrumentation to the tested web application, it sits in critical points and monitors certain events. When a black box scanner sends a SQL injection test, that will reach a sensitive method (sink), our glass box agent will be able to notify the scanner that a vulnerability exists [Problem #2 solved]. Moreover, it will be able to report back on the vulnerable file name, line number, enclosing class and method, as well as the library class and method that was vulnerable –e.g. Java's executeQuery [Problem #3 solved]

In order to solve application coverage issues, various different kinds of glass box agents can be used, the simplest would be an agent that monitors the web application's file system, and submits back information about its structure and files. A run time code instrumentation agent similar to the one mentioned earlier, could also detect certain unreferenced parameters - those that are mentioned in code, but never referred to by HTML - like 'debug' parameters [problem #1 solved]. There are many other things a glass box agent could do to improve and complement black box testing, this is merely the tip of the iceberg.

Up until now, I discussed the merits of glass box testing in general. Now I would like to briefly discuss the unique capabilities we've built into AppScan Standard 8.5 that was released yesterday.

AppScan’s first glass box agent, performs runtime analysis through code instrumentation of web applications. It hooks into the application, and observes critical application points, reporting vital information back to AppScan Standard. This information includes:

Monitoring of sensitive methods (sinks) for a range of application layers attacks, bringing unparalleled ultra high accuracy to existing issue detection, as well as the capability to detect issues that black box scanners simply can't spot
Detecting unreferenced application parameters, and increasing application crawling coverage dramatically

Other than the cool detection capabilities that were implemented, we had to make sure our users are successful in deploying and using glass box. We can't simply build a half-baked prototype, right? So we baked into it some nifty and important features such as:

Simple agent installation, through an automatic installer for Windows, Linux and Unix
Manual agent installation & step-by-step guide for complex systems and environments
Agent authentication & support for SSL communications with AppScan
Agent command & control, which allows AppScan to remotely push new (digitally signed) logic & rules into deployed agents
Reduced agent footprint. When the agent is not being actively used, it stops monitoring the application to avoid even the minimal effect on performance
Real time agent status monitoring. From as early as the scan configuration phase, and through the entire scan, AppScan users know exactly what is going on with the agent. Is it up, down, monitoring or configured improperly
Agent logging. Glass box logs can be remotely configured and accessed from AppScan's user interface
Agent management. A cross-scan persistent management of known agents, so you won't have to configure the same things over and over again.

As you can see, we take glass box testing very seriously. This is not just a new feature in the product.

We believe glass box is the future of dynamic analysis.

We continuously benchmark our glass box testing capabilities on many different web applications, trying to assess the exact increase in scan accuracy and coverage. In reality, it really depends on the specific application that is being tested. But when we ran AppScan Standard 8.5 with and without glass box, on a sample set of the standard known vulnerable web applications, we found that it brings an increase of at least 180% in real true findings, and removes false positives completely.

Glass box testing provides the best of both white and black box worlds. It enjoys the merits of dynamic analysis - the fact that it is testing a real live web application, and provides real exploitable issues without any noisy ‘theoretical’ results. And at the same time, it enjoys code-level information, similar to static analysis - the ability to look at the application's code and inner workings, and tie each issue to the specific location where the defect lies.

In fact, this reminds me that glass box testing is actually not our first attempt to marry white box and black box – our previous product release, included the highly successful groundbreaking JavaScript Security Analyzer, which uses a hybrid dynamic and static analysis engine, to analyze JavaScript code for client-side vulnerabilities. Back when it was released last year, we reported that JSA found JavaScript issues in 14.5% of the Fortune 500 web sites – in AppScan Standard 8.5, we actually went back and improved our analysis algorithms, and we now know that JSA finds security issues in 40% of the fortune 500 web sites (as reported in the latest 2011 IBM X-Force trend analysis report). That is an incredibly awesome yet disturbing piece of data.

In order to give our customers the best possible way to secure their applications, we are continuously blurring the lines between the different types of analysis approaches. I personally think that the entire black box vs. white box debate is way past us. Security testers shouldn’t really care what analysis they are using, as long as it produces accurate and actionable results.

Glass box testing is available as a feature of AppScan Standard Edition 8.5, and does not require any integration with other IBM products. Simply download and install AppScan Standard 8.5
Glass box testing is a patent pending technology – US patent application 20090205047
AppScan Standard customers can download the latest release, which includes glass box testing from this link

JSON-based XSS exploitation

2011-10-24T17:22:54+03:00

JSON rendering in Internet Explorer

In the world of Web2.0 and mash web applications, security researchers come across more and more XSS vulnerabilities that are reflected in non HTML responses.
For example, JSON responses are becoming more and more common, but exploiting XSS vectors in those pages is considered theoretical because browsers pop up the file download dialog instead of rendering the response when the returned content-type is application/json or application/javascript.

There are a few known methods to indirectly exploit these issues:

1. Attacking the JSON parsing mechanism:
Some applications use JS evaluation functions in order to create an object from the returned JSON content. If the attacker is able to inject, for example, a quote sign, he can break out of the JS string surrounding the value and exploit the XSS through the eval function. For example:
"name":"Foo "+alert(/XSS/.source)+"Bar"

2. Waiting for document.write:
Some applications will write parts of the data returned in the JSON response to the DOM. An attacker can inject HTML content into the JSON response that will be rendered once the application writes it to the page.
For example:
"name":"Foo <img src=x onerror=alert(/XSS/.source)>Bar"

Although the previous methods will work, they have a few limitations:

Not all applications have the logical flow needed in order to exploit these attacks.
Some applications use client side filtering that will prevent them from running.

After thorough research on alternative ways to exploit these types of vulnerabilities, we have discovered a way to render JSON responses in IE by direct browsing.

The way IE decides what content-type will be used for a specific response is as follows: (As discovered by Black-Box research)

The suggested (server supplied) content-type is searched for in the windows registry for the corresponding CLSID, in order to find the correct handler for that response.
If the suggested content-type is found, IE will consider that to be the final content-type.
If the suggested content-type however is not found, IE will attempt to figure out the content-type based on the file extension and other vectors.

JSON responses generally use the content-type application/json, the problem is that the default mime type list of Internet Explorer does not include that mime-type, in fact it does not include any JSON mime type whatsoever.

Example scenario while browsing to a link which returns JSON content:

User browses to http://attacker.com/json.php
Internet Explorer searches the windows registry (HKCR\MIME\Database\Content Type\) for the returned content-type (application/json). – Not found.
Internet Explorer searches the windows registry (HKCU\Software\Classes\) for the file extension (.php) – Not found.
Internet Explorer prompts the file download dialog.

From this scenario we can conclude that in cases where the server returns content-types that are unknown to Internet Explorer, the file extension (in addition to other factors not covered here) dictates the final content-type that will be used.

In order to force IE to render JSON responses, the file extension in the URL must be set to something that IE consider as text/html (.htm or .html).

The way most web servers parse the path from a request is this:

The user requests the page http://site.com/html/pages/page.php?id=1
The server starts to search for the requested resource at the pre-defined path of the web server (for example /var/www/)
The server searches for the path requested by the user one entity at a time (starting from left).
The server finds that /html/pages/page.php is an executable file and stops the search (executable means that the server has some handler that correlates to that file type; in this case the PHP engine).
The rest of the path (id=1) is then passed as a parameter (GET) to PHP.

Most server side languages (.Net, PHP, Python, Perl…) accept another type of parameter to be passed from the URL: Path-Info.
Unlike the GET parameter, in which the delimiter value is the question mark sign (?), path-info uses the slash sign (/) as its delimiter.
For example the previous path for page.php can be expanded into having a path-info:
http://site.com/html/pages/page.php/user=2?id=1
[scheme]://[domain][path]/[path-info]?[get-query]

Once an attacker combines path-info with IE's way of considering content-type values, a wide method of exploiting JSON responses for XSS is achievable.

Consider the following scenario:

The attacker found a reflected XSS in a web application.
When browsing to "http://site.com/page.php?user=bla<img onerror=alert(1) src=x>bla" Internet Explorer pops up the file download dialog (explained in the beginning of this document).
The attacker now adds the value ".html" as a path-info to the URL
The attacker now browses to: http://site.com/page.php/.html?user=blah<img onerror=alert(1) src=x>blah
The server returns the same page (containing XSS) with same content-type (application/json)
Internet Explorer searches the windows registry for the application/json content-type and cannot find it.
This is the point where Internet Explorer uses the file extension of the URL to determine the content-type of the response, only this time the extension IE sees is .html!
Internet Explorer finds the matching content-type for .html files to be text/html, renders the response and fires up the XSS.

Impact:

Client side, tested successfully on:
• Internet Explorer 6
• Internet Explorer 7
• Internet Explorer 8
• Internet Explorer 9
Server side, tested successfully on:
• IIS 5.1 (ASPX , PHP)
• IIS 6 (ASPX , PHP)
• IIS 7.5 (ASPX , PHP)
• Apache/2.2.14 (PHP)

Remediation:

Client side:
• The following registry key will add the content-type application/json and a corresponding CLSID
[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/json]
"CLSID"="{3050f4d8-98B5-11CF-BB82-00AA00BDCE0B}"
Server side:
• In order to remediate this issue in the server side, beyond the normally recommended sanitization of user supplied inputs, we recommend turning off support of Path-Info.

DNS poisoning via Port Exhaustion

2011-10-18T23:20:43+03:00

Today we are releasing a very interesting whitepaper which describes a DNS poisoning attack against stub resolvers.

It discloses two vulnerabilities:

A vulnerability in Java (CVE-2011-3552, CVE-2010-4448) which enables remote DNS poisoning using Java applets. This vulnerability can be triggered when opening a malicious webpage. A successful exploitation of this vulnerability may lead to disclosure and manipulation of cookies and web pages, disclosure of NTLM credentials and clipboard data of the logged-on user, and even firewall bypass.
A vulnerability in multiuser Windows environments which enables local DNS cache poisoning of arbitrary domains. This vulnerability can be triggered by a normal user (i.e. one with non-administrative rights) in order to attack other users of the system. A successful exploitation of this vulnerability may lead to information disclosure, privilege escalation, universal XSS and more.

The whitepaper can be found here.

A few video demos of our Proof-of-Concept:

Attack: Remote DNS poisoning via Java Applets: Cookie theft.
Environment: Ubuntu 11.04, Firefox 7.0.1.
Attack: Remote DNS poisoning via Java Apples: NTLM credentials and Clipboard theft.
Environment: Windows 2008, Internet Explorer 9.
Attack: Remote DNS poisoning via Java Applets: Firewall bypass.
Environment: Windows 2008, Firefox 7.0.1.
Attack: Local DNS poisoning via port exhaustion.
Environment: Windows 2008.

We would like to thank Oracle and Microsoft for their cooperation.

-Roee Hay and Yair Amit

Google App Engine Code Execution Vulnerability (CVE-2011-1364)

2011-10-11T20:18:06+03:00

We have recently identified an interesting code execution vulnerability in the Google App Engine SDK for Python. By combining a CSRF vulnerability in the administration web UI, with some other vulnerabilities we found in the Google python libraries, a remote hacker could gain remote code execution privileges on victim's machine. This vulnerability affects all operation systems running Google App Engine SDK for python (i.e. Windows, Mac OS, etc.).

The full advisory can be found here.

As always, Google has been very quick with fixing the issue. According to the company, the fix was provided in version 1.5.4, which was released on Sep 12th.

Dolphin Browser HD Cross-Application Scripting

2011-09-20T19:50:01+03:00

We have identified that Dolphin Browser HD is also vulnerable to Cross-Application Scripting, by using the same attack vector as of the Android Browser vulnerability we disclosed last month. This vulnerability can be exploited by a non-privileged application in order to inject JavaScript code into the context of an arbitrary domain.

Dolphin Browser HD 6.1.0 has been released, which incorporates a fix for this bug.

The full advisory can be found here.

Demo of the PoC:

We would like to thank the Dolphin team for the efficient and quick way in which it handled this security issue.

Opera Mobile Cache Poisoning XAS

2011-09-20T15:59:35+03:00

Recently we detected a security vulnerability in Opera Mobile for Android which can be exploited by a non-privileged application in order to inject JavaScript code into the
context of any domain; therefore, this vulnerability has the same implications as global XSS, albeit from an installed application rather than another website.

Opera Mobile 11.1 update 2 has been released, which incorporates a fix for this bug.

The complete advisory can be found here.

Demo of the PoC:

We would like to thank the Opera Team for the efficient and quick way in which it handled this security issue.

The Ultimate Web App Security Scanner Comparison Published - AppScan Standard Leads the Pack

2011-08-03T13:42:42+03:00

Shay Chen, an Information Security consultant and blogger, recently published the latest results of his ultra-thorough web application security scanner comparison. The survey, covered 60(!) different open source and commercial scanners, and summarized some of the most critical features and capabilities of each scanner, such as:

Audit features and capabilities
- Active vulnerability detection features
- Complementary scanning features (passive analysis, known issues, etc.)
- Usability, Coverage and Scan Initiation Features
- Authentication, Scan Control and Connection Support Features
- Advanced and Uncommon Features
Accuracy benchmark (performed against WAVSEP)
Cross-site scripting success & false positives rate
SQL Injection success & false positive rate

Needless to say, AppScan Standard Edition led the pack in most aspects - especially around Audit Features and Scanning Capabilities, where no other scanner came even close:

This course no was not a surprise to us - AppScan Standard has been around since the year 1999, and is an extremely mature product - it is capable of scanning *any* type of application, and can be customized to work on every kind of environment it faces (non-standard URLs, RESTful applications, JSON, JavaScript frameworks and AJAX, Adobe Flash/Flex, SOAP web services, etc.).

On the accuracy front - when it comes to detecting Cross-site Scripting (XSS), AppScan performed flawlessly, and ranked #1:

100% detection rate for all of the reflected XSS test cases, and 0% false positives on the false positive test cases (WAVSEP includes special test cases, attempting to trick the scanner to false positive, and AppScan did not fall for that...).

In the SQL Injection tests, AppScan performed extremely well (although did not rank #1), it managed to find 127 issues out of 136 (93.38% success rate), with 3 False Positives out of the 10 False Positive test cases.

Needlees to say, this will be improved and fixed as soon as possible, so that we rank #1 in SQLi as well.
We did demo the next release of AppScan Standard to Shay Chen, which includes a promising new technology capable of dramatically increasing the detection rate for such issues - the results were astounding - 100% success rate (136/136), and 0% false positives! so - stay tuned!

To sum things up, Shay has done an excellent work compiling and comparing a huge amount of scanning tools. I strongly recommend that you review this work, and download each of the comparison sections - it contains all the information needed in order to choose which product better suits your needs.

Last but not least, I would like to mention that the XSS test cases, did not cover DOM-based XSS, one of my favorite topics recently. AppScan is still the only scanner capable of performing true hybrid analysis (harnessing dynamic scanning capabilities with real JavaScript taint analysis) to locate a long list of client-side JavaScript issues.

>> Direct link to the scanner comparison page <<

Android Browser Cross-Application Scripting (CVE-2011-2357)

2011-08-02T13:29:27+03:00

Recently we detected a security vulnerability in Android’s Browser which can be exploited by a non-privileged application in order to inject JavaScript code into the
context of any domain; therefore, this vulnerability has the same implications as global XSS, albeit from an installed application rather than another website.

Android 2.3.5 and 3.2 have been released, which incorporate a fix for this bug. Patches are available for Android 2.2.* and will be released at a later date. Organizations can contact security@android.com for patch information.

The complete advisory can be found here.

Demo of the PoC:

We would like to thank the Android Security Team for the efficient and quick way in which they handled this security issue.