Testing and securing android studio applications: Debug and secure your Android applications with Android Studio

What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Testing and securing android studio applications

Chapter 1. Introduction to Software Security

You want to learn how to improve your Android applications so that they're secure and robust. You would like to learn about mobile software security and its most important threats and vulnerabilities. You want your users to be satisfied while ensuring that their data is secure and that the application has no bugs. Can you do this easily? What do you need to do in order to achieve this?

This chapter will teach you the basics of software security. We'll begin by teaching you the different security terms that we will use in this book. You'll see the most important threats and vulnerabilities that may affect your application. You'll then learn about secure code design principles, as well as how to test our application for security issues.

In this chapter, we will cover the following topics:

Software security terms
Threats, vulnerabilities, and risks
Secure code design principles
Security testing

Software security terms

In recent years, the Internet has experienced a huge increase in electronic commerce (e-commerce). This increase in monetization of information in the cloud means that attackers can now be rewarded financially, socially, and even politically for a successful attack. There is a low risk in attempting these attacks, since there is a small chance of getting captured and therefore, of prosecution. With a more motivated enemy, companies and enterprises have to improve their security measures to face these new threats. They must identify the threats and defend the vulnerabilities that may affect the data that has a big impact on their business.

In order to understand the content of this book completely, you will first need to understand some basic concepts about software security:

Access control: This ensures selective access to resources by users that are entitled to it.
Asymmetric cryptography: This is also known as the public key cryptography and uses algorithms that employ a pair of keys—one public and one private. A public key is used to encrypt the data while a private key is used to decrypt data.
Authentication: This is a process through which we can confirm the identity of a user.
Authorization: This is a process through which we give someone permission to do or have something.
Availability: This means that the system and data are available to authorized users when they may make use of it.
Brute force: This is a very basic and nonoptimal cryptanalysis technique that tries every possibility to crack a key or a password.
Cipher: This is a cryptographic algorithm that may be used for encryption and decryption.
Code injection: This is an attack where the code is inserted into application queries. This kind of attack is commonly used to alter databases via SQL injections.
Confidentiality: This specifies that the data is only available for users who have permission to access it.
Crack: This is the process through which an attacker attempts to gain access to a machine, network, or software.
Decryption: This is the process through which an encrypted message is transformed into its original state.
Denial-of-service (DoS): This is a type of attack that makes an online resource unavailable for a fixed amount of time.
Distributed denial-of-service (DDoS): This type of attack is similar to the DoS attack, but it is perpetrated from several machines and is generally more effective than a DoS attack.
Dictionary attack: This is a basic cryptanalysis technique that uses all the words in a dictionary when trying to crack a key or password.
Encryption: This is a process through which a plain piece of data is transformed into an encrypted state, with the objective of concealing this information in order to prevent access from unwanted sources.
Hash function: This is a type of algorithm that maps data of different sizes into data of a fixed size.
Hijack attack: This is a form of attack in which an already established communication is seized and acts as one of the original participants.
Hypertext Transfer Protocol Secure (HTTPS): This is an application level protocol based on HTTP that allows a secure transfer of sensitive information in the form of hypertext.
Integrity: This means that the information is accurate and is not changed accidentally or deliberately.
MD5: This is a very commonly used hash function.
Man-in-the-middle attack: This is a type of attack where the attacker assumes a position in the middle of a communication, intercepts and reads the messages of a communication, and lets the victims believe that they are directly connected to each other.
Password: This is a string of characters used for authentication.
Phishing: This is an attack attempt that appears to be from a reliable source and tricks the user into entering their authentication credentials in a different domain or application.
Risk: This is the likelihood of an attack happening and succeeding.
SHA1: This is a commonly used hash function.
Sniffing attack: This is an attack that analyses the packets exchanged in a network in order to extract useful information from them.
Spoofing attack: This is an attack where an unauthorized entity gains access to a system with the credentials of an authorized user.
Symmetric cryptography: This is a type of cryptography that uses the same key for encryption and decryption, and therefore, every entity shares the same key.
Threat: This is a circumstance that could breach security and cause harm to the system.
Vulnerability: This is a weakness that allows for a threat to occur.

