Quando o Record.pt lançou o novo site, a primeira coisa que fiz foi ir ver o código do site bem como HTTP headers, pedidos XHR, cookies, etc! Ao fim de alguns minutos a interagir com o site, percebi que o endpoint de submissão de um voto num comentário era um GET.

Na altura não liguei, embora com noção que alguém se poderia aproveitar desta situação, não quis acreditar que efetivamente alguém se desse a esse trabalho!

Passados uns dias encontrei este comentário:

Percebi que mais alguém tinha descoberto o problema no endpoint das votações dos comentários! Mas apesar do que este comentário indica, o problema não foi resolvido! O endpoint continuava um GET.

Um exemplo prático de como aproveitar esta vulnerabilidade seria colocar uma tag de imagem com a source a ser um desses endpoints. Esta tag num desses sites dos ‘inácios’ da vida, com toda a certeza gerava milhares de votos por dia! E era apenas um tag por ali perdida completamente inofensiva!

Ao fim de meia dúzia de tweets com um jornalista do Record.pt (obrigado João Oliveira) expus o problema, bem como uma possível e fácil solução, trocar de GET para POST!

Endpoints de submissão/escrita nunca devem ser um GET! Ao utilizarem este método de HTTP, para este tipo de acções, o Record.pt ficou vulnerável a ataques de CRSF (Cross-Site Request Forgery).

Entretanto o problema foi corrigido com a solução que apontei. No entanto não recebi qualquer aviso ou indicação por parte do Record.pt que o problema tivesse sido efectivamente resolvido.

Depois desta situação, comecei a pensar, se um site como o Record.pt, que é consecutivamente o terceiro site mais visitado no rank netScope como estariam outros sites portugueses a nível de segurança!

Não foi preciso muito para descobrir outro site com algum tipo de vulnerabilidade! E desta vez foi a TVI24!

Sendo apenas um curioso no que diz respeito à segurança web, vendo um input de pesquisa a primeira tentativa que faço, é injetar alguns vetores de XSS. O que acontece, é que o javascript injectado estava a ser bloqueado pelo próprio browser! A TVI24, e bem, tinha definido o HTTP Header X-XSS-PROTECTION 1 mode=block, que faz com que os browsers bloqueiem a execução de javascript. Isto significa que qualquer coisa que se coloque no input de pesquisa, seja efectivamente executado.

Foi a altura de se injetar HTML dentro do input de pesquisa. O resultado podia ser algo deste género:

Com isto, consegue-se inserir qualquer elemento de HTML, incluindo css inline, e todo o código é executado. Este tipo de manipulação podia levar a que qualquer pessoa pudesse escrever notícias fictícias no site da TVI24 e passar o link a um amigo! Está no site da TVI24 é suposto ser verdade e não causar quedas na bolsa! É fácil fazer engenharia social assim :)

Ao contrário do que aconteceu no caso do Record.pt, vi esta vulnerabilidade a ser bastante usada dada a sua simplicidade e ao que se conseguia fazer. Era melhor contactar a TVI24 para resolverem o problema o mais rapidamente possível.

Ao fim de uns bons minutos a procurar um contacto encontrei o relacoes.publicas@tvi.pt, como sabia que não seria uma pessoa ‘técnica’ a ver o email também enviei para o responsável técnico do domínio tvi.pt. Apesar das horas tardias a que enviei o email, recebi imediatamente uma resposta por parte das relações públicas da TVI que encaminhou para o departamento responsável!

Passados uns dias o problema está resolvido! e a TVI24 não está mais vulnerável a ataques do tipo HTML Injection. Uma vez mais, não recebi qualquer contacto de retorno por parte da TVI24.

Update: A TVI24 entretanto já me contactou a informar que corrigiu o problema e a agradecer os ter informado e esperado pela resolução para publicar os problemas!