As we all know, web application scanners are meant to assist a user in identifying the vulnerabilities in a web application. The user/ audience for this tool can be penetration testers, developers or auditors. The true potential of any tool can be extracted only by a user who understands the domain and the tool he is operating. That means, these tools should only become in assisting a skilled or semi skilled person to conduct a web test. Even after more than a decade of engineering a security scanner for web applications, we see mixed reports on why some scanners perform poorly while some perform better. From my experience, most of the benchmarking reports I see are for test websites and when it comes to real applications, most of the scanner’s perform relatively the same.

If web application tests are compared to network tests, it will be noticed that web application tests are considered to be costlier than network tests. Day-by-day network tests will only become cheaper but web application tests are not going to follow that path. The classic difference is that network tests are conducted on a well defined protocol where it is meant for the machines to understand. If you look at the nessus plugins, it would be quite clear that the attack request and its response communicate a well defined protocol and structure. While in the case of web applications, even though the protocol it uses is HTTP, the crux of the problem is in understanding the context within which the application tests are conducted. Here also, there are reliable tests with zero false positives possible if it is fairly based on injections, error/pattern matching etc. But what about business logic tests, privilege escalation tests etc. Can they be truly automated?

So here, I would like to discuss one aspect of web application testing and check out the possibilities of true automation, where even a person who is not qualified to do a test should benefit from it. I will particularly refer to some aspects of OWASP testing guide v3’s Session Management testing [1].

Session Management Testing

At the core of any web application is to handle state information and there by handle the user interaction with the target site. As the transport mechanism used is HTTP, and it being a stateless protocol, the state needs to be carried in a way so that the client and server understand it. This session or state information can be tracked in cookie, URL or hidden form parameters at the client side and when it is transferred to the server, this information can be located in URL, Cookie header or in the body of the request (as a URL encoded data). Understanding these basic concepts, now let’s see how different black box tests can be truly automated and what could be the challenges in automation.

In a true automated scanning for session management, the scanner should be able to login to the application. This could be fairly simple to complex, based on how the scanner automatically detects the login page and processes it. Some heuristics can be applied for detecting login page, such as; if there are only two input boxes and the type for one input box is ‘text’ and the type for the other input box is ‘password’. Now this heuristic may apply in most cases but processing login page itself involves rather other set of problems like execution of javascript and rendering of the DOM, the URL for form submission is only generated by java script, the form submission for login is an event etc.

In a simple scenario, where the credentials are given in the scan profile and if the scanner should make an automatic login to the application, it needs to understand the difference between a successful login and a login failure. To automatically understand this difference, a scanner can send “n” number of login requests with wrong credentials and create a statistical score of the failed login pages. Once the scanner understands how a login failure looks like, then it can submit the form for login with the correct credentials and check the statistical difference of this page’s response to the failed login pages. In this way, to some extent a scanner can reliably learn a successful login page attempt.

Another key challenge for the scanners is to understand the true order of execution of java script events in a page. This is an open problem in truly understanding the order of events. A scanner can try out all the “n” possible combinations of event execution starting from a pivot event and later process the branches independently. This way of execution is very time consuming and it will lead to an exponential order to even complete the testing of a single page. As with web 2.0 applications, this complexity will only rise and the practical solution is to do a depth first search of events or a breadth first search of events and test it accordingly, so that ensuring at least a registered event for an element is executed once.

Another millennium challenge would be truly testing for privilege escalations. Considering the case where, the scan profile consists of two or more different user role credentials, then the scanner can automatically login to the application. Now if the scanner keeps the map of resources that are accessible from each role after authentication, the scanner can try to access the resources (which are not present in the current role’s list) listed in other roles. This might sound fairly simple but it is awfully complex to implement for any real world application. Some of the reasons are (1) Determining two responses whether they are the same or not has a context involved in it (2) Order of execution of events cannot be determined (3) if the resources are dynamic pages, then that requires valid query parameters etc. Most of the problems for true automation of testing arise because of the way web applications are designed and developed.

Other than that, some of the easy and automatable cases in session management testing are given below:

Testing for Set-Cookie directives tagged as Secure.

This test for checking “secure” attribute can be truly automated after fetching the Set-Cookie header value and parsing the Cookie object or doing a pattern matching for “Secure”.

Testing for Cookie operations over unencrypted transport

