Hoje pela manhã, uma pessoa que me adicionou ao MSN, via site, entrou em contato comigo e começou a me questionar sobre serviços de hospedagem.

Precisei me ausentar um pouco para resolver problemas com dois trabalhos a serem entregues, e depois fui ver o que ele havia deixado em tela, já que havia dito que queria me perguntar sobre um assunto.

E o que ele me perguntou, ou disse, foi mais ou menos isso:
“André, hoje em dia não existem muitos DESENVOLVEDORES WEB, por conta dos CMS´s!
Creio eu que as pessoas não gostam de codificar, e já que os CMS´s já vêm prontos para uso, as coisas ficam mais fáceis!
Um dos problemas que vejo hoje em dia, é que quando você coloca o seu CMS para validar o código no modo STRICT, ele não valida! (…)”.

Bom, isso me fez pensar em uma coisa bem sutil, mas da mesma maneira que me fez pensar, gostaria e muito de saber a opinião de vocês: compensa SEGUIR OS PADRÕES WEB?

Eu particularmente creio que sim!
A partir do momento que existem BOAS PRÁTICAS (que ao meu entender não significam REGRAS!), eu não vejo problemas em segui-las e/ou implementá-las! Se determinada coisa foi feita para ser usada de uma maneira, use-a da maneira que foi projetada! Não tente inventar moda ou usar um “address” para colocar algo em itálico! Use “em” para itálico!
Mas o que me faz pensar mesmo, e sinceramente, me revoltar demasiadamente, são serviços que temos na Internet que não respeitam regras!
Muitos que acessam meu site e vêem minhas vídeo aulas, sabem que eu tenho um TITÂNICO DESPRAZER em trabalhar com o Internet Explorer. Em todas suas versões! Eu odeio de paixão esse programa!
E, do que adianta nós seguirmos os PADRÕES WEB, se quem necessita renderizar esses padrões não os entende?

Você coloca determinada regra no CSS, valida o arquivo, e no validador dá que seu CSS está perfeito! Você abre o Internet Explorer e volta ao seu arquivo HTML para botar comentários condicionais para CONSERTAR A EXIBIÇÃO NA PIMBÓRDIA DO INTERNET EXPLORER!
Do que adianta fazer as coisas da maneira correta, sendo que às vezes, ou normalmente, temos programas que não respeitam isso?
O que eu acho mais estranho, é que fazendo-se uma comparação idiota, é o seguinte: Você vai a um dentista, e pede para o/a profissional arrumar seu dente da frente que tá com problema. O profissional vai lá, arruma o seu dente, e bota um “remendo” de cor “duvidosa” no seu dente. Você vai voltar nele?

É CLARO QUE NÃO!

Você vai procurar outro correto? Para quem têm um mínimo de inteligência, sim!
Então, eu me pergunto: PORQUE INSISTIMOS EM CORRIGIR ERROS NO INTERNET EXPLORER? PORQUE CONTINUAMOS A DESENVOLVER SITES PARA UM PROGRAMA QUE NÃO RESPEITA OS PADRÕES?
Porque é o mais utilizado?

O GOOGLE já anunciou que não dará mais suporte às versões antigas do IE. Ele está errado, em tirar dos usuários o bom funcionamento do seu sistema? Eu, sinceramente, acho que não.
Não quero culpar o usuário por não atualizar seu navegador, pois se muitos deles têm dificuldade em navegar na web, imagine então atualizar programas!
Eu acho que a culpa na realidade é de quem FABRICA essa %$#@%! Me desculpe os mais puritanos, meu palavreado!

Gostaria muito que houvesse uma corrente, forte, como houve para a mudança do HTML 4 para o HTML5, que pregasse a “não utilização de comentários condicionais no INTERNET EXPLORER”. Simplesmente, gostaria e muito, que nós, webdesigners e webdevelopers, numa corrente de tentar “mudar a internet” (nada utópico de minha parte!), parássemos de dar suporte ao IE.

Quem sabe, os “profissionais” que criam esse navegador fizessem um serviço decente que atendesse aos padrões, assim como o Firefox ou o Chrome atendem. Pelo menos, eu consigo ver meu site do jeito que é para ficar nesse navegador.

Aí eu te pergunto: compensa usar os padrões web? Eu uso… embora o Internet Explorer não me ofereça suporte!

