Security guidelines

This document describes the data security guidelines you need to implement on the application level. Infrastructure security measures are not described, because they are implemented by default in SCCOS and PaaS environments.

Passwords

The most important about password security is to not save it in plain text. Therefore, Spryker uses BCrypt based on Blowfish to hash passwords and add a random salt to each hash, preventing rainbow table attacks. To prevent dictionary and brute force attacks, you can force users to use special characters by adding validation rules to needed forms. For even higher security, use 2-factor authentication and CAPTCHA.

Encrypted communication

As HTTP is a textual protocol having no built-in encryption, passwords and customer personal data are transferred to shops in plain text. So, a good practice is to configure and implement transport layer security (TLS), which is widely known to most users as HTTPS.

In most cases, it prevents eavesdropping on traffic of users in local public networks like free Wi-Fi hotspots. Besides, it can be used to authenticate users using third-party integrations by requiring a client certificate to be trusted.

You can force HTTPS for the Storefront, Back Office, and Glue using the Strict-Transport-Security header:

• HttpConstants::ZED_HTTP_STRICT_TRANSPORT_SECURITY_ENABLED
• HttpConstants::YVES_HTTP_STRICT_TRANSPORT_SECURITY_ENABLED
• HttpConstants::ZED_HTTP_STRICT_TRANSPORT_SECURITY_CONFIG
• HttpConstants::YVES_HTTP_STRICT_TRANSPORT_SECURITY_CONFIG
• HttpConstants::GLUE_HTTP_STRICT_TRANSPORT_SECURITY_ENABLED
• HttpConstants::GLUE_HTTP_STRICT_TRANSPORT_SECURITY_CONFIG

Session security and hijacking

Websites include many third-party JavaScript libraries that can access the content of a page.

• To prevent access to session cookies from Javascript, Spryker sets the HttpOnly attribute of the session cookie by default. We advise to set this attribute for all sensitive cookies.
• When using TLS, you can use a secure cookie flag to instruct a browser to send this cookie back to the server only via an encrypted connection. To configure it, use the *_SESSION_COOKIE_SECURE configuration keys.
• To prevent session fixation, session identifier is refreshed on login and logout events. We recommend implementing the same behavior for other sensitive cookies if you use them in your shop.
• Make sure that your web server configuration does not cut these flags from cookie headers.
• Make sure that *_SESSION_COOKIE_DOMAIN matches only your domain to disallow a browser to send the cookie to another domain or subdomain.
• Never send a session ID as a GET parameter of a URL, because the ID can be logged in logs or forwarded to external websites in HTTP Referer header.

Cross-site request forgery (CSRF)

CSRF forces a user to execute unwanted actions while being logged in and either click on a specially crafted link or just embed the URL into some HTML tags triggering the request automatically—for example, the src attribute of img. To prevent such attacks, Symfony Form provides the csrf_protection token by default. We recommend using it in all forms.

Cross-site scripting (XSS)

Cross-site scripting is a possibility to inject malicious scripts to be executed in the browser context, for example, for a logged-in user to scrape information from the page or steal cookies. To prevent such vulnerabilities, developers should filter input and sanitize output to prevent rendering HTML or JS code from user input.

Twig template engine has autoescaping enabled by default, so make sure to not use a raw filter. HTML should be stripped from user input.

Usually, shop operators are trusted to enter raw HTML. Because you can’t limit them in this case, we recommend restricting access to the Back Office and other administrative panels in your shop. For example, introduce a VPN, IP whitelisting, or additional authentication.

Additionally, you can set X-XSS-Protection using HeadersSecurityServiceProvider.

Security between the Storefront and the Back Office

The Storefront uses HTTP RPC calls to communicate with the Back Office. Secure these calls by enabling Back Office authorization for Storefront requests:

• Set ZedRequestConstants::AUTH_ZED_ENABLED and AuthConstants::AUTH_ZED_ENABLED to true.
• Set a random value of AuthConstants::AUTH_DEFAULT_CREDENTIALS[‘zed_request’][‘token’] for each environment.
• Optional: Change the username used by Storefront in UserConstants::USER_SYSTEM_USERS.

Remote code execution

Avoid triggering remote code execution as follows:

• Local file inclusion: using unsanitized paths in include statements. To limit locations of files to be included, use the include_path PHP configuration option.
• Remote file inclusion: avoid using unsanitized URLs or user input in include statements.
• Unsafe deserialization. Serialized data should not be sent to the browser and should not be accepted back by the server. During deserialization of serialized data, PHP might instantiate classes mentioned in the payload and invoke some actions. Avoid this behavior or implement signature verification methods to validate this input.
• Command injection: avoid forwarding user input to exec, system, passthru, or similar functions.

SQL injection

SQL injections are happening when unsanitized user input is embedded into an SQL statement. Use the following mechanisms to prevent SQL injections:

• Propel to build queries and avoid plain SQL.
• Prepared statements (used by Propel by default) and typed placeholders.
• Casting incoming data to concrete data types like integer or string.
• The CastId method in Zed controllers.

Clickjacking

Clickjacking is when UI tweaked to force users to click on specific buttons or links. To prevent clickjacking, set correct headers in X-Frame-Options and Content-Security-Policy provided by HeadersSecurityServiceProvider. Make sure that the headers are not deleted by webserver configuration. For more information about clickjacking, see the OWASP article.

Obsolete or outdated dependencies

To make sure that all the security updates are installed, keep Spryker and third-party modules up to date. For upgradability guidelines, see Keeping a project upgradable.

Exceptions and debug mode

Make sure that, in your production environment, the debugging mode is disabled, and exceptions are not shown.

Debug mode is configured with the following:

• ApplicationConstants::ENABLE_APPLICATION_DEBUG
• ShopApplicationConstants::ENABLE_APPLICATION_DEBUG
• GlueApplicationConstants::GLUE_APPLICATION_REST_DEBUG

Demo data

Remove all the demo data from the environment. A project should only use the real data that will be used after going live. Remove all the demo data that comes with Spryker, which includes demo and admin users. Demo admin users in a live shop pose a significant security risk for your project. Also, make sure to set strong passwords when creating new admin users.

Summary

To sum up, the main points to keep the data secure are the following:

• Educate: Learn and spread OWASP guidelines in your team.
• Check the presence of security-related HTTP headers.
• Check cookie settings.
• Configure TLS.
• Secure the Back Office.
• Check Spryker configuration and change default authentication parameters like users and passwords.
• Keep systems and applications up to date.
• Make sure that exceptions are not shown and debug mode is disabled on production.