uStore Security Features

Summary: This article describes uStore security features.

Overview

uStore is an e-commerce platform offering web-2-print and VDP capabilities. Storefronts based on uStore are exposed to the world wide web and are publicly available.

uStore Storefront customers enter their credentials, billing information and other sensitive details in the store, as well as upload their documents, images, mailing lists and other files which might contain sensitive information.

Therefore, uStore must offer a secure and safe environment. This article describes uStore security features.

Setting security options (SSL)

SSL (Secure Sockets Layer) is used to ensure that information added to uStore is secure. You need to install and configure SSL to be able to use the secure options.

In the Security Options (SSL) section, specify how to use the SSL protocol to secure the information users enter into your online stores (for example, login or payment details).

Securing uStore using SSL requires one of the following certificates, depending on the number of domains you want to secure:

• A regular SSL certificate – secures a single domain. This certificate is useful for securing a single store, or several stores that share the same domain name, but differ by their sub-folder name.

• A Multi Domain SSL certificate – secures multiple domains. This certificate is useful for securing several stores that have different domain names (friendly URLs).

Once you have installed and configured SSL on your website’s Internet Information Server (IIS), you can configure it in uStore by choosing one of the options below.

Note:  When a Proxy server is used in front of an application server and all connections coming from the web to the uStore server are routed through the Proxy server, the SSL certificate must be installed on both uStore and Proxy servers.

To set security options:

In the Security Options (SSL) section (Store Setting > Set Up Store > Advanced tab), select one of the following options:

• Not Secured - if you do not want the store to be secured by SSL. This option is useful while you are working offline and are in the process of setting up the store. Once you make the store available online, make sure you change this setting to Secure All.

• Secure All - to secure all pages in this store. This configuration may slow down the page loading.

Important! The system does not support having both secured and non-secured stores on the same domain/sub-domain.
If you have both secured and non-secured stores on the same domain/sub-domain, please change the non-secured ones to be secured (or vice versa, although not recommended), or shoppers may have a problem accessing them.

Users

uStore has an enhanced authentication and permissions mechanism, which makes sure that customers can only log in to stores they are allowed to.

Moreover, it is possible to restrict customers to certain products or product groups, and to deny customers from checking out orders.

Registration

uStore registration mechanism has a CAPTCHA feature which can be enabled on the store level to make sure only human customers register to the store.

uStore also has an activation feature, which can be enabled for a store in order to make sure customers register using a real email address, and one that they really have access to.

It is also possible to integrate a custom registration page, in which uStore customers can implement their own UI and logic for customer registration.

Registration settings are configured in Store Setting > Set Up Store > General tab:

Passwords

uStore has a password policy feature, which can be enabled on the store level and can enforce the following:

1. A certain password format, defined mainly by minimum and maximum number of characters of different types.

2. Passwords can expire after a certain number of days.

3. An account can be locked out after a certain number of login attempts, and can be unlocked after a certain amount of time.

Password policy settings are configured in BackOffice > Store Setup > Permissions tab:

Sender address in triggered emails

When creating an email trigger, you are required to enter a Sender Address. This is the email address that appears in the From field of the received email.

Make sure you use a genuine email address, but one that is not used for logging into the system.

SQL injection

Websites that store or process data will usually use some sort of Structured Query Language (SQL) database as a back end repository. This database can be used to store anything from product and customer information to usernames and passwords.

Copying user input into the SQL database query string and executing that query can lead to SQL injection vulnerabilities. SQL injection vulnerabilities can allow cyber-criminals to collect sensitive information stored in the database and to completely take over the vulnerable system.

uStore uses a common technique, known as “parameterized queries” (or “prepared statements”), in order to cope with the risk of SQL injection. The implementation of parameterized queries is documented on the OWASP website ().

This technique is used in queries made internally by uStore, as well as in queries that can be configured by uStore administrators for some advanced features offered by uStore.

Cross-site scripting

Cross-site scripting is a security vulnerability which enables a cyber-criminal to execute client side script, which might be harmful.

Cross-site scripting is prevented by default by the ASP.NET platform on which uStore is based. However, in some cases, cross-site scripting is enabled in uStore Back Office by design. In those cases, uStore administrators may enter HTML and JavaScript code for particular fields. By doing so, a uStore administrator can customize the Product Details page with anything HTML and JavaScript has to offer.

Please keep in mind that the Back Office should not be publicly available, and that cross-site scripting is not possible from the Storefront, so security is maintained.

Example:

Back Office: Product Details Step Configuration

Storefront: Product Details Step

Cross-site framing

Cross-site framing means that a web page can be embedded in a frame by another page. It is considered a security vulnerability as a cyber-criminal can exploit it in order to replicate the look and feel of a page, and in fact create a phishing site in which sensitive information can be retrieved from victims.

Cross-site framing is enabled in uStore by design. It enables uStore customers to embed uStore in their website, for example, as a Facebook application.

Cross-site framing is not high risk vulnerability and can be prevented by uStore customers in a number of ways, if necessary.

