Software Security Testing the Keys to Launching a Safe, Secure Application
Total Page:16
File Type:pdf, Size:1020Kb
Software Security 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 Mobile Security………………. 3 - The Goal of Security Testing……………...……… 4 “The tools and techniques are there, the information is readily available, • Software 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 software testing 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 usability testing. 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? Authentication: Does your app check to see if you are who you say you are? Authorization: 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 Encryption 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.