Quanto aos testes de penetra¸c˜ao realizados sobre a aplica¸c˜ao html5vuln, verificou- se que a dificuldade de dete¸c˜ao de vulnerabilidades HTML5 via ZAP, est´a em primeiro lugar relacionada com a capacidade de dete¸c˜ao do pr´oprio ZAP relati- vamente `as amea¸cas comuns (i.e. XSS, CSRF, entre outras), e `as dificuldades que estas acarretam. Em segundo lugar com os nomes atribu´ıdos `as vari´aveis e protocolos, tal como foi descrito nas sec¸c˜oes anteriores.
Extens˜
ao
ao
ZAP
Figura 7.6: Exemplo de dete¸c˜ao de vulnerabilidades HTML5 do ZAP.
Conclus˜ao e Trabalho Futuro
Os testes de dete¸c˜ao realizados demonstraram que o ZAP consegue identificar a existˆencia das vulnerabilidades e dos riscos de seguran¸ca discutidos neste cap´ıtulo. No entanto, em alguns casos ´e necess´ario ensin´a-lo para que essa identifica¸c˜ao tenha sucesso. Esta dete¸c˜ao apenas acontece quando o c´odigo injetado afeta a mesma p´agina que foi explorada na aplica¸c˜ao, caso contr´ario essa vulnerabilidade n˜ao ´e identificada. Resumindo, relativamente `a capacidade de dete¸c˜ao, apenas se pode concluir que determinada aplica¸c˜ao apresenta certas vulnerabilidades, mas nunca se pode concluir quanto `a total inexistˆencia delas.
A Figura 7.6 corresponde a um exemplo de dete¸c˜ao do ZAP recorrendo a estes novos m´odulos. Neste caso foi identificado um risco de seguran¸ca relativo a uma utiliza¸c˜ao indevida dos Web Sockets para tentar roubar o cookie da sess˜ao, atrav´es da inje¸c˜ao do vetor de ataque ilustrado na figura (i.e. com o texto selecionado). Atrav´es da mesma figura tamb´em ´e vis´ıvel a dete¸c˜ao de um risco de seguran¸ca relativo ´a m´a utiliza¸c˜ao do CORS. Pois como se pode ver o cabe¸calho da resposta HTTP possui a propriedade Access-Control-Allow-Origin definida como ”*”, assim como a propriedade Access-Control-Allow-Credentials definida como true o que tamb´em permite enviar os cookies.
Cap´ıtulo 8
Conclus˜ao e Trabalho Futuro
O HTML5 traz melhorias significativas para a web, e com isso novas preocupa¸c˜oes de seguran¸ca. Os conceitos e caracter´ısticas apresentadas ao longo deste docu- mento, focam precisamente algumas dessas preocupa¸c˜oes relativas aos novos re- cursos HTML5, descritos nas especifica¸c˜oes da W3C e WHATWG.
8.1
Conclus˜ao
Este trabalho consiste sobretudo num levantamento detalhado sobre a seguran¸ca na web, sobre quais as principais vulnerabilidades presentes nas aplica¸c˜oes web, e como estas v˜ao evoluindo com o aparecimento de novas tecnologias como ´e o caso do HTML5. O scanning de seguran¸ca de aplica¸c˜oes e a dete¸c˜ao de algumas dessas vulnerabilidades ´e outro dos objetivos delineados no inicio deste documento.
Olhando um pouco para os objetivos propostos, o primeiro objetivo ´e coberto no cap´ıtulo 3, onde s˜ao apresentados quais os m´odulos que constituem um BB- WASS, incluindo algumas das suas maiores dificuldades. Resumindo os maiores desafios dos BB-WASS situam-se na fase de crawling e de an´alise das respostas. Relativamente `a fase de crawling a dificuldade ocorre quando as p´aginas requerem inputs humanos (e.g. dados de login, captcha, etc). Outro desafio do scanner
Conclus˜ao e Trabalho Futuro
crawling ap´os a submiss˜ao de dados para a aplica¸c˜ao. A dificuldade na an´alise das respostas tem a ver com a decis˜ao de classificar determinada dete¸c˜ao como sendo uma vulnerabilidade sem uma garantia absoluta.
O objetivo de identificar as amea¸cas de seguran¸ca mais comuns e que mais fre- quentemente afetam as aplica¸c˜oes web s˜ao descritas no cap´ıtulo 4. Neste cap´ıtulo s˜ao identificadas o TOP5 das amea¸cas de seguran¸ca mais cr´ıticas classificadas pela OWASP e aquelas que, de certa forma, est˜ao mais relacionadas com o HTML5. Neste caso, ´e apresentado em que consiste cada uma delas, exemplos de aplica¸c˜ao das mesmas e que medidas devem ser tomadas para prevenir essas amea¸cas.
A an´alise dos riscos de seguran¸ca derivados das novas funcionalidades do HTML5, relativo ao terceiro objetivo s˜ao cobertos no cap´ıtulo 6. Onde s˜ao descritas cada uma das funcionalidades, acompanhadas da descri¸c˜ao dos seus riscos, de qual o impacto destes riscos para com o cliente ou UA, assim como da apresenta¸c˜ao de medidas de atenua¸c˜ao. De entre essa an´alise concluiu-se que o cliente precisa ser protegido, assim como a implementa¸c˜ao segura do lado do servidor tamb´em ´e necess´aria. Nem todas as vulnerabilidades podem ser atenuadas atrav´es da imple- menta¸c˜ao segura no lado do servidor, algumas tamb´em afetam o lado do cliente e o servidor nada pode fazer para proteger o lado do cliente. Por exemplo, o servidor n˜ao consegue prevenir o envenenamento da cache de aplica¸c˜oes offline. A s´ıntese do cap´ıtulo em causa j´a resume as principais medidas a adotar, mas conv´em que sejam seguidas a medidas apresentadas para cada uma das funcionalidades.
O contributo apresentado no cap´ıtulo 7 corresponde ao derradeiro objetivo re- lativo `a contribui¸c˜ao com m´odulos extra de dete¸c˜ao adicionados ao ZAP, e que acaba por corresponder a uma prova de conceito de toda esta an´alise. Tamb´em ficou vis´ıvel que as vulnerabilidades mais influentes s˜ao a inje¸c˜ao de c´odigo em particular o XSS. No caso do HTML5 o XSS apresenta-se como o m´etodo ideal para os testes de penetra¸c˜ao. Tudo o que envolve a execu¸c˜ao de JS pode acarretar um risco, por isso ter especial cuidado com isso. Caso uma aplica¸c˜ao web baseada em HTML5 n˜ao possua vulnerabilidades XSS, ent˜ao pode considerar-se que os riscos de seguran¸ca herdados do HTML5 s˜ao reduzidos. No entanto, importa reter
Conclus˜ao e Trabalho Futuro
que com o HTML5 os ataques XSS ficaram muito mais poderosos e perigosos e at´e mesmo mais f´aceis de executar, sobretudo devido ao CORS, Web Messaging e Web Sockets, pois tornou o roubo de informa¸c˜ao muito mais f´acil.
Pode concluir-se ainda que a capacidade de dete¸c˜ao dos scanners Black Box, acusa dificuldade na dete¸c˜ao de Stored XSS e Stored SQL Injection, sendo esta ultima ainda mais dif´ıcil de detetar, at´e mesmo quando os scanners s˜ao ensinados para o efeito.