This test can also be truly automated by checking the scheme of transport for any transaction where cookie is transferred to the server.

Testing for Cookie be forced over unencrypted transport

This test can be truly automated based on certain conditions such as assumption of an HTTP service running at any other port. The test can check for sending of cookie to the default HTTP port and as it is not an encrypted channel, we can check the response coming from the server. If the HTTP is not running on a default port, then this test will fail to complete.

Testing for Cookies persistence.

This test can be truly automated by checking the attributes of the cookie and also checking if the cookie’s are deleted once the session is expired.

What Expires= times are used on persistent cookies, and are they reasonable?

This test can be truly automated and a check on reasonable value of expiration can be compared with a policy set with the scan configuration/profile.

This is not a comprehensive guide on explaining what all can be automated for session management testing. The objective for this post was to make others aware of some of the challenges in building true automation for testing. So a tool like scanners should only assist any user in conducting his test for the application. Even zero false positive scanners’ can not be absolutely zero false positive if they are intending to have larger coverage of OWASP test cases. If it is solved in any innovative way, I would like to read a research paper regarding the same.

[1] https://www.owasp.org/index.php/Testing_for_Session_Management

Some days back, when I was going through the record breaking statistics of Facebook and its social networking platform’s REST APIs,  I found phrases like “People on Facebook install 20 million applications every day. More than 2.5 million websites have integrated with Facebook”. It  really shows the incredible power of REST APIs and probably it is just a start. Apart from Facebook, the list of API provider applications providing REST APIs is increasing day by day, some of these applications include LinkedIn, Google, Bing, Delicious, GroupOn, Paypal, Twitter, Salesforce and so on. The number of 3^rd party applications built on top of REST APIs is also drastically increasing. Probably, we are going to see atleast thousands of 3^rd party applications in the near future, built on top of REST APIs, creating a true mesh of applications never seen before.

However, everything comes with a cost and here the cost can be loss of your privacy, social and professional relationships, money and confidential data. As a result, it is extremely important to know and remediate various security risks involved with REST APIs and 3^rd party applications. In this post, we will discuss some of the major security risks involved from the perspective of end users. In the end, we will demonstrate a real life scenario of privacy breach of a victim user.

There are two main scenarios to access API provider application by a user.

Scenario 1:

You access your API provider application directly over the
HTTP layer with proper security mechanisms provided by the application.

Figure 1: Scenario 1 where a user accesses API provider application directly

Scenario 2

You access your API provider application’s features via a 3^rd party application on your browser. 3^rd party application is responsible for making REST API based calls to API Provider App to implement necessary features. Authentication and authorization is provided by upcoming standard called OAuth.

Figure 2: Scenario 2 where a user accesses API provider functionality via a 3rd party application.

Threats

Following table shows how a 3^rd party application can put a user under various security risks even if API Provider Application is secure from major security flaws. As shown, XSS/CSRF/Broken Authentication puts a user under the same risk as that of 3^rd party application. On the other hand, Injection / Broken Authorization puts  you under different risks depending upon exact functionality of 3^rd party application.

Table 1: OWASP Top 5 Risks and comparison of how an  insecure 3rd party application can make API Provider App insecure.

An illustration

Consider the following scenario where a popular social / professional networking site like LinkedIn or Facebook is an API Provider Application and there are 3^rd party applications that provide functionality to make REST APIs calls to them.  Say LinkedIn is secure from CSRF vulnerability, however there is CSRF vulnerability in 3rd Party application and as a result, we will show, it is possible to trick a victim user, say, to add an attacker as a contact in LinkedIn’s professional network.

In summary, attack sequences are described as following. Figure 3 demonstrate the attack sequences diagrammatically.

Figure 3: Flow depicting how an attacker exploits CSRF flaw in a 3rd party application.

Step 1: Attacker creates a blog with title called “REST API for dummies”.  Attacker shares the blog post with the victim user.

The blog recommends 3rd Party application to try REST API calls. 3rd Party application is integrated with LinkedIn using OAuth protocol. OAuth authenticates and authorizes every 3^rd party application before it can make any REST API call. Attacker creates a JavaScript exploit embedded in the blog post. The exploit utilizes CSRF vulnerability in the 3rd Party application to send a friend request to the attacker on  behalf of the victim user, without victim user’s real intention and knowledge.

