PplWare Mobile

Site do MySQL atacado via SQL Injection

                                    
                                

Este artigo tem mais de um ano


Autor: Pedro Pinto


  1. Bruno says:

    No php.ini basta colocar esta directiva magic_quotes_gpc = on, que aliás já vem por defeito. Ainda dizem que o php é pouco seguro…

  2. Arnaldo says:

    Ninguém está a salvo.

  3. Rik says:

    Sou só eu ou a imagem to topico faz um efeito esquisito na pagina inicial se andares para cima e para baixo

  4. anónimo says:

    O exemplo que está assim não me parece totalmente correcto, porque tendo esta query para consulta:

    SELECT user,passwd FROM users WHERE user = ‘$user’ AND passwd=’$passwd’;

    e ao introduzir como password => 123456;DROP TABLE users;

    ficaria assim SELECT user,passwd FROM users WHERE user = ‘pplware’ AND passwd=’123456;DROP table users;’;

    e não assim

    SELECT user,passwd FROM users WHERE user = ‘pplware’ AND passwd=’123456′;DROP table users;

    Acho eu, mas posso estar enganado, mas penso que o correcto é ficar tudo entre plicas e nesse caso já não se consegue SQLInjection, correcto?

  5. Gerardo says:

    Este problema é tão antigo será que é assim tão difícil de resolver?????

    Comentário de alguém, que percebe mesmo pouco de programação e BD’s…

    • roliveira says:

      É antigo, mas as vulnerabilidades de SQL injection e XSS estão mesmo assim no top de vulnerabilidades em aplicações web.

      Tens este estudo da OWSAP, para teres uma ideia.

      http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

      A culpa é mesmo quem desenvolve as aplicações, preocupado mais em funcionalidades que propriamente em pormenores de segurança das suas aplicações. Sem falar que há também muita falta de preparação para mitigar estas vulnerabilidades de algumas pessoas que programam.

    • rodasp says:

      Até pode ser fácil de resolver, o problema é a formação que nos dão (ensino fraco e antigo).

      Falo por mim, antigo aluno ensino profissional. Nunca tive aulas sobre segurança e os exercícios que tinha, maior parte, eram de caca… O que me preparou para o mercado foi o projecto final de curso e o estágio, que é uma coisa mais a sério…

      O resto se quis saber tive que estudar em livros (que não da escola) e na net…

  6. Fábio Rocha says:

    O engraçado aqui não é fazer Drop Tables, é conseguir o retorno de dados apresentado na página

  7. dwrcdII says:

    ninguem está a salvo, mas ha sempre a hipotese de dificultar as coisas e tornar um sistema de login mais seguro.

    Escapar os dados enviados para o mysql : mysql_real_escape_string(),
    e Validar os dados retornados pelo mysql com os dados inseridos pelo utilizador.

    Para não falar em limites de tentativas /tempo, origem do request (brute force)

    Não é mt dificil pois não?
    cumpz.

  8. Zé Tolas says:

    Sobre o ataque e as observações que leio limito-me a citar uma passagem bíblica “aquele que não tiver pecado que atire a primeira pedra”

    • Zé Tolas says:

      Estive a reler os comentários e aproveito para “traduzir” o meu. Há aqui comentários bastante parvos que indiciam que poderá haver quem não perceba a mensagem. Tradução: “aquele que nunca deixou um bug, e/ou muito menos buracos de segurança no seu código que avise, certamente será um caso de estudo e haverá empresas a contratarem-no por valores milionários”

      P.s.: Sr. readctor do artigo: Não me parece que o feitiço se tenha virado contra o feiticeiro. Seria verdade se eles (MySQL) alegassem ser impossível ataques de injecção de SQL e/ou eles próprios andassem por aí a promove-los. A primeira não é verdade, até porque qualquer motor de base de dados está sujeito a eles. É uma consequência das opções de design das API / SQL. A segunda também não. Uma possibilidade para combater estes problemas são os prepared statements como “jesus” mencionou no seu post aos leitores 🙂 (de qualquer forma podem haver implementações sujeitas a problemas também)

  9. Trambulhao says:

    Sinceramente, nem sei o que dizer.. invasão por SQLInjection num campo de “consulta de cliente”.. custa acreditar.

    Como é possível acontecer uma invasão tão simples num site de tal importância.

    Será que foi isso mesmo que aconteceu? A antiga equipe do MySQL não tem nada haver com essa história? Uma pequena vingança contra Oracle = Sun Microsystems?

    Muito estranho!

    • Fábio Rocha says:

      Simples? O exemplo citado no artigo é simples, no entanto há SQL injection de vários níveis.

      Eu não entraria em teorias de conspiração, parece-me mais que alguma team quis ganhar créditos no IRC, há quem faça destas habilidades só para ter reputação, e SQL injection no mysql.com é do melhor…

  10. Filipe Rodrigues says:

    lool para se fazer isso tem de ser ter a pass

  11. João Cardoso says:

    bem mais grave do que isto foi o que se passou com uma filial da Comodo que em Portugal nem se ouviu falar mas que pôs em causa toda a estrutura de como é feita autenticação na web

  12. lulwut says:

    Para os que estão espantados: a falha não foi explorada assim tão directamente como no exemplo apresentado. Até porque o exemplo apresentado de simples SQLi não tem quase nada a ver com o ataque de BLIND SQLi e XSS que foi realmente efectuado.

    • Kenny says:

      Ia mesmo dizer isso. 🙂

      Além disso, o exemplo apresentado não funcionaria, pois para fazer drop a uma tabela ela não pode estar a ser usada…

      Há ainda a técnica ‘or 1=1’.

      O impressionante mesmo foi o uso de Blind SQL Injection. Enfim, é como trancar a porta e abrir a janela. xD

      Este ataque já foi mais que dissecado por várias fontes, é só pesquisar. 🙂

      Abraço.

  13. Rogério says:

    Se permite XSS, nem quero imaginar o que estes h@ck3rs poderiam ter feito…

    Para além de terem drupado umas tabelas, só não fizeram mais porque não quiserem, ou porque não tiveram tempo para o fazer…

    Quando um site está vulnerável a XSS, as coisas podem ir bem mais além do que só apanhar dados em forms… Por norma o PHP tem protecções contra o XSS e SQLi, só deixam o site vulnerável a estas coisas só porque querem… se as seguranças existem, que as usem.

    Este ataque não foi feito de um dia para outro, quem fez isto já devia andar a sondar o site à muito tempo, e descobriu sítios por onde injectar javascript e SQL sem que dessem logo conta.

    Pode ser que com isto, muitos outros programadores pensem mais em seguranças do que só na apresentação do site e em funcionalidades.

    Não levem a sentido inverso do que queria dizer, eu sou contra o cibercrime e espero que sejam inovadas os meios de seguranças que existem de forma a combater o cibercrime.

    • pikax says:

      Programadores e web developers existem muitos, agora os que programam a ter em conta a segurança são muito poucos.

      Maior parte das empresas que desenvolvem sites, pensam so’ em:”Esta’ a funcionar, esta’ bom.”.

      Ja vi sites, em que se mudava o cookie de login, para ‘admin’ e tínhamos acesso de admin… nem uma verificação de pass fizeram, nem um hash, nada…

  14. José Fonseca says:

    É sempre bom alertar para este tipo de problemas que afectam a grande maioria das aplicações web. Todos os programadores devem estar alerta e ter muito cuidado com as entradas de dados na aplicações. Os dados de entrada devem ser sempre validados, os de saída também (para evitar XSS, por exemplo). Mas isso não é tudo, também não se deve esquecer a lógica do programa, por exemplo.

Deixe um comentário

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.