GUIDANCE FOR IMPLEMENTATION TEAMS

The Guidance for Implementation Teams consists of following topics:

CSRF Mitigation – Generating Nonces

A nonce is a pseudo random number that may be used only once. If a nonce is sent across in every request from the client to the server and the server validates the sent nonce every single time, then it mitigates the risk of Cross Site Request Forgery (CSRF).

The product provides a REST Service to generate nonces – each nonce can be used only once to identify each request uniquely, for each session. The product also has an inbuilt framework that will validate the nonce sent in the request.

Therefore post a successful login you need to make a call to https://<Host>:<Port>/digx/v1/session/nonce before you make a call to any other service. This service will return back an array of nonces in the response header. You can pick up any one nonce from the array and use it to send across the nonce required in a subsequent request. A nonce can be used only once. You need to discard it after usage.

Please note that unless you send across a nonce, the services that are accessed post login will not work.

Indirect Object Reference Implementation

What it means

It is a good security practice to hide sensitive data objects from the end user. Although the system needs to play around with sensitive data objects, it is recommended to refer to these sensitive data objects via pointers – tokens that temporarily point to the sensitive data objects but themselves do not contain any sensitive data.

For example consider a credit card application on the web which offers the following 2 transactions:

The Credit Cards Summary page will typically list all credit card numbers in a masked format. Let’s assume that the end user holds 2 Credit Cards C1 and C2. When the end user hits the Summary link, the server returns back the following in its response:

T1 and T2 are random tokens – difficult to guess – which the server has generated as proxies for C1 and C2 respectively. The server has internally stored this mapping of C1-T1 and C2-T2 somewhere. Please note that T1 and T2 are tied to the current session. The moment the session expires, T1 and T2 get discarded. Next time the user logs in, the server generates different tokens T1x and T2x for C1 and C2 respectively.

Whenever the user clicks on say Credit CardClosed A credit card is a payment card issued to users (cardholders) as a method of payment. Details for C1, the client sends T1 to the server instead of C1, as a request parameter. The server internally figures out that the request is actually for C1 and processes the request accordingly.

Thus we refer to sensitive data indirectly via tokens that are generated with different values for every session

How OBDX supports it

To implement the above mechanism the framework offers interception of both the request and the response. For the interception to work automatically, the sensitive fields holding the Personally Identifiable Information (PII) must be defined as a Java type, which extends the abstract class.

com.ofss.digx.datatype.complex.MaskedIndirectedObject.

The abstract class essentially exposes 2 fields, namely value and displayValue. The value field holds the indirected value which is used for data transmission. Whereas, the displayValue field holds the masked value of the data.

The following data types are supported out-of-box:

To modify the existing/base product-masking pattern for any of the above data types, the following entries need to be copied/cloned from the table DIGX_FW_CONFIG_ALL_B to the table DIGX_FW_CONFIG_ALL_O and then modified as required in DIGX_FW_CONFIG_ALL_O.

Note: Please DO NOT MODIFY these entries IN DIGX_FW_CONFIG_ALL_B.

Data Type

Category ID

Property ID

Account

MaskingPattern

AccountNumberMasking

ApplicantClosed An applicant refers to an individual or a non-individual (organization or trust) who has applied for one or more main lines.

MaskingPattern

ApplicantIdMasking

ApplicationId

MaskingPattern

ApplicationIdIdMasking

ContentId

MaskingPattern

ContentIdMaskingPattern

CreditCard

MaskingPattern

CreditCardNumberMasking

DebitCard

MaskingPattern

DebitCardNumberMasking

Email

MaskingPattern

EmailIdMasking

PartyClosed A party is any individual or business entity having a banking relationship with the bank.

MaskingPattern

PartyIdMasking

PhoneNumber

MaskingPattern

PhoneNumberMasking

SSNClosed Social Security Number

MaskingPattern

SSNMasking

SubmissionId

MaskingPattern

SubmissionIdMaskingPattern

The characters allowed in the making pattern are as below:

N – Keeps the character transparent. Does not mask.

Any other character – Replaces the character at the location to the character specified.

For example: XXXXXNNNN will keep the last 4 characters in clear text and mask the first 5 characters using the character ‘X’.

Output Encoding

To mitigate inline Cross Site Scripting attacks, the product provides a framework to encode the data sent in the response. In the previous versions there was guidance in this section of the security guide on the steps needed to be followed to implement output encoding in your service response. However, in OBDX 17.2.0.0.0 this is something that is handled implicitly in the framework for all services, base as well as any custom services that you might write.

There is nothing that you need to do explicitly to achieve this

Configuring the Hashing Algorithm for OTPs

The hashing algorithm used to hash the One Time Passwords used for payments and other transactions is configurable.

This has been made configurable since Cryptography is an ever changing field. Algorithms that are considered as secure today might be rendered insecure tomorrow by attackers doing research in cryptography. Making the hashing algorithm configurable will help the customer upgrade to the latest algorithm prevailing at the time in the future, with reasonable ease.

Configuration Steps:

Security

Security

Implementing a custom 2FA mechanism

Security 

com.ofss.digx.framework.security.authentication.provider.I2FactorAuthenticationProvider

Scurity

Security

Disable Password Protection for PDF Documents

By default all the pdf documents are password protected. There is configuration to override the feature by updating value for “PDF_PASSWORD_HELPER” in digx_fw_config_all_b table.

Note: Overriding this value will make all the documents which user can download (in pdf format) password non-protected.

Scripts:

update digx_fw_config_all_b set prop_value ='' where prop_id ='PDF_PASSWORD_HELPER' and category_id ='documentConfig';

Note: Server/DB restart required.

Back