Security Checklist II

This is the second part of the Mobile App testing checklist series. The first part is presented here. Continuing the series, we present a checklist of test cases for some more categories.

Network Communication Requirements

Apps serve as the front end and frequently make network calls to backend systems. This interaction involves exchanging critical information like personal details, bank information. Communication with external systems, particularly over the WWW, requires that the data sent should be over a secure channel to prevent it from being compromised.

For Android and iOS

Verify All network traffic goes via SSL

Verify SSL Pinning is enabled.

i.e. Using MITM tools like Charles, verify that the https traffic cannot be decrypted Platform Interaction Requirements

Platform Interaction Requirements

Modern smartphones offer a bevy of features. Camera, location, Bluetooth, gyroscope, and many more. Apps that use any such feature have to ask for the user’s consent to use the same. It is necessary to verify if the user is prompted to wilfully permit the app to use any feature outside of itself.

For Android

• Verify for dangerous permissions, for all the below permissions an explicit prompt should be displayed to the user
• READ_CALENDAR
• WRITE_CALENDAR
• READ_CALL_LOG
• WRITE_CALL_LOG
• PROCESS_OUTGOING_CALLS
• CAMERA
• READ_CONTACTS
• WRITE_CONTACTS
• GET_ACCOUNTS
• ACCESS_FINE_LOCATION
• ACCESS_COARSE_LOCATION
• RECORD_AUDIO
• READ_PHONE_STATE
• READ_PHONE_NUMBERS
• CALL_PHONE
• ANSWER_PHONE_CALLS
• ADD_VOICEMAIL
• USE_SIP
• BODY_SENSORS
• SEND_SMS
• RECEIVE_SMS
• READ_SMS
• RECEIVE_WAP_PUSH
• RECEIVE_MMS
• READ_EXTERNAL_STORAGE
• WRITE_EXTERNAL_STORAGE
• Verify unnecessary permission are not added in Android.manifest file
• Verify app authentication is required when using Deep Links in the app
• If webviews are displayed inside the app, ensure the url is https, and cannot be decrypted via Charles
• Disable local file access in Code. Check with the developer and see if these restrictions are in place.
• webView.getSettings().setAllowFileAccess(false);
• webView.getSettings().setAllowFileAccessFromFileURLs(false);
• webView.getSettings().setAllowUniversalAccessFromFileURLs(false);
• webView.getSettings().setAllowContentAccess(false);
• Verify that App can be force updated.

For iOS

• Verify app ask user permissions for the following
• Bluetooth peripherals
• Calendar data
• Camera
• Contacts
• Health sharing
• Health updating
• HomeKit
• Location
• Microphone
• Motion Music and the media library
• Photos
• Reminders
• Siri
• Speech recognition
• the TV provider
• Verify app authentication is required when using Deep Links in the app
• Verify webviews only load https content. Check the code for WKWebView and verify the following flag “hasOnlySecureContent” is set to true
• Verify Webviews cannot be decrypted via Charles
• Verify Both allowFileAccessFromFileURLs and allowUniversalAccessFromFileURLs are set to “0”, on webviews are set. Check with developers
• Verify that App can be force updated.

Code Quality and Build setting requirements

Apps have a minimum of two configurations; a debug version where the app is not yet optimized for release or customer use.

For example, logs would be enabled in the debug version to track bugs while developing. In the debug version, the app can get away with being slower and “fatter”. Apps also have a production version, meant for end-users. Here the app is “thinned” down for the target device on which the app is running. This version is optimized. So when it comes to the production version of the app, it is essential to test the build settings and other aspects used only for the debug version such that it does not leak into the production version.

For Android

• Verify APK is Signed correctly.
• Test using the following command,
• apksigner verify –verbose Desktop/example.apk,

Following output should be displayed

for example,

Verified using v1 scheme (JAR signing): true

Verified using v2 scheme (APK Signature Scheme v2): true

Verified using v3 scheme (APK Signature Scheme v3): true

Number of signers: 1

• Verify the store build is generated as a “Release” build and not “Debug” build.
• Using apktool decompile apk and check AndroidManifest.xml, android:debuggable should false
• Verify APK is Obfuscated (i.e, Proguard is enabled) and no sensitive data is visible.Decompile the apk using apktool. Convert classes.dex to .jar using d2j-dextojar. View the jar file via JDGUI
• Verify all debug logs are disabled. Run adb logcat and check if the apk is displaying any sensitive information

For iOS

