O Magento lançou um novo patch de segurança para o M1 e atualizações para o M1 e o M2.
Quais problemas devo procurar ao atualizar ou aplicar este patch?
SUPEE-10570, Magento Commerce 1.14.3.8 e Open Source 1.9.3.8 contêm vários aprimoramentos de segurança que ajudam a fechar a execução remota de código (RCE), scripts entre sites (XSS e outros problemas). Essas versões também incluem pequenas correções funcionais listadas no notas de lançamento.
ATUALIZAÇÃO DE SEGURANÇA DO MAGENTO 2.2.3, 2.1.12 E 2.0.18
O Magento Commerce e o Open Source 2.2.3, 2.1.12 e 2.0.18 contêm vários aprimoramentos de segurança que ajudam a fechar o Cross-Site Scripting (XSS), a autenticação remota de código do usuário Admin autenticada (RCE) e outras vulnerabilidades. Os lançamentos incluem correções funcionais adicionais. Para descobrir mais sobre as correções funcionais, consulte as Notas de versão do Magento Commerce 2.0.18, 2.1.12, 2.2.3 e Magento Open Source 2.0.18, 2.1.12, 2.2.3.
Respostas:
Aqui está a lista de arquivos modificados pelo patch SUPEE-10570:
EDITAR
Finalmente, depois de implantar no site do meu produto (CE 1.7.0.2), notei um problema crítico de bloqueio (processo de pagamento bloqueado).
O contexto: após o endereço da etapa 1, eu crio E registro diretamente o cliente, ele deve ver apenas a próxima etapa da finalização da compra.
O problema: após o supee-10570, o processo de checkout é interrompido após a etapa 1 (no caso de criação da conta) e o cliente é redirecionado para a página inicial (com o carrinho de compras vazio + desconectado) = impossível realizar o checkout.
A correção de emergência: caso você encontre um problema semelhante com sua sessão de checkout / cliente, comente as linhas 414-430 de app / code / core / Mage / Core / Model / Session / Abstract / Varien.php (as adicionadas pelo patch , ver abaixo).
EDIT (2)
Eu acho que a seguinte condição sempre retornará false (Mage_Core_Model_Session_Abstract_Varien nas linhas 414-419, especialmente as linhas 417 + 418).
VALIDATOR_PASSWORD_CREATE_TIMESTAMP será sempre maior que VALIDATOR_SESSION_EXPIRE_TIMESTAMP. O registro de data e hora de "expiração" da sessão é redefinido na criação da conta, inevitavelmente mais antigo que o init da sessão.
Por exemplo, se você criar o cliente durante o checkout, isso retornará falso e o cliente será expulso (= finalizar o checkout, redirecionar para a página inicial e o carrinho vazio). Muito mal.
Eu relatei esse problema para a equipe magento. Vou dar um feedback aqui o mais rápido possível.
EDIT (3)
Um novo patch é o wip (na página de download do patch do magento, escreva "SUPEE-10570 para CE 1.7.0.0 - PATCH ATUALIZADO ESPERADO, NÃO USE (0,06 MB)").
EDIT (4) ~ 1 mês após o problema inicial de bloqueio relatado
Oi! Espero que todos sejam mercadorias (e espere que você não tenha mantido o estado inicial do patch até agora, a menos que a receita da sua empresa provavelmente tenha diminuído seriamente ^^).
Observei a seguinte frase da página oficial: "O Magento agora está fornecendo um patch atualizado (SUPEE-10570v2) que não causa mais esse problema. Observe, no entanto, que esse novo patch não protege mais contra duas tarefas relacionadas ao manuseio de sessões de baixo risco. problemas de segurança contra os quais o SUPEE-10570 está protegido. " da página oficial supee-10570.
Na página de lançamento, podemos finalmente encontrar o arquivo v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).
Eu investiguei as modificações em detalhes. Finalmente, parece que a equipe do magento decidiu deixar uma parte de segurança do patch. Espero que essa falha de segurança não cause danos graves (é pouco crítico de acordo com a nota oficial).
Depois de reverter v1 + aplicar v2, lembre-se de que os seguintes arquivos sejam revertidos como seu estado inicial (antes da aplicação da v1):
PS: obviamente, alguns outros arquivos também são modificados, verifique em conformidade.
fonte
app/etc/applied.patches.list
(não tenho certeza se isso estava nas notas de versão do começo)
Problemas conhecidos
Esses dois problemas conhecidos estão associados ao uso de tags HTML no atributo SKU de um produto:
Invalid value in SKU column. HTML tags are not allowed.
HTML tags are not allowed in SKU attribute.
Nas notas de atualização :
Se o patch não for aplicado durante o patch
lib/Zend/Mail/Transport/Sendmail.php
, isso pode significar que a instalação do Magento foi corrigida anteriormente com SUPEE-9652v1 em vez de SUPEE-9652v2. A solução recomendada é reverter o patch SUPEE-9652v1 e aplicar SUPEE-9652v2 antes de aplicar o SUPEE-10570.fonte
Eu tive o mesmo problema que o @DarkCowboy depois de aplicar o patch ao Magento CE 1.7.0.2.
Depois de optar por me registrar como um novo cliente durante a finalização da compra, fazer o pedido cria o pedido e o cliente, mas, em vez de exibir a página de sucesso do pedido, sou redirecionado para a página inicial e desconectado.
A solução que encontrei é reverter a ordem dos blocos de código nas alterações para
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
.Comparando a versão corrigida com o mesmo arquivo no Magento CE 1.9.3.8, encontrei os novos blocos para validar a expiração da sessão e o carimbo de data e hora da senha em uma ordem diferente.
Magento CE 1.9.3.8 - Linhas 476-491:
Magento CE 1.7.0.2 - Linhas 414-430:
Isso resulta no valor de
$validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
ser maior que$sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
, o que significa que o método sempre retorna falso e a validação falha.Alterar o código no Magento CE 1.7.0.2 para corresponder à versão no Magento CE 1.9.3.8 corrige o problema.
O código resultante para Magento CE 1.7.0.2 - Linhas 414-430:
Sugiro que você crie seu próprio arquivo de correção e aplique diretamente no arquivo principal (é assim que eu costumo abordar a correção de bugs no núcleo). Isso facilitaria a reversão se o Magento emitir uma versão 2 do patch.
fonte
useValidateSessionPasswordTimestamp()
retornandofalse
. (uma mudança de linha no mesmo arquivo)Vimos uma página em branco no / checkout / carrinho após aplicar o SUPEE-10570 e compilar. Apenas para esclarecer: com o compilador desativado, tudo correu bem; com o compilador ativado, só conseguimos ver uma página em branco do carrinho quando logado sem nenhuma entrada de log (mesmo depois de ativar todos os logs possíveis e modo de desenvolvedor).
A solução foi alterar a função
getPasswordTimestamp()
emapp/code/core/Mage/Customer/Helper/Data.php
(é claro que significaapp/code/local/Mage/Customer/Helper/Data.php
:!) E usar emMage::getSingleton('core/resource')
vez deMage::getModel('customer/customer')
ouMage::getSingleton('customer/session')
. Então substitua a função inteira, por exemplo, com estas linhas de código:Depois de recompilar o problema se foi. Mais alguém com esse problema?
Explicação em alemão aqui .
fonte
1.7.0.0
Patch:
PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh
Este erro ocorre se você ainda não aplicou o SUPEE-9652 ou SUPEE-9767
Aplique esses patches para corrigir o problema.
fonte
1.7.0.0
PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh
Arquivo de Patchapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php
O patch para 1.7.0.0 adiciona apenas uma constante:
No entanto, adiciona o uso de duas novas constantes, notadamente esta:
Isso resulta no erro:
O conserto:
Adicione uma definição para esta segunda constante acima ou abaixo da primeira constante adicionada por este patch.
Até agora não vi esse problema em nenhum dos 1,9. ou 1.14.x patches, porque eles definem a constante corretamente.
fonte
const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';
ao topo do arquivo, como é feito na maioria das outras versões deste patch.A primeira coisa que você deve verificar, se você aplicou a versão correta do SUPEE-6788 ou SUPEE-7405 anteriormente, se não reverter a versão errada e, em seguida, aplique a versão correta do SUPEE-6788 / SUPEE-7405.
Em seguida, tente novamente aplicar o SUPEE-10570.
fonte
Os arquivos abaixo são atualizados / adicionados após o patch aplicado SUPEE - 10570 no EE
O @DarkCowboy forneceu uma lista de arquivos diferentes dos arquivos EE :
Algumas notas importantes
password_created_at
criado na tabela de atributos do cliente.Os arquivos acima são usados para criação e validação. Quando um problema de sessão ocorre na finalização da compra ou na verificação de logon do usuário, qualquer um dos arquivos acima é substituído no pool local ou Qualquer
password_created_at
atributo é criado na tabela de atributos do cliente e o valor apropriado é armazenado nessa tabela.fonte
Minha versão do magento é ver. 1.9.1.0
Vimos uma página em branco no / checkout / carrinho após aplicar o SUPEE-10570 e compilar. Apenas para esclarecer: com o compilador desativado, tudo correu bem; com o compilador ativado, só conseguimos ver uma página em branco do carrinho quando logado sem nenhuma entrada de log (mesmo depois de ativar todos os logs possíveis e modo de desenvolvedor).
Causa:
a função getPasswordTimestamp será chamada duas vezes quando estiver logado e visite / checkout / carrinho.
compilador desabilitado tanto o trabalho de invocação.
habilitar o compilador apenas o primeiro trabalho de chamada, a segunda chamada falhou.
alguém pode explicar e dar a boa solução?
fonte
Um problema com o 1.7.0.2 que notei é o seguinte:
Adicione o produto ao carrinho e vá ao Google Checkout
Clique em "Register"
O PROBLEMA COMEÇA AQUI
5. Redirecionar automaticamente para a página inicial. Você não vê a confirmação do número do pedido. Mas, na realidade, o pedido é feito e a conta do cliente criada.
fonte
Eu encontrei o mesmo problema, o Magento 1.9.3.8 adicionou esse método à classe Mage_Customer_Helper_Data
Se você substituir essa classe na pasta Local (não é a melhor prática), poderemos ter erros gerados por essa classe.
fonte
Esse patch quebrou alguns dos gerenciadores de hierarquia do CMS para usuários de EE.
Isso ocorre devido à seguinte linha de correção, responsável por escapar dos nomes das lojas / sites e corrigir o APPSEC-1873/1979/1980.
Ele deve mostrar o seletor de loja à esquerda, mas mostra o html à direita. Se você realmente precisar dessa funcionalidade, precisará fazer uma chamada de segurança versus funcionalidade, o que não é ótimo.
fonte
O mesmo erro exato de Tyler, no patch Magento 1.9.2.4 PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh
fonte
Se você possui alguma ferramenta de detecção de patches, provavelmente precisará modificar a detecção
SUPEE-9562
porqueSUPEE-10570
modifica o mesmo arquivo:fonte
O patch foi alterado pelo Magento silenciosamente. Aqui mostrado com patch para o Magento 1.8.1.0-1.9.0.1. No primeiro download eu tenho o arquivo
Alguns dias depois eu tenho o seguinte arquivo
Diff mostra que o arquivo anterior contém arquivos do Magento Enterprise Edition que contêm a licença incorreta "Contrato de licença do usuário final do Magento Enterprise Edition". Isso foi corrigido para "Open Software License (OSL 3.0)".
fonte
Você pode receber o seguinte erro
Hunk #3 FAILED at 17
depois da linhaIsso aconteceu comigo na versão Magento 1.10.0.2EE. Isso aconteceu porque o patch SUPEE-6285 não foi aplicado.
fonte