DEV Community: Karan Gandhi

Happy new year !

Karan Gandhi — Wed, 01 Jan 2025 13:56:05 +0000

MASVS & MSTG: A Quick Guide To Mobile App Security

Karan Gandhi — Mon, 25 Jan 2021 12:47:37 +0000

While dealing with mobile application security, we often hear of the OWASP Mobile Top Ten list - as its name implies, it’s a list of the top ten security risks associated with mobile applications.

However, seasoned developers and testers might feel the list is inadequate. Let us look at some caveats of OWASP Top Ten.

It's not a guide; it's a crowdsourced list of vulnerability categories;
The list was last updated in 2016 and there are no immediate plans to update it.

As developers, we would like a comprehensive set of standards that can be used to design applications. Likewise, security testers would like to test an application against a list of items using predefined methodologies.

To meet these needs, we can look at the OWASP Mobile Application Security Verification Standard (MASVS) and OWASP Mobile Security Testing Guide (MSTG), which provide enough info to facilitate secure application development and adequate testing.

OWASP MASVS

MASVS is an application standard for mobile app security. It helps developers to develop secure mobile applications. Testers can use the standard to highlight relevant security risks.

This standard provides a list of requirements an application should adhere to, defining two security levels. MASVS-L1 contains generic security requirements that are recommended for all apps; MASVS-L2 contains requirements for defense-in-depth. Then, we also have MASVS-R, a set of reverse engineering requirements that is useful for providing client-side defenses. These levels will be explored in more detail in the next section.

Currently, the verification requirements are segregated into 8 types. They are:

V1 - Architecture Design and Threat Modelling Requirements
V2 - Data Storage and Privacy Requirements
V3 - Cryptography Requirements
V4 - Authentication and Session Management Requirements
V5 - Network Communication Requirements
V6 - Platform Interaction Requirements
V7 - Code Quality and Build Setting Requirements
V8 - Resilience Requirements

V1-V7 provides requirements for MASVS-L1 and MASVS-L2. MASVS-R is a separate requirement. Enforcing a control requirement is dependent on the business use-case.

OWASP MSTG

MSTG is a comprehensive manual that can be used to test if an application fulfills the requirements outlined in MASVS. Likewise, Developers can use the manual to get an idea of how the application can be hacked.

MASVS has broken down its requirements in the form of MSTG-IDs. Each MSTG-ID in MASVS maps to a relevant test case in MSTG. The Architecture section includes references to other materials like secure SDLC and the OWASP Cheatsheet series. MSTG has a list of tools and methods specifically to analyze a mobile application.

Understanding the MASVS verification Levels

MASVS-L1

MASVS-L1 is termed as standard security. It adheres to mobile security best practices and fulfills basic requirements in terms of code quality, handling sensitive data, and interaction with the mobile OS. As of MASVS 1.2, it's recommended for L1 Apps to fulfill the following requirements

MSTG-ARCH 1-4 & 12
- All app components are identified and needed.
- Security controls are enforced on both server and client.
- High-Level Architecture has been devised and its security is accounted for.
- All sensitive data for the business case has been identified.
- The app complies with relevant privacy laws and regulations.
MSTG-STORAGE 1-7
- System Credential Facilities are used to save sensitive data.
- Sensitive Data is not stored outside the credential facilities, not logged, not shared with third-parties unless part of the architecture, not exposed to IPC mechanisms, and not exposed through a user interface.
- The keyboard cache is disabled while handling sensitive data.
MSTG-CRYPTO 1-6
- The app doesn't rely solely on symmetric cryptography with hardcoded keys.
- The app uses proven implementations of cryptography.
- The app doesn't use deprecated standards.
- The app doesn't use the same key for multiple purposes.
- The app uses high entropy RNG.
MSTG AUTH 1-7 & 12
- Authentication and Authorization are performed on the remote endpoint. A password policy is present at the remote endpoint.
- Stateful sessions should associate the client with randomly generated session identifiers.
- Stateless Auth tokens should be signed using a secure algorithm.
- Sessions are invalidated after tokens expire.
- On Logout, the session should be terminated remotely.
- Remote Endpoints are configured to disallow multiple login attempts.
MSTG-NETWORK 1-3
- Use TLS with recommended best practices.
- Verify x.509 of the remote endpoint. Trust verified CAs only.
MSTG-PLATFORM- 1-8
- Manage permissions properly.
- Sanitize external inputs, viz data from external URLs, and intents.
- Avoid exporting sensitive functionality.
- Disable JS in WebView.
- Restrict protocols in WebView.
- Restrict Native code access to JS in the app package.
MSTG-CODE 1-9
- The app is signed with a valid certificate with a private key.
- The published build is in release mode.
- Debugging symbols have been removed.
- Third-party libraries and components have been identified and tested against vulnerabilities.
- Access is denied by default.
- Security features offered by toolchain are used.

Typically, enforcing L1 requirements won’t have a significant impact on the SDLC. Depending on the business and use-cases, it's recommended to employ L1 requirements in all apps.

MASVS-L2

MASVS-L2 is termed as a defense-in-depth. To fulfill L2 requirements, a threat model must exist and security should be a part of the app life cycle. For example:

A separate secure life cycle has to be defined for sensitive data.
2FA is enforced mandatorily. Certificate Pinning is enforced.
Custom keyboards are blocked from accessing sensitive data.

The following requirements are necessary for L2 Apps. We will be highlighting the ones above the L1 requirements:

MSTG-ARCH 1-12
- The app components should be defined in terms of business and security functions.
- A threat model for the mobile application should be defined and possible countermeasures should be recorded.
- A separate policy for cryptography should be established.
- A mechanism for enforcing updates should be implemented.
- Security should be addressed across all components.
- A responsible disclosure policy should be in place.
MSTG-STORAGE 1-15
- Sensitive data should not be present in the provided backups.
- The app removes sensitive data when it moves to the background.
- The app doesn't hold sensitive data in memory for long. Memory should be cleared explicitly after usage.
- The app should enforce minimum device security policy like forcing the user to set a device passcode.
- The app educates the user about the sensitive data the app uses and the security best practices it follows.
- Sensitive data should not be present on the phone. It should be stored at a remote endpoint and retrieved from the endpoint.
- In case sensitive data needs to be stored on the mobile device, it should be encrypted with a key derived from hardware-backed storage that requires authentication.
- The app's local storage should be wiped out after multiple unsuccessful attempts.
MSTG-CRYPTO 1-6
- Same as L1.
MSTG AUTH 1-12
- Biometric Authentication should not be event-bound.
- 2FA is consistently enforced.
- Sensitive transactions require step-up authentication.
- The app informs the user about all sensitive activities in their accounts. As in, users should be able to see all logged-in sessions, locations from where a device logged in, and device info of logged-in users.
- Controls for blocking devices should be made available to users.
MSTG-NETWORK 1-6
- The app uses its own certificate or pins an endpoint certificate. The app doesn't trust an endpoint with a different certificate.
- The app doesn't rely on a single insecure communication (email, SMS) for operations like enrollment or account recovery.
- The app depends on updated, secure libraries.
MSTG-PLATFORM- 1-11
- The app should protect itself against screen overlay attacks.
- WebView's cache, storage, and resources should be destroyed after a WebView is destroyed.
- The app prevents the usage of third-party keyboards when a user is entering sensitive data
MSTG-CODE 1-9
- Same as L1.

As you can see, L2 has a considerably high development overhead. Such requirements are usually applicable to financial and healthcare apps. These domains require certain compliances (HIPAA, PSD2, and PCI-DSS).

While MASVS-R is a separate level for client-side attacks, it's safe to assume that an L2-compliant app should employ the R level as well. One of the requirements of L2 is to threat model an application. And client-side security should be a part of that threat model.

MASVS-R

The MASVS - R is a specially defined level for defense against client-side attacks. That includes attacks like tampering, modifying, and reverse engineering. As such, an application should:

Detect rooted/jailbroken devices and emulators.
Prevent debugging.
Detect application and asset tampering.
Verify client integrity.
Identify popular dynamic analysis tools like Frida and impede them.
Have multiple strategies to achieve the points above.
Employ device fingerprinting.
Impede static analysis by encryption and obfuscation.
Have solid hardened communication strategies.

MASVS-R can be used with L1 or L2 controls. As mentioned earlier, we can safely assume an L2-compliant app already might employ MASVS-R controls. There are some unique cases when you don't need sensitive data management but require client-side security. Let's see some of the use cases:

Games: Gaming is a booming industry that is traditionally targeted by hackers. You can see unique and aggressive client-side defenses in games like Pokemon Go and Fate Grand Order.
Mobile apps that require client-side IP protection. Like apps interfacing with hardware like IoT devices, biometric devices, wearables, etc.
Business use-cases that require offline functionality. If you read the list, a lot of the security controls require an internet connection to enforce them. For offline apps, client-side security has to be thought out extensively.

Framing MASVS to Cross-Platform Frameworks

Cross-platform frameworks allow developing applications for both Android and iOS using a shared codebase. Some of the most popular cross-platform frameworks include React Native, Ionic, Cordova, Flutter, Xamarin, NativeScript, and Unity (for games).

MSTG covers cross-platform frameworks rather briefly. However, it’s recommended to test them as Native Apps. This makes sense from the standpoint of a tester but it's problematic from a developer perspective. For brevity, we will be considering JavaScript frameworks.

One of the biggest selling points of cross-platform frameworks is that we can leverage existing web technologies to develop an application on multiple platforms. A developer doesn't need to have a very extensive knowledge of native code to create mobile apps.

While there are good practices outlined in the documentation, to develop a secure solution, a developer needs a deep understanding of web technologies and native platforms.

We have outlined some good practices in our guides to Secure Ionic and Securing React Native. If you’re working with either of these frameworks, make sure to follow these guides.

Even so, some of the security controls outlined in MASVS have to be enforced as native code. This adds quite a bit of overhead while developing the applications. So, it's recommended to develop a security model based on MASVS with WebView risks and utility overhead and then proceed to development.

Addressing MASVS-R With Jscrambler

As stated before, MASVS-R outlines certain security controls that must be implemented in mobile applications that are especially critical. Examples include mobile banking apps, fintech services, healthcare apps, apps with in-app purchases, and mostly every client-facing app that handles sensitive user data or contains proprietary logic.

Jscrambler directly addresses the client-side security requirements of MASVS-R. Specifically, it:

Allows detecting rooted/jailbroken devices and triggering countermeasures to prevent the app (or some app features) from running on these risky devices;
Actively prevents debugging and tampering, using a Self-Defending feature that scatters integrity checks throughout the code and breaks the app when a debugger is opened or when the source code has been tampered with;
Allows preventing tampering attempts at runtime without disturbing the user experience, using a Self-Healing feature that uses checksum techniques to verify the app’s integrity and guarantees that only the correct code is executed;
Ensures the integrity of the client environment, providing a series of Code Locks that can be used to only allow app execution in allowed domains, browsers, OSes, and timeframes;
Includes a Code Hardening feature that prevents the usage of reverse engineering tools, which is constantly updated to cover new versions of these tools;
Provides state-of-the-art obfuscation, with a combination of 20+ transformations like control flow flattening, string concealing, and identifiers renaming, which provide maximum potency and resilience;
Has a polymorphic behavior, ensuring that each new deployment of protected code is completely different, but still works just like the original code;
Has specific features to protect sensitive data, namely Memory Protection, which ciphers sensitive data when it’s not being used by the app.

You can directly test these transformations in your own code with a Jscrambler free trial. Plus, you can use Jscrambler to protect JavaScript, C/C++, Objective-C/C++, Java, Swift, and Kotlin.

In case you’re working with a hybrid framework, check the integration tutorials for React Native, Ionic, and NativeScript.

Final Thoughts

This was a brief overview of what OWASP MASVS and MSTG can offer to mobile app developers and testers.

We recommend that you check the Mobile App Security Checklist, which maps MASVS and MSTG as an Excel sheet.

In case you have specific security concerns, feel free to request a meeting with one of Jscrambler's Application Security Experts.

Setting Up A Parse Server As An Alternative Backend

Karan Gandhi — Thu, 24 Sep 2020 16:23:09 +0000

Sometimes, we encounter situations when it's not feasible to develop a full-fledged backend from the ground up. In such situations, we rely on services like Firebase to speed up development.

Parse is an open-source mobile Backend As a Service (mBAAS) platform. Previously, Parse was a backend platform similar to Firebase. In 2016, Facebook open-sourced the platform code and sunsetted their hosting services. In this article, we will be taking a brief look at Parse and seeing how it allows us to deploy applications quickly.

Overview

Parse is a full-fledged backend with support for REST API and GraphQL which can be self-hosted. It is open source and is being actively maintained by communities.

It has SDKs available for iOS, Android, JavaScript, and other platforms, as well as support for Push Notifications including campaigns, out-of-the-box user management, support for OAuth providers (including Facebook, Twitter, Google, GitHub, and LDAP), support for Docker, deployment options to various platforms (including AWS and Heroku), as well as support for different storage adapters.

Parse is extensible with webhooks, jobs, and config, and has quite a few community plugins. You can use it together with Express.js.

