Teste de segurança - Guia rápido

O teste de segurança é muito importante para manter o sistema protegido de atividades maliciosas na web.

O que é teste de segurança?

O teste de segurança é uma técnica de teste para determinar se um sistema de informações protege os dados e mantém a funcionalidade conforme pretendido. O teste de segurança não garante a segurança completa do sistema, mas é importante incluir o teste de segurança como parte do processo de teste.

Os testes de segurança tomam as seguintes seis medidas para fornecer um ambiente seguro -

• Confidentiality - Protege contra a divulgação de informações a destinatários indesejados.

• Integrity - Permite a transferência de informações desejadas precisas e corretas dos remetentes para os destinatários pretendidos.

• Authentication - Verifica e confirma a identidade do usuário.

• Authorization - Especifica direitos de acesso aos usuários e recursos.

• Availability - Garante a prontidão das informações sobre o requisito.

• Non-repudiation - Garante que não haja recusa do remetente ou do destinatário por ter enviado ou recebido a mensagem.

Exemplo

Identificar uma falha de segurança em um aplicativo baseado na web envolve etapas complexas e pensamento criativo. Às vezes, um teste simples pode expor o risco de segurança mais grave. Você pode tentar este teste básico em qualquer aplicativo da web -

• Faça login no aplicativo da web usando credenciais válidas.

• Faça logout do aplicativo da web.

• Clique no botão VOLTAR do navegador.

• Verifique se você é solicitado a fazer login novamente ou se consegue voltar à página de login novamente.

Os testes de segurança podem ser vistos como um ataque controlado ao sistema, que revela falhas de segurança de forma realista. Seu objetivo é avaliar o estado atual de um sistema de TI. Também é conhecido comopenetration test ou mais popularmente como ethical hacking.

O teste de penetração é feito em fases e aqui neste capítulo, discutiremos o processo completo. A documentação adequada deve ser feita em cada fase para que todas as etapas necessárias para reproduzir o ataque estejam prontamente disponíveis. A documentação também serve como base para o relatório detalhado que os clientes recebem no final de um teste de penetração.

Teste de Penetração - Fluxo de Trabalho

O teste de penetração inclui quatro fases principais -

• Impressão do pé
• Scanning
• Enumeration
• Exploitation

Essas quatro etapas são reiteradas várias vezes, o que anda de mãos dadas com o SDLC normal.

Software malicioso (malware) é qualquer software que fornece controle parcial ou total do sistema para o criador do invasor / malware.

Malwares

Várias formas de malware estão listadas abaixo -

• Virus- Um vírus é um programa que cria cópias de si mesmo e insere essas cópias em outros programas de computador, arquivos de dados ou no setor de inicialização do disco rígido. Após a replicação bem-sucedida, os vírus causam atividades prejudiciais em hosts infectados, como roubar espaço no disco rígido ou tempo de CPU.

• Worm - Um worm é um tipo de malware que deixa uma cópia de si mesmo na memória de cada computador em seu caminho.

• Trojan - Trojan é um tipo de malware que não se auto-reproduz que contém código malicioso, que após a execução resulta em perda ou roubo de dados ou possível dano ao sistema.

• Adware- Adware, também conhecido como freeware ou pitchware, é um software de computador gratuito que contém anúncios comerciais de jogos, barras de ferramentas de desktop e utilitários. É um aplicativo baseado na web e coleta dados do navegador da web para direcionar anúncios, especialmente pop-ups.

• Spyware- Spyware é um software de infiltração que monitora anonimamente os usuários, permitindo que um hacker obtenha informações confidenciais do computador do usuário. O spyware explora vulnerabilidades de usuários e aplicativos, muitas vezes associadas a downloads de software online gratuitos ou a links clicados pelos usuários.

• Rootkit - Um rootkit é um software usado por um hacker para obter acesso de nível de administrador a um computador / rede que é instalado por meio de uma senha roubada ou pela exploração de uma vulnerabilidade do sistema sem o conhecimento da vítima.

Medidas preventivas

As seguintes medidas podem ser tomadas para evitar a presença de malware em um sistema -

• Certifique-se de que o sistema operacional e os aplicativos estejam atualizados com patches / atualizações.

• Nunca abra e-mails estranhos, especialmente aqueles com anexos.

• Quando você baixa da internet, sempre verifique o que você instalou. Não basta clicar em OK para descartar as janelas pop-up. Verifique o editor antes de instalar o aplicativo.

• Instale o software antivírus.

• Certifique-se de verificar e atualizar os programas antivírus regularmente.

• Instale o firewall.

• Sempre habilite e use os recursos de segurança fornecidos pelos navegadores e aplicativos.

Software Anti-Malware

O seguinte software ajuda a remover os malwares de um sistema -

• Microsoft Security Essentials
• Microsoft Windows Defender
• AVG Internet Security
• Spybot - Pesquisar e destruir
• Avast! Home Edition para uso pessoal
• Panda Internet Security
• MacScan para Mac OS e Mac OS X

Compreender o protocolo é muito importante para ter uma boa compreensão dos testes de segurança. Você poderá apreciar a importância do protocolo quando interceptamos os dados do pacote entre o servidor web e o cliente.

Protocolo HTTP

O Hypertext Transfer Protocol (HTTP) é um protocolo de nível de aplicativo para sistemas de informação hipermídia distribuídos e colaborativos. Esta é a base para a comunicação de dados para a World Wide Web desde 1990. HTTP é um protocolo genérico e sem estado que pode ser usado para outros fins, bem como usando a extensão de seus métodos de solicitação, códigos de erro e cabeçalhos.

Basicamente, o HTTP é um protocolo de comunicação baseado em TCP / IP, que é usado para entregar dados como arquivos HTML, arquivos de imagem, resultados de consultas, etc. pela web. Ele fornece uma maneira padronizada para os computadores se comunicarem entre si. A especificação HTTP especifica como os dados solicitados pelos clientes são enviados ao servidor e como os servidores respondem a essas solicitações.

Recursos básicos

Existem três recursos básicos a seguir que tornam o HTTP um protocolo simples, mas poderoso -

• HTTP is connectionless- O cliente HTTP, ou seja, o navegador inicia uma solicitação HTTP. Após fazer uma solicitação, o cliente se desconecta do servidor e aguarda uma resposta. O servidor processa a solicitação e restabelece a conexão com o cliente para enviar a resposta de volta.

• HTTP is media independent- Qualquer tipo de dado pode ser enviado por HTTP, desde que o cliente e o servidor saibam como lidar com o conteúdo dos dados. Isso é necessário para o cliente e também para o servidor especificar o tipo de conteúdo usando o tipo MIME apropriado.

• HTTP is stateless- HTTP é um protocolo sem conexão e isso é um resultado direto de que o HTTP é um protocolo sem estado. O servidor e o cliente estão cientes um do outro apenas durante uma solicitação atual. Depois, os dois se esquecem um do outro. Devido a essa natureza do protocolo, nem o cliente nem o navegador podem reter informações entre diferentes solicitações nas páginas da web.