• Check the ipa is Release Mode and not in Debug Mode. Use Xcode and Check if the app can be debugged.
• Check all debug logs are disabled and no sensitive information is logged in Xcode
• Verify “Strip Debug Symbols During Copy”, “Strip Linked Product”, “Strip Swift Symbols” are set to Yes in Xcode build settings
• Check for vulnerabilities in 3rd party Pods. Run OWASPs tool
• dependency-check –enableExperimental –out . –scan Podfile.lock
• Resiliency

For Android

• Verify apk does not launch on rooted devices.
• Checksum of apks should be created and validated against the server every time it’s launched.

For iOS

• Verify app does not launch on Jailbroken phones
• Obfuscate code with iXGuard and verify via MachoView tool

How does MQTT work in IoT projects?

 

If you think that the internet has changed your life, think again. The IoT is about to change it all over again!

What Is IoT?

The Internet of Things, or IoT, refers to the billions of physical devices around the world connected to each other via the Internet. Collecting and sharing data. Connecting up all these different objects and adding sensors to them adds a level of intelligence to these devices, enabling them to communicate real-time data without involving a human being. These devices range from ordinary household objects like bulbs, thermostats to sophisticated industrial tools, computers, etc. Previously Bluetooth and RF (radio frequency) were used to control IoT applications, but they were limited to a short distance. Adding MQTT capabilities can help in overcoming inter-communication problems by securely automating IoT appliances.

What Is MQTT?

MQTT is one of the most commonly used protocols in IoT projects. MQTT (Message Queuing Telemetry Transport) is a messaging protocol that works on top of the TCP/IP protocol. MQTT can also run on SSL/TLS. SSL/TLS is a secure protocol built on TCP/IP to ensure that all data communication between devices is encrypted and secure. MQTT is a lightweight protocol that uses publish/subscribe operations to exchange data between clients and the server. Furthermore, its small size, low power usage, minimized data packets and ease of implementation make the protocol ideal for the “machine-to-machine” or “Internet of Things” world. Unlike HTTP’s request/response paradigm, MQTT is event-driven, and clients receive published messages. This type of architecture decouples the clients from each other to enable a highly scalable solution without dependencies between data producers and data consumers.

How does MQTT work?

MQTT uses your existing Internet home network to send messages to your IoT devices and respond to the messages.

At the core of MQTT is the MQTT broker and the MQTT clients. The broker is responsible for dispatching messages between the sender and the rightful receivers. An MQTT client publishes a message to a broker and other clients can subscribe to the broker to receive messages. Each MQTT message includes a topic. A client publishes a message to a specific topic and MQTT clients subscribe to the topics they want to receive. The MQTT broker uses the topics and the subscriber list to dispatch messages to appropriate clients. If the connection from a subscribing client to a broker is broken, then the broker will buffer messages and push them out to the subscriber when it is back online. If the connection from the publishing client to the broker is disconnected without notice, then the broker can close the connection and send subscribers a cached message with instructions from the publisher.

MQTT Components:

In MQTT there are a few basic concepts that you need to understand:

Broker – The broker is the server that distributes the information to the interested clients connected to the server. This is the heart of the publish/subscribe protocol. The MQTT Broker is optimally designed to handle many thousands of concurrently connected MQTT clients.

Client – The device that connects to broker to send or receive information. The MQTT Client, be it Subscriber or Publisher (or both in one device) is any device from small Microcontroller up to a fully-fledged server, that has an MQTT library running and is connected to an MQTT Broker over any kind of network.

Topic – Messages make their way from a publisher, through a broker, to one or more subscribers using topics. Topics are hierarchical UTF-8 strings. Clients publish, subscribe, or do both to a topic. In other words, topics are the way you register interest for incoming messages or how you specify where you want to publish the message.

Publish – Clients that send information to the broker to distribute to interested clients based on the topic name.

Subscribe – Clients tell the broker which topic(s) they’re interested in. When a client subscribes to a topic, any message published to the broker is distributed to the subscribers of that topic. Clients can also unsubscribe to stop receiving messages from the broker about that topic.

QoS – Quality of Service. Each connection can specify a quality of service to the broker with an integer value ranging from 0-2. The QoS does not affect the handling of the TCP data transmissions, only between the MQTT clients.

1. specifies at most once, or once and only once without requiring an acknowledgment of delivery. This is often referred to as fire and forget.

2. specifies at least once. The message is sent multiple times until an acknowledgment is received, known otherwise as acknowledged delivery.

3. specifies exactly once. The sender and receiver clients use a two-level handshake to ensure only one copy of the message is received, known as assured delivery.

How to Use MQTT in Home Automation?