Setting up Parse

Parse requires Node 8+, MongoDB or PostgreSQL to set up. On UNIX like systems, it's advisable to use NVM for Node.js installations. The steps are as follows:

npm install -g parse-server mongodb-runner
mongodb-runner start
parse-server --appId APPLICATION_ID --masterKey MASTER_KEY --databaseURI mongodb://localhost/test

We can also use Docker to start Parse:

git clone https://github.com/parse-community/parse-server
cd parse-server
docker build --tag parse-server .
docker run --name my-mongo -d mongo
docker run --name my-parse-server -v cloud-code-vol:/parse-server/cloud -v config-vol:/parse-server/config -p 1337:1337 --link my-mongo:mongo -d parse-server --appId APPLICATION_ID --masterKey MASTER_KEY --databaseURI mongodb://mongo/test

APPLICATION_ID is the name of the application and can be user-generated. MASTER_KEY is a key that can override all permissions. Other parameters are listed below:

databaseURI: Connection string URI for your MongoDB.
cloud: Path to your app’s Cloud Code.
appId: A unique identifier for your app.
fileKey: A key that specifies a prefix used for file storage. For migrated apps, this is necessary to provide access to files already hosted on Parse.
masterKey: A key that overrides all permissions. Keep this secret.
clientKey: The client key for your app. (optional)
restAPIKey: The REST API key for your app. (optional)
javascriptKey: The JavaScript key for your app. (optional)
dotNetKey: The .NET key for your app. (optional)
push: An object containing push configuration. See Push
filesAdapter: An object that implements the FilesAdapter interface. For example, the S3 files adapter
auth: Configure support for 3rd party authentication.
maxUploadSize: Maximum file upload size.

And that's it! We have a Parse backend running successfully in minutes.

For convenience, we can install the Parse dashboard - a visual admin panel for the Parse server. To run parse-dashboard, we need to install it globally.

npm -i g parse-dashboard

parse-dashboard --dev --appId APPLICATION_ID --masterKey MASTER_KEY --serverURL "http://localhost:1337/parse/" --appName SimpleFileStorage

We can access the dashboard on localhost:4040. For this tutorial, we will be using the REST API.

Backend Features

Storing Data

As mentioned earlier, Parse allows us to store data easily. The base unit of all data is the objects API. For example, if we define a vehicle class with the keys manufacturer and model, we can perform CRUD REST operations using a simple curl request.

curl -X POST \
  -H "X-Parse-Application-Id: simple_file_storage" \
  -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"manufacturer": "Lamborghini", "model":  "Gallardo"}' \
  http://localhost:1337/parse/classes/vehicle

We get objectId and created _date in response. Further operations on the object can be performed using objectid.

curl -X GET \
  -H "X-Parse-Application-Id: simple_file_storage" \
  -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \
  -H "Content-Type: application/json" \
  http://localhost:1337/parse/classes/vehicle/objectId

curl -X PUT \
  -H "X-Parse-Application-Id: simple_file_storage" \
  -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"manufacturer": "Lamborghini", "model":  "Murcielago"}' \
  http://localhost:1337/parse/classes/vehicle/objectId

curl -X DELETE \
  -H "X-Parse-Application-Id: simple_file_storage" \
  -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \
  http://localhost:1337/parse/classes/objectId

In case a class is not predefined, it will be created by the server. We can use Parse Dashboard to create custom classes. As far as data types are concerned, Parse has support for string, number, boolean, arrays, JSON Objects, Date-Time, File, and Null. Additionally Parse has two custom datatypes, Pointer to Another Parse Object and Relation to another Parse Class. Data types in Parse are locked in. Once a datatype is set, it will return an error if you try to save anything else.

Files

As with data, file upload is straightforward. The files URL is the /files route and the file name.
However, we have to manually handle the content type.

curl -X POST \
  -H "X-Parse-Application-Id: simple_file_storage" \
  -H "X-Parse-REST-API-Key: REST_API_KEY" \
  -H "Content-Type: image/jpeg" \
  --data-binary '@myPicture.jpg' \
  http://localhost:1337/parse/files/pic.jpg

As a response, we receive the file location and name of the saved file. A unique identifier is appended to the file name.

{
  "url": "http://localhost:1337/parse/files/simple_file_storage/d840137c22d89d126075ec7fa875c54f_pic.jpg",
  "name": "d840137c22d89d126075ec7fa875c54f_pic.jpg"
}

Authentication & Security

Parse provides out-of-the-box user authentication. This includes token-based authentication, user actions like sign up, login, email verification, reset passwords, token-based session management, and role-based access management. The routes for users are /parse/users, the routes for roles are /parse/roles and the routes for sessions are /parse/sessions.

To secure data, Parse provides Class Level Permissions (CLP) and Access Control Lists (ACL). CLP provides fine-grained control over data access to roles. Using Class Level Permissions we can define Roles which will have the ability to:

Create new Classes;
Add Fields to Classes;
Read or Query Data from classes;

Furthermore, using ACLs we can restrict access to objects to individuals and roles. An example snippet of ACL is:

{
  classLevelPermissions:
  {
    "find": {
      "requiresAuthentication": true,
      "role:admin": true
    },
    "get": {
      "requiresAuthentication": true,
      "role:admin": true
    },
    "create": { "role:admin": true },
    "update": { "role:admin": true },
    "delete": { "role:admin": true }
  }
}

This particular object:

is inaccessible to guests;
requires authentication to view and query objects;
has a predefined role admin, can perform all operations.

The picture below, from the Parse docs, demonstrates how CLPs and ACLs interact.

Miscellaneous Features

Cloud Functions allow us to define custom functions in the Parse backend.
Hooks allow us to run custom code in other languages and extend server-side logic.
Jobs allow us to run long-running functions so we don't have to wait for a response.
Triggers allow us to write custom code before/after data is modified.
Analytics allows us to add dimensions and metrics to our application.
Push Dashboard allows us to create custom push campaigns for our mobile apps.
Geo points allow us to associate real-world latitudes and longitudes with an object.
Config allows us to save config parameters on the server.

Extending Parse with Chisel and Parse Auditor

Chisel CMS

Chisel is an API-first headless CMS built upon Parse. Setting up Chisel over Parse is quite straightforward.

npm install -g chisel-cms
chisel-cms --appId "APP_ID" --serverURL "https://YOURSERVER.com/parse"

Chisel will start at localhost:9000.

Chisel provides an admin panel where we can set up multiple sites. Additionally, it has its own Parse server. While you can run Chisel on any Parse server, Chisel's server has helpful templates like blog and knowledge base.
It's advisable to check the data structures and content publishing life cycle before diving in.

Parse Auditor

Parse auditor is a module inspired by the Envers Project. It adds automated data tracking/auditing to classes. This is useful when the app is needed to adhere to regulations like HIPAA. Parse Auditor has to be used in the cloud code. Let's take a look at how Parse Auditor works

Let's assume we have ImportantData and SortOfImportanData classes in Parse. We would like to track data changes in both classes and know if ImportantData was accessed.

To set up Parse Auditor, we need to edit the cloud code. First, shut down any running instance of the Parse server and dashboard. Then, navigate to the cloud folder of your Parse installation. If there is no cloud folder, then create a main.js file inside a cloud folder. We need the absolute path of the cloud folder. It should look like this:

C:\somefolder\Parse\cloud\main.js

Inside the cloud folder, add parse-auditor to the dependencies in package.json

{
  "dependencies": {
    "parse-auditor": "*"
  }
}

Now, edit the main.js file as follows:

const ParseAuditor = require('parse-auditor');
ParseAuditor(['ImportantData', 'SortOfImportantData'],['ImportantData'])

The first param takes an array of Class names and tracks them in a separate Class_AUD class. The second param takes an array of Class names and tracks views in the Class_AUD class.

By default, changes to ImportantData and SortOfImportantData will be tracked in ImportantData_AUD and SortOfImportantData_AUD. Views of ImportantData will be tracked in SortOfImportantData_AUD. Four extra fields are attached to audit logs:

meta_actor: The user involved in this event. Either the user who made the update or the one who viewed this record.
meta_action: Will be "SAVE", "DELETE", or "FIND" depending on the action the user took.
meta_class: The name of the class, convenient when combining complex audit histories across many classes.
meta_subject: The row being edited/viewed.

The plugin can be configured further using these fields:

{
    classPrefix: '', //Class Prefix
    classPostfix: '_AUD', //Class Postfix
    fieldPrefix: 'meta_', //field Postfix
    fieldPostfix: '', // field Postfix
    parseSDK: Parse, //SDK Object
    useMasterKey: false, //MasterKey
    clp: {} //Class Level Permissions 
}

Consider the example below:

const ParseAuditor = require('parse-auditor');
const customConfig = { classPostfix: '_LOGS' };
ParseAuditor(['ImportantData', 'SortOfImportantData'], ['ImportantData'], customConfig);

This will log the data to a class sufficed with _LOGS. To start the server, we will have to pass main.js to the cloud param as below.

parse-server --appId APPLICATION_ID --masterKey MASTER_KEY --databaseURI mongodb://localhost/test --cloud "C:\somefolder\Parse\cloud\main.js"

With this, we have successfully set up Parse with custom logging.

Final Thoughts

In this article, we have seen how we quickly generate an app backend using Parse.

We have covered how Parse handles permissions and how they can be used to secure data. Also, we have covered two useful tools that can be used with Parse: Chisel CMS and Parse Auditor.

SSL Pinning

Karan Gandhi — Fri, 29 May 2020 13:33:39 +0000

Introduction to TLS/SSL

Transport Layer Security (TLS) is a cryptographic protocol that is used to secure communications over the network. TLS was preceded by Secure Sockets Layer (SSL). Websites use TLS to secure communications between servers and web browsers.
The common flow in a TLS connection is as follows:

A client initiates a connection to the server;
The server responds with a certificate containing its public key;
The client verifies the certificate with preinstalled Certified Authority (CA) certificates on the computer;
On success, the client creates a new secret key which is encrypted using Server's Public key;
The server decrypts the new key with its private key;
All further communications are carried using this secret key.

CAs play a key role in securing the connections. They issue digital certificates that certify ownership of public keys, usually X.509.

Digital Certificates

Asymmetric Cryptography is a system that uses a pair of public and private keys to secure a system. A user can distribute his public key which in turn can be used by others to sign a message. A user can verify the authenticity of the message using his private key. A digital certificate is an electronic document that certifies ownership of a public key. If the signature is valid and the issuer is trusted, then that key can be used to communicate securely. In our context, the Certificate Authority is the issuer. Let's take a look at the different types of certificates.

Root Certificates: this is a certificate that identifies a Certificate Authority. These certificates are self-signed. Usually CAs issue certificates in a tree format. Root certificates are used to sign an intermediate certificate and establish a root chain. Intermediate certificates inherit the trustworthiness of the root chain. Major software companies like Microsoft, Apple, Mozilla, Google, Oracle have their Root Programs to store root certificates. Root stores are certificates installed in operating systems.
Intermediate certificates: CAs don't issue server certificates directly from a root certificate. They usually sign an intermediate certificate with its private key. As mentioned earlier, the certificate inherits the trustworthiness of a parent. This process can be repeated multiple times to form a certificate chain. The end-user certificate or Leaf certificate is usually signed by an intermediate certificate. There is a huge risk involved in signing with root - it's easier to revoke an intermediate certificate.
Leaf Certificate: this refers to certificates that cannot be used to sign other certificates. SSL/TLS server certificates are usually leaf certificates.
Self Signed Certificates: lastly, if a certificate is not signed by a CA, then it's a self-signed certificate. Self-signed certificates can be created using tools like Apples' Keychain, OpenSSL, and Java's Keytool. Self-signed certificates are useful for testing. However, they are susceptible to Man-in-the-Middle (MiTM) attacks. It's advised to avoid self-signed certificates in production.

Certificate Chain

As mentioned earlier, a CA doesn't sign a leaf certificate with its root. A complex chain of intermediate certificates is established, with each intermediate certificate inheriting the trustworthiness of its parent.

Usually, while connecting to a secure server, the client downloads the server certificate. Unless the certificate is self-signed, the certificate used to sign a leaf certificate is downloaded. If the intermediate certificate is not root, then the process is repeated. If the final certificate is a root certificate and it is verified, the entire chain of certificates is trusted and hence the connection is trusted. If the root is not verified or if the last certificate is not a root certificate, then the chain is untrusted.

Pinning

HTTPS traffic can potentially be intercepted by installing malicious CA certificates in a device. Tools like OWASP ZAP, Burp, and mitmproxy auto-generate CAs to intercept traffic from the browser. Usually, malicious actors use social engineering to install rogue CAs on devices. Unlike home computers, it's relatively easier to install certificates on mobiles. Commonly, WiFi hotspots can be used to install such rogue CAs.

We can use certificate pinning to add an extra layer of defense. Certificate pinning is a technique with which we can directly associate the host/app to a certificate or its public key instead of accepting any certificate signed by a trusted CA. By revoking trust from CA, we are reducing the attack surface. As such, even if an attacker manages to install a rogue CA on a device, he won't be able to intercept traffic easily. The best practice is to pin the server's leaf certificate. However, a developer can choose to pin an intermediate certificate to increase compatibility. This will allow us to change the server's leaf certificate periodically - but it also increases the attack surface.