Cookies

Cookies are used by web applications in order to keep information on the client side, and in order to keep the state of the connection to the server (known as session). A cyber-criminal obtaining a cookie may take over a user’s session and exploit it to retrieve sensitive information.

uStore cookies are HTTP-Only cookies. HTTP-Only cookies can only be accessed from the server side, so a cyber-criminal obtaining such a cookie will not be able to exploit it.

Files upload

uStore enables customers to upload their images, recipient lists and documents. Such file uploads are restricted to certain file types, so a customer cannot upload malicious files. However, files uploaded to the server may contain viruses which may be harmful, so an anti-virus software should be installed on the uStore server.

Harden the server against ClickJacking attacks

Clickjacking is a malicious technique of tricking web users into revealing confidential information or taking control of a user’s computer while clicking on seemingly innocuous web pages. A click-jacked page tricks a user into performing undesired actions by clicking on a concealed link.

On a click-jacked page, the attackers show a set of dummy buttons, and then load another page over it in a transparent layer. The users think that they are clicking the visible buttons, while they are actually performing actions on the hidden page. The hidden page may be an authentic page, and therefore the attackers can trick users into performing actions which the users never intended to do and there is no way of tracing such actions later, as the user was genuinely authenticated on the other page.

Microsoft IIS tilde directory enumeration

It is possible to detect short names of files and directories which have an 8.3 file naming scheme equivalent in Windows by using some vectors in several versions of Microsoft IIS. For instance, it is possible to detect all short-names of ".aspx" files as they have 4 letters in their extensions.

Exploiting this vulnerability may cause the leakage of files containing sensitive information such as credentials, configuration files, maintenance scripts and other data.

To handle this vulnerability:

1. Add a registry key named NtfsDisable8dot3NameCreation to HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. Set the value of the key to 1 to mitigate all 8.3 name conventions on the server.

2. Open IIS Manager and click the default website.

3. Click the Request Filtering option.

   

4. Click the URL tab.

5. In the Actions panel on the right, select Deny Sequence.

   

6. Add ~.

SSL weak ciphers

A weak cipher is defined as an encryption/decryption algorithm that uses a key of insufficient length. Using an insufficient length for a key in an encryption/decryption algorithm opens up the possibility (or probability) that the encryption scheme could be broken.

It is advisable to disable weak ciphers.

Additional information

Learn:

• Manage SSL/TLS protocols and cipher suites for AD FS

• Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2

Execute:

• This tool may help you with Disabling weak cyphers (use at own discretion!)

Test:

• Test your site's ciphers using the SSL server test

• SSL server test (use to test your site's ciphers)

Server banner disclosure

The application was found to disclose server information about the server software in use. Information disclosure is a common and prevalent vulnerability in applications. The disclosure of sensitive information either directly or implicitly through application behavior, may aid an attacker with information gathering or profiling, and determining or establishing other vectors of attack against the application or host.

Using a proxy server

When using a proxy server you might still have “Server“ and “X-Powered-By“ headers. In such a case, you can configure IIS on the proxy machine to remove them.

1. On IIS, click the root node of the proxy server.

2. Click the configuration editor icon.

3. Search under the Sections field for: system.webServer > httpProtocol-

4. Click the 3 dots on the value of key: customHeaders

   

5. Window opens. Search for the value X-powere-by, click it and click Delete.

6. Click Apply.

7. Search under the Sections field for: system.webServer > security > requestFiltering

   

8. Search for key “removeServerHeader” and set it to True.

   

9. Click Apply.

Misconfigured CORS

The HTML5 cross-origin resource sharing policy controls whether and how content running on other domains can perform two-way interaction with the domain which publishes the policy.

The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user. Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application which allows access.

Missing Security Headers (HTTP)

HTTP headers are used by the client and web server to share information as part of the HTTP protocol. When a URL entered in the address bar of the browser or clicked on any link, the web browser sends a HTTP request containing client headers while the HTTP response contains server headers. Some HTTP headers which are used against common vulnerabilities like Cross-site Scripting, Session Hijacking, Frameable Response (Clickjacking) are called security headers. Missing security headers may increase the risk of exploitation of those vulnerabilities, if they exist in your application.

Apply these steps on the uStore application server and/or proxy server:

1. Open IIS.

2. Choose HTTP Response Headers.

3. Add the name and value for requested headers – see table below.

Name	Value	Comments
Strict-Transport-Security	max-age=31536000 ; includeSubDomains; preload
X-Content-Type-Options	nosniff	Apply only to the proxy server (installed by default on the uStore application server)
Feature-Policy	camera 'none'; speaker 'none'
X-XSS-Protection	1;mode=block	Apply only to the proxy server (installed by default on the uStore application server)

Antivirus Protection

It is highly recommended that on-premise customers install and enable antivirus scanning on their machine to enhance security.

 

 

Created by: Ben Pelkinson, last updated by Mohammad Mansour: December, 2024