Figure 4: An example blog created by attacker, embedding a JavaScript exploit.

Step 2: Victim user follows the blog and open 3rd Party application in a new tab of web browser.  Victim user selects OAuth option to authenticate and authorize 3rd Party application to make REST A
PI calls to LinkedIn.

Figure 5: 3rd Party application asks for a permission to get access to victim user’s LinkedIn Account

Step 3: The JavaScript exploit, embedded in the blog post, makes a HTTP Post request to 3rd Party on  behalf of the victim user.  As a result of CSRF vulnerability in 3rd Party application, HTTP POST will trigger logic at the backend server of 3rd Party to create a REST API call to LinkedIn. In the current example, exploit will send a fake friend request from victim user to the attacker.  However, as a generic  case, it is possible to post a comment, read the mailbox or perform any other action supported by LinkedIn REST APIs.

Step 4: A friend request email will be sent to attacker. Attacker can easily accept the invitation and add victim user as a friend in LinkedIn’s professional network.

Figure 6: An illustration of successful exploitation. Invitation mail sent to attacker on the behalf of victim user’s LinkedIn Account.

Conclusion

Application Mesh ups and REST APIs bring new dimensions to web application security. Security challenges of REST APIs need to be discussed, formalized and remediated.

In the next few blogs, I will explore some of the following topics:

1. REST API and Next Generation Threats: Part 2
2. REST API and Security Remediation from perspective of API providers, 3^rd party applications and end users.
3. REST APIs and role of Web Application Penetration Testing.

Please feel free to provide your valuable comments, questions and suggestions and stay tuned.

Mr. John (name changed) is the senior security manager of one of the large organization in the world.  Mr. John enforces best of the security policy to protect his organization from latest threats and risks. He has deployed best of the anti-virus on all the desktops and servers. He keeps all the anti-virus signature updated all the time. He has deployed firewalls at the perimeter of his organization’s network.  He has deployed IDS/IPS to detect any malicious activity in the network proactively. He enforces regular backup and has incidence response team to act upon any unforeseen event. Mr. John trusts Anti-virus, firewalls and IDS/IPS to implement best of the network security in his organization.

Very recently, during our penetration testing assignment with Mr. John’s organization, Mr John and his senior management team asked us, “How secure are my anti-virus and firewalls?”. They also wanted to know vulnerability trends in the security products.

We did some survey on the internet to find something closely related to vulnerability trends in security products. As part of our survey, we came across some interesting articles like Security Vulnerability found in almost all antivirus and security products, IBM: 2010 Mid-Year Trend and Risk Report, Secunia: Half Year Report for 2010 shows interesting trends and many more but nothing was close to what we were looking for. Finally we decided pull out data from NVD vulnerability database and run some SQL queries to create some interesting statistics. We decided to publish the statistics as whitepaper to benefit whole security community. You can download the latest copy from here.

History of Vulnerability finding in Security Products

Following figure shows vulnerability finding in the security products for last 10 years (since big bang, year 2000 was the year when first of the vulnerabilities were reported in the security products).  As shown, security products are not immune from vulnerabilities and security flaws. In fact,  your anti-virus and firewalls are often deployed at perimeter and gateways and as a result they are the most lucrative targets for the attacker to compromise your network and personal desktop. Interestingly, year of 2005 saw a great increase in vulnerability findings in the security products.

Vulnerability findings in major Security Product Types

We classified the security products into major classes of Anti–virus (personal, enterprise, mail, gateway etc), Firewalls (Network, Web Applications etc), IDS/IPS, VPN and others (others include products like security management softwares, NAC devices and other miscellaneous security softwares).  Following figure shows that all the classes / types of security products are affected by security flaws. Anti-virus tops the list with 625 vulnerabilities reported upto end of 2010 year, followed up by firewalls.

Deep Diving

When we dig deeper, we found out that Cisco (with overall 838 vulnerability findings) tops the list of security vendors affected by vulnerability findings in their products, followed up by Symantec with overall 258 vulnerability findings. Some of the major security products that tops the list are ClaimAV Anti-virus, Norton Antivirus, Checkpoint Firewall-1, Cisco Pix Firewall.

Final Words:

