Novo patch supee-6788 como aplicar o patch

Após semanas de espera pelo patch de hoje (27.10.2015), foi lançado: SUPEE-6788

Muitas coisas foram corrigidas e também é encorajado a revisar os módulos instalados quanto a possíveis vulnerabilidades.

Abro este post para obter algumas informações sobre como aplicar o patch. Quais são as etapas para aplicar o patch? Para meu entendimento, estas são as etapas:

1. Corrija os módulos com a funcionalidade de administrador que não está na URL do administrador
2. Corrija módulos que usam instruções SQL como nomes de campos ou campos de escape
3. Blocos de lista branca ou diretivas que usam variáveis ​​como {{config path=”web/unsecure/base_url”}}e{{bloc type=rss/order_new}}
4. Abordando a exploração potencial com o tipo de arquivo de opção personalizada (não faço idéia de como fazer isso)
5. Aplique o patch

Esse é o procedimento correto?

Em geral, você pode aplicar o patch como todos os anteriores. Dê uma olhada na documentação oficial e verifique este post do SE . Mas sim, existem alguns pontos adicionais que você deve verificar ao aplicar esse patch. Byte / Hypernode tem um bom post sobre isso.

1. Verifique se o seu tema tem um costume template/customer/form/register.phtmlou costume template/persistent/customer/form/register.phtml. Se for esse o caso, verifique se ele inclui a form_key.
2. Verifique se o seu tema tem um costume layout/customer.xml. Se for esse o caso, certifique-se de aplicar as alterações necessárias do patch ( customer_account_resetpasswordfoi alterado para customer_account_changeforgotten).
3. Você usa variáveis ​​não padrão em páginas do CMS, blocos estáticos ou modelos de email? Em seguida, verifique se você os colocou na lista de permissões. Veja esta pergunta SE para aprender como colocar variáveis ​​/ blocos na lista de permissões.
4. Você executa o cron.phpvia HTTP? Certifique-se de usar melhor cron.sh. Se isso não for possível, certifique-se de chamar o cron.php via CLI PHP. Se, por algum motivo, você não puder configurar um cronjob real e precisar executá-lo via HTTP, consulte esta pergunta SE
5. Verifique se todas as suas extensões usam o "novo" roteamento de administrador. Você pode usar este plugin n98-magerun para verificar. Você também pode usar este script da CLI . Você também pode dar uma olhada nesta pergunta relacionada ao SE .
   6. Quando todas as suas extensões usarem o roteamento de administrador adequado, desative "Ativar o modo de compatibilidade de roteamento de administrador" em Sistema - Configuração - Admin - Segurança.
6. Se você usa o M2ePro, atualize-o para a versão mais recente, pois as versões antigas não funcionam com o novo patch.

Ao atualizar, exclua o arquivo dev/tests/functional/.htaccess. Não está mais presente no Magento 1.9.2.2. Mantê-lo significa que você ainda está vulnerável.

De qualquer forma, verifique sua página com o MageReport após a atualização para ver se tudo correu bem.

Há também uma postagem técnica no blog da Piotr , que descreve as mudanças críticas.

Há um arquivo de verificação que ajuda a identificar problemas: https://github.com/gaiterjones/magento-appsec-file-check

Eu fiz um script CLI com isso. https://github.com/Schrank/magento-appsec-file-check

Para o Nginx, certifique-se de bloquear o acesso ao cron.php e à pasta dev. Nós usamos este bloco:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

Acabei de aplicar o patch no meu 1.10.1 EE e isso causa efeitos colaterais nas telas nativas porque o núcleo não é compatível com APPSEC-1063:

Exemplo:

Em app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Você pode encontrar 2 addFieldToFilterchamadas não compatíveis com APPSEC-1063.

Isso está quebrando as grades Customer> Attribute, então você deve corrigir o patch usando o truque recomendado no pdf "SUPEE-6788-Technical% 20Details% 20.pdf" na seção APPSEC-1063

Mudando os vários

    $this->addFieldToFilter($field, 0);

(onde $ field contém instruções sql complexas (CASE .. WHEN THEN ...))

para dentro

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Tanto o supee-6788-toolbox como o gaiterjones não detectaram esse tipo de problema, verifiquei todos os outros -> addFieldToFilter ($ e nenhum parece estar causando o problema.

Outros arquivos principais do 1.10 afetados: (encontrados pela rhoerr's supee-6788-toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php 

Pode haver mais.