ti-enxame.com

Como desenvolver uma extensão segura do Joomla?

Antes de escrever minha primeira extensão, gostaria de entender como projetá-la o mais invulnerável possível.

Existe um conjunto de regras para escrever uma extensão segura do Joomla?

Eu posso imaginar apenas injeção SQL como possível ameaça, então eu sei que a entrada do formulário nunca pode ser inserida diretamente no comando SQL 'como está'.

Quais são os outros vetores de ataque que devo conhecer ao escrever um módulo ou plug-in personalizado?

7
miroxlav

Uma coisa principal que você apontou é a injeção de SQL. Isso é algo que algumas pessoas que eu vi parecem sentir falta completamente e começar a desenvolver usando non Padrões de codificação do Joomla e começar a escrever filas SQL usando mysql_* comandos.

Segunda coisa que eu meio que mencionei no primeiro ponto, que sempre segue os padrões de codificação do Joomla. O único momento em que você não deve é ​​quando o Joomla não fornece uma alternativa.

Em terceiro lugar, se a extensão cria uma pasta ou arquivo, garanta que você conceda as permissões corretas e não comece a criar a pasta chmod 777. Essa é a razão exata pela qual o K2, que é uma das extensões mais populares por aí, foi considerado vulnerável e removido temporariamente do JED.

Sempre use tokens com formulários. Isso garantirá que nenhum ataque não autorizado de outros sites possa ser executado. Para obter mais informações sobre isso, consulte o seguinte:

http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms

Se você não tiver certeza de que alguma coisa já tenha executado alguns testes, tente ir para Code Review Stackexchange , pois pode haver alguém disposto a verificar seu código para você.

Uma coisa que você pode fazer é dar uma olhada na Lista de Extensões Vulneráveis para ver as extensões que foram removidas temporariamente (até corrigidas) do Diretório de Extensões do Joomla por não serem seguras.

Espero que isso lhe dê algumas dicas e boa sorte com sua primeira extensão

8
Lodder

Seguindo a documentação oficial, aqui estão algumas etapas sobre o tópico Diretrizes de codificação segura :

  • Valide todos os dados obtidos da solicitação (POST, GET, COOKIES, etc.). Não confie no usuário e seja o mais rigoroso possível. Se você espera que um integer, não permita que um string seja aceito.

  • Uploads de arquivos - evite, sempre que possível, aceitar arquivos em páginas públicas da web. Se você precisar validar as meta informações do arquivo e fazer todas as verificações possíveis.

  • Construindo consultas SQL - entenda como as injeções SQL funcionam, mas também como você lida com erros de banco de dados. Quanto mais erros você exibir, mais informações você fornecerá sobre sua estrutura de banco de dados. Idealmente, você registra erros, mas não os exibe.

  • Proteger formulários usando um token

7
Valentin Despa

É principalmente seguro para a maioria das extensões. No entanto, tenha muito cuidado com qualquer coisa que possa precisar salvar/editar arquivos, filtragem ou validação inadequada pode criar um ponto de entrada.

Contanto que você use a API do JDatabase corretamente, você também deve estar protegido contra injeção de sql. Você pode ver com_content ou plg_system_loadpositon em uma instalação do Joomla para ajudar a descobrir alguns dos pontos mais delicados de várias APIs do Joomla (já que a documentação é um pouco difícil de seguir).

Também usando as APIs, se elas falharem e algum tipo de vulnerabilidade for usada, a correção provavelmente acabaria sendo uma atualização principal (se for o JDatabase, posso imaginar uma versão do Joomla dentro de uma hora se a descoberta for: D), e não uma atualização à sua extensão.

Essa é uma das principais falhas do código aberto: qualquer pessoa que pretenda causar danos possui todas as informações necessárias para fazê-lo. Se for uma extensão fechada (não disponível ao público), é provável que nunca haverá um problema.

Por fim, quanto mais simples a extensão for (menos código), maior a probabilidade de ela ser 'invulnerável'. À medida que uma extensão cresce, há muitos outros lugares em que pode ocorrer um pequeno erro ao criar um ponto de entrada.

4
Jordan Ramstad