Magento the New Key field, enter or paste

Magento
2 Security Features

Written by Eugene Shevchuk, Kira Kharevich

 

1. Strong data encryption (available both in Magento Commerce
and Magento Open Source)

 

Magento uses an encryption
key to protect passwords and other sensitive data. An industry-standard
Advanced Encryption Standard (AES-256) algorithm is used to encrypt all data
that requires decryption. This includes credit card data and integration
(payment and shipping module) passwords. In addition, a strong Secure Hash
Algorithm (SHA-256) is used to hash all data that does not require decryption.

During the initial
installation, you are prompted to either let Magento generate an encryption
key, or enter one of your own. The Encryption Key tool allows you to change the
key as needed. The encryption key should be changed on a regular basis to
improve security, as well as at any time the original key might be compromised.
Whenever the key is changed, all legacy data is re-encoded using the new key.

 

To change the
encryption key, make sure that the following file is writable:

your
store/app/etc/env.php

 

Please go to System
> Other Settings > Manage Encryption Key: https://screen.amasty.com/d5d47644cd8b7e27960796b4680db082.png

Here you can choose
auto-generation for the key or to use your own key.

For the first variant,
please set Auto-generate Key to “Yes”.

To use a different key,
please set Auto-generate Key to “No”. Then in the New Key field, enter or paste
the key that you want to use.

Now please press
“Change Encryption Key” button: once that’s done, new key is added. Please keep
a record of the new key in a safe place. It will be required to decrypt the
data, if any problems occur with your files.

 

FOR
MARKETING: ??????? ??????:
http://docs.magento.com/m2/ce/user_guide/system/encryption-key.html.

 

2.  Session Validation

 

Magento Open Source
allows you to validate session variables as a protective measure against
possible session fixation attacks, or attempts to poison or hijack user
sessions. The Session Validation Settings determine how session variables are
validated during each store visit, and if the session ID is included in the URL
of the store.

The validation checks
to see that visitors are who they say they are by comparing the value in the
validation variables against the session data that is already stored in
$_SESSION data for the user. Validation fails if the information is not
transmitted as expected, and the corresponding variable is empty. Depending on
the session validation settings, if a session variable fails the validation
process, the client session immediately terminates.

Enabling all of the
validation variables can help prevent attacks, but might also impact the
performance of the server. By default, all session variable validation is
disabled. We recommend to experiment with the settings to find the best
combination for your Magento installation. Activating all of the validation
variables might prove to be unduly restrictive, and prevent access to customers
who have Internet connections that pass through a proxy server, or that
originate from behind a firewall.

 

You can find Session
Validation Setting under Stores > Settings > Configuration > General
> Web: https://screen.amasty.com/a3958c73ff6b03e37492fb9b4e6163c1.png

To verify that the IP
address of a request matches what is stored in the $_SESSION variable, set
Validate REMOTE_ADDR to “Yes.”

To verify that the
proxy address of an incoming request matches what is stored in the $_SESSION
variable, set Validate HTTP_VIA to “Yes.”

To verify that the
forwarded-for address of a request matches what is stored in the $_SESSION
variable, set Validate HTTP_X_FORWARDED_FOR to “Yes.”

To verify that the
browser or device that is used to access the store during a session matches
what is stored in the $_SESSION variable, set Validate HTTP_USER_AGENT to
“Yes.”

If you want a user to
stay logged in while switching between stores, set Use SID on Frontend to
“Yes.”

If including SID with
analytics, you must configure your analytics software to filter the SID from
URLs, so the page visit counts are correct.

 

FOR
MARKETING: ??????? ??????: http://docs.magento.com/m2/ce/user_guide/stores/security-session-validation.html.

 

3. Cookie Validation

 

HTTP Cookie is a small packet of
data which is sent from a web server to a user’s web browser. Since HTTP is a
stateless protocol, it can not relay information from one page to the other —
that is why a cookie is required.

Secure cookie is a type of cookie
which is transmitted over an encrypted HTTP connection. When setting the
cookie, the secure attribute instructs the browser that the cookie should only
be returned to the application over encrypted connections. The secure attribute
does not protect the cookie in the process of transmitting from the application
to the browser, both Firefox and Internet Explorer allows cookie with the
Secure attribute to be set over HTTP.

To fully protect a cookie, the
HttpOnly and SameSite attribute should also be applied to the cookie. The
HttpOnly protects the cookie from being accessed by, for instance, JavaScript,
while the SameSite attribute only allows the cookie to be sent to the
application if the request originated from the same domain.

In 2016 Google Chrome version 51
introduced a new kind of cookie which can only be sent in requests originating
from the same origin as the target domain. This restriction mitigates attacks
such as cross-site request forgery (XSRF). A cookie is given this
characteristic by setting the SameSite flag to Strict or Lax.

To send secury and HttpOnly cookie,
you should use setcookie() function with params true and true in 6 and 7
position, like:

setcookie($name, $value, $expTime,
$path, $domain, true, true);

By default, Magento checks if https
is enabled and set secury flag automatically. If you want to use HttpOnly flag
for cookie, you can enable it in Magento admin panel. In Magento 2 you will
find this configuration by path Stores > Configuration > General > Web
> Default Cookie Settings:

https://screen.amasty.com/1516721084574.jpg

 

For Marketing ??????? ?????? – https://en.wikipedia.org/wiki/Secure_cookies https://en.wikipedia.org/wiki/HTTP_cookie#SameSite_cookie

 

4.
CSRF protection.

 

CSRF (Cross Site
Request Forgery, also known as XSRF) is a type of web-site visitor attack that
exploits the disadvantages of the HTTP protocol. If the victim comes to a
web-site created by an attacker, a request is sent to it on behalf of another
server performing a certain malicious operation. To perform this attack, the
victim must be authenticated on the server to which the request is sent, and
this request should not require any acknowledgment from the user that can not
be ignored or forged by the attacking script.

The main application of
CSRF is forcing the execution of any actions on the vulnerable site on the
behalf of the victim (changing the password, the secret question for password
recovery, mail, adding an administrator, etc.). Moreover, it is possible to use
mirrored XSS detected on another server using CSRF.

Magento 2 uses
additional secret token to protect against such attacks, which is automatically
generated along with any form where the information is sent and after the form
is submitted, Magento 2 checks for a match between token submitted and the
token that is stored within the session. If the results coincide, then the user
for which the form has been generated and the user that has submitted the form
are the same. If the token is not valid, the form is not further processed and
no data will be changed.

 

For
Marketing – Cross-Site Request Forgery Securitylab.ru, 13 ????? 2007 ?. ???????
?? ????

 

5. XSS protection.

 

XSS (Cross-Site
Scripting) is a type of attack on a web-based system that involves inserting a
malicious code page (which will be executed on the user’s computer when the
page is opened to it) and interacting with the malicious web-server. It is a
kind of attack called “code injection”.

The peculiarity of such
attacks means that the malicious code can use the authorization of the user in
the web-system to obtain an expanded access to it or to obtain user
authorization data. Malicious code can be inserted into the page either through
a vulnerability in the web-server or through a vulnerability on the user’s
computer.

XSS was put on the
third place in the key risks ranking of web applications according to OWASP
2013. For a long time, programmers have not given them due attention, often
considering them harmless. However, this opinion is erroneous: on the page or
in the HTTP-Cookie there may be especially vulnerable data (for example, the
administrator session ID or the number of payment documents), and where there
is no protection against CSRF, the attacker can perform any actions available
to the user. Cross-site scripting can be used to conduct a DoS attack.

There are mainly three
types of XSS vulnerabilities:

·                   
Persisted XSS – In this type of vulnerability, the source of invalidated data
comes from the Database or Backend permanent store.

·                   
Reflected (non-persistent) XSS – This type of
vulnerability occurs when data provided by a web client are used immediately by
server-side scripts to parse and display a page to a user without properly
sanitizing the request.

·                   
DOM XSS – For this vulnerability, the malicious data do not touch the
web-server. Rather, it is being reflected by the JavaScript code, fully on the
client side.

Preventing
XSS

XSS vulnerabilities can
be prevented by always validating and sanitizing both user input and output,
i.e., user input should never be trusted. Both the PHP language and Magento
provides classes and functions (for example, escaper classes) to help secure
your extension from XSS vulnerabilities.

Input
Processing

Any data you receive
from an external source need to be validated and sanitized to prevent the
storage or execution of malicious code. Input data need to be validated within
the accepted possible values for that data item. This can vary depending on
what that data is used for, but certain field validations can be applied almost
universally such as checking for control characters.

Output
Processing

Output processing
involves sanitizing strings that may have come from external data sources
before sending it to the browser to be rendered with templates. It is the main
method of protecting your extension from XSS attacks.

For more information,
please see the article on templates XSS security:  http://devdocs.magento.com/guides/v2.2/frontend-dev-guide/templates/template-security.html

Using the Escaper classes

Magento provides the
Escaper class for HTML output. This class contains the following useful
functions:

escapeHtml() – Used for
escaping string inside HTML content.

escapeHtmlAttr() – Used
for escaping strings in HTML tag attributes.

escapeCss() – Used for
escaping strings inside a CSS context.

escapeJs() – Used for
escaping strings inside a JavaScript context.

escapeUrl() – Used for
escaping strings that will be used in a URL.

 

You shouldn’t escape
text, if it’s a result of Magento methods like getTitleHtml(), getHtmlTitle()
or PHP methods like count(). Also, don’t escape variables, which forced reduces
to some type like int, float, boolean. For example, getId() ?>.

Output in a single
quotes or output in a double quotes without variables also doesn’t require
escaping.

 

For
Marketing. ??????? ?????? http://devdocs.magento.com/guides/v2.2/extension-dev-guide/xss-protection.html ? ? ????Jatana1, Nishtha, Agrawal, Adwiteeya, Sobti,
Kritika Post XSS Exploitation: Advanced Attacks and Remedies  — P. 9. ?
Seth Fogie, Jeremiah Grossman, 2007, p. 290, 379.

BACK TO TOP