Security products like anti-virus, firewalls, IDS/IPS and VPN have become of paramount importance to provide highest degree of confidentiality, availability and Integrity (CIA) to individuals and organizations. However, it is foolish to assume that security products are free from any vulnerability (security flaws). Security Products can also be of target of attacks from the attackers.

Please download the full report of Vulnerability Trends in Security Products upto Year 2010 and post your views/feedback in the comment. If relevant, we will update the report with due credits to you.

References:

1. KHOBE – 8.0 earthquake for Windows desktop security software.
2. Security vendors respond to Matousec research.
3. IBM: 2010 Mid-Year Trend and Risk Report.
4. Secunia: Half Year Report for 2010 shows interesting trends.
5. SANS: The Top Cyber Security Risks.
6. Common Vulnerability Enumeration (CVE)
7. Common Product Enumeration (CPE)
8. National Vulnerability Database (NVD)

You may be wondering what Website Ranking Improvement has to do with Search Engine Security Testing. Few years back  I also wondered the same before I came across one smart SEO guy. Combined with his insights in SEO and my background in security testing, I’m convinced that all search engine marketeers should now consider adopting search engine security testing. Here is why..According to Jeff Bezos, CEO Amazon, Internet is a gold rush and all of us know that top ranking in major search engines is equal to a lot of Gold. In this rush, only being good is not enough, you also need to prove to Search Engines (mainly Google) that you are good . Wherever there is money or Gold, there are two worlds, one “white” and the other one “black”. Rather I should say there are 2 hats viz. white and black hat (Also I must mention grey hat, which swings from white to black depending on situations). In this post we will see how an effective vulnerability testing can determine some black hat signals (negative hidden practices by your SEO Company, competitors or your team that can hurt your search engine ranking and traffic).

What can hurt your Search Engine Ranking : The 6 negative signals..

