Hypertext transfer protocol (HTTP) é o protocolo de comunicações usado para acessar a World Wide Web e por todos os aplicativos da web de hoje. É um protocolo simples que foi originalmente desenvolvido para a recuperação de recursos estáticos baseado em texto. Desde então, foi ampliado e alavancado em várias maneiras para apoiar as complexas aplicações distribuídas que são agora comuns.

HTTP usa um modelo baseado na mensagem em que um cliente envia uma mensagem de solicitação e o servidor retorna uma mensagem de resposta. O protocolo é essencialmente sem conexão (connectionless): embora HTTP usa o protocolo TCP stateful como o seu mecanismo de transporte, cada troca de solicitação e resposta é uma transação autônoma e pode usar uma conexão TCP diferente.

Solicitações HTTP

Todas as mensagens HTTP (solicitações e respostas) consistem em um ou mais cabeçalhos, cada um em uma linha separada, seguido por uma linha em branco obrigatória, seguido de um corpo da mensagem opcional. Uma solicitação HTTP típica é a seguinte:

GET /auth/488/YourDetails.ashx?uid=129 HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml,
image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwaveflash,
*/*
Referer: https://mdsec.net/auth/488/Home.ashx
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64;
Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR
3.0.30729; .NET4.0C; InfoPath.3; .NET4.0E; FDM; .NET CLR 1.1.4322)
Accept-Encoding: gzip, deflate
Host: mdsec.net
Connection: Keep-Alive
Cookie: SessionId=5B70C71F3FD4968935CDB6682E545476

A primeira linha de cada solicitação HTTP é composto por três itens, separados por espaços:

• Um verbo que indica o método HTTP. O método mais usado é GET, cuja função é recuperar um recurso do servidor web. Solicitações GET não tem um corpo de mensagem, então, nenhum dado vem após a linha em branco depois das mensagens do cabeçalho;
  
• A URL solicitada. A URL geralmente funciona como um nome para o recurso sendo solicitado, juntamente com uma string de consulta opcional que contém os parâmetros que o cliente está passando para aquele recurso. A string de consulta é indicada pelo caractere ? na URL. O exemplo contém um único parâmetro com nome de uid e o valor 129.
• A versão HTTP sendo utilizada. As únicas versões HTTP de uso comum na Internet são 1.0 e 1.1, e a maioria dos navegadores usam a versão 1.1 por padrão. Existem algumas diferenças entre as especificações destas
  duas versões; no entanto, a única diferença é provável que você encontrar ao atacar aplicações web é que na versão 1.1 a solicitação do cabeçalho Host é obrigatória.

Vejamos alguns outros pontos interessantes no exemplo dado:

• O cabeçalho Referer é usado para indicar a URL a partir do qual o pedido é originado (por exemplo, porque o usuário clicou em um link na página). Note-se que este cabeçalho foi digitado incorretamente no caderno de especificações originais HTTP, e a versão com erro ortográfico foi mantido desde então.
• O cabeçalho User-Agent é usado para fornecer informações sobre o navegador ou outro software cliente que gerou o pedido. Note-se que a maioria dos navegadores inclui o prefixo Mozilla por razões históricas. Esta foi a string User-Agent usado pelo navegador Netscape originalmente dominante, e outros navegadores queria afirmar aos sites que eles eram compatíveis com este padrão. Tal como acontece com muitas peculiaridades da história da computação, ele tornou-se tão estabelecido que ainda é mantida, mesmo com a versão atual do Internet Explorer, o que fez o pedido apresentado no exemplo;
• O cabeçalho Host especifica o nome do host que aparece na URL completa sendo acessada. Isso é necessário quando vários sites estão hospedados no mesmo servidor, porque a URL enviada na primeira linha do pedido geralmente não contém um nome de host.
• O Cookie é usado para enviar parâmetros adicionais que o servidor emitiu para o cliente.

Respostas HTTP

Uma resposta HTTP típica seria assim:

HTTP/1.1 200 OK
Date: Tue, 19 Apr 2011 09:23:32 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc
X-AspNet-Version: 2.0.50727
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1067
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”><html xmlns=”http://
www.w3.org/1999/xhtml” ><head><title>Your details</title>
...

A primeira linha de toda resposta HTTP consiste em três itens, separados por espaços:

• A versão do HTTP sendo utilizada;
• Um código de status numérico que indica o resultado do pedido. 200 é a mais código de status comum; isso significa que a solicitação foi bem sucedida e que o recurso solicitado está sendo devolvido.
• Uma frase textual, descrevendo ainda mais o status da resposta. Este pode ter qualquer valor e não é usado para qualquer finalidade por navegadores atuais.

Vejamos outros pontos interessantes nesta resposta:

• O cabeçalho Server contém um banner que indica o software de servidor web sendo utilizado, e às vezes outros detalhes como módulos instalados e o sistema operacional do servidor. As informações contidas podem ou não
  ser preciso.
• O cabeçalho Set-Cookie emite ao navegador mais um cookie; este é enviado de volta no cabeçalho da solicitação do Cookie posteriores a este servidor.
• O cabeçalho Pragma instrui o navegador para não armazenar a resposta em seu cache. O cabeçalho Expire indica que o conteúdo da resposta expirou no passado e, portanto, não deve ser armazenado em cache. Estas instruções são frequentemente emitida quando o conteúdo dinâmico está sendo devolvido para garantir que os navegadores obter uma nova versão deste conteúdo em ocasiões futuras.
• Quase todas as respostas HTTP contêm um corpo de mensagem de uma linha em branco após os cabeçalhos. O cabeçalho Content-Type indica que o corpo desta mensagem contém um documento HTML.
• O cabeçalho Content-Length indica o comprimento do corpo da mensagem em bytes.

Métodos HTTP

Quando você está atacando aplicações web, você estará lidando quase que exclusivamente com os métodos mais comumente usados: GET e POST. Você precisa estar ciente de algumas diferenças importantes entre estes métodos, uma vez que pode afetar a segurança da aplicação, se negligenciado.

Método GET

O método GET é projetado para recuperar os recursos. Ele pode ser usado para enviar parâmetros para o recurso solicitado na string da URL. Isto permite aos usuários guardar uma URL de recurso dinâmica para que possam reutilizar depois ou outros usuários podem obter o recurso equivalente numa ocasião posterior (como numa consulta de pesquisa guardada nos favoritos). URLs são exibidas na tela e são logados em vários locais, tais como o histórico do navegador e os logs de acesso do servidor web. Eles são também transmitidos no cabeçalho Referer para outros locais quando links externos são seguidos. Por estas razões, a string de consulta não deve ser usada para transmitir informações sensíveis.

Ao consultar por Maceió no Google, podemos ver que o parâmetro q está passando o valor que digitei Maceió

https://www.google.com.br/search?&q=Maceió

Método POST

O método POST é projetado para executar ações. Com este método, os parâmetros de solicitação podem ser enviados tanto na string de consulta URL e no corpo da mensagem. Embora o URL ainda possa ser armazenada, todos os parâmetros enviados no corpo da mensagem serão excluídos ao ser guardado nos favoritos. Estes parâmetros também serão excluídos dos vários locais em que as URLs são armazenadas e do cabeçalho Referer. Porque o método POST é projetado para executar as ações, se um usuário clicar o botão Voltar do navegador para retornar a uma página que foi acessado usando este método, o navegador não reeditar automaticamente o pedido. Em vez disso, ele avisa o usuário de que ele está prestes a fazer, como mostrado abaixo na imagem. Isso impede que os usuários inadvertidamente executar uma ação mais de uma vez. Por esta razão, as solicitações POST deve ser sempre usado quando uma ação está sendo executada.

Para comprovar isto, visite o site http://www.w3schools.com/php/demo_form_post.php e preencha o formulário. Após enviar, tente atualizar a página e você será alertado sobre reenviar as informações.

Além dos métodos GET e POST, o protocolo HTTP suporta outros métodos que têm sido criadas para fins específicos. Aqui estão os outros que são mais mais conhecidos:

• HEAD funciona da mesma forma como uma solicitação GET, exceto que o servidor não deve retornar um corpo de mensagem em sua resposta. O servidor deve retornar os mesmos cabeçalhos que teria devolvido ao GET correspondente que foi solicitado. Assim, este método pode ser usado para verificar se um recurso é presente antes de fazer um pedido GET para ele. Serve quando você está mais interessado em saber o código de resposta e os cabeçalhos HTTP, e não no documento em si.
• TRACE é projetado para fins de diagnóstico. O servidor deve retornar na corpo de resposta exatamente o conteúdo da mensagem de pedido que ele recebeu. Isto pode ser usado para detectar o efeito de algum servidor de proxy entre o cliente e o servidor que possa estar manipulando o pedido.
• OPTIONS pede ao servidor para relatar os métodos HTTP que estão disponíveis para um recurso em particular. O servidor normalmente retorna uma resposta contendo um cabeçalho Allow que lista os métodos disponíveis.
• PUT tenta fazer upload de um recurso específico para o servidor, usando o conteúdo contido no corpo do pedido. Se este método estiver ativo, você pode ser capaz de aproveitá-lo para atacar o aplicativo, por exemplo, fazendo upload de um script arbitrário e executá-lo no servidor.

Existem outros métodos HTTP, mas que não são relevantes para ataques de aplicações web. Entretanto, um servidor web pode se expor para ataque se um método específico perigoso esteja ativo. Veremos estes exemplos em outra postagem.

URLs

Uma Uniform Resource Locator (URL) é um identificador único para um recurso da Web através do qual aquele recurso pode ser recuperado. O formato da maior parte das URLs é a seguinte:

protocolo://hostname[:porta]/[caminho/]arquivo[?param=valor]

Vários componentes deste sistema são opcionais. O número da porta é normalmente incluídos somente se ele for diferente do padrão utilizado pelo protocolo em questão. A URL usada para gerar o pedido de HTTP mostrada anteriormente é a seguinte:

https://mdsec.net/auth/488/YourDetails.ashx?uid=129

Além desta forma absoluta, URLs podem ser especificadas para um host em particular ou relativo a um determinado caminho naquele host. Por exemplo:

/auth/488/YourDetails.ashx?uid=129
YourDetails.ashx?uid=129

Estas formas relativas são frequentemente utilizadas em páginas da web para descrever a navegação dentro do site ou aplicação em si.

Representational State Transfer (REST) é um estilo de arquitetura para sistemas distribuídos em que solicitações e respostas contêm representações do estado atual dos recursos do sistema. As principais tecnologias empregadas na World Wide Web, incluindo o protocolo HTTP e o formato de URLs, estão de acordo com o estilo arquitetônico REST.

Embora as URLs que contenham parâmetros dentro da string de consulta que eles mesmos estão em conformidade com as restrições REST, o termo “URL estilo REST” é muitas vezes usado para significar uma URL que contém os parâmetros dentro do caminho do arquivo da URL, ao invés da string de consulta. Por exemplo, a URL seguinte contendo uma string de consulta:

http://www.aplicacaowebfalsa.com.br/busca?marca=fiat&modelo=uno

Corresponde ao estilo de URL contendo os parâmetros “estilo REST”:

http://www.aplicacaowebfalsa.com.br/busca?marca=fiat&modelo=uno

Cabeçalhos HTTP

HTTP suporta um grande número de cabeçalhos, alguns dos quais são implementados para fins específicos e incomuns. Alguns cabeçalhos podem ser usados para ambos os pedidos e respostas, e os outros são especificos a um destes tipos de mensagens. Veremos abaixo os cabeçalhos que são possíveis de encontrar quando for atacar aplicações web.

Cabeçalhos gerais

• Connection diz para a outra ponta da comunicação se deve fechar a conexão TCP depois da transmissão HTTP for completada ou manter ela aberta para mensagens futuras.
• Content-Encoding especifica que tipo de codificação está sendo usada para o conteúdo do corpo da mensagem, como gzip, o qual é usada por algumas aplicações para comprimir as respostas para uma transmissão mais rápida.
• Content-Length especifica o tamanho do corpo da mensagem, em bytes (exceto nos casos de respostas para as solicitações HEAD, quando indica o tamanho do corpo na resposta para a solicitação GET correspondente).
• Content-Type especifica o tipo de conteúdo do corpo da mensagem, como text/html para documentos HTML.
• Transfer-Encoding especifica algum tipo de codificação que foi realizada no corpo da mensagem para facilitar sua transferência sobre o HTTP.

Cabeçalhos de solicitações

• Accept informa ao servidor que tipo de conteúdo o cliente estará aceitando, como tipos de imagens, formatos de documento office, e assim por diante.
• Accept-Encoding diz ao servidor que tipo de codificação do conteúdo o cliente estará aceitando.
• Authorization envia as credenciais ao servidor para um tipo embutido de autenticação HTTP.
• Cookie envia os cookies para o servidor, o qual o próprio servidor enviou anteriormente.
• Host especifica o hostname que apareceu na URL completa solicitada.
• If-Modified-Since especifica quando o navegador recebeu pela última vez uma solicitação do recurso. Se o recurso não foi modificado desde então, o servidor pode instruir o cliente a usar a cópia armazenada em seu cache, usando uma resposta com o código de status 304.
• If-None-Match especifica uma tag de entidade, o qual é um identificador que denota o conteúdo do corpo da mensagem. O navegador envia a tag da entidade que o servidor enviou ao recurso solicitado quando isto foi enviado pela última vez. O servidor pode usar uma tag de entidade para determinar se o navegador pode usar sua cópia de cache do recurso.
• Origin é usado em solicitações Ajax cross-domain para indicar o domínio do qual a solicitação foi originada.
• Referer especifica a URL do qual a solicitação atual foi originada.
• User-Agent provê informação sobre o navegador ou outro software cliente que originou a solicitação.

Cabeçalhos de respostas

• Access-Control-Allow-Origin indica quando o recurso pode ser obtido através de solicitações Ajax cross-domain.
• Cache-Control passa as diretivas de cache para o navegador (por exemplo, no-cache).
• ETag especifica uma tag da entidade. Clientes podem enviar este identificador nas solicitações futuras para o mesmo recurso no cabeçalho If-None-Match para notificar o servidor qual versão do recurso do navegador atualmente tem em seu cache.
• Expires diz ao navegador por quanto tempo o conteúdo do corpo da mensagem são válidos. O navegador pode usar uma cópia em cache deste recurso até este momento.
• Location é usado em redirecionamentos de respostas (aqueles que tem o código de status iniciando com 3) para especificar o alvo do redirecionamento.
• Pragma passa as diretivas de caching para o navegador (por exemplo, no-cache).
• Server provê informação sobre o software do servidor web está sendo usado.
• Set-Cookie emite os cookies para o navegador que será enviado de volta para o servidor em solicitações subsequentes.
• WWW-Authenticate é usado em respostas que tem o código de status 401 para prover detalhes nos tipos de autenticação que o servidor suporta.
• X-Frame-Options indica qual e como a resposta atual pode ser carregada dentro do frame do navegador.

Cookies

Os cookies são uma parte fundamental do protocolo HTTP que a maioria das aplicações web dependem. Frequentemente pode ser usado como um meio para a exploração de vulnerabilidades. O mecanismo de cookie permite que o servidor enviar dados para o cliente, o qual o cliente armazena e reenvia para o servidor. Ao contrário dos outros tipos parâmetros de solicitaçõess (aqueles dentro da string de consulta URL ou no corpo da mensagem), cookies continuam a ser reenviados em cada pedido subsequente sem qualquer ação especial solicitada pelo aplicativo ou o usuário.

Um servidor emite um cookie usando o cabeçalho de resposta Set-Cookie, como você pode ser visto:

Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

O navegador do usuário então automaticamente adicionar o cabeçalho seguinte nas solicitações subsequentes de volta para o mesmo servidor:

Cookie: tracking=tI8rk7joMx44S2Uu85nSW

Cookies normalmente consistem de um par de nome/valor, como mostrado, mas podem consistir de qualquer string que não contenha um espaço. Vários cookies podem ser emitidos usando vários cabeçalhos Set-Cookie na resposta do servidor. Estes são submetidos de volta para o servidor no mesmo cabeçalho Cookie, com um ponto e vírgula separando diferentes cookies.

Além do valor real do cookie, o cabeçalho Set-Cookie pode incluir qualquer um dos seguintes atributos opcionais, que podem ser utilizados para controlar a forma como o navegador lida com o cookie:

• expires define uma a data de validade para o cookie. Isto faz com que o navegador salve o cookie para armazenamento persistente, e é reutilizado nas sessões subsequentes do navegador até a data de vencimento ser atingida. Se este atributo não for definido, o cookie é utilizado apenas na sessão atual do navegador.
• domain especifica o domínio para o qual o cookie é válido. Este deve ser o mesmo ou um pai do domínio a partir do qual o cookie é recebido.
• path especifica o caminho URL para o qual o cookie é válido.
• secure – Se este atributo for definido, o cookie será apresentado apenas em solicitações HTTPS.
• HttpOnly – Se esse atributo for definido, o cookie não pode ser acessado diretamente através de JavaScript do lado cliente.

Cada um destes atributos de cookies pode afetar a segurança do aplicativo. O impacto principal é sobre a capacidade do atacante de alvejar diretamente os outros utilizadores da aplicação.

Código dos Status HTTP

Cada mensagem de resposta HTTP deve conter um código de status em sua linha primeiro, indicando o resultado do pedido. Os códigos de status caem em cinco grupos, de acordo com o primeiro dígito do código:

• 1xx — Informacional.
• 2xx — Solicitação feita com sucesso.
• 3xx — O cliente é redirecionado para um recurso diferente.
• 4xx — A solicitação contêm um erro de algum tipo.
• 5xx — O servidor encontrou um erro ao realizar a consulta.

Existem numerosos códigos de status específicos, muitos dos quais são utilizados apenas em situações especiais. Aqui estão os códigos de status que são mais suscetíveis de encontrar ao atacar uma aplicação web, junto com a frase habitualmente associado a eles:

• 100 Continue – É enviado em algumas circunstâncias, quando um cliente envia uma solicitação contendo um corpo. A resposta indica que os cabeçalhos de solicitação foram recebidos e que o cliente deve continuar a enviar o corpo. O servidor retorna uma segunda resposta quando a solicitação foi concluída.
• 200 OK – Indica que a solicitação foi bem sucedida e que a resposta do corpo contém o resultado do pedido.
• 201 Created – É devolvido em resposta a uma solicitação PUT para indicar que o solicitação foi bem-sucedida.
• 301 Moved Permanently –  Redireciona o navegador de forma permanente para uma URL diferente, que é especificada no cabeçalho Location. O cliente deve usar a nova URL no futuro, em vez do original.
• 302 Found – Redireciona o navegador temporariamente para uma URL diferente, que é especificada no cabeçalho Location. O cliente deve reverter para a URL original nas solicitações subseqüentes.
• 304 Not Modified – Instrui o navegador a usar a sua cópia em cache do recurso solicitado. O servidor usa os cabeçalhos da solicitação If-Modified-Since e If-None-Match para determinar se o cliente tem a versão mais recente do recurso.
• 400 Bad Request – Indica que o cliente apresentou uma solicitação HTTP inválida. Você provavelmente vai encontrar isso quando você tem modificar um pedido de certa maneira inválida, como pela colocação de um caractere de espaço na URL.
• 401 Unauthorized – Indica que o servidor requer autenticação HTTP antes do pedido ser atendido. O cabeçalho WWW-Authenticate contém detalhes sobre o tipo(s) de autenticação suportado.
• 403 Forbidden – Indica que ninguém está autorizado para acessar o recurso solicitado, independentemente de autenticação.
• 404 Not Found – Indica que o recurso solicitado não existe.
• 405 Method Not Allowed – Indica que o método utilizado no pedido é suportado para a URL especificado. Por exemplo, poderá receber esta código de status se você tentar usar o método PUT onde não é suportado.
• 413 Request Entity Too Large – Se você está buscando por vulnerabilidades de buffer overflow no código nativo, e, portanto, está enviando string de dados longas, isso indica que o corpo de seu pedido é muito grande para o
  servidor manusear.
• 414 Request URI Too Long – É semelhante à resposta 413. Ela indica que a URL utilizadas no pedido é muito grande para o servidor de manusear.
• 500 Internal Server Error – Indica que o servidor encontrou um erro ao tentar cumprir com a solicitação. Isso normalmente ocorre quando você apresenta um input inesperado que causou um erro não tratado em algum lugar dentro do processamento da aplicação. Você deve analisar cuidadosamente o conteúdo completo
  da resposta do servidor para quaisquer detalhes indicando a natureza do erro.
• 503 Service Unavailable – Normalmente indica que, embora o servidor we está funcionando e pode responder às solicitações, o aplicativo acessada através do servidor não está respondendo. Você deve verificar se este é o resultado de qualquer ação que você executou.

HTTPS

O protocolo HTTP usa TCP simples como seu mecanismo de transporte, que é criptografado e, portanto, pode ser interceptado por um atacante que esteja adequadamente posicionado na rede. HTTPS é, essencialmente, o mesmo protocolo da camada de aplicação como HTTP, mas é encapsulado sobre o mecanismo de transporte seguro, Secure Sockets Layer (SSL). Isso protege a privacidade e integridade dos dados que passa sobre a rede, reduzindo as possibilidades de ataques de interceptação não-invasivas. Solicitações e respostas HTTP funcionam exatamente da mesma maneira, independentemente de SSL estar sendo usado para o transporte.

Observação: SSL tem sido estritamente substituída por Transport Layer Security (TLS), mas ultimamente ainda é referido utilizando o nome antigo.

HTTP Proxies

Um proxy HTTP é um servidor que faz o intermédio do acesso entre o navegador do cliente e o servidor Web de destino. Quando um navegador estiver configurado para usar um servidor proxy, ele fará solicitações para este servidor. O proxy retransmite as solicitações para os servidores web relevantes e encaminha suas respostas de volta para o navegador. A maioria dos proxies também oferecem serviços adicionais, incluindo cache, autenticação e controle de acesso.

Você deve estar ciente de duas diferenças na forma como HTTP funciona quando um servidor proxy está sendo usado:

• Quando um navegador emite uma solicitação não criptografada para um servidor proxy, ele coloca a URL completa dentro da solicitação, incluindo o prefixo do protocolo http://, o hostname do servidor e o número da porta, e usa isto para direcionar as solicitações para o destino correto no servidor web.
• Quando o HTTPS está sendo usado, o navegador não pode realizar o handshake SSL com o servidor proxy, porque isto iria quebrar o túnel de segurança e deixar a comunicação vulnerável para ataques de interceptação. Consequentemente, o navegador deve usar o proxy como um relay a nível TCP puro, o qual passa todos os dados da rede em ambas as direções entre o navegador e o servidor web de destino, com o qual o navegador faz um handshake SSL normalmente. Para estabelecer este relay, o navegador faz uma solicitação HTTP para o servidor proxy usando o método CONNECT e especifica o hostname de destino e o número da porta como URL. Se o proxy permite a solicitação, ele retornará uma resposta HTTP com o código de status 200, mantendo a conexão TCP aberta, e a partir daí atuar como um relay a nível TCP puro com servidor web de destino. Por alguma medida, o item mais útil em seu kit de ferramentas ao atacar aplicações web é um tipo especializado de servidor proxy que fica entre o navegador e o site de destino, que permitirá você interceptar e modificar todos os pedidos e respostas, mesmo aqueles usando HTTPS.

HTTP Authentication

O protocolo HTTP inclui seu próprio mecanismo para autenticação de usuários usando vários esquemas de autenticação, incluindo os seguintes:

• Basic é um mecanismo simples de autenticação que envia ao usuário as strings credenciais codificada com Base64 é um cabeçalho de solicitação com cada mensagem.
• NTLM é um mecanismo de desafio-resposta e usa uma versão do protocolo NTLM do Windows.
• Digest é um mecanismo de desafio-resposta e usa verificação MD5 das credenciais do usuário.

É relativamente raro encontrar estes protocolos de autenticação sendo usadas pelas aplicações web na internet. Eles são mais usadas comumente dentro das organizações para acessar serviços baseados em intranet.

Fonte: The Web Application Hacker’s Handbook – 2nd edition.

Mapa Mental