Security in Znode

TABLE OF CONTENTS

Introduction
API Application Security
Payment API Security
- Payment API security against whitelisted referrers only
- Payment API Token-Based Authentication
  - Additional Security Limits with Tokens:
Webstore Security

Introduction

Znode provides quite a few out-of-box security features to keep your application safe against invalid access.

API Application Security

Basic Authentication for APIs

As the name suggests this is the basic authentication, which protects access to APIs using a static key/value (username/password) authentication.

The Znode API uses basic authentication with the Authorization header to validate requests. And Authorization header’s value is built using WebstoreDomain|APIKey.

For more detailed information, check here.

Setup key/value per store basis:

Prerequisites:

The following configurations are required in web.config file:

The following needs to be set in API, Admin and Webstore web.config.

Global Authorization is set to “false”:

If you have multiple webstores OR want to have an independent authorization key/value for each webstore, then you can do it by adding your key value in the following format:

Use the Web.config file of admin, webstore, and Api application to add the following entry.

E.g. <add key="store1.yoursite.com" value="store1-api-key" />

Setup key/value once for all stores (GlobalAPIAuthorization)

Prerequisites:

The following configurations are required in web.config file:

The following needs to be set in API, Admin and Webstore web.config.

Global Authorization is set to “true”:

If you have many webstore domains and you do not want to set up a domain name and key setup for each store, then you should use the 'IsGlobalAPIAuthorization' key as true in the Web.config file of admin, webstore, and API. In this case, use the API’s domain name and apikey, in below mentioned settings.

Note: When GlobalAPIAuthorization key value is set to true then you must set the ZnodeApiDomainName and ZnodeApiDomainKey as per the column DomainName and APIKey of database table 'ZnodeDomain'.

Token-based authentication for APIs

The Znode API also provides token-based authentication to validate the request. To enable the token-based authorization, you need to set the EnableTokenBasedAuthorization key as true in the Api, Webstore, and Admin Web.config file.

The EnableTokenBasedAuthorization will work only if the 'ValidateAuthHeader' key value is set as true.

Token Expiration time (time in minutes) is configurable through APIs Web.config file:

The following steps for Token-Based Authorization would be required if you are going to call Znode APIs from another client app. Znode’s admin and webstore apps already have the following steps implemented:

For “Token Based Authorization”, first of all, the client will have to ask for a token from token/generate-token API using the BasicAuthorization (mentioned above), and then for other API requests, send this token value in HTTP Header named “token”.

Make API application “private” and Make images accessible through “Network Drive” or 3rd Party storage setting

By default, Znode is configured for local file storage for DAM assets. And these images are stored on the “API” application location. Due to this reason, API applications need to be kept public so that Webstore and admin applications are able to show images.

But for stricter security, one can opt to keep the API application “private”, and change DAM settings to use images through a different URL, instead of the API URL (Local server storage).

Administrators can manage the servers where the media will be stored when uploaded to the Media Library. Apart from local file storage, Znode supports Amazon S3, Azure Storage Servers, and Network Drive. After a storage server has been configured, new media asset data can be saved to the location specified.

Note: After changing the storage server, administrators will need to generate the Images manually and clear the cache of the stores.

Click here to learn more about DAM Image location settings.

Disabling Swagger Access of API and Payment API

Having access to Swagger definition to unidentified sources will allow them to know the API structure and may help them build some sort of attacks.

To prevent Api and Payment Api swagger to be accessed from unidentified sources use the EnableSwagger key. This key can be used to enable or disable the swagger.

The following setting needs to be configured in Api and payment Api Web.config file.

In Production/Public environments, it is recommended to keep this setting as “false”.

Payment API Security

Payment API security against whitelisted referrers only

Znode payment API can restrict access to clients based on the “referer” HTTP Header. You can whitelist the specific referrer domains which are allowed to access Payment API.

Payment API Web.config file, CORS_Domains key.

E.g. <add key="CORS_Domains" value="admin.yoursite.com,store1.yourstore.com,store2.yoursite.com" />

without this Znode admin and webstore applications will not be able to connect with the payment API.

Note - The above key is available only after v9.7

This helps mitigate security risks at a certain level. Additionally, customers can use any WAF (Web Application Firewalls) of their choice for more robust rules.

The following needs to be set in Payment API web.config.

If the ValidateAuthHeader flag is set to false in the paymentApi Web.config, the API can be accessed without requiring validation of the authentication header. Therefore, it is recommended to enable this key.

Payment API Token-Based Authentication

Znode Payment APIs can be authenticated using “expiry tokens” only. HTTP Request would carry an “Authorization” header to get access.

A token can be generated using the “authtoken/paymentaccesstokengenerator/{userOrSessionId}/{fromAdminApp}” endpoint and bypassing the Private-Key in the “Znode_PrivateKey” header. The private key can be found/configured in the Web.config (“ZnodePrivateKey” setting) of the Payment API application.