In today’s world, automation has become important and is being used in many applications in our daily life. A Home Automation System (HAS) is a system where in home appliances or environment is controlled without much human involvement. It saves power, time and efforts and is more efficient than the conventional systems. Home environmental monitoring is a major Internet of Things (IoT) application, which involves monitoring the inside and outside environment of the home. By using IoT technology, user can create advanced Home Automations Systems that can improve the quality of the life.

Let’s take one such example.

Example:

Let’s say our Home Automation System consists of an electric light bulb that can be controlled with the help of a mobile device. User will use mobile application to toggle light switch and this state will be sent to the mqtt broker. On the other side, electric light bulb with help of microcontroller receives the state sent by user. For this to happen, the mobile device will first define the topic it wants to publish on, then only it will publish the message. Meanwhile, the microcontroller attached to the light bulb subscribes to the same topic. Then once it receives the message that the device has published, it toggles light based on the state. It might also want to publish to another topic so that other clients can monitor the state of that light. Again, the broker role here is to take the message and deliver it to subscribed clients.

Topics are the way you register interest for incoming messages or how you specify where you want to publish the message. Topics are represented with strings separated by a forward slash. Each forward slash indicates a topic level. And also remember topics are case-sensitive. If you want to control multiple light across multiple rooms, you will need to come up with unique topic for these lights. Let’s suppose If we want to toggle bedroom light, the topic will be home/bedroom/lamp.

Now that we have 2 clients the first mobile application will publish to the topic “home/bedroom/lamp” with a message of “on” or “off” every time we push a button from app. In our demo we are using “MyMqtt” app from google play store. The second client will subscribe to “home/bedroom/lamp” and respond to the message by turning a light bulb on or off. And later it will publish with a message of “on” or “off” to another topic like “bedroom/lamp/state” so that other clients can monitor the state of that light.

Cloud for MQTT brokers?

MQTT on-premise broker is a rather time-consuming and demanding solution for any project. If we are talking about the quick launch of the solution for the Internet of things, then launching your own data center with a server for the MQTT broker will require resources for the initial launch and installation. Plus, expanding and scaling the on-premises broker creates a lot of problems when migrating to new servers.

Now let’s compare this solution with a cloud service, where for a minimal cost you can quickly connect your project to high-quality service and start using the MQTT protocol. With a cloud service, you also get support for your project and an already configured security system on the server and the ability to increase your capacities almost without limit. Placing the MQTT broker in the cloud can be a successful strategy both for small projects and for corporate-level projects.

Cloud-based MQTT brokers are many, like:

• Amazon
• Cloud MQTT
• Google Cloud IoT Core
• Heroku
• IBM
• Microsoft Azure IoT

Conclusion

MQTT is a communication protocol based on a publish and subscribe system. It is simple to use and it is great for Internet of Things and Home Automation projects. On the other hand, choosing a right cloud provider to service MQTT also gives you a lot of options now and you can use the message broker in your existing cloud, or choose the most suitable for your task.

How to increase the speed of software development

 

Software development is a complex process. And it’s constantly reimagined or repurposed with new features. Unlike the production industry or manufacturing industry, increasing the number of people/resources won’t increase the speed of software development proportionately. The reason being, no other engineering discipline uses Intellectual capital as much as software development. Software development is perhaps the most knowledge-intensive engineering branch. So how does one increase or optimize the speed of an engineering discipline which is more abstract than concrete?

Software development as an activity comprises people, processes, and technology. To increase the speed of development, the math is simple. Assuming everything else is normal, reduce the variables which drag the project down or reduce the speed and increase the variables which speed up the process.

What are these variables which can increase/decrease the pace of development?

Project Management Activities

Clear requirements

The clearer your requirements, the lesser the unknowns. And hence certainty in what needs to be done. Precise requirements are the first step in faster development. It is difficult to freeze requirements because change is inevitable. Therefore, what needs to be done might still be challenging to achieve and, hence, time-consuming. But it’s a known challenge. Hence with precise, documented requirements, there is no avoidable delay in development.

Availability of resources

With precise requirements or defined goals, the next step is to ensure the availability of resources. Resources can be material, people, tools & frameworks, etc. As with requirements, it may not be possible to have the right amount of resources. Or even know what are the right resources at the start of the project. But what is important to realize is that the right resources can make or break the project. Experienced people, the right tools, the proper process can accelerate the execution of a project. Being short-staffed might make economic sense, but it’s a guaranteed way to delay your project.

Project Plan – Backup/Schedule/Risk

A well-defined project plan goes a long way in executing a development project faster. A project faces risks of many types at different stages. Schedules can go awry for a variety of reasons. Data loss because of catastrophic events is a possibility. A well-planned project mitigates all of these risks and has a plan B for all scenarios. By taking out the unknowns in a project, development can be done uninterrupted. With well-defined, realistic schedules, slippage and the delay associated with that are overcome.