P.S. – Uma pergunta que não quer calar: “Porque lançaram o IE9, se eu preciso colocar uma linha no HEAD do meu HTML que o faça se comportar como IE8?”

Este tipo de ataque explora falhas de segurança na politica SOP (same origin policy). SOP é o conceito de segurança mais importante dos browsers modernos. Esta política diz que, páginas web de diferentes origens, por padrão, não podem comunicar-se entre si.
XSHM é baseado no fato de que os objetos de browser no client-side não são segmentados em uma base por site. Manipulando o histórico do browser, pode fazer com que o SOP seja comprometido, permitindo que CSRF’s bi-direcionais aconteçam, ocasionando diversos riscos como:
– violação da privacidade de usuários;
– login status detection;
– mapeamento de recursos, entre outros

Informações Inferência

É possível a inferência de informações sigilosas de uma página em uma origem diferente, se implementar num redirecionamento condicional. Suponha que em um aplicativo de RH que não seja publicamente acessível, onde o usuário pode pesquisar empregados por nome, salário e outros critérios. Se a pesquisa não tem nenhum resultado, um comando de redirecionamento é executado com um “Not Found” página. Ao apresentar a seguinte URL:

http://Intranet/SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500

e observando o redirecionamento NotFound, os atacantes podem inferir informações sensíveis sobre o salário de um trabalhador.
Isso pode ser feito usando o vetor de ataque que se segue:

1. Criar um IFRAME com src = “NotFound.aspx”
2. Lembre-se o valor atual da history.length
3. Alterar src do IFRAME para “SearchEmployee.aspx? Name = Jon& SalaryFrom = 3000 = 3500 & SalaryTo”
4. Se o valor da history.length permanece o mesmo, então sua pesquisa não tem resultados

Ao repetir o ataque acima e tentar diferentes valores de salário, um atacante pode reunir informações detalhadas de qualquer funcionário. Este é um vazamento de informação muito séria Cross-Site. Se um aplicativo tem uma função como uma página de pesquisa com redirecionamento condicional, então esta aplicação é vulnerável a XSHM e, essencialmente, é semelhante a uma exposição direta à Universal XSS – a aplicação em si é XSS-safe, mas executá-la a partir de um site diferente dentro de um IFRAME, torna vulnerável.
Exemplo – Condition Leakage
Condition leakage ocorre quando um atacante pode injetar valores sensíveis de um determinado conditional statement na aplicação atacada. Por exemplo, se um site utiliza a seguinte lógica:
Página A: se (condição) – Redireciona (página B)
Um atacante pode executar um Cross-site Request Fogery (já falado em outros artigos) e conseguir uma indicação sobre o valor da condição existente como feedback. Este ataque é executado a partir de um site atacante. O site então envia um Cross-site Request para o site vítima, e manipulando o History Object, obtem um feedback sobre a informação requerida que o site vitima irá expor.
Vetor de Ataque
1. Criar um IFRAME com src=Pagina B
2. Salve o valor atual do history.lenght
3. Modifique o src do IFRAME para página A
4. Se o valor do history.lenght for o mesmo, isso quer dizer que a condição é verdadeira.

Protegendo a aplicação
Para conseguir uma proteção eficiente contra XSHM, ambas as URLs do site de origem e a que será redirecionada, devem conter um token randomico. Por exemplo, redirecionando para uma pagina de Login, será seguro apenas no seguinte caso:

If ( !isAuthenticated)
Redirect(„Login.aspx?r=? + Random())

Para previnir um ataque de URL/Parameter enumeration, qualquer URL deve conter um forte token randomico.

O ataque HTTP Request Smuggling explora uma análise incompleta dos dados apresentados feito por um sistema intermediário HTTP trabalhando como um proxy. HTTP Request Smuggling consiste no envio de uma solicitação HTTP especialmente formatada que será analisada de forma diferente pelo sistema de proxy e pelo sistema final, então o atacante poderia roubar uma solicitação para um sistema sem o outro estar ciente disso. Este ataque faz com que seja possível explorar outros ataques, como cache poisoning, session hijacking, Cross-site Scripting (XSS) e, sobretudo, a capacidade de burlar a proteção de firewall de aplicações web.

