# Como funciona uma aplicação web ## Introdução Para detectarmos anomalias em aplicações web, precisamos primeiro saber como elas funcionam na prática. Aplicações web utilizam protocolos específicos para se comunicarem precisamente com outros ativos. No caso das aplicações web, elas utilizam o protocolo **Hypertext Transfer Protocol** (HTTP). Vamos ver, mais abaixo, como funciona o protocolo HTTP. ## Protocolo HTTP O protocolo HTTP atua na **sétima** camada do modelo OSI (**Aplicação**). Isso significa que protocolos como Ethernet, IP e SSL são utilizados antes do protocolo HTTP.

Modelo TCP/IP x Modelo OSI

A comunicação HTTP é estabelecida entre o servidor e o cliente da seguinte maneira: 1. Primeiro, o cliente solicita algum recurso específico do servidor 2. O servidor recebe a requisição HTTP e envia uma resposta (HTTP) ao cliente, após passar por alguns controles e processos 3. O dispositivo do cliente então recebe a resposta e mostra o recurso solicitado no formato apropriado

Requisição do cliente x resposta do servidor

Abaixo, veremos sobre requisições e respostas HTTP em maiores detalhes. ## Requisições HTTP Uma requisição HTTP é utilizada para obter algum recurso específico do servidor. Esse recurso pode ser um arquivo HTML, um vídeo, dados em *json* etc. O trabalho do servidor, nesse caso, é processar a requisição recebida e apresentar a resposta ao usuário. Existe um formato HTTP padrão que todas as requisições devem possuir, para que os servidores a compreendam corretamente. Se a requisição é enviada em um formato diferente, o servidor web não irá entender e responderá com uma mensagem de erro para o usuário, ou simplesmente não conseguirá entregar o serviço.

Exemplo de requisição HTTP

Uma requisição HTTP consiste de uma linha de requisição (*Request Line*), linhas de cabeçalho (*Request Headers*) e o corpo da mensagem *(Request Message Body*). A linha de requisição contém o método HTTP utilizado e o recurso solicitado ao servidor. Nas linhas de cabeçalho existem informações específicas de cabeçalho que o servidor irá processar. A linha de corpo da mensagem contém as informações a serem enviadas ao servidor. Examinando a requisição na imagem acima, temos as seguintes linhas: > * `GET` -> Método utilizado para solicitar o recurso `/` dentro do servidor. Uma solicitação sem nome como essa nos diz que a página principal do servidor web foi solicitada > * `Host` -> Hoje em dia, existem aplicações web que pertencem a mais de um domínio encontrado em um único servidor, então os navegadores web utilizam esse para descrever a qual domínio o recurso solicitado pertence > * `Cookie` -> Quando uma aplicação web precisa armazenar informações no dispositivo do cliente, ela utiliza o cabeçalho `Cookie` para tal. Cookies são, geralmente, utilizados para armazenar informações de sessão do usuário. Graças a esse cabeçalho, não precisamos digitar nossas credenciais a todo tempo quando visitamos uma aplicação que requer login > * `Upgrade-Insecure-Requests` -> Utilizado para informar que o cliente deseja realizar uma comunicação criptografada (SSL) > * `User-Agent` -> Nesse cabeçalho são passadas as informações sobre o navegador e sistema operacional utilizados pelo cliente. Os servidores utilizam essa informação para enviar respostas HTTP específicas para cada tipo de dispositivo. Existem, inclusive, scanners de vulnerabilidades que utilizam User-Agents específicos, justamente para sua fácil identificação > * `Accept` -> Cabeçalho que descreve o tipo de informação solicitada pelo cliente > * `Accept-Encoding` -> Descreve o tipo de codificação que o dispositivo do cliente compreende é passado no cabeçalho > * `Accept-Language` -> Nesse cabeçalho, temos as informações a respeito do idioma do cliente. O servidor web utiliza essa informação para entregar o conteúdo no idioma adequado ao cliente > * `Connection` -> Esse cabeçalho mostra como a conexão HTTP será realizada. Se a informação `close` estiver nesse cabeçalho, quer dizer que a conexão será fechada após a resposta do servidor ser recebida. Se a conexão for `Keep-Alive`, sigifica que a conexão será mantida > * Uma linha vazia é inserida entre os cabeçalhos da requisição e seu corpo, para que as informações sejam particionadas > * Após isso, entramos no **corpo** (`Body`) da requisição, onde são passadas as informações que o cliente deseja comunicar ao servidor. Se uma requisição utilizar o método `POST` por exemplo, então os parâmetros POST são passados nesse campo ## Respostas HTTP Uma vez que o servidor web recebe a requisição HTTP, ela executa os controles necessários, processa e envia o recurso solicitado ao cliente. Não existe um processo muito "uniforme" nessa parte, por conta das inúmeras e diferentes tecnologias e designs utilizados mundialmente. O servidor pode enviar dados a partir de um banco de acordo com o recurso solicitado, ou ela pode processar de acordo com os dados de entrada. Porém, a mensagem de resposta HTTP deve chegar ao cliente após todos os processos. Uma mensagem de resposta HTTP contém uma linha de status, cabeçalhos e corpo de resposta. A linha de status contém o código de status (como por exemplo, 200 (OK)) e informações a respeito do protocolo HTTP. Existem cabeçalhos utilizados para inúmeras finalidades dentro dos cabeçalhos de resposta. Informações sobre o recurso solicitado são localizadas no corpo da resposta.

Exemplo de resposta HTTP

Temos as seguintes informações a partir da requisição de exemplo acima: 1. `Status Line` -> Informações sobre a versão e código de status de resposta HTTP. O código de status HTTP representa o status da requisição. Existem inúmeros códigos de status de resposta HTTP, mas eles podem ser sumarizados em: 1. *100-199* -> Respostas informacionais 2. *200-299* -> Respostas de êxito 3. *300-399* -> Respostas de redirecionamento 4. *400-499* -> Respostas de erro do cliente 5. *500-599* -> Respostas de erro do servidor `Response Headers` -> Cabeçalhos comumente encontrados em respostas HTTP: 1. `Date` -> Data e hora exatos em que o servidor enviou a resposta ao cliente 2. `Connection` -> Como a conexão será manipulada, assim como no cabeçalho de requisição 3. `Server` -> Informações sobre o sistema operacional e versão do servidor 4. `Last-Modified` -> Última vez que o recurso solicitado foi modificado. Esse cabeçalho é utilizado em mecanismos de cache 5. `Content-Type` -> Tipo de informação enviada ao cliente 6. `Content-Length` -> Tamanho da informação enviada ao cliente `Response Body` -> No corpo da resposta contém a informação solicitada pelo cliente e, consequentemente, enviada pelo servidor.

Exemplo de resposta HTTP

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://2h4ck.gitbook.io/home/artigos/web/como-funciona-uma-aplicacao-web.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.