Well defined communication points

Modern development projects are cross-functional. There are many departments involved. Not all the departments would be technically savvy, mainly when we are dealing with enterprise projects. Software development has always suffered this problem of business-engineering communication during development. Hence the need to have a clear, single point or channel of contact. Speed of execution gets affected when people across a team are left searching for answers from another department or unit. This might be due to awareness or simply lack of knowledge about who to reach out to. If there is a single source of information or a single point of contact, development speed is greatly improved. This is especially true when the project involves cross-functional teams.

Evaluation of requirements; Feasible-Doable

We discussed precise requirements earlier. Parallel to that is feasible, doable requirements. Far too often, project initiation happens and with clear requirements as well. But some of the requirements won’t be feasible or doable in the current context. Maybe the technology is not yet there, and perhaps compliance is an issue. Maybe the relevant standards do not permit it. Once a project starts, and the discovery of such a non-feasible-doable requirement is made, teams usually try to “band-aid” a solution that is relative to the original feature leading to further delays. Hence it is essential to choose only those features which are possible in the current context. This reduces technical debts.

Engineering

Agile Development Methodology (Tools & Automated Testing)

The software engineering process in the early days was pretty simple. Hence a linear flow of development worked fine. The requirements were given ad-hoc. It was developed as a whole. After testing, it was deployed or delivered. But as technology and the digital world evolved, complexities increased as well. The linear flow or waterfall model could not scale or adapt to these complex requirements. Hence the Agile development methodology became popular. With agile development methods, tools, and automation, development becomes faster. Products are built iteratively. Agile development helps in faster development because of this. Changes, which are a leading cause of delay, are reduced to a minimum with iterative development. The stakeholders are given a periodic review, and hence the final goal is always evident.

DevOps CI/CD

DevOps and CI/CD are a must for fast development. DevOps and CI/CD, which comprises automated development, deployment, and testing, reduce the bottleneck in communication between various stages of development. For example, the development team need not generate or deploy separate builds for quality analysis or other project stakeholders. Thanks to well-scripted and defined pipelines, deployment is faster, and hence feedback is more instantaneous. With automated testing, every commit to the code is tested and verified. With tracking and monitoring also automated, development speed is increased dramatically.

Right Tech Stack

Over the last couple of decades, technology has evolved rapidly. Many tech stacks have become obsolete. Many have become suited for specific applications, and some have become popular with the development community. The right tech stack can make a difference in the development process through greater speed, third-party support, developer community support, vendor support, etc.

Human Centric

Focused time for work and dedicated offline time

Ultimately all software projects or software engineering is done by people. At least that’s the state currently! Skills, intellect, and knowledge vary from person to person. Similarly, emotional attributes like curiosity, temperament, patience also differ from one person to another. People clearly cannot work 24 hours a day to deliver some output. Getting the best out of every person in a beneficial manner to the person and the project is an essential skill for a manager. Motivational programs, skill upgrades, learning opportunities, dedicated downtime, work-life balance, meaningful work go a long way in encouraging an employee to do his best. Ultimately leading to faster output

Finally

Software development projects are unique, diverse, have different scales and complexity. Hence it’s safe to say that what works for one project won’t work for another. The trick to increase the speed of development or optimize the process is by having well-defined goals, eliminating risks, having the right amount plus relevant resources, and planning in the best possible way. Any activity in a particular project which helps these should be encouraged. It is essential to realize that the velocity of the execution can be improved at any stage.

FIDO / Fast Identity Online

 

Take a moment to consider the number of online accounts that you have. It does not matter whether they are social media accounts, news sites, blogs or enterprise accounts. The answer would be quite a lot. And that’s fairly common for anybody. Also it’s pretty safe to say that pretty much all these accounts are password protected. So any user at any given time is dealing with a lot of passwords and the complications associated with it. Such as while creating; specific character combinations, meeting minimum length restrictions, specific character properties like case sensitivity, maximum length restrictions, special characters, complexity, periodic changes(90 days etc) and many more.

Problems

Passwords are complex in maintaining and creating. But they are the best line of defence when it comes to secure data access. Since it’s easy to set up, it breeds a sense of complacency when it comes to security. Set a password once and we are done, right? But the truth is passwords need to be maintained consistently. With good and strong characteristics. Also passwords are susceptible to a wide variety of attacks. Brute Force, Phishing, Credential Stuffing etc. Survey after survey shows depressing statistics when it comes to password usage in the context of security. Consider this

