IBM Application Security Insider

Have you scanned your mobile site for vulnerabilities yet?

Mobile sites - Resurrecting security risks

In today's world any self respecting web site must provide access to its services through a desktop browser as well as a mobile device. This basically means that there are two versions to every site, one for desktop users and one for mobile users. Are both secure? How do we know for sure?

First, let's take a quick look at some of the reasons why companies would prefer to have mobile users visit a mobile-based site instead of directing them to the original desktop site.

• Technologies - There are certain technologies that are not supported on a mobile device (e.g. Flash on iOS) that would have to be re-designed to meet smartphone requirements.
• User experience - The user experience is completely different. For example, take the hover action, a desktop user can hover over a certain area and have menus sliding this way and that. But on a mobile device hovering does not exist.

Old Habits Die Hard: Cross-Zone Scripting in Dropbox & Google Drive Mobile Apps

Recently, as part of a broader research into mobile application security, I discovered a security vulnerability in several file-sharing mobile apps:

App Name	Vulnerable Version
DropBox	1.4.6 (iOS) + 2.0.1 (Android)
Google Drive	1.0.1 (iOS)

Exploiting this vulnerability, an attacker could steal arbitrary files from a DropBox / Google Drive user by tricking him into viewing a malicious HTML file inside the mobile app. By abusing the way in which these app render HTML files, an attacker could bypass Same Origin Policy restrictions and read files that are accessible to the app itself, including sensitive user content and application configuration.

Cross-Zone Scripting was once quite common in Desktop environments until it was mitigated by browser vendors. Unfortunately, this vulnerability type has been carried on to the Mobile world, where it is still a threat. As always, it is interesting to see how old vulnerabillities sneak up to new products.

Use Traffic Viewer to Unlock Ultimate AppScan Power-User Secrets

If you have ever worked with an AppScan expert they probably got you to install the AppScan Traffic Viewer. This tool is the Swiss army knife of the AppScan Power user containing a multitude of support features and giving you ultimate visibility on what happens under the covers.

If you didn't use the tool yet you should definitely give it a try. Starting with AppScan 8.6 the tool will be located in the AppScan tools folder ([AppScan Installation Directory]\Tools\Traffic Viewer\TrafficViewerSetup.msi) or can be downloaded from the AppScan Enterprise portal (by going to http://[appscan_server]/appscan_instance/downloads/TrafficViewerSetup.msi).

Built using the model of other HTTP Debuggers such as Fiddler or Paros, it can actually work in both online and offline mode, by loading the AppScan traffic dumps and can give you a post mortem of the security scan without interfering with the scan itself. For example, if your site crashed during the scan and you want to find out which request is responsible for this Denial of Service, Traffic Viewer is ideal to do that.

To obtain the AppScan Standard traffic log you will need to enable it from Tools > Options > Enable Request/Response Logging. In AppScan Enterprise you enable it from the Scan Properties > Log Settings and can download it from the Scan Statistics screen.

I started building this tool when I was part of the AppScan support team and over the years every time when we needed an extra tool or capability in a troubleshooting situation I would add it to Traffic Viewer, so the tool kind of adapted to our support needs. Latest version allows you to text diff HTTP traffic, reproduce HTTP requests, do regex searches, replacements, export traffic to various formats, encode/decode strings and many many other things.

Please watch the video to see a demo of Traffic Viewer and take full advantage of this tool in this release of AppScan Standard and AppScan Enterprise.

 

 

The Most Comprehensive Web Application Security Scanner Comparison Available Marks AppScan Standard as the Leader (Again)

Once again, AppScan has proven to be the leader of web application security testing tools, in a recent benchmark of over 60 commercial and open-source tools published by Shay Chen.

Attack vector comparison (taken from the WAVSEP benchmark review)

The benchmark covered several categories aimed to help choose the web application scanner right for you. A few of the more important categories are the different input vectors a scanner is capable of attacking, the different attack vectors that are in-effect used against the site, and the coverage features included in order to successfully crawl and scan the web application.
This is the 2nd year in a row that AppScan is found to be on top, and we are of course very excited, though not surprised due to AppScan's track record.

toStaticHTML: The Second Encounter (CVE-2012-1858)

HTML Sanitizing Bypass - CVE-2012-1858

