Your SlideShare is downloading. ×
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla

3,487

Published on

Monografia de minha pós-graduação em engenharia de sistemas. Só para variar, Segurança e Joomla!

Monografia de minha pós-graduação em engenharia de sistemas. Só para variar, Segurança e Joomla!

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,487
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE SISTEMAS JÚLIO CÉSAR DE PAULA COUTINHO PROCESSO DE TESTES DE VULNERABILIDADES EM COMPONENTES MVC PARA CMS JOOMLA VILA VELHA – ES 2011
  • 2. JÚLIO CÉSAR DE PAULA COUTINHO PROCESSO DE TESTES DE VULNERABILIDADES EM COMPONENTES MVC PARA CMS JOOMLA Monografia apresentada ao Curso de Pós-Graduação em Engenharia de Sistemas da Escola Superior aberta do Brasil como requisito para obtenção do título de Especialidade em Engenharia de Sistemas, sob orientação do Prof. Ms. Cleyverson Pereira Costa. VILA VELHA – ES 2011
  • 3. JÚLIO CÉSAR DE PAULA COUTINHO PROCESSO DE TESTES DE VULNERABILIDADES EM COMPONENTES MVC PARA CMS JOOMLA Monografia aprovada em .. de 2011. Banca Examinadora VILA VELHA – ES 2011
  • 4. A minha esposa Rosana e meu filho Bruno pelo apoio e paciência demonstrados em todos os momentos desta minha caminhada.
  • 5. AGRADECIMENTOS À Deus pela oportunidade da vida, saúde e vontade de aprender, a minha família pelo apoio e paciência.
  • 6. “O ditado de que os sistemas de segurança têm de vencer sempre e o atacante só tem de vencer uma vez é verdadeiro.” (Dustin Dykes)
  • 7. RESUMO Palavras-chave: Desenvolvimento de extensões, CMS Joomla, Vulnerabilidades em componentes Este estudo tem objetivo demonstrar as fases de desenvolvimento de um componente MVC para o CMS Joomla com ênfase nas vulnerabilidades mais comuns, tipos de ataques e formas de proteção extras a serem empregadas em componentes e websites desenvolvidos em Joomla! A facilidade de uso e baixa curva de aprendizagem exigida pelo CMS, levam o usuário a crer na facilidade de desenvolver componentes MVC para o mesmo, ignorando a necessidade de grande conhecimento técnico para tal empreendimento. Invasões em websites joomla, seja através de componentes vulneráveis, seja através de templates piratas, ou ainda pelo uso de provedores desatualizados e permissões inadequadas, enfraquecem o projeto e prejudicam a comunidade como um todo, o enfraquecimento de projetos open source acabam por fortalecer projetos de código-fonte fechados. Componentes MVC bem desenvolvidos, seguindo preceitos de segurança, aliados ao uso de templates qualificados e a escolha de provedores idôneos, com aplicação correta das permissões em diretórios e arquivos minimizam consideravelmente o risco de ataques bem sucedidos. Este conjunto de fatos resulta em credibilidade para a marca Joomla! como um todo possibilitando desta forma um ganho real para toda a sociedade e comunidade Joomla! em geral.
  • 8. LISTA DE FIGURAS Figura 1 – Camadas do CMS Joomla!..........................................................30 Figura 2 – API do CMS Joomla! Fonte: http://docs.joomla.org/, (2009)........34 Figura 3 – Classe JFACTORY Fonte: http://docs.joomla.org/, (2009) ..........35 Figura 4 – MVC Fonte: http://pt.wikipedia.org/wiki/MVC, (2011) ..................42 Figura 5 – Classe JModel) Fonte: http://docs.joomla.org/, (2009) ................44 Figura 6 – Classe JView) Fonte: http://docs.joomla.org/, (2009) ..................45 Figura 7 – Classe JController Fonte: http://docs.joomla.org/, 2009 ..............46 Figura nr 8 – Instanciando o BD Fonte: autoria própria (2011).....................47 Figura nr 9 – executando consulta Fonte: autoria própria (2011) .................47 Figura 10 – Executando a consulta Fonte: autoria própria (2011)................47 Figura 11 – apresentação de resultados Fonte: autoria própria (2011)........48 Figura 12 – resultado em array) Fonte: autoria própria (2011) .....................48 Figura 13 – Query completa Fonte: autoria própria (2011)...........................48 Figura 14 – query para atualização Fonte: autoria própria (2011)................49 Figura 15 – Método getEscaped Fonte: autoria própria (2011) ....................50 Figura nr 16 – Método geNullDate Fonte: autoria própria (2011) .................50 Figura nr 17 – Método getNullRows Fonte: autoria própria (2011)...............50 Figura nr 18 – Método getErrorNum) Fonte: autoria própria (2011) .............51 Figura 19 – Parte do código-fonte do arquivo joomla.php Fonte: autoria própria (2011) ...............................................................................................54 Figura nr 20 – continuação código-fonte joomla.php Fonte: autoria própria (2011) ...........................................................................................................55 Figura 21 – parte do código-fonte do arquivo helper.php Fonte: autoria própria (2011) ...............................................................................................56
  • 9. Figura 22 – Formulário para inserção de dados em componente MVC via backend Fonte: autoria própria (2011)..........................................................60 Figura nr 23 – Tipo de ataque CSRF Fonte: http://www.google.com/images/, (2011) ...........................................................................................................68 Figura nr 24 – Defacement Fonte: http://www.google.com/images/, (2008).68 Figura 25 – Iniciando o backtrack em máquina virtual..................................72 Figura 26 – Backtrack pronto para uso em máquina virtual Fonte: autoria própria (2011)...............................................................................................73 Figura nr 27 – A aplicação é a ponta do iceberg Fonte: autoria própria (2010) ......................................................................................................................77 Figura 28 – JRoute Fonte: autoria própria (2011).........................................85 8.8.3 Verificando o Token.............................................................................85 Figura nr 29 – JRequest Fonte: autoria própria (2011).................................85 Figura 30 – JRequestGet Fonte: autoria própria (2011) ...............................85 Figura 31 – $_Get[] Fonte: autoria própria (2011) ........................................88 Figura 32– SQLInjection Fonte: autoria própria (2011).................................88 Figura nr 33 – String SQLInjection Fonte: autoria própria (2011) .................89 Figura nr 34 – String SQLInjection Fonte: autoria própria (2011) .................89 Figura 35 – String Request Fonte: autoria própria (2011) ............................90 Figura 36 – String HmtlSpecial Fonte: autoria própria (2011).......................90 Figura nr 37 – JEXEC Fonte: autoria própria (2011) ....................................91
  • 10. LISTA DE SIGLAS JOOMLA! – Sistema Gerenciador de Conteúdos Open Source distribuído sob licença GNU/GPL cuja pronúncia correta é “DJUMLA!” LAMP – Linux Apache Mysql PHP CMS – Sistema Gerenciador de Conteúdos WEBDESIGN – Projeto para Web WEBSITE – Conjunto de páginas relacionadas a determinada instituição ou pessoa codificada em linguagem de marcação de texto ou linguagem de programação para a web, renderizadas por um navegador BROWSER – Navegador Web MVC – Padrão de projeto de desenvolvimento de software que divide as camadas em Modelo Visão e Controlador HACKER – usuário com grande conhecimento em informática geralmente aplicado para o bem comum CRACKER – usuário com grande conhecimento em informática geralmente aplicado para o mal através de invasões em sistemas web com intuito de furto de dados sensíveis pessoais e corporativos
  • 11. SCRIPTKIDDIES – usuários novatos que buscam na internet informações úteis para invadir websites e sistemas em busca de reconhecimento HASH – impressão digital usada em criptografia de senhas FORK – Separação, briga TOKEN – Chave para acesso a ambiente seguro LDAP – Servidor de acesso muito utilizado em intranet
  • 12. SUMÁRIO 1. INTRODUÇÃO ......................................................................................................16 1.1 PALAVRAS-CHAVE ..................................Erro! Indicador não definido. 1.2 EXPOSIÇÃO DO ASSUNTO..................................................................17 1.3 PROBLEMA DE PESQUISA ..................................................................18 1.4 JUSTIFICATIVA......................................................................................18 1.5 OBJETIVOS............................................................................................19 1.5.1 Geral ...................................................................................................19 1.5.2 Específicos.........................................................................................19 1.7 METODOLOGIA DE PESQUISA............................................................20 2. FUNDAMENTAÇÃO TEÓRICA............................................................................21 2.1 WEBDESIGN..........................................................................................21 2. 2 CMS.......................................................................................................21 2. 3 HISTÓRICO DO CMS JOOMLA!...........................................................23 2. 4 VERSÕES DO CMS JOOMLA! .............................................................24 2.5 JOOMLA! NO MERCADO WEB .............................................................25 2. 6 QUEM USA JOOMLA!...........................................................................26 2. 7 JOOMLA! E O WEBDESIGNER............................................................26 2. 8 EXTENSÕES PARA JOOMLA! .............................................................28 2.9 SEGURANÇA E JOOMLA!.....................................................................28 3. JOOMLA! FRAMEWORK.....................................................................................30 3.1 CAMADA APLICATIVO ..........................................................................31 3.2 CAMADA EXTENSÕES .........................................................................32 3.3 FUNCIONAMENTO DO FRAMEWORK .................................................32
  • 13. 4. JOOMLA! API.......................................................................................................34 4.1 JFACTORY.............................................................................................35 4.1.1 Método Getacl....................................................................................35 4.1.2 Método Getapplication......................................................................36 4.1.3 Método Getcache...............................................................................36 4.1.4 Método Getconfig ..............................................................................37 4.1.5 Método Getdbo ..................................................................................37 4.1.6 Método Getdocument........................................................................37 4.1.7 Método Geteditor...............................................................................38 4.1.8 Método Getlanguage .........................................................................38 4.1.9 Métdod Getmailer ..............................................................................39 4.1.10 Método Getsession..........................................................................39 4.1.11 Método Gettemplate ........................................................................39 4.1.12 Método Geturi ..................................................................................40 4.1.13 Método Getuser ...............................................................................40 4.1.14 Método Getxmlparser......................................................................41 5. DESENVOLVIMENTO DE COMPONENTE MVC.................................................42 5.1 O MODELO (MODEL) ............................................................................42 5.2 A VISÃO (VIEW).....................................................................................43 5.3 O CONTROLADOR (CONTROLLER) ....................................................43 5.4 CLASSES UTILIZADAS NA IMPLEMENTAÇÃO DE COMPONENTES MVC..............................................................................................................44 5.4.1 JModel ................................................................................................44 5.4.2 JView ..................................................................................................44 5.4.3 JController..........................................................................................45 5.4.4 JDATABASE.......................................................................................46
  • 14. 5.4.4.1 Consultas com JDATABASE......................................................47 5.4.4.2 Atualizações de registros com JDATABASE.............................49 5.4.4.3 Outros recursos do objeto JDATABASE ....................................49 5.4.4.3.1 getEscaped()...........................................................................49 5.4.4.3.2 getNullDate() ...........................................................................50 5.4.4.3.3 getNumRows() ........................................................................50 5.4.4.3.4 getErrorNum();...............................................................................50 5.5 FERRAMENTAS CASE PARA O DESENVOLVIMENTO DE COMPONENTE MVC...................................................................................51 5.5.1 Aptana ................................................................................................51 5.5.2 Alphaplug ...........................................................................................51 5.5.3 GEPAC................................................................................................52 5.6 Tipos de componentes MVC................................................................52 5.7 Falhas de segurança no componente, encontradas na fase de testes ......................................................................................................................52 5.8 Criptografia das senhas no Joomla!...................................................54 5.8.1 Joomla.php.........................................................................................54 5.8.2 getCryptedPassword.........................................................................55 5.8.3 HASH ..................................................................................................57 5.8.4 MD5.....................................................................................................58 5.9 Formas de correção das falhas encontradas.....................................58 6. VULNERABILIDADES E DEFACEMENT’S .........................................................60 6.1 SQL INJECTION ....................................................................................61 6.2 Campos de texto em formulário sem filtragem..................................62 6.3 Manuseando campos de texto em Formulário com PHP ..................63 6.3.1 Tipos não esperados.........................................................................64 6.4 CROSS-SITE SCRIPTING (XSS)...........................................................65
  • 15. 6.5 Directory Scanning...............................................................................67 6.6 CROOS-SITE REQUEST FORGERY (CSRF) .......................................67 6.7 Defacement ...........................................................................................68 7. TESTES DE PENETRAÇÃO ................................................................................70 7.1 Teste caixa preta...................................................................................71 7.2 Teste caixa branca................................................................................71 7.3 Testes de vulnerabilidades em componente MVC.............................71 7.4 Bactrack ................................................................................................71 7.5 Nikto.......................................................................................................73 7.6 ZeroDayscan .........................................................................................73 7.7 OWASP ..................................................................................................74 7.7.1 Requisitos e funcionamento do OWASP.........................................74 8. MELHORES PRÁTICAS PARA EVITAR INVASÕES ..........................................77 8.1 O provedor de hospedagem ................................................................78 8.2 Instalação automática do Joomla! ......................................................78 8.4 URL’s amigáveis...................................................................................80 8.5 Aplicação correta das permissões......................................................80 8.6 Atualização da versão do CMS............................................................83 8.8 Protejam-se de ataques CSRF.............................................................84 8.8.1 POST...................................................................................................84 8.8.2 GET .....................................................................................................84 8.8.3 Verificando o Token ..........................................................................85 8.8.4 Procedimentos complementares .....................................................85 8.9 Validação de campos nos formulários de componentes..................86 8.9.1 Validação de campos no lado cliente ..............................................87 8.9.2 Validação de campos no lado do servidor ......................................87
  • 16. 8.9.3 Validação de formulário contra SQL Injection ................................87 8.9.4 Validação de formulários contra ataques XSS................................89 8.10 Validação do nível de permissão dos usuários ...............................90 8.11 Segurança na programação de componente MVC ..........................90 CONCLUSÃO ...........................................................................................................93 REFERÊNCIAS BIBLIOGRÁFICAS.........................................................................96
  • 17. 1. INTRODUÇÃO O presente trabalho abordará o tema Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla. O problema consiste em demonstrar que componentes em desacordo com os padrões de projeto MVC e boas práticas de segurança, podem facilitar invasões a websites desenvolvidos com CMS Joomla! O desenvolvedor deve preocupar-se em testar o seu componente contra os tipos de ataques mais conhecidos, fazendo uso de aplicativos e técnicas utilizadas em testes de penetração, escaneamento de servidores e aplicativos, não se esquecendo de validar todos os campos de entrada em formulários. A invasão de websites desenvolvidos em CMS Joomla! são em sua grande maioria possíveis através de falhas no servidor de hospedagem, porém, é crescente o número de ataques do tipo code injection realizados via extensões vulneráveis. Independente da causa que possibilitou a efetivação do ataque, um website invadido prejudica não só o projeto, mas toda a comunidade que utiliza o CMS Joomla! 1.2 EXPOSIÇÃO DO ASSUNTO Este trabalho aborda testes de vulnerabilidades em componente MVC desenvolvido para o CMS Joomla!
  • 18. 1.3 PROBLEMA DE PESQUISA Qual a relação das vulnerabilidades no desenvolvimento de componente MVC para o CMS Joomla com invasões sofridas em websites com o CMS? 1.4 JUSTIFICATIVA Com o fortalecimento do “software livre” produtos de excelente qualidade estão disponíveis, particularmente para o mercado web. Sistemas de Gerenciamento de Conteúdos são programas que auxiliam no desenvolvimento de um webdesign seguindo os conceitos previstos na Web 2.0. O CMS Joomla! destaca-se por sua facilidade de uso e baixa curva de aprendizagem, tendo sido adotado pela maioria dos Órgãos do Governo Federal. As extensões utilizadas pelo CMS Joomla são classificadas em componentes, módulos, plugins e templates, cada uma com sua função específica e requisitos prévios obrigatórios. O desenvolvimento de um componente é processo extremamente técnico que exige conhecimento em programação orientada a objetos e observância na utilização de padrões de projeto MVC. Entretanto, muitos desenvolvedores criam novas soluções utilizando a programação procedural ou mesmo, deixam de testar e validar os campos de entrada de dados de suas extensões, abrindo uma brecha perigosa na segurança do CMS Joomla! Com popularização da Internet e o advento das mídias sociais, diminui-se consideravelmente o tempo de resposta a boatos e situações impostas. As empresas e instituições precisam possuir um website ou portal de qualidade, integrado às mais importantes mídias sociais, sob pena de verem suas marcas e reputações manchadas pelos boatos da rede. Mais do que 24/7, os projetos web devem prover 24/7/365. No quesito desenvolvimento web, o CMS Joomla! com seu poder de extensibilidade é a melhor opção open source do mercado.
  • 19. 1.5 OBJETIVOS 1.5.1 Geral Descrever um processo de análise de testes de vulnerabilidades no desenvolvimento de componente MVC para o CMS Joomla. 1.5.2 Específicos  Demonstrar o desenvolvimento de um componente MVC para Joomla;  Descrever as principais vulnerabilidades existentes;  Demonstrar falhas de segurança no componente, encontradas na fase de testes;  Demonstrar formas de correção das falhas encontradas. 1.6 DELIMITAÇÃO DO TRABALHO Demonstrar as fases do processo de desenvolvimento de um componente MVC para o CMS Joomla, explorar as principais falhas de segurança e melhores práticas, para evitar o sucesso de possíveis ataques de crackers.
  • 20. 1.7 METODOLOGIA DE PESQUISA Quanto ao objetivo será utilizada a metodologia de pesquisa do tipo Exploratório- Descritiva e a técnica a pesquisa bibliográfica. Análise dos dados coletados através da lista oficial de componentes vulneráveis do projeto Joomla, lista de websites que sofreram ataques do tipo defacement disponível no website H-Zone, leitura e consulta à livros especializados no desenvolvimento de extensões MVC e segurança para a Web e websites especializados no assunto, na rede mundial de computadores (INTERNET).
  • 21. 2. WEBDESIGN, CMS E JOOMLA 2.1 WEBDESIGN O webdesign sempre foi relegado à segundo plano nas Instituições Governamentais e Empresas Privadas. Via de regra, ficava à cargo do “menino do site” a incumbência de desenvolver o website ou portal corporativo. Entretanto, os websites deixaram de ser apenas folders decorativos e passaram a ser “vetores” de informação em tempo real. É praticamente impossível pensar em websites sem acesso a banco de dados, o velho website estático com HTML puro está praticamente extinto e o webdesigner fica em situação difícil dependendo do “amigo programador enrolado” para desenvolver os códigos relacionados à programação. Não cabe ao webdesigner desenvolver código e sim atender aos requisitos levantados em relação a usabilidade, acessibilidade, persuasão e política de webmarketing do projeto, traduzidos no design de página, design de site, design de conteúdo e design de navegação. Segundo Nielsen (2000), Qualquer empresa que torne seu site fácil de usar terá uma grande vantagem sobre seus concorrentes, independente do setor em que se encontra. 2.2 CMS O significado de CMS é Content Management System ou simplesmente Sistema Gerenciador de Conteúdos. O CMS é um framework, que possui todos os insumos necessários para o desenvolvimento de um webdesign. Todas as etapas do
  • 22. processo são implementadas com a utilização do CMS. O design de página e design de site ficam a cargo do template que é a camada de visão. O design de conteúdo é o foco principal do CMS, permitindo um gerenciamento rápido e simples, possível a qualquer pessoa com o mínimo de conhecimento em um editor de texto. O CMS pode ter suas funcionalidades extendidas com a utilização de programas específicos que permitem acoplar ao projeto, determinada função que até então não existia no mesmo. Por exemplo, um álbum de fotos. Existem vários projetos relacionados a CMS, disponíveis sob licença GNU/GPL, destacando-se: Joomla, Drupal e Xoop’s. Segundo Memória (2006), Projetos sérios para a Internet são essencialmente multidisciplinares, envolvendo diferentes áreas do conhecimento. A presença de profissionais especializados em diferentes disciplinas está cada vez maior nos dias atuais e o webmaster, ou faz tudo, morreu. Mas será essa realmente a realidade do mercado brasileiro? Quantos websites sérios e de sucesso foram desenvolvidos pelo faz tudo, ou simplesmente freela? As produtoras resistiam em utilizar ferramentas gratuitas para seus clientes com receio de encolher o valor do produto final que ofereciam. Mas o mercado valoriza soluções open source, sempre em evolução. Arquitetos, analistas e gerentes estão restritos a instituições governamentais, grandes agências e empresas que podem manter um time de desenvolvimento multidisciplinar. Projetos de médio e pequeno porte são desenvolvidos por agências menores que não possuem a estrutura multidisciplinar ideal.
  • 23. Os Gerenciadores de Conteúdos, ou CMS, ressuscitaram e trouxeram de volta ao mercado, com força total, a figura do webmaster, ou faz tudo. A pequena curva de aprendizagem da maioria dos CMS permite que em pouco tempo sejam desenvolvidos projetos profissionais, seguros e dinâmicos. Porém, se o escopo é o desenvolvimento de novas funcionalidades ou layouts gráficos, conhecidos por templates, será exigido do profissional, conhecimentos relacionados a programação orientada a objetos, banco de dados, webdesign, webmarketing e noções de sistemas operacionais. 2.3 HISTÓRICO DO CMS JOOMLA! Joomla! (pronuncia-se djumla) é a transcrição fonética para a palavra Swahili "Jumla", que significa "todos juntos" ou "sob a forma de um todo". Esta palavra Swahili é de origem Árabe, usualmente entendida como "Total" ou "soma" e devido à influência dos comerciantes árabes está presente em outros idiomas. É um CMS “open Source”, distribuído gratuitamente, que funciona com a tecnologia LAMP (Linux Apcahe Mysql PHP). Infelizmente carece, enquanto a maioria dos projetos desenvolvidos sob a ideologia do “Software Livre, de uma documentação robusta e organizada. Na maioria das vezes a própria comunidade é quem busca documentar o projeto. Originou-se de uma briga entre os desenvolvedores do CMS Mambo e a empresa Miro, detentora da patente, quando a mesma decidiu criar uma fundação e de certa forma restringiu o acesso ao código-fonte.
  • 24. O projeto Joomla é mantido pela Open Source Matters, Inc. (OSM), uma organização sem fins lucrativos, constituída nos termos da lei dos Estados Unidos e do estado de Nova York. Oferece apoio organizacional, legal e financeiro para o projeto. A OSM foi criada para garantir que o projeto Joomla possa continuar existindo no futuro independentemente da participação de voluntários individuais. 2. 4 VERSÕES DO CMS JOOMLA! A primeira versão do Joomla, a 1.0, surgiu no ano de 2005 causando apreensão e perspectiva na comunidade tendo em vista a situação política do momento aliada ao fato de que o seu código-fonte mantinha todas as características do Mambo. Joomla! 1.5 foi lançado em janeiro de 2008 rompendo de vez com o Mambo através da implantação de um modelo orientado a objetos, seguindo padrões de projeto MVC, Factory e etc... e com override de template, característica que o tornou digno de um CMS dentro dos padrões da Web2.0. Em janeiro de 2011 foi lançada a nova versão do CMS, a 1.6, com grandes novidades e melhorias em relação as anteriores:  Uma nova “ACL” foi disponibilizada permitindo ao desenvolvedor a criação de níveis e grupos;  O gerenciamento de conteúdos foi simplificado com a exclusão das seções, que hierarquicamente, burocratizavam o uso do CMS;  A opção de websites em vários idiomas de forma nativa, sem a necessidade do uso de extensões de terceiros é outra melhoria considerável; e  O gerenciamento do tempo de publicação dos módulos era algo a muito esperado pela comunidade.
  • 25. O lançamento do Joomla! 1.7 está previsto para julho de 2011 e em 2012 deverá ser lançada a versão 1.8 do CMS. 2.5 JOOMLA! NO MERCADO WEB Existem vários CMS open source que usam a mesma tecnologia (LAMP) disponíveis no mercado, dentro eles podemos citar:  Drupal;  Xoop's;  Wordpress;  Moodle;  Magento. Os principais concorrentes do Joomla no mercado são Drupal e Xoop's, tendo em vista que os dois atuam no gerenciamento de conteúdo voltado a websites e portais. Muitas pessoas confundem e até mesmo comparam Wordpress com Joomla, mas, é preciso lembrar que o Wordpress é um excelente CMS voltado ao gerenciamento de “Blogs”. Moodle é um CMS voltado ao ensino à distância “EAD” modalidade E-Learning com várias opções de provas, questionários e interatividade acadêmica. Magento tem o foco em e-commerce “b2-c” ou “b2-b”. O grande diferencial do CMS Joomla em relação a todos os outros, sem dúvida, é a comunidade atuante em toda a parte do mundo, através de seus mais de 400.000
  • 26. usuários do fórum em diversos idiomas, 147 JUG'S (Grupo de Usuários) pelo mundo afora, organizando o evento oficial Joomla! Day, postando artigos na Joomla! Magazine, participando do Joomla! People. O CMS Joomla foi premiado diversas vezes, venceu o Best PHP Open Source Content Management System em 2007 e desde então firma-se enquanto melhor CMS open source do mercado. 2.6 QUEM USA JOOMLA! O CMS Joomla vem sendo utilizado em larga escala por grandes empresas e instituições governamentais, dentre elas podemos citar:  Danone;  Porsche do Brasil;  Ministério da Educação;  Departamento de Segurança da Informação e Comunicações da Presidência da República;  Ministério da Defesa;  Exército Brasileiro;  Aeronáutica;  Marinha. 2. 7 JOOMLA! E O WEBDESIGNER O CMS Joomla! É uma web app multiplataforma com baixa curva de aprendizagem, que permite que qualquer pessoa sem conhecimento técnico, possa gerenciar
  • 27. websites ou portais. Mas, Joomla é uma ferramenta, ele não faz nada. Em tese, o webdesign, seja um website, portal ou sistema é desenvolvido por uma equipe ou pessoa qualificada tecnicamente e hospedado em servidores idôneos e com o ambiente bem configurado e atualizado. Mas na prática, por tratar-se de “software livre” o que vêm ocorrendo é que as pessoas pensam que Joomla! faz tudo, que está tudo pronto e que não existe necessidade de investimentos capacitação ou contratação de mão de obra. O resultado, se traduz em potencial risco à marca e imagem das empresas e instituições, tendo em vista a probabilidade de ocorrer um grave incidente relacionado a segurança, seja através de defacement, SQL Injection, Denial of Service, xss ou PHP injection. A maioria dos ataques podem ser evitados com medidas básicas relativas ao Uso do CMS Joomla, que por si só é extremamente seguro, com ambiente administrativo acessado via usuário e senha, senha esta criptografada com Hash MD5. O Joomla! permite ainda a utilização de TOKEN e servidores LDAP. As melhores práticas de segurança estão relacionadas a: manter a versão do CMS atualizada, hospedar o projeto em servidores idôneos e bem configurados, utilizar url’s amigáveis e templates comerciais adquiridos nos clubes de template. O desenvolvimento de extensões MVC deve ser realizado apenas por programadores Orientados a Objetos, qualificados, ambientados com o framework do Joomla e que sigam orientações rígidas no sentido de proteger o código-fonte de suas extensões. Extensões têm papel fundamental enquanto programas que irão integrar-se ao projeto para estender suas funcionalidades. Ao serem instaladas passam a fazer parte do website Joomla! com acesso total ao banco de dados da aplicação. Se mal projetadas, podem abrir backdoors que permitirão incidentes de segurança causando danos irreparáveis ao webdesign, prejudicando desta forma o desenvolvedor, a marca do cliente e em última instância: “ O projeto Joomla! e toda a sua Comunidade.”
  • 28. 2. 8 EXTENSÕES PARA JOOMLA! Segundo North (2011), Extensões são programas que permitem estender as funcionalidades de um projeto desenvolvido com CMS Joomla! São divididas em extensões do core ou núcleo e extensões de terceiros. São classificadas em:  Componentes: são programas desenvolvidos para permitir algum tipo de funcionalidade até então inexistente no projeto, por exemplo um álbum de fotos. Componentes interagem com o banco de dados do website criando novas tabelas e relacionamentos;  Módulos: geralmente estão associados a algum componente e têm a função de mostrar determinada informação no website. Podem ser utilizados para integrar sistemas ou formulários legados, ao website;  Plugins: são scripts, pedaços de código que reagem à ação do usuário possibilitando determinado efeito no website. Por exemplo, o plugin de inserção de imagens em artigos de conteúdo;  Templates: responsáveis pela camada de visão, layout gráfico, design de página e design de site de um projeto desenvolvido com CMS Joomla;  Languages: são pacotes de idiomas que podem ser facilmente instalados no projeto desenvolvido com CMS Joomla, permitindo a internacionalização do mesmo. Caratti e Silva (2010), entendem que extensão é uma pequena aplicação desenvolvida com regras de construção estabelecidas pelo ambiente Joomla! 2.9 SEGURANÇA E JOOMLA!
  • 29. Mitnick (2005), defende que o departamento de tecnologia da informação de qualquer empresa deve ter um conjunto especial de políticas que o ajude a proteger os ativos de informações da organização. Segundo Hope e Walther (2009), criar dados de entrada anti-segurança e testar o software são as tarefas mais difíceis de fazer. Joomla é um CMS estremamente seguro, já recebeu prêmios relacionados ao tema, mas tem sido criticado por conta de ataques bem sucedidos, particularmente defacements. A falta de uma política séria voltada a segurança, a utilização de extensões vulneráveis e desenvolvedores sem capacitação técnica são os grandes responsáveis pelos problemas de segurança com o CMS Joomla! 2.10 CONSIDERAÇÕES PARCIAIS Houve uma época em que fazer “na mão” era sinônimo de conhecimento. Hoje, é no mínimo insensato não utilizar um CMS, para desenvolver um projeto web. Os gerenciadores de conteúdos permitem instalar funcionalidades e recursos fundamentais em qualquer projeto moderno. Joomla é um dos melhores gerenciadores de conteúdo da atualidade, possui uma comunidade forte e atuante ao redor do mundo e tem conseguindo destaque no governo brasileiro, sendo utilizado por grande parte das Instituições Governamentais.
  • 30. 3. JOOMLA! FRAMEWORK Framework é um arcabouço, em desenvolvimento de software, uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. Pode atingir uma funcionalidade específica, por configuração, durante a programação de uma aplicação. O framework dita o fluxo de controle da aplicação, chamado de inversão de controle. Figura 1 – Camadas do CMS Joomla! Fonte: http://docs.joomla.org/, 2009 Tudo no Joomla é construído sobre o seu framework, esta base constituída por classes de objetos que controlam, geram informações e coordenam as ações do Joomla. Possui vários pacotes:  o pacote aplicativo, que alimenta a camada aplicativo e contém a classe JApplication;  o pacote com as bibliotecas de cachê;  o pacote chamado de comum e que contém as classes básicas e as bibliotecas de compatibilidade com versões anteriores;  o pacote conector com bibliotecas para clientes como FTP e LDAP;  o pacote para a base de dados que contém a classe JDatabase e as bibliotecas necessárias;
  • 31.  o pacote documento com as bibliotecas necessárias para criar e apresentar páginas;  o pacote do sistema de arquivos com bibliotecas para interagir com o filesystem;  o pacote i18n com bibliotecas de internacionalização (idiomas);  o pacote de instalação com bibliotecas para poder instalar extensões (componentes, módulos, plugins, templates, etc);  o pacote de e-mail com bibliotecas;  o pacote modelo com bibliotecas o objeto de acesso de dados;  o pacote de parâmetros com bibliotecas para a manipulação de parâmetros;  o pacote de registro (registry) com bibliotecas de armazenamento de configurações;  o pacote de modelos com bibliotecas de templates;  o pacote de utilidades com diversas bibliotecas de uso geral;  a classe JFactory que permite instanciar os objetos do framework;  a classe JVersion que permite obter a versão do Joomla. O framework não pode ser acessado diretamente, mas o Joomla oferece uma ponte para criar seus vários objetos através do JFactory. Os plugins, são extensões que trabalham par e passo com o framework ampliando suas funcionalidades. Por exemplo, podemos ter um plugin que analisa o texto de uma página antes que seja apresentado e mude algumas das suas características substituindo partes do texto ou trocando alguns marcadores por imagens. 3.1 CAMADA APLICATIVO
  • 32. A camada aplicativo é formada por todos os objetos necessários para que o sistema funcione de forma integrada e coordenada. Esta camada também é a interface para as extensões. 3.2 CAMADA EXTENSÕES Esta camada é constituída por componentes, módulos e templates. Os componentes são aplicativos escritos para o Joomla que ampliam a funcionalidade do sistema. Por exemplo, um sistema de gerenciamento de weblinks ou de downloads. Os componentes são elementos incluídos no corpo da página. Os módulos também são pequenos aplicativos que podem ser incluídos em todas as páginas (ou apenas nas da sua escolha) no topo, nas laterais ou no rodapé. Exemplos são o módulo de login e o módulo de estatística do site. Templates são modelos de apresentação das páginas, a camada de visão. Controlam a disposição dos módulos e fornecem informações sobre a aparência e disposição do texto. 3.3 FUNCIONAMENTO DO FRAMEWORK Para produzir extensões para o Joomla é muito importante entender o mecanismo do sistema. Conhecendo o funcionamento do sistema fica mais fácil criar extensões que se integrem de forma harmônica e que incorporem a segurança e a coordenação oferecida pelo sistema. Simplicando as coisas ao máximo, o mecanismo é o seguinte: um script "acorda" o framework para que ele forneça os modelos (classes) necessários para produzir
  • 33. todos os objetos que vão compor o sistema. Usando o JFactory como ferramenta, o script vai criando todos os objetos necessários para o funcionamento do mesmo, ou seja, vai compondo a camada aplicativo povoando-a com objetos e com referências a bibliotecas. Quando esta camada estiver pronta e ativa, os componentes, módulos e templates são incorporados e os plugins são "ativados".
  • 34. 4. JOOMLA! API A “API” do Joomla! é chamada simplesmente de Joomla! Framework. Para tirar o melhor proveito do Joomla! Framework no desenvolvimento de extnesões MVC deve-se usar chamadas a API do Joomla, evitando-se ao máximo as chamadas diretas as bibliotecas. Figura 2 – API do CMS Joomla! Fonte: http://docs.joomla.org/, (2009)
  • 35. 4.1 JFACTORY Esta classe possui vários Métodos utilizados no desenvolvimento de componentes MVC, sendo a mais importante do framework. O código-fonte pode ser acessado no diretório/pasta /libraries/joomla/factory.php. Figura 3 – Classe JFACTORY Fonte: http://docs.joomla.org/, (2009) 4.1.1 Método GETACL O Método getACL obtém um objeto de autorização retornando uma referência para o objeto global JAuthorization, criando-o se ainda não existir. Referência: function &getACL( ). Exemplo de uso: $autoriza =& JFactory::getACL();
  • 36. 4.1.2 Método GETAPPLICATION O Método getApplication obtém um objeto aplicativo retornando uma referência para o objeto global JApplication, criando-o se ainda não existir. Referência: function &getApplication([mixed $id = null], [array $config = array()], [$prefix = 'J']) $id - (opcional) um identificador ou nome do cliente $config - (opcional) um array associativo da configuração Exemplo de uso: $aplicativo =& JFactory::getApplication(); 4.1.3 Método GETCACHE O Método getCache obtém um objeto cache retornando uma referência para o objeto global JCache. Referência: function &getCache([string $group = ''], [string $handler = 'callback'], [string $storage = null]) $group - (opcional) o nome do grupo cachê $handler - (opcional) o manipulador a ser usado $storage - (opcional) o Método de armazenamento Exemplo de uso: $cache =& JFactory::getCache();
  • 37. 4.1.4 Método GETCONFIG O Método getConfig obtém um objeto configuração retornando uma referência para o objeto global JRegistry, criando-o se ainda não existir. Referência: function &getConfig([string $file = null], [string $type = 'PHP']) $file - (opcional) o caminho (path) para o arquivo de configuração $type - (opcional) o tipo de arquivo Exemplo de uso: $config =& JFactory::getConfig(); 4.1.5 Método GETDBO O Método getDBO obtém um objeto banco de dados retornando uma referência para o objeto global JDatabase, criando-o se ainda não existir. Referência: function &getDBO( ) Exemplo de uso: $db =& JFactory::getDBO(); 4.1.6 Método GETDOCUMENT O Método getDocument obtém um objeto documento retornando uma referência para o objeto global JDocument, criando-o se ainda não existir.
  • 38. Referência: function &getDocument( ) Exemplo de uso: $documento =& JFactory::getDocument(); 4.1.7 Método GETEDITOR O Método getEditor obtém um objeto editor retornando uma referência para o objeto global JEditor. Referência: function &getEditor([string $editor = null]) $editor - (opcional) o editor que deve ser carregado, depende dos plugins instalados Exemplo de uso: $editor =& JFactory::getEditor(); 4.1.8 Método GETLANGUAGE O Método getLanguage obtém um objeto idioma retornando uma referência para o objeto global JLanguage, criando-o se ainda não existir. Referência: function &getLanguage( ) Exemplo de uso: $idioma =& JFactory::getLanguage();
  • 39. 4.1.9 Método GETMAILER O Método getMailer obtém um objeto mailer retornando uma referência para o objeto global JMail, criando-o se ainda não existir. Referência: function &getMailer( ) Exemplo de uso: $mail =& JFactory::getMailer(); 4.1.10 Método GETSESSION O Método getSession obtém um objeto sessão retornando uma referência para o objeto global JSession, criando-o se ainda não existir. Referência: function &getSession([array $options = array()]) $options - (opcional) uma array contendo as opções da sessão Exemplo de uso: $sessao =& JFactory::getSession(); 4.1.11 Método GETTEMPLATE O Método getTemplate obtém um objeto template retornando uma referência para o objeto global JTemplate, criando-o se ainda não existir.
  • 40. Referência: function &getTemplate( ) Exemplo de uso: $template =& JFactory::getTemplate(); 4.1.12 Método GETURI O Método getURI pbtém um objeto URI retornando uma referência para o objeto global JURI. Referência: function &getURI([ $uri = 'SERVER']) Exemplo de uso: $uri =& JFactory::getURI(); 4.1.13 Método GETUSER O Método getUser obtém um objeto usuário retornando uma referência para o objeto global JUser, criando-o se ainda não existir. Referência: function &getURI([ $id = NULL]) $id - (opcional) o usuário que deve ser carregado. Pode ser um inteiro ou string (a string é automaticamente transformada em ID) Exemplo de uso: $usuario =& JFactory::getUser('admin');
  • 41. 4.1.14 Método GETXMLPARSER O Método getXMLParser obtém um documento XML retornando uma referência para o objeto documento XML. Referência: function &getXMLParser([string $type = ' DOM'], [array: $options = array()]) $type - (opcional) o tipo de analisador de XML necessário: 'DOM', 'RSS' ou 'Simple' $options - (opcional) Usando 'DOM': Se ['lite'] for true ou não for definido, então domit_lite é usado Usando 'RSS': ['rssUrl'] a url rss a ser analisada Usando 'RSS': ['cache_time'] é o tempo de cache do feed. Se não definido, o default é 3600 seg Exemplo de uso: $parser =& JFactory::getXMLParser(); 4.2 CONSIDERAÇÕES PARCIAIS A Interface de Programação do Joomla segue padrões de projetos e seus métodos e classes auxiliam sobremaneira no desenvolvimento de novas aplicações para o CMS. A utilização de métodos é fundamental para ganharmos tempo e desenvolvermos extensões mais seguras e funcionais.
  • 42. 5. DESENVOLVIMENTO DE COMPONENTE MVC Uma das grandes vantagens do CMS Joomla é a possibilidade de estender as funcionalidades do projeto web com a utilização de extensões. Um componente é um sistema orientado a objetos, desenvolvido para desempenhar determinada função de forma integrada ao Joomla, possuindo geralmente duas interfaces: Administrativa, restrita a usuários autorizados e acessada via backend e pública acessada por todos os usuários via frontend. Para desenvolver o componente utiliza-se uma “IDE” do porte do Aptana ou o bloco de notas. Ao ser instalado, o componente passa a fazer parte do projeto, possui acesso total ao banco de dados através da classe JDATABASE e funciona em total harmonia com os outros componentes existentes no projeto permitindo um ganho real em funcionalidades. Entretanto a falsa impressão de ser fácil programar para o joomla, aliada a falta de cuidados básicos de segurança no desenvolvimento do código-fonte podem trazer sérios prejuízos ao projeto desenvolvido, tendo em vista que uma porcentagem considerável de ataques bem sucedidos à projetos desenvolvidos com o CMS Joomla ocorrem justamente através da exploração de vulnerabilidades em componentes MVC. O padrão de projeto utilizado no desenvolvimento de componentes é o MVC (Model View Controller), um padrão de arquitetura de software que visa a separar a lógica de negócio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolado de ambos. Figura 4 – MVC Fonte: http://pt.wikipedia.org/wiki/MVC, (2011) 5.1 O MODELO (MODEL)
  • 43. É a parte do componente que encapsula os dados da aplicação. Na maioria das vezes vai fornecer rotinas de administração e manipulação de dados através de Métodos para adicionar, eliminar e atualizar informações na base de dados (CRUD). De modo geral, a técnica de acesso aos dados deve ser encapsulada no modelo. Desta forma, se uma aplicação for transferida de um sistema que usa banco de dados para um sistema que usa arquivos texto para guardar as informações, o único elemento que precisa ser alterado será o modelo. Representa o domínio da informação ou dados que o componente trabalha. 5.2 A visão (View) É a parte do componente usada para transformar e preparar os dados do modelo para que possam ser apresentados de alguma forma, geralmente numa página HTML. O controlador retira os dados do modelo e os entrega para a visão. Esta, por sua vez, alimenta “templates” com estes dados para que possam ser apresentados ao usuário. A visão não modifica os dados de nenhuma forma, apenas os apresenta. Poderá ser apresentada no formato HTML ou PDF. 5.3 O controlador (Controller) O controlador é responsável pelas respostas às ações dos usuários, validação dos dados, controle de paginação e aplicação de filtros. No caso de uma aplicação web, uma ação de usuário (geralmente) é a solicitação de uma página. O controlador vai determinar qual solicitação foi feita e vai responder de acordo fazendo com que o modelo manipule os dados necessários na base de dados para depois passá-los para a visão e esta providenciará a visualização ao usuário.
  • 44. 5.4 Classes utilizadas na implementação de componentes MVC 5.4.1 JModel JMODEL é uma classe abstrata, estendida da classe JOBJECT, que fornece as funcionalidades básicas para os padrões de projeto MVC do Joomla! Modelos que estendem a classe JMODEL são frequentemente utilizados em componente MVC com objetivo de definir a lógica de negócio do componente específico. Figura 5 – Classe JModel) Fonte: http://docs.joomla.org/, (2009) 5.4.2 JView JVIEW é uma classe abstrata, estendida da classe JOBJECT, que fornece as funcionalidades básicas para os padrões de projeto MVC do Joomla! Para utilizar as
  • 45. funcionalidades de forma plena nos componentes MVC, deverão ser criadas as classes JVIEW exclusivas do componente. Figura 6 – Classe JView) Fonte: http://docs.joomla.org/, (2009) 5.4.3 JController JCONTROLLER é uma classe abstrata, estendida da classe JOBJECT, que fornece as funcionalidades básicas para as classes do controlador de seu componente MVC.
  • 46. Figura 7 – Classe JController Fonte: http://docs.joomla.org/, 2009 5.4.4 JDATABASE Quando o Joomla 1.5 é iniciado, ele precisa fazer uma série de consultas à sua base de dados, senão nem consegue "entrar no ar". Para fazer estas consultas, o sistema cria um objeto database. Se este objeto já existe, não há a necessidade de criar um
  • 47. objeto do mesmo tipo para suprir as necessidades do novo componente MVC, basta chamá-lo por referência. 5.4.4.1 Consultas com JDATABASE Para invocar qualquer objeto por referência usa-se o marcador &. No caso, para obter este objeto, o código é o seguinte: Figura nr 8 – Instanciando o BD Fonte: autoria própria (2011) Com o objeto Database à disposição o programador pode fazer uma query (pergunta) ao banco de dados e depois colher as respostas. Para colocar uma pergunta chama-se (com ->) o Método setQuery() através deste objeto. Por exemplo: Figura nr 9 – executando consulta Fonte: autoria própria (2011) Depois da query colocada, os resultados podem ser verificados. Por exemplo, se apenas o valor do primeiro campo da primeira linha do conjunto de resultados for desejado, é só usar o Método loadResult: Figura 10 – Executando a consulta Fonte: autoria própria (2011)
  • 48. Se o programador desejar todos os campos da primeira linha do conjunto de resultados, então é preciso chamar através do seguinte código: Figura 11 – apresentação de resultados Fonte: autoria própria (2011) Os resultados encontrados serão colocados num array. Se o programador desejar um objeto cujas propriedades sejam os nomes dos campos, pode executar a query com: Figura 12 – resultado em array) Fonte: autoria própria (2011) Agora $objeto->title é o título do primeiro artigo achado, $objeto->alias é o apelido do artigo. Quando o objeto for null, este Método cria o objeto e lhe atribui as propriedades com os valores da primeira linha encontrada. Mas, se o programador desejar um array de objetos com todos os artigos da tabela, deve fazer o seguinte: Figura 13 – Query completa Fonte: autoria própria (2011) O código acima vai listar todos os títulos e todos os “alias” dos artigos existentes na tabela de artigos.
  • 49. 5.4.4.2 Atualizações de registros com JDATABASE Na atualização de algum campo da tabela, o programador pode usar o trecho de código abaixo em sua consulta: Figura 14 – query para atualização Fonte: autoria própria (2011) A query foi colocada numa variável, a $query. Depois, esta variável foi usada como parâmetro em setQuery(). Isto não é obrigatório, mas deixa o código um pouco mais claro. Uma vez colocada a query, ela pode (e deve) ser acionada pelo Método query() 5.4.4.3 Outros recursos do objeto JDATABASE O JDATABASE pode ser usado para fornecer alguns valores extras, além de efetuar consultas contra o banco de dados. 5.4.4.3.1 getEscaped() O Método getEscaped, preparar strings com caracteres especiais (como é o caso do apóstrofo) para que sejam aceitas pelo banco de dados sem darem erro. O Método
  • 50. abaixo transforma "pingo d'água" em "pingo d'água" permitindo a gravação do registro no banco de dados: Figura 15 – Método getEscaped Fonte: autoria própria (2011) 5.4.4.3.2 getNullDate() O Método getNullDate fornece uma "data e hora" zerada, ou seja, 000-00-00 00:00:00: Figura nr 16 – Método geNullDate Fonte: autoria própria (2011) 5.4.4.3.3 getNumRows() O Método getNumRows retorna a quantidade de linhas produzidas pela última query executada: Figura nr 17 – Método getNullRows Fonte: autoria própria (2011) 5.4.4.3.4 getErrorNum(); O Método getErroNum é utilizado para tratamento de erros.
  • 51. Figura nr 18 – Método getErrorNum) Fonte: autoria própria (2011) 5.5 FERRAMENTAS CASE PARA O DESENVOLVIMENTO DE COMPONENTE MVC Existem ferramentas que auxiliam e agilizam o processo de desenvolvimento de componentes MVC para o CMS Joomla. 5.5.1 Aptana Aptana é uma IDE (Integrated Development Environment) open source, gratuita, baseada no eclipse, possui um plugin para integração com o PHP, sendo utilizada em larga escala no desenvolvimento de componentes MVC para o CMS Joomla! O seu download pode ser feito livremente no endereço <http://www.aptana.com/> 5.5.2 Alphaplug Alphaplug é um aplicativo online que permite a geração de toda a estrutura do componente MVC (modelos, visões, controladores), além dos arquivos de idiomas, arquivos de instalação e desinstalação, scripts .sql para criação e população das tabelas. Após preencher os dados básicos do componente é gerado um pacote compactado, pronto para ser instalado no Joomla, cabendo ao programador a codificação do componente. O alphaplug pode ser utilizado livremente no endereço <http://www.alphaplug.com/index.php/products/mvc-generator-online.html/>
  • 52. 5.5.3 GEPAC GEPAC é um gerenciador online de pacotes MVC para Joomla! 1.6 que permite a geração de toda a estrutura do componente MVC (modelos, visões, controladores), além dos arquivos de idiomas, arquivos de instalação e desinstalação, scripts .sql para criação e população das tabelas. Após preencher os dados básicos do componente é gerado um pacote compactado, pronto para ser instalado no Joomla! 1.6, cabendo ao programador a codificação do componente. O GEPAC pode ser utilizado livremente no endereço <http://www.joomlabrasilia.com.br/gepac/> 5.6 TIPOS DE COMPONENTES MVC Existem 02 (dois) tipos de componentes MVC, os que fazem parte do núcleo do CMS Joomla e são distribuídos com o pacote de instalação e os desenvolvidos por empresas e programadores independentes sem ligação com a equipe mantenedora do projeto. Esses componentes recebem a denominação de “extensões de terceiros.” 5.7 FALHAS DE SEGURANÇA NO COMPONENTE, ENCONTRADAS NA FASE DE TESTES Muitos componentes são desenvolvidos por programadores inexperientes que não tomam medidas preventivas visando a proteção de seus componentes contra tentativas de ataques de crackers. As principais falhas observadas são relativas a falta ou validação ineficiente dos dados inseridos em formulários de seus componentes, o que pode acarretar a
  • 53. aceitação de qualquer tipo de dados pela aplicação, ou mesmo o envio de formulários em branco que acabam por gravar registros nulos no banco de dados. Os principais ataques a componentes MVC estão relacionados à passagem de valores inesperados em formulários que podem culminar em um defacement, ou mesmo em um total comprometimento do website através de ataques do tipo SQL Injection. O projeto Joomla! mantém um grupo de especialistas que trabalha exclusivamente com a segurança do CMS e Componentes, catalogando os componentes de terceiros que apresentem algum tipo de vulnerabilidade, ficando os mesmos registrados na base de dados até que venham a apresentar a solução para o problema levantado, geralmente através de uma release de segurança ou nova versão para o componente. A lista oficial de componente vulneráveis pode ser acessada em <http://docs.joomla.org/Vulnerable_Extensions_List/> A comunidade Joomla! também mobiliza-se em prol da segurança do CMS e suas extensões sendo importante o acompanhamento dos feeds abaixo, voltados à este tema: <http://feeds.joomla.org/JoomlaSecurityNews/> <http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions/> <http://pipes.yahoo.com/pipes/pipe.info?_id=NFvms7053RGSMS6czKky6g/>
  • 54. 5.8 CRIPTOGRAFIA DAS SENHAS NO JOOMLA! Para entender a engenharia utilizada no processo de criptografia e armazenamento de senhas do CMS, é preciso analisar dois arquivos. Um faz parte do parte do plugin de autenticação do joomla e o outro faz parte da biblioteca do joomla. 5.8.1 Joomla.php O arquivo joomla.php está localizado em /plugins/authentication/ e a parte de seu código-fonte que trata da criptografia da senha pode ser analisado abaixo: Figura 19 – Parte do código-fonte do arquivo joomla.php Fonte: autoria própria (2011) As linhas 70 a 78 mostram que o plugin acessou o banco de dados do Joomla para buscar algumas informações na tabela de usuários filtrando os dados pelo nome de usuário.
  • 55. Figura nr 20 – continuação código-fonte joomla.php Fonte: autoria própria (2011) Se tiver encontrado alguma coisa, explode o que encontrou no campo password usando o delimitador ":" (linha 82). A primeira parte (a senha criptografada) é armazenada na variável $crypt; (linha 83) a segunda (o chamado sal) é colocada na variável $salt (linha 84). Isto indica que as senhas guardadas são compostas por duas partes. Alguns exemplos são: 3291503d0bd0059c54b466049594c443:Tk7F78S1VpAAGgPB 69a02eba32f545982806168859ebb08b:kQFgQ54RngbuYhsC Logo a seguir, o Método getCryptedPassword, que pertence à classe JUserHelper, é chamado com os parâmetros senha e sal (veja na linha 85). 5.8.2 getCryptedPassword O Método getCryptedPassword da classe JUserHelper está inserido no arquivo helper.php, localizado em /libraries/joomla/user A função getCryptedPassword (linha 106) precisa no mínimo de um parâmetro: a senha em texto claro ($plaintext); os outros três parâmetros são opcionais. Se o sal ($salt) não for fornecido, ele recebe uma string vazia; se o tipo de encriptação ($encryption) não for definido, o valor padrão 'md5-hex' é assumido e se mostrar o tipo de encriptação ($show_encrypt) não for especificado, o padrão será falso.
  • 56. Em princípio, se chamarmos a função apenas com a senha fornecida pelo usuário, o sal não será usado, o tipo de cifragem será md5-hex e o tipo de encriptação não será adicionado ao resultado. É a cifragem mais simples que existe. As linhas restantes desta função tratam de identificar o tipo de encriptação solicitado e realizam a cifragem de acordo. Para nós interessam apenas as linhas finais, onde o hash do tipo md5-hex é calculado. Se o sal estiver presente, a variável $encrypted recebe o valor de retorno da função do PHP md5() aplicada ao conjunto $plaintext.$salt; se não estiver presente, a mesma função do PHP é aplicada apenas a $plaintext. Da mesma forma, se $show_encrypt for verdadeiro, o tipo de cifragem é adicionado ao resultado pela concatenação de '{MD5}'.$encrypted; caso contrário, o valor de retorno será apenas o hash obtido. Figura 21 – parte do código-fonte do arquivo helper.php Fonte: autoria própria (2011)
  • 57. 5.8.3 HASH Joomla! usa Hash MD5. Um hash, também chamado de "digesto", é uma espécie de "assinatura" ou "impressão digital" que representa o conteúdo de um fluxo de dados. Um hash pode ser comparado com um selo de embalagem que indica clara e inequivocamente se a embalagem já foi aberta ou violada. Hashes transformam os dados do texto (claro ou cifrado) num pequeno digesto, de tamanho fixo, numa operação de mão única. Uma operação de mão única não tem volta, ou seja, em tese não é possível obter o texto claro a partir de um resultado hash. Porém, já existem programas capazes de quebrar hashes. Guardar senhas em texto claro é dar chance para o azar. Se um arquivo de senhas for roubado ou um banco de dados com registros de senhas for hackeado, o estrago pode ser enorme. Como um hash não é reversível e, para serem usadas, as senhas precisam ser conferidas, é muito mais prudente armazenar os resultados hash das senhas do que as próprias senhas. O uso de uma senha pressupõe que um usuário a digite. Tendo a senha como entrada, é fácil e rápido calcular o resultado hash da senha fornecida e compará-lo com o valor arquivado. Se forem idênticos, a senha confere, mostrando que o usuário conhecia uma senha válida. Este procedimento reduz sensivelmente os riscos porque o único momento em que a senha pode ser roubada é enquanto está sendo digitada e antes de ser transformada em hash.
  • 58. 5.8.4 MD5 O MD5 foi desenvolvido por Ron Rivest em 1991. É basicamente o MD4 com um "cinto de segurança" - os cálculos são um pouco mais lentos, mas, em compensação, é muito mais seguro. Da mesma forma que outras funções hash, o MD5 é usado em assinaturas digitais onde um texto longo precisa ser "comprimido" de forma segura antes de ser cifrado com uma chave privada (secreta) por um criptossistema de chave pública. Foi projetado para máquinas de 32 bits, podendo ser facilmente programado de forma compacta. O autor colocou o algoritmo no domínio público em abril de 1992. Como o texto sobre a função hash MD4 é bastante minucioso e o MD5 é muito parecido, não há a necessidade de entrar em muitos detalhes. Caso você tenha dúvidas, complemente a leitura com o texto MD4. 5.9 FORMAS DE CORREÇÃO DAS FALHAS ENCONTRADAS Para corrigir falhas de segurança nos componentes MVC durante a fase de testes, devem ser adotadas práticas relacionadas a testes de validação dos dados inseridos nos formulários. 5.10 CONSIDERAÇÕES PARCIAIS Desenvolver componentes para o CMS Joomla exige do técnico, conhecimento avançado em lógica de programação, programação orientada a objetos e banco de dados.
  • 59. Diferente do gerenciamento de conteúdo ou do desenvolvimento de um website, o desenvolvimento de um componente MVC exige sim, conhecimento técnico. Muitas invasões são efetuadas em cima de vulnerabilidades existentes em componentes desenvolvidos fora dos padrões de projeto do framework do Joomla! Utilizar os métodos do próprio framework e seguir padrões de projeto são atitudes fundamentais para que seja desenvolvida uma extensão segura.
  • 60. 6. VULNERABILIDADES E DEFACEMENT’S As principais vulnerabilidades em componentes MVC estão relacionadas à falta de tratamento aos tipos de dados que são enviados pelos formulários à base de dados, particularmente com expressões regulares que impeçam a formação de tags HTML. Este descuido pode facilitar ataques de diversos tipos. Observe na imagem abaixo que possuímos 04 (quatro) campos de texto em um formulário e espera-se que o usuário insira somente caracteres do tipo “string”. Mas, e se o usuário inadvertidamente tentar inserir dados numéricos ou caracteres especiais, qual seria o comportamento do componente? Ele iria processar o registro? Figura 22 – Formulário para inserção de dados em componente MVC via backend Fonte: autoria própria (2011) Um componente que funcione no backend do Joomla!, dificilmente sofrerá um ataque de crackers tendo em vista a própria política do CMS que só permite acesso a usuários com perfil de Administrador e Super Administrador. Partimos do princípio que se o cracker conseguiu acesso ao backend, todo o website está comprometido. Porém, os componentes que recebem dados via frontend estão sujeitos a diversos tipos de ataques.
  • 61. 6.1 SQL INJECTION Qualquer SGBD (Sistema Gerenciador de Bancos de Dados Relacional) entende apenas uma linguagem: SQL (Structured Query Language) ou linguagem de consulta estruturada. CREATE, DELETE, UPDATE e SELECT são apenas alguns dos comandos mais utilizados nesta linguagem, mas não está no escopo do nosso artigo, ensinar SQL e sim apresentar-lhe o SQL INJECTION. Uma das formas mais comuns e efetivas de ataque na internet é o SQL Injection. No SQL Injection, um cracker tenta enviar códigos SQL via consultas SQL não autorizadas e filtradas. O código SQL do cracker pode não ter nenhum retorno em termos de informações de segurança ou simplesmente executar um processo de destruição absoluta. Existem precauções básicas que você deve tomar, para proteger os dados que serão recebidos através de formulários, principalmente se foi você quem o desenvolveu. A regra básica é tratar e validar os dados que serão recebidos e se assegurar que o seu código nunca irá receber os dados de uma forma bruta, ou seja, sem o devido tratamento. Você pode tratar os dados de várias formas, desde limite de caracteres aceitos com maxlenght e size até scripts em javascript, para fazer a validação a nível cliente e scripts PHP, para validação a nível provedor. Todos os dados enviados devem ser processados e validados antes de serem utilizados pela aplicação.
  • 62. 6.2 CAMPOS DE TEXTO EM FORMULÁRIO SEM FILTRAGEM Por exemplo, um formulário HTML pode aceitar um campo para um nome. Enquanto um usuário normal iria simplesmente digitar o seu nome no campo de texto do formulário, o cracker injeta código SQL para tentar executar uma consulta não autorizada ao banco de dados. Se no código do script PHP que vai receber os dados do formulário você “setou” a variável $name do tipo Get ou Post nome, que é o campo do formulário, a consulta normal ao banco de dados seria algo isto: $sql="Select * FROM jos_users WHERE name =' " . $name. " ';"; O cracker então digitaria algo parecido com o que segue: dummytext ' OR ' a ' = ' a O código SQL gerador a partir desta injeção seria algo parecido com isto: select * FROM jos_users WHERE name = 'dummytext' OR ' a ' = ' a '; Quando a consulta enviada pelo cracker é executada, o teste ' a ' = ' a ' retornaria um valor real para cada linha e a consulta apresentaria a lista de todos os usuários existentes na tabela jos_users. O mais assustador é que qualquer código SQL válido, ou seja, sem erro de sintaxe, pode ser injetado, como mostrado no código a seguir: dummytext ' ; DROP table jos_users; SELECT * FROM jos_poll where title = ' O código acima iria destruir completamente a tabela de usuários do Joomla. Uma rotina simples de tratamento e validação do campo de texto do formulário permitiria eliminar qualquer perigo de um ataque deste tipo.
  • 63. 6.3 MANUSEANDO CAMPOS DE TEXTO EM FORMULÁRIO PHP Joomla inclui rotinas para gerar caracteres de escape para quaisquer caracteres (string) que não podem ser armazenados adequadamente dentro de um banco de dados. Por exemplo, a “plica” ( ' ) não pode ser armazenada na declaração SQL padrão de inserção sem modificação. Portanto, uma seqüência de caracteres de escape com barra invertida ( ) permite a inclusão de caracteres especiais no MySql. Assim, uma barra invertida seguida pela citação ( " ) seria o único meio de armazenar os dados no campo do banco de dados. A seqüência de caracteres de escape fornecidos pelo próprio sistema invalida o ataque via injection, porque os caracteres digitados pelo hacker não serão entendidos pelo sistema como um comando SQL, será apenas um caracter literal comum a ser armazenado no banco de dados. O provável resultado dessa consulta seria o retorno de um erro, uma vez que não existem registros correspondentes a esse valor seria encontrado. Para o código PHP, você pode usar um banco de dados específicos de cada Método para gerar uma string que cria códigos para escapar de caracteres especiais. Para o MySQL, PHP inclui a função mysql_real_escape_string () O uso da função fica parecido com isto: $name = mysql_real_escape_string($name); Joomla! fornece um Método getEscaped () que irá retornar a string independentemente de seqüência de escape de caracteres. Embora Joomla atualmente só suporte MySQL (previsto suportar ORACLE a partir da versão 6), você pode obter com o objeto JDatabase, a string que escapou e seria algo parecido com isto: $db =& Jfactory::getDBO(); $name = $db->getEscaped($name) ;
  • 64. Voltando aos ataques, no primeiro exemplo de ataque via SQL Injection, com os caracteres de escape, teríamos a seguinte seqüência inofensiva: dummytext ' or 'a ' = ' a O segundo exemplo ficaria assim: dummytext' ; Drop Table jos_users; select * from jos_polls where title = ' Existe uma diretiva do PHP conhecida como "magic quotes", que irá adicionar automaticamente barras para todos os campos recebidos de fonte externa (como um navegador da web). Na versão 6 do PHP, esta diretiva foi eliminada. Portanto, é melhor ficar atento (a) aos códigos, principalmente de extensões de terceiros, para que seja executado de forma segura e caso esteja hospedando o Joomla em servidores com PHP 4.x (a maioria dos baratinhos ainda utiliza esta versão antiga do PHP) verifique a magiq quotes. ELA DEVE ESTAR LIGADA, ou seja, magiq_quotes = ON 6.3.1 Tipos não esperados Outra forma de ataque via SQL Injection pode ocorrer quando valores não esperados, (string, float, e assim por diante) são digitados e passados diretamente para a consulta SQL. Por exemplo, um valor de id obtido a partir de uma consulta ao banco de dados executada diretamente em linha de comando como esta:
  • 65. $sql = " select * from jos_users where id = " . $id . "; “; O mesmo tipo de SQL Injection poderia ser utilizado com o id recuperado, se não for tratado com os caracteres de escape: 1; Drop table jos_users; Portanto, quando você aceitar valores de uma consulta ou formulário de envio, certifique-se de escrevê-los através do php. Por exemplo, para escrever o $id em um valor inteiro (Integer), você poderia utilizar o seguinte código PHP: $id= intval($id); Digitando este código, qualquer tipo de SQL Injection, será automaticamente eliminado, ou irá gerar um erro quando o código encontrar os caracteres inválidos. Se você usar os Métodos JRequest:: getVar () ou JRequest:: get (), nativos do Joomla para obter a seqüência de dados enviados via formulário de consulta, você já está protegido. Estas funções fornecem um filtro seguro para todos os tipos de dados indefinidos ou não esperado. Entretanto, quaisquer dados obtidos fora dessas funções, devem ser tratados por você com caracteres de escape, sempre que possível. 6.4 CROSS-SITE SCRIPTING (XSS) É um Método de inserção de algumas instruções para que seja executado um código javascript, um objeto, ou código HTML quando um editor de HTML é disponibilizado para o usuário. Este código pode abrir uma janela oculta no sistema
  • 66. do usuário e gravar itens como nomes de usuários e senhas em outras janelas do navegador. O fato de um “website” permitir ao usuário postar conteúdo (uma das principais características da web 2.0), este vulnerabilidade tem aumentado e sido explorada ao máximo. Croos-site scripting é um ataque muito perigoso e deve ser evitado. Estes tipos de ataques podem ser controlados através da interface de usuário do joomla! No entanto, a prevalência de extensões disponíveis que permitem inserção de código HTML, por exemplo, (Livros de visitas e fóruns) significa que você deve estar alerta para prevenir esses tipos de ataque. Assegurar que as novas extensões façam a filtragem das tags utilizadas por este Método de ataque (principalmente e) antes de implantar a extensão ou o seu site. PHP tem um conjunto de funções que podem lhe ajudar. A função strip_tags () irá funcionar retirando todas as tags de HTML, XML e PHP, de uma seqüência de dados enviados e devolvendo o texto plano. Isto pode ser utilizado de forma muito eficaz se a sua aplicação não está esperando este tipo de formatação de texto como entrada. Para a formatação, você poderia usar BBCode, que é aceita sem ser afetada por essa função. A função htmlentities () do PHP irá converter todos os caracteres não-alfanuméricos (como aspas, maior que, asterisco e assim por diante) para formatação HTML. Você também pode usar expressões regulares para tirar todos os caracteres especiais exceto alfanuméricos. Por último, em um campo Nome, você pode usar uma declaração como esta: $myString = preg_replace("/[^a-z 0-9]/i", "", $myString);
  • 67. 6.5 DIRECTORY SCANNING A navegação entre diretórios é um convite aberto para crackers tentarem descobrir uma grande quantidade de informações sobre seu sistema. A partir de arquivos de configuração geral do sistema o cracker poderá ter acessos a informações sobre o sistema operacional do provedor e da aplicação. Como medida preventiva, o CMS Joomla cria um arquivo index.html, em branco, em cada diretório do site e subdiretório do site para evitar esta possível intrusão. A maior parte das extensões e templates desenvolvidas por terceiros, no entanto, não adotam este ato preventivo. 6.6 CROOS-SITE REQUEST FORGERY (CSRF) Cross site request forgery é um tipo de ataque simples e devastador. Este tipo de ataque depende da confiança de um site no usuário logado e que pode fazer certos tipos de transações. O CSRF força o navegador logado da vítima a enviar uma requisição de solicitação não autorizada para uma aplicação web vulnerável, que realiza a ação desejada em nome da vítima. Por exemplo, digamos que um usuário esteja conectado no backend do Joomla e em outra aba do navegador esteja navegando em um website comprometido. Em alguns navegadores, um ataque CSRF pode ser lançado pela simples adulteração de um elemento do tipo IMG, para que eles apontam para algo como http://some/joomla/site/administrator/index2.php?option=com_users&task=delete...
  • 68. Quando o usuário, logado no backend, navega no site comprometido, e clica sobre a imagem com o link alterado o pedido forjado será interpretado como autenticado e executado no backend do Joomla! Figura nr 23 – Tipo de ataque CSRF Fonte: http://www.google.com/images/, (2011) 6.7 DEFACEMENT O objetivo deste ataque é “pixar” a página inicial do website e geralmente é praticado por script kiddies com cunho político ou pessoal. A utilização de templates piratas em websites Joomla pode abrir backdoors que facilitam em última análise, ataques deste tipo. Figura nr 24 – Defacement Fonte: http://www.google.com/images/, (2008)
  • 69. 6.8 CONSIDERAÇÕES PARCIAIS Uma aplicação web está sujeita a vários tipos de ataques. Porém, a maioria pode ser evitada com a adoção de melhores práticas relacionadas à segurança, por parte de quem desenvolve. É comum encontrarmos websites com nome de usuário administrativo padrão e senha fraca. Hospedados em hosts desatualizados, com sérios problemas de permissionamento. Estas preocupações são inerentes ao desenvolvedor web e uma vez negligenciadas colocam em risco toda a estrutura envolvida, desde a rede até a aplicação. O defacement é o tipo de ataque mais temido por mudar as características da página inicial do website, podendo comprometer seriamente a marca do cliente invadido. Porém, dependendo da intensidade não é o mais perigoso. Não existe sistema seguro, o que podemos fazer é otimizar a segurança para minimizar as chances de sucesso por parte do atacante. Mas, desejamos 100% de segurança, só existe uma opção: “desligar a máquina.”
  • 70. 7. TESTES DE PENETRAÇÃO Para avaliar o nível de segurança do componente MVC desenvolvido, é importante viabilizar testes de penetração com ferramentas específicas para este fim. O teste de penetração é um Método que avalia dentre outras coisas, a segurança de um sistema, neste caso o componente. Com o teste, é feita uma simulação de ataque de uma fonte maliciosa e o processo envolve uma análise nas atividades do sistema em busca de alguma vulnerabilidade em potencial resultante da má configuração ou má codificação do sistema. Todas as análises submetidas pelos testes escolhidos são apresentadas no sistema, junto com avaliação do impacto e muitas vezes, proposta para resolução do problema. O objetivo central do teste de penetração é determinar a viabilidade de um ataque e mensurar o seu impacto caso seja bem sucedido. Ele age como um componente na auditoria de segurança e é altamente recomendável que desenvolvedores de componentes considerem incluir testes de penetração no processo. Podem ser realizados de várias maneiras sendo mais comuns o teste caixa preta e o caixa branca. Testes de penetração podem ser usados para busca de vulnerabilidades em sistemas, uma simples varredura na organização dos endereços IP, abrir/fechar portas ou fazer uma auditoria completa no escopo da rede em busca de vulnerabilidades.
  • 71. 7.1 TESTE CAIXA PRETA O teste da caixa preta assume que não existe qualquer conhecimento prévio da infra-estrutura a ser testada. Sendo que o primeiro teste deve determinar a localização e extensão dos sistemas antes de iniciar a análise. Simulam um ataque de alguém que esteja familiarizado com o sistema. 7.2 TESTE CAIXA BRANCA O teste da caixa branca assume que o testador possui total conhecimento da infra- estrutura a ser testada, incluindo o diagrama da rede, endereçamento IP e qualquer informação complementar. Simula o que pode acontecer durante o expediente de um trabalho ou depois de um "vazamento" de informações, em que o invasor tenha acesso ao código fonte do sistema. 7.3 TESTES DE VULNERABILIDADES EM COMPONENTE MVC Uma vez instalado no “website” o componente deve sofrer testes para verificar o nível de segurança em relação aos principais ataques conhecidos e utilizados contra websites. 7.4 BACKTRACK Backtrack é uma poderosa solução desenvolvida para testes de penetração, apreciada por especialistas em segurança, hackers e crackers. Conta com 13 ferramentas de código aberto que lhe conferem um alto poder de “fogo”.
  • 72. As ferramentas do Backtrack são divididos em três categorias: Aquisição de Imagem, escultura de arquivo e análise forense. As ferramentas da categoria de aquisição de imagem permitem-lhe adquirir pouco a pouco as imagens de discos. As duas ferramentas de escultura de arquivos, ajudam no processo de resgate de arquivos apagados. As nove ferramentas da categoria de análise forense permitem uma pesquisa completa no disco em busca de mensagens de email, histórico de navegação e miniaturas de imagens. O Backtrack pode ser utilizado em conjutno com outros aplicativos para testar componentes MVC desenvolvidos para o CMS Joomla, a partir de algumas de suas ferramentas para identificação de vulnerabilidades: Nikto, SQL Inject, SQLbrute. Algumas ferramentas irão interagir com a máquina servidora e outras, diretamente com a aplicação. Figura 25 – Iniciando o backtrack em máquina virtual Fonte: autoria própria (2011)
  • 73. Figura 26 – Backtrack pronto para uso em máquina virtual Fonte: autoria própria (2011) 7.5 NIKTO Nikto é um projeto open source de um scanner que busca vulnerabilidades no servidor web. O nikto está embutido no Backtrack, mas pode ser executado separadamente em um terminal de uma máquina GNU/LINUX exibindo um raio-x do servidor em que o website está hospedado. O comando shell para execução do Nikto é: nikto –h http://www.sitealvo.com.br. 7.6 ZERODAYSCAN ZeroDayScan é um scanner de segurança online voltado para web, usado por webmasters e especialistas em segurança para validar a segurança dos seus sites e aplicativos. Os principais destaques são:
  • 74.  Nenhuma instalação é necessária. É um serviço on-line;  Detecta ataques Cross Site Scripting (XSS);  Detecta diretórios ocultos e arquivos de backup;  Olha para vulnerabilidades de segurança conhecidas;  Pesquisas para vulnerabilidades de injeção SQL;  Detecta automaticamente bugs do tipo zero-day;  Realiza “Fingerprinting” no website;  Gera relatórios em PDF grátis. 7.7 OWASP Projeto open source de um scanner de vulnerabilidades em CMS. Os seguintes recursos estão disponíveis no OWASP:  Sondagem da versão atual do Joomla! (o scanner pode dizer se o alvo está executando a versão 1.5.12 em diante);  Detecção comum do Joomla! Baseado na aplicação web e firewall;  Procurar as vulnerabilidades conhecidas do Joomla! E seus componentes;  Reportagem de saída em Texto e HTML;  Capacidade de atualização imediata via scanner ou svn. 7.7.1 Requisitos e funcionamento do OWASP - Sistema Operacional GNU/LINUX
  • 75. - Faça o download no “website” (http://yehg.net/lab/pr0js/files.php/joomscan- latest.zip) e descompacte o arquivo zip ($ unzip file) na raiz do seu “website”; e - Acesse o diretório e dê permissão de execução no arquivo joomscan.pl ($ chmod +x joomscan.pl) - Atualize a base de dados do scanner $ ./joomscan.pl update - O uso básico do scanner é: $ ./joomscan.pl -u http://seusite.com.br - Parâmetros Usage: ./joomscan.pl -u <string> -x proxy:port -u <string> = joomla Url -x <string:int> = proxy to tunnel -c <string> = cookie (name=value;) -g "<string>" = desired useragent string(within ") -nv = No Version fingerprinting check -nf = No Firewall detection check -nvf/ -nfv = No version+firewall check -pe = Poke version only and Exit -ot = Output to Text file (target-joexploit.txt) -oh = Output to Html file (target-joexploit.txt) -vu = Verbose (output every Url scan) -sp = show completed Percentage
  • 76. 7.8 CONSIDERAÇÕES PARCIAIS É fundamental realizar testes para termos certeza que a infraestrutura de hospedagem, as extensões e o website, estão com a segurança maximizada. A maioria dos programas são exclusivos do sistema operacional GNU/LINUX, mas existem soluções on line e gratuitas que podem ser utilizadas, enviando de forma automática uma análise estatística de toda a situação.
  • 77. 8. MELHORES PRÁTICAS PARA EVITAR INVASÕES O profissional responsável pelo desenvolvimento do website precisa prever no levantamento de requisitos, a política de segurança com o uso de extensões específicas para este fim. Deve manter a versão atualizada, evitar o uso de templates piratas, extensões que estejam relacionadas na lista de vulnerabilidades do projeto Joomla! e a utilização de provedores pouco conhecidos. A aplicação correta das permissões de arquivos e diretórios, a escolha de uma senha forte com troca do nome padrão do usuário de administração completa o ciclo. As tecnologias envolvidas na preparação do ambiente de hospedagem representadas pelo acrônimo LAMP e o gerenciamento de toda a estrutura da rede, com seus sistemas de firewall, voltados a impedir acesso não autorizado são fundamentais para garantir o sucesso de um projeto web e ficam a cargo do provedor de hospedagem contratado. Figura nr 27 – A aplicação é a ponta do iceberg Fonte: autoria própria (2010)
  • 78. O CMS representa à camada de aplicação que pode ser comparada a ponta de um iceberg. A preocupação com a segurança deve ser prioridade no desenvolvimento de um projeto web. Projetos desenvolvidos com o CMS Joomla devem obedecer a regras específicas para a melhor utilização do CMS. 8.1 O PROVEDOR DE HOSPEDAGEM A escolha do provedor de hospedagem é uma etapa importante e que poderá comprometer toda a segurança do projeto se for escolhido um provedor ruim, com os aplicativos que sintetizam o “LAMP” desatualizados. Muitas vezes fica a cargo do desenvolvedor tendo em vista que o cliente ignora o que venha a ser um provedor. Neste caso, deve-se evitar a venda casada e os provedores extremamente baratos. O melhor a fazer é orientar o cliente e buscar em conjunto, provedores idôneos através de pesquisa de mercado. Todos os direitos relativos ao domínio devem ficar com o cliente. 8.2 INSTALAÇÃO AUTOMÁTICA DO JOOMLA! Joomla! vende e por isso, vários provedores prometem suporte e instalação automática do CMS. Não existe suporta a Joomla, qualquer máquina que possua no mínimo PHP e Mysql será capaz de prover condições de funcionamento ao CMS desde que devidamente configurada com um web Server. O fato é que essas empresas utilizam programas que instalam automaticamente, não só o CMS, como vários outros programas. Geralmente utilizam o “Fantástico” que é um instalador automático. O problema é que o “Fantástico” leva em média 15 (quinze) dias para atualizar sua base de dados e o usuário acaba por ter um website
  • 79. com duas, três, às vezes quatro versões atrasadas do CMS e dificilmente percebe este fato. A conseqüência será um website com um Joomla desatualizado e potencialmente suscetível a ataques bem sucedidos de crackers. O processo de instalação do Joomla! É extremamente simples e existem vários tutoriais na internet que podem ajudar sendo desaconselhável a utilização de programas instaladores. 8.3 ENCAPSULAMENTO DO ADMINISTRATOR Ataques do tipo força bruta precisam acessar o /administrator do website para tentar combinações aleatórias de usuários e senhas. Encapsular o endereço diminui em pelo menos 80 % as tentativas desta natureza uma vez que não existirá o endereço buscado pelo atacante. Existem várias extensões que protegem o acesso ao /administrator do Joomla! Sendo o mais utilizado o plugin JSecure que permite a criação de uma chave que será pedida ao final da url de administração do website. A instalação e habilitação do plugin forçam o usuário a digitar após o /administrator, a chave criada pelo superadministrador do website. Ex: http://www.seusite.com.br/administrator?suachave
  • 80. 8.4 URL’S AMIGÁVEIS Todo CMS gera url’s dinâmicas que são um conjunto de caracteres e variáveis que indicam o conteúdo a ser renderizado pelo navegador. Url’s amigáveis nada mais são que endereços humanamente compreensíveis. Por exemplo: O endereço http://www.seusite.com.br/index.php?option=1&content=2 é um exemplo de url dinâmica. Utilizando-se url amigável poderíamos ter algo parecido com http://www.seusite.com.br/blog/meuartigo.html. A url amigável além de permitir uma melhor indexação pelas máquinas de busca e conseqüente melhora no Page rank é importante fator de aumento na segurança do website joomla!, tendo em vista que muitos ataques automáticos buscam fragmentos de url para obter êxito. Um componente chamado com_prest geraria o seguinte fragmento na url dinâmica de seu website: http://www.seusite.com.br/index.php?option=com_prest. Caso este componente possua algum tipo de vulnerabilidade o robô irá capturar este fragmento (com_prest) e buscará em sua base de dados, a melhor forma de explorar a vulnerabilidade encontrada e conseqüentemente irá obter êxito invadindo o seu website. Com a utilização de url’s amigáveis fica impossível para o robô identificar o componente no fragmento da url tornando inócua esta tentativa de ataque. 8.5 APLICAÇÃO CORRETA DAS PERMISSÕES O GNU/LINUX, que é o sistema operacional da máquina servidora do seu website é baseado no UNIX e por isso requer permissões de LEITURA - GRAVAÇÃO - ESCRITA. Mudanças de permissão são conseguidas com o comando chmod
  • 81. (CHANGE MODE), ficando assim na linha de comando: chmod [parametro diretorio/arquivo] * Ex: chmod 755 -r /var/www/novosite * chmod 755 (/var/www/novosite) - aquí o prorietário têm todas as permissões, mas o grupo e os outros utilizadores apenas têm permissão de leitura e execução. O -r significa recursivamente, ou seja, todos os diretórios abaixo do /novosite serão atingidos. * -r afeta também os subdiretórios * -v mostra cada arquivo a ser processado * -c mostra apenas os arquivos que sofreram alterações Para entendermos como este comando pode ser utilizado será melhor percebermos como as permissões são atribuídas a cada arquivo ou diretório. A permissão Read tem o valor 4 , a Write o valor 2 e o Execute o valor é 1. A permissão total do arquivo é obtida somando esses 3 números. Um arquivo com permissão de leitura (Read) assume o valor 4. A permissão de escrita (Write) assume o valor 2, a permissão Execute assume o valor 1. Vejam-se alguns dos exemplos mais comuns:  chmod 777 (nome_arquivo/diretório) - neste exemplo o proprietário, grupo e todos os usuários têm permissões quer de leitura (Read) , gravação (Write) e execução (Execute)  chmod 755 (nome_arquivo/diretório) - aquí o proprietário têm todas as permissões, mas o grupo e os outros usuários têm apenas permissão de leitura e execução, ou seja, não podem gravar.  chmod 666 (nome_arquivo/diretório) - Dá permissões de gravação e leitura a todos os usuários
  • 82.  chmod 644 (nome_arquivo/diretório) - atribui leitura e gravação para o proprietário e apenas leitura para o grupo e usuários Se o proprietário quiser todas as permissões, ficaria assim:  Read + Write + Execute (4+2+1);  Read + Execute (4+1) para o grupo (para ser Write teria de ser 4+2); e  Execute para os restantes teríamos a seguinte exemplo chmod 751 (nome_arquivo/diretório) O chmod permite atuar sobre 3 grupos bem distintos, que são :  'u' - utilizador (user)  'g' - grupo (group)  'o' - outros (others) Isto significa que podemos ou usar as letras (u, g, o) , ou o modo octal explicado antes. Estas letras são conjugas com as restantes r (read), w (write) x (execução) Mas e o que isso tem haver com o Joomla? Tudo se levarmos em conta que você estará hospedando no GNU/LINUX. Os seus diretórios deverão estar com permissão 0755 e os seus arquivos com permissão 0644 e o provedor de hospedagem deve utilizar sistema operacional GNU/LINUX.
  • 83. 8.6 ATUALIZAÇÃO DA VERSÃO DO CMS A equipe de desenvolvimento do Joomla! É muito ativa e reage rapidamente a novos tipos de ataques e/ou vulnerabilidades encontradas no código-fonte do CMS, lançando releases das versões estáveis. Cabe aos usuários, particularmente a quem desenvolve e possui perfil de super administrador de um website, a atualização da versão utilizada em seu projeto. A atualização é um processo simples e pode ser utilizada uma extensão para automatização do processo. É fundamental manter a versão do CMS atualizada para evitar problemas de segurança. 8.7 INFORMAÇÕES RELEVANTES Desabilite o relatório de erros no backend do Joomla, escolhendo a opção Nenhuma para relatórios de erros nas configurações globais. É interessante que a diretiva display_errors do php também esteja desabilitada. Mas, lembre-se que dependendo do contexto o display_errors deve estar habilitado. Por exemplo: você instala um módulo e ele dá pau. Com o display_errors desabilitado você verá apenas uma página em branco. Esta diretiva fica no php.ini e você não terá acesso no servidor. O máximo que poderá fazer é criar uma flag no seu arquivo (.htaccess) alterando o padrão de ON para OFF.
  • 84. 8.8 ATAQUES CSRF Joomla! tenta se proteger de ataques CSRF inserindo uma seqüência aleatória chamada “token” em cada requisição de formulário do tipo POST ou GET. Esta seqüência aleatória fornece proteção porque não só o site comprometido precisa saber a URL do site de destino e um formato de solicitação válida para o local do alvo, ele também deve conhecer a seqüência aleatória que muda a cada sessão e a cada usuário logado. O framework do joomla! torna fácil incluir essa proteção em componentes MVC também. É simples de implementar em ambos as requisições de formulários, POST e GET. 8.8.1 POST Para requisições do tipo POST em formulários HTML do componente MVC deve-se usar a seguinte linha de código: <?php echo JHTML::_( 'form.token' ); ?> Será impresso algo parecido com <input type="hidden" name="1234567890abcdef1234567890abcdef" value="1" /> 8.8.2 GET Para requisições do tipo GET em formulários HTML do componente MVC deve-se usar a seguinte linha de código que irá gerar uma URL com o símbolo na seqüência de consulta.
  • 85. Figura 28 – JRoute Fonte: autoria própria (2011) 8.8.3 Verificando o Token Depois de ter incluído o símbolo em sua forma ou na sua seqüência de consulta, o token deve ser verificado antes que o script do componente MVC realize o pedido. Isto é feito com a seguinte linha: Figura nr 29 – JRequest Fonte: autoria própria (2011) Se a solicitação é proveniente da seqüência de consulta, isto deve ser especificado no componente MVC. O código deve ficar da seguinte forma: Figura 28 – JRequestGet Fonte: autoria própria (2011) 8.8.4 Procedimentos complementares Embora esses Métodos ajudam a prevenir contra ataques do tipo CSRF, é importante perceber que existem outras práticas de segurança que devem ser
  • 86. seguidas pelo administrador do sistema para evitar que a mesma seja comprometida. 1. Não navegue em outros sites com o mesmo navegador enquanto estiver logado no backend do Joomla. 2. Use sempre o “logout” para encerrar a sessão do backend do joomla. 3. Não fique logado no backend do joomla sem fazer nada. 4. Verifique se o endereço na barra do navegador corresponde ao endereço do seu website 8.9 VALIDAÇÃO DE CAMPOS NOS FORMULÁRIOS DE COMPONENTES Todos os campos de formulários que receberão entrada de dados devem ser validados no próprio código-fonte do componente, em scripts no lado cliente (javascript) e no lado servidor (php). As validações devem verificar se o tipo de dado inserido é permitido, se o tipo de dado condiz com o esperado pela aplicação, o tamanho do dado inserido bem como evitar o envio de qualquer “tag” que possa causar danos ao sistema. Para o tamanho de campos dos dados a serem inseridos nos formulários devem ser utilizados “maxlength” e “size”. A eliminação de “tags” deve ser realizada através da utilização de funções específicas do “PHP”, para este fim.
  • 87. 8.9.1 Validação de campos no lado cliente Existem vários scripts em javascript que validam os campos digitados em um formulário de inserção de dados e emitem alertas através de janelas avisando sobre os possíveis erros encontrados ou usam máscaras que evitam erros de digitação sendo as mais comuns, as utilizadas para campos do tipo CPF, CNPJ e telefone. Este tipo de validação pode ser visualizado através do código-fonte da página. 8.9.2 Validação de campos no lado do servidor As validações no lado servidor ficam protegidas e não podem ser visualizadas no código-fonte da página. São scripts em “PHP” que podem ser incluídos no corpo do próprio código-fonte ou serem instanciados via “include” ou “require once”. 8.9.3 Validação de formulário contra SQL Injection Injecções SQL tornam possível para os atacantes de modificar algumas consultas SQL inseguro, o script é executado, de tal forma que poderia alterar dados em seu banco de dados ou dar a dados sensíveis para o atacante. Isso é por causa da entrada do usuário invalidado. Abaixo temos uma parte do código-fonte de um formulário de login de um componente MVC.
  • 88. Figura 30 – $_Get[] Fonte: autoria própria (2011) A variável $database executa uma consulta e seleciona todos os registros da tabela mytable onde a chave primária da tabela possua o mesmo valor passado no formulário através do campo que passa o valor da variável $value. Um invasor pode entrar com uma seqüência do tipo "1 OR 1 ', no formulário e os resultados da consulta ficariam parecido com: Figura 31 – SQLInjection Fonte: autoria própria (2011) A consulta irá retornar todas as linhas da tabela jos_mytable, o formulário de “login” acaba de ser invadido e a segurança do sistema comprometida. As seguintes medidas deveriam ter sido aplicadas em todas as entradas dos formulários de consulta “SQL” para campos que recebam os números inteiros em consultas SQL, para proteger o mesmo de ataques do tipo SQL Injection:
  • 89. Figura nr 32 – String SQLInjection Fonte: autoria própria (2011) Além disso, devemos usar mosGetParam () para recuperar a entrada do usuário a partir da solicitação, por exemplo: Figura nr 33 – String SQLInjection Fonte: autoria própria (2011) mosGetParam irá retornar valores de escape, independentemente da configuração do PHP magic_quotes_gpc. JRequest:: getVar – retornará valores “unsecaped”, independentemente da configuração do PHP magic_quotes_gpc. Em Joomla! 1.5, devido ao suporte UTF- 8, a regra-quadro é que as variáveis no código são escapados, e banco de dados apropriado escapar deve ser aplicado no momento da requisição do banco de dados, com US $-> db getEscaped ($ string) ou usando o objeto de Métodos save () Que fazem o bom escape. 8.9.4 Validação de formulários contra ataques XSS Cross Site Scripting (XSS) significa a execução de código script (JavaScript por exemplo) em um navegador por visitantes. É importante evitar o uso indiscrimidado
  • 90. do “echo” no código-fonte fo componente por ser potencialmente perigoso para os visitantes: Figura 34 – String Request Fonte: autoria própria (2011) Usar mosGetParam () para recuperar a entrada do usuário a partir de um pedido, pode melhorar muito a segurança. Mas não confie no usuário, também dê uma boa olhada em lugares onde ecoam as informações para o browser. Use: Figura 35 – String HmtlSpecial Fonte: autoria própria (2011) 8.10 VALIDAÇÃO DO NÍVEL DE PERMISSÃO DOS USUÁRIOS Componentes que possuam diferentes níveis de acesso devem possuir linhas de validação para garantir que apenas usuários com o nível de permissão adequada possam acessar determinadas áreas do mesmo. O componente deve verificar se o usuário faz parte do grupo de usuários com nível de acesso “gerente”, “administrador” ou “super administrador”. 8.11 SEGURANÇA NA PROGRAMAÇÃO DE COMPONENTE MVC O primeiro cuidado que você precisa ter é evitar o acesso direto de componentes, módulos, plugins, etc. Todo mundo está careca de saber que os componentes do
  • 91. Joomla ficam no diretório /components, os módulos ficam no diretório /modules e os plugins no diretório /plugins. Além disto, os subdiretórios são identificados como com_seuComponente, mod_seuMódulo e assim por diante. Devido ao padrão utilizado, é muito fácil chamar diretamente uma extensão. Basta colocar o seguinte na barra de endereços do navegador: http://www.seusite.com.br/index.php?option=com_seucomponente Com esta chamada, se o seu componente estiver programado para executar algum código, existe o perigo de invasão. O Joomla deve ser utilizado para fazer o bloqueio. Quando o Joomla é inicializado, a variável _JEXEC também é inicializada e só será reconhecida se o próprio Joomla fizer a chamada, ou seja, nas chamadas diretas ela será ignorada. Para se proteger das chamadas diretas basta incluir a seguinte linha no início de cada script PHP do componente MVC: Figura nr 36 – JEXEC Fonte: autoria própria (2011) Este simples recurso irá aumentar consideravelmente a segurança do componente MVC. 8.12 CONSIDERAÇÕES PARCIAIS As melhores práticas são divididas em áreas de responsablidade:  Código-fonte do CMS: a cargo da equipe de desenvolvimento do Joomla! que deve prover releases de segurança tão logo sejam descobertas vulnerabilidades ou novas técnicas de invasão;
  • 92.  Código-fonte das extensões mvc de terceiros: a cargo do desenvolvedor da extensão, que teve ter a exata noção do impacto negativo para o projeto Joomla, como um todo, em caso de invasão através de sua extensão;  Websites: fica a cargo do profissional que desenvolveu o website, a segurança relacionada as permissões de pastas e arquivos, escolha de provedor idôneo, escolha de extensões confiáveis, não utilização de templates piratas, aplicação de testes de vulnerabilidades nos projetos; e  Infraestrutura: a cargo das empresas prestadoras de serviço de hosting com ambiente compatível com o CMS Joomla!
  • 93. CONCLUSÃO Diariamente somos surpreendidos pela quantidade crescente de incidentes relacionados à segurança de projetos web, particularmente em websites que sofrem defacement e comprometimento de suas bases de dados. A responsabilidade fica dividida entre o desenvolvedor, provedor de hospedagem e aplicativo. A falta de comprometimento de “pseudo-profissionais” que não entregam os projetos prometidos no tempo acordado fazem com que o webdesign seja prejudicado perante a parcela da sociedade que usa este serviço. A conseqüência do descrédito é um número crescente de “aventureiros” e profissionais liberais de outras áreas que resolvem fazer seus próprios websites em busca de economia ou por medo de investir em algo que não irá receber. A profissional web precisa capacitar-se, atualizar-se e valorizar o webdesign como um todo, pois a época das páginas estáticas já ficou para trás. A equipe de desenvolvimento do CMS Joomla! busca manter-se na vanguarda lançando, através do time de segurança, releases a cada novo tipo de ataque iniciado, mas, a guerra é desigual e a cada dia novos tipos de atos ilícitos surgem desafiando e testando a capacidade de reação de todos os envolvidos no projeto. Os provedores de hospedagem precisam assumir as suas responsabilidades e melhorar os seus serviços através de investimento em infraestrutura, suporte técnico realmente capacitado, atualização e configuração correta dos aplicativos que fazem parte do acrônimo “LAMP”. É inadmissível que “vendam” hospedagem para Joomla! e permitam que programas automáticos instalem versões desatualizadas do CMS, passando ao usuário toda a responsabilidade pelo resultado final.
  • 94. Usuários não técnicos precisam entender que Joomla! é um Gerenciador de Conteúdos cuja característica principal está relacionada à sua simplicidade de administração e gerenciamento do “design de conteúdo” de um webdesign. Joomla! não faz nada, apenas gerencia o que foi desenvolvido por uma equipe de profissionais e hospedado em um bom provedor. Logo, ao não técnico, cabe gerenciar e não desenvolver. Webdesign pouco tem haver com arte estando embasado em técnicas e padrões que devem ser seguidos. A arte, fica a cargo do “designer gráfico” que no contexto de um projeto com CMS Joomla! será responsável pela criação do “design de página” junto com o webdesigner. Havendo necessidade de desenvolvimento de alguma extensão específica entra em campo a equipe de programadores e apesar da baixa curva de aprendizagem que tornou o CMS Joomla! campeão em downloads e utilização, os usuários precisam conscientizar-se da necessidade de capacitarem-se para bem utilizar a ferramenta. Aventurar-se no desenvolvimento de um componente MVC sem os devidos pré- requisitos relacionados à Programação Orientada a Objetos coloca em risco não só a reputação do usuário enquanto profissional, em caso de uma invasão bem sucedida. A marca do cliente e o projeto Joomla! como um todo sofre o impacto nefasto do descrédito a cada evento relacionado a incidentes de segurança envolvendo o CMS. Precisamos estar cientes da importância de projetos de software livre open source, tipo o CMS Joomla!, para a sociedade em geral. Anualmente várias licitações são abertas e milhares, milhões de reais são investidos com a utilização de nossos impostos. Quando um website em Joomla! é invadido, a segurança do CMS é questionada prejudicando sua participação em projetos desta natureza. Abre-se espaço para os CMS proprietários que escravizam usuários e clientes com suas licenças e oneram os valores finais dos projetos web.
  • 95. TRABALHOS FUTUROS Espero com este estudo ajudar desenvolvedores de extensões a produzirem produtos de qualidade e seguros, que venham trazer novas funcionalidades, sem colocar em risco a segurança do CMS Joomla! Pretendo desenvolver uma extensão que automatize o processo de mudança de ID do usuário administrador, minimizando ataques de SQL INJECTION em cima deste registro default da instalação Joomla!
  • 96. REFERÊNCIAS BIBLIOGRÁFICAS NORTH Barrie M: Joomla! 1.6 A User's Guide: Pearson Education, INC. USA, 2011. MEMÓRIA Felipe: Design para a Internet: ELSEVIER, 2006. NIELSEN JAKOB: Projetando Websites Designing Web Usability: ELSEVIER, 2000. RAHMEL Dan: Professional Joomla!: Ed. Wiley Publishing INC. USA, 2007. KENNARD, James: Mastering Joomla! 1.5 Extension and Framework Development: Ed. Packt Publishing INC. USA, 2007. NORTH Barrie M: Joomla! Guia do Operador: Ed. Alta Books, 2008. CARATTI Ricardo Lima e SILVA Leonardo Mafra: Joomla! Avançado: Ed. Novatec, 2009. MITNICK Kevin D: A Arte de Enganar: Ed. Makron Books, 2005. HOPE Paco e WALTHER Ben: Web Segura Guia de Testes e Soluções: Ed. Alta Books, 2009. FAIRCLOTH Eremy, HURLEY Chris, e VARSALONE Jesse: Penetration Tester's Vol 2: Ed. Elsevier INC. USA, 2007. ALPHAPLUG. Disponível em:< http://www.alphaplug.com/index.php/products/mvc- generator-online.html>. Acesso em: 12 de janeiro 2011. APTANA. Disponível em: <http://www.aptana.com>. Acesso em: 12 janeiro 2011. JOOMLA! BRASÍLIA. Disponível em: <http://www.joomlabrasilia.org/tutoriais-de- joomla/seguranca-e-joomla.html>. Acesso em 12 de janeiro 2011.
  • 97. JOOMLA BRASÍLIA. Disponível em: <http://www.joomlabrasilia.com.br/tutoriais/joomla-16-for-dummies/131-o-que-e- joomla.html>. Acesso em: 05 de abril de 2011. JOOMLA! OPEN SOURCE. Disponível em: <http://docs.joomla.org/Vulnerable_Extensions_List>. Acesso em: 12 de janeiro 2011. ZONE-H.ORG – UNRESTRICTED INFORMATION SPECIAL DEFACEMENT ARCHIVE . Disponível em:< http://www.zone-h.org/archive/special:1>. Acesso em: 12 de janeiro de 2011. ALDEIA NUMA BOA. Disponível em: <http://www.numaboa.com/informatica/tutos/joomla>. Acesso em: 03 de janeiro 2011. WEBINSIDER. Disponível em:<http://webinsider.uol.com.br/2005/06/08/o-que-e- cms-e-porque-voce-precisa-de-um/>. Acesso em: 02 de abril de 2011. WEBINSIDER. Disponível em:<http://webinsider.uol.com.br/2006/08/31/joomla-e- opcao-de-cms-que-vem-crescendo-rapidamente/> Acesso em: 02 de abril de 2011. WEBINSIDER. Disponível em: < http://webinsider.uol.com.br/2007/08/27/produtoras- perdem-o-medo-de-usar-ferramentas-gratuitas/> Acesso em: 02 de abril de 2011. ZERODAYSCAN. Disponível em: < http://www.zerodayscan.com/ >. Acesso em: 05 de abril de 2011. OWASP. Disponível em: < http://yehg.net/lab/pr0js/files.php/joomscan-latest.zip/ >. Acesso em: 05 de abril de 2011.

×