We can implement pinning in two ways.

First, we can directly pin the certificate by bundling the certificate in our apps. However, once the certificate expires, a transition plan will have to be implemented beforehand. Once the certificate expires, older apps will throw errors.

Second, we can pin the Public Key of the certificate. By pinning a public key, we won't have to worry about the certificate expiring as long as the public key remains the same. We can pin multiple certificates - such an arrangement is known as a pinset.

Let's take a look at commonly used plugins in React Native and Ionic.

Pinning in React Native.

In a previous article, we have mentioned plugins that can be used for certificate pinning. We will list them here again.

react-native-ssl-pinning: This plugin uses OkHttp3 on Android and AFNetworking on iOS to provide SSL pinning and cookie handling. It supports both Certificate and Public Key Pinning. We will be using fetch from the library to consume APIs. This library uses promises and supports multi-part form data. It has support for React Native 0.60 and above.
react-native-pinch: React Native Pinch is used to pin certificates. Both callbacks and promises are supported.
react-native-cert-pinner: This plugin allows us to pin the public key. Unlike the plugins above, we can use fetch and other utilities directly. The pinning occurs before native JS is run. Also, there is no requirement to define hashes in the request itself.
react-native-trustkit: this is a wrapper plugin for the iOS Trustkit library. This library is available for iOS only.

Pinning in Ionic Apps

Currently, certificate pinning is only available via cordova-plugin-advanced-http. Advanced HTTP is a versatile plugin that can be used to perform complex HTTP operations like SSL pinning, certificate-based auth, and complex file operations.

Pinning Caveats

Theoretically, pinning secures the connection between the client (app) and the server. Practically, rogue pinsets can be inserted via tampered apps. Therefore, it's advisable to use Pinning with Attestation Checks like SafetyNet.

If the pinned certificate changes regularly, the application has to be updated too. App Store updates can take multiple days and have a certain level of uncertainty involved. This may cause unintended service outages to end-users.

While this article was more focused on network security, you should protect your JavaScript source code as well. See our tutorials on protecting React, Angular, Vue, React Native, Ionic, and NativeScript.

Authentication & Authorization in Web Apps

Karan Gandhi — Thu, 02 Apr 2020 16:45:30 +0000

Most modern applications require individuals to verify their identity. Authentication is the process of verifying the identity of an individual. A user can interact with a web application using multiple actions. Access to certain actions or pages can be restricted using user levels. Authorization is the process of controlling user access via assigned roles & privileges.

In this post, we will be covering some Authentication & Authorization concepts as well as security recommendations.

Authentication

As mentioned before, authentication is the process of verifying identity. A unique identifier is associated with a user which is the username or userid. Traditionally, we use a combination of username and password to authenticate a user. The authentication logic has to be maintained locally so we will term it local authentication. Apart from local authentication, we can use OpenID, Oauth & SAML can also be used as Auth providers. Let's cover them step by step.

Local Authentication

The most common authentication technique is using a username and password.

The common flow while implementing it is:

The user registers using an identifier like username/email/mobile;
The application stores user credentials in the database;
The application sends a verification email/message to validate the registration;
Post successful registration, the user enters credentials for logging in;
On successful authentication, the user is allowed access to specific resources;
The user state is maintained via Sessions or JWT.

OpenID / OAuth

OpenID is an authentication protocol that allows us to authenticate users without using a local auth system. In such a scenario, a user has to be registered with an OpenID Provider and the same provider should be integrated with our authentication flow. To verify the details, we have to forward the authentication requests to the provider. On successful authentication, we receive a success message and/or profile details with which we can execute the necessary flow.

OAuth is an authorization mechanism that allows our application user access to a provider. On successful response, we receive a token with which we can access certain APIs on behalf of a user. OAuth is convenient in case your business use case requires some certain user-facing APIs like access to Google Drive or sending tweets on your behalf. Most OAuth 2.0 providers can be used for pseudo authentication. Having said that, it can get pretty complicated if you are using multiple OAuth providers to authenticate users on top of the local authentication system.

Multi-Factor Authentication

Users are generally recommended to have different passwords for different websites or use password managers to secure their identity. However, in reality, a major chunk of people reuse their passwords. This makes them vulnerable to credential sniffing (as this XKCD comic brilliantly explains). If an attacker has access to unsalted passwords from a dump of breached applications then he can use it to log in to our application.

To reduce the risk we can implement multi-factor authentication in our application. Multi-Factor authentication is when a user is authenticated using two or more factors as authentication methods. The factors are listed below.

Factor	Example
Something You Know	Passwords, PINs, TAN, security questions
Something You Have	USB keys, Software tokens, certificates, email, SMS, phone calls.
Something You Are	Biometrics(fingerprints/iris scans, Facial Recognition), typing speed, key pattern interval
Location	Source IP ranges and geolocation

The common second factors implemented in applications are:

Email
OTP via SMS / Phones
TOTP (Time-based OTP) apps like Google Authenticator / Authy
x.509 certificates

The location-based factor is used to implement geographical restrictions. IP addresses can be used to allow/block users from certain countries. This is common practice in streaming and banking applications. It's easier to access geographical data from a mobile phone or any GPS enabled device.

FIDO2-compliant biometric devices and USB keys can leverage WebAuthn API to handle the authentication. WebAuthn is a new browser API that makes it easier to implement a second factor for authentication.

Mobile Device User Authentication vs User Authentication

This is a somewhat newer scenario. Under most circumstances, we login to our mobile phones using our Google/iCloud accounts. As a device user, the account can store our private data, has access to multiple apps with persistent logins and is associated with multiple payment providers. There can be a case where our application user and the device user can be different.

While executing a critical transaction, we would like to associate a device owner with our application user OR we would like a device owner to authenticate the application users. In such cases, we have to add an extra layer of security. On Android, we can use biometric auth and keyguard manager. On iOS, we can use Local Authentication to verify the device user.

Authentication Libraries

Let’s take a look at common Node.JS authentication libraries.

PassportJS

PassportJS is one of the most popular auth libraries for Express. Apart from Local Authentication, Passport has support for OpenID, OAuth 1.0, SAML and OAuth 2.0.

There are around 500 providers/strategies which can be used with Passport. You can check our recent tutorial which covers Passport here.

Grant

Grant is another auth library. It has support for Express, Hapi and Koa. Like Passport, grant supports OpenID connect OAuth 1.0a & OAuth 2.0. There are currently 180 supported providers.

Firebase Authentication

Firebase Auth has limited OAuth providers (Facebook, Github, Twitter, Google, Apple, Microsoft). However, it does provide Auth for email login, anonymous login, and phone number login.

A full authentication workflow is provided by the Firebase Auth API. Also, we can link Multiple OAuth users to a single user. Coupled with other Firebase products (Push, Database, Storage, Hosting, Crashlytics, Functions), this can be a very good fit for small projects.

Authentication through OWASP's Lens

Broken Authentication is ranked #2 in OWASP Top 10 and #4 in OWASP Mobile Top 10. From OWASP itself:

Confirmation of the user’s identity, authentication, and session management is critical to protect against authentication-related attacks.

There may be authentication weaknesses if the application:

Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
Permits brute force or other automated attacks.
Permits default, weak, or well-known passwords, such as “Password1” or “admin/admin“.
Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers”, which cannot be made safe.
Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure).
Has missing or ineffective multi-factor authentication.
Exposes Session IDs in the URL (e.g., URL rewriting).
Does not rotate Session IDs after successful login.
Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) >* aren’t properly invalidated during logout or a period of inactivity.

Taken these points into account, we can strengthen our application by:

Hashing and salting the passwords - plaintext passwords are a huge security risk. Use libraries like bcrypt to implement hashes with the maximum rounds your CPU can afford (also, check this blog post for further reading on hashing algorithms);
Using password strength estimators like owasp-password-strength-test to enforce a strong password policy;
Not truncating the passwords;
Notifying users to update passwords regularly;
Reauthenticating users while performing a critical transaction like payment or account update;
Transmitting passwords over TLS (https) only;
Not leaking any information in error messages. Login failed. Password for user Karan is wrong is a bad message. Login failed: Invalid user or password is a good message.

For resetting passwords, we will take the following points into consideration:

Send an email to the user;
Create a temporary session for a password reset;
Do not display user credentials on screen;
Verify the user using security questions / TOTP codes;
Redirect the user to a form;
Change the password in the same session.

So far, we have covered some techniques and best practices associated with Authentication. Now, let's look at Authorization.

Authorization

Authorization is a process with which we can allow or restrict resources. Depending on the business logic, the requirement of user authorization can vary.

Let's take a CMS as an example. Blog readers can read content without authentication. To create a post in the blog, a user will have to sign up as an author. To publish a post, the user must have editor privileges. To make site-wide changes he must have Administrator privileges.

In this example, user authentication is not required to read a post but it's required to publish one.

For the sake of this example let’s define & assign some routes.

The reader role has access to /blog routes & can read all published posts. The author role has access to /blog/posts routes & can write a post. The editor role has access to /blog/editor routes & can publish posts. The administrator role has access to /blog/admin routes & can do whatever he wants.

Let's assume the business expands and there is a requirement for separate Security & JS editors.

Now, in an enhanced role:

Security Editor has access to /blog/editor but can only publish posts marked with security tag. JS Editor has access to /blog/editor but can only publish posts marked with js tag. Global Editor has access to /blog/editor and can publish posts with all tags.

Let's expand the scenario further. A chief editor is chosen from 10 editors. One of the additional duties of the chief editor is to create reports for the authors. This action is usually assigned to administrators. The developer creates a custom action and adds the privilege to a user. The chief editor can now create reports using the /blog/reports route.

Post registration, a user can be assigned certain roles like Author or Editor. The author role doesn't have access to /posts/editor, so he is authenticated but not authorized. In enhanced role management, two new sub-roles were created which had authorization levels of an editor but with restriction placed with help of tags. This is roughly the basis of any authorization scenario:

Create defined roles as per specific use cases.
Extend or restrict certain roles depending on use cases
Assign custom actions to a user to fine grain.

Implementing Authorized Routes (Express / Angular)

Consider a function Auth which checks user authentication.

function Auth(){
  ...
    return auth.role; 
}

We can implement Auth middleware in express using:

function checkAuth(res, req, next){

    if(Auth() === 'Editor')
        return next();
    res.redirect('/blog')
}
app.get('/blog/editor', checkAuth, function(req, res) {
  res.send('Success');
});

Angular has the CanActivate interface which acts as a Route Guard. First, we define an AuthRouteGuard class:

import { CanActivate } from '@angular/router';
import { Injectable } from '@angular/core';


@Injectable()
export class AuthRouteGuard implements CanActivate {

  constructor() {}

  canActivate() {
    return this.Auth();
  }
  Auth(){
    ...
    return auth.editor.status; 
}
}

In Route config, we define:

import { Routes, CanActivate } from '@angular/router';
import { EditorPage } from './angular/editor-page';
import { AuthRouteGuard } from './auth-route-guard';
export const ROUTES: Routes = [ 
  { 
    path: 'protected',
    component: ProtectedPage,
    canActivate: [AuthRouteGuard] 
  },
  { path: '**', redirectTo: '' }
];

When CanActivate returns true, the user can activate the route. We have to define auth logic in the Auth() or in a separate service.

In the Express snippet, we are blocking disallowed access to a specific user role (Editor). In the Angular snippet, we have assumed a boolean editor.status which is a custom privilege assigned to every user.

Authorization through OWASP's Lens

The most common attack associated with Authorization is privilege escalation. An example of this would be an author discovering a vulnerability and publishing Java tutorials on a JavaScript blog.

Broken Access Control in OWASP Top Ten & Insecure Authorization in OWASP Mobile Top Ten are the risks associated with Authorization.

As OWASP puts it:

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Common access control vulnerabilities include:

Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.
Allowing the primary key to be changed to another’s users' record, permitting viewing or editing someone else’s account.
Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.
Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation
CORS misconfiguration allows unauthorized API access.
Force browsing to authenticated pages as an unauthenticated user or privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.

To strengthen Authorization, we should:

Use Reject-All strategy for everything except public routes.
Implement logging for all privileged actions
Invalidate sessions & tokens after logout/timeout.

Final Thoughts

In this article, we have covered some concepts of Authentication & Authorization. Authentication is still a major security risk. OWASP features it as an A2 risk in the OWASP Top Ten Web Application Security Risks.

As a developer, it's important to invest in secure coding practices. Web attacks are growing and extra efforts have to be made to secure Web apps.

Besides the topics we covered here today, another important security practice in web apps is protecting their JavaScript source code. See our tutorials on protecting React, Angular, Vue, React Native, Ionic, and NativeScript.

Securing React Native Applications

Karan Gandhi — Mon, 24 Feb 2020 15:41:52 +0000

React Native is a popular cross-platform JavaScript framework. Components of React Native apps are rendered in Native UI. In this article, we will focus on the security side of the framework.