These are few of the signals below one need to check, some can be highly negative (Some of which is plain ignorance. But still one can’t eliminate the possibilities of a competitor doing a compromise with the existing website/webapp vulnerability to hurt your search engine ranking. Let’s see some of the negative signals that can be checked during  search security testing:

1. Checking for malware distribution (An absolute search engine ranking killer, your site can vanish in matter of days from search engine ranking)
2. Redirection to steal your traffic (It can come under the Search Engine Scanner for cloaking)
3. Link stealers (When you link to bad sites, you may also be considered bad by search engines )
4. Content stealers (The original content is not considered the original but the one that is being discovered first by the search engine, all others are duplicate contents )
5. Hidden content injection (Considered bad by Search Engines )
6. Creating crawling errors for search engines http://www.google.com/support/webmasters/bin/answer.py?&answer=35120

Let’s take it one by one and see how security testing can help:

#1: Malware injection and Distribution

This may not be considered as a Black hat practice by your own team or the hired SEO Company but it can be a competitor’s black hat mantra to kill competition. Here is a real story I collected from the web:

Peter Kevin (name changed for obvious reasons) had his website infected by a malware but he could not catch it before Google could list his site as an “Attack Site”

Soon Peter could see his ranking going down, visitors getting scared to click on his results because of the warning that Google throws:

Since Peter was advertising, he was losing money on ads and potential sales every day. It was a good amount of money in ads and business at stake.

How security and vulnerability testing can help?

Google also uses a scanner to identify the malware injected sites http://www.google.com/support/webmasters/bin/answer.py?answer=163633 but the consequences of Google finding it before the webmaster can be costly. A good vulnerability test can find such malware injections really quick and help the webmaster correct it before search engines find it. The steps to be taken immediately:

• Send a 503 status message for all pages http://googlewebmastercentral.blogspot.com/2006/08/all-about-googlebot.html
• This is how you can do that in Apache (Sending 503 only to Google bots)

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*(Googlebot|Googlebot|Mediapartners|Adsbot|Feedfetcher)-?(Google|Image)? [NC]
# or RewriteCond %{HTTP_USER_AGENT} ^.*google.* [NC]
RewriteRule .* /cgi-bin/error/503.php

Sending 503 for everyone
Options +FollowSymLinks
RewriteEngine On
RewriteBase /

RewriteCond %{REMOTE_HOST} !^1\.1\.1\.1
RewriteCond %{REQUEST_URI} !^/cgi-bin/error/503\.php [NC]
RewriteRule .* /cgi-bin/error/503.php

#2 Traffic redirection and Cloaking

Redirecting your website to some other sites without you, even getting to know it. There are different levels of redirection here under Traffic stealing:

• Only for specific search engine keywords redirection. There were instances when the traffic was redirected to another website only for certain keywords when it was coming from search engines. This allowed the hacker to get the targeted traffic (quite funny though that how hacker are focusing on quality traffic)
• Only for certain referrals (Generally they avoid redirecting the direct traffic)
• All traffic redirection.
• Only converted leads redirection (This can be business logic vulnerability): Stealing your visitors (leads): There were few instances when the same lead was contacted by many vendors without the knowledge of the original vendor.
• How this is done: This can be done at the script level, $_SERVER variable (in PHP) offers a lot of information about the visitor like referral, current IP, which can be use to redirect easily. Also it can be done at the htaccess level, or server httpd.conf level. The most common one is the iframe based redirects http://www.guardian.co.uk/technology/2008/apr/03/security.google , http://www.networkworld.com/news/2008/031308-hackers-launch-massive-iframe.html?fsrc=rss-security

How Search Engine Security test can help?

Vulnerability testing scanner can scan for various level redirects. Also the vulnerability scanner can change its user type to Google Bot (http://www.seoforclients.com/blog/marketing/seo/how-to-browse-and-check-like-google-bot.html ) to see the pages it is rendering. This may not suffice as the scanner will also have to emulate with a proper referral and keywords. Even that may not suffice as the scanner may have to visit the thank you (or conversation) page. A proper vulnerability testing should also find the URL based session id authentication to avoid a possible lead leak.

# 3 Detecting Link Sealers

One of the main incentives for the unethical hacker is to steal your website’s reputation and link power through some vulnerability.

• Link is a major part of Google’s ranking algorithm (Read the journey of search engine algorithm below). There are scanners that run to find website with vulnerabilities to insert links to their websites. Unethical hackers will hack in and edit the High PR pages and add their links. This will increase the PR of the hacker’s site and your PR will be passing on without your information.
• The major problem comes when it redirects (with a 301 redirects) and passes all the link value to another website. Not only link value is passed but also the ranking is passed on to other site.  This happens as Google’s every redirected domain as a shift of domain and thus passes all the value from old domain to the new domain http://googlewebmastercentral.blogspot.com/2008/04/best-practices-when-moving-your-site.html

#4 Content stealer – Content is the King, Kill the king

In search engine algorithm content is considered the king and by killing your king, your competitors can win the game altogether. In this case the Copied competitor’s website can rank better than yours, even when your website is the original content developer. This can happen when the hacker delays the indexed of your website’s content and copies the same content to his website and claims the originality. It is difficult for Google to understand who actually owns the content http://www.seoforclients.com/blog/marketing/seo/faq-why-our-competitors-rank-better-than-us-for-our-own-content-video-ranking-too.html

#5 Detecting Hidden content injection

Hidden content is a common black hat practice http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=66353. It was once a super hit formula for Google ranking but now it is considered a bad practice. A good security testing and website scanner shall be able to detect such mistakes as well.

#6 Detecting crawling errors for search engines

As explained in point #4, crawling errors created by some vulnerability can cause major problems in search engine ranking http://www.google.com/support/webmasters/bin/answer.py?&answer=35120 . There are various levels of crawling errors starting from User Agent based blocking at Web Server level to Meta tag based restrictions. A good search engine testing shall be able to scan for all such possibilities and suggest the webmaster for correction.

Since we have already discussed some of the possible issues in search engine ranking due to website vulnerabilities, it will also be helpful to understand how Search Engine Algorithms evolved and how Black hat and white hat world is striving to win the Gold. Let’s look into these details in the second part of this article. Keep out a watch……(To Be Continued)

Yesterday, I received a post in the Pen-Test mailing list requesting for tips/resources on penetration testing of flash applications.  While there are some tools and white papers available, I could not find many authoritative resources which wraps the entire spectrum of flash security testing of RIA applications.  So here is an endeavor to detail out the steps of testing.  I will keep this post only to outline the essential steps or points.  Please feel free to recommend additional inclusion of tools and techniques.  The idea is to come up with a comprehensive paper which can be used by pen-testers to test flash based Rich Internet Applications (RIA).

A short unnecessary introduction on Flash RIA

Adobe Flash (formerly Macromedia Flash) is a multimedia platform originally acquired by Macromedia and currently developed and distributed by Adobe Systems. Since its introduction in 1996, Flash has become a popular method for adding animation and interactivity to web pages. Flash is commonly used to create animation, advertisements, and various web page Flash components, to integrate video into web pages, and more recently, to develop rich Internet applications. Source: en.wikipedia.org/wiki/Adobe_Flash

Conventionally, RIA developed with Adobe Flash technology consists of a frontend application compiled as an SWF/AIR object to be executed by the Flash Plugin inside the User’s Browser or the AIR Platform installed on the User’s System. This interactive application provides a user Interface to the end-user and in turn communicates with a backend server for its business logic over protocols like HTTP/AMF, HTTP/SOAP, HTTP/REST etc.

The security angle..

Similar to any widely used web application and software, a RIA can also be a victim of most common and dangerous security Issues. For example, since most Flash based RIAs are backed by an application for its business logic which in turn uses a database, a Flash based RIA might also be vulnerable to common application vulnerabilities like SQL Injection if user input is not sanitized properly. Quite logical huh?. Attackers can also utilize Flash to execute mass exploitation, for example backdoors or malware entirely written in Flash/ActionScript or BOFs against player/plugin or browser.

It is quite general to deduce that security flaws may also be present in the core environment (which includes the OS and web browsers) that can be exploited regardless of the applications (including Flash Player) running in that environment. A recent paper from Adobe suggests that the approach of Adobe is to implement robust security within its own products while “doing no harm” to the rest of the environment (in other words, to introduce no exposures to the rest of the environment, nor allow any avenues for additional exploitation of any existing platform security weaknesses). This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwards-compatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments.

Vulnerabilities in flash RIA can be broadly classified under two categories: client side vulnerabilities and server side vulnerabilities. Let’s review each one of these very quickly:

Client Side Vulnerabilities:

Amongst the various vulnerabilities that might affect a Flash Application on the client side, some of the most common ones are:

Flash parameter Injection: It might be possible for an attacker can inject global Flash parameters when the movie is embedded in a parent HTML page. These injected parameters can grant the attacker full control over the page DOM, as well as control over other objects within the Flash movie. There is nice detailed paper by the IBM Rational guys on this vulnerability. You can download it here.

Cross Domain Privilege Escalation: Cross Domain inter-mixing of content and data is done based on access policy defined in crossdomain.xml of the serving domain for the SWF object. If the access policy is too open, then under certain circumstances, it might be possible for an attacker to supersede the original SWF object with his own malicious version or access the DOM of the hosting domain.

Cross Site Scripting: Depending on access policy, a Flash SWF can access its host DOM for various functional use cases. A Flash SWF can in turn modify the DOM of its host and if it does so based on un-sanitized user input, it might be possible to perform a conventional XSS attack on the host DOM.

Cross Site Flashing: Cross Site Flash (XSF) occurs when an SWF objects loads another SWF Object.  This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form.  XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie methods are used. OWASP has a testing guide for XSF. Although not comprehensive, still it is a very good point to start. Read it here.

Server Side Vulnerabilities

Flash Applications seldom makes remote calls to a backend server for various operations like looking up accounts, retrieving additional data and graphics, and performing complex business operations. However, the ability to call remote methods also increases the attack surface exposed by these applications. Flash Applications built with Adobe Flex SDK usually use AMF Objects exchanged over HTTP Protocol as a method of communication. AMF Remoting calls are essentially RPC like calls where the Flash Application is calling a given method defined on the server on a specific AMF Endpoint. An attacker can intercept and tamper the AMF data to compromise the server.

In most of the cases the application server responsible for providing Business Logic to a Flash RIA frontend is a standard web application and can be affected by the very same vulnerabilities as any other web application like as described by the WASC Threat Classification Project.

Testing Flash Applications: Objectives and Approach

A Flash Security Testing exercise for a Flash Based RIA is conducted with the following objectives:

• Identify the application entry points and test for possible vulnerabilities in the SWF Object itself.
• Identify the remote server with which the application might communicate for its business logic requirements.
• Identify the protocol with which the SWF Object is communicating with its back-end server. In most of the cases, the protocol will either be SOAP/REST or AMF.
• Identify and enumerate all the functionalities exposed by the back-end application.
• Penetration Testing of the individual functionalities exposed by the back-end application for standard application security vulnerabilities.

Client Side Testing

Client side primarily relates to static analysis of the flash application. The idea of static analysis of a Flash SWF Object is to decompile the SWF file and attempt to do a white box testing approach by looking into the source code of the Flash SWF File. Basic approach to test client side vulnerabilities is :

1. Decompile SWF files into source code (ActionScript) and statically analyzes it to identify security issues such as information disclosure (hard coded).
2. Audit third party applications without requiring access to the source code.
3. Common vulnerabilities includes hard coded login credentials, internal IP disclosure, etc.
4. Apart from analyzing the SWF file, it is also important to analyze the code responsible for generating the HTML file that embeds the SWF object. Under certain circumstances in might be possible to manipulate the FlashVars variable through which SWF inputs can be influenced.

There are however automated tools like HP SWFScan available to do this job upto a certain degree.

Server Side Testing

The best straightforward way to do a server side testing for flash based RIA applications are as follows:

1. Extract Gateway

• Load the flash e.g http://foo.com/bar.swf in a browser with service capture/burp proxy/charlesproxy running .
• Decompile the SWF using swfdump and grep the gateway patterns. Also get a list of all the urls in SWFdump.

2.  Enumerate service/methods

• Try amfphp.DiscoveryService on all gateways using Pinta.
• Use Pinta for AMF calling even if the services and methods are manually entered and hence can be helpful in testing remote methods.
• If it fails try extracting them using regex from SWFDump using the following regular expression.
  Services:

  –"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)

  –"destination id=\"([\\w\\d]*)\"“

3.  Make AMF calls

• Use Pinta to call remote methods using different test parameters.
• Single quote (SQL injection), neighbor parameters (Direct Object Reference).

Testing the backend application once the exposed functionalities are enumerated should be more or less conventional to standard web application security testing methodology just that a different protocol (AMF serialized calls in this case) is used for interacting with the server and invoking the functionalities.

Checklist of Vulnerabilities to be tested

• Cross Site Scripting
• Malicious Data Injection
• Insufficient Authorization Restrictions
• Secure Transmission
• SWF Information Leak
• Minimum Stage Size for Anti-ClickJacking
• SWF Control Permission
• Untrusted SWF in Same Domain
• Clickjacking
• Privilege Seperation
• Cross Domain Policy Audit
• Uninitialized Variable Scanning
• Remote Method Enumeration
• Business Logic Testing

This is a brief guide to testing flash applications. Comments are welcome to make it better and more comprehensive. At the end, we intend to publish a freely available whitepaper to pen testers for testing flash based RIA. Additional sections included in the paper will also carry due credits as received in the comments section below.

Ok, I’m going to keep this one real short. A few days ago I created one Squidoo Lens on the vulnerabilities of facebook and twitter which received good user feedback and comments. Following up on that, here is a summary (as well some new ones) that you may consider to prevent your computers being targeted by malware through twitter.  Kaspersky labs deployed a tool named Krawler in August and it has come up with an evidence that alomost 500 URL’s points to sites with malware. (The number is growing so beware!)

1. Don’t believe blindly that a link is completely safe because it is from someone whom you are following.
2. Don’t believe blindly Twitter links are not malicious because Twitter is now focusing on website security .
3. Don’t believe blindly Bit.ly Links are perfectly secure.
4. Always have your browser updated (because many exploit browser vulnerabilities) and have Windows download all the latest patches as they are released.
5. Have your Adobe Reader and Adobe Flash always updated.
6. Don’t just dwell on the assumption that you are secure because you are using a Mac.
7. Always verify the email messages from social networks. Make sure the message is signed by twitter.

In this day and age, the way we do business has raised the demand for Web application security testing services. Every progressive and successful company nowadays has their own Web site or web application. Since the 1990s, more and more businesses have extended their presence online. The Internet is no longer just a place to place an online catalog in, but it has expanded to e-commerce and customer relations management. More and more businesses currently accept and fulfill orders online. Moreover, an increasing number of businesses have moved their processes into cloud computing. Data and information migrate from physical offices to the Web storage.

This would not have been possible if not for the various Web applications and software that have come out during the past few years. However not all Web application is created equal and not all of them are 100% secure. This is where Web application security assessment comes in.

Without secure Web applications, all of these processes will fail, leaving you in the dust!

Web application security testing is a type of penetration testing that scrutinizes the Web applications and client server applications found in a computer system. Any application that is on the Web or is accessible by people outside of your organization may be tested.

Web application testing typically evaluates and assesses the security measures in your interactive Web sites, which may include applications like extranet services, order forms, contact forms and e-commerce systems. Web application security testing may also be conducted on the company’s customer database, especially if this is shared over the Web.

The bottom line is that Web application security is important in conducting business online. Would you trust your financial data onto some system that you know is not secure? Your customers would be adamant about having private personal information kept safe too.

There are a lot of security audit companies that offer Web application security testing services, so a typical company can have their pick on testing providers at a price that they can afford. Companies could avail of bundled security testing services, or just this particular testing service. This ensures that you can have the level of security assessment you need and not pay for security testing that you do not need. Read how to choose a penetration testing company to select the best suited company for you.

Not Just Quality Assessment, you need more than that..

Do not be lulled by a false sense of security. If you think that quality assurance is enough guarantee that your applications are secure, you are wrong. There are processes that even the most thorough quality assurance procedures would not be able to test. There are procedures in web application security testing that goes beyond quality assurance. Further, if you think that a network firewall would secure your systems, think again. There are attacks that even the most popular firewalls can not protect against.

Web application testing should be able to tell you if you have enough security measures in place, and if you have security issues that you should be aware of. More than this, experienced consultants could peruse thousands of lines of codes and determine vulnerabilities in such a way that automated software can not.

Web application security assessment covers a lot of areas. To be sure, find out what type of application you have and what kind of testing you want to be done on them. The more prevalent Web application testing areas are on authorization and authentication, account management, meta character stripping, encryption, parameter tampering, session management, hidden field manipulation, script injection attacks, vulnerabilities in forms, buffer overflow checks, forceful browsing, character bounds checks, debugging, and known software vulnerabilities.

Most companies nowadays put their information on the cloud, not on physical systems. This information could include sensitive customer and client information, processes, insider secrets, research and development. There is an inherent risk that these data and information could be compromised, more so if you use applications both on the Web and internally that have vulnerabilities that may be easily exploited. To be sure that you account for all these vulnerabilities, have your Web programs and software undergo application penetration testing.

Application Security Puzzle

1. Application penetration testing is a type of penetration test that covers a lot of areas including, but not limited to, client server applications and web applications. Any application on your system that may be exposed to the public or outside forces and even those that are part of the internal systems in your company or business may undergo application penetration testing.
2. Application penetration testing often involves auditing and scrutinizing the design of each component, application layers, web services, Web site communications, interfaces and underlying databases.
3. Moreover this testing looks at the various source codes affecting critical areas in your applications like authentication and validation, database calls, and configuration and set up. Software used in the company, as well as internal applications may also undergo application penetration testing.
4. The aim of application testing is to guarantee that the highest security is implemented. Sometimes what seems to be an insignificant issue in both Web applications and software can turn out to be a troublesome security issue. Also, these severe security flaws do not fit the traditional functional errors. Routine and simple quality assurance, then, is not enough. This is because quality assurance procedures often lack the thoroughness that a focused application penetration testing can provide. There are also other areas in application penetration testing that are absent from quality assurance procedures.
5. Do not get caught unaware. Get the peace of mind of knowing and anticipating what vulnerabilities your software, database, processes and Web applications might have. This way you can plan and manage any untoward incidents involving them. You can also limit the damage or impact that a hacker would bring. Much more, you can prevent a hacker from exploiting these weaknesses in your system. You can also avoid damaging your company’s reputation and brand, while decreasing down times or incidents when your system is down and inoperable.

These types of tests are part of a wider range of network security audits designed to protect your computer systems and by extension, your company. For one, it ensures the integrity of your systems and keeps your information confidential. It decreases the likelihood that a hacker attack would succeed. For some, it could also spell the difference between being in compliance with certain industry or regulatory standards.

There are many security companies that offer application penetration testing either as part of a larger security audit or as a stand alone service. This will ensure that you can avail of the service any time you need or want it.

Remember: Application penetration testing can uncover hidden security bugs, and even weaknesses in “correct” application codes and functionality.