Unconfigured Ad Widget

Collapse

Anúncio

Collapse
No announcement yet.

Dica – executando testes de seguranÇa web (xss cross-site scripting) usando o fiddler

Collapse
X
 
  • Filter
  • Tempo
  • Show
Clear All
new posts

  • Font Size
    #1

    Dica Dica – executando testes de seguranÇa web (xss cross-site scripting) usando o fiddler

    [SIZE="3"]Eu encontrei esse post e me ajudou bastante espero ajudar vcs tbm /SIZE]
    Link do post original caso prefiram >>Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...

    Esse artigo, iremos demonstrar como executarmos testes não funcionais (segurança) usando a ferramenta FIDDLER e identificando possíveis locais em nosso aplicativo ou página Web (Web Page) que possui propensão a ataques XSS (Cross Site Scripting).

    Cross-site scripting (XSS) é um tipo de vulnerabilidade do sistema de segurança de um computador, encontrado normalmente em aplicações web que activam ataques maliciosos ao injectarem client-side script dentro das páginas web vistas por outros usuários. Um script de exploração de vulnerabilidade cross-site pode ser usado pelos atacantes para escapar aos controlos de acesso que usam a política de mesma origem.

    Através de um XSS, o cracker injeta códigos JavaScript em um campo texto de uma página já existente e este JavaScript é apresentado para outros usuários, porque persiste na página.

    Exemplo de ataque: Imaginem que o cracker insira, em um fórum de um website alvo de ataque, um texto que contenha um trecho de JavaScript. Este JavaScript poderia, por exemplo, simular a página de login do site, capturar os valores digitados e enviá-los a um site que os armazene. Quando o texto do fórum for apresentado a outros usuários, um site atacado pelo XSS exibirá o trecho de JavaScript digitado anteriormente nos browsers de todos os outros usuários, provocando a brecha de ataque.

    O invasor envia um script para o servidor:<script>malicious.js… = SYN onde o servidor recebe o script e interpreta uma nova página inserindo o código como resposta da requisição ao atacante = SYN/ACK.

    Por fim, o atacante recebe a resposta em seu browser = ACK

    Esse teste pode ser executado em conjunto com algum teste funcional, pois a ferramenta irá executar tentativas de inserção de códigos XSS conforme sua navegação, como login, preenchimento de informações, geraçao de relatórios, entre outras. Ou seja, é um teste que não consome muito tempo, pois deve ser feito de forma paralela e não a parte.

    – Requisitos

    Para executar esse testes você precisará:

    Ferramenta FIDDLER: O FIDDLER é uma ferramenta gratuita e pode ser baixada nesse link. Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...



    Plugin X5S: Plugin que você irá instalar no FIDDLER para executar os testes de XSS. Esse plugin está disponível no site CODEPLEX, Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...



    Para navegar na aplicação, pode usar o Navegador Padrão de sua aplicação. Para validar a inserção dos códigos XSS, depois de seus testes concluídos e a captura de dados feita, use o FIREFOX ou CHROME mesmo que sua aplicação não suporte, ou desative a proteção XSS que seu Internet Explorer possui, pois ele poderá bloquear seu

    – Instalação

    Instale o FIDDLER conforme os passos abaixo:







    Depois instale o PLUGIN XSS:









    – Configurando o FIDDLER para Testes XSS

    Feche todos os programas de seu computador e sites e abra o FIDDLER. Observe a ABA do X5S (XSS).



    Para configurar:

    No plugin X5S vá na aba Configuration;

    Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...

    Clique em Enable;

    em Preamble digite o nome do seu teste para depois gerar os relatórios, por exemplo TesteABCXSS;

    Habilite Enable Domain Name Targeting e digite o nome do dominio que será o alvo, assim ficará mais fácil a filtragem do FIDDLER;

    Selecione Auto-Injection Options e marque todas, assim cada página que você navegar durante seus testes;



    Agora vamos configurar quais tipos de códigos serão injetados em nossa página ou aplicação. Para isso, vá na aba Test Configuration.



    Selecione conforme sua necessidade os tipos de códigos XSS mais usados atualmente. Eu selecionei todos nesse Caso de Teste.



    – Realizando o Teste

    Depois de configurado, inicie sua navegação no site normalmente, executando seus testes funcionais.





    Depois de seu teste funcional realizado, valide os relatórios do seu teste não funcional de segurança e valide se foi identificado pontos de vulnerabilidades. Vá no FIDDLER e clique na aba RESULTS. Depois clique em HOTSPOT e identifique se há pontos possiveis de vulnerabilidades.







    No caso acima, nos locais que naveguei não foram identificados HOT SPOTS. Se tivesse sido indetificados, estariam conforme essa tela abaixo:



    Estando conforme a tela acima, você deve clicar em cima da possível falha de segurança, para identificar do lado esquerdo do FIDDLER, e na barra de status qual a URL em questão. No caso, usei uma aplicação minha de testes na minha URL de testes de segurança para demonstração.



    Porém, não significa que realmente está com XSS, mas que está aceitando a inserção do código na URL, porém o desenvolvedor pode ter tratado dentro do código ainda. E porque acontece isso?

    O desenvolvedor pode tratar diretamente na URL se desejar, porém existem aplicações que necessitam a inserção desses códigos especiais, como aplicações que recebem informações de sincronismo de dados com caracteres especiais, e se ele “barrar” na URL, seu produto perderá tal funcionalidade. Lembrem-se que Segurança vai na contra-mão de Usabilidade e também de facilidades de sua aplicação. Mas ele ainda sim, pode tratar os tipos de ataques mais conhecidos em seu código, porém periodicamente o testador deverá realizar tais testes, pois como não dá para simplesmente tratar na raiz, para atender as demandas, acabasse sendo necessário validar periodicamente tais itens. Mas não é díficil!

    Bom, continuando, depois do FIDDLER ter demonstrado possiveis locais de ataque, vamos validar realmente se esses locais aceitam. Para isso, use um dos caracteres abaixo + a URL propensa ao ataque e use seu navegador para simular.

    <script>alert(1)</script> or <script>alert(1)</script>

    “><script>alert(1)</script> or “><script>alert(1)</script>

    </style><script>alert(1)</script>


    “)</script><script>alert(1)</script>

    “><img src=”a” onerror=”prompt”>

    Exemplo:

    Selecione o HOT SPOT, olho na coluna a esquerda a URL que ficou sombreada e copio a mesma:





    Abro o bloco de notas e colo a URL e insiro o código XSS, conforme os modelos acima mencionados:

    http://tisafe.abc.com/Security/Login.aspx?ReturnUrl=%2f<script>alert(1)</script> or <script>alert(1)</script>

    E valido se aceita, caso sim, aparecerá um POPUP com meu código inserido, no caso “Alert(1).”

    Veja a tela de exemplo:



    O ideal é testar todos os códigos disponiveis acima.

    Lembrem-se que, o teste é para cada URL (não precisa repetir). E esse teste pode ser feito depois, se desejar, apenas salve os relatórios das informações que o FIDDLER coletou e se desejar, exporte a sessão também. Armazene em seu sistema de Testes, para futuras análises e comparações entre versões.



    Como Resolver?

    Depois de detectado os locais e confirmado as falhas, para resolver o desenvolvedor deverá:

    Apesar de várias ocorrências de XSS e das diferentes formas de exploração, impedir a própria vulnerabilidade é conceitualmente simples. O que a torna problemática na prática é a dificuldade de identificar todos os campos da aplicação onde há dados manipulados pelo usuário e que serão posteriormente exibidos em tela. A causa do XSS refletido e persistente é que estes dados são inseridos em respostas da aplicação sem validação. Para eliminar tais vulnerabilidades, o primeiro passo é identificar todas as instâncias dentro da aplicação em que os dados são colocados nas respostas das requisições. Uma vez identificados os locais destes dados, é necessário realizar os seguintes procedimentos:

    – Validação de Entrada

    Este é o momento em que a aplicação recebe os dados fornecidos pelo usuário, que podem ser apresentados em respostas futuras. É necessário que a aplicação realize uma validação dentro do contexto daquele conteúdo, tornando-o mais restrito possível, por exemplo:
    Limitando o tamanho do campo a ser inserido
    Definindo o conjunto de caracteres aceito pela aplicação
    Estabelecendo uma expressão regular para os dados

    Estas regras de validações variam de acordo com o campo e com o contexto da aplicação, por exemplo, nomes, endereços de e-mails, números de contas e cartões, ou seja, de acordo com o tipo de informação, espera-se um formato pré-determinado de conteúdo.

    – Validação da Saída

    Agora é a vez da aplicação copiar em suas respostas os dados que originados por algum usuário ou até mesmo por terceiros. Estes dados devem ser codificados em HTML para tratar potenciais caracteres maliciosos. Codificação em HTML é a técnica de substituir os caracteres literais pela sua entidade HTML correspondente. Isto garante que o navegador, browser, irá exibir, como saída, tais caracteres de forma segura, tratando-o como parte do documento HTML e não da sua estrutura. Alguns deste caracteres são:
    ” → &quot;
    ‘ → &apos;
    & → &amp;
    < → &lt;
    > → &gt;

    Os caracteres também podem ser representados por seu código correspondente na tabela ASCII:
    % → %
    * → *

    Há algumas funções que fazem a codificação automaticamente para o desenvolvedor:
    PHP htmlspecialchars(), htmlentities()
    ASP.NET Server.HTMLEncode()

    Para maiores informações, acesso o site do MSDN.

    Prevenindo XSS em aplicações .NET.

    Espero ter ajudado e até a próxima!

    Alan Carlos < créditos para
    besouro
    O caminho é longo...
    não se preocupe quando cansar você não chegou nem na metade do caminho...
    Similar Threads
X
Working...
X