IBM Application Security Insider

Building Rich Internet Applications Models: Example of a Better Strategy

Crawling “classical” web applications is a problem that has been addressed more than a decode ago. Efficient crawling of web applications that use advanced technologies such as AJAX (called Rich Internet Applications, RIAs) is still an open problem. Crawling is important not only for indexing content, but also for building models of the applications, which is necessary for automated testing, automated security and accessibility assessments and in general for using software engineering tools. This paper presents a new strategy to crawl RIAs. It uses the concept of Model-Based Crawling (MBC) and introduces a new model, the “menu model”, which we show to be much simpler than previous models for MBC and more effective at building models than previously published methods. This method and others are compared against a set of experimental and real RIAs.

The SSRG research team will present these findings at ICWE 2013, 11 July@16:00, Aalborg, North Denmark.

Keywords: Crawling, RIAs, AJAX, Modeling

Suryakant Choudhary, Mustafa Emre Dincturk, Seyed Mirtaheri, Guy-Vincent Jourdan, Gregor Bochmann and Iosif Viorel Onut.
Building Rich Internet Applications Models: Example of a Better Strategy
in Proceedings of the 13th International Conference on Web Engineering (ICWE 2013), Aalborg, North Denmark, July 2013.
To be published in Lecture Notes in Computer Science by Springer.

Conference link: http://icwe2013.webengineering.org/
Accepted papers link: http://icwe2013.webengineering.org/accepted-full-papers
Link to the .pdf paper: http://ssrg.site.uottawa.ca/docs/ICWE2013.pdf

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.

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.

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.

Handling Complex Scenarios with AppScan's Custom Parameters

If you are familiar with web technologies, either from assessing them for security, or from developing them, you are probably aware of the many innovative ways developers choose to implement web applications. The days of following the HTTP RFC are long gone - developers do whatever they need to do, in order to make things work.

For example, HTTP Parameters are passed as a part of the URL (e.g. REST), tokens are passed as HTTP headers (e.g. CSRF protection) instead of as cookies or parameters, parameter values are concatenated with weird strings instead of ampersand (&), XML islands inside HTTP request body, JSON, etc.

Testing RESTful Services with AppScan Standard

By Ory Segal

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:

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

Simple right?

Through the Looking-Glass

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 –

1. Application coverage (or lack thereof)
2. Scan results inaccuracies (false positives, negatives, and non-exploitable issues)
3. 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.

Proactive Malware Scanning

I'll start with a short personal angle -

I have a friend that works as a freelance web site developer and webmaster. Once in a few weeks he gives me a call, telling me that one of the sites he manages seems to be serving malicious JavaScript code to its users. It appears to me that this problem is getting out of hand these days, sites are getting (silently) hacked into, and JavaScript code is injected and later on served to users.

From what I hear and read, more than 70% of the Malware today is being served or linked from legitimate web sites.

Take a look at this article from InformationWeek, which was posted in January 2009:

Seventy percent of the top 100 Web sites either hosted malicious content or contained a link designed to redirect site visitors to a malicious Web site during the second half of 2008

The common approach to Malware protection and Malware scanning today, puts the (security) responsibility on the end users (browser protections, A/V, etc.) or the organizations (content filtering gateways, A/V gateways) from which the end users browse the web from.

I think that web site owners should start taking responsibility for the contents they are serving to users, and a simple way to do that, is to constantly monitor or scan your own web application for malicious contents.

About two years ago, I had an interesting thought - if you are already scanning your web application with an automated scanner, that has the capability to perform deep crawling and analysis (using automatic form filling, JavaScript and Flash execution, etc.), why not attempt to locate malicious code that is being served to your web users?!

BTW, malicious code can end up in your application in different ways such as -

• Someone hacked into your application and put it there
• You are including web contents (or application code) from a 3rd party. This is oftentimes the case in Web 2.0 scenarios
• You pissed off one of your web developers, and they decided to get back at you by infecting your users with Malware

Enter Malware Scanner AppScan eXtension

The Malware Scanner AppScan eXtension helps you verify that your application is not hosting or linking to malware. The extension couples the deep-scanning capabilities of IBM Rational AppScan with ISS X-Force technology that is used to identify malicious content and links.

The Malware Scanner checks these conditions:

• Files hosted on your application are malicious or not
• Files that are "one click" away from your application are malicious or not
• Links on your site lead to malicious domains (malware sites or phishing sites, for example)
• Links on your site lead to unwanted content (illegal sites, hate sites, adult content, and so forth).

The Malware Scanner works in two phases:

1. It passes all of the visited links through the ISS Virus Prevention System (VPS) engine, to determine whether they are malicious or not. This is similar to browsing every page in your application, including clicking every button and downloading every file, using a machine with updated antivirus software.
2. It passes all of the links that lead to external domains through the ISS WebFilter SDK. This SDK then fetches the classification of each link (news site, porn site, malware site, illegal site, and so forth), based on the constantly updated online classification database. Links that are deemed malicious or unwanted are flagged for your attention.

When something needs to be brought to your attention, a security issue is created in Rational AppScan so that you can benefit from the strength of Rational AppScan results management capabilities, such as creating reports, saving and loading scans, and so forth.

You can read more about the Malware Scanner eXtension and download it from our eXtensions web site (you need to have AppScan installed to run it).