https://services.google.com/fh/files/blogs/google_security_infographic.pdf

According to an online survey conducted by Google

52% of people reuse the same password for many (but not all) accounts

Only a minor 13% Use a different password for all accounts

A whooping 35% reuse the same password for all their accounts

https://digitalguardian.com/blog/uncovering-password-habits-are-users-password-security-habits-improving-infographic#:~:text=In%20fact%2C%20a%20Dashlane%20analysis,to%20a%20single%20email%20address.

A detailed survey conducted by digital guardian showed that

Only about 31.3% of respondents changed their passwords one to two times

Only about one-fifth (22.4%) changed their passwords more than five times per year

Almost half of the respondents, 49.3%, said they reuse passwords

https://dataprot.net/statistics/password-statistics/

In a survey conducted by Data prot,

53% of people rely on their memory to manage passwords.

51% of people use the same passwords for both work and personal accounts.

57% of people who have already been scammed in phishing attacks still haven’t changed their passwords.

Passwords are mostly in a “data at rest” state. Data or password which is stored or in the state of rest is not as vulnerable as data in transit over the network. But data in the state of rest is usually more critical.

Passwords or passcodes are as old as computing itself. MITs Compatible Time-Sharing System built way back in 1961, featured the first passcode. Computing has evolved from clunky, giant devices to nimble mobile devices. Password unfortunately has remained the same. Also, in the modern digital age with plenty of devices the problem of maintaining and managing many accounts and passwords. So why hasn’t the world moved on from passwords?

Two Factor authentication

To a large extent, 2FA or two factor authentication makes an account safer. By having another level of security to a user’s account risks are reduced. 2FA can be enabled in conjunction with passwords with

Something that a user knows — Password, PIN, Swipe gesture etc

Something that a user has — Mobile device, compatible security key etc

Something that a user is — Biometrics

2FA makes accounts secure. But 2FA is a bad experience from a user perspective. The time taken to authenticate is more with 2FA. and in certain cases, like loss, corruption of compatible devices, even more problematic. Ultimately 2FA is an “Extra” level of security on top of passwords. So the password problem is always there. It hasn’t gone away even with 2FA

FIDO Alliance

The problem is quite simply, how to get rid of passwords and in its place have a system which is more secure. How to change a timeless way of login i.e using passwords. That’s exactly what FIDO or Fast Identity Online seeks to achieve. FIDO Authentication aims to replace password-only logins.

Genesis

FIDO Alliance was founded by Industry leaders. PayPal, Lenovo, Nok Nok Labs, Validity Sensors, Infineon, and Agnitio etc. Other Tech Giants like Google, Paypal and Samsung also lent their support to the FIDO alliance later on. Thereby increasing its credibility. At its heart, FIDO uses the robust, proven technique of PKI or public key infrastructure. A public/private key is generated at the time of registration. The public key resides in the server and the private key never leaves the user. The data which is encrypted with a public key can only be decrypted with a private key

Passwordless and Multifactor : FIDO version one

The first FIDO standards, launched back in 2014 had two major components. The Universal Authentication Framework (UAF) and the Universal 2nd Factor (U2F).

UAF is the backbone for authentication by means of multi factor security. UAF enables the app or service to present different mechanisms for logging in. Such as fingerprint scan, face scan, voice recognition, PIN etc while registering. Instead of the usual id/password flow, users follow the authentication they chose while registering.

U2F as the name suggests deals with the standards associated with USB based physical security keys such as NFC and Bluetooth. These devices serve as the secondary factor for authentication or form the basis of 2 Factor authentication. 2AF is a familiar authentication technique. Similar to that FIDO too has a secondary factor authentication standard i.e U2F

So in other words UAF + U2F offers higher levels of authentication and security as in passwords, but without the hassles of passwords

Version FIDO 2

FIDO 2 was launched in 2018 and it was the updated and upgraded version of version one. FIDO 2 introduced Web Authentication (WebAuthn) in conjunction with the World Wide Web Consortium (W3C). FIDO 2 extends the power of UAF and U2F to third party apps and services. FIDO-based authentication is made available on supported browsers and platforms. By virtue of Web Authentication component, standards and web application programming interfaces (APIs). At the time of writing this, WebAuth is supported in pretty much all the major browsers like Chrome, Firefox, Edge and Safari

Conclusion

FIDO alliance or specifically WebAuthn is a win-win for all as there are tangible benefits to replacing passwords. WebAuth offers a good experience plus the security offered by having a password less, PKI based infrastructure. Service providers also don’t have to worry about the complexity of maintaining, developing and updating complex secure authentication solutions.

Source: FIDO / Fast Identity Online