Threats, vulnerabilities, and risks

There are three key terms that you need to understand. They were defined in the previous section, but we will talk a little bit more about them since they are commonly mixed up. These terms are threat, risk, and vulnerability and they are discussed in the following sections.

Threat

A threat is anything that may exploit vulnerability in order to access, modify, or destroy information. A threat is the source and type of an attack and is what we try to defend against. Threat assessments are used to determine the best way to defend against a determined class of threat.

When we consider a communication between two authorized entities, a source (S) and a destination (D), threats can be categorized into the following four segments:

Interception: This happens when an attacking entity has an access to a communication between two authorized entities. The entities do not realize that interception is happening and keep on with their communication normally.
Interruption: This refers to when the attacking entity intercepts the communication. The source entity may not realize this is happening, while the destination entity has no knowledge of the communication attempt.
Modification: This happens when the attacking entity changes the information sent between the two authorized entities. The destination entity does not realize that the information has been tampered with by the attacking entity.
Fabrication: This happens when the attacking entity acts like the source entity. The destination entity acknowledges the communication as if it was produced by the source entity.

Vulnerability

Vulnerability is a weakness or a flaw in the security system of our application that may be used by a determined threat to access, modify, or destroy information. Vulnerability testing is mandatory and should be performed repeatedly to ensure the security of our application.

When a human or a system tries to exploit vulnerability, it is considered to be an attack. Some of the most common kinds of vulnerabilities that can be exploited to damage our system are as follows:

Improper authentication: This happens when an entity claims that it has been authenticated and the software does not check whether this is true or false. This vulnerability affects our system of access control, since an attacker can evade the authentication process. A very common example of exploiting this vulnerability is modifying a cookie which has a field that determines whether the user is logged in. Setting loggedin to true can cheat the system into believing that the entity is already logged in and is therefore granted access when it should not be granted.
Buffer overflow: This happens when the software has access to a determined amount of memory but tries to read a buffer out of the limits. For example, if the software has a buffer of size N but tries to read the position N+2, it will read information that may be used by another process. This grants access and even modifies the information that belongs to a part of the memory where the software should not have access.
Cross-site scripting (XSS): This is a kind of vulnerability that allows a third-party to inject code in our software. It is especially common in websites, but it also applies to certain mobile applications. The most commonly used examples of XSS are the access to cookies from a different site and the injection of JavaScript into a different site.
Input validation: When reading information provided by the user, it is always a good idea to validate the data. Not validating the data may result in an attacker introducing certain unexpected values that can cause an issue in the system.
SQL injection: This is a kind of input validation vulnerability. It is very common to use a search feature in almost any application. The string that the user introduces in the search field is then introduced in a SQL sentence. If there is no analysis and filter of the string provided by the user, an attacker could write a SQL query that would be executed. If this is combined with a bad access control, the attacker could even delete the whole database.

Risk

A risk is the potential for an attack happening and being successful. The more sensitive the information, the higher the risk of attack, as it can cause a higher level of damage to our system. Risks are the result of a threat exploiting vulnerability and accessing, modifying, or destroying a piece of information that we want to be protected. Risk assessments are performed to identify the most critical dangers and to evaluate the potential damage. This potential damage is calculated through a state between the cost of a breach happening, which depends on how sensitive the information is, and the probability of that event, which depends on the threats and vulnerabilities that may affect the application.

As you can see, there is a very important relationship between these three terms; especially when trying to correctly identify the risk that the information stored suffers. Assessing threats and detecting vulnerabilities is crucial to the protection of the information in our application.

Secure code-design principles