Introduction

The toStaticHTML component, which is found in Internet Explorer > 8, SharePoint and Lync is used to sanitize HTML fragments from dynamic and potentially malicious content.

If an attacker is able to break the filtering mechanism and pass malicious code through this function, he/she may be able to perform HTML injection based attacks (i.e. XSS).

It has been a year since the first encounter was published, we've now returned with a new bypass method.

Vulnerability

An attacker is able to create a specially formed CSS that will overcome toStaticHTML's security logic; therefore, after passing the specially crafted CSS string through the toStaticHTML function, it will contain an expression that triggers a JavaScript call.

XSS Analyzer Gives You 700 Million Reasons To Feel Secure

When it comes to detecting Cross-Site Scripting (XSS), AppScan is the industry's #1 tool. Today we're making it even better.

AppScan's "XSS Analyzer" is one of the most significant DAST innovations in recent years. It breaks the mold of the standard way of doing black-box testing, that has been essentially unchanged for the last twelve years, and really does something new. Something fresh. Something exciting.

Here's why we believe XSS Analyzer sets itself apart from any other scanner out there: XSS Analyzer works and thinks like a human pentester does. We've packaged the experience and expertise of the best pentesters in the industry, together with the broadest possible knowledge about the different ways to exploit XSS. Essentially, we've created an "expert human pentester in a box".

A spotlight on JSA, the amazing hybrid security analysis for JavaScript

By now you have probably heard about JSA. Introduced in AppScan Standard 8.0 in Oct '10, and now included in AppScan Enterprise 8.6, JSA is a component that does static analysis of JavaScript to detect a range of client-side security issues. Issues such DOM-based XSS, Open Redirect, and many others.

Why is this significant? 

Client-side code percentage in web applications grew from around 5% five years ago, to an amazing 25% today. Driven by the Web 2.0 explosion, JavaScript is now everywhere, on every web page. And guess what -- it's painfully full of security holes. Evil, nasty ones, that are particularly difficult to catch.

We were really surprised when we discovered that nearly 1 in 6 of the Fortune 500 websites have serious, exploitable security issues in their JavaScript code. You can imagine this got a lot of attention when we shared these news with the world. It quickly become the #1 downloaded whitepaper in IBM Rational.

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

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.

 

Microsoft Internet Explorer 'toStaticHTML' HTML Sanitizing Information Disclosure Vulnerability (CVE-2011-1252)

HTML Sanitizing Information Disclosure - CVE-2011-1252
Introduction
The JavaScript function toStaticHTML, which is found in Internet Explorer 8 and Internet Explorer 9 is used to sanitize
HTML fragments from dynamic and potentially malicious content.
If an attacker is able to break the filtering mechanism and pass malicious code through this function, he/she may be
able to perform HTML injection based attacks (i.e. XSS).

Vulnerability

An attacker is able to create a specially formed CSS that after passing through the toStaticHTML function will contain

an expression that will trigger a JavaScript call.

 

The following JavaScript code will demonstrate the vulnerability:

Vtiger CRM Path Traversal & Malicious Code Execution Vulnerabilities

Summary:

A Path Traversal vulnerability exists in Vtiger CRM release 5.1.0 (Linux) and 5.2.0RC (Windows), which allows a malicious user to view the contents of any file that resides on the machine on which Vtiger CRM is installed. In addition, when the malicious user can place his/her own PHP file on the same machine, this vulnerability can be used in order to execute the contents of that PHP file under the permissions used by the Vtiger CRM application.

Description:

the vulnerability exists in the parameter 'login_theme', which is passed as a part of the login request to the application, as can be seen below:

[Login, HTTP Request - Line Wrapped]

POST /vtigercrm/index.php HTTP/1.1
Content-Length: ...
Content-Type: application/x-www-form-urlencoded
Host: www.vuln.site
Connection: Keep-Alive

module=Users&action=Authenticate&return_module=Users&return_action=Login&
user_name=standarduser&user_password=user&login_theme=[MALICIOUS_PAYLOAD]&
login_language=en_us&Login.x=41&Login.y=20

[End of HTTP Request]

In order to exploit this vulnerability, a malicious user can manipulate the value of the 'login_theme' parameter, to a value such as: