<<

Software Testing The Keys to Launching a Safe, Secure Application

White Paper June 2011

White Paper: Security Testing

White Paper Security Testing The Keys to Launching a Safe, Secure Application

Table of Contents • Introduction………………………………………….. 3 - State of Web and ………………. 3 - The Goal of Security Testing……………...……… 4 “The tools and techniques are there,

the information is readily available, • Security………………………………….. 3 but security still takes a lower 1. Know Your Enemy: Common Attacks……. 5 priority until an accident happens. 2. Security Testing Scenarios………………… 6 Just look at the breaches that appear 3. Building Your Security Team……………….. 7 4. Mobile App Security……………..………….. 8 on an almost daily basis.” 5. Security Testing Tools……….……………… 9 6. Summary and Next Steps…………………….10 - James Sivak, Former QA • About uTest………………………………………….. 11 Director of McAfee

You might also like….

eBooks White Papers Case Studies

Our whitepapers See how Read our new have everything companies of all collection of you need to sizes are improve the way launching better eBooks, written you test your apps for less by some of the web, mobile and time and money industry’s leading desktop apps: with uTest experts.

utest.com/ebooks utest.com/whitepapers utest.com/customers

2 White Paper: Security Testing

Introduction

The State of Web and Mobile Security “The flaw, which could enable a knowledgably criminal to use a computer to break Netscape’s security coding system in less than a minute, means that no one using the software can be certain of protecting credit card information, bank account numbers or other types of information that Netscape is supposed to keep private during on-line transactions.” – New York Times, 1995

Not much has changed in sixteen-odd years, as the fundamental threat of hackers, thieves and miscreants remains as real today as it did in 1995. Don’t take our word for it though; here are some eye-popping statistics from whitehatsec.com on the previous year in software insecurity:

 Most websites were exposed to at least one serious vulnerability every day of 2010). Only 16% of websites were vulnerable less than 30 days of the year  During 2010, the average website had 230 serious vulnerabilities  In 2010, 64% of websites had at least one information leakage vulnerability, which overtook cross-site scripting as the most prevalent vulnerability by a few tenths of a percent

In other words, hardly a day goes by without a major security breach. And while intrusions at giant organizations like Citi, Sony and the US Senate receive the lion’s share of media attention, the truth is that everyone is at risk.

With all that’s at stake, it’s puzzling to see security testing take a back seat to other forms of quality assurance, like functional or . Though still important to launching a high-caliber application, each of these practices can be rendered meaningless if a hacker is able to perform any number of common exploits. To quote software security guru James Whittaker, from his book How to Break Software Security:

“Software can be correct without being secure. Indeed, software can meet every requirement and perform every specified action flawlessly yet still be exploited by a malicious user. This is because security bugs are different from traditional bugs. In order to locate security bugs, testers have to think differently too.”

Though he was writing for an audience of software testers, the same applies to companies large and small: In order to improve the security of your application, you need to accept the fact that security testing is a much different animal – which brings us to the purpose of this brief whitepaper.

By offering tips, tools and advice for companies of all sizes, we hope to lay out a few simple approaches to help you make your current and future applications more secure.

3 White Paper: Security Testing

The Goal of Security Testing Despite the Hollywood stereotypes, the goal of security testing is NOT just to ensure that your application is safe from shady criminals hell bent on world domination (although we hope it is). In reality, security testing should first be thought of without any regard to hackers. To put you in the proper state of mind, here are a few important security-related questions to ask yourself:

 Confidentiality: Does your application keep your private data private?  Integrity: Can the data from your app be trusted and verified?  : Does your app check to see if you are who you say you are?  : Does your application properly limit your privileges?  Availability: Can an attacker take your application offline?  Non-Reputation: Does your app keep records of events for later verification?

As you can see, hackers are not necessarily a prerequisite to insecure software. The discipline is in fact much broader than commonly perceived. More on that in a second, but now, let’s now dive into some specifics for improving the security of your application.

Software Security 1. Know Your Enemy: Common Attacks The list of security threats is exhaustive, but some are more prevalent than others. Here’s a quick look at some of the most common security exploits, along with a brief definition.

 Cross-Site Scripting: This exploit occurs when someone tricks a website into accepting malicious code, which will be shared with other visitors, thus compromising their security. The term “cross-site” applies to an entire family of attacks, where users are tricked into doing something on a site with their knowledge or consent.

 SQL Injection: With this breach, an attacker tricks a website into running an arbitrary SQL command on the database layer of an application, usually within queries, where user input is incorrectly filtered.

 Spoofing: Spoofing is when an attacker tricks an application into believing they are someone (or something) they’re not. For example, a hacker may duplicate an e-commerce site in an effort to get users to enter their credit card and personal information.

 Buffer Overflows: A complex attack to trick an app (desktop, mobile and occasionally web) into executing malicious code. Bugs like this are hard to discover without code review, mindless automation, or evil geniuses. A buffer overrun occurs when a program allows input to write beyond the end of the

4 White Paper: Security Testing

allocated buffer. This can result in an attacker gaining control of an entire operating system. Many famous exploits are based off buffer overflows.

 Denial of Service: This attack involves someone performing a malicious action to prevent a computer from delivering an intended service. Here, it is most often a concerted effort on the part of multiple people to prevent a site from delivering a vital service. Targets for such attacks often include applications that are hosted on large web servers (i.e. banks, credit cards, government services).

 Social Engineering: Simply put, this exploit involves breaking computer security by tricking people, not software. This is one of the easiest ways to compromise security and one of the hardest to prevent. Examples of this breach include fake anti-virus software, which “alerts” users to recently discovered “vulnerabilities”.

As noted, there are dozens (if not hundreds) of similar exploits, but these are the ones you should be watching out for. As further proof, here are the ten most dangerous and prevalent programming errors of 2011, as compiled by Common Weakness Enumeration:

1. Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) 2. Improper Neutralization of Special Elements used in an OS Command 3. Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’) 4. Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) 5. Missing Authentication for Critical Function 6. Missing Authorization 7. Use of Hard-coded Credentials 8. Missing of Sensitive Data 9. Unrestricted Upload of File with Dangerous Type 10. Reliance on Untrusted Inputs in a Security Decision

Now that you’ve identified some of the biggest threats, let’s take a look at some ways to determine if your application is at risk.

2. Security Testing Scenarios

Security testing isn’t easy, as the more complex aspects of security testing take years to learn. However, it’s relatively easy to put yourself in the proper state of mind to start identifying areas of weakness. Here are a few scenarios and practices to consider, courtesy of expert security tester Bill Ricardi. Note that the tips presented here have been written for novice security testers, yet the principles apply to anyone inside a company or organization who wants better insight into the security of their application.

5 White Paper: Security Testing

On the outside looking in The first stage of intrusion testing is to assume the role of a kid with his nose pressed against the glass window of a candy store. You are determining your motives. Why would you want to break into this site, if you were an intruder? Certainly, the motives of anarchy and revenge are always appropriate. But is there financial gain available? Is there sensitive information that might be used to embarrass or blackmail the company? Is there confidential client information that needs to remain private?

Your perceived motivations can be used to expand the range of standard attacks that you might mount against the test platform. Financial gain might mean a focus on the checkout stack. Sensitive internal information might mean mounting an attack on their internal email. Confidential client information means a focus on the client login scripts.

You need to understand motivation, so that you can explain why security is important to your application. Often times (and this is especially true with start-up companies), a company won't understand why anyone would want to target them with an attack.

Getting a Foothold A 'foothold' scenario is when an invader is trying to set up shop in your territory. After you've determined what you can get out of a particular application or web site, you need to put that in the back of your mind. That is a goal, a final step. The first thing that you need to do is find something - anything - that will help get you 'inside.’ You need to dig for more information, more access, and more power. Like any good invader, it is time for you to establish a foothold.

On a web server, gaining your foothold might involve scanning for security risks in the form of old software or open ports. For other client-server software, you might search the web for potential valid logins (possibly discovered by publicly known email addresses, FTP accounts, etc.) that you can try to crack. Look at the notes in the source material (and view the source of web pages on the server) to see if there are hints of otherwise un-advertised insecurities.

You don't care how you get 'in', as long as you get in. It doesn't matter if all you get is an E-mail account when you were looking for a way to crack their credit card authorization system. Once you have a foothold, you can develop your position into something more advantageous.

Pressing the Advantage No matter what kind of foothold you get, you should be able to leverage it into something important: Information. You're no longer on the outside looking in. You're inside the candy store, but you need to quietly get to the display case that has all of the good candy! So now is a time of discovery. What can you do with the access

6 White Paper: Security Testing

that you've earned? Read every help file. Use every informational command. Avoid interacting with human beings... talk to the robots. Anything that answers your requests automatically is your friend! Get all of the information you need to map out the software and services available to you. Then research the weaknesses of the particular versions of the program that you encounter.

Seek to be redundant. If you have one user account in hand, see if you can get another via the same discovery methods. If you have an FTP or Telnet login, see if you can also get its counterpart for all other active services. Lay your backup plans, just in case you get discovered. If you have access to create new accounts, make a handful with different access levels. If this company has the same security setup on different servers, seek to spread it out to other machines. If you find a weakness in one router, map out their network and see if the same weakness will give you access to other routers. Use your information. Expand. Look for the pot of gold.

Reporting the Kill At this point, you have come full circle. You can go back to the mindset that you had when you started the process, and see if you can achieve any of the goals that a motivated attacker might have. You should have all of the information that you need to either make your case, or discover an avenue of attack that you might not have thought of before you had all of the facts.

If your research yields something that you consider 'powerful' (be it root access, a strong denial of service, stealing the identity of someone in power, etc.), be careful, as you might not want to demonstrate the new power you’ve discovered, but rather just evidence of how you got there.

Some clients will be savvy and experienced enough to understand what you've accomplished, and see the writing on the wall. They'll be glad that you haven't done any damage that they'll have to undo, whether or not you had permission! Other clients will want you to go ahead and execute at least some level of final attack, so that they can see what the end result would be. If that's the case, don't overdo it. If you can make your attack reversible, great. If you can turn it off at will, super.

But at this stage, consult with the project leader for your best course of action before doing anything rash. Some clients test on production servers. In cases like this, NEVER take it down or take it out of action. If the clients ask you to, explain to them the consequences of their request via your project leader!

As you can see, you have to be really careful about your 'proof'. Good documentation, a lot of screen shots, and referencing the right security articles is usually a much better option than a destructive attack.

As noted, these approaches should be a substitute for professional security testing, but they should put you in the correct state of mind to understand the general principles of .

7 White Paper: Security Testing

3. Building Your Security Testing Team

If you’re like most companies with a software product or application, chances are you have an in-house QA team, staffed with testers who are experienced in , automation and other common testing practices. But when it comes to security testing, the same testers might not have the mindset and experience to excel at security testing. In other words, security is a much different animal.

For this reason, it’s recommended to contract with a specialty firm to conduct your security testing. But if you do decide to hire full-time staff, are a few tips on hiring from some of the most successful QA managers and testing minds in the industry:

“Almost all of the best people I know in testing have significant experience in other fields. It’s common for people to move from testing to programming or writing or marketing and then back, bringing what they’ve learned with them, to test with a richer perspective and with a much more productive vision of where testing can fit within development/marketing/support cycles.” – Cem Kaner, original author of the Agile Manifesto

As a hiring test manager, I look for these qualities: cautious, critical, curious, friendly, diplomatic, honest, insightful, and thoughtful. I want candidates to tell me about a cool bug they found, or give me their best test idea. I want them to make me think. I want them to inspire me and make me curious.” – Jon Bach, QA Director of eBay

“I know how to teach people technologies, the basics of a new programming language, how to report bugs, how to document process, and how to generate test ideas from whatever information we have. What I don’t know how to teach people is how to be curious, the desire to investigate their curiosity, or to be excited by the thought of investigating things that strike them as odd.” – Scott Barber, testing author and consultant

“It’s a mindset and a passion. From the 100s of interviews I’ve done, “great” boils down to: 1) a special predisposition to finding problems and 2) a passion for testing to go along with that predisposition. In other words, they love testing and they are good at it. They also appreciate that the challenges of testing are, more often than not, equal or greater than the challenges of programming. A great “career” tester with the testing gene and the right attitude will always be able to find a job. They are gold.” – Patrick Copeland, Senior Engineering Director, Google

To be a good tester you must be curious about technology, and eager to learn it. You must be able to ask questions and make explanations. You must be skeptical, but you must have at least a little faith about one thing: the possibility of undiscovered trouble.” – James Bach, author, speaker and founder of Satisfice

8 White Paper: Security Testing

Of course, you’ll also want to have a testing team diverse in technical matters, including hardware and software, experience, location, languages and other categories.

4. Mobile App Security

The explosion of mobile devices and applications presents yet another challenge for companies looking improve the security of their products and businesses. While most of the tools and practices of traditional web and desktop applications are equally applicable to mobile, there are some unique concerns to keep in mind, including:

 Lost or stolen devices  Consumer device access  Managing access to data and apps  Compliance requirements  Employees using Wi-Fi hotspots  Targeted attacks on devices  Mobile

Veracode, a leader in Application Risk Management, outlined the unique risks of mobile apps for developers in a recent blog post. There’s a lot to cover here, but here’s the key excerpt to get you started in the right direction:

There are 2 main categories of mobile app risks. The category of Malicious Functionality is a list of unwanted and dangerous behaviors that are stealthily placed in a Trojan app that the user is tricked into installing. The user thinks they are installing a game or utility and instead get hidden , UI, or unauthorized premium dialing.

A. Malicious Functionality

Activity monitoring and data retrieval

1. Unauthorized dialing, SMS, and payments 2. Unauthorized network connectivity (exfiltration or command & control) 3. UI Impersonation 4. System modification (, APN proxy config) 5. Logic or

The category of vulnerabilities are errors in design or implementation that expose the mobile device data to interception and retrieval by attackers. Vulnerabilities can also expose the mobile device or the cloud applications used from the device to unauthorized access.

B. Vulnerabilities

9 White Paper: Security Testing

7. Sensitive data leakage (inadvertent or side channel) 8. Unsafe sensitive data storage 9. Unsafe sensitive data transmission 10. Hardcoded password/keys

Essentially, as your business become more mobile, be sure not to ignore this component of testing.

5. Free Security Testing Tools

Having already identified several methods for approaching security, it’s now time to take a closer look at some free tools to make the process run more efficiently:

Wireshark: A comprehensive yet easy-to-use protocol analyzer (sniffer) which will allow you to view, filter and analyze all network transmissions.

Paros Proxy: Acts as a proxy which allows the tester to intercept and modify all HTTP/S data between server and client, including cookies and form fields.

Burp Suite (Man-In-The-Middle): Integrated platform for attacking web applications which contains several interfaces for handling HTTP requests, persistence, authentication, downstream proxies, logging, alerting and extensibility. Acts as a man-in-the-middle between client and server, thus allowing the tester to intercept and modify all HTTP requests between both parties.

WebScarab: Framework for analyzing and modifying all HTTP/S requests and responses between the browser and the server, which uses several plugins.

SQL Injection 1.2: A component to transform check boxes, radio buttons, select elements to a input text and enable disabled elements from all forms in a page. It makes it easier to test and identify SQL injection vulnerabilities in web pages.

Access Me: Accessing vulnerabilities in an application can allow an attacker to access those same resources without being authenticated. Access-Me is a Firefox extension used to test for these types of vulnerabilities.

SQL Inject me: SQL Injection vulnerabilities can cause a lot of damage to a web application. A malicious user can possibly view records, delete records, drop tables or gain access to your server. SQL Inject-Me is Firefox Extension used to test for SQL Injection vulnerabilities.

XSS Me: Cross-Site Scripting (XSS) is a common flaw found in today’s web applications. XSS flaws can cause serious damage to a web application. Detecting XSS vulnerabilities early in the development process will help protect a web

10 White Paper: Security Testing

application from unnecessary flaws. XSS-Me is the Exploit-Me tool used to test for reflected XSS vulnerabilities.

Tamper Data: View and modify HTTP/HTTPS headers and post parameters. It’s a similar tool to Burp suite, however, it features basic and limited data tampering capabilities directly via FF.

When selecting a tool for security testing purposes, be careful not to over-invest. A free tool is something can be freely abandoned, whereas an expensive tool becomes something you might feel obligated to use, regardless of its effectiveness.

Summary and Next Steps

Security failures can occur for a number of reasons, whether it be poor design, code, processes, people, training, or a combination of the above. Regardless of the source, it's critical for today's software companies to identify these security risks as soon as possible - a difficult task when internal resources are stretched thin.

Utilizing white hat security experts from our global community of 50,000 testers, uTest – the world’s largest marketplace for software testing services – can provide any size company with a variety of security testing services. We’ll probe for the most common security & privacy vulnerabilities, including XSS (cross-site scripting), SQL injection, Denial of Service (DoS) and other common attacks.

Our services include:

 Manual Penetration: A hand-picked team of white-hat security experts will manually probe your application for common security vulnerabilities.  Static Security Testing: Utilizing the latest in automated technology, uTest will review your static code for common security holes.  Dynamic Security Testing: Using live testers and automated tools, uTest will search your active code for XSS, SQL and other common attacks.

For more information, including details on pricing and deliverables, visit:

www.utest.com/secuirty-testing

11 White Paper: Security Testing

About uTest uTest provides in-the-wild testing services that span the entire software development lifecycle – including functional, security, load, localization and usability testing. The company’s community of 50,000+ professional testers from 180 countries put web, mobile and desktop applications through their paces by testing on real devices under real-world conditions.

Thousands of companies -- from startups to industry-leading brands – rely on uTest as a critical component of their testing processes for fast, reliable, and cost-effective testing results.

More info is available at www.utest.com or blog.utest.com, or you can watch a brief online demo at www.utest.com/demo.

uTest, Inc. 153 Cordaville Road Southborough, MA 01772 p: 1.800.445.3914 e: [email protected] w: www.utest.com

eBooks White Papers Case Studies Case Study Our whitepapers See how Read our new have everything collection of Case Study companies of all you need to sizes are software testing improve the way eBooks, written launching better you test your apps for less by some of the web, mobile and industry’s leading time and money desktop apps. experts. with uTest.

utest.com/ebooks utest.com/whitepapers utest.com/customers

12