Security Guidelines Handbook

Best Practices:

POJO:

• Size validations on strings

• Regex validations wherever applicable

• @SafeHtml or custom annotation to block any html code in string fields

File Upload:

• Rename files before storing 

• File should not be stored in application folder

• Only required file extensions should be whitelisted

• Magic number should be checked for the file using library like Apache Tika

API:

• _create API should have some sort of rate throttling on it

• _search API should return results in paginated manner

• Before whitelisting any API all use cases must be properly thought through(check if it can lead to any security loophole)

• Some sort of IP based throttling should be applied on whitelisted API to prevent DDoS attack

• Role action mapping should be thoroughly checked especially in case of CITIZEN role, only API required from Citizen UI should be mapped to CITIZEN role

• Sensitive information should not be send in url (as a query param) instead should be send in request body or in headers

Coding Practises:

• Error handling should be proper. Custom Exception should be thrown instead of returning the complete stack trace

• For generating hash use strong hashing algorithm like SHA-2

• Avoid capturing Java.Lang Security Exception

• Don’t throw exceptions in finally block

• Always close Input and Output resources in finally block

• Avoid using external input directly to create pathname that is intended to identify file or directory

• Scan for potential infinite loops. Avoid executing loops using user input directly

• Check for SQL injection. Always use prepared statements instead of directly creating query as string from input parameters

• Insead of standard pseudo-random generators use cryptographic PRNG

• Sensitive and Environment dependent properties like DB host and password should not be hardcoded, and should be overwritten during deployment

• Avoid logging sensitive information or it’s exposure through error messages

• Do not compare class objects with getName() or getSimpleName() methods

• The setter method for an identifier property (id or composite-id) should be private

• Do not allow external input to control resource identifiers

Detailed Guidelines:

Privilege Escalation

Role Action mapping should be in accordance with the business requirements. No role should have access to resources which are not required by that role on UI. In case of CITIZEN role extra precaution should be taken. If there is a business requirement for user based access to entities instead of role based access, validations should be added at module level to verify the user id.

There is a possibility of horizontal/vertical escalation in case of workflows. We have fixed this issue by validating the logged in user and the workflow item's owner. Allowing access if the logged in user and the workflow owner are the same.

Failure to restrict URL Access

We use pre-signed urls, so we cannot restrict the access to the file if someone gets the url. As a security measure we should restrict the value of the url validity to as minimum as possible. The value is configurable and can be overwritten in helm charts using the following property:

Insecure direct object references (IDOR)

API’s like /user/_search which exposes personal data of users shouldn’t be directly exposed. We have removed access to the API from UI, the user information of logged in user can be instead fetched from /user/oauth/token which is now enhanced to return the required info.

Malicious file upload leads to Cross Site scripting

Unrestricted file upload is a serious security risk. To tackle this problem we have bunch of security validations. The file extension, content and content-type in header are all validated. We define the allowed extensions and there corresponding content-type as a map and is configurable using the following property:

Improper Authentication

Before adding endpoints in whitelist or mixed endpoints list all security implications should be thought through, as there will be no authentication or authorisation of the request. It’s a good practise to add origin based rate limiting to avoid DDoS attack

Missing Account Lockout

Account locking mechanism is provided in digit platform and should be never be disabled. It helps in mitigating brute force attacks.

Request Throttling Attack

All _create API’s should have some sort of rate throttling to avoid DDoS attack that can overwhelm the system. The rate limiting can be achieved by configuring the endpoint in limiter.properties of zuul. Following is a sample configuration:

Weak Encoding Mechanism

Client secrets shouldn’t be sent in Base64 encoded format from UI, only for server to server call the secret can be sent in Authorization header in Base64 format. We have removed client secret from Authorization header in Digit Platform

Sensitive Information in URL

Avoid sending sensitive information in url as query param. Instead it can be sent either in request body or in headers. For example in previous Digit version in _logout API, authToken was sent in query param as below:

The API is now enhanced to accept the authToken in Request Body as below :

Lack of Automatic Session Expiration

Proper expiry time should be set for authToken validity. In case the authToken get’s stolen, it can be exploited only till the time the token is valid. The validity can be configured from the following two property in helm charts:

Concurrent Session

Multiple login using same user name and password should be avoided. Due to business requirement, we currently have not implemented the feature in Digit

Improper Error Handling

Error should not expose any sensitive data or detailed error message to the end user. Hackers can use these information to attack the system. Use of e.printStackTrace() should be avoided instead the error should be logged using logger. Always return custom error message to the end user.

Improper Input Validation

All user inputs should be validated before storing in DB. If not done attacker could use malicious input to
modify data or possibly alter control flow in unexpected ways, including arbitrary command execution. In Digit we use annotations to validate user data Following is a sample validation using annotations:

Mail Command Injection