In order to reduce the number of vulnerabilities of your application, a good security design is mandatory. There are many standards and guidelines that recommend different processes to produce secure applications. In this section, we are going to identify the most important principles that you should follow when designing your application:

Secure defaults: Security is of the utmost importance for an average user. When designing your application, you should make sure that the most demanding user is going to be satisfied and, therefore, your application should offer the best security methods available. However, there are some users who may prefer accessibility over security and may want to reduce the level of security. For example, you may want to add password aging to your authentication system. This means that every established period of time, the users should change their password to a new one. This means an additional level of security but can be annoying for certain users. Adding an option in the preferences to turn off this feature can be a good idea. However, always make sure to set the default to the more secure setting, and let the user decide whether they want to increase the risk of breaching their information.
Least privileges: Privileges are sometimes conceded in excess in order to speed up the process of development. This principle states that you should always concede the least privileges as possible in order to minimize security risks.
Clarity: Never trust obscurity to ensure the security of your application. Concealing the information on how your security system works is a good idea, but it should not be granted as enough by itself; the security must come from good cryptographic techniques and a good security design.
Small surface area: If you know you may have vulnerability in a determined section of your code, you can try to minimize the risk of a threat exploiting it by minimizing the overall use of this section. For example, if you think that certain functionality may be exploited, you can restrict this functionality to authenticated users.
Strong defense: When defending against a certain attack, there may be different methods to use. One control can surely be enough but sensitive information demands extraordinary measures. Also, using more than one method of precaution is most of the times convenient.
Failing securely: When developing our application, we aim for the highest robustness. However, applications fail sometimes and we need to adapt our code to make sure the application fails securely. When programming for Android, we can address this issue by controlling every exception, for example, through the correct usage of try and catch.
Not trusting the third-party companies: There are many services available that have been developed by the third-party companies with different privacy and security policies. It is important to know that while using one of these services, you trust the companies on how they use your information. The principle of not trusting the third-party companies recommends that you should only trust an external service with the minimal amount of information possible and always implies a certain level of trust with them.
Simplicity: Always try to keep your security code simple. Although it is recommended to use code patterns, when talking about security, the safest and more robust way is its simplicity.
Address vulnerabilities: When you detect vulnerability, it is important to address this issue correctly. You need to understand both the vulnerability and the threat and then act accordingly.

Testing the basics

As stated by Boris Beizer, author of the book Software Testing Techniques, Dreamtech Press:

"Bugs lurk in corners and congregate at boundaries."

Security testing can be defined as a process through which we find vulnerabilities or flaws in our security system. Although we may do exhaustive security testing, it does not imply that no flaws exist. In this section, we will focus on the taxonomy of tests that can be performed in any circumstance.

Tests can be categorized into two big groups: white-box tests or structural tests and black-box tests or functional tests. Structural testing, more commonly known as the white-box testing, is a testing method that evaluates the internal behavior of a component. It is focused on the analysis of the behavior of each procedure in different moments of execution. The white-box test evaluates how the software produces a result. Functional testing, specification testing, or black-box testing, are methods of testing that focus on the functionality of the component rather than its structure. When using this kind of test, the tester is aware that a certain input should generate a particular output. This test evaluates what the software produces.

The two test categories, white-box test and black-box test, are shown in the following diagrams:

There are various white-box techniques. However, the most commonly used are control flow testing, data flow testing, basis path testing, and statement coverage and they are explained as follows:

Control flow testing: This evaluates the flow graph of the software to indicate whether the set of tests covers every possible test case.
Data flow testing: This requires an evaluation of how the program variables are used.
Basis path testing: This ensures that every possible path in a code has been included in the test cases.
Statement coverage: This consists of the evaluation of the code and the development of individual tests that will work on every individual line of code.

The black-box testing design also includes different techniques. The most frequently used techniques are equivalence partitioning, boundary value analysis, cause-effect graphing, state transition testing, all pairs testing, and syntax testing, and they are explained as follows:

Equivalence partitioning: This divides test cases in different partitions that present similar characteristics. This technique can help in reducing the number of tests cases.
Boundary value analysis: This is performed in order to analyze the behavior of a component when the input is near the extreme valid values.
Cause-effect graphing: This graphically illustrates the relationship between circumstances or events that cause a determined effect on the system.
State transition testing: This is performed through a number of inputs that make the system execute valid or invalid state transitions.
All pairs testing: This is a combinatorial method that tests every possible combination of parameters. When the number of parameters and the possible values for each parameter are big, this test technique can be combined with the equivalent partitioning technique to reduce the number of test cases.
Syntax testing: This analyses the specifications of a component to evaluate its behavior with a huge number of different inputs. This process is usually automatized due to the large number of inputs required.

When testing an application, there are different levels of testing that depend on the size of the part of the system involved. There are five commonly known levels of tests: unit, integration, validation, system, and acceptance.

Unit tests: These tests focus on each individual component. These tests are usually performed by the same development team and consist of a series of tests that evaluate the behavior of a single component checking for the correctness of the data and its integrity.
Integration tests: These tests are performed by the development team. These tests assess the communication between different components.
Validation tests: These tests are performed by the fully developed software in order to evaluate the fulfilment of functional and performance requirements. They can also be used to assess how easy it is to maintain or to see how the software manages errors.
System tests: These tests involve the whole system. Once the software is validated, it is integrated in the system.
Acceptance tests: These tests are performed in the real environment where the software is used. The user performs these tests and accepts the final product.

The higher the level of testing, unit testing being the lowest and acceptance testing the highest, the more likely it is to use black-box tests. Unit tests evaluate components that are small and therefore easy to analyze in behavior. However, the higher the level, the bigger the system, and therefore the more difficult and more resource-consuming it is to apply white-box testing category. This does not mean that you should not apply the black-box testing category while performing unit tests, as each one complements the other.

What you will learn

Control the execution of your Android application by working with the debugging environment in Android Studio

Mitigate the existing vulnerabilities in Android applications

Create unit tests to verify the state and behavior of an activity

Use local storage and encryption appropriately to preserve the privacy of your application data

Ensure that communications between your applications and external servers are safe by protecting network connections

Choose the appropriate authentication method for your Android application

Set up the test environment to create test cases

Create functional tests to check the interaction between components

What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Frequently bought together

Testing and securing android studio applications

€29.99

€36.99

Total € 66.98

SuJo Nov 19, 2014

Testing and Securing Android Studio ApplicationsWhat an amazing book, securing applications is so important and yet I find games that are exploitable because they don't follow security practices which result in a terrible experience. There are zero day hacks for many games on both the iOS and Android markets, and this book would be the holy grail for developers for securing their applications. The book was practical and very easy to follow. I enjoyed the coverage over each authentication method, and I was delighted to find out about the HTTPS utilization in applications, I figured it was the de facto standard, boy was I wrong.If you're developing applications then you should pickup a copy of this book, it is a real eye opener. Before I conclude this review it is highly noteworthy to mention the coverage on unit testing, I find many books ignore this completely and shouldn't. I'm very glad this book included it and didn't leave it out!Publisher Link: https://www.packtpub.com/application-development/testing-and-securing-android-studio-applications

Amazon Verified review

Rossi Pietro Alberto Oct 06, 2014

