xsrf - cross site request forguery

Discussão em 'Dicas e tutoriais' iniciado por kodo no kami, 11 Julho 2017.

  1. kodo no kami
    Offline

    kodo no kami Membro Conhecido

    Afiliado:
    16 Dezembro 2015
    Mensagens:
    234
    Sexo:
    Masculino
    Avaliações:
    +312 / -0
    e ae galera blz? a pedido do mano v4p0r vou esta escrevendo esse artigo sobre a exploração do xsrf (cross site request forgery), tambem vou esta mostrando como sanar essa vulnerabilidade lembrando que meu foco é sempre a segurança da info e a programação e não o ataque em si (menos quando estou bebado, ai nasce o kodo maligno da peste '-' kkkk ~ so que nao), para evitar problemas em mostrar tal vulnerabilidade em cms reais mesmo isso sendo exemplos, vou esta usando um sistema que eu mesmo codei especifico para isso ao inves de utilizar um wp ou um joomla da vida, esse meu sisteminha é bem simples permite apenas criar postagem e deletar elas (voce pode baixar e brincar com ele ai tambem bastando colocar ele em um servidor web local como o xampp, lembrando de colocar tambem os comandos no mysql do arquivo banco.sql e configurar o usuario dele em config.php)

    baixar kovuln

    [​IMG]

    no sistema temos um botão adm que permite logar como admin (usuario padrao é kodo, senha 123456)

    [​IMG]

    depois de logado temos acesso como admin permitido criar nova postagem ou deletar elas como nos outros cms desse tipo (blogs, foruns e sites)

    [​IMG]

    agora que a gente ja conhece o sistema ja estamos a um passo para explorar o xsrf nele, normalmente esse tipo vulnerabidade so pode ser explorado se voce conhece o sistema principalmente o codigo fonte, diferente do xss que voce injeta um script no formulario para saber se esta ou não vulneravel, o xsrf muitas vezes voce precisa ver as passagens de metodos daquele formulario para saber se esta ou não vulneravel (seja ele get ou post), sendo esse um dos motivos que é necessario voce saber como o sistema funciona quais são os metodos passados. no codigo fonte no navegador vemos que o botão que apaga a mensagem tem o evento onclick que chama uma função em javascript chamado deletar, nessa função é passado um numero para ele, como cada mensagem tem um botão deletar e cada chamada da função tem um numero diferente para cada botão podemos deduzir que é passado o ID (se a gente tiver o acesso ao codigo fonte do php podemos confirmar isso)

    [​IMG]

    se a gente der uma olhada na função deletar do javascript pelo codigo fonte no navegador (inspecionar elemento ou firebug), vamos perceber que nesse caso ele redirecionara para propria pagina php passando como metodo a palavra "deletar=" seguido da variavel n que seria o valor que passamos na chamada da função, ou seja quando apertamos o botão apagar ele chama a função deletar e passa para ela o id da mensagem que sera deletada e redireciona para o script php passando o argumento que sera apagado

    [​IMG]

    então podemos tanto apertar o botão quanto ir direto naquela url que vai funcionar da mesma forma sera apagado o id 3

    Código (Forge Crash):
    http://192.168.1.1/kodo/kovuln/index.php?deletar=3
    [​IMG]

    se a gente desconectar como admin e olhar o codigo fonte vamos perceber que não existe o javascript ou o botão de apagar

    [​IMG]

    porem ainda sim é possivel apagar o post pelo url apenas manipulado o metodo get/post sem mesmo precisar esta logado no sistema (essa tambem seria uma vulnerabilidade não necessarimente um xsrf), porem para gente saber que é o parametro delelar precisamos ter acesso ao sistema como admin ou ter o codigo fonte do cms (por isso é muito comun achar essa vulnerabilidade em cms abertos onde é possivel baixar eles para estudar o seu funcionamento do que em sites fechados)

    Código (Forge Crash):
    http://192.168.1.1/kodo/kovuln/index.php?deletar=1
    [​IMG]

    no exemplo anterior podemos por exemplo criar um exploit em qualquer linguagem para fazer essa requisição (voce poderia criar um formulario em html em outro site tambem e apontar o action para ele), veja um exemplo em perl que permite a gente fazer a requisição para a postagem

    Código (Forge Crash):
    #!/usr/perl
    #xpl xsrf kovun

    use WWW::Mechanize;

    print "digite a url: ";
    my $kurl = <>;
    print "digite o titulo: ";
    my $ktitulo = <>;
    print "digite a postagem: ";
    my $kmsg = <>;
    chomp($kurl);
    chomp($ktitulo);
    chomp($kmsg);
    $kurl .= '?postar&titulo=' . $ktitulo . "&postagem=" . $kmsg;

    my $kodo = new WWW::Mechanize;
    $kodo->get($kurl);
    [​IMG]

    porem nem sempre sera possivel executar os comandos ou passar os parametros pela conta atual direto pelo atacante, pode ser que o programador foi inteligente limitando eles para apenas o admin ou usuario especifico é nesse momento que entra o ataque de xsrf, dependendo voce pode simplesmente usar um site externo e redirecionar a vitima para aquela determinada url usando engenharia social nela (olha nudes '-' ), voce pode fazer isso por javascript ou forçar um envio de formulario com metodo post usando javascript tambem ou ate mesmo o proprio html

    Código (Forge Crash):
    <script>document.location = "http://192.168.1.1/kodo/kovuln/index.php?deletar=2";</script>
    tambem podemos redirecionar em php usando o header location

    Código (Forge Crash):
    <?php
      header("location: http://192.168.1.1/kodo/kovuln/index.php?deletar=2");
    ?>
    em CGI com varias outras linguagens como perl

    Código (Forge Crash):
    #!/usr/bin/perl

    print "Content-type: text/html\n";
    print "Location: http://192.168.1.1/kodo/kovuln/index.php?deletar=2\n\n";
    print "<html><head></head><body></body></html>";
     
    tambem podemos fazer o proprio ataque direto em um iframe na propria pagina, nesse caso a vitima nem vai perceber o ataque ja que não vai ser redirecionada para o site ira apenas abrir um site dentro do outro sendo que o iframe pode esta oculto, se ela estiver logada no site então no proprio iframe ela tambem vai esta logada ou seja bastaria apontar o iframe para a url certa, voce poderia por exemplo usar funções com setInterval e carregar url especificas em sequencia assim executando paramentros um a pos o outro (isso tudo em background enquanto ela assiste algum filme na pagina)

    Código (Forge Crash):

    <iframe width=580 height=450 src="http://192.168.1.1/kodo/kovuln/index.php?deletar=2"></iframe>
     
    [​IMG]

    agora que a gente ja sabe como o ataque funciona vamos da uma rapida olhada em como evitar, uma das forma mais simples seria um token dinamico e passar ele junto no formulario (ou no metodo), com isso basta checar antes de fazer aquela ação no site, esse token deve ser gerado de forma bem dinamica, e deve ser um token diferente para cada usuario alem de expirar depois de um tempo, isso evitaria o atacante criar um formulario como o nosso iframe ja que não teria como ele saber qual o token gerado para o usuario (isso tambem vai restringir o nivel de acesso evitando aquele nosso script), outra forma de evitar o xsrf seria pedir uma confirmação antes de alguma ação, um exemplo seria determinada pergunta antes de deletar a mensagem "deseja realmente deletar essa mensagem?", outra forma seria olhar o cabeçalho do pacote http, normalmente quando voce redireciona de um servidor para outro ou usa o iframe é enviado junto com a requisiçao o parametro Referer com dominio ou IP da onde foi feita aquela requisição ou aquele redirecionamento, outra forma seria pelo proprio protocolo http sendo que ele permite um determinado parametro que bloqueia isso sendo esse parametro o X-Frame-Options

    kovuln_prot

    Código (Forge Crash):
    <?php
      header("X-Frame-Options: Deny");
    ?>
    <html>
    <head>
    ...
    [​IMG]

    bom galera existem N formas para explorar o xsrf inclusive em conjunto com outras vulnerabilidades como tambem existem muitas formas para se proteger dela, vou terminar esse artigo por aqui porem antes vou dizer que ainda tem duas vulnerabilidades nesse meu sisteminha que podem ser exporadas em conjunto com o xsrf, deixo elas para voces descobrir quais são e como explorar elas tambem (ps: o kodo tem fetiche por sacerdotisas e não por sacerdozias ~ nem a pau vou editar tudo isso kkkk)

    by kodo no kami
     
    • Informativo Informativo x 1
    Última edição: 11 Julho 2017
  2. EzequielDeMario
    Offline

    EzequielDeMario Membro Conhecido VIP Sabotador.com VIP Sabotador.com

    Afiliado:
    3 Dezembro 2012
    Mensagens:
    157
    Sexo:
    Masculino
    Avaliações:
    +102 / -0
    Apelido no Minecraft:
    NinjaOficial
    Muito bom, :grin: . Uma brecha de segurança extremamente retardada mas que acontece
     
    • Concordo Concordo x 1

Compartilhe esta Página