HTTP / 1.0 usa uma nova conexão para cada troca de solicitação / resposta, enquanto a conexão HTTP / 1.1 pode ser usada para uma ou mais trocas de solicitação / resposta.

Arquitetura

O diagrama a seguir mostra uma arquitetura muito básica de um aplicativo da web e descreve onde o HTTP reside -

O protocolo HTTP é um protocolo de solicitação / resposta baseado na arquitetura cliente / servidor em que o navegador da web, robôs e mecanismos de pesquisa, etc. atuam como clientes HTTP e o servidor da web atua como servidor.

• Client - O cliente HTTP envia uma solicitação ao servidor na forma de um método de solicitação, URI e versão do protocolo, seguido por uma mensagem semelhante a MIME contendo modificadores de solicitação, informações do cliente e possível conteúdo do corpo por meio de uma conexão TCP / IP.

• Server - O servidor HTTP responde com uma linha de status, incluindo a versão do protocolo da mensagem e um código de sucesso ou erro, seguido por uma mensagem semelhante a MIME contendo informações do servidor, metainformações de entidade e possível conteúdo de corpo de entidade.

HTTP - Desvantagens

• HTTP não é um protocolo totalmente seguro.

• HTTP usa a porta 80 como porta padrão para comunicação.

• HTTP opera na camada de aplicativo. Ele precisa criar várias conexões para transferência de dados, o que aumenta as despesas administrativas.

• Nenhuma criptografia / certificados digitais são necessários para usar HTTP.

Detalhes do protocolo Http

Para entender o protocolo HTTP em profundidade, clique em cada um dos links abaixo.

• HTTP Parameters

• HTTP Messages

• HTTP Requests

• HTTP Responses

• HTTP Methods

• HTTP Status Codes

• HTTP Header Fields

• HTTP Security

HTTPS (Hypertext Transfer Protocol sobre Secure Socket Layer) ou HTTP sobre SSL é um protocolo da web desenvolvido pela Netscape. Não é um protocolo, mas é apenas o resultado da camada de HTTP sobre SSL / TLS (Secure Socket Layer / Transport Layer Security).

Resumindo, HTTPS = HTTP + SSL

Quando o HTTPS é necessário?

Quando navegamos, normalmente enviamos e recebemos informações usando o protocolo HTTP. Portanto, isso leva qualquer um a espionar a conversa entre nosso computador e o servidor web. Muitas vezes, precisamos trocar informações confidenciais que precisam ser protegidas e impedir o acesso não autorizado.

Protocolo Https usado nos seguintes cenários -

• Sites de bancos
• Gateway de pagamento
• Sites de compras
• Todas as páginas de login
• Apps de e-mail

Trabalho Básico de HTTPS

• A chave pública e os certificados assinados são necessários para o servidor no protocolo HTTPS.

• Solicitações de clientes para a página https: //

• Ao usar uma conexão https, o servidor responde à conexão inicial oferecendo uma lista de métodos de criptografia que o servidor da web suporta.

• Em resposta, o cliente seleciona um método de conexão e o cliente e o servidor trocam certificados para autenticar suas identidades.

• Depois de fazer isso, o servidor da Web e o cliente trocam as informações criptografadas após garantir que ambos estejam usando a mesma chave e que a conexão seja fechada.

• Para hospedar conexões https, um servidor deve ter um certificado de chave pública, que incorpora informações de chave com uma verificação da identidade do proprietário da chave.

• Quase todos os certificados são verificados por terceiros para que os clientes tenham a garantia de que a chave está sempre segura.

O que é codificação e decodificação?

Codificação é o processo de colocar uma seqüência de caracteres, como letras, números e outros caracteres especiais em um formato especializado para transmissão eficiente.

A decodificação é o processo de converter um formato codificado de volta na sequência original de caracteres. É completamente diferente da criptografia, que geralmente interpretamos mal.

Codificação e decodificação são usadas em comunicações e armazenamento de dados. A codificação NÃO deve ser usada para transportar informações confidenciais.

Codificação de URL

Os URLs só podem ser enviados pela Internet usando o conjunto de caracteres ASCII e há casos em que o URL contém caracteres especiais além dos caracteres ASCII, ele precisa ser codificado. Os URLs não contêm espaços e são substituídos por um sinal de mais (+) ou por% 20.

Codificação ASCII

O navegador (lado do cliente) codificará a entrada de acordo com o conjunto de caracteres usado na página da web e o conjunto de caracteres padrão em HTML5 é UTF-8.

A tabela a seguir mostra o símbolo ASCII do personagem e seu símbolo igual e finalmente sua substituição que pode ser usada na URL antes de passá-la para o servidor -

ASCII	Símbolo	Substituição
<32		Codifique com% xx, onde xx é a representação hexadecimal do caractere.
32	espaço	+ ou% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	$	% 24
37	%	% 25
38	E	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	>	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	UMA	UMA
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	Eu	Eu
74	J	J
75	K	K
76	eu	eu
77	M	M
78	N	N
79	O	O
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	você	você
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	`	% 60
97	uma	uma
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	Eu	Eu
106	j	j
107	k	k
108	eu	eu
109	m	m
110	n	n
111	o	o
112	p	p
113	q	q
114	r	r
115	s	s
116	t	t
117	você	você
118	v	v
119	W	W
120	x	x
121	y	y
122	z	z
123	{	% 7B
124	|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		Codifique com% xx onde xx é a representação hexadecimal do caractere

O que é criptografia?

Criptografia é a ciência para criptografar e descriptografar dados que permite aos usuários armazenar informações confidenciais ou transmiti-las através de redes inseguras para que possam ser lidas apenas pelo destinatário pretendido.

Os dados que podem ser lidos e compreendidos sem quaisquer medidas especiais são chamados plaintext, enquanto o método de disfarçar o texto simples, a fim de esconder sua substância é chamado encryption.

O texto simples criptografado é conhecido como texto cifrado e o processo de reverter os dados criptografados para texto simples é conhecido como decryption.

• A ciência de analisar e quebrar a comunicação segura é conhecida como criptoanálise. As pessoas que realizam o mesmo também são conhecidas como atacantes.

• A criptografia pode ser forte ou fraca e a força é medida pelo tempo e recursos que seriam necessários para recuperar o texto simples real.

• Portanto, uma ferramenta de decodificação apropriada é necessária para decifrar as mensagens criptografadas fortes.

• Existem algumas técnicas criptográficas disponíveis com as quais mesmo um bilhão de computadores fazendo um bilhão de verificações por segundo, não é possível decifrar o texto.

• Como o poder da computação está aumentando dia a dia, é necessário tornar os algoritmos de criptografia muito fortes para proteger dados e informações críticas dos invasores.

Como funciona a criptografia?

Um algoritmo criptográfico funciona em combinação com uma chave (pode ser uma palavra, número ou frase) para criptografar o texto simples e o mesmo texto simples criptografa para texto cifrado diferente com chaves diferentes.

Conseqüentemente, os dados criptografados são alguns parâmetros completamente dependentes, como a força do algoritmo criptográfico e o sigilo da chave.

Técnicas de criptografia

Symmetric Encryption- A criptografia convencional, também conhecida como criptografia convencional, é a técnica em que apenas uma chave é usada para criptografar e descriptografar. Por exemplo, DES, algoritmos Triple DES, MARS da IBM, RC2, RC4, RC5, RC6.

Asymmetric Encryption- É a criptografia de chave pública que usa um par de chaves para criptografar: uma chave pública para criptografar dados e uma chave privada para descriptografar. A chave pública é publicada para as pessoas, enquanto a chave privada é mantida em segredo. Por exemplo, RSA, Digital Signature Algorithm (DSA), Elgamal.

Hashing- Hashing é criptografia ONE-WAY, que cria uma saída codificada que não pode ser revertida ou pelo menos não pode ser revertida facilmente. Por exemplo, algoritmo MD5. É usado para criar certificados digitais, assinaturas digitais, armazenamento de senhas, verificação de comunicações, etc.

A Same Origin Policy (SOP) é ​​um conceito importante no modelo de segurança de aplicativos da web.

O que é a política da mesma origem?

De acordo com esta política, ela permite a execução de scripts em páginas originadas do mesmo site, que podem ser uma combinação do seguinte -

• Domain
• Protocol
• Port

Exemplo

A razão por trás desse comportamento é a segurança. Se você tiver try.com em uma janela e gmail.com em outra janela, NÃO deseja que um script de try.com acesse ou modifique o conteúdo de gmail.com ou execute ações no contexto do gmail em seu nome.

Abaixo estão as páginas da mesma origem. Como explicado antes, a mesma origem leva em consideração domínio / protocolo / porta.

• http://website.com
• http://website.com/
• http://website.com/my/contact.html

Abaixo estão páginas da web de uma origem diferente.

• http://www.site.co.uk (outro domínio)
• http://site.org (outro domínio)
• https://site.com (outro protocolo)
• http://site.com:8080 (outra porta)

Exceções de política da mesma origem para IE

O Internet Explorer tem duas exceções principais ao SOP.

• O primeiro está relacionado a 'Zonas confiáveis'. Se ambos os domínios estiverem em uma zona altamente confiável, a política de Mesma Origem não será totalmente aplicável.

• A segunda exceção no IE está relacionada à porta. O IE não inclui porta na política de Mesma Origem, portanto, http://website.com e http://wesite.com:4444 são considerados da mesma origem e nenhuma restrição é aplicada.

O que é um biscoito?

Um cookie é uma pequena informação enviada por um servidor da web para armazenar em um navegador da web para que possa ser lida posteriormente pelo navegador. Dessa forma, o navegador lembra algumas informações pessoais específicas. Se um Hacker obtiver as informações do cookie, isso pode levar a problemas de segurança.

Propriedades de Cookies

Aqui estão algumas propriedades importantes dos cookies -

• Geralmente são pequenos arquivos de texto, com tags de ID que são armazenadas no diretório do navegador do seu computador.

• Eles são usados ​​por desenvolvedores da web para ajudar os usuários a navegar em seus sites com eficiência e executar certas funções.

• Quando o usuário navega no mesmo site novamente, os dados armazenados no cookie são enviados de volta ao servidor da web para notificar o site das atividades anteriores do usuário.

• Os cookies são inevitáveis ​​para sites que têm bancos de dados enormes, precisam de logins e têm temas personalizáveis.

Conteúdo do Cookie

O cookie contém as seguintes informações -

• O nome do servidor de onde o cookie foi enviado.
• A vida útil do cookie.
• Um valor - geralmente um número exclusivo gerado aleatoriamente.

Tipos de Cookies

• Session Cookies- Esses cookies são temporários e são apagados quando o usuário fecha o navegador. Mesmo se o usuário efetuar login novamente, um novo cookie para essa sessão será criado.

• Persistent cookies- Esses cookies permanecem na unidade de disco rígido, a menos que o usuário os limpe ou eles expirem. A expiração do cookie depende de quanto tempo eles podem durar.

Teste de Cookies

Aqui estão as maneiras de testar os cookies -

• Disabling Cookies- Como testador, precisamos verificar o acesso ao site após desabilitar os cookies e verificar se as páginas estão funcionando corretamente. Navegue por todas as páginas do site e observe as falhas do aplicativo. Também é necessário informar ao usuário que os cookies são necessários para usar o site.

• Corrupting Cookies- Outro teste a ser realizado é corromper os cookies. Para fazer o mesmo, é necessário encontrar a localização do cookie do site e editá-lo manualmente com dados falsos / inválidos que podem ser usados ​​para acessar informações internas do domínio que, por sua vez, podem ser usadas para hackear o site.

• Removing Cookies - Remova todos os cookies do site e verifique como o site reage a eles.

• Cross-Browser Compatibility - Também é importante verificar se os cookies estão sendo gravados corretamente em todos os navegadores suportados de qualquer página que grava cookies.

• Editing Cookies- Se o aplicativo usa cookies para armazenar informações de login, como um testador, devemos tentar alterar o usuário no cookie ou na barra de endereço para outro usuário válido. Editar o cookie não deve permitir que você faça login em uma conta de usuário diferente.

Visualizando e editando cookies

Os navegadores modernos suportam a visualização / edição das informações dos cookies dentro do próprio navegador. Existem plugins para mozilla / chrome com os quais podemos realizar a edição com sucesso.

• Editar plugin de cookies para Firefox

• Editar este plugin de cookie para o Chrome

As etapas devem ser executadas para editar um cookie -

• Baixe o plugin para o Chrome aqui

• Edite o valor do cookie apenas acessando o plug-in 'editar este cookie' no Chrome, conforme mostrado abaixo.

Existem várias metodologias / abordagens que podemos usar como referência para realizar um ataque.

Aplicação Web - Metodologias de PenTesting

Pode-se levar em consideração os seguintes padrões ao desenvolver um modelo de ataque.

Entre a lista a seguir, OWASP é o mais ativo e há uma série de contribuintes. Vamos nos concentrar nas técnicas OWASP que cada equipe de desenvolvimento leva em consideração antes de projetar um aplicativo da web.

• PTES - Padrão de execução de teste de penetração

• OSSTMM - Manual de metodologia de teste de segurança de código aberto

• Técnicas de teste OWASP - protocolo aberto de segurança de aplicativos da Web

OWASP Top 10

A equipe do Open Web Application Security Protocol divulgou as 10 principais vulnerabilidades que prevalecem na web nos últimos anos. Abaixo está a lista de falhas de segurança que são mais prevalentes em um aplicativo baseado na web.

Aplicativo - Prático

Para entender cada uma das técnicas, vamos trabalhar com um exemplo de aplicação. Vamos realizar o ataque ao 'WebGoat', a aplicação J2EE que é desenvolvida explicitamente com falhas de segurança para fins de aprendizagem.

Os detalhes completos sobre o projeto webgoat podem ser localizados https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. Para baixar o aplicativo WebGoat, navegue atéhttps://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) e ir para a seção de downloads.

Para instalar o aplicativo baixado, primeiro certifique-se de que não haja nenhum aplicativo em execução na porta 8080. Ele pode ser instalado usando apenas um único comando - java -jar WebGoat-6.0.1-war-exec.jar. Para mais detalhes, visite Instalação WebGoat

Após a instalação, devemos ser capazes de acessar o aplicativo navegando para http://localhost:8080/WebGoat/attack e a página seria exibida conforme mostrado abaixo.

Podemos usar as credenciais de convidado ou administrador, conforme exibido na página de login.

Web Proxy

Para interceptar o tráfego entre o cliente (navegador) e o servidor (sistema onde a aplicação Webgoat está hospedada em nosso caso), precisamos usar um proxy web. Usaremos Burp Proxy que pode ser baixado dehttps://portswigger.net/burp/download.html

É suficiente baixar a versão gratuita do pacote burp conforme mostrado abaixo.

Configurando Burp Suite

Burp Suite é um proxy web que pode interceptar cada pacote de informação enviado e recebido pelo navegador e servidor web. Isso nos ajuda a modificar o conteúdo antes que o cliente envie as informações para o servidor web.

Step 1- O aplicativo é instalado na porta 8080 e o Burp é instalado na porta 8181 conforme mostrado abaixo. Inicie o pacote Burp e faça as seguintes configurações para trazê-lo para a porta 8181, conforme mostrado abaixo.

Step 2- Devemos garantir que o Burp esteja ouvindo a porta # 8080 onde o aplicativo está instalado para que o pacote Burp possa interceptar o tráfego. Essas configurações devem ser feitas na guia de escopo do Burp Suite, conforme mostrado abaixo.

Step 3- Em seguida, faça as configurações de proxy do navegador para ouvir a porta 8181 (porta Burp Suite). Assim, configuramos o proxy da Web para interceptar o tráfego entre o cliente (navegador) e o servidor (servidor da Web) conforme mostrado abaixo -

Step 4 - O instantâneo da configuração é mostrado abaixo com a ajuda de um diagrama de fluxo de trabalho simples, conforme mostrado abaixo

A técnica de injeção consiste em injetar uma consulta SQL ou um comando usando os campos de entrada do aplicativo.

Aplicativo da Web - Injeção

Uma injeção SQL bem-sucedida pode ler, modificar dados confidenciais do banco de dados e também excluir dados de um banco de dados. Ele também permite que o hacker execute operações administrativas no banco de dados, como desligar o DBMS / descartar bancos de dados.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplos

O aplicativo usa dados não confiáveis ​​na construção da seguinte chamada SQL vulnerável -

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

Mãos em

Step 1 - Navegue até a área SQL Injection do aplicativo conforme mostrado abaixo.

Step 2- Conforme apresentado no exercício, usamos String SQL Injection para ignorar a autenticação. Use a injeção de SQL para fazer login como o chefe ('Neville') sem usar a senha correta. Verifique se o perfil de Neville pode ser visualizado e se todas as funções estão disponíveis (incluindo Pesquisar, Criar e Excluir).

Step 3 - Injetaremos um SQL de forma que possamos contornar a senha enviando o parâmetro como 'a' = 'a' ou 1 = 1

Step 4 - Pós-exploração, podemos fazer o login como Neville, que é o administrador, conforme mostrado abaixo.

Prevenção de injeção de SQL

Existem várias maneiras de prevenir a injeção de SQL. Quando os desenvolvedores escrevem o código, eles devem garantir que lidam com os caracteres especiais de acordo. Existem folhas de dicas / técnicas de prevenção disponíveis no OWASP, que são definitivamente um guia para desenvolvedores.

• Usando consultas parametrizadas
• Escapar de todas as entradas fornecidas pelo usuário
• Habilitar privilégio mínimo para o banco de dados para os usuários finais

Quando as funções de autenticação relacionadas ao aplicativo não são implementadas corretamente, isso permite que os hackers comprometam senhas ou IDs de sessão ou explorem outras falhas de implementação usando as credenciais de outros usuários.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

Um usuário autenticado do site encaminha a URL para seus amigos para saber sobre as vendas com desconto. Ele envia um e-mail com o link acima sem saber que o usuário também está fornecendo os IDs de sessão. Quando seus amigos usam o link, eles usam sua sessão e cartão de crédito.

Mãos em

Step 1- Faça login no Webgoat e navegue até a seção 'Falha de gerenciamento de sessão'. Vamos contornar a autenticação falsificando o cookie. Abaixo está o instantâneo do cenário.

Step 2 - Ao fazer o login usando as credenciais webgoat / webgoat, descobrimos no Burp Suite que o JSESSION ID é C8F3177CCAFF380441ABF71090748F2E enquanto o AuthCookie = 65432ubphcfx após a autenticação bem-sucedida.

Step 3 - Ao fazer o login usando o aspecto / aspecto das credenciais, descobrimos no Burp Suite que a JSESSION ID é C8F3177CCAFF380441ABF71090748F2E, enquanto AuthCookie = 65432udfqtb após autenticação bem-sucedida.

Step 4- Agora precisamos analisar os padrões do AuthCookie. A primeira metade '65432' é comum para ambas as autenticações. Portanto, agora estamos interessados ​​em analisar a última parte dos valores do authcookie, como - ubphcfx para o usuário do webgoat e udfqtb para o usuário do aspecto, respectivamente.

Step 5- Se dermos uma olhada profunda nos valores AuthCookie, a última parte tem o mesmo comprimento que o nome do usuário. Portanto, é evidente que o nome de usuário é usado com algum método de criptografia. Mediante tentativa e erros / mecanismos de força bruta, descobrimos que após inverter o nome de usuário, webgoat; terminamos com taogbew e então o caractere do alfabeto anterior é o que está sendo usado como AuthCookie. ou seja, ubphcfx.

Step 6- Se passarmos esse valor de cookie e vamos ver o que acontece. Após a autenticação como usuário webgoat, altere o valor AuthCookie para simular a usuária Alice, encontrando AuthCookie para o mesmo executando as etapas 4 e 5.

Mecanismos de Prevenção

• Desenvolva uma autenticação forte e controles de gerenciamento de sessão de forma que atenda a todos os requisitos de autenticação e gerenciamento de sessão definidos no Padrão de Verificação de Segurança de Aplicativos da OWASP.

• Os desenvolvedores devem evitar falhas de XSS que podem ser usadas para roubar IDs de sessão.

Cross-site Scripting (XSS) ocorre sempre que um aplicativo pega dados não confiáveis ​​e os envia ao cliente (navegador) sem validação. Isso permite que os invasores executem scripts mal-intencionados no navegador da vítima, o que pode resultar em sequestro de sessões do usuário, desfigurando sites ou redirecionando o usuário para sites mal-intencionados.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Tipos de XSS

• Stored XSS - O XSS armazenado, também conhecido como XSS persistente, ocorre quando a entrada do usuário é armazenada no servidor de destino, como banco de dados / fórum de mensagem / campo de comentário, etc. Em seguida, a vítima é capaz de recuperar os dados armazenados do aplicativo da web.

• Reflected XSS - O XSS refletido, também conhecido como XSS não persistente, ocorre quando a entrada do usuário é imediatamente retornada por um aplicativo da web em uma mensagem de erro / resultado da pesquisa ou a entrada fornecida pelo usuário como parte da solicitação e sem armazenar permanentemente os dados fornecidos pelo usuário.

• DOM Based XSS - O XSS baseado em DOM é uma forma de XSS quando a origem dos dados está no DOM, o coletor também está no DOM e o fluxo de dados nunca sai do navegador.

Exemplo

O aplicativo usa dados não confiáveis ​​na construção sem validação. Os caracteres especiais devem ser escapados.

http://www.webpage.org/task/Rule1?query=try

O invasor modifica o parâmetro de consulta em seu navegador para -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Mãos em

Step 1- Faça login no Webgoat e navegue até a seção de cross-site scripting (XSS). Vamos executar um ataque Stored Cross-site Scripting (XSS). Abaixo está o instantâneo do cenário.

Step 2- De acordo com o cenário, vamos fazer o login como Tom com a senha 'tom' conforme mencionado no próprio cenário. Clique em 'ver perfil' e entre no modo de edição. Como tom é o invasor, vamos injetar o script Java nessas caixas de edição.

<script> 
   alert("HACKED")
</script>

Step 3 - Assim que a atualização terminar, tom recebe uma caixa de alerta com a mensagem "hackeado", o que significa que o aplicativo está vulnerável.

Step 4 - Agora, de acordo com o cenário, precisamos fazer o login como jerry (HR) e verificar se jerry foi afetado pelo script injetado.

Step 5 - Depois de fazer login como Jerry, selecione 'Tom' e clique em 'ver perfil' conforme mostrado abaixo.

Enquanto visualiza o perfil de tom da conta de Jerry, ele consegue obter a mesma caixa de mensagem.

Step 6 - Esta caixa de mensagem é apenas um exemplo, mas o invasor real pode realizar muito mais do que apenas exibir uma caixa de mensagem.

Mecanismos Preventivos

• Os desenvolvedores devem garantir o escape de todos os dados não confiáveis ​​com base no contexto HTML, como corpo, atributo, JavaScript, CSS ou URL em que os dados são colocados.

• Para os aplicativos que precisam de caracteres especiais como entrada, deve haver mecanismos de validação robustos antes de aceitá-los como entradas válidas.

É provável que ocorra uma referência direta a um objeto quando um desenvolvedor expõe uma referência a um objeto de implementação interno, como um arquivo, diretório ou chave de banco de dados, sem nenhum mecanismo de validação que permita aos invasores manipular essas referências para acessar dados não autorizados.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

O aplicativo usa dados não verificados em uma chamada SQL que está acessando informações da conta.

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

O invasor modifica o parâmetro de consulta em seu navegador para apontar para Admin.

http://webapp.com/app/accountInfo?acct=admin

Mãos em

Step 1- Faça login no Webgoat e navegue até a seção de falhas de controle de acesso. O objetivo é recuperar o tomcat-users.xml navegando até o caminho onde ele está localizado. Abaixo está o instantâneo do cenário.

Step 2 - O caminho do arquivo é exibido no campo 'o diretório atual é' - C: \ Users \ userName $ \. Extract \ webapps \ WebGoat \ lição_plans \ en e também sabemos que o arquivo tomcat-users.xml é mantido em C: \ xampp \ tomcat \ conf

Step 3- Precisamos percorrer todo o caminho para fora do diretório atual e navegar em C: \ Drive. Podemos realizar o mesmo interceptando o tráfego usando o Burp Suite.

Step 4 - Se a tentativa for bem-sucedida, ele exibe o tomcat-users.xml com a mensagem "Parabéns. Você concluiu esta lição com sucesso."

Mecanismos Preventivos

Os desenvolvedores podem usar os seguintes recursos / pontos como um guia para evitar referência direta insegura a objetos durante a própria fase de desenvolvimento.

• Os desenvolvedores devem usar apenas um usuário ou sessão para referências indiretas de objetos.

• Também é recomendável verificar o acesso antes de usar uma referência direta ao objeto de uma fonte não confiável.

Segurança A configuração incorreta surge quando as configurações de segurança são definidas, implementadas e mantidas como padrão. Uma boa segurança requer uma configuração segura definida e implementada para o aplicativo, servidor da web, servidor de banco de dados e plataforma. É igualmente importante ter o software atualizado.

Exemplo

Alguns exemplos clássicos de configuração incorreta de segurança são fornecidos -

• Se a listagem de diretórios não estiver desabilitada no servidor e se o invasor descobrir o mesmo, o invasor pode simplesmente listar os diretórios para encontrar qualquer arquivo e executá-lo. Também é possível obter a base de código real que contém todo o seu código personalizado e, em seguida, encontrar falhas graves no aplicativo.

• A configuração do servidor de aplicativos permite que os rastreamentos de pilha sejam retornados aos usuários, potencialmente expondo falhas subjacentes. Os invasores obtêm as informações extras fornecidas pelas mensagens de erro, o que é suficiente para eles penetrarem.

• Os servidores de aplicativos geralmente vêm com aplicativos de amostra que não são bem protegidos. Se não for removido do servidor de produção, o seu servidor ficará comprometido.

Mãos em

Step 1- Inicie o Webgoat e navegue até a seção de configuração insegura e deixe-nos tentar resolver esse desafio. Um instantâneo do mesmo é fornecido abaixo -

Step 2- Podemos experimentar quantas opções pudermos pensar. Tudo o que precisamos é encontrar a URL do arquivo de configuração e sabemos que os desenvolvedores seguem uma espécie de convenção de nomenclatura para arquivos de configuração. Pode ser qualquer coisa listada abaixo. Geralmente é feito pela técnica de força BRUTE.

• web.config
• config
• appname.config
• conf

Step 3 - Ao tentar várias opções, descobrimos que 'http://localhost:8080/WebGoat/conf'é bem-sucedido. A página a seguir é exibida se a tentativa for bem-sucedida -

Mecanismos Preventivos

• Todos os ambientes, como ambientes de desenvolvimento, controle de qualidade e produção, devem ser configurados de forma idêntica, usando diferentes senhas usadas em cada ambiente que não possam ser invadidas facilmente.

• Certifique-se de que uma arquitetura de aplicativo forte está sendo adotada, fornecendo separação eficaz e segura entre os componentes.

• Ele também pode minimizar a possibilidade desse ataque executando varreduras automatizadas e auditorias periódicas.

Como os aplicativos online continuam inundando a Internet dia após dia, nem todos os aplicativos são protegidos. Muitos aplicativos da web não protegem adequadamente os dados confidenciais do usuário, como informações de cartões de crédito / informações de contas bancárias / credenciais de autenticação. Os hackers podem acabar roubando esses dados fracamente protegidos para conduzir fraude de cartão de crédito, roubo de identidade ou outros crimes.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

Alguns dos exemplos clássicos de configuração incorreta de segurança são os fornecidos -

• Um site simplesmente não usa SSL para todas as páginas autenticadas. Isso permite que um invasor monitore o tráfego de rede e roube o cookie de sessão do usuário para sequestrar a sessão do usuário ou acessar seus dados privados.

• Um aplicativo armazena os números de cartão de crédito em um formato criptografado em um banco de dados. Após a recuperação, eles são descriptografados, permitindo que o hacker execute um ataque de injeção de SQL para recuperar todas as informações confidenciais em um texto não criptografado. Isso pode ser evitado criptografando os números de cartão de crédito usando uma chave pública e permitindo que aplicativos back-end os descriptografem com a chave privada.

Mãos em

Step 1- Inicie o WebGoat e navegue até a seção "Armazenamento Inseguro". Um instantâneo do mesmo é exibido abaixo.

Step 2- Digite o nome de usuário e a senha. É hora de aprender diferentes tipos de metodologias de codificação e criptografia que discutimos anteriormente.

Mecanismos Preventivos

• É aconselhável não armazenar dados confidenciais desnecessariamente e deve ser removido o mais rápido possível, caso não seja mais necessário.

• É importante garantir que sejam incorporados algoritmos de criptografia fortes e padrão e que haja um gerenciamento de chaves adequado.

• Também pode ser evitado desativando o preenchimento automático em formulários que coletam dados confidenciais, como senha, e desativando o cache de páginas que contêm dados confidenciais.

A maioria dos aplicativos da web verifica os direitos de acesso de nível de função antes de tornar essa funcionalidade acessível ao usuário. No entanto, se as mesmas verificações de controle de acesso não forem executadas no servidor, os hackers podem entrar no aplicativo sem a devida autorização.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

Aqui está um exemplo clássico de controle de acesso de nível de função ausente -

O hacker simplesmente força os URLs de destino. Normalmente, o acesso de administrador requer autenticação, no entanto, se o acesso ao aplicativo não for verificado, um usuário não autenticado pode acessar a página de administrador.

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

Mãos em

Step 1 - Vamos fazer o login como gerente de conta, primeiro percorrendo a lista de usuários e seus privilégios de acesso.

Step 2 - Ao tentar várias combinações, podemos descobrir que Larry tem acesso ao gerente de contas de recursos.

Mecanismos Preventivos

• O mecanismo de autenticação deve negar todo o acesso por padrão e fornecer acesso a funções específicas para cada função.

• Em um aplicativo baseado em fluxo de trabalho, verifique o estado dos usuários antes de permitir que eles acessem quaisquer recursos.

Um ataque CSRF força um usuário autenticado (vítima) a enviar uma solicitação HTTP forjada, incluindo o cookie de sessão da vítima para um aplicativo da web vulnerável, o que permite que o invasor force o navegador da vítima a gerar uma solicitação de forma que o aplicativo vulnerável perceba como solicitações legítimas de a vítima.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

Aqui está um exemplo clássico de CSRF -

Step 1 - Digamos que o aplicativo vulnerável envie uma solicitação de alteração de estado como um texto simples, sem qualquer criptografia.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - Agora, o hacker constrói uma solicitação que transfere dinheiro da conta da vítima para a conta do invasor incorporando a solicitação em uma imagem que é armazenada em vários sites sob o controle do invasor -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

Mãos em

Step 1- Vamos realizar uma falsificação de CSRF incorporando um script Java em uma imagem. O instantâneo do problema está listado abaixo.

Step 2 - Agora precisamos simular a transferência em uma imagem 1x1 e fazer a vítima clicar na mesma.

Step 3 - Ao enviar a mensagem, a mensagem é exibida conforme destacado abaixo.

Step 4- Agora, se a vítima clicar na URL a seguir, a transferência é executada, que pode ser encontrada interceptando a ação do usuário usando o pacote de burp. Podemos ver a transferência localizando-a em Obter mensagem, conforme mostrado abaixo -

Step 5 - Agora, ao clicar em atualizar, a marca de conclusão da lição é exibida.

Mecanismos Preventivos

• O CSRF pode ser evitado criando um token exclusivo em um campo oculto que seria enviado no corpo da solicitação HTTP em vez de em uma URL, que é mais sujeita à exposição.

• Forçar o usuário a reautenticar ou provar que são usuários para proteger o CSRF. Por exemplo, CAPTCHA.

Esse tipo de ameaça ocorre quando os componentes, como bibliotecas e estruturas usadas no aplicativo, quase sempre são executados com privilégios totais. Se um componente vulnerável for explorado, o trabalho do hacker será mais fácil de causar uma perda grave de dados ou controle do servidor.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

Os exemplos a seguir são de uso de componentes com vulnerabilidades conhecidas -

• Os invasores podem invocar qualquer serviço da web com permissão total, deixando de fornecer um token de identidade.

• A execução remota de código com vulnerabilidade de injeção de linguagem de expressão é introduzida por meio do Spring Framework para aplicativos baseados em Java.

Mecanismos Preventivos

• Identifique todos os componentes e as versões que estão sendo usados ​​nos webapps, não apenas restritos a bancos de dados / estruturas.

• Mantenha todos os componentes, como bancos de dados públicos, listas de discussão de projetos, etc. atualizados.

• Adicione invólucros de segurança em torno de componentes que são vulneráveis ​​por natureza.

A maioria dos aplicativos da web na Internet freqüentemente redireciona e encaminha os usuários para outras páginas ou outros sites externos. No entanto, sem validar a credibilidade dessas páginas, os hackers podem redirecionar as vítimas para sites de phishing ou malware, ou usar encaminhamentos para acessar páginas não autorizadas.

Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.

Exemplo

Alguns exemplos clássicos de redirecionamentos e encaminhamentos não validados são fornecidos -

• Digamos que o aplicativo tenha uma página - redirect.jsp, que recebe um parâmetro de redirecionamento . O hacker adiciona um URL malicioso que redireciona os usuários que executam phishing / instala malware.

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

• Todos os aplicativos da web usados ​​para encaminhar os usuários para diferentes partes do site. Para conseguir o mesmo, algumas páginas utilizam um parâmetro para indicar para onde o usuário deve ser redirecionado se uma operação for bem-sucedida. O invasor cria uma URL que passa na verificação de controle de acesso do aplicativo e, em seguida, encaminha o invasor para uma funcionalidade administrativa para a qual o invasor não obteve acesso.

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

Mecanismos Preventivos

• É melhor evitar o uso de redirecionamentos e encaminhamentos.

• Se for inevitável, deve ser feito sem envolver os parâmetros do usuário no redirecionamento do destino.

Javascript e XML assíncrono (AJAX) é uma das técnicas mais recentes usadas para desenvolver aplicativos da Web para fornecer uma experiência rica ao usuário. Por se tratar de uma nova tecnologia, há muitos problemas de segurança que ainda não foram estabelecidos e abaixo estão alguns problemas de segurança no AJAX.

• A superfície de ataque é maior, pois há mais entradas a serem protegidas.

• Ele também expõe as funções internas dos aplicativos.

• Falha em proteger as informações e sessões de autenticação.

• Há uma linha muito estreita entre o lado do cliente e o lado do servidor, portanto, há possibilidades de cometer erros de segurança.

Exemplo

Aqui está um exemplo para AJAX Security -

Em 2006, um worm infectou o serviço de e-mail do yahoo usando XSS e AJAX que se aproveitou de uma vulnerabilidade no tratamento de eventos onload do Yahoo Mail. Quando um e-mail infectado era aberto, o worm executava seu JavaScript, enviando uma cópia para todos os contatos do Yahoo do usuário infectado.

Mãos em

Step 1- Precisamos tentar adicionar mais recompensas ao seu conjunto permitido de recompensas usando injeção de XML. Abaixo está o instantâneo do cenário.

Step 2- Certifique-se de interceptar a solicitação e a resposta usando o Burp Suite. Configurações iguais às mostradas abaixo.

Step 3- Insira o número da conta conforme fornecido no cenário. Poderemos obter uma lista de todas as recompensas para as quais somos elegíveis. Temos direito a 3 recompensas em 5.

Step 4- Agora vamos clicar em 'Enviar' e ver o que obtemos no XML de resposta. Conforme mostrado abaixo, as três recompensas de que somos elegíveis são passadas para nós como XML.

Step 5 - Agora vamos editar esses XMLs e adicionar as outras duas recompensas também.

Step 6- Agora, todas as recompensas seriam exibidas para o usuário selecionar. Selecione os que adicionamos e clique em 'Enviar'.

Step 7 - A seguinte mensagem aparece dizendo: "* Parabéns. Você concluiu esta lição com sucesso."

Mecanismos Preventivos

Lado do cliente -

• Use .innerText em vez de .innerHtml.
• Não use eval.
• Não confie na lógica do cliente para segurança.
• Evite escrever código de serialização.
• Evite construir XML dinamicamente.
• Nunca transmita segredos ao cliente.
• Não execute criptografia no código do lado do cliente.
• Não execute lógica de impacto de segurança no lado do cliente.

Lado do servidor -

• Use proteção CSRF.
• Evite escrever código de serialização.
• Os serviços podem ser chamados diretamente pelos usuários.
• Evite construir XML manualmente, use a estrutura.
• Evite construir JSON manualmente, use uma estrutura existente.

Em aplicativos modernos baseados na web, o uso de serviços da web é inevitável e eles também estão sujeitos a ataques. Como a solicitação de serviços da web é obtida de vários sites, os desenvolvedores precisam tomar algumas medidas adicionais para evitar qualquer tipo de penetração de hackers.

Mãos em

Step 1- Navegue até a área de serviços da Web do Webgoat e vá para Digitalização WSDL. Precisamos agora obter os detalhes do cartão de crédito de algum outro número de conta. O instantâneo do cenário é mencionado abaixo.

Step 2 - Se selecionarmos o primeiro nome, a chamada da função 'getFirstName' é feita através do xml de solicitação SOAP.

Step 3- Ao abrir o WSDL, podemos ver que existe um método para recuperar informações de cartão de crédito, bem como 'getCreditCard'. Agora vamos alterar as entradas usando o conjunto Burp, conforme mostrado abaixo -

Step 4 - Agora vamos modificar as entradas usando o pacote Burp conforme mostrado abaixo -

Step 5 - Podemos obter as informações do cartão de crédito de outros usuários.

Mecanismos Preventivos

• Como as mensagens SOAP são baseadas em XML, todas as credenciais passadas devem ser convertidas para o formato de texto. Portanto, é preciso ter muito cuidado ao passar as informações confidenciais, que devem ser sempre criptografadas.

• Proteger a integridade da mensagem implementando mecanismos como a soma de verificação aplicada para garantir a integridade do pacote.

• Protegendo a confidencialidade da mensagem - A criptografia assimétrica é aplicada para proteger as chaves de sessão simétricas, que em muitas implementações são válidas para apenas uma comunicação e são descartadas posteriormente.

Um estouro de buffer surge quando um programa tenta armazenar mais dados em uma área de armazenamento temporário de dados (buffer) do que deveria. Como os buffers são criados para conter uma quantidade finita de dados, as informações extras podem transbordar para os buffers adjacentes, corrompendo os dados válidos neles mantidos.

Exemplo

Aqui está um exemplo clássico de estouro de buffer. Ele demonstra um estouro de buffer simples causado pelo primeiro cenário no qual depende de dados externos para controlar seu comportamento. Não há como limitar a quantidade de dados que o usuário inseriu e o comportamento do programa depende de quantos caracteres o usuário inseriu.

...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

Mãos em

Step 1- Precisamos fazer o login com nome e número do quarto para ter acesso à internet. Aqui está o instantâneo do cenário.

Step 2 - Também habilitaremos "Unhide hidden form fields" no Burp Suite como mostrado abaixo -

Step 3- Agora enviamos uma entrada no campo nome e número do quarto. Também tentamos injetar um número bem grande no campo do número do quarto.

Step 4- Os campos ocultos são exibidos conforme mostrado abaixo. Clicamos em aceitar os termos.

Step 5 - O ataque foi bem-sucedido de tal forma que, como resultado do estouro do buffer, ele começou a ler as localizações de memória adjacentes e foi exibido para o usuário conforme mostrado abaixo.

Step 6- Agora vamos fazer o login usando os dados exibidos. Após o registro, a seguinte mensagem é exibida -

Mecanismos Preventivos

• Revisão de código
• Treinamento de desenvolvedor
• Ferramentas de compilador
• Desenvolvimento de funções seguras
• Varredura Periódica

O ataque de negação de serviço (DoS) é uma tentativa dos hackers de tornar um recurso de rede indisponível. Geralmente interrompe o host, temporária ou indefinidamente, que está conectado à internet. Esses ataques normalmente visam serviços hospedados em servidores da web de missão crítica, como bancos, gateways de pagamento com cartão de crédito.

Sintomas de DoS

• Desempenho de rede excepcionalmente lento.
• Indisponibilidade de um determinado site.
• Incapacidade de acessar qualquer site da web.
• Aumento dramático no número de e-mails de spam recebidos.
• Negação de longo prazo de acesso à web ou a quaisquer serviços da Internet.
• Indisponibilidade de um determinado site.

Mãos em

Step 1- Inicie o WebGoat e navegue até a seção 'Negação de serviço'. O instantâneo do cenário é fornecido abaixo. Precisamos fazer login várias vezes lá, violando o tamanho máximo do pool de threads do banco de dados.

Step 2- Primeiro precisamos obter a lista de logins válidos. Usamos SQL Injection neste caso.

Step 3 - Se a tentativa for bem-sucedida, ele exibirá todas as credenciais válidas para o usuário.

Step 4- Agora faça login com cada um desses usuários em pelo menos 3 sessões diferentes para que o ataque DoS seja bem-sucedido. Como sabemos que a conexão de banco de dados pode lidar com apenas duas threads, usando todos os logins ela criará três threads que tornam o ataque bem-sucedido.

Mecanismos Preventivos

• Execute validações de entrada completas.

• Evite operações que consomem muito da CPU.

• É melhor separar os discos de dados dos discos do sistema.

Os desenvolvedores geralmente usam ou concatenam entradas potencialmente vulneráveis ​​com arquivos ou presumem que os arquivos de entrada são genuínos. Quando os dados não são verificados corretamente, isso pode fazer com que o conteúdo vulnerável seja processado ou chamado pelo servidor da web.

Exemplo

Alguns dos exemplos clássicos incluem -

• Carregue o arquivo .jsp na árvore da web.
• Carregue .gif para ser redimensionado.
• Faça upload de arquivos enormes.
• Carregar arquivo contendo tags.
• Carregue o arquivo .exe na árvore da web.

Mãos em

Step 1- Inicie o WebGoat e navegue até a seção de execução de arquivo malicioso. O instantâneo do cenário é fornecido abaixo -

Step 2 - Para concluir esta lição, precisamos carregar guest.txt no local mencionado acima.

Step 3- Vamos criar um arquivo jsp de forma que o arquivo guest.txt seja criado ao executar o jsp. A nomenclatura do jsp não tem nenhum papel a desempenhar neste contexto, pois estamos executando o conteúdo do arquivo jsp.

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

Step 4- Agora carregue o arquivo jsp e copie a localização do link do mesmo após o upload. O upload está esperando uma imagem, mas estamos enviando um jsp.

Step 5 - Ao navegar até o arquivo jsp, não haverá nenhuma mensagem para o usuário.

Step 6 - Agora atualize a sessão onde você carregou o arquivo jsp e você receberá a mensagem "* Parabéns. Você concluiu a lição com sucesso".

Mecanismos Preventivos

• Proteja sites usando permissões de sites.
• Adote contramedidas para segurança de aplicativos da web.
• Compreenda as contas de usuário e grupo integradas no IIS 7.0.

Existem várias ferramentas disponíveis para realizar testes de segurança de um aplicativo. Existem algumas ferramentas que podem realizar testes de segurança ponta a ponta, enquanto algumas são dedicadas a detectar um tipo específico de falha no sistema.

Ferramentas de código aberto

Algumas ferramentas de teste de segurança de código aberto são fornecidas -

S.No.	Nome da Ferramenta
1	Zed Attack Proxy Fornece scanners automatizados e outras ferramentas para detectar falhas de segurança. https://www.owasp.org
2	OWASP WebScarab Desenvolvido em Java para análise de solicitações Http e Https. https://www.owasp.org/index.php
3	OWASP Mantra Suporta estrutura de teste de segurança multilíngue https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
4	Burp Proxy Ferramenta para interceptar e modificar o tráfego e trabalhar com certificados SSL personalizados. https://www.portswigger.net/Burp/
5	Firefox Tamper Data Use tamperdata para visualizar e modificar cabeçalhos HTTP / HTTPS e parâmetros de postagem https://addons.mozilla.org/en-US
6	Firefox Web Developer Tools A extensão Web Developer adiciona várias ferramentas de desenvolvedor web ao navegador. https://addons.mozilla.org/en-US/firefox
7	Cookie Editor Permite ao usuário adicionar, excluir, editar, pesquisar, proteger e bloquear cookies https://chrome.google.com/webstore

Conjuntos de ferramentas específicos

As ferramentas a seguir podem nos ajudar a identificar um tipo específico de vulnerabilidade no sistema -

S.No.	Ligação
1	DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/
2	OWASP SQLiX − SQL Injection https://www.owasp.org/index.php
3	Sqlninja − SQL Injection http://sqlninja.sourceforge.net/
4	SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/
5	sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/
6	SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools
7	THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/
8	Brutus − Brute Force Password http://www.hoobie.net/brutus/
9	Ncat − Brute Force Password https://nmap.org/ncat/
10	OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/
11	Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz
12	Metasploit − Testing Buffer Overflow https://www.metasploit.com/

Ferramentas comerciais de teste de caixa preta

Aqui estão algumas das ferramentas comerciais de teste de caixa preta que nos ajudam a identificar problemas de segurança nos aplicativos que desenvolvemos.

S.No	Ferramenta
1	NGSSQuirreL https://www.nccgroup.com/en/our-services
2	IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/
3	Acunetix Web Vulnerability Scanner https://www.acunetix.com/
4	NTOSpider https://www.ntobjectives.com/products/ntospider.php
5	SOAP UI https://www.soapui.org/Security/getting-started.html
6	Netsparker https://www.mavitunasecurity.com/netsparker/
7	HP WebInspect http://www.hpenterprisesecurity.com/products

Analisadores de código-fonte grátis

S.No	Ferramenta
1	OWASP Orizon https://www.owasp.org/index.php
2	OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform
3	SearchDiggity https://www.bishopfox.com/resources/tools
4	FXCOP https://www.owasp.org/index.php/FxCop
5	Splint http://splint.org/
6	Boon https://www.cs.berkeley.edu/~daw/boon/
7	W3af http://w3af.org/
8	FlawFinder https://www.dwheeler.com/flawfinder/
9	FindBugs http://findbugs.sourceforge.net/

Analisadores de código-fonte comercial

Esses analisadores examinam, detectam e relatam os pontos fracos do código-fonte, que são propensos a vulnerabilidades -

S.No	Ferramenta
1	Parasoft C/C++ test https://www.parasoft.com/cpptest/
2	HP Fortify http://www.hpenterprisesecurity.com/products
3	Appscan http://www-01.ibm.com/software/rational/products
4	Veracode https://www.veracode.com
5	Armorize CodeSecure http://www.armorize.com/codesecure/
6	GrammaTech https://www.grammatech.com/