Application Security

This topic describe the security of applications which run on Samsung devices.

Overview

Security is becoming an important issue with the increase of various smart devices. In order to protect data from users and businesses, Samsung devices are enhancing security in several layers, from hardware to software. As Samsung device applications are also software driven by Samsung, the security needs to be taken into account.

Samsung device applications can store important information such as code and key values and personal information of the user, which is an important resource that must be protected.

These resources can be leaked due to a variety of reasons, such as a simple mistake by a developer or hacking by an attacker. In order to safeguard this, Samsung device applications need to be developed according to Secure by Design. In particular, the personal information of the
user should comply with the policy related to the personal information for each country.

Secure by Design

All software within the devices developed by Samsung are based on the Secure Development Lifecycle (SDL) model, and development step is divided into analysis, design, implementation, and testing, so vulnerability should be removed by performing a security review at each step.

From the same point of view, applications operating on Samsung device should maintain the same security level. For this, we recommend that you consider security in the application development phase by referring to the following step-by-step security review.

  • Security in the analysis/design phase: You should identify important information that is stored and transferred and ensure that the information is handled safely.
    • If you receive user input, you should review that you do not require more information than you need, and there is no issue with the input format.
    • You must identify the important information to be used and ensure that the information is displayed on vulnerable areas in the flow of the program.
    • In particular, when transmitting important information outside the device, you need to ensure that it communicates with the specified server through a secured channel.
    • At the time of designing, you must first define important information that needs to be protected and design it in a proper manner to protect it.
  • Security in the implementation phase: It must be implemented in compliance with security rules to prevent information in the software from being leaked through known vulnerabilities.
    • Important information obtained in the design phase should be stored by applying security techniques such as encryption and make sure that it does not exist in plain text within the program.
    • Establish secure coding rules for each language and proceed with development accordingly.
    • You must use only the minimum permissions required and notify the user of the permissions you use.
    • You should make sure that the security channel is properly set on the network, and the latest version of the technology is applied.
    • If you use encryption algorithms, you must use them securely using verified standard algorithms where vulnerabilities are not reported.
  • Security in test phase: Security checks must be performed before deployment to prevent security issues and maintain security through maintenance after deployment.
    • Before deployment, it is necessary to verify that there is no issue with analysis, design, and implementation when actually operated through simulated hacking, packet checking, etc.
    • After deployment, if a new vulnerability is found or a modification occurs in the security check, it must be patched and applied to all users as soon as possible.

Security Review Process

In order to maintain the security of the application ecosystem, Samsung is performing security checks on the submitted applications.

Figure 1. Application security review process

Figure 1. Application security review process

Samsung checks the risk or misuse cases that may occur due to the submitted applications, and if there is an issue, the deployment process can be stopped and the application submitter can be advised to fix it.

Application Security Guide

This section provides basic security guidelines to consider in the development of applications. For a safe and reliable application running environment, we recommend that you proceed with the following points in the development phase.

Data Protection

Three key factors for data protection are confidentiality, integrity, and availability. If an application sends or stores sensitive information, the application must encrypt data stored on these devices and protect it from attackers.
It is very important to protect sensitive data such as user credentials or personal information in application security. If the mechanism of the operating system is not used correctly, sensitive data can be unintentionally exposed.

Definition of sensitive data:

  • Personally Identifiable Information that can be exploited for identity theft: for example, Resident registration number, social security number, credit card number, bank account number, health information, etc.
  • Sensitive data that can lead to loss of honor and loss of money if leaked
  • All data that must be protected for legal or compliance reasons.
Table 1. Data Protection security description and reference links
Security Item Description
Data Protection Sensitive data, such as passwords or PIN data, should not be exposed through the user interface.
The key values used by the application must be hardcoded or not stored in plain text.
Sensitive data should not be stored in an application container or external storage.
Sensitive data should not be recorded in the application log. - Sensitive data should not be shared with third parties unless it is necessary in the architecture.
Sensitive data should not be shared with third parties unless it is necessary in the architecture.
Keyboard cache must be disabled from the text input that processes sensitive data.
Sensitive data should not be exposed even during internal communication.
You should ensure that the data stored in the client-side storage (Ex: HTML5 local storage, session store, IndexedDB, regular cookie, or flash cookie) does not contain sensitive data.
Make sure that you have provided clear T&C for the collection and use of the provided personal information and that you have provided selective consent to the use of that data before you use it.
Reference links:

Authentication

If there is a feature to log-in to the remote service by the user, it must be configured through security design. Even when most of the logic is operating on a remote service, the device must also meet security requirements on how to manage user accounts and sessions.

Table 2. Authentication security description
Security Item Description
Authentication If the application provides remote services to the user, user name and password authentication must be performed from the remote service.
If you use Status Storage Session Management, the remote service must authenticate the client request using the randomly generated session identifier without sending the user's credentials.
If using stateless token-based authentication, the remote services must provide signed tokens using security algorithms.
When a user logs out, the remote service must end the existing session.

Access Control

An application can access a resource only if it has access to it.

Table 3. Access Control security description and reference links
Security Item Description
Access Control Application must require only the minimum access required.
Application must use the privilege that match the permissions and specify the Privileges used.
When accessing user data, make sure that the principle of minimum access privilege requirement is followed. Applications must have access to APIs, data files, URLs, controllers, directories, services, and other resources with minimal access required.
You should verify and process all input from external resources and users. This should include data received through the UI, a user-defined URL, inter-process communication (IPC), etc.
If an application uses a completely unprotected custom URL, you should not export sensitive information.
Important data or APIs must be protected from user access other than data owners.
Reference links:

Communications

When the network is used, the application should not display the transmitted/received content using
a secured channel.

Table 4. Communications security description and reference links
Security Item Description
Communications Data must be encrypted on the network using TLS(Transport Layer Security). Security channels must be used consistently throughout the application.
The setting of the security channel must be configured to protect information safely.
The data being transmitted must be protected from being snatched/taken over in the middle. (ex. Defence against Man In The Middle attack)
Reference links:

Input Validation

You must defend the command insertion attack through validating the validity of input value.
Input value validation should be considered at all stages of development.

Table 5. Input Validation security description and reference links
Security Item Description
Input Validation Input values must process the data based on type and content, applicable laws, regulations and other policy compliance, and define how to handle it.
You must ensure that input validation is performed on a trusted service layer.
You need to check whether it protects against parameter attacks such as mass parameter allocation attacks or unsafe parameter allocation.
All possible input values (e.g. HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc.) must be checked using validation (ex. whitelist).
You should check whether the values entered are in the correct form in well-defined schemas, including allowed characters, lengths, and patterns.
The URL redirection and forward should display a warning that only whitelist targets are allowed or that you are connecting with potentially untrusted content.
Make sure you use memory safety strings, secure memory copy, and pointer calculation to detect or prevent stacks, buffers, or heap overflows.
In order to prevent integer overflow, you need to make sure that sign, range, and input validation techniques are used.
Reference links:

Password Management

In case of application with different user password, security settings are required for them.

Table 6. Password Management security description and reference links
Security Item Description
Password ManagementYou must ensure that the password does not contain spaces and cut/copy is not performed.
In the Password Change feature, you should check that the user's current password and new password are required.
It is recommended to provide a password strength meter so that users can set a stronger password. It is also recommended to provide rules that limit allowed character types (Uppercase letter, numeric, special characters).
You should check that it is recommended to change your user password within the right due date.
Do not store the user password in the application's properties or settings file in plain text or recoverable form.
Passwords must be stored, transferred, and compared in a hashed state using a standard hash function.
To prevent random attacks, you should use the login limit(number of login) or CAPTCHA.
Default password should not be generated.
Make sure you do not show the key information, like passwords in the log.
Reference links:

Session Manager

A session is a technique for controlling and maintaining the status of a user or device
interacting with one user in a Web application. A session has a unique value for each user and
cannot guess or share that value.

Table 7. Session Manager security description and reference links
Security Item Description
Session ManagerYou should check that the session token is not exposed/displayed in the application's URL parameter or error message.
Make sure the application generates a new session token from user authentication.
You should check that the session token is stored using properly secured cookies or security methods.
You should check that a session token is generated using a standard encryption algorithm.
Make sure the session is not reused by verifying that the session token is invalid when logout and session expires.
Reference links:

Error Handling

The purpose of error handling is to allow applications to provide security events related to
monitoring, status check, and increase in permission, and not just creating logs.

Table 8. Error Handling security description
Security Item Description
Error HandlingYou must ensure that common error handling formats and access method are used.
You must make sure exception handling is used on the code base to explain expected and unexpected error conditions.
You must ensure that other error handlers that can prepare all unprocessed exceptions are defined.
In case of an error, you must make sure that the message shown to the user does not contain application-related technical or sensitive information. We recommend using separate error codes for error support..

Release

Check the following before releasing the application.

Table 9. Release security description
Security Item Description
ReleaseApplication must be signed and distributed with a valid certificate, and the private key must be properly protected.
Debugging code and developer support code (test code, back door, hidden settings, etc.) must be removed. Deployed applications should not output or record detailed errors or debugging messages.
Libraries and frameworks etc. used by applications should be checked for known vulnerabilities.
The equipment used for release must be able to respond to external threats (viruses, hacking, etc.).
It should be built in release mode. A separate debug message should not be left from the application.
If you include binary, debug information should be removed.
If a vulnerability occurs after release, you should update the application as soon as possible and always keep the latest version.