<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 .red {
 color: #e74c3c;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 Na programação web e para dispositivos móveis, a escolha do formato de arquivo de imagem é crucial para a eficiência do site e a qualidade de visualização das imagens. Vamos analisar os formatos mencionados nas alternativas para determinar quais são válidos para o uso em fotografias e imagens digitais.
 

 <ul>
 <li>
 A) BAT e SCR:
 INCORRETO. BAT é uma extensão associada a arquivos batch (ou lotes) que são scripts utilizados para automatizar ações em sistemas operacionais Windows. SCR representa um arquivo executável que geralmente contém um protetor de tela. Ambos, portanto, não estão associados a formatos de imagem.
 </li>
 
 <li>
 B) SCR e PNG:
 INCORRETO. Como mencionado, SCR não é um formato de imagem, mas sim um formato comumente usado para protetores de tela. PNG (Portable Network Graphics), por outro lado, é um formato de imagem popular que suporta compressão de dados sem perda e permite transparência, sendo amplamente utilizado para gráficos on-line devido à sua eficiência e suporte para cores detalhadas.
 </li>
 
 <li>
 C) PNG e JPG:
 CORRETO. PNG e JPG (ou JPEG, Joint Photographic Experts Group) são ambos amplamente reconhecidos como formatos de arquivo de imagem. JPG é especialmente popular para fotografias devido à sua capacidade de comprimir imagens de alta qualidade em tamanhos de arquivo menores, ainda que essa compressão ocasione perda de qualidade. PNG é preferido para gráficos e imagens com áreas de cores sólidas devido à sua compressão sem perda.
 </li>
 
 <li>
 D) JPG e BAT:
 INCORRETO. JPG, como discutido, é um formato de imagem adequado para fotografias. No entanto, BAT não se relaciona com formatos de imagem, sendo associado a arquivos de scripts em sistemas Windows.
 </li>
 
 </ul>
 

 Portanto, a alternativa correta é C.

</body>
</html>

 “covid-19”site:www.arantina.mg.gov.br

 “covid-19”sítio:www.arantina.mg.gov.br

 “covid-19” em www.arantina.mg.gov.br

 “covid-19”sítio#www.ar#ntina.mg.gov.br

 “covid-19”site#www.arantina.mg.gov.br

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 Na situação apresentada, um cidadão de Arantina – MG deseja buscar informações específicas sobre covid-19 diretamente no site da Prefeitura dessa cidade utilizando o Google Chrome. A compreensão do modo como os mecanismos de pesquisa interpretam os argumentos é crucial para a eficácia da pesquisa.
 

 O argumento de busca precisa ser formatado de uma maneira que otimize a filtragem de resultados exclusivamente para o site desejado e para a expressão exata. Portanto, o uso de operadores específicos do Google se faz necessário.
 
 
 Para tal, analisamos cada alternativa:
 
 
 <ul>
 <li>A) “covid-19” site:www.arantina.mg.gov.br
 Certa: Esta alternativa usa o operador site: seguido imediatamente pelo endereço exato do site (sem espaços), garantindo que a pesquisa seja realizada somente dentro deste domínio. As aspas duplas ("") ao redor da palavra covid-19 asseguram que o termo seja buscado exatamente como está, mantendo a ordem e a combinação dos termos.
 </li>
 
 <li>B) “covid-19” sítio:www.arantina.mg.gov.br
 Errada: A formatação sítio: não é reconhecida pelos mecanismos de pesquisa como um operador válido, portanto, essa busca não vai filtrar os resultados para o site especificado.
 </li>
 
 <li>C) “covid-19” em www.arantina.mg.gov.br
 Errada: Esta alternativa não utiliza nenhum operador de pesquisa reconhecido. O termo em não tem função de operador nos mecanismos de busca, resultando em uma pesquisa que não limita os resultados ao site especificado.
 </li>
 
 <li>D) “covid-19” sítio#www.ar#ntina.mg.gov.br
 Errada: Além do uso incorreto de um operador não existente (sítio#), o URL está incorretamente estruturado (com # que seria interpretado de outra forma), o que impediria que a busca fosse efetiva no domínio corretamente especificado.
 </li>
 
 <li>E) “covid-19” site#www.arantina.mg.gov.br
 Errada: O uso de # imediatamente após o operador site invalida a função do operador, pois os operadores devem ser seguidos diretamente pelo valor relevante sem espaços ou caracteres especiais interpelantes.
 </li>
 
 </ul>
 

 Portanto, a alternativa correta é A.
 

</body>
</html>

 a listagem de diretórios do servidor web seja desativada.

 os tokens JWT stateless sejam de longa duração.

 as sessões stateful sejam mantidas no servidor após o logout.

 evite reutilizar os mecanismos de controle de acesso.

 utilize APIs sem taxa limite de requisições.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 O tema da questão é "Broken Access Control", um problema significativo nas aplicações web. O conceito de "Broken Access Control" se refere a situações onde as restrições de acesso não são implementadas ou são inadequadamente administradas, possibilitando que usuários não autorizados acessem recursos de maneira indevida. A prevenção dessas falhas é crucial para a segurança das aplicações web.
 

 A Organização de Segurança em Aplicações Web, OWASP, fornece várias recomendações para mitigar esse risco. A questão aborda essas recomendações e pede que as identifiquemos.
 

 Veja, então, cada uma das alternativas apresentadas:
 
 
 <ul>
 <li>
 A) A listagem de diretórios do servidor web seja desativada:
 Permitir a listagem de diretórios é uma prática que pode expor arquivos e estruturas internas do servidor ao público, aumentando o risco de um ataque malicioso. Desabilitar essa listagem ajuda a proteger o sistema ao evitar que informações sensíveis sejam descobertas facilmente por atacantes. É uma medida recomendada para fortalecer o controle de acesso.
 </li>
 
 <li>
 B) Os tokens JWT stateless sejam de longa duração:
 Embora os tokens JWT (JSON Web Tokens) sejam comumente utilizados em autenticação e controle de acesso, recomendar que sejam "de longa duração" pode aumentar os riscos, principalmente se o token for comprometido. É preferível ter tokens de curta duração para minimizar potenciais danos em caso de roubo ou vazamento de um token.
 </li>
 
 <li>
 C) As sessões stateful sejam mantidas no servidor após o logout:
 Manter sessões no servidor mesmo após o usuário ter se deslogado é uma prática insegura. Isso pode permitir que sessões antigas sejam reutilizadas, possivelmente por um usuário não autorizado, caso essas informações sejam interceptadas.
 </li>
 
 <li>
 D) Evite reutilizar os mecanismos de controle de acesso:
 A reutilização de mecanismos de controle de acesso em contextos diferentes pode não ser apropriada se as exigências de segurança de cada contexto variarem. No entanto, a reutilização em si não é necessariamente uma prática insegura; depende da capacidade do mecanismo de se adaptar às necessidades específicas do ambiente onde está sendo aplicado.
 </li>
 
 <li>
 E) Utilize APIs sem taxa limite de requisições:
 Não implementar limites na taxa de requisições pode levar a abusos, como ataques de negação de serviço (DoS), que podem sobrecarregar a aplicação e afetar sua disponibilidade para usuários legítimos. Definir taxas limites é uma prática recomendada para proteger o sistema contra abusos.
 </li>
 </ul>
 
 
 Analisando as opções listadas, a única medida que efetivamente ajuda a prevenir falhas de controle de acesso por esconder a estrutura interna do servidor web e reduzir a superfície de ataque é a desativação da listagem de diretórios do servidor web.
 
 
 Portanto, a alternativa correta é A.
 

</body>
</html>

 uso de cabeçalho X-Csrf-Protection nas requisições GET.

uso do atributo httponly nos cookies utilizados.

uso de tokens anti-csrf pela aplicação.

garantia que os cookies não serão enviados em texto claro na rede.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 A vulnerabilidade CSRF (Cross-Site Request Forgery) é um tipo de ataque através do qual ações mal-intencionadas são enviadas de um usuário que o navegador confia para uma aplicação que não tem qualquer conotação de malícia nele. Isso geralmente acontece quando há uma sessão ativa e autenticada aberta em um tab e outro tab executa ações prejudiciais esperando que a sessão autenticada execute comandos sem o conhecimento do usuário.
 

 Vamos analisar cada uma das alternativas para entender os métodos eficazes e os não eficazes para a prevenção de CSRF:
 

 <ul>
 <li>A) Desativação do recurso HSTS.
 Incorreto porque o HSTS (HTTP Strict Transport Security) é uma política de segurança que protege os sites contra ataques como o downgrade de protocolo, mas não oferece proteção contra CSRF.
 </li>
 
 <li>B) Uso de cabeçalho X-Csrf-Protection nas requisições GET.
 Incorreto porque, primeiro, o cabeçalho X-Csrf-Protection não é um padrão reconhecido para a proteção contra CSRF. Segundo, as vulnerabilidades CSRF frequentemente visam solicitações de tipo estado-mutante como POST, PUT, DELETE, e não GET.
 </li>
 
 <li>C) Uso do atributo httponly nos cookies utilizados.
 Incorreto porque a marcação httponly em cookies impede que os scripts do lado do cliente acessem os dados dos cookies. Embora aumente a segurança, principalmente contra ataques de XSS (Cross-Site Scripting), não impede que CSRF utilize a sessão de usuário para enviar solicitações não autorizadas.
 </li>
 
 <li>D) Uso de tokens anti-csrf pela aplicação.
 Correto porque o uso de tokens anti-CSRF é uma medida eficaz de proteção. Esses tokens são valores únicos e secretos que são verificados em cada solicitação estado-mutante, garantindo que a solicitação veio do site legítimo e do próprio usuário. Isso impede que ações não autorizadas sejam submetidas mesmo se houver um cookie de sessão válido.
 </li>
 
 <li>E) Garantia que os cookies não serão enviados em texto claro na rede.
 Incorreto porque, apesar de a segurança do transporte de cookies ser importante, isso por si só não protege contra ataques CSRF, uma vez que a vulnerabilidade se focaliza no uso de sessões confiáveis para enviar comandos não autorizados.
 </li>
 
 </ul>
 
 
 Portanto, a alternativa correta é D.
 

</body>
</html>

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 Para responder corretamente essa questão, precisamos entender o conceito de Webhooks e como eles operam dentro do contexto de aplicações web.
 

 Webhooks são uma forma de notificações automáticas disparadas por eventos dentro de uma aplicação, enviando dados em tempo real para outras aplicações ou serviços. Eles são comumente utilizados para integrar diferentes sistemas ou para reagir a eventos sem necessidade de polling.
 
 
 Analisemos cada afirmativa conforme apresentada no enunciado:
 
 
 <ul>
 <li>( ) Não existe a necessidade de um endpoint para webhook poder funcionar.
 Esta afirmativa é falsa. Um endpoint é essencial para um webhook, pois é o URL para o qual as notificações são enviadas automaticamente sempre que o evento monitorado acontece. Sem um endpoint definido, a aplicação não tem um destino para enviar a informação.
 </li>
 
 <li>( ) Os dados recebidos em um webhook jamais podem ser no formato JSON.
 Esta afirmativa também é falsa. O formato JSON é amplamente utilizado em Webhooks devido à sua facilidade de uso e interoperabilidade entre diversas plataformas. JSON permite uma troca de dados estruturada e eficaz, sendo bastante comum em APIs e serviços web.
 </li>
 
 <li>( ) O webhook pode enviar notificações em tempo real em aplicações web.
 Verdadeira. Uma das principais vantagens dos webhooks é a capacidade de fornecer informações em tempo real. Isto é, quando um evento ocorre, o webhook dispara imediatamente a notificação para o endpoint configurado, permitindo que ações e reações ocorram imediatamente após os eventos.
 </li>
 
 </ul>
 
 
 Portanto, com base na análise feita, a sequência correta de respostas é Falso, Falso, Verdadeiro, correspondendo à assertiva:
 
 
 Portanto, a alternativa correta é D.
 

</body>
</html>

Questões de Tecnologia da Informação - Conceitos de Web Services - 2022