Category Archives: Application Security Strategies


Mobile Security Attacks – A Glimpse from the Trenches (OWASP AppSec USA 2014 Preso Review)

AppSecUSA.2014At the recent OWASP AppSecUSA in Denver, Yair Amit and Adi Sharabani of Skycure presented a very informative overview of mobile security issues. There was a great deal of good material in this presentation, packed into a short period of time.

The presenters divided the attacks into four overlapping areas:

  • Physical Security
  • Network
  • Application Security & Privacy
  • Malware

Physical Layer

The problem here is obvious: the device is lost or stolen, or temporarily accessed by a non-authorized user. In these cases, the responsibility has fallen on the OS for protection. With stolen devices in particular, the opportunities for controlling loss are greatly reduced, as the thief will intentionally disable internet access, which is required for many of those protective mechanisms to work.

Network Attacks

The presenters estimate that 10% of “scanned networks” (presumably wifi) pose some sort of threat, and that the likelihood of encountering such a network is 40% over a period of four months, with that number increasing with time. They have even put together a real-time mapping of network threats: (Just for fun, I recently entered Los Angeles into the app, and it identified a half dozen clustered in east LA, and one in South Central. Central LA seemed clear, but there were some other threats in Beverly Hills and Westwood. Your mileage may vary.) For more information:

Network Security Implementation Issues

Two network layer implementation issues affecting mobile devices were reviewed: the gotofail bug in iOS, and Heartbleed in Android. The presenters briefly contrasted the updating mechanisms for the two platforms. The good news for iOS is that gotofail could be easily fixed and updated on affected devices, as iOS is a single platform that is updated by the vast majority of users in short order. The less good news for Android is that updating is more difficult due to platform fragmentation. Since Heartbleed is really more of a server concern and is hard to exploit on a device, the lack of updatability was not too troubling in this case.

Network Security General Design Issues

This portion of the presentation focused on design issues of the more general “protocol” varieties (i.e. not mobile device specific).


The first design flaw examined was the five year old sslstrip vulnerability. The solution, HSTS, is only present on newer browsers. Older devices have older browsers (presumably especially on harder-to-update Android) that do not support HSTS. In terms of how to address the problem, the difference between this design issue and the implementation bugs above is (presumably) that a server modification is necessary in addition to the device update.

“SSL Decryption”

“SSL decryption” was the second general design issue discussed. By this, the presenters are referring to a man-in-the-middle SSL certificate attack. While this is a general issue and not mobile-specific, the presenters nevertheless focused on the dialog that pops up on iOS devices when there are SSL certificate problems. This dialog allows the user to either cancel or continue with the connection. Of course, “continue” is the wrong choice as it may indicate a man-in-the-middle attack, but they have found that 92% of users choose to continue.

They also suspect that the percentage rises with repetition of the dialog, due to the annoyance (if “cancel” means I keep getting the dialog, then…). If a user clicks “continue” not when loading a web page, but due to a problem communicating with an Exchange server, then credentials are compromised. This can lead to even further compromise, e.g. other accounts by resetting passwords, changing contacts with new phone numbers, etc.

My Ten Agorot (or two cents, hey, the presenters are Israeli…)

The presenters did not describe how this SSL certificate problem is handled on Android, which would have been interesting to hear. Neither did the presenters explore possible solutions to this problem, such as future versions of mobile OS that might have a setting to automatically always disallow certificate mismatches.


The third general design vulnerability is the Karma wifi auto-connect attack.

My Two Cents

This warranted only a brief mention with practically no discussion at all. Probably the omission was due to time, as there has been a lot of content disseminated on this already, and more recent mobile OS versions have been updated to prevent the attack from working. For more information, see it in action using our favorite hacking device, the WiFi Pinapple (

Network Security Mobile Design Issues

iOS Configuration Profiles

The combination of having one app store with a lot of screening and the sandbox model do make iOS a relatively secure platform. However, there is a rather significant attack vector available for iOS: “configuration profiles.” These are XML files that allow IT departments to configure iOS devices for specific network purposes. They are very powerful, affecting the entire device, and they bypass all of the aforementioned security mechanisms, making them attractive not only for legitimate use, but also for attackers. They can do some potentially very nasty things, such as redirect traffic and install root certificates! And all it takes is a tap by the user. A web site can be crafted to make such an attack look entirely legitimate, when in fact a Trojan is what is being offered. The presenters put together an example configuration profile attack that worked as a key logger as well as a device keyboard controller. It looks like complete control of the device may be possible including launching and controlling apps!

These attacks do exist in the wild, and they are aware of cases where even legitimate configuration profiles were somehow hijacked by malicious actors. Further, some of the attacks are then spread virally, by sending messages through email and social networking to the victim’s contacts to entice them to also install the malicious configuration profile. For more information:

My Two Cents

This part of the presentation held particular interest for me. When I was at DEFCON earlier this year, I noticed that the conference wifi was provided for iOS devices by means of a configuration profile. Even though I knew nothing about them at the time, it struck me as a risky proposition to install something like this. I demurred, and while I’m sure it was safe enough, I ultimately decided to stick to the cellular network as a (probably) safer option. It was gratifying to see my concerns about configuration profiles validated.


Going back to the Karma attack, mobile device carriers may install pre-defined wifi settings that will result in a device automatically connecting to certain wifi networks, right out of the box. These settings are not user-modifiable, and the devices are vulnerable to a Karma-like attack without the user having to take affirmative steps to connect to anything at all. For more information:

Application Security

As a software engineer in the field of web application scanning, my greatest interest is most clearly in this category, which they characterize as an “emerging threat.”

My Two Cents

Whether they mean mobile web applications or installed mobile applications, this threat has clearly already emerged. Web applications generally have been a primary point of attack since the early 2000’s. Now, installable mobile applications are rapidly being released. What’s worse about these new applications is that they utilize newer technologies, and neither the developer nor security teams have the same experience testing them, nor the tools to do so. So, the risk associated with mobile applications is of great concern. Gartner predicts that through 2015, more than 75% of mobile applications will fail basic security tests. (Gartner Application Security Magic Quadrant, 2014)

Most global enterprises and large organizations have well-established application security programs to detect and resolve application security issues. While we are used to thinking of this as primarily a browser presentation issue, the mobile dimension will increase over time. Some of the “old” vulnerabilities (such as SQL injection) can show up in the web service back-ends for mobile applications. For more on current application security threats and trends, visit

Plain HTTP

Non-encrypted traffic is still a used by some mobile applications (amazingly). No further elaboration is necessary.

Certificate Pinning

Mobile applications can and should be pinned to a specific certificate to work, but according to the presenters, few apps do this, even major ones. This is an astounding security hole, but the poor rate of use is due to pinning being difficult to implement correctly. Specifically, if a certificate must change, due to expiration or compromise, some mechanism must be provided to update the client app.

HTTP Request Hijacking

In an untrusted environment, a man-in-the-middle issues a persistent redirect (301) to a malicious server. This has a permanent effect even when back on a safe network, with the app still contacting the malicious server pointed to by the redirect. This is a cleverly sneaky attack that I will enjoy testing on several apps.


Malicious apps have been more of a problem with Android than with iOS. The “year of Android malware” was 2011, countered by “Bouncer” a year later. Then malware went to other external stores, followed by a focus on “verified apps,” moving Android closer to the iOS security model. Thus malicious applications now are becoming sneakier. The best example given was asking for all keystrokes in exchange for better services! This is possible on Android and iOS 8 with installable keyboards.

NTOBJECTives Relevance

Almost everything in this presentation focused on the client side of the mobile security equation. This is a natural and typical focus for mobile security. But the traffic between a mobile application and a server can be just as vulnerable, and more damaging if breached, to the server side of the equation than to the device side. NTOSpider can be used to scan such sites and web services for vulnerabilities. For example, one of the issues in this presentation touches on server side behavior beyond simply the general use of SSL/TLS: the use of HSTS for preventing the sslstrip attack. NTOSpider detects this header and reports on the lack of its use in conjunction with HTTPS.

For more information on mobile applications and web application scanning see the following content at


NTOSpider 6.4 Now Available!

We are excited to announce a host of enhancements to NTOSpider that will further assist you in testing more of your applications in less time. Our mission is and has always been to create the most automated and accurate assessment possible even on the most modern applications. And, in this release, we further expand NTOSpider’s ability to effectively test modern web and mobile applications.

The following are some of the highlights of NTOSpider 6.4:

  • Web service authentication to further automate testing of web services and mobile applications.
  • Automatic update tool to enable users to automatically download new versions of NTOSpider.
  • Crawler improvements to further expand coverage of Web 2.0 applications and improved performance on very large sites.
  • Added and improved attack modules to include additional vulnerabilities in automated coverage, including Shellshock or BASH Bug.
  • Improved UI features including user defined attack policies and macro debugging.

New and Enhanced Features

  • Web Service Authentication – Expanded ability to test web services with the ability to handle the authentication and session management solutions used by many web services. Including: comprehensive OAuth, HMAC, integrated NONCE support and user defined solutions.
  • Improved Web 2.0/3.0 and HTML5 crawling – Improved automated crawling of heavy Javascript (AJAX) web sites and popular frameworks such as jQuery.
  • Enhanced performance – Performance improvements include increased scan speed and reduced memory consumption especially for very large sites.
  • Auto-updater – NTOSpider finally has a configurable automatic update mechanism that enables users to choose between three options that give the user flexibility and control over upgrades.
  • User Defined Attack Policy – Simplifies selections of attacks.
  • Macro debugger – UI feature to help user replay and debug MACRO recordings.
  • Attack modules – The following attack modules have been added or improved.
    • Shellshock (aka The BASH Bug)
    • CORS (Cross-Origin Resource Sharing)
    • XPath Injections
    • LDAP Injection
    • XML External Entity
    • Server Side Include (SSI) Injection
    • Expression Language Injection
    • ASP.NET ViewState Validation

For complete details review the release notes.

For more information or to request a free trial of NTOSpider visit:


Dynamic Application Security Testing (DAST) is Anything but Static

5 Things A Modern Scanner Must Have

Dynamic Application Security Testing (DAST) solutions have been around for over a decade, so you might think the market is static. But, that’s hardly the case. Web applications and malicious hackers continue to evolve and DAST solutions need to keep pace. According to Gartner, DAST technology analyzes applications in their running state (in real or “almost” real life) during operation or testing phases. It simulates attacks against a Web application, analyzes application reactions and, thus, determines whether it is vulnerable. [Gartner Magic Quadrant for Application Security Testing, Neil MacDonald, Joseph Feiman, July 2014]

Visit this NT OBJECTives’ Gartner resource center to review some of the latest research on DAST technology.

  1. Ability to Test Web 2.0 (AJAX), Web Services, and Mobile
    Applications have evolved to be very complex and transactional – leveraging web services, mobile components and complex workflows like shopping carts. These applications are built with new technologies like HTML5 that delivers the rich clients that today’s consumers expect and REST interfaces used by AJAX. These REST interfaces also power most mobile apps, and business to business API’s. It’s critical that today’s scanners understand these new technologies.If a dynamic application security scanner hasn’t been modernized to understand these new technologies, it’s almost certainly completely skipping that area of the application leaving it untested or requiring that entire section to tested by hand. Most of the pen testers I know already have their hands full testing advanced business logic and other hard to reach areas. DAST solutions should be automatically covering as much of these applications as possible.
  2. Continuous Integration API’s to Support the SDL
    Most of the global enterprises we work with require extensibility to enable them to drive security earlier into the software development lifecycle (SDL) and to connect with existing and home grown tools. Many organizations are integrating their DAST solutions into their Continuous Integration solutions (HudsonJenkins, etc) to ensure security testing is conducting easily and automatically before the application goes into production. This requires a dynamic application security scanner that works well in “point and shoot” mode and offers open API’s for running scans. Ask your vendor how their scanner would fit into your CI environment.
  3. DEV/QA Integration and Flexible Training Options
    Security teams are collaborating with development and QA teams to leverage the test automation tools & scripts such as Selenium to create repeatable security tests that can be executed in conjunction with nightly application builds. This is an excellent way to build security into the process from the beginning with very little additional effort. Talk to your DAST scanning vendor about how their integration with Selenium and other automation tools works.
  4. Enterprise Reporting for Metrics
    Enterprise reporting means different things to different people, so one of the key features a solution should have is flexibility with open access to raw data for custom analytics. You want to make sure that your vendor does not hide the data in any way, and preferably makes it readily available with standard database query option.
  5. Point and Shoot High Quality Results
    This one is critical! Your dynamic application security scanner must do everything possible on its own to comprehensively crawl the application and then attack it. Of course training can help, but the problem is that organizations often have too many applications and the security team rarely has the time or knowledge of each application to ever possibly be able to train the scanner for them. Additionally that human time could be better spent by the security team to test things that automation cannot, such as privilege escalation and cross-account data leakage.

Ask your DAST vendor if their scanner requires training in order to understand your complex applications, and then test them for yourself.


Fix Security Defects Earlier with NTOSpider and Selenium Integration

It’s a well-known fact that it costs less to fix security defects earlier in the software development lifecycle than later. But because most security professionals are experts in security and less familiar with applications, and QA teams are experts in applications and less familiar with security, integrating security testing earlier in the software development lifecycle can be a challenge. NTOBJECTives is changing that in a big way.

As innovators in web application security scanning, we are always thinking how can we can continue to push ourselves, to continue our innovation and really deliver world class scanning to our customers. One of the things we have done is enhance our web application security scanner, NTOSpider, to integrate with browser automation program Selenium to help companies bridge the gap between software development and security testing.


Here’s how it works. First, you may already be familiar with Selenium. It is often used by software development and QA teams to automate the security testing of web applications, and enable users to record a series of events and analyze the results. The NTOSpider and Selenium integration enables security teams to automatically detect security defects earlier in the software development lifecycle, such as during the nightly build process. As a result, security teams can improve web application security with minimal additional costs and without the help of development and/or QA teams.

Our latest version of NTOSpider supports two methods of Selenium integration:

  1. It executes the Selenium script directly, while NTOSpider is running, to avoid working from a possibly expired session.
  2. It imports the output of a previously executed script, expediting the testing process.

In addition to improving web application security testing, NTOSpider’s integration with Selenium can also be used to automate complex authentication solutions and specific application workflows, like shopping cart sequences.

NTOSpider offers development/QA and security teams an exciting opportunity to finally close the knowledge gap that often exists between them and develop more secure web applications at a lower cost. If you’d like to learn more about the benefits of integrating web application security scanners with Selenium or how NTOSpider can “piggy-back” on the application knowledge built into Selenium, I encourage you to download our white paper, The Case for Integrating Selenium and Application Security Testing.

This becomes even more interesting when you hook all this together with a Continuous Integration solution such as Jenkins. In this model, NTOSpider scans are launched against the latest build of the application in a fully automated fashion.NTO-CI-IntegrationWithSelenium

And while the integration of Selenium is an exciting one, we are off and running on our next enhancement. More on that soon!

Until then, scan your apps or face attack!


Hackazon, new open source vulnerable web application – Sneak Peak at AppSecUSA

I hope you’ll join me next week at AppSec USA 2014 in Denver as we unveil a new open source vulnerable web application, called Hackazon in interactive group discussion, on Friday September 19th from 8:30am – 9:15am. The talk is titled, “Hackazon: Get Your App Scanners Ready.”


Many IT security professionals are concerned about their ability to adequately test modern web and mobile applications as well as web services and rightly so, because today’s modern web applications have a host of new technologies that are not being adequately tested. A critical part of the ability to test today’s applications is honing your skills and evaluating the effectiveness of the security testing tools your team uses. We have some great test applications that have served the industry as a learning platform, but these applications are dated and none of them (e.g. WebGoat, DVWA, Hackme Bank and Hackme Casino) have use cases and technologies that reflect the real world applications we are seeing today.  All of the older vulnerable web applications were built on good old GET and POST (the year 2000 called, it wants its request response traffic back). 

Enter Hackazon! Hackazon is built with the rich client and mobile technologies used in today’s applications. It’s an online storefront with an AJAX interface, strict workflows and RESTful API’s used by a companion mobile app. And, it’s littered with your favorite vulnerabilities like SQL Injection, cross-site scripting and so on.

Hackazon enables users to configure each area of the application in order to change the vulnerability landscape to prevent “known vuln testing” or any other form of cheating. Since the application includes RESTful interfaces that power AJAX functionality and mobile clients (JSON, XML, GwT, and AMF), users will need to the latest dynamic application security testing tools and techniques to discover all the vulnerabilities. Hackazon also requires tedious testing of strict workflows common in todays business applications, like shopping carts.

During my workshop at AppSec USA, I’ll give a sneak preview of Hackazon, and seek your input as to what you’re seeing in applications and would like to see in Hackazon.

Looking forward to it! Hope you’ll join me for a lively discussion!

1.7 Automation Reduces Man Hours

Application Security Scanning Today – Big Organizations, Big Challenges

IT security teams in global enterprises face significant challenges in application security scanning that create the need for application scanners to deliver a scalable solution that is capable of assessing today’s applications. At NT OBJECTives, most of the organizations we talk to and work with are some of the largest organizations in the world. They are dealing with tremendous challenges from numerous applications and limited resources to ever changing technology. Let’s examine the three key challenges many of our customers face.

1. Complex Applications, New Technologies

One of the primary challenges in application security testing today is the complexity of modern applications.

“The surface of attacks targeting applications and data has expanded from Web into mobile and cloud systems. Rapid adoption of detection and protection concepts and technologies is critical for all enterprises.”
Section from Gartner other report on market state
Hype Cycle for Application Security 2013, July 25, 2013

Today’s applications are written in different technologies and those technologies are constantly changing and evolving. In the early 2000’s, most applications were simple HTML applications. Now with Rich Internet Applications (RIA’s), mobile and cloud applications, we have a host of new technologies used in applications. These technologies include everything from AJAX and Google Web Toolkit to REST and JSON.

Most application scanners have fallen behind the innovation curve and can no longer automatically or accurately assess applications that include these technologies, leaving enterprises vulnerable.


Scanners were historically based on their ability to crawl an application in order to understand it and they were able to crawl HTML, but this is no longer the case. A new architecture and approach is required for these newer technologies. From what I can tell, NTOSpider is the only that has been modernized to address today’s applications. Be sure to examine your application security scanner carefully to determine if it’s covering the newer technologies. To read more about dynamic application security tool coverage of new technologies, please check out our white paper, “Is Your Scanner Like the Emperors New Clothes?”.

2. Enterprise Scalability & Automation

Compounding this issue of the complexity of applications is the sheer volume of them. Today’s enterprise security teams are faced with the enormous challenge of securing hundreds or thousands of applications, built in a variety of technologies with small security teams.

In order to effectively secure that many applications, security teams require a high-level of sophisticated automation. We often refer to the breadth of scanner coverage – is it covering this AJAX corner of the application, or that complex business workflow.

Considering Application Security Scanner Coverage

Application scanner coverage is the percentage of an application that a scanner can automatically understand and test. As an application scanner’s coverage of applications increases, costs for scanning all of the organizations application’s decreases. In order to achieve maximum scalability, organizations should use maximum automation. Maximum automation is derived from maximum application coverage by a scanner. There aren’t any application scanners that can scan 100% of a complex application because they will always require some testing by hand for certain business and application logic functions. However, scanners should be able to achieve maximum coverage of a complex application. Roughly 80% of a security test, even on a complex application, is capable of being automated.

For this discussion, I’m using a sample organization that has 80 standard applications and 20 complex applications.  The potential cost savings of using an application scanner with maximum coverage available (80%) would be about $228,000 or 1520 man hours per scan cycle. Many organizations do quarterly cycles, so this can result in a savings of approximately $1m per year. The following tables and graphs demonstrate the business case for maximum automation.

Cost Savings Driven by a Highly Automated Scanner for 20 Complex Applications

The table below details the time and cost savings realized with improved automation (scanner coverage) for one cycle of testing for the 20 complex applications. Using this rough estimation technique, you can see that an organization can save $80,000 in one testing cycle where 20 complex applications are tested one time.

For the purposes of this example, I am estimating the cost per pen test hour at $150 and estimating the man hours required to complete a scan based on the coverage the application scanner can provide and the complexity of the application. The estimated total man hours required for testing the applications is multiplied by the $150 to get the cost for the apps for each row.

The following table demonstrates how total security testing costs decrease for 20 complex applications as the application security scanner’s % coverage of the application increases.

1.0 Time & Cost Savings for Complex Applications

Note: The column called, “Man hours required to complete a scan” refers to the total number of human hours required to assess an application including: configuration time, pen testing time, vulnerability review and validation time, etc.

So, if we look at the same cost savings for 20 complex applications in a graph, we can see that as scanner automation improves, costs decrease. 

1.1 1.1 Cost Savings with Improved Automation (20 Complex Apps)

Cost Savings Driven by a Highly Automated Scanner for 80 Standard Applications

So, does the same logic hold true for more standard applications that are less complex? This table details the time and cost savings realized with improved automation for 80 standard applications over one test cycle. Again, using this rough estimation technique an organization can save $72,000 in one testing cycle where 80 standard applications are tested one time.

1.2 1.2 Time & Cost Savings for Standard Applications

Again, looking at it in a graph format, you can see that as scanner automation improves, costs for testing 80 standard applications decreases. With 50% coverage, the applications will cost around $120,000 to test, but with 90% coverage, the costs decrease to less than $20,000.

1.3 1.3 Cost Savings with Improved Automation (80 Standard Apps)

Cost Savings Driven by a Highly Automated Scanner for 100 Mixed Complexity Applications

So, when you look at all 100 applications of mixed complexity, again we see that as scanner coverage increases, man hours and therefore overall costs, also decrease.

1.4 Time and Cost Savings (100 apps, mixed complexity)

And the graph demonstrates that  an organization can save almost $200,000 by testing all 100 of their applications one time with maximum automation as opposed to 50%.

1.7 Automation Reduces Man Hours

3. Scalability with Cost Control

A third major issue is that most of these organizations are building world class application security programs to address thousands of web and mobile applications with limited financial and human resources in a race against ever increasing threats. This challenge requires them to find highly automated and distributed application scanning solutions while effectively using resources to control costs.

But controlling costs is difficult. The smartest solution is one that combines the most accurate and automated web application vulnerability scanning with the benefits of elastic computing in the cloud to provide a sophisticated and scalable solution that effectively controls costs while conducting automatic vulnerability detection for even the most complex applications. Our scalable, elastic solution leverages NTOEnterprise and enables the largest global enterprises to provide their own application security assessment shared services to their customers or different divisions around the world.

A highly sophisticated and automated solution combined with elastic computing enables global organizations to easily expand and contract resources based on their scanning demand.

At NT OBJECTives, we have always strived to maximize automation. We find that many of the largest organizations in the world choose us because the complexity of their application security program necessitates sophisticated automation, maximum application coverage and scalability. For more information about how we solve these problems, please visit us at or request that we contact you by filling out this short form.

iphone image

Mobile Application Security 101

Mobile Applications – Still Insecure

Businesses are racing to meet the demands for mobile applications, yet mobile application security is an afterthought, just as web application security was when web applications started to proliferate.

As an industry, we know so much about securing web applications that applies to mobile, but most organizations are still repeating past mistakes and making new mobile specific mistakes that expose businesses to security incidents.

According to a recent Gartner report, “Most enterprises are inexperienced in mobile application security.  Security testing, if conducted at all, is often done casually — not rigorously — by developers who are mostly concerned with the functionality of applications, not their security.[1]” In this same report, the firm indicates that “through 2015, more than 75% of mobile applications will fail basic security tests.[2]


Don’t Forget Mobile Web Services

There has been so much talk about mobile device and mobile client security, but the key thing to keep in mind when approaching mobile application security is that it’s critical to test both the client as well as the communication to the web service that powers it. For example, if you’re using your Twitter app, the primary logic that resides on the mobile client is display and user authentication. The app must then communicate to a web service in order to get and send Tweets. This web service is the real power of Twitter and where the real security risk lies. Why attack one user, when you can attack that web service that is used by millions?

Even though mobile applications leverage a client-server model, they are built with entirely new technologies that necessitate new processes, technologies and skills.  While mobile application security does drive these new requirements, the overall problem is one that the security industry is already well acquainted with because the vulnerabilities showing up in mobile applications aren’t new at all. We often say that we are “Hacking like it’s 1999” because, the reality is that mobile vulnerabilities are are just the same old vulnerabilities that we have been hunting for over 13 years now: SQL injection, overflow, and client attacks.

These new requirements for mobile testing are driven by the new programming languages used for building mobile clients (Objective-C and Android’s Java variant), the new formats used by back-end web services (JSON and REST) and the new authentication and session management options (OAuth, HMAC, etc). And while those familiar SQL Injection attacks look almost exactly like they did 10 ago, you just can’t find them without understanding how to deliver these attacks within the new structures.

iphone image

SQL Injection Alive and Well

We call the mobile vulns the Where’s Waldo of application security. They’re your old familiar friend, SQL Injection, who looks almost exactly like he did 10 years before – maybe with a few gray hairs – but you just can’t find him as easily because he’s in an all new environment. We simply need to adjust to this new landscape and start looking for our old friend again.

Another important thing to keep in mind about mobile application security testing is that there ARE tools that automate the process. There just aren’t that many of them that automate the entire process or do it very well.

We see several categories of security vulnerabilities in mobile applications:

More on Mobile Application Security


[1] [2]Gartner Research Document

Gartner, Technology Overview: Mobile Application Security Testing for BYOD Strategies, By Joseph Feiman and Dionisio Zumerle, August 30, 2013.


Mobile application security testing – fast and easy!

Mobile-App-SecMobile application security testing: Four words that, for many security professionals, elicit a nagging feeling that comes from knowing the challenge is imminent if not already present, yet very difficult to tackle.

We at NT OBJECTives understand, and we’ve got your back. Our newest service offering is designed to help busy security teams easily and thoroughly test mobile applications – without intensive training or resource drain.

NTOMobile On-Demand gives NTOSpider customers everything they need to quickly security test mobile applications, including mobile client native code and back-end web services. No need to choose between testing the source code, testing the services or pen testing the mobile app. NTOMobile On-Demand does it all with a comprehensive software solution combined with expert pen testing.

Comprehensive mobile application testing requires both static and dynamic analysis, so we’ve packaged them together, along with expert pen testing, to deliver comprehensive mobile application security testing. By leveraging the power of NTOSpider’s dynamic application security testing capabilities, NTOMobile On-Demand effectively and automatically tests the web services that power mobile back ends and that leverage new technologies like REST, JSON and SOAP. You won’t find another web application security testing solution that delivers better coverage of your custom web service implementations.

Mobile application security testing is a challenge for security teams that don’t have the time or resources to invest in effective training and tools. NTOMobile On-Demand enables security teams to conduct comprehensive mobile application security testing – and obtain the peace of mind that comes from doing what needs to be done.

Mobile Apps

How to Overcome the Shortfalls of Web Application Security Scanners when Testing Mobile & Rich Internet Applications

Mobile AppsYou’ve built a custom rich internet application that is sure to become your business’ next major revenue stream. Conscious of security, you’ve ensured that the native application authenticates to the server, and you’ve run the app through a web application security scanner to identify weaknesses in the code. Those vulnerabilities have been remediated, and now you’re ready to go live.

Not so fast.

Despite your best intentions, chances are good your rich internet application is going live with dangerous security flaws. Most traditional web application security scanners and authentication methods do not provide the necessary protection when you’re dealing with modern application architectures, data formats and other underlying technologies. However, you can still build state-of-the-art rich internet applications with reliable and safe web application security by following these simple steps.

Step 1: Understand your chosen technology and its security requirements.

Classic HTML applications are no challenge for web application security scanners because that’s what they were originally built to do. However, rich internet applications based on newer technologies like AJAX, JSON and REST are a different story –,most security scanners do not support these new formats unless they’ve been re-architected. Due to the heavy use of JavaScript or complete lack of HTML, these new application formats and technologies make it nearly impossible for scanners to crawl an app. Plus, mobile applications further complicate matters because they often use web services which cannot be crawled at all.

To make matters worse, attackers are finding new ways to exploit application programming interfaces (APIs) associated with mobile applications. Web application session management techniques fail to deliver the protection developers expect, and these old and insecure techniques do not stop attackers from tampering with the application, committing fraud or performing man-in-the-middle attacks.

Therefore, it is important to understand the technologies used in your rich internet applications so you can find an appropriate web application security scanner and/or supplement your scanning efforts accordingly. Below is a list of the technologies that may require a more in-depth security solution:

  • AJAX applications: JSON (JQuery), REST, GWT (Google WebToolkit)
  • Flash remoting: Action Message Format (AMF)
  • HTML5
  • Back end of mobile apps powered by JSON, REST and other custom formats
  • Web services: JSON, REST, XML-RPC, SOAP
  • Complex application workflows: Sequences (shopping cart and other strict processes) and XSRF/CSRF tokens

Step 2: Understand the vulnerabilities of rich internet applications.

There are two key qualities you should require of a web application security scanner that you plan to use for modern rich internet applications. The first is the ability to import proxy logs. The second is an understanding of mobile application traffic, which enables the scanner to create attacks to test for security flaws. Vendors are often quick to advertise their scanners’ ability to be fed data from a proxy, but if the scanner is not familiar with JSON and REST, it will not be able to create attack variations – even when fed recorded traffic.

Like web application security scanners, traditional authentication methods fail to deliver the protection they once promised. While historically used to protect server-side mobile applications from SQL injection and cross-site scripting attacks, today’s authentication methods simply aren’t sophisticated enough to provide adequate web application security to new rich internet applications and mobile apps. For example, attackers can exploit weak passwords when a scheme only authenticates the user and not the application. This can be avoided by using a client-side certificate to identify the application, but this isn’t feasible for all apps – especially customer-facing mobile apps.

Step 3: Determine whether your web application security scanner is capable.

You can – and should – ask your web application security scanner provider what technologies the tool is able to scan. But don’t leave it at that – verify what they say is true. For instance, you can test for the security scanning coverage of an AJAX application by analyzing the request/response traffic. To do so, simply enable the scanner’s detailed logging feature, run the scanner through a proxy like Paros, Burp or WebScarab, and save the logs for manual review.

JSON also poses a unique challenge to web application security scanners. They must be able to decipher the new format and insert attacks to test the security of web application interfaces. A review of detailed logs of request/response traffic will indicate whether the web application security scanner is fully capable of protecting rich internet applications like yours. However, not all web application security scanners provide detailed logging. If this is the case, you will need to set up a proxy to capture traffic during the scan. Begin by scanning only a page that uses JSON, then check to see if the scanner requests include the JSON traffic and requests.

Step 4: Bolster manual testing efforts and custom web application security models.

Attackers are increasingly targeting back-end servers. And while new mobile APIs like JSON create new ways to engage customers in rich internet applications, they also create new ways for attackers to reach back-end servers. The only way to discover and remediate API security flaws, authentication weaknesses, protocol-level bugs and load-processing bugs is with several rounds of testing. Also, understand that you cannot rely on SQL or basic authentication to protect the back end. Develop server-based applications to anticipate attacks by continually verifying the integrity of the application and uptime environment.

Finally, when developing rich mobile applications, keep the following tips in mind:

  • Data provided by the client should never be trusted.
  • A device’s mobile equipment identifier should never be used to authenticate a mobile application, but do use multiple techniques to verify that requests are from the intended user.
  • Because session tokens for mobile apps rarely expire, attackers can use them for a very long time.
  • Credentials should not be stored in the application’s data store, local to the device.
  • When requiring SSL, a valid certificate should be necessary.

Guaranteeing reliable web application security for rich internet applications and mobile apps can be tricky business. However, completing the proper research, choosing the right security scanner, and performing an ample amount of testing will help detect vulnerabilities and ward off new attacks, allowing your application to be successful in the marketplace.

New Technologies in WebApp Sec

Webcast: SQLInjection Vulnerabilities Hidden in New Places

Why are your applications still suffering from SQL Injection Vulnerabilities?

Even though we know so much about SQL Injection, we have a perfect storm brewing for serious security problems in many modern applications. The perfect storm is brewing because the younger generation of developers who are building these new applications in technologies like JSON, REST, SOAP and AJAX aren’t experienced in security and the security professionals who need to test them aren’t experienced in these formats.


To make matters worse, business managers are under pressure to get these applications out quickly which often results in inadequate security testing. And then we have the scanners. Most scanners were built to scan classic HTML based apps.

Please join me next week on Wednesday, October 16th as I share what I have learned after two years of testing “modern applications.” such as mobile, RIA’s and web services. I will demonstrate that they are susceptible to all the same SQL Injection mistakes of the past.

This webcast is designed for both developers and security professionals who want to learn more about how SQLInjection and other vulnerabilities hide in these modern formats. I will go through each format, review how to understand it and how to find vulnerabilities in it. Finally, I will discuss how to scale testing on these kinds of applications in an automated way.

Join me for this webcast to learn

  • Why SQL Injection is so prevalent in these technologies despite the fact that we have understood SQL Injection for so long.
  • How to understand these newer formats (JSON, REST, SOAP) and find SQL Injection vulnerabilities in nine technologies commonly used in these applications.
  • How you can scale your testing to automatically find these vulnerabilities.

Finally, we’ll discuss how you can scale your testing with automation to automatically find these vulnerabilities.

See more at: