5. Vulnerabilidades
• XSS – podia ser encontrada em “wp-admin/edit-
post-rows.php”
Regularizado na versão 2.3.1 fix final de 2007
• SQL Injection – Acesso sem autorização de
utilizadores na registados
Regularizado na versão 2.3.1 fix final de 2008
www.company.com
6. Vulnerabilidades
• SQL Injection – Reportado no componente RSS FEED iJoomla.
Não foi regularizado reportado a 16 de junho 2009
• Local file disclosure – Reportado no componente MooFAQ.
Não foi regularizado reportado a 11 de Junho 2009
• Broken Authentication Control – Afectava o sistema de autenticação do joomla, e
alterar a password do administrador
Regularizado, na versão 1.5.6 fix a 13 de Agosto de 2008
www.company.com
7. Vulnerabilidades
• SQL insertion vulnerability – Reportado no modulo de gestão de
taxonomias, inserir dados sem autorização.
Regularizado Para todas as versões Fix 19 de Junho 2009
• Security bypass – Reportado no modulo de views, podia modificar os
nós especificos ou classes sem autenticação
Regularizado Para todas as versões Fix 22 de Maio 2009
www.company.com
8. Prática
NIKTO projecto open-source, base de dados de 3300 scripts para testar
•
vulnerabilidades.
. / n i k t o . p l −h { u r l } −C −o f i c h e i r o r e p o r t . t x t
•
Devolve o id exemplo OSVDB-3092
•
The Open Source Vulnerability Database http://www.osvdb.org
•
alerta e ajuda a corrigir
www.company.com
9. Conclusão
• -É Positivo reportar / alertar as falhas que sejam encontradas
• -Ao divulgar uma vulnerabilidade num forum, alerta o desenvolvimento de correcções
• -Não divulgar é uma má pratica e prejudica a evolução do projecto
•
• -A causa comum de maior percentagem de vulnerabilidades é devido:
->má pratica de utilização da API, no desenvolvimento de novos
componentes / módulos /extensões
• ->Principalmente nos componentes comerciais
• -Para garantir a segurança, deverá ser aplicada em todo o ciclo de vida de software,
• metodologias apropriadas, desde a escolha de:
-Servidor web e a actualização do software
www.company.com