The book is composed by eleven chapters that on the whole are the basis to secure an Android application.The first chapter introduces the various terms of security and the different types of vulnerability that can occur. A very important chapter because it provides the basis to understanding the rest of the book. Also, it describes the various types of tests: unit, integration, validation, system and acceptance.The second chapter describes the architecture of Android operating system and the basics regarding the permission, Intent and content provider, highlighting the possible problems that could occur managing these badly.Android has various tools to monitor of an application. The third chapter introduces the DDMS tool. It includes various tools like Thread monitor, Network Statistics, File Explorer, etc...all are described briefly to get an idea of what the Android SDK provides us.The fourth chapter describes how to make common actions safe, like database communication, avoid SQL Injection, and validation of input.The problem of the privacy is widespread in IT habit and what the fifth chapter suggests is to secure our data, saved on shared preference or storage, encrypting the data themselves. The examples of codes are very explicative and simple to understand.The sixth chapter continues with the file of the previous chapter, adding one more security level over the network connection, recommending the HTTPS protocol that allows us to have encrypt and secure communication.There exists several types of authentication, besides the common username and password. The seventh chapter describes the various types of authentication, based on different factors underlining these phrases: “something the user knows”, for user and password or pin code, “something the user has”, for TOTP, and “something the user is”, for biometric authentication.Also, the chapter describes how to use the AccountManager class to manage the possible account saved on the device.The eighth and nineth chapters talk about testing out-and-out, differentiating between unit tests and functional tests. They start with a simple test project, up to examining all the classes that promote test developing, important to prevent bugs after publishing the application. As a test-developer, reading these chapters is very important to understand how to work with the Android platform.The tenth chapter describes foreign libraries to facilitate the creation of tests, a thing that could speed up the writing of tests.The last chapter explains the possible parts of application to be tested, for example the behaviour without stable internet connection or when to change the orientation of the screen.The book, in its own small way, is great to identify the basic aspects regarding the testing and the safety of the application. Every developer should have a copy of this book in his library. Highly reccomended.

Alain Couniot Oct 17, 2014

"Testing and Securing Android Studio Applications" is a book everybody involved in serious Android application development should read. Despite many years spent in various IT roles, with an accent on architecture, methodology and security, I have learned from this book. (And should I add: what I have not learned was nicely and adequately introduced and explained by the authors). Let's be clear: despite addressing all the (too often neglected because considered boring) aspects of professional Android developments, the book is too concise to qualify as a "Bible" in its domain. It won't turn you into an Android Jedi developer (not to say, Ninja ;-) ). However all relevant topics are covered, albeit very briefly, by a well-balanced mix of theory and practical considerations. The book is structured taking the typical application life cycle as a foundation and is very well structured indeed. The authors have succeeded in turning "un-sexy" topics into an interesting reading, with a few examples. Tools and libraries are briefly mentioned (maybe too tersely) and their respective strengths and weaknesses are analysed. A highly recommended reading.

Shane Nov 05, 2014

A robust and secure product plays a major role to success in the Android market place. "Testing and Securing Android Studio Applications". The introduction is at a high level but this book quickly gets into some deeper Android programming techniques. I appreciated how threads were covered in Chapter 3 and found it useful in the application I'm developing. Overall this is a well organized text and an good reference for anyone developing with Android.

Kevin P Nov 13, 2014

The usefulness of this book really depends on your Android development skills. I found it a bit too much high level. It touches a lot of interesting things, but then the deep research is left to the reader, which is a pity.I wasn't sure what to expect from the combination of testing and security. Then I figured it actually makes sense, because you need to test the security measures you're taking. But the book does not cover that at all. First there is a high level overview of security and then there is a high level overview of testing, both smacked together into one book.I'm still rating it 4 stars because it can be a very interesting introduction to both these topics for a lot of people. If you've looked into security and testing Android apps a bit yourself, this book is probably not for you.

Testing and securing android studio applications: Debug and secure your Android applications with Android Studio

What do you get with Print?

Testing and securing android studio applications

Chapter 1. Introduction to Software Security

Software security terms

Threats, vulnerabilities, and risks

Threat

Vulnerability

Risk

Secure code-design principles

Testing the basics

Summary

Page 1 of 6

Description

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the authors

FAQs

Testing and securing android studio applications: Debug and secure your Android applications with Android Studio

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Description

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the authors

FAQs