Summary: This article describes uStore security features.
Quick Links ShowHide
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.
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.
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.
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.
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:
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 Back Office > Store Setup > Permissions tab:
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 (https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet).
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 is a security vulnerability which enables a cyber-criminal to execute client side script, which might be harmful.
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.
Back Office: Product Details Step Configuration
Storefront: Product Details Step
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 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.
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.
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.
See information on how to address this issue (authorised users only).
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 ~.
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
Click to disable weak ciphers.
· Managing SSL/TLS Protocols and Cipher Suites for AD FS
· Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2
· Disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect
· Qualys discussions
· SSL server test (use to test your site's ciphers)
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.
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.
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.
See information on how to address this issue (authorised users only).
Created by: Ben Pelkinson, last updated by Mohammad Mansour: November, 2022