Para explorar o HTTP Request Smuggling, algumas condições específicas devem existir, tais como a presença do sistema de proxy específico e versão, como SunOne Proxy 3.6 (SP4) ou beta FW-1/FP4-R55W ou uma vulnerabilidade de XSS no servidor web.

Basicamente o ataque consiste em enviar uma solicitação HTTP que encapsula uma segunda solicitação HTTP no mesmo cabeçalho, como mostrado abaixo:

GET /some_page.jsp?param1=value1&param2=
Content-Type: application/x-www-form-
Content-Length: 0
Foobar: GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Neste caso, o primeiro cabeçalho HTTP é analisado pelo sistema de proxy, e o segundo pelo sistema final, permitindo ao invasor burlar as regras de acesso do proxy.

Exemplo: Request Credential Hijacking

Outra area de interesse é a habilidade do atacante forçar a execução de um script (/some_page.jsp) com as credenciais de um cliente. Esse ataque é similar aos efeitos do ataque de Cross-site Request Forgery, mas este é mais eficiente, pois o atacante não é obrigado a interagir com o cliente (vítima). O ataque ocorre como abaixo:

POST /some_script.jsp HTTP/1.0
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
Content-Length: 142
this=thatGET /some_page.jsp?param1=value1&param2=value2 HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Foobar:

Quando o cliente envia uma requisição, como:

GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Tomcat irá colocar esta requisição na fila de incompletes, e juntos, terão:

GET /some_page.jsp?param1=value1&param2=value2 HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Foobar: GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Agora com uma requisição completa, ele irá chamar o script /some_page.jsp e retornar seus resultados ao cliente. Se este script é um pedido de alteração de senha, ou uma transferência de dinheiro para a conta do atacante, então isso pode incorrer em danos potencialmente graves para o cliente.

Muitas vezes durante a implantação de sistemas, os desenvolvedores acabam utilizando scripts auxiliares para ajudar muitas vezes no debug, ou então gerenciar de forma mais simples algum processo junto a database, ou então simplesmente ao utilizar sistemas já prontos, como por exemplo, o Joomla, acabam ficando para traz arquivos que podem ser perigosamente utilizado por atacantes.

Entre esse tipo de “sucata” acabam ficando:

– infs,
– arquivos.inc
– pastas com arquivos de backup, e etc

Apesar de modificar a configuração do Webserver para evitar que o index da pasta seja visível e adicionando um index em todas as pastas, existem diversas possibilidades de detectar estes dados e na maioria das vezes eles contêm informações como senhas de base de dados, source code de aplicação ou então algum script privilegiado que foi negligenciado pelo desenvolvedor.

O ataque de Forced Browsing consiste no uso de diversas técnicas que visam enumerar entre as possibilidades disponiveis:

– Diretórios importantes e/ou que podem conter informações privilegiadas (/admin, /install, /setup, /includes, etc);
– Arquivos de backup com códigos-fonte de aplicações ( index.php.bak, login.bak, etc.);

Uma ferramenta automatizada pode varrer milhares de combinações em sua database de conhecimento de possíveis pastas. O nikto é uma delas. Ele atua como ferramenta opensource para teste de diversas vulnerabilidades em sistemas web, tais como:

– Má configuração no webserver
– Ataques de xss, sql injection, entre outros
– Ataques de Force Browsing.

A técnica utilizada para enumerar recursos escondidos no webserver é conhecida como fuzzing e é vastamente utilizada por analistas de segurança a fim de detectar vulnerabilidades até então desconhecidas.

Basicamente a tecnica consiste em enviar requisições para o servidor web e analisar a resposta.

Quando um recurso existente é acessado, o servidor responde com a mensagem HTTP 200 OK.

Da mesma forma existem diversas outras respostas que podem evidenciar a existência de informações interessantes tais como a mensagem HTTP 403 que se refere à necessidade de autenticação para acessar o conteúdo no webserver.

Eliminando as respostas 404 (not found), a ferramenta consegue minerar as respostas e separar somente as informações realmente interessantes.

HTTP response splitting ocorre quando os dados entram na aplicação web através de uma fonte não confiável, frequentemente em um request HTTP, sendo essa manipulada de forma que os dados enviados sejam adicionados em um response Header para o usuário sem ser validada a procura de caracteres maliciosos.

O HTTP response splitting é o que chamamos de vetor de ataques e não um ataque com finalidade por si só. Quando focamos a atenção meramente na técnica, vemos que ela simplesmente retrata um atacante enviando dados maliciosos para uma aplicação vulnerável e a aplicação inclui os dados no cabeçalho de resposta.

Para montar um exploit bem sucedido, a aplicação deve permitir que os dados inseridos contenham o caractere CR (carriage return, que pode ser enviado através de %0d ou \r) e o LF (line feed, que pode ser inserido através de um %0a ou \n) diretamente no header. Estes caracteres não apenas dão ao atacante controle dos headers e o corpo da resposta como também o restante de toda a resposta que a aplicação pretendia enviar para o usuário, criando desta forma uma resposta totalmente controlada por ele.

Exemplo:
O segmento de códigos abaixo se refere ao nome do autor de um weblog, pelo campo author, através de um HTTP request e é setado em um cookie header pelo HTTP response

String author = request.getParameter(AUTHOR_PARAM);
…
Cookie cookie = new Cookie(“author”, author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

Tendo que uma string que consiste de caracteres padrão alpha-numeric, como por exemplo, “Joao Pedro” é enviada em um HTTP response incluindo este cookie tenha a seguinte forma:

HTTP/1.1 200 OK
…
Set-Cookie: author=Joao Pedro
…

Entretanto, devido o valor do cookie ser formado por dados não validados em um user input, a resposta somente irá permanecer desta forma se o valor submetido para AUTHOR_PARAM não contiver os caracteres CR e LF. Se um atacante submeter uma string maliciosa como, por exemplo,
“Hacker\r\n\HTTP/1.1 200 OK\r\n…”

A resposta HTTP pode ser quebrada em 2 responses com a seguinte forma:
HTTP/1.1 200 OK
…
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
…

Claramente a segunda resposta é totalmente controlada pelo atacante e pode ser construída com qualquer header e conteúdo desejado no corpo da pagina. A habilidade de um atacante construir respostas HTTP arbitrárias pode permitir uma variedade de ataques resultantes como, por exemplo:

– Cross-user Defacement
– Cache Poisoning
– Cross-site Scripting
– Page Hijacking

Nos próximos artigos veremos como utilizar a técnica demonstrada acima para obter diversos resultados de ataques como o Cache Poison e o Cross-site Scripting.

O ataque de Path Transversal tem o objetivo de acessar arquivos e diretórios que estão armazenados fora do diretório utilizado pela aplicação (Webroot).
Acessando a aplicação pelo browser o atacante pode olhar os links absolutos para arquivos armazenados no Web Server. Manipulando as variáveis que referencia os arquivos utilizando “dot-dot-slash (../)” utilizando diferentes seqüências e variações podem permitir acesso arbitrário a arquivos e diretórios no file system, incluindo código fonte da aplicação, arquivos críticos e de configuração do sistema operacional entre outros. Utilizando “../” o atacante consegue direcionar a aplicação para diretórios acima do diretório padrão.
Este ataque pode ser potencializado como veremos abaixo utilizando um código malicioso externo que pode ser injetado diretamente como variável na aplicação, sendo este ataque conhecido também como RFI (Remote File Injection). Este tipo de vulnerabilidade pode ser detectada facilmente utilizando scripts chamados de Spider/Crawler.

Vejamos abaixo dois exemplos clássicos desta falha.

Exemplo 1
O exemplo abaixo mostra como uma aplicação manipula recursos em uso.

http://site/get-files.jsp?file=report.pdf
http://site/get-page.php?home=aaa.html
http://site/some-page.asp?page=index.html

Neste exemplo é possível inserir a string maliciosa como parâmetro da variável a fim de acessar arquivos localizados fora do diretório onde estão publicados os arquivos web.

http://site/get-files?file=../../../../diretorio/arquivo
http://site/../../../../diretorio/arquivo

A URL abaixo mostra como explorar um sistema Unix para pegar seu arquivo de senhas.

http://site/../../../../etc/shadow
http://site/get-files?file=/etc/passwd

Exemplo 2
Vejamos um exemplo clássico de aplicação em PHP vulnerável.

$template = ‘blue.php’;
if ( is_set( $_COOKIE[‘TEMPLATE’] ) )
$template = $_COOKIE[‘TEMPLATE’];
include ( “/home/users/phpconf/templates/” . $template );
?>

Um atacante pode explorar esta vulnerabilidade enviando a seguinte requisição HTTP:

GET /vulneravel.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Gerando uma resposta do servidor como esta:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache

root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh
daemon:*:1:1::/tmp:
phpconf:f8fk3j1OIf31.:182:100:Developer:/home/users/phpconf/
:/bin/csh

A repetição dos caracteres ../ apos /home/users/phpconf/templates fez com que a função include() fizesse o include do arquivo /etc/passwd.

Como proteger sua aplicação:

• Preferivelmente trabalhe sem utilizar inputs de usuários na aplicação quando você utilizar file system calls
• Use chroot Jail e políticas de code Access para restringir onde os arquivos podem ser obtidos ou salvos em sua aplicação
• Sanitize todas as variáveis que sua aplicação utiliza impedindo assim que caracteres de escape maliciosos sejam indexados e processados

Para facilitar a vida dos desenvolvedores, abaixo seguem 2 regras para trabalhar melhor o aspecto de segurança da aplicação, seguindo como um roteiro para melhorar a segurança dos sistemas. Obviamente cada desenvolvedor deve verificar quais das regras se adéquam melhor as necessidades da aplicação. Na grande maioria dos casos o simples fato de aplicar 1 das regras já surte o efeito necessário como contenção de riscos na aplicação.

Nunca inserir dados não confiáveis exceto em locais permitidos.

Esta primeira regra é para negar tudo. Não insira dados inseguros em um documento HTML a não ser que seja em uma localização diferente das listadas abaixo. A razão disto é que existem muitos contextos estranhos em HTML que podem tornar o filtro por caracteres de escape muito complicado e as vezes ineficiente. Pensando friamente não existe nenhuma boa razão para colocar dados não confiáveis nestes contextos.

Diretamente em um Script:

Dentro de um comentário HTML:

Em um nome de Atributo:

… NUNCA COLOQUE DADOS NÃO CONFIAVEIS AQUI…=teste />

Em uma tag name:

E o mais importante: Nunca aceite códigos JavaScript a partir de uma origem não confiável e depois execute. Por exemplo, um parâmetro chamado “callback” que contem um JavaScript Code Snippet. Nem uma centena de escaping rules conseguiria consertar uma vulnerabilidade destas.

Faça HTML Escape antes de inserir dados não confiáveis em um elemento HTML

Esta regra é para aqueles que desejam colocar dados não confiáveis diretamente em algum lugar do corpo do formulário HTML. Isto inclui tags normais como div, p, b, td, etc. A maioria dos framworks web tem um método para HTML encoding que escapam os caracteres abaixo. Entretanto, isto é absolutamente não eficiente para outros contextos HTML.

…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…

…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…

Faça escape dos seguintes caracteres com HTML entity encoding para previnir problemas em contextos de execução, como por exemplo um script, style ou entção event handlers. Usar codificação hexadecimal é recomendada. Alem disto existem 5 caracteres significantes em XML (&, <, >,”,’) que podem ajudar em um contexto HTML.

& –> &
< –> <
> –> >
” –> “
‘ –> ‘ ‘ não e recomendado
/ –> / a barra de data é recomendada em contextos html.

Resumindo, quando pensamos em XSS attacks, temos que levar em conta que o Client Side é tão crítico quando o Server side, ou seja, temos que cuidar sempre do aspecto do cliente que acessa a aplicação evitando problemas futuros com roubos de informações.

(continua na próxima edição…)

Cross-site-scripting attacks, ou Xss como são conhecidos, são um tipo de Injection attacks, onde scripts maliciosos são injetados através de parâmetros confiáveis em um Website. O ataque de XSS ocorre quando um atacante utiliza a aplicação web para enviar códigos maliciosos, geralmente na forma de Browser Side Scripts para um usuário acessar.

O atacante pode utilizar o XSS para enviar um script malicioso com diversas finalidades:

– Roubar cookies do browser para efetuar um seqüestro de sessão;
– Iludir o usuário para que este acessse um determinado conteúdo e preencha dados seus pensando que está utilizando o site real, quando na verdade o conteúdo que o mesmo está acessando faz parte de um HTML malicioso que foi embutido em algum componente vulnerável da aplicação.

Os ricos de ataques XSS podem ser variáveis, pois depende muito do que o atacante pretende fazer com a falha que ele encontrou. Desta forma o XSS pode ser o vetor para uma infinidade de outros ataques muito mais perigosos como Browser Hijacking, ClickJacking e XSRF (Cross-site Request Forgery).

Como proteger sua aplicação para evitar que este tipo de falha seja utilizado contra seus usuários permitindo que credenciais sejam roubadas?

Dica importante:

Dados não Confiáveis

Dados não confiáveis são todos aqueles dados que são originados a partir de HTTP requests, em forma de parâmetros URL, form fields, headers ou Cookies. Porém dados que são originados a partir de Databases, web services e outros sources são frequentemente tratados também como não confiáveis a partir da perspectiva de segurança.

Todos os dados que sua aplicação utilizada devem ser sanitizados para remover caracteres de escape entre outras coisas. Nunca se deve trabalhar diretamente com dados inseguros em funções que injetem ou exibam informações em uma database ou em um form HTML.

(leia: Roteiro para a melhoria da segurança dos sistemas)

Filtragem Incorreta de Caracteres de Escape

Ocorre quando o dado inputado na variável não é filtrado para remoção de caracteres de escape e então é transformado em uma query SQL. Isto resulta na potencial manipulação de queries executadas na database pelo usuário da aplicação.

Um exemplo:

statement = “SELECT * FROM users WHERE name = ‘” + userName + “‘;”
Este código é designado para trazer resultados de um determinado username a partir da tabela users. Entretanto, se a variável “userName” for modificada para um determinado valor especifico que contenha caracteres de escape como por exemplo ‘, “, ), essa query SQL pode retornar mais do que o autor do código previu. Por exemplo, colocando o “userName” como:
a’ or ‘t’=’t
Ao ser executada pelo código da aplicação web a database irá executar o seguinte query:
SELECT * FROM users WHERE name = ‘a’ OR ‘t’=’t’;
Se este código for utilizado em um procedimento de autenticação, este exemplo pode ser utilizado para selecionar um usuário válido porque a validação do query ‘t’=’t’ é sempre válida, afinal t sempre é igual a t.
Gerenciamento de tipos de dados incorretos
Ocorre quando um valor inputado em um campo não é checado pelo tipo dele. Por exemplo, se a aplicação irá fazer uma checagem na base utilizando uma variável de tipo numérico e o programador não colocou uma checagem para validar se a variavel realmente tem um valor numérico. Por exemplo:
statement := “SELECT * FROM data WHERE id = ” + a_variable + “;”
Está claro neste statement que o autor do código definiu a_variable para ser um número correlacionado com o campo “id”. Entretanto, se de fato for uma string o usuário pode manipular o statemente como quiser, inclusive sobrepassando a necessidade de um caracter de escape. Exemplo, colocando a variavel como:
1;DROP TABLE users
Irá deletar a tabela “users” da database, porque para o sql a string acima será executada da seguinte forma:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;

Como o character “;” no SQL é um delimitador de linha, tudo que vier após ele será considerado um novo comando.

Existentes a mais de uma década, os ataques de SQL Injection vem crescendo drasticamente nos últimos anos, como exemplo, no segundo trimestre de 2008 tivemos aproximadamente 500.000 websites explorados com essa técnica.

Ataques de SQL Injection consistem na exploração de vulnerabilidades de segurança em um website inserindo e executando códigos maliciosos em uma base de dados. Podem ser utilizados para desfigurar um site modificando seus arquivos ou entradas no banco de dados (defacing) e desabilitá-los apagando seu conteúdo, ou ainda hospedar e espalhar vírus, malwares e spywares alterando conteúdos legítimos e fazendo com que usuários acessem material malicioso sem que saibam disso, em hipóteses mais sérias pode ocorrer o roubo de informações de cartões de crédito, senhas e outros.

No início de 2009 um hacker romeno utilizou vulnerabilidades de SQL Injections para hackear e ganhar acesso a diversos dados em grandes empresas de Antivirus, por exemplo, o caso da Kaspersky, Bit Defender e F-Secure.

Basicamente a falha de SQL Injection acontece quando uma determinada variável tratada dentro da aplicação não manipula de forma correta os valores que são inseridos dentro dela, passando estes dados diretamente para uma Query SQL e executando logo em seguida.

Os tipos mais conhecidos de ataques em SQL Injections são:

– Filtragem incorreta em caracteres de escape
– Gerenciamento de Tipos de dados incorretos