Analyzing React Native

React Native has an alternative approach for cross-platform development. Traditionally, Cordova-based frameworks used WebView to render the whole application. In contrast, React Native applications run the JS code in a JavaScript VM based on JavaScriptCore. The application uses native JavaScriptCore on iOS and JavaScriptCore libs are bundled on an APK on Android.

In React Native, the communication between Native and JavaScript code is handled by a JavaScript Bridge. The source JS files are compiled into one single bundle file known as entry-file. In development mode, the file is bundled on a local server and fetched by the application. For production, the application logic is usually bundled in a single file, usually index.android.bundle or index.ios.bundle. Similarly to Cordova, the bundle file is present in the assets folder and, as also happens with Cordova, we can assume React Native apps as containers that run JS code. This logic is implemented in expo. Under certain limitations, Expo can run different business logic in a single application. At this moment, it's fair to assume the entry-file as the core application logic.

We will be dividing the article into the following sections:

Securing app to server connection
Securing local data
Advanced integrity checks

Securing App to Server Connection

Usually, smartphone apps communicate with the backend server via APIs. Insecure Communication is highlighted in the OWASP Mobile Top 10 at #3:

Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception. The use of transport security does not mean the app has implemented it correctly. To detect basic flaws, observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. - M3-Insecure Communication.

Starting from iOS 9 and Android Pie, SSL is required by default. We can enable cleartext traffic but it's not recommended. To secure the connection further, we can pin our server certificates.

SSL Pinning in React Native

Apps are dependent on Certificate Authorities (CA) and Domain Name Servers (DNS) to validate domains for TLS. Unsafe certificates can be installed on a user device, thereby opening the device to a Man-in-the-Middle attack. SSL pinning can be used to mitigate this risk.

We use the fetch API or libraries like axios or frisbee to consume APIs in our React Native applications. However, these libraries don't have support for SSL pinning. Let's explore the available plugins.

react-native-ssl-pinning: this plugin uses OkHttp3 on Android and AFNetworking on iOS to provide SSL pinning and cookie handling. In this case, we will be using fetch from the library to consume APIs. For this library, we will have to bundle the certificates inside the app. Necessary error handling needs to be implemented in older apps to handle certificate expiry. The app needs to be updated with newer certificates before certificates expire. This library uses promises and supports multi-part form data.
react-native-pinch: this plugin is similar to react-native-ssl-pinning. We have to bundle certificates inside the app. This library supports both promises and callbacks.

To use HPKP (Http Public Key Pinning), we can consider these plugins:

react-native-cert-pinner: this plugin allows us to use public hashes to pin the server. Unlike the plugins above, we can use fetch and other utilities directly. The pinning occurs before native JS is run. Also, there is no requirement to define hashes in the request itself.
react-native-trustkit: this is a wrapper plugin for the iOS Trustkit library. This library is available for iOS only.

Alternatively, we can use native implementations as outlined by Javier Muñoz. He has implemented pinning for Android and iOS natively.

Securing Local Storage

Quite often, we store data inside our application. There are multiple ways to store persistent data in React Native. Async-storage, sqlite, pouchdb and realm are some of the methods to store data. Insecure storage is highlighted at #2 in the OWASP Mobile Top 10:

Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Usage of poor encryption libraries is to be avoided. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data. - M2-Insecure Data Storage.

Let's take a look at some plugins which add a layer of security to our application. Also, we will be exploring some plugins which use native security features like Keychain & Keystore Access.

SQLite

SQLite is the most common way to store data. A very popular and open-source extension for SQLite encryption is SQLCipher. Data in SQLCipher is encrypted via 256 bit AES which can't be read without a key. React Native has two libraries that provide SQLCipher:

react-native-sqlcipher-2 : this is a fork of react-native-sqlite-2. We can use pouchdb as an ORM provider with this library, so it's an additional bonus.
react-native-sqlcipher-storage : this is a fork of react-native-sqlite-storage. The library has to be set up manually since it doesn't seem to support react-native link. Interestingly, the library is based on the Cordova implementation.

Realm

Realm is a nice alternative database provider to React Native Apps. It's much faster than SQLite and it has support for encryption by default. It uses the AES256 algorithm and the encrypted realm is verified using SHA-2 HMAC hash. Details of the library can be found here.

Keychain and Keystore Access

Both iOS and Android have native techniques to store secure data. Keychain services allows developers to store small chunks of data in an encrypted database. On Android, most plugins use the Android keystore system for API 23(Marshmallow) and above. For lower APIs, Facebook's conceal provides the necessary crypto functions. Another alternative is to store encrypted data in shared preferences.

React Native has three libraries that provide secure storage along with biometric/face authentication:

React Native KeyChain: as the name implies, this plugin provides access to keychain/keystore. It uses Keychain (iOS), Keystore (Android 23+), and conceal. There is support for Biometric Auth. This plugin has multiple methods and options for both Android and iOS. However, it only allows the storage of the username & password.
React Native Sensitive Info: this plugin is similar to React Native Keychain. It uses Keychain (iOS) and shared preferences (Android) to store data. We can store multiple key-value pairs using this plugin.
RN Secure Storage: this plugin is similar to React Native Sensitive Info. It uses Keychain (iOS), Keystore (Android 23+), and Secure Preferences to store data. We can store multiple key-value pairs.

Advanced Integrity Checks

JailMonkey and SafetyNet

Rooted and jailbroken devices should be considered insecure by intent. Root privileges allow users to circumvent OS security features, spoof data, analyze algorithms, and access secured storage. As a rule of thumb, the execution of the app on a rooted device should be avoided.

JailMonkey allows React Native applications to detect root or jailbreak. Apart from that, it can detect if mock locations can be set using developer tools.

SafetyNet is an Android-only API for detecting rooted devices and bootloader unlocks. We have covered SafetyNet extensively in a previous article. react-native-google-safetynet is a wrapper plugin for SafetyNet's attestation API. It can be used to verify the user's device.

Additionally, we can use react-native-device-info to check if an app is running in an emulator.

Protecting the Application Logic

Earlier in the article, we mentioned how the application logic in entry-file is available in plain sight. In other words, a third-party can retrieve the code, reverse-engineer sensitive logic, or even tamper with the code to abuse the app (such as unlocking features or violating license agreements).

Protecting the application logic is a recommendation in the OWASP Mobile Top 10. Specifically, the main concerns include code tampering:

Mobile code runs within an environment that is not under the control of the organization producing the code. At the same time, there are plenty of different ways of altering the environment in which that code runs. These changes allow an adversary to tinker with the code and modify it at will. — M8-Code Tampering

And reverse engineering:

Generally, most applications are susceptible to reverse engineering due to the inherent nature of code. Most languages used to write apps today are rich in metadata that greatly aides a programmer in debugging the app. This same capability also greatly aides an attacker in understanding how the app works. — M9-Reverse Engineering

Let’s highlight two different strategies to address this risk.

Hermes

Facebook introduced Hermes with the react-native 0.60.1 release. Hermes is a new JavaScript Engine optimized for mobile apps. Currently, it is only available with Android and it’s usage is optional. Hermes can be used in the project with react-native 0.60.4 by changing the enableHermes flag in build.gradle.

Its key benefits are improved start-up time, decreased memory usage, and smaller app size. One of the strategies that Hermes uses to achieve this is precompiling JavaScript to bytecode. At first glance, this appears to make entry-file unreadable. But let's look at a real example.

Let's assume that our entry-file is the one found below:



const {createDecipheriv, createCipheriv, randomBytes} = require('crypto');
const key = Buffer.from('60adba1cf391d89a3a71c72a615cbba8', 'hex');
const algorithm = 'aes-128-cbc';
const softwareVersion = '2.0';
module.exports.createKey = function(userId, expireDate) {
  const payload = {
    userId,
    expireDate,
    softwareVersion
  };
  const json = Buffer.from(JSON.stringify(payload), 'utf8');
  const iv = randomBytes(16);
  const cipher = createCipheriv(algorithm, key, iv);
  let encoded = cipher.update(json);
  encoded = Buffer.concat([encoded, cipher.final()]);
  const joined = iv.toString('hex') + ';' + encoded.toString('hex');
  return Buffer.from(joined, 'utf8').toString('base64');
}
module.exports.validateLicense = function(license, userId) {
  const licenseFields = Buffer.from(license, 'base64').toString('utf8');
  const fields = licenseFields.split(';');
  const iv = Buffer.from(fields[0], 'hex');
  const data = Buffer.from(fields[1], 'hex');
  const decipher = createDecipheriv(algorithm, key, iv);
  let decoded = decipher.update(data);
  decoded = Buffer.concat([decoded, decipher.final()]);
  const result = JSON.parse(decoded);
  if (result.userId != userId) {
    throw new Error('Wrong user');
  }
  if (new Date(result.expireDate) < new Date()) {
    throw new Error('Expired license');
  }
  if (result.softwareVersion != softwareVersion) {
    throw new Error('This license is not valid for this program version');
  }
  return result;
}

After Hermes compiles this file, the resulting bytecode can easily be decompiled using hbcdump and, among the decompiled code, we find some easy to read code:



s0[ASCII, 0..-1]: 
s1[ASCII, 0..2]: 2.0
s2[ASCII, 3..34]: 60adba1cf391d89a3a71c72a615cbba8
s3[ASCII, 35..35]: ;
s4[ASCII, 36..50]: Expired license
s5[ASCII, 71..120]: This license is not valid for this program version
s6[ASCII, 121..130]: Wrong user
s7[ASCII, 133..143]: aes-128-cbc
s8[ASCII, 143..148]: crypto
s9[ASCII, 154..159]: global
s10[ASCII, 160..165]: base64
s11[ASCII, 166..168]: hex
s12[ASCII, 177..180]: utf8
i13[ASCII, 50..56] #C765D706: exports
i14[ASCII, 56..70] #FF849242: softwareVersion
i15[ASCII, 127..132] #6FE51CD4: userId
i16[ASCII, 147..154] #1E019520: toString
i17[ASCII, 167..176] #68A06D42: expireDate
i18[ASCII, 173..176] #CD347266: Date
i19[ASCII, 181..186] #5AA7C487: Buffer
i20[ASCII, 186..196] #FD81EB01: randomBytes
i21[ASCII, 196..200] #0EC469F8: split
i22[ASCII, 201..205] #9102A3D0: Error
i23[ASCII, 205..211] #EB75CA32: require
i24[ASCII, 212..215] #971CE5C7: JSON
i25[ASCII, 216..221] #CB8DFA65: concat
i26[ASCII, 222..235] #96C7181F: createCipheriv
i27[ASCII, 235..249] #D60B6B51: validateLicense
i28[ASCII, 250..265] #723D6A80: createDecipheriv
i29[ASCII, 266..274] #01D3AE7D: createKey
i30[ASCII, 275..279] #47993A63: final
i31[ASCII, 280..283] #EAF03666: from
i32[ASCII, 283..288] #2A322C6E: module
i33[ASCII, 289..293] #958EDB02: parse
i34[ASCII, 294..302] #807C5F3D: prototype
i35[ASCII, 303..311] #8D1543BD: stringify
i36[ASCII, 312..317] #60396F4B: update

Function<global>0(1 params, 15 registers, 4 symbols):
Offset in debug table: src 0x0, vars 0x0
license.js[1:1]
    CreateEnvironment r0
    GetGlobalObject   r1
    TryGetById        r4, r1, 1, "require"
    LoadConstUndefined r3
    LoadConstString   r2, "crypto"
    Call2             r2, r4, r3, r2
    GetByIdShort      r3, r2, 2, "createDecipheriv"
    StoreToEnvironment r0, 0, r3
    GetByIdShort      r3, r2, 3, "createCipheriv"
    StoreToEnvironment r0, 1, r3
    GetByIdShort      r2, r2, 4, "randomBytes"
    StoreToEnvironment r0, 2, r2
    TryGetById        r5, r1, 5, "Buffer"
    GetByIdShort      r4, r5, 6, "from"
    LoadConstString   r3, "60adba1cf391d89a3"...
    LoadConstString   r2, "hex"
    Call3             r2, r4, r5, r3, r2
    StoreToEnvironment r0, 3, r2
    TryGetById        r2, r1, 7, "module"
    GetByIdShort      r3, r2, 8, "exports"
    CreateClosure     r2, r0, 1
    PutById           r3, r2, 1, "createKey"
    TryGetById        r1, r1, 7, "module"
    GetByIdShort      r1, r1, 8, "exports"
    CreateClosure     r0, r0, 2
    PutById           r1, r0, 2, "validateLicense"
    Ret               r0

So, while Hermes introduces a certain degree of complexity to the entry-file code, it doesn't actually conceal the code nor do anything to prevent code tampering, which means that it won't stop an attacker ⁠— let's not forget that this is not even the purpose of Hermes.

And this leads us to an approach that obfuscates React Native’s JavaScript source code to effectively mitigate the risk of code tampering and reverse engineering: Jscrambler.

Jscrambler

Jscrambler provides a series of layers to protect JavaScript. Unlike most tools that only include (basic) obfuscation, Jscrambler provides three security layers:

Polymorphic JavaScript & HTML5 obfuscation;
Code locks (domain, OS, browser, time frame);
Self-defending (anti-tampering & anti-debugging);

By protecting the source code of React Native apps with Jscrambler, the resulting code is highly obfuscated, as can be observed below:

On top of this obfuscation, there's a Self-Defending layer that provides anti-debugging and anti-tampering capabilities and enables setting countermeasures like breaking the application, deleting cookies, or destroying the attacker’s environment.

To get started with protecting React Native source code with Jscrambler, check the official guide.

Final Thoughts

This article provides an overview of techniques to harden a React Native application.

Developer surveys show that React Native is still a framework of choice, even among development teams of large enterprises.

It’s then crucial to create a threat model and, depending on the application’s use case, employ the required measures to ensure that the application is properly secured.

Feel free to test how Jscrambler protects your React Native source code by using a free trial.

Best Practices for Secure Session Management in Node

Karan Gandhi — Thu, 13 Feb 2020 16:57:27 +0000

In a web application, data is transferred from a browser to a server over HTTP. In modern applications, we use the HTTPS protocol, which is HTTP over TLS/SSL (secure connection), to transfer data securely.

Looking at common use cases, we often encounter situations where we need to retain user state and information. However, HTTP is a stateless protocol. Sessions are used to store user information between HTTP requests.

We can use sessions to store users' settings like when not authenticated. Post authentication sessions are used to identify authenticated users. Sessions fulfill an important role between user authentication and authorization.

Exploring Sessions

Traditionally, sessions are identifiers sent from the server and stored on the client-side. On the next request, the client sends the session token to the server. Using the identifier, the server can associate a request with a user.

Session identifiers can be stored in cookies, localStorage, and sessionStorage. Session identifiers can be sent back to the server via cookies, URL params, hidden form fields or a custom header. Additionally, a server can accept session identifiers by multiple means. This is usually the case when a back-end is used for websites and mobile applications.

Session Identifiers

A session identifier is a token stored on the client-side. Data associated with a session identifier lies on the server.

Generally speaking, a session identifier:

Must be random;
Should be stored in a cookie.

The recommended session ID must have a length of 128 bits or 16 bytes. A good pseudorandom number generator (PNRG) is recommended to generate entropy, usually 50% of ID length.

Cookies are ideal because they are sent with every request and can be secured easily. LocalStorage doesn't have an expiry attribute so it persists. On the other hand, SessionStorage doesn't persist across multiple tabs/windows and is cleared when a tab is closed. Extra client code is required to be written to handle LocalStorage / SessionStorage. Additionally, both are an API so, theoretically, they are vulnerable to XSS.

Usually, the communication between client and server should be over HTTPS. Session identifiers should not be shared among the protocols. Sessions should be refreshed if the request is redirected. Also, if the redirect is to HTTPS, the cookie should set after the redirect. In case multiple cookies are set, the back-end should verify all cookies.

Securing Cookie Attributes

Cookies can be secured using the following attributes.

The Secure attribute instructs the browser to set cookies over HTTPS only. This attribute prevents MITM attacks since the transfer is over TLS.
The HttpOnly attribute blocks the ability to use the document.cookie object. This prevents XSS attacks from stealing the session identifier.
The SameSite attribute blocks the ability to send a cookie in a cross-origin request. This provides limited protection against CSRF attacks.
Setting Domain & Path attributes can limit the exposure of a cookie. By default, Domain should not be set and Path should be restricted.
Expire & Max-Age allow us to set the persistence of a cookie.

Typically, a session library should be able to generate a unique session, refresh an existing session and revoke sessions. We will be exploring the express-session library ahead.

Enforcing Best Practices Using express-session

In Node.js apps using Express, express-session is the de facto library for managing sessions. This library offers:

Cookie-based Session Management.
Multiple modules for managing session stores.
An API to generate, regenerate, destroy and update sessions.
Settings to secure cookies (Secure / HttpOnly / Expire /SameSite / Max Age / Expires /Domain / Path)

We can generate a session using the following command:

app.use(session({
  secret: 'veryimportantsecret',  
}))

The secret is used to sign the cookie using the cookie-signature library. Cookies are signed using Hmac-sha256 and converted to a base64 string. We can have multiple secrets as an array. The first secret will be used to sign the cookie. The rest will be used in verification.

app.use(session({
  secret: ['veryimportantsecret','notsoimportantsecret','highlyprobablysecret'],
}))

To use a custom session ID generator, we can use the genid param. By default, uid-safe is used to generate session IDs with a byte length of 24. It's recommended to stick to default implementation unless there is a specific requirement to harden uuid.

app.use(session({
    secret: 'veryimportantsecret', 
    genid: function(req) {
      return genuuid() // use UUIDs for session IDs
     }
}))

The default name of the cookie is connect.sid. We can change the name using the name param. It's advisable to change the name to avoid fingerprinting.

app.use(session({
  secret: ['veryimportantsecret','notsoimportantsecret','highlyprobablysecret'], 
  name: "secretname" 
}))

By default, the cookies are set to

{ path: '/', httpOnly: true, secure: false, maxAge: null }

To harden our session cookies, we can assign the following options:

app.use(session({
  secret: ['veryimportantsecret','notsoimportantsecret','highlyprobablysecret'],  
   name: "secretname",
  cookie: {
      httpOnly: true,
      secure: true,
      sameSite: true,
      maxAge: 600000 // Time is in miliseconds
  }
}))

The caveats here are:

sameSite: true blocks CORS requests on cookies. This will affect the workflow on API calls and mobile applications.
secure requires HTTPS connections. Also, if the Node app is behind a proxy (like Nginx), we will have to set proxy to true, as shown below.

app.set('trust proxy', 1)

By default, the sessions are stored in MemoryStore. This is not recommended for production use. Instead, it's advisable to use alternative session stores for production. We have multiple options to store the data, like:

Databases like MySQL, MongoDB.
Memory stores like Redis.
ORM libraries like sequelize.

We will be using Redis as an example here.

npm install redis connect-redis

const redis = require('redis');
const session = require('express-session');
let RedisStore = require('connect-redis')(session);
let redisClient = redis.createClient();

app.use(
  session({
    secret: ['veryimportantsecret','notsoimportantsecret','highlyprobablysecret'], 
     name: "secretname", 
     cookie: {
      httpOnly: true,
      secure: true,
      sameSite: true,
      maxAge: 600000 // Time is in miliseconds
  },
    store: new RedisStore({ client: redisClient ,ttl: 86400}),   
    resave: false
  })
)

The ttl (time to live) param is used to create an expiration date. If the Expire attribute is set on the cookie, it will override the ttl. By default, ttl is one day.

We have also set resave to false. This param forces the session to be saved to the session store. This param should be set after checking the store docs.

The session object is associated with all routes and can be accessed on all requests.

router.get('/', function(req, res, next) {
  req.session.value = "somevalue";  
  res.render('index', { title: 'Express' });
});

Sessions should be regenerated after logins and privilege escalations. This prevents session fixation attacks. To regenerate a session, we will use:

req.session.regenerate(function(err) {
  // will have a new session here
})

Sessions should be expired when the user logs out or times out. To destroy a session, we can use:

req.session.destroy(function(err) {
  // cannot access session here
})

Side Note: While this article focuses on back-end security, you should protect your front-end as well. See these tutorials on protecting React, Angular, Vue, React Native, Ionic, and NativeScript.

Extra Security with Helmet.js (Cache-Control)

Web Caching allows us to serve requests faster. Some sensitive data might be cached on the client computer. Even if we timeout the session, there might be a possibility that the data can be retrieved from the web cache. To prevent this, we need to disable cache.

From the POV of this article, we are interested in setting the Cache-Control header to disable client-side caching.

Helmet.js is an Express library that can be used to secure our Express apps.
The noCache method will set Cache-Control, Surrogate-Control, Pragma, and Expires HTTP headers for us.

const helmet = require('helmet')
app.use(helmet.noCache())

However, in general, it's wise to use the other options too. Helmet.js provides:

dnsPrefetchControl to control browser DNS prefetching.
frameguard to prevent clickjacking.
hidePoweredBy to hide X-Powered-By header.
hsts for HTTP Strict transport Security
noSniff to keep clients from sniffing MIME types
xssFilter to add some XSS protection.

Alternatively, if the site has the requirement to be cached, at the very least, the Cache-Control header must be set to Cache-Control: no-cache="Set-Cookie, Set-Cookie2"

router.get('/', function(req, res, next) {
res.set('Cache-Control', "no-cache='Set-Cookie, Set-Cookie2'");
// Route Logic
})

Logging Sessions

Whenever a new session is created, regenerated, or destroyed, it should be logged. Namely, activities like user-role escalation or financial transactions should be logged.

A typical log should contain the timestamp, client IP, resource requested, user ID, and session ID.

This will be helpful to detect session anomalies in case of an attack. We can use winston, morgan or pino to log these requests. By default, Express comes with morgan preinstalled. The default combined setting provides us standard Apache combined log output.

We can modify morgan to include session identifiers using custom morgan tokens. Depending on the use-case we add additional data to output. Similar processes can be implemented in other logging libraries.

var express = require('express')
var morgan = require('morgan')

var app = express()

morgan.token('sessionid', function(req, res, param) {
    return req.sessionID;
});
morgan.token('user', function(req, res, param) {
    return req.session.user;
});

app.use(morgan(':remote-addr - :remote-user [:date[clf]] ":method :url HTTP/:http-version" :status :res[content-length] ":referrer" ":user-agent" :user :sessionid'))

app.get('/', function (req, res) {
  res.send('hello, world!')
})

Depending on the use case, logging scenarios should be built and implemented.

Additional Client-Side Defenses

There are some other client-side measures we can take to expire sessions.

Session Timeouts on Browser Events

We can use JavaScript to detect if the window.close event is fired and subsequently force a session logout.

Timeout Warnings

A user can be notified of session timeouts on the client-side. This will notify the user that his session is going to expire soon. This is helpful when a long business process is involved. Users can save their work before timeout OR continue working.

Initial Login Timeout

A client-side timeout can be set between the page that was loaded and the user that was authenticated. This is to prevent session fixation attacks, especially when the user is using a public/shared computer.

Alternatives

Currently, JWT is a viable alternative to the session. JWT is a stateless Auth mechanism. A Bearer token is sent in the header of every authenticated request. The payload of the JWT token contains the necessary details used for authorization. This is useful when we want to expose some part of our data as an API resource. However, unlike sessions, JWT is stateless and hence the logout code has to be implemented on the client-side. You can set an expiry timestamp in JWT payload but cannot force a logout.

Final Thoughts

As we explored in this tutorial, managing sessions securely in Node/Express apps is a key security requirement.

We have highlighted some techniques to prevent some very serious attacks like CRSF, XSS, and others that might expose sensitive user information.

At a time when web-based attacks are growing fast, these threats must be addressed while developing the app to minimize the application’s attack surface.

For some further reading on security in JavaScript apps, check this data sheet.

Background Services in Ionic Capacitor

Karan Gandhi — Wed, 30 Oct 2019 14:23:53 +0000

A few months back, the Ionic team introduced Capacitor, a new runtime for cross-platform development. Capacitor supports Android, iOS, PWA, and Electron platforms.

We covered PWA development with Capacitor in another article. In this article, we will be focusing on native workflow and functionalities.

Alternative to Cordova

Both Cordova and Capacitor are runtimes providing native functionalities over WebView. Cordova is a quite mature runtime with numerous plugins and robust tooling. Capacitor is a relatively new runtime with a different approach.

The Cordova framework provides a lot of native features like file management and camera to develop applications. The framework can be extended via multiple community plugins.

Frameworks like Ionic and OnsenUI were built on top Cordova and integrated the Cordova CLI into their tooling. The build process is handled by cordova-cli which could be extended via hooks. Native App features can be controlled via the config.xml file. The application logic is usually in the www folder. Ionic applications usually have it in the src folder which is then compiled to www via the Ionic CLI. In this context, the www or src folders are important. The platforms folder, which has native code, can be configured at build time. There is little need for the platforms to be a part of the developer workflow.

This is where Capacitor differs from Cordova. Capacitor considers the platforms folder as a source asset instead of a build time asset. Developers are encouraged to use Native IDEs, namely Android Studio and X-Code for development. The native code in the platforms folder is a part of the developer's git repository. Developers have more control over native code as compared to Cordova. Capacitor apps don't require a deviceready event. All plugin methods are available as soon as the WebView loads. However, Capacitor has limited backward compatibility with Cordova plugins. Due to the lack of support for hooks, the plugins have to be manually set up beforehand.

Starting a new project

We can initialize a Capacitor project in multiple ways. The simplest way to create a new project is by using the Ionic CLI.



ionic start CapacitorProject sidemenu --capacitor

We can add Capacitor to an existing Ionic project using



ionic integrations enable cordova

Capacitor is platform-agnostic - which means that we can also add it to an existing web app using



npm install --save @capacitor/core @capacitor/cli
npx cap init

Alternatively, we can start a project using the Capacitor CLI.



npx @capacitor/cli create

Capacitor Config

We can configure Capacitor projects using capacitor.config.json. This file provides configuration to the Capacitor's tooling. Here is the JSON which we used in the RealWorldApp docs.



{
  "appId": "me.karandpr.conduit",
  "appName": "Conduit",
  "bundledWebRuntime": false,
  "npmClient": "npm",
  "webDir": "build"
}

appID is the package identifier and appName is the application name. npmClient is the package manager in use. webDir is the directory where the build web assets are stored. The rest of the config options can be found here

Developer Workflow

In Cordova projects, we simply used the following command to run on a device:



ionic cordova run android

The developer workflow for Capacitor projects is below.

As shown, we can build projects using relevant build command like



npm run build



yarn run build



ionic build

The built web app should be available in folders like www or build. We have already specified the folder to be webDir in capacitor.config.json. To copy the assets to native platforms, we will execute



npx cap copy

If we have installed a new plugin, we will have to use the command



npx cap sync

Lastly, we can open the project in a native IDE using



npx cap open

Background Tasks

Now that we covered the main developer workflow, let’s zoom into how background services work in Capacitor.

Capacitor has default plugins to ease up native development. The usual suspects File, Camera, Geolocation and Push are already present. One plugin API which caught our fancy is Background Task. The Background Task API allows the Capacitor app to run short tasks in the background. This comes in handy if we want to finish some tasks after the app is pushed to the background. Currently, the plugin provides two functions.

BackgroundTask.beforeExit: This function allows certain tasks to be run in the background.
BackgroundTask.finish: This function notifies the OS that the task is over. This is important for iOS.

In the future, the plugin may support background fetch operations.
Let's look at a code snippet to see how Background Task works. The purpose of the snippet is to get the Latitude & Longitude of the device after the app is pushed to the background. We have used Geolocation and LocalNotifications API for that purpose.



 App.addListener('appStateChange', (state) => {     
      if (!state.isActive) {
        // We are using the appStateChange event to detect a change.

        let taskId = BackgroundTask.beforeExit(async () => {
          // We will be using this function to get geolocation.
          let location = await this.getCurrentPosition(); 
          // The location is fetched using Geolocation service.

          LocalNotifications.schedule({
            notifications: [
              {
                title: "Last Known Location",
                body: "Latitude: "+ location.coords.latitude +"Longitude: "+ location.coords.longitude,
                id: 1,
                schedule: { at: new Date(Date.now() + 1000 * 10) },
                sound: null,
                attachments: null,
                actionTypeId: "",
                extra: null
              }
            ]
          });   
          // We have scheduled a notification after 10 seconds.
          BackgroundTask.finish({
              taskId
            });         
            // We have notified the OS that the task is finished.
        });
      }   
    })

    async getCurrentPosition() {
      const coordinates = await Geolocation.getCurrentPosition();      
      return coordinates
    }

The iOS implementation uses UIApplication's Background Task. It's mandatory in iOS to invoke finish - otherwise, the app may be labeled as impacting battery life. The usual time allowed for running the task is around 180 seconds. After the time limit, iOS may close the app. Also, setInterval and setTimeout won't work once the app is in the background.

The Android Implementation uses IntentService to execute background tasks. IntentService runs outside the application in a background process. Hence, a task can run independently even after the app is removed from memory. On Android, there is no restriction on the length of the task.

Closing Thoughts

Capacitor introduces us to a new way to develop WebView Apps. It has some interesting plugin APIs like Background Task. Currently, there are some incompatible plugins which might require some workarounds. If you are a seasoned developer, you should try Capacitor in your upcoming projects.

As a drawback, old or private Cordova plugins might cause build issues with Capacitor. There is no specific guideline for integrating such plugins. In such cases, it's better to stick to current build processes and plan out a migration strategy. Also, it might be frustrating for new developers to work in three workspaces. If you don't want to work with native platforms, you can always use Cordova.

As a final note, don't forget that, before deploying your commercial or enterprise Ionic apps to production, you should always protect their logic against reverse-engineering, abuse, and tampering by following this guide.

Originally published on the Jscrambler Blog.

Developing a Real World App in Ionic React

Karan Gandhi — Fri, 07 Jun 2019 16:49:31 +0000

Ionic recently added support for the React and Vue frameworks. Traditionally, Ionic used Angular and Cordova frameworks to create their apps. With Ionic 4, we can develop framework-agnostic apps. In this tutorial, we will create a basic Ionic app in the React Framework.

RealWorld and Conduit

The folks at Thinkster are behind a project known as RealWorld project. Conduit is a Medium clone which can be built using multiple stacks. We can mix and match different types of backends and frontends. Every backend and frontend follow the same API spec.

Unlike simple CRUD ToDo Apps, Conduit is a full-fledged CMS. Implementing the project requires some effort.

Getting Started

For this tutorial, we will be covering the following points.

Home Page (With and Without Auth)
- List of Articles
- Favorite an Article (Auth Required)
- Navigate to Article Page
- Navigate to Author Profile Page
- Display your Feed (Auth Required)
- Display Popular Tags.
- Filter Articles by Tags.
Article Page (With and Without Auth)
- Read Article
- List Comments
- Add Comment (Auth Required)
- Navigate to Author Page
Settings Page (Auth required)
- Modify user Settings
Profile Page (With and Without Auth)
- Display User details
- Display Posts by user
- Display Posts Favorited by user
- Follow User (Auth Required)
Create Article (Auth Required)
- Create Article
Login / Signup Page
- Signup User
- Login User

Understanding the Conduit API

Conduit has a production API endpoint here. We will use that endpoint for this tutorial. Alternatively, you can set up your own backends using a variety of languages.

We will be using:

/articles: For fetching articles, comments
/users: For creating and Authenticating users
/profiles: For following profiles
/tags: For fetching tags

Users are authenticated via a JWT token in headers.

Setting up the Project

The Ionic CLI currently doesn't support React templates. We will be using create-react-app to set up our project. Use:

npm i -g create-react-app
create-react-app conduit --typescript

Alternatively, we can use npx:

npx create-react-app conduit --typescript

Navigate to the folder and install Ionic and React router:

cd conduit
npm install @ionic/react react-router react-router-dom @types/react-router @types/react-router-dom

Let's initialize Ionic in this project.

ionic init "Conduit" --type=custom

We need to enable Capacitor in our project

ionic integrations enable capacitor

A file capacitor.config.json is generated in our project directory. In the file, we need to change the build directory from "webDir": "www" to "webDir": "build".

Create a build folder OR generate a build using:

npm run build

Now, we can add a platform to our project.

npx capacitor add android

Additionally, we will be using this folder structure.

src
- components/
- pages/
- constants.ts

Let's set up our constants file.

export interface AppConfig {    
    API_ENDPOINT : string

  }  

export const CONFIG: AppConfig = {
    API_ENDPOINT : "https://conduit.productionready.io/api/"
  };

In the App.tsx file, we need to import the Ionic CSS files.

import '@ionic/core/css/core.css';
import '@ionic/core/css/ionic.bundle.css';

Developing the App

An offline user has access to the Home, Article, Profile and Login pages. An online user has access to the Home, Article, Profile, Settings and Login Pages.

There are 70+ Ionic components we can use to speed up our development. First, let's set up routing.

Routing

We are using React Router to manage Routing. We will be using IonRouterOutlet to manage routes. The key difference with the website is that users can't navigate with urls. We are also creating a custom component SideMenu for side menu navigation. IonMenuToggle is used to toggle the menu in components.

A loggedIn key and an Event Listener are used to manage user state. The token obtained from authentication will be saved in localstorage.

class App extends Component {
  constructor(props: any){
    super(props);
  }
  render() {
    return (
      <Router>
        <div className="App">        
          <IonApp>
          <IonSplitPane contentId="main">
            <SideMenu></SideMenu>
            <IonPage id="main">        
                <IonRouterOutlet>
                    <Route exact path="/" component={HomePage} />
                    <Route exact path="/login" component={LoginPage} />  
                    <Route path="/article/:slug" component={ArticlePage} />
                    <Route path="/profile/:authorname" component={ProfilePage} />
                    <Route path="/settings" component={SettingsPage} />
                    <Route path="/newarticle" component={NewArticlePage} />                             
                </IonRouterOutlet>
            </IonPage>
            </IonSplitPane>
          </IonApp>
        </div>
      </Router>
    );
  }
}

export default App;

Side menu Component:

class SideMenu extends React.Component<any, any> {
  constructor(props: any){
    super(props);
        this.state = {      
      isLoggedIn: localStorage.getItem("isLogin") ? localStorage.getItem("isLogin") :"false",   
      routes:  {
        appPages: [
          { title: 'Home', path: '/', icon: 'home' },         
        ],        
        loggedOutPages: [
          { title: 'Login', path: '/login', icon: 'log-in' },
        ]  }
    }
    window.addEventListener('loggedIn', (e: any) => {            
      this.setState({
        isLoggedIn : e['detail'].toString(),
        routes : {
          appPages: [
            { title: 'Home', path: '/', icon: 'home' },         
          ],
          loggedInPages: [
            { title: 'My Profile', path: '/profile/'+localStorage.getItem("username"), icon: 'person'},        
            { title: 'New Article', path: '/newarticle', icon: 'create' },
            { title: 'Settings', path: '/settings', icon: 'settings' },
            { title: 'Logout', path: '/login', icon: 'log-out' }
          ],
          loggedOutPages: [
            { title: 'Login', path: '/login', icon: 'log-in' },
          ]  }        
      })      

    });  
  }    

   renderMenuItem(menu: any) {
    return (
         <IonMenuToggle key={menu.title} auto-hide="false">
                   <IonItem>
                     <IonIcon name={menu.icon} ></IonIcon>
                     <Link replace className="sidemenu-link" to={menu.path} >{menu.title}</Link> 
                   </IonItem>
                   </IonMenuToggle>
      )
  }

  render() {
      return (  
        <IonMenu side="start" menuId="first" contentId="main">
          <IonHeader>
            <IonToolbar color="success">
              <IonTitle>Start Menu</IonTitle>
            </IonToolbar>
          </IonHeader>
          <IonContent>
            <IonList>
              {this.state.routes.appPages.map((art: any) => this.renderMenuItem(art))}
              {this.state.isLoggedIn === "true" ? <> {this.state.routes.loggedInPages.map((art: any) =>
                this.renderMenuItem(art))} </> :<> {this.state.routes.loggedOutPages.map((art: any) =>
                this.renderMenuItem(art))} </> }
            </IonList>
          </IonContent>
        </IonMenu>
      )
  }
}
export default SideMenu

Home Page

As mentioned above, the Home Page has a list of articles. The /articles endpoint provides us an array of 20 articles.

A normal user can:

View a list of articles
Navigate to a full article
Navigate to author profile
Filter articles by tags

An authenticated user can additionally:

View his/her article feed
Favorite an article

We will create the ArticleCard and TagsCloud components to make our tasks simpler.

Additionally, Header is a wrapper around Ionic Header with title as props.

   <IonHeader>
          <IonToolbar >
          <IonTitle  class="header"  color="success">{this.props.title}</IonTitle>           
            <IonMenuButton slot="start"></IonMenuButton>
          </IonToolbar>
        </IonHeader>

TagsCloud is a component to retrieve popular tags. We receive an array of tags at the endpoint /tags. We will be passing a function onTagClick in props. So, we will be able to filter the articles using the clicked tag. We are using IonChip to render the tag chips.

handleClick(tag: any) {
    console.log(tag);
    this.props.onTagClick(tag);
  }

  componentDidMount() {    
    fetch(CONFIG.API_ENDPOINT+"tags")
      .then(res => res.json())
      .then(
        (res) => {
          this.setState({          
            tags: res.tags
          });
        },      
        (err) => {
          console.log(err)
        }
      )
  }

  render() {
    return (      
      <div className="tagcloud">
      <IonLabel text-center>
            Popular Tags
          </IonLabel>
          <div>        
         {this.state.tags.map((tag: any, index: number) => 
          <IonChip color="success" key={index}>
          <IonLabel  onClick={() => this.handleClick(tag)}>{tag}</IonLabel>
        </IonChip>           
             )}         
         </div>
      </div> 
    );       
  }
}

The ArticleCard component returns an IonItem and IonItemSliding for logged in users. A user can swipe and favorite an article if he/she chooses to.

Let's create a function loggedOutCard to return an IonItem.

loggedOutCard() {
  return (                 
           <IonItem >
          <IonAvatar slot="start">
              <img src={this.props.src} />              
            </IonAvatar>
            <IonLabel>
              <p className="title">{this.props.title}</p>              
              <IonGrid >
                <IonRow>
                  <IonCol class="author" size="6">
                  <Link className="link" to={this.profileLink}>
                  {this.props.author}</Link>                     
                 </IonCol>
                  <IonCol  size="6" text-right>                  
                  <Link className="link" to={this.routeLink}>Read More</Link>        
                  </IonCol>
                </IonRow>
              </IonGrid>
            </IonLabel>
          </IonItem>      
  )
}

We create a function loggedInCard to return an IonSlidingItem.

loggedInCard(){
  return (        
           <IonItemSliding>
          {this.loggedOutCard()}
        <IonItemOptions side="end">
          <IonItemOption  color={this.state.favorited ? "success": "light"} onClick={this.favoriteArticle}>
          <IonIcon color={this.state.favorited ? "light": "success"} class="icon-blog-card" name="heart" />{this.state.favoritesCount}</IonItemOption>
        </IonItemOptions>
      </IonItemSliding>           
  )
}

Authenticated users can favorite an article. We will create a function favoriteArticle to achieve this.

favoriteArticle = (params: any) => {
  console.log(params);
  let url = CONFIG.API_ENDPOINT+"articles/" + this.props.slug + '/favorite';
  let method;
  if (!this.state.favorited) {
    method = 'POST'
  } else {
    method = "DELETE"
  }
  fetch(url, {
      method: method,
      headers: {
        "Content-Type": "application/json",
        "Authorization": "Token " + localStorage.getItem("token"),
      }
    })
    .then(res => res.json())
    .then(
      (res) => {       
        this.setState({
          favorited: res.article.favorited,
          favoritesCount: res.article.favoritesCount,
        })
      },
      (err) => {
        console.error(err);
      }
    )
}

Finally, let’s return the component based on user state.

  render() {   
      return (
        <>
        {localStorage.getItem("isLogin") === "true" ? this.loggedInCard() : this.loggedOutCard()} 
        </>               
      );    
  }
}

After fetching the articles from the /articles endpoint, we will iterate the ArticleCard component in our Home Page.

render() {      
      return (
        <>   
        <Header title="Home"></Header>
        <IonContent> 
          <IonSegment onIonChange={this.toggle} color="success">
              <IonSegmentButton value="Global" color="success" checked={this.state.segment==='Global' }>
                  <IonLabel>Global Feed</IonLabel>
              </IonSegmentButton>
              {localStorage.getItem("isLogin") === "true" ? <IonSegmentButton value="myfeed" color="success"
                  checked={this.state.segment==='myfeed' }>
                  <IonLabel>Your Feed</IonLabel>
              </IonSegmentButton> : '' }
          </IonSegment>
        <IonList>
        {this.state.articles.map((article: any) => 
        <ArticleCard key={article.slug} title={article.title} src={article.author.image} description={article.description} favorited={article.favorited} favoritesCount={article.favoritesCount} slug={article.slug} author={article.author.username}></ArticleCard>
        )}      
        </IonList>
        <TagCloud onTagClick={(e: any) => this.handleTagClick(e)} ></TagCloud>   
        </IonContent>    
      </>
      );
    }

The toggle and handleTagClick functions are in the source code.

Article Page

We are fetching an individual article by slug in the article page. The body of the article is in Markdown format. To display the article, we will be using showdown to convert it. Additionally, comments for the article are fetched from the /articles/slug/comments endpoint and logged in users can post a comment. We will be creating a separate Comment component to iterate over the list. To post comments, logged in users can use IonTextArea.

npm i showdown @types/showdown

We will initialize showdown using:

  this.converter = new Showdown.Converter({
          tables: true,
          simplifiedAutoLink: true,
          strikethrough: true,
          tasklists: true,
          requireSpaceBeforeHeadingText: true
        });

And we will display markdown display using:

   <div dangerouslySetInnerHTML={{ __html: this.converter.makeHtml(article.body)}}></div>

            </div>

The rest of the source can be viewed here.

Login Page

Login Page is a basic form Page. We will be accepting email and password. The /users/login endpoint accepts the POST request and returns a JWT token. We will save the JWT token in localstorage to manage our auth. In order to toggle the side menu, we will be using standard JS events. Also, we will be signing up users using the /users endpoint. Additionally, we are using the IonToast component to display error messages. The code used for the Login Page is below. IonInput uses CustomEvent and we can use the onIonChange event to bind the input to the state.

updateUserName = (event: any) => {
    this.setState({ username: event.detail.value });  
  };
login= () => {
    let url , credentials;     
    if(this.state.action  == 'Login'){
      url = CONFIG.API_ENDPOINT + '/users/login';
      credentials = {
        "user": {
          "email": this.state.email,
          "password": this.state.password
      }
      }

    } else {
      url = CONFIG.API_ENDPOINT + '/users';
      credentials = {
        "user": {
          "email": this.state.email,
          "password": this.state.password,
          "username": this.state.username
      }
      }
    }
    fetch(url, {
            method: 'POST',
            headers: {
                "Content-Type": "application/json",              
            },
            body: JSON.stringify(credentials)

        })
        .then((res) => {
          console.log(res);
          if(res.status == 200){
            return res.json();
          } else {  
            if(this.state.action == 'SignUp') {
              throw new Error("Error creating user");
            } else {
              throw new Error("Error Logging in")  
            }                
          }

        } )
        .then(
          (result) => {
              console.log(result);    
              localStorage.setItem("token",result.user.token);       
              localStorage.setItem("username", result.user.username);
              localStorage.setItem("isLogin", "true");
              localStorage.setItem("email", result.user.email);

              this.event = new CustomEvent('loggedIn', {
                detail: true
              });
              window.dispatchEvent(this.event);
              this.props.history.push('/blog');
          },

          (error) => {
           console.error(error);           
           this.setState({toastMessage: error.toString(), toastState: true});
          }
        )
  }

  render(){
    return(
      <>
    <Header title="Login"></Header>    
    <IonContent padding>

    <div className="ion-text-center">
    <img src={image} alt="logo" width="25%" /> 
    </div>
    <h1 className="ion-text-center conduit-title">conduit</h1>      

    <IonToast
        isOpen={this.state.toastState}
        onDidDismiss={() => this.setState(() => ({ toastState: false }))}
        message= {this.state.toastMessage}
        duration={400}
      >
      </IonToast>

    <form action="">

    <IonItem>

      <IonInput  onIonChange={this.updateEmail} type="email" placeholder="Email"></IonInput>
    </IonItem>
    {this.state.action === 'SignUp' ?    
      <IonItem>

        <IonInput onIonChange={this.updateUserName} type="text" placeholder="Username"></IonInput>
      </IonItem>
      : <></> }

    <IonItem>
    <IonInput onIonChange={this.updatePassword} type="password" placeholder="Password"></IonInput>      
    </IonItem>

    </form>      

            <IonButton onClick={this.login}>{this.state.action}</IonButton>         

    </IonContent>
    <IonFooter>
      <IonToolbar text-center>
          Click here to <a onClick={this.toggleAction}>{this.state.action === 'Login'? 'SignUp' : 'Login'}</a>
      </IonToolbar>
    </IonFooter>
  </>
    )
  }

New Article Page

This page is a form page like the login page. However, for the article body, we will be using a Markdown editor instead of a text area. For this tutorial, we are going to use react-mde.

npm install --save react-mde

The form code is as below:

<form onSubmit={this.submitArticle}>
      <IonInput type="text" placeholder="Title" onIonChange={this.titleChange} class="border-input"></IonInput>
    <IonInput type="text" placeholder="What's this article about"  onIonChange={this.descriptionChange} class="border-input"></IonInput>

          <ReactMde
          onChange={this.handleBodyChange}
          onTabChange={this.handleTabChange}
          value={this.state.articleBody}
          selectedTab={this.state.tab}
          generateMarkdownPreview={markdown =>
            Promise.resolve(this.converter.makeHtml(markdown))
          }
        />
         <IonInput type="text"  placeholder="Enter Tags" class="border-input"  onIonChange={this.tagsChange}></IonInput>
         <IonButton expand="block" onClick={this.submitArticle}>Submit Article</IonButton>        
      </form>

Creating a Build Using Capacitor

We will use run build to build our React project:

npm run build

We will then use Capacitor to copy the files:

npx capacitor copy

Now, we will need to compile the project natively:

npx capacitor open android|ios

Final Thoughts

My mileage while developing Conduit varied a lot. Conduit doesn't have a spec for mobile, so it took a while to figure out the best workflow.

We can improve the app by using middleware like Redux, using skeletons loaders at places, integrating infinite scroll and handling errors better. To complete the app experience, we will have to modify the backend so it can handle push notifications. A notification system makes sense if you receive a new follower or if a person you are following publishes a new post.

As far as Ionic React is concerned, it felt like I was developing a React web application using a set of predefined components. Components like IonInfiniteScroll are still WIP and we can hope to get them soon. Personally, I missed the tight integration of the framework and the side menu template. We can expect full Ionic CLI and Cordova support in the future.

Android users can check the app here.

Lastly, if you're building an application with sensitive logic, be sure to protect it against code theft and reverse-engineering by following our guides for React and for Ionic.

Originally published by Karan Gandhi in the Jscrambler Blog.

Create a File Storage Mobile App with NativeScript 5

Karan Gandhi — Mon, 04 Mar 2019 17:34:24 +0000

In this article, let's create a small demo project with NativeScript 5. To start with, let’s set up a scenario for the demo.

SimpleFileTransfer is a virtual file locker. Users can sign up for the service and get 100 MB of free virtual storage space. Users can then download and upload files on a server. Users will be able to increase their storage space by filling a form.

Let’s jot down the App functionalities before moving ahead:

Signup: User can signup for the app.
Login: Authenticates user.
Details Page: Provides user details like current quota and total space. Also, we can display a list of files.
Download file: Download file from the server to a device.
Upload file: Upload files from a device to the server.
Increase Quota: Increases storage quota of a user by a specified amount.

You can find the whole code on GitHub.

Structuring the Backend

The backend must provide the functionalities of managing routes, providing basic authentication and storage, and facilitating file transfers.

Based on the requirements above, we will be using the following stack:

Node: Server
Express: Middleware
Sequelize: ORM Middleware
SQLite: Database

We will also be using libraries like multer and bcrypt for specific functionalities that will be explained later on.

Initializing the Backend Project

We will be using express-generator to set up the project. Install express-generator globally using:

npm install express-generator -g

Start a new project using the command:

express file-server

Navigate to the file-server directory and install the dependencies using npm install. Also, install the following dependencies:

npm install multer async sequelize sqlite3 body-parser bcrypt --save

Additionally, we will be creating some extra folders for:

Database: Storing SQLite DB & DB script.
Model: Storing Models.
Upload: Temporarily storing uploaded files.
Storage: storing file for specific users.

Starting with Sequelize

Sequelize is an ORM middleware for SQLite, MySQL, PostgreSQL and MSSQL. For small projects, it’s convenient to use the Sequelize + SQLite combo.

In our current scenario, we require only one Model. We will define our model user as follows:

   const User = sequelize.define('user', {
   uid: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true },
       username:  { type: Sequelize.STRING, unique: true },
       password: Sequelize.STRING,
       quota: {type: Sequelize.INTEGER, defaultValue: 104857600},
       createdAt: Sequelize.DATE,
       updatedAt: Sequelize.DATE,
     })

We can use Sequelize's Model.sync to initialize Models Table in a database. To initialize users table, we will be using the code below.

     User.sync({force: true}).then(() => {
        // Table created
      });

We will store the user model in the user.js file in the model folder.

Signup & Login

This part is pretty straightforward. For signup, the server accepts a username and password and stores it in the database. We will be using the bcrypt library to salt the passwords. As shown below, we are salting the password 10 times before storing it in the database. We are using Sequelize's Model.create to store the value. Once a user is created, we will create a directory on our server for his uploads.

The code is as below:

     router.post('/', function(req, res, next) {
       console.log(req);
       bcrypt.hash(req.body.password, 10, function(err, hash) {
         User
         .create({ username: req.body.username, password: hash })
         .then(user => {    
         if (!fs.existsSync('storage/'+user.get('uid'))){
         fs.mkdirSync('storage/'+user.get('uid'));
         } 
           res.send({status: true, msg: 'User created', uid: user.get('uid')});
         }).catch(err => {
           res.send({status: false, msg: err });
         })
       });
     });

For login, the server accepts a username and password and validates it against the database. We are using Model.findAll to get the database record. We use bcrypt.compare to compare passwords.

   router.post('/', function(req, res, next) {
     console.log(req);
     User.findAll({
       attributes: ["username", "password"],
       where: {
         username: req.body.username
       }
     }).then(dbQ => {    
         if(dbQ.length > 0) {
           bcrypt.compare(req.body.password, dbQ[0].dataValues.password, function(err, result) {
             if (result == true){
               res.send({status: true, msg: 'Login Success'});
             } else {
               res.send({status: false, msg: 'Incorrect Password'});
             }            
         });
       } else {
         res.send({status: false, msg: 'User not found'});
       }         
     });
   });

Defining the Users Route

An authenticated user is allowed to perform the following functions:

Upload file
Download file
Get Details
Increase quota

Let's define the routes for those functions:

Upload: POST /users/:id/upload
Download: GET /users/:id/download/:filename
Details: GET /users/:id/details
Increase Quota: POST /users/:id/increasequota

Uploading a File to the Server

We will be using multer to handle uploads.

The multer library is useful to handle multi-part form data. Initially, we will be uploading the file to the uploads folder. Then, the file will be moved to /storage/uid folder where uid is user id.

   var storage = multer.diskStorage({
     destination: function (req, file, cb) {
       cb(null, 'uploads/')
     },
     filename: function (req, file, cb) {
       cb(null, file.originalname )
     }
   });

   router.post('/:id/upload', upload.single('fileparam'), function(req, res, next) {
     if (!req.file) {
       console.log("No file received");
       return res.send({
         success: false,
         msg: "Error Uploading files"
       });
     } else {
       console.log('file received');
       fs.rename('uploads/'+ req.file.originalname, 'storage/'+req.params.id+'/'+req.file.originalname, function (err) {
           if (err) {
                console.log(err);
               return;
           }  
           return res.send({
             success: true,
             msg: "File Uploaded"
           })   
       });   
     }
   });

The upload.single method is used for handling uploads. This route is expecting a file with name fileparam in the URL call. This is quickly done by adding a name attribute an HTML form. We will need the name attribute app side.

Download Route

ExpressJS provides us with a function to set the download route, conveniently called download.

This is the logic we are following:

A user logs into the app.
He selects a file and initiates the download.
The server receives a request with userid and filename.
The server sends the file back to the user.

The code for the route is below

    router.get('/:id/download/:filename', function(req, res, next) {
         const file = 'storage/'+req.params.id + '/' + req.params.filename;
         res.download(file);
    });

Increase User Quota Route

We will be invoking Model.update to adjust the quota. By default, we have 104857600 bytes — which is equivalent to 100 MB — assigned to each user. You can find the query below.

   router.post('/:id/increasequota', function(req, res, next) {
     User.update({
       quota: req.body.quota,
     }, {
       where: {
         uid: req.params.id        
       }
     }).then(response => {
       res.send({status: true, msg: "Quota Increased"});
     }).catch(err => {
       res.send({status: false, msg: err});
     }); 
   });

User Details Route

This is a route which we will be using for fetching multiple data, such as:

Storage Limit of user: from the DB,
Current File Space occupied: from the /storage/userid directory,
Space Remaining: it's just Point 1 - Point 2,
File List: list of Files,

We can fetch the storage limit of a user using Model.findAll. For fetching file names and storage space, we are using fs .readdir, fs.stat and async.

   function getStorageSpace(relpath) {
     let space = 0;
     let fileNames = [];
     let promise = new Promise(function (resolve, reject) {
       fs.readdir(relpath, function (err, items) {
         if (err){
           reject(err);
         }
         fileNames = items;
         let filesArr = items.map(function (val) {
           return relpath + '/' + val;
         });
         async.map(filesArr, fs.stat, function (err, results) {

           for (let i = 0; i < results.length; i++) {
             if (err) {
               reject(err);
             }
             space = space + results[i].size;
           }
           resolve({fileNames: fileNames, space: space });
         });
       });
     });
     return promise;
   }

   function getStorageLimit(uid){
     let promise = new Promise(function (resolve, reject) {
       User.findAll({
         attributes: ["quota"],
         where: {
           uid: uid
         }
       }).then(dbQ => {

         if(dbQ.length < 1) {
           reject("Quota Not Found")
         } else {
           resolve(dbQ[0].dataValues.quota);
         }     
       }).catch(err => {
         reject(err);
       });
     });
     return promise; 
   }

   router.get('/:id/details', function(req, res, next) {
     let it;
     let relpath = 'storage/'+req.params.id;
     Promise.all([getStorageSpace(relpath), getStorageLimit(req.params.id)]).then(result => {

       res.send({storageLimit: result[1], occupiedSpace: result[0].space, fileNames: result[0].fileNames, remainingSpace: result[1]- result[0].space});
     })
   });

N.B.: The code works on assumption that user is not allowed to create a subdirectory in his folder.

The code for enforcing storage limit will be discussed later in the article.

NativeScript App

For the app side, we will be taking an alternative approach. A demo project based on Angular-Blank template will be shared with users. A significant part of this article will cover details about plugins concerning the plugin functionalities.

Consuming Web Services

We are consuming data from simple web services for Login / Signup / User Details Page.

As mentioned in the previous article, we can access these webservices using the HttpClient Module. The basic steps are as follows:

Import NativeScriptHttpClientModule in the PageModule.
Import HttpClient and HttpHeaders in Component or Provider.
Consume the URL as you will in an Angular application.
We will set Content-Type header to application/json.

For the JavaScript/TypeScript templates, we can use the NativeScript Core http module. The http. getJson function provides the required framework to consume webservices. Alternatively, we can also use the fetch module.

As a response from the server, we will be receiving the uid of a user. After authentication, we need to store the uid so we can allow a mobile user to access /users/uid route.

Storing Data

The NativeScript framework doesn't have any method to store data persistently. We can add that functionality using plugins. We are going to look at two of these plugins.

nativescript-sqlite: This plugin provides an interface for the SQLite library. This works well if your app needs to store a large volume of records. Install it with:

tns plugin add nativescript-sqlite

nativescipt-localstorage: This plugins provides a key value API for string data, similar to window.localstorage. This works well if your app doesn't have lot of records. Install it with:

tns plugin add nativescript-localstorage

The demo app will be using nativescript-localstorage.

Uploading Files from a Device to a Server

Let's break this functionality into subtasks:

Choose Files from the device.
Get File Path.
Upload File over uploads WebService.

To choose a file and get a file path, we will be using the nativescript-mediapicker plugin. The plugin has multiple modes and we can customize it for specific use cases. You can check the plugin documentation here.

To select a file, first, we need to define extensions. This is different for both OSes.

For Android devices, we have to use file extensions based on mime types like let extensions = ["xlsx", "xls", "doc", "docx", "ppt", "pptx", "pdf", "txt", "png"]
For iOS devices, we have to define extensions from list for Unified Type identifiers: let extensions = [kUTTypePDF, kUTTypeText];

You can read more about UTIs here and here.

The code for invoking filepicker is as below:

   let options: FilePickerOptions = {
       android: {
           extensions: extensions,
           maxNumberFiles: 1
       },
       ios: {
           extensions: extensions,
           multipleSelection: false
       }
   };

   let mediafilepicker = new Mediafilepicker();
   mediafilepicker.openFilePicker(options);

   `mediafilepicker.on("getFiles", function (res) {
       let results = res.object.get('results');
       console.dir(results);
   });

   mediafilepicker.on("error", function (res) {
       let msg = res.object.get('msg');
       console.log(msg);
   });

   mediafilepicker.on("cancel", function (res) {
       let msg = res.object.get('msg');
       console.log(msg);
   });`

As above, we will receive the filepath of a file in the getFiles event.

We will send the file to the server using the nativescript-background-http plugin. You can read about the plugin here.

Earlier, we defined the /users/:id/upload route. As mentioned earlier, our server is expecting the file in the attribute named fileparam.

The background http provides us with two functions: uploadFile and multipartUpload. Since we need to set the name attribute, we will be using the multiPartUpload function.

    let session = bgHttp.session("image-upload");
    let request: bgHttp.Request = {
        url: Config.apiUrl  + '/users/' + localStorage.getItem('uid') + '/upload'   ,
        method: "POST",
        headers: {
            "Content-Type": "multipart/form-data"
        },
        description: 'FileName'
    };
    let params = [{
        name: 'file',
        filename: path
    }];
    let task: bgHttp.Task = session.multipartUpload(params, request);
    task.on("error", (e) => {
        reject(e);
    });
    task.on("complete", (e) => {
        resolve(e);
    });

Downloading a File to the Device

We will be using the core file-system, platform and utils modules to achieve the result. Both Android and iOS handle downloads differently. We will be using isAndroid and isIOS variables from platform module to segregate the code.

The file-system module provides us with a knownFolders sub-module. Three predefined folders for both Android and iOS are available:

knownFolders.currentApp()
knownFolders.documents()
knownFolders.temp()

Additionally, an iOS sub-module provides us with some other predefined folders. E.g:

knownFolders.ios.download
knownFolders.ios.sharedPublic

iOS Code

On an iOS scenario, this is straightforward:

Show a list of server files.
Download the files to the documents folder.
List downloaded files in a separate view
Use the utils.openFile function to open the file.

To download the files, we will be using the http module of the NativeScript framework. The getFile function can be used to fetch files from the server and save them to a specific file location. The snippet for iOS is below:

      let filePath: string = path.join(knownFolders.documents().path, fileName);
           getFile(download_url + fileName, filePath).then((resultFile) => {
                   // The returned result will be File object
   }, (e) => {
       console.log(e);

Once the file has been downloaded, we can use the openFile function from the utils module to open a file on iOS.

Android Code

The Android side of coding is a bit trickier. The locations of the knownFolders module are as below.

currentFolder: /data/data/:appid/files/app
documents: /data/user/:androiduser/:appid/files
temp: /data/user/:androiduser/:appid/cache

As you can see, all the folders are located in /data. /data is inaccessible to normal users. Furthermore, external apps won't be able to access the files in those folders. Also, there is no openFile function for Android.

As of now, the best we can do is:

Show a list of server files.
Download a file to a user accessible location.
List the files present in the location.

To implement the functionality, we will be using a bit of native code.
Before moving ahead, we will have to install tns-platform-declarations with:

npm i tns-platform-declarations --save

Create a reference.d.ts file in the root folder and add the following lines:

`/// <reference path="./node_modules/tns-platform-declarations/ios.d.ts" />`
`/// <reference path="./node_modules/tns-platform-declarations/android.d.ts" />`

You can check the readme for more details.

Android OS provides us with a function to access the external storage.

We will be using the constant DIRECTORY_DOWNLOADS and the function getExternalStoragePublicDirectory to create a publicly accessible download location.

We will append a path “SimpleFileTransfer” to create a custom folderPath and filePath.

   const androidDownloadsPath = android.os.Environment.getExternalStoragePublicDirectory(android.os.Environment.DIRECTORY_DOWNLOADS).toString();
   const androidFolderPath = fs.path.join(androidDownloadsPath, "SimpleFileTransfer");
   const filePath: string = fs.path.join(androidFolderPath, fileName);
   getFile(download_url + fileName, filePath).then((resultFile) => {
                   // The returned result will be File object
   }, (e) => {
       console.log(e);

If you check your file explorer, a new directory will be created in the Downloads folder called SimpleFileTransfer. You will find all the files downloaded there.

Listing Downloaded Files

We will be using the file-system module. The Folder class of the file-system module has a getEntities function which allows us to list files in a folder. As with fs.readdir in Node.js, we can only list the files.

For iOS, the path is

const  folderPath:  string  =  fs.knownFolders.documents().path;

For Android, the path is

const androidDownloadsPath  =  android.os.Environment.getExternalStoragePublicDirectory(android.os.Environment.DIRECTORY_DOWNLOADS).toString();

`const  folderPath=  fs.path.join(androidDownloadsPath, "SimpleFileTransfer");`

To access the Folder functions, we define a folder using

let  internalFolder  =  fs.Folder.fromPath(folderPath);

Then, we use getEntities to get a list of files:

   internalFolder.getEntities()
               .then((entities) => {
                   // entities is array with the document's files and folders.

                   entities.forEach((entity) => {
                   let  fileSize  =  fs.File.fromPath(entity.path).size;
                       this.listArray.push({
                           name: entity.name,
                           path: entity.path,
                           lastModified: entity.lastModified.toString(),
                           size : fileSize
                       });
                   });                  
               }).catch((err) => {
                   // Failed to obtain folder's contents.
                   console.log(err.stack);
               });

Additionally, we have used the size property of File class to get file size.

Enforcing Storage Limit

The storage limit can be enforced in two ways:

Upload file to the server --> Checking remaining space --> Reject the upload on the server side.
Check remaining space using webservice --> Check file size --> Cancel the upload on the app side.

To enforce the former, we can modify the upload route as below:

   Promise.all([getStorageSpace(relpath), getStorageLimit(req.params.id)]).then(result => {
     if (result[1] - result[0].space > req.file.size){
       fs.rename('uploads/'+ req.file.originalname, 'storage/'+req.params.id+'/'+req.file.originalname, function (err) {
         if (err) {
           return res.send({
             success: false,
             msg: "Error Uploading files"
           });
         }  
         return res.send({
           success: true,
           msg: "File Uploaded"
         })   
     });
     } else {
       return res.send({
         success: false,
         msg: "Storage Limit Exceeded"
       });
     } 
     })

To enforce the latter, we get the file size of the file selected by the mediafilepicker plugin and check it against the space remaining using the details webservice.

`let  fileSize  =  fs.File.fromPath(results[0].file).size;`

    if(fileSize < remainingSpace){
    // Send To server
   }`else {
   // alert user about lack of space
   }

Closing Thoughts

This demo covers quite a few different concepts.

We divided the solution into a series of functionalities. We used core NativeScript for UX, interacting with the backend, file system management, and Routing. We extended the framework by installing plugins for functionalities like picking files. Going further, we used a bit of native code for solving a specific problem.

Using NativeScript allowed us to develop the app faster for both platforms as against individually.

If you want to learn how you can secure your NativeScript source code against theft and reverse-engineering, be sure to check our tutorial.

This article was originally published on the Jscrambler Blog by Karan Gandhi.