A versão de Alfresco Enterprise 4.0.1 inclui correcções de dois problemas criticais de segurança. Estes problemas são:O API REST de SOLR permite acesso ao conteúdo do repositório sem autorização (ALF-13721) (existe só em versão 4.0)A exploração remota de código é possível através do processador de XSLT dos Web Scripts (ALF-13726) (existe em todas as versões antes de 4.0.1)Os usuários de edição de Alfresco Enterprise já receberem uma notificação sobre estes problemas com instruções de corrigi-los. Ambos estes problemas são corrigidos em versão 4.0.1. A correcção do problema com XSLT faz parte de versão 3.4.9, e o apoio tem um hotfix por 3.4.8.A próximo versão de edição de Alfresco Community vai ter estas correcções. Até lá, temos instruções para ajudar resolver os problemas.O API REST de SOLR permite acesso ao conteúdo do repositório sem autorizaçãoAcesso aos APIs de repositório através de HTTP usando os caminhos de /alfresco/s/api/solr, /alfresco/wcservice/api/solr, e /alfresco/wcs/api/solr não foi protegido pelo certificado de SSL de SOLR. Estes caminhos poderiam ser usados sem autorização para recobrar informação do repositório. Este problema existe ainda que não use o SOLR por pesquisa nem que tem configurado o SOLR.Este problema é corrigido facilmente pela adição de um pouco de XML ao arquivo de web.xml. Se olhar ao arquivo de web.xml, vai ver um elemento de tipo de security-constraint (restrição de segurança) que corresponde ao padrão de "/service/api/solr":<security-constraint>
<web-resource-collection>
<web-resource-name>SOLR</web-resource-name>
<url-pattern>/service/api/solr/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>repoclient</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
O problema é que o web script permanece acessível através de mais padrãos. Para corrigir este baraco, é necessário adicionar mais regras nesta maneira:<security-constraint>
<web-resource-collection>
<web-resource-name>SOLR</web-resource-name>
<url-pattern>/s/api/solr/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>repoclient</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>SOLR</web-resource-name>
<url-pattern>/wcservice/api/solr/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>repoclient</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>SOLR</web-resource-name>
<url-pattern>/wcs/api/solr/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>repoclient</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
A exploração remota de código é possível através do processador de XSLT dos Web ScriptsAntes, o processador de XSLT de Alfresco permitia os modelos de XSLT que foram usados pelos formas de web e de web scripts para chamar métodos java arbitrários através dos extensões Xalan de Apache. Qualquer usuário com permissão a fazer upload de um webscript o modelo de XSLT podia explorar este buraco de segurança. Agora evitamos qualquer namespace de extensões alem de original namespace de Alfresco "alf".Com este correcção, os extensões Xalan não podem executar métodos arbitrários porque os únicos extensões que são permitidos são de Alfresco. Se você necessitar chamar seu próprio código de Java através de extensão Xalan, vai ser necessário configurar o processador de XSLT para o permitir.Se a gente não quer esperar pelo lançamento da próxima versão de Community Edition, pode usar o código ligado ao relatório em JIRA para remendar seu repositório.