Validate any user input that is used to create email subject line from user input. And encode special characters after proper canonicalization, and in particular, any line break (CR / LF) characters
in the input, that attackers may use to inject unexpected headers in the mail message sent to the server.

Use of hardcoded credentials

Always overwrite sensitive values in application.properties during deployment. Never use hardcoded credentials. Generally the sensitive values in application.properties will be like the DB user name and password, secrets etc. In Digit all the sensitive values are overwritten using kubernetes ConfigMaps. Following is examples of properties which we overwrite:

Use of sensitive information into configuration file

Make sure any sensitive information like authToken or secrets are not exposed in any configuration file.

Exclude unsanitized user input from format strings

If the format string is constructed with untrusted input, an attacker may produce unexpected application
behavior. It may cause an exception such as java.util.MissingFormatArgumentException to be thrown (which, if not catched, may lead to a denial-of-service condition), or information leak. Do not compose format strings from untrusted input. The arguments, except format string, to the formatting
methods, are data, and could contain format specifiers without any unexpected behaviour.

HTTP Parameter Pollution

Sanititze user input before using it in HTTP parameters. Concatenating unvalidated user input into a URL can allow an attacker to override the value of a request parameter

Standard pseudo-random number generators cannot withstand cryptographic attacks

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical
properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. In latest release of Digit we have taken care of it by following replacement:

replaced with

Weak cryptographic hash

Use of weak hashing algorithm could compromise the original value. For example, if an authentication system takes an incoming password and generates a hash, then compares the hash to another hash stored in the authentication database, then the ability to create a collision could allow an attacker to provide an alternate password that produces the same target hash, bypassing authentication. It is recommended to use SHA-2 instead of SHA-1.

Insecure SSL configuration

The problem with flawed SSL configuration is that it may allow man-in-the-middle attacks and other issues. Following is a reference implementation:

Improper Neutralization of CRLF Sequences in HTTP Header

An attacker could inject line separators (CR/LF sequences) that could split the response message generated by the software into two messages. The second response is completely under the control of the attacker (intermediate web proxies may cache it), with could produce multiple conditions (web defacement, cache poisoning, cross-site scripting, or page hijacking). It is recommended to strip out any input which contains the %0d%0a URL encoded characters in HTTP request headers.

Avoid Capturing Java.Lang Security Exception

Security exceptions are related to security breaches such as denied permissions and improper use of the API. The code should not catch security exceptions except in specific cases where it may be necessary to mask some of these exceptions, for example, in the case of a log-on failure.

Always normalize system inputs

Not validating and normalizing the user input can lead to execution of arbitrary code. An application’s strategy for avoiding cross-site scripting (XSS) vulnerabilities may include forbidding <script> tags in inputs. Such blacklisting mechanisms are a useful part of a security strategy, even though they are insufficient for complete input validation and sanitization. When implemented, this form of
validation must be performed only after normalizing the input. We handle this by annotating all string user input field with @SafetHtml annotation

Avoid the Command Throws within Finally

Throwing an exception from within a finally block will mask any exception which was previously thrown in
the try or catch block, and the masked's exception message and stack trace will be lost.

Close Input and Output resources in finally block

Failure to properly close resources will result in a resource leak which could bring first the application on to their knees. Always closes any input stream in finally block.

Cross Site Request Forgery

CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim. A successful CSRF exploit can compromise end user data and operation in the case of a normal user. If the targeted end user is the administrator account, this can compromise the entire web application. For this attack to be successful, user must be logged into the application.

We have fixed these CSRF issues by adding a CSRF Filter in the security filter chain. All requests mapped to pass through the csrf filter and the csrf token validation happens in the filter. All the requests except GET required to pass a csrf token.

applicationContext-security.xml

applicationSecurityContext-<modulename>.xml

ex: applicationSecurityContext-egi.xml

Cross Site Scripting - Stored

Cross-site scripting is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other.

1. We have added a Validation Interceptor to validate the user input for all struts requests. Used OWASP AntiSamy policy to validate the user input.

2. Added entity level validation annotations to validate the entities used in spring requests.

struts.xml

XSSValidator.java

Insufficient Cookie Attributes

The application was missing the “Secure” cookie attribute which was carrying the session information (SessionID). The Secure attribute makes sure that the cookie will only be sent with requests made over an encrypted connection and an attacker will not be able to steal cookies by sniffing.

Added the missing secure cookie attribute

Code Injection

Application accepts the unvalidated user input. Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Fixed this issue by sanitizing the user input and removed eval().

Exclude unsanitized user input from format strings

Used format specifiers (%s, %d, %c etc) while constructing format strings instead of adding using the additional operator.

Avoid data submissions to non-editable fields

Fixed this issue by using WebDataBinder.setDisallowedFields() to disallow id in request binding.

Potential Infinite Loops

Most of the loops present in the third party (YUI) libraries. So we have not changed this.

Avoid dangerous J2EE API, use replacements from security-focused libraries (like OWASP ESAPI)

Replaced the dangerous J2EE API with OWASP Enterprise Security API (ESAPI) equivalent APIs

pom.xml

Do not allow external input to control resource identifiers

Sanitized the user input to fix this issue.

The setter method for an identifier property (id or composite-id) should be private

Changed the idetifier's setter to private/protected

Frontend - Android APK:

URL Redirection to Untrusted Site ('Open Redirect')
It was observed that the application redirects the user’s browser to a URL provided in a user request, without proper validation of the user input.
So it is recommended not to allow external input to modify the target URL. Perform a strict validation on the external input to ensure that the final URL is valid, appropriate for the application, and authorized

Exported activity must require permissions

Activity can be exported by setting its attribute exported=true, or adding an intent-filter not setting attribute exported=false. To receive or bind them a permission must be required, otherwise any apps can access the activity

It is recommended to set attribute exported=false or remove the intent-filter as default value without the intent is considered as false.

Potential code injection via WebView.addJavaScriptInterface()

Exposing Java objects to JavaScript could have negative security implications, such as code injection (allowing access to native phone functionality like sending SMS to premium numbers, accessing account information and sensitive data, etc.) Such code injection may, for example, do something like this (to launch a system command): exposedObj.getClass().forName('java.lang.Runtime').getMethod('getRuntime', null).invoke(null, null).exec(cmd)
To avoid this security issue, you may remove addJavaScriptInterface() when possible

Either

(1) remove the JavaScript/Java bridge (addJavascriptInterface) or

(2) make sure that the content loaded by WebView is really trusted (and place a suppression for violations when needed), or

(3) upgrade to API level 17 or higher and place a @JavascriptInterface annotation on allowed public methods, as in the following code

Intent Manipulation

The application allows the user input to control Intent parameters that could enable an attacker to control the behavior of the subsequent activity
If untrusted input is inserted into certain parts of an Android Intent, without proper sanitization, a malicious user or app could force, via the tainted Intent, the execution of unintended code or inject malicious data in the vulnerable app. Certain Intent properties could change the expected semantics of the Intent, like setAction(), setClass(), setClassName(), or setComponent(). If the Intent is used to start an Activity or Service, for example, the attacker may change the expected element launched, with potential nefarious consequences
It is recommended to validate untrusted input that does not proceed from app-controlled resources, and in particular user interface fields and other Intents coming from other apps.

Do not release debuggable apps

It was observed that android:debuggable is set to true. Android allows the attribute android:debuggable to be set to true in the manifest, so that the app can be debugged. By default this attribute is disabled, i.e., it is set to false, but it may be set to true to help with debugging during development of the app. However, an app should never be released with this attribute set to true as it enables users to gain access to details of the app that should be kept secure.
The best practice is to set android:debuggable="false">

Enabling JavaScript is not recommended
WebView consumes web content that can include HTML and JavaScript from an external URL, improper use can introduce common web security issues such as cross-site-scripting (XSS, or JavaScript injection).

Android includes several mechanisms to reduce the scope of these potential issues by limiting the capability of WebView to the minimum functionality required by your application.

Frontend- Web Application

Do not use eval() function, for security and performance reasons
It was observed that the application uses eval(code)

If the end-user has control over evaluated code (because the code is concatenated with user data), this leads to 'script injection' vulnerabilities, which could end in well-known security attacks like cross-site scripting.

It is recommended to avoid use of eval(code).

Do not use dangerouslySetInnerHTML property in React components.

dangerouslySetInnerHTML is React’s replacement for using innerHTML in the browser DOM. In general, setting HTML from code is risky because it’s easy to inadvertently expose your users to a cross-site scripting (XSS) attack.

Avoid dangerouslySetInnerHTML, equivalent to the risky innerHTML in DOM, when possible. Try using HTML directly from React, but use dangerouslySetInnerHTML and pass an object with a __html key.

Avoid post cross-document messages with an overly permissive target origin
It was observed that the cross-document messaging feature has been used. The feature allows scripts to post messages to other windows. The corresponding API allows the user to specify the origin of the target window. However, caution should be taken when specifying the target origin because an overly permissive target origin will allow malicious script to communicate with the victim window in an inappropriate way.

Always specify an exact target origin, not *, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.

We have Removed the instance as it was not required.

Potential infinite loops
The application executing infinite loops using user inputs. would lead to denial of service.

It Is recommended to a proper termination condition for every lo0ps

Never use JavaScript 'history' object or navigation-based positioning functions
Using 'history' (window.history, self.history) or navigation-based positioning functions (window.back(), window.forward()) is a bad practice for different reasons: * POST: If a visited page was generated with POST, browser will emit a warning if the submitted data is not encoded in the URL. * PRIVACY: No application should know which pages a user visited (browsers will emit a security alert and block access). * POOR NAVIGATION LOGIC: The exact page sequence taken by users may not match programmer expectations

It is recommended not to use the navigation history.