Value for ZnodePrivateKey can be anything random, not driven from DB.

But make sure the value is added in Admin, Webstore, and API Web.config apart from PaymentApi Web.config.

Notes:

The above key is available only after v9.7
Token generation calls must happen over the trusted private network only. Private Key must not be exposed in public calls to API.

Additional Security Limits with Tokens:

By default, Any token is set to expire after “3” time use. After that, a shopper session must generate a new token.

Also, a single shopper account can generate a maximum of “10” tokens within the span of “5 mins”.

These 2 limitations are being added to avoid scripted/bot usage of the Payment API.

These values are currently configurable in “Payment DB’s Stored Procedures”.

“Use Count Limit” can be set in SP named “Znode_ValidateAuthToken.sql” and

“Token Generate Limit” can be set in SP named “Znode_InsertAuthToken.sql”.

Webstore Security

Captcha in Webstore

In Znode, Captcha is implemented for the Login page and Contact Us pages whose visibility is dependent on the Store level global attribute values.

Is Captcha Required For Login - If the setting is set as “yes” then the Captcha will be shown on the login page.
Is Captcha Required For Forms - If the setting is set as “yes” then the Captcha would be shown in the respective forms.

For more information view this article on Captcha

Webstore: AntiForgeryToken implementation for any new form/post requests

The purpose of using the anti-forgery token attribute is to prevent cross-site request forgery (CSRF) attacks.

A cross-site request forgery is an attack in which a harmful script element, malicious command, or code is sent from the browser of a trusted user.

To prevent CSRF attacks, decorate Controller/Action methods with the ValidateAntiForgeryToken attribute as shown below:

[HttpPost]

[ValidateAntiForgeryToken]

public virtual ActionResult YourMethod()

{

//Method Body

}

And in the view file (.cshtml), add the following code to insert the AntiForgeryToken in the HTML page so that it can be used to validate the form upon submission.

@Html.AntiForgeryToken();

The Znode webstore application already has this token added to the required forms.

Znode webstore Web.config has HttpOnly and IsCookieSecure flags that can be used to make the cookies more secure. When a secure flag is used, then the cookie will only be sent over HTTPS, which is HTTP over SSL/TLS.

The httpOnly flag is set as true, when there’s no restriction in place, cookies can be transferred not only by HTTP, but any JavaScript files loaded on a page can also access the cookies. This ability can be dangerous because it makes the page vulnerable to cross-site scripting (XSS) attacks. The only way to restrict this is by setting the HttpOnly flag. See the following setting in Webstore’s Web.config.

The IsCookieSecure flag specifies that the cookie may only be transmitted using HTTPS connections (SSL/TLS encryption) and never sent in clear text. If the cookie is set with the Secure flag and the browser sends a subsequent request using the HTTP protocol, the web page will not send this cookie to the web server in its HTTP response. See the following setting in the Webstore’s Web.config.

By default, Cookies without the SameSite header are treated as SameSite=Lax. With SameSite=Lax, Cookies are not sent on normal cross-site subrequests. And In the cross-site request scenarios, some functionality (which depends on cookies) may not work on platforms like Safari, Chrome on iOS and Apple devices.

To overcome this issue, some configurations need to be verified as mentioned below:

WebStore Web.config Key Configurations:

Webstore Content-Security-Policy Header

The HTTP Content-Security-Policy response header allows administrators to control resources the user agent (e.g. browser) is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks. For more information check here.

This policy affects the different types of content loaded in the Webstore like images, js, CSS, ajax, etc.

Znode webstore is configured with the required values for this header in the Web.config file. If you are using Content from additional sources, then you need to add those URLs in the Web.config file in the following section.

Webstore Permission-Policy and Referrer-Policy

Permissions Policy provides mechanisms for web developers to explicitly declare what browser capabilities can and cannot be used on a website. You define a set of "policies" that restrict what APIs the site's code can access or modify the browser's default behavior for certain features.

Znode webstore is preconfigured with default permissions policy in the WebStore Application Web.config file, please modify them as per your need.

Referrer-Policy is a new header that allows the site to control how much information the browser includes with navigations away from a document and should be set by all sites.

In Znode Webstore we have added the default referrer policy in the WebStore Application Web.config file.

External WAF (E.g. CloudFlare)

A WAF or web application firewall helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. It typically protects web applications from attacks such as cross-site forgery, cross-site scripting (XSS), file inclusion, and SQL injection, among others.

For robust security of your application and based on your business needs, it is advised to use WAF to protect your application from a lot of known attacks and vulnerabilities.

Additional note: Znode has CDN Caching integration with Cloudflare. Cloudflare offers a WAF module as well for an additional fee.