Sumri

Exemplo 4
......................................................................................................
RELATRIO 5 - Evitando ataques RCP e DDOS Ataques DoS (Denial of Service) e
DDoS (Distributed DoS)

ETAPA 1
RELATRIO 1- Desenvolvendo Softwares Seguros, abordando a necessidades de
investir em segurana no desenvolvimento de sistemas e a lista com os princpios de
segurana.

Figura 1 - Invadindo seu Sistema

importante que o software seja desenvolvido com segurana, a fim de diminuir o
nmero de vulnerabilidades, que a cada ano vem crescendo. Para tanto, os requisitos de
segurana da informao precisam ser incorporados em cada etapa do desenvolvimento,
desde, o incio do desenvolvimento de software at a etapa de implantao, pois quanto mais
cedo forem identificadas as vulnerabilidades, menores sero os gastos no projeto, sendo de
suma importncia que os nveis de segurana de um produto sejam mensurados de acordo
com o risco que apresenta.
No desenvolvimento do software importante conhecer as vulnerabilidades de cada
etapa do desenvolvimento para que as ameaas iminentes possam ser removidas da forma
mais clere possvel, eliminando assim os riscos da m gesto de custos e da descoberta de
vulnerabilidades j na finalizao do software. Quando a empresa sofre essas ameaas
(ataques ou tentativas de ataques) importante coletar as situaes anteriores, a fim de que, os
dados possam ser analisados sempre que um novo sistema for desenvolvido.
2

Como j dito, os nveis de segurana alteram de acordo com o mbito de negcio que
a empresa possui, logo importante importante reunir os *stakeholders para propor quais
sero os critrios de avaliao para a implantao da segurana e quais sero os nveis de
segurana.
Para que os problemas no desenvolvimento de softwares sejam atenuados, preciso
adotar padres de cdigos, normas e manuais de segurana a fim de que se possam evitar
erros no cdigo fonte, alm da etapa de testes que ser muito importante a cada nova
implementao de levantamento de requisitos.
O modelo clssico ou Cascata, que tambm conhecido por abordagem top-down,
foi proposto por Royce em 1970. At meados da dcada de 1980 foi o nico modelo com
aceitao geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim
de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com
outros modelos de desenvolvimento de software, este mais rgido e menos administrativo.
O modelo Cascata um dos mais importantes modelos, e referncia para muitos
outros modelos, servindo de base para muitos projetos modernos. A verso original deste
modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado hoje em
dia.
Grande parte do sucesso do modelo Cascata est no fato dele ser orientado para
documentao. No entanto deve salientar-se que a documentao abrange mais do que
arquivo de texto, abrange representaes grficas ou mesmo simulao. Uma abordagem
incorporando processos, mtodos e ferramentas deve ser utilizada pelos criadores de software.
Esta abordagem muitas vezes designada de Abordagem do Processo de Desenvolvimento.
Existem trs abordagens de modelos de processo de desenvolvimento de software. Elas
tentem colocar ordem numa atividade inerentemente catica.
Uma vez definido o modelo de ciclo de desenvolvimento, existem trs abordagens
para implement-lo:

Cascata pura;
Incremental;
Evolucionria.
O modelo Cascata um modelo de engenharia projetado para ser aplicado no

desenvolvimento do software. A idia principal que o dirige que as diferentes etapas de

desenvolvimento seguem uma seqncia: a sada da primeira etapa flu para a segunda
etapa e a sada da segunda etapa flu para a terceira e assim por diante. As atividades a
3

executar so agrupadas em tarefas, executadas seqencialmente, de forma que uma tarefa s

poder ter incio quando a anterior tiver terminado.
O modelo em Cascata tem a vantagem que s avana para a tarefa seguinte quando o
cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupe que o cliente
participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o
impacto da compreenso adquirida no decurso de um projeto, uma vez que se um processo
no pode voltar atrs de modo a alterar os modelos e as concluses das tarefas anteriores,
normal que as novas idias sobre o sistema no sejam aproveitadas.
Numa tentativa de resolver este tipo de problema foi definido um novo tipo de
processo baseado no clssico em cascata, designado por modelo em cascata revisto, cuja
principal diferena consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se
poder regressar a uma tarefa anterior de forma a contemplar alteraes funcionais e/ou
tcnicas que entretanto tenham surgido, em virtude de um maior conhecimento que entretanto
se tenha obtido. O risco desta abordagem que, na ausncia de um processo de gesto do
projeto e de controlo das alteraes bem definido, podemos passar o tempo num ciclo infinito,
sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.
Sendo isso estabelecido, os requisitos devem ser definidos de uma maneira apropriada
para que sejam teis na etapa seguinte. Esta etapa inclui tambm a documentao e o estudo
da facilidade e da viabilidade do projeto com o fim de determinar o processo de incio de
desenvolvimento do projeto do sistema; pode ser vista como uma concepo de um produto
de software e tambm como o incio do seu ciclo de vida.
Com certeza, todas essas variaes do modelo Cascata possuem o mesmo conceito
bsico: a idia de que uma etapa fornece sada que sero usadas como entradas para a etapa
seguinte. Portanto, o processo de desenvolvimento de um produto de software de acordo com
o modelo Cascata simples de conhecer e controlar.
Outras atividades que tambm so levadas em considerao em cada uma das etapas
de desenvolvimento do software: a documentao, a verificao e a administrao das etapas
serem documentos. A verificao, por sua vez, necessria para que uma etapa fornea os
dados corretos para a etapa seguinte. J a administrao, efetua a gesto e o controle da etapa.

Problemas
O ciclo de vida Cascata o paradigma mais visto e mais amplamente empregue na
engenharia de software, porm sua aplicabilidade, em muitos campos, tem sido questionada.
Entre os problemas que surgem quando se aplica o modelo so:

Na realidade, os projetos raramente seguem o fluxo seqencial que o modelo prope. A

interao sempre necessria e est presente, criando problemas na aplicao do modelo;

Em princpio, difcil para o cliente especificar os requisitos explicitamente, o que

acarreta a incerteza natural do incio de qualquer projeto;

O cliente deve ser paciente, pois uma verso funcional no estar disponvel at o final do
desenvolvimento. Qualquer erro ou mal entendido, se no for detectado at que o software
seja revisado, pode ser desastroso.
Apesar desses problemas, o modelo Cascata tem um lugar bem definido e importante
nos trabalhos de engenharia de software. Ele fornece um padro do qual se encaixam
mtodos para a anlise, projeto, codificao e manuteno.

Domnio de aplicaes
O modelo Cascata aplica-se bem em situaes em que o software a ser desenvolvido
simples, os requisitos so bem conhecidos, a tecnologia usada bem acessvel e os recursos
para o desenvolvimento esto disponveis.

Vantagens do modelo
Torna o processo de desenvolvimento estruturado. Tem uma ordem seqencial
de fases. Cada fase cai em cascata na prxima e cada fase deve estar terminada antes
do incio da seguinte;
Todas as atividades identificadas nas fases do modelo so fundamentais e esto

na ordem certa;
Esta abordagem atualmente a norma e provavelmente permanecer como tal nos
prximos tempos.
Desvantagens do modelo

No fornece feedback entre as fases e no permite a atualizao ou redefinio das

fases anteriores;
No suporta modificaes nos requisitos;
No prev a manuteno;
No permite a reutilizao;
excessivamente sincronizado;
Se ocorrer um atraso todo o processo afetado;
Faz aparecer o software muito tarde;
O modelo conduz a uma rgida diviso de trabalho (analistas, arquitetos,

programadores, controladores de qualidade, programadores de manuteno);

S o chefe do projeto tem uma viso global do problema;
Quando algo corre mal, a culpa dos outros... ningum se sente realmente
responsvel.

Figura 2 - Modelo Cascata

Lista dos Princpios de Segurana

Anlise (Especificao dos requisitos)

Nesta etapa, estabelecem-se os requisitos do produto que se deseja desenvolver, o que

consiste usualmente nos servios que se devem fornecer, limitaes e objetivos do software.
Sendo isso estabelecido, os requisitos devem ser definidos de uma maneira apropriada para
que sejam teis na etapa seguinte. Esta etapa inclui tambm a documentao e o estudo da
facilidade e da viabilidade do projeto com o fim de determinar o processo de incio de
desenvolvimento do projeto do sistema; pode ser vista como uma concepo de um produto
de software e tambm como o incio do seu ciclo de vida.
Desenho (Arquitetura e modelo do sistema)
O projeto do sistema um processo de vrios passos que se centraliza em quatro
atributos diferentes do sistema: estrutura de dados, arquitetura do software, detalhes procedais
e caracterizao das interfaces.
O processo de projeto representa os requisitos de uma forma que permita a codificao
do produto ( uma prvia etapa de codificao).
Da mesma maneira que a anlise dos requisitos, o projeto documentado e
transforma-se em uma parte do software.
Implementao (Codificao e desenvolvimento)
Esta a etapa em que so criados os programas, se o projeto possui um nvel de
detalhe elevado, a etapa de codificao pode implementar-se automaticamente. A princpio,
sugere-se incluir um teste unitrio dos mdulos nesta etapa; nesse caso, as unidades de cdigo
produzidas so testadas individualmente antes de passar a etapa de integrao e teste global.
Teste do sistema (Validao e qualidade)
Concluda a codificao, comea a fase de teste do sistema, o processo de teste
centraliza-se em dois pontos principais: as lgicas internas do software e as funcionalidades
externas. Esta fase decide se foram solucionados erros de comportamento do software e
assegura que as entradas definidas produzam resultados reais que coincidam com os requisitos
especificados.
Implantao (Instalao e manuteno)
7

Essa etapa consiste na correo de erros que no foram previamente detectados, em

melhorias funcionais e de preferncia e outros tipos de suporte.
A etapa de manuteno parte do ciclo de vida do produto de software e no pertence
estritamente ao seu desenvolvimento.
Melhorias e correes podem ser consideradas como parte do desenvolvimento. As
etapas descritas so as principais, porm existem sub-etapas dentro de cada etapa, as quais
diferem muito de um projeto para outro.
Tambm possvel que certos projetos de software exijam a incorporao de uma
etapa extra ou a separao de uma etapa em outras etapas.
Com certeza, todas essas variaes do modelo Cascata possuem o mesmo conceito
bsico: a idia de que uma etapa fornece sada que sero usadas como entradas para a etapa
seguinte. Portanto, o processo de desenvolvimento de um produto de software de acordo com
o modelo Cascata simples de conhecer e controlar.

RELATRIO 2 - Evitando o estouro de Buffer

Buffer Overflow
Buffers so reas de memria criadas pelos programas para armazenar dados que esto
sendo processados de maneira anloga. Visando uma melhor compreenso possvel
referenciar buffer como pilha. Cada pilha tem um determinado tamanho que depende do tipo
de dados que ele ir armazenar.
A situao de buffer overflow ocorre quando o programa recebe mais dados do que
est preparado para armazenar na pilha. Desta forma, se o programa no foi adequadamente
escrito este excesso de dados pode acabar sendo armazenado em reas de memria prximas
o que acaba corrompendo dados ou travando o programa. Ainda h a possibilidade do mesmo
ser executado que a mais perigosa devido a uma possvel escalada de privilgios.
O princpio bsico do buffer overflow consiste em estourar o buffer e ao sobrescrever
parte da pilha altera os valores das variveis locais, parmetros e/ou o endereo de retorno
(return address). Ao alterar o endereo de retorno de uma funo o buffer overflow faz com
que o endereo aponte para uma rea em que o cdigo encontra-se armazenado. Normalmente
8

o novo endereo apontado um cdigo malicioso dentro do prprio buffer estourado. Pode-se
assim, executar cdigos arbitrrios com os privilgios do usurio que executa o programa
vulnervel. Os principais alvos so servios de sistema ou aplicaes que executam com
privilgios de Super-usurio.

Figura 3 - Pilha aps chamada de funo ( Call )

Na Figura 3, possvel verificar a existncia de dois registradores utilizados para
controle de uma pilha. So eles: EBP e ESP, o primeiro EBP base pointer utilizado para
indicar a base de uma pilha. J o segundo, o registrador ESP stack pointer utilizado para
indicar o topo de uma pilha. Uma pilha pode conter alm do endereo de retorno, algumas
variveis, parmetros e outros dados para controle da pilha, como os registradores acima
citados. A pilha o enfraquecedor de toda essa estrutura uma vez que possvel alterar o
valor do endereo de retorno do programa e redirecion-lo para um cdigo malicioso. Assim,
os ponteiros de instrues como do processo ESP, que o registrador que guarda o topo da
lista, passam a ser controlados pelo atacante que pode fazer chamadas a funes disponveis
no sistema. Devido ao fato da alterao do endereo de retorno poder ser feita pelo estouro
de uma varivel local alocada na pilha que originou o nome buffer overflow.

Shellcode
Shellcode um conjunto pequeno de instrues em Assembly gerados a partir de um
programa que foi codificado e compilado especificamente para a plataforma alvo( entende-se
por plataforma alvo o tipo de processador) objetivando explorar uma vulnerabilidade e
executar comandos arbitrrios. Geralmente comum ter como resultado a chamada de um
interpretador de comandos ("Shell") por isso o nome "shellcode".
9

Shellcode em nvel de kernel significa cdigo de mquina. Por exemplo, nas janelas a
instruo de conjunto do eax que responsvel em armazenar o valor de retorno de uma
pilha, transformada em 0x50. A instruo nop (no operation) que no faz nenhum tipo de
alterao nos dados transformada em 0x90. Essas alteraes so os chamados opcodes
(operation codes) correspondentes, ou seja, ao debugar um programa possvel verificar que
as instrues equivalentes em cdigo de mquina, possuem o seguinte formato 0xYY, onde Y
um caractere hexadecimal. Ao explorar uma vulnerabilidade o atacante controla o programa
alvo para executar seu shellcode.
Shellcodes so muito usados nos exploits (programas customizados para explorao de
uma vulnerabilidade) como parte dos mesmos, camuflando as instrues arbitrrias, ou seja,
so os cdigos maliciosos que atravs de cdigo de baixo nvel realizam chamadas funes
do sistema a fim de se modificar por exemplo o status de um usurio, fazer chamadas de um
novo interpretador de comandos (Shell).

Exploit
O termo Exploit, que em portugus significa literalmente, explorar. No mundo virtual
usado comumente para referir-se a pequenos cdigos de programas desenvolvidos
especialmente para explorarem falhas introduzidas em aplicativos por erros involuntrios de
programao.
Podem ser preparados para atacar um sistema local ou remotamente, variam muito
quanto sua forma e poder de ataque. Pelo fato de serem peas de cdigo especialmente
preparadas para explorarem falhas muito especficas, geralmente h um diferente Exploit para
cada tipo de aplicativo alvo, para cada tipo de falha ou para cada tipo de sistema operacional.
Exploits que trabalham tentando fazer uma explorao de estouro de pilha, geralmente,
obtm dois resultados, ou o travamento da mquina, ou a escalada de privilgios, caso o
Exploit tenha sido devidamente codificado e o cdigo malicioso injetado e executado atravs
do mesmo.
Tipos de ataque
Os tipos de ataque baseados em estouro de pilha acontecem quando, o atacante atravs
de um Exploit, estoura a capacidade de algum buffer e modifica o fluxo de execuo do
10

processo, possibilitando a execuo de cdigos arbitrrios previamente injetados em alguma

regio, geralmente no prprio buffer estourado.
O princpio estourar o buffer e sobrescrever parte da pilha, alterar o valor das
variveis locais, valores dos parmetros e/ou endereo de retorno da pilha. Alterando o
endereo de retorno para que ele aponte para a rea em que o cdigo a ser executado
encontra-se armazenado (cdigo malicioso dentro do prprio buffer estourado ou at algum
trecho de cdigo presente no programa vulnervel).
Stack Overflow
Um processador constitudo por alguns registradores que servem para inserir e retirar
pequenos dados que ficam armazenados para possveis operaes. Porm existe uma grande
limitao sobre esses registradores no que refere-se capacidade disponvel de memria
(somente alguns bits). Para aumentar essa capacidade existe a pilha que uma regio da
memria que foi reservada para armazenar alguns dados do processamento de um programa.
O exemplo mais comum de buffer overflow o stack overflow. O termo stack overflow vem
do ingls stack que seria a pilha e overflow que o ato de exceder a capacidade da pilha.

Evitando o estouro de Buffer (Contendo cinco erros comuns e como corrigi-los).

Buffer Overflow (Estouro de memria)
A falha ocorre ao passar uma string com quantidade maior do que o esperado pelo
programa. Ento, j temos em mente que para evitar a falha, basta que verifiquemos a
quantidade de bytes que ser copiado, e caso seja maior, copiaremos apenas a quantidade
suportada pela varivel.
Exemplo 1
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
char buffer[128];
11

if (argc > 1)
strcpy(buffer, argv[1]);
return 0;
}

Temos acima, um programa vulnervel que no est verificando o tamanho da string

que ser copiada para a varivel buffer. Como a verificao no feita, este programa pode
ser explorado facilmente.
A resoluo do problema simples basta que utilizemos uma outra funo que faz a
cpia por tamanho definido por ns.
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
char buffer[128];
if (argc > 1)
memcpy(buffer, argv[1], 127);
return 0;
}

Este o mtodo mais simples de proteo contra Buffer Overflow e 100% garantido
que s ser copiado para a varivel buffer uma string de tamanho at 127 bytes.
Agora, vamos ver um mtodo que resolve o problema de forma diferente ao anterior.
Iremos copiar toda a string informada pelo usurio, mesmo que a quantidade de bytes seja
grande. Precisaremos utilizar alocao dinmica de memria para que o tamanho da memria
reservada para a varivel seja do mesmo tamanho da string. Pra trabalhar com alocao
dinmica, iremos fazer uso de ponteiros, o canivete suo da linguagem C.
12

Exemplo 2
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char** argv)
{
char *buffer;
long long int len;
if (argc > 1)
{
len = strlen(argv[1]) + 1;
buffer = (char*) malloc(sizeof(char) * len--);
memcpy(buffer, argv[1], len);
buffer[len] = '\0';
printf("%d bytes copiados\n", len);
}
return 0;
}

A diferena desse cdigo para o anterior praticamente de 99%, 1% fica para a linha
aonde fizemos a cpia da string. O que fizemos foi obter o tamanho da string que ser copiada
para buffer, alocamos memria com a quantidade obtida, copiamos a string e, por fim,
finalizamos a string (buffer[len] = '\0';).
Este cdigo to seguro quanto o anterior, mas existe um problema com esse ltimo
exemplo. Quem est decidindo a quantidade de memria a reservar o usurio e no o
programador. Isso um grande problema.
13

Para resolvermos isso, basta definirmos um tamanho mximo de bytes que podem ser
copiados.
Exemplo 3
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_BUFFER 1025
int main(int argc, char** argv)
{
char *buffer;
long long int len;
if (argc > 1)
{
len = strlen(argv[1]) + 1;
if (len > MAX_BUFFER)
{
fprintf(stderr, "String muito longa\n.");
exit(-1);
}
buffer = (char*) malloc(sizeof(char) * len--);
memcpy(buffer, argv[1], len);
buffer[len] = '\0';
printf("%d bytes copiados\n", len);
}
return 0;
}
14

Prevenindo o Buffer Pverflow (Cookies)

Cookies como so conhecidos, servem para armazenar informaes que sero
utilizadas em um futuro pouco distante, seja para validao ou para lembrar algo feito
anteriormente pelo usurio.
Vamos aplicar este mtodo em nosso programa para verificarmos se o valor do cookie no foi
sobreposto. Se o valor for outro, significa que um Buffer Overflow est acontecendo.
Exemplo 4
#include <stdio.h>
#include <limits.h>
#include <string.h>
#include <stdlib.h>
#define MAX_BUFFER 10
#define MAX_COOKIE sizeof(int)
int main(int argc, char** argv)
{
char buffer[MAX_BUFFER + MAX_COOKIE];
static int cookie;
int bkp_cookie;
if (argc > 1)
{
srand(time(NULL));
//Gera um cookie
cookie = rand() % INT_MAX;
//Copia o cookie para o final da string
memcpy(&buffer[MAX_BUFFER], &cookie, MAX_COOKIE);
15

//Copia a string (Tamanho 125)

strcpy(buffer, argv[1]);
memcpy(&bkp_cookie, &buffer[MAX_BUFFER], MAX_COOKIE);
if (bkp_cookie != cookie)
{
printf("Buffer overflow!!!\n");
printf("Cookie: %d Backup Cookie: %d\n", cookie, bkp_cookie);
exit(-1);
}
else
{
buffer[MAX_BUFFER] = '\0';
printf("String informada: %s\n", buffer);
}
}
return 0;
}
Exemplo 5
Neste cdigo possvel observar que o mtodo ProcessaParam faz uma chamada a funo
strcpy, que possui um elevado risco quando utilizada, podendo causar uma fragilidade quanto
estouro de pilha. Portanto, caso a string seja maior que 10 caracteres, que o tamanho
mximo do vetor buffer, a varivel arg permitir um ataque baseado em estouro de pilha.
void ProcessaParam (char *arg);
void main (int argc, char *argv[]) {
if (arg > 1){
16

printf("Param: %s\n", argv[1]);

ProcessaParam(argv[1]);
}
}
void ProcessaParam (char *arg)
{ char buffer[10];
strcpy(buffer, arg);
/* PROBLEMA: se a string contida em arg tiver mais que 10 caracteres havera um "buffer
overflow" */ printf(buffer);
}

ETAPA 2
RELATRIO 3 - Utilizando Criptografia
O termo Criptografia surgiu da fuso das palavras gregas "krypts" e "grphein", que
significam "oculto" e "escrever", respectivamente. Trata-se de um conjunto de conceitos e
tcnicas que visa codificar uma informao de forma que somente o emissor e o receptor
possam acess-la, evitando que um intruso consiga interpret-la. Para isso, uma srie de
tcnicas so usadas e muitas outras surgem com o passar do tempo.
Na computao, as tcnicas mais conhecidas envolvem o conceito de chaves, as
chamadas chaves criptogrficas. Trata-se de um conjunto de bits baseado em um determinado
algoritmo capaz de codificar e de decodificar informaes. Se o receptor da mensagem usar
uma chave incompatvel com a chave do emissor, no conseguir extrair a informao.

17

Figura 4 - Requisitos de segurana em documento eletrnico

Autenticao: garantia de identificao das pessoas ou organizaes envolvidas na

comunicao e na autoria do documento eletrnico;

Integridade: garantia de que o contedo de uma mensagem ou resultado de uma consulta

no ser alterado durante seu trfego e armazenagem;

Privacidade (Confidencialidade ou sigilo): garantia de que somente as pessoas ou

organizaes envolvidas na comunicao possam ler e utilizar as informaes
transmitidas de forma eletrnica pela rede;

No-Repdio (No- recusa): garantia que o emissor ou pessoa que executou

determinada transao de forma eletrnica, no poder, posteriormente negar sua
autoria;
18

ncora Temporal (Temporalidade ou irretroatividade): certeza e imparcialidade de

quando o documento eletrnico foi criado e da relao de precedncia com outros.
Os primeiros mtodos criptogrficos existentes usavam apenas um algoritmo de

codificao. Assim, bastava que o receptor da informao conhecesse esse algoritmo para
poder extra-la. No entanto, se um intruso tivesse posse desse algoritmo, tambm poderia
efetuar um processo de decifragem, caso capturasse os dados criptografados. H ainda outro
problema: imagine que a pessoa A tivesse que enviar uma informao criptografada pessoa
B. Esta ltima teria que conhecer o algoritmo usado. Imagine agora que uma pessoa C
tambm precisasse receber uma informao da pessoa A, porm a pessoa C no poderia
descobrir qual a informao a ser enviada pessoa B. Se a pessoa C capturasse a
informao enviada pessoa B, tambm conseguiria decifr-la, pois quando a pessoa A
enviou sua informao, a pessoa C tambm teve que conhecer o algoritmo usado. Para a
pessoa A evitar esse problema, a nica soluo seria utilizar um algoritmo diferente para cada
receptor.
Com o uso de chaves, um emissor pode usar o mesmo algoritmo (o mesmo mtodo)
para vrios receptores. Basta que cada um receba uma chave diferente. Alm disso, caso um
receptor perca ou exponha determinada chave, possvel troc-la, mantendo-se o mesmo
algoritmo.
Chave de 64 bits, chave de 128 bits so valores que expressam o tamanho de uma
determinada chave (senhas). Quanto mais bits forem utilizados, mais segura ser a
criptografia. Explica-se: caso um algoritmo use chaves de 8 bits, por exemplo, apenas 256
chaves podero ser usadas na decodificao, pois 2 elevado a 8 256. Isso deixa claro que 8
bits inseguro, pois at uma pessoa capaz de gerar as 256 combinaes (embora demore),
imagine ento um computador! Porm, se forem usados 128 ou mais bits para chaves (faa 2
elevado a 128 para ver o que acontece), teremos uma quantidade extremamente grande de
combinaes, deixando a informao criptografada bem mais segura.
Chave Simtrica
Esse um tipo de chave mais simples, onde o emissor e o receptor fazem uso da
mesma chave, isto , uma nica chave usada na codificao e na decodificao da

19

informao. Existem vrios algoritmos que usam chaves simtricas, como o DES, o IDEA, e
o RC:

DES (Data Encryption Standard): criado pela IBM em 1977, faz uso de chaves de
56 bits. Isso corresponde a 72 quatrilhes de combinaes. um valor absurdamente
alto, mas no para um computador potente. Em 1997, esse algoritmo foi quebrado por
tcnicas de "fora bruta" (tentativa e erro) em um desafio promovido na internet;

IDEA (International Data Encryption Algorithm): criado em 1991 por James

Massey e Xuejia Lai, o IDEA um algoritmo que faz uso de chaves de 128 bits e que
tem uma estrutura semelhante ao DES. Sua implementao em software mais fcil
do que a implementao deste ltimo;

RC (Ron's Code ou Rivest Cipher): criado por Ron Rivest na empresa RSA Data
Security, esse algoritmo muito utilizado em e-mails e faz uso de chaves que vo de 8
a 1024 bits. Possui vrias verses: RC2, RC4, RC5 e RC6. Essencialmente, cada
verso difere da outra por trabalhar com chaves maiores.
H ainda outros algoritmos conhecidos, como o AES (Advanced Encryption Standard)

- que baseado no DES - , o 3DES, o Twofish e sua variante Blowfish, entre outros.
O uso de chaves simtricas tem algumas desvantagens, fazendo com que sua utilizao
no seja adequada em situaes onde a informao muito valiosa. Para comear,
necessrio usar uma grande quantidade de chaves caso muitas pessoas ou entidades estejam
envolvidas. Ainda, h o fato de que tanto o emissor quanto o receptor precisam conhecer a
mesma chave. A transmisso dessa chave de um para o outro pode no ser to segura e cair
em "mos erradas".
Chave Assimtrica
Tambm conhecida como "chave pblica", a chave assimtrica trabalha com duas
chaves: uma denominada privada e outra denominada pblica. Neste mtodo, um emissor
deve criar uma chave de codificao e envi-la ao receptor. Essa a chave pblica. Uma outra
chave deve ser criada para a decodificao. Esta, a chave privada, secreta.
Para melhor compreenso, imagine o seguinte: O InfoWester criou uma chave pblica
e a enviou a vrios outros sites. Quando qualquer desses sites quiser enviar uma informao
20

criptografada ao InfoWester dever utilizar a chave pblica deste. Quando o InfoWester

receber essa informao, apenas ser possvel extra-la com o uso da chave privada, que s o
InfoWester tem. Caso o InfoWester queira enviar uma informao criptografada a outro site,
dever obter uma chave pblica fornecida por este.

Figura 5 - Chave Assimtrica

Entre os algoritmos que usam chaves assimtricas, tm-se o RSA (o mais conhecido) e o
Diffie-Hellman:

RSA (Rivest, Shamir and Adleman): criado em 1977 por Ron Rivest, Adi Shamir e
Len Adleman nos laboratrios do MIT (Massachusetts Institute of Technology), um
dos algoritmos de chave assimtrica mais usados. Nele, nmeros primos (nmero
primo aquele que s pode ser dividido por 1 e por ele mesmo) so utilizados da
seguinte forma: dois nmeros primos so multiplicados para se obter um terceiro
valor. Porm, descobrir os dois primeiros nmeros a partir do terceiro (ou seja, fazer
uma fatorao) muito trabalhoso. Se dois nmeros primos grandes (realmente
grandes) forem usados na multiplicao, ser necessrio usar muito processamento
21

para descobr-los, tornando essa tarefa praticamente invivel. Basicamente, a chave

privada no RSA so os nmeros multiplicados e a chave pblica o valor obtido;

ElGamal: criado por Taher ElGamal, esse algoritmo faz uso de um problema
matemtico conhecido por "logaritmo discreto" para se tornar seguro. Sua utilizao
freqente em Assinaturas Digitais. Existem ainda outros algoritmos, como o DSA
(Digital Signature Algorithm), o Schnorr (praticamente usado apenas em assinaturas
digitais) e Diffie-Hellman.

Certificao Digital
Um recurso conhecido por certificao digital muito utilizado com chaves pblicas.
Trata-se de um meio que permite, por exemplo, provar que um certo documento eletrnico foi
mesmo emitido por uma determinada entidade ou pessoa. O receptor da informao usar a
chave pblica fornecida pelo emissor para se certificar da origem. Alm disso, a chave fica
integrada ao documento de forma que qualquer alterao por terceiros imediatamente a
invalide.

22

Figura 06 - Certificao Digital

PGP - Pretty Good Privacy
PGP a sigla para Pretty Good Privacy. Trata-se de um software de criptografia criado
por Philip Zimmermman em 1991. A inteno de Zimmermman foi a de ajudar na defesa da
liberdade individual nos Estados Unidos e no mundo inteiro, uma vez que ele percebeu que o
uso do computador seria algo cada vez maior e que o direito privacidade deveria ser
mantido nesse meio. Por ser disponibilizado de forma gratuita, o PGP acabou se tornando uns
dos meios de criptografia mais conhecidos, principalmente na troca de e-mails.
No PGP, chaves assimtricas so usadas. Alm disso, para reforar a segurana, o
software pode realizar um segundo tipo de criptografia atravs de um mtodo conhecido como
"chave de sesso" que, na verdade, um tipo de chave simtrica.
Um fato curioso a ser citado que Zimmermman foi alvo de uma investigao policial
que durou quase 3 anos. Isso porque a legislao americana probe a exportao de software
criptogrfico sem expressa autorizao do governo. Porm, na investigao, ficou provado
que algum sem identificao e no o prprio Zimmermman que distribuiu o programa pela
internet. O PGP ento passou a ser enviado para outros pases atravs de uma brecha na
legislao americana: novas verses tiveram seu cdigo-fonte publicado em livros. Estes so
exportados de forma legal, pois a lei americana probe a exportao do software, mas o cdigo
impresso no considerado programa.
Criptografia s pode ser considerada como tal se 4 princpios bsicos forem seguidos e
oferecidos: confidencialidade, autenticao, integridade da informao e no repudiabilidade
(o remetente no pode negar o envio da informao). por isso que a criptografia um
recurso to importante na transmisso de informaes pela internet e, mesmo assim, no
capaz de garantir 100% de segurana, pois sempre existe algum que consegue desenvolver
uma maneira de "quebrar" uma codificao.

Criptografia em PHP nos formatos: MD5, SHA1 e BASE64

Hoje criptografar dados to importante que passou a ser bsico, uma prtica que
em determinados aspectos essencial. Prticas para derrubarem sistemas de criptografia so
23

exploradas a todo o tempo, mas mesmo assim temos que utilizar do maior potencial de
segurana que estiver ao nosso alcance de forma a tornarmos a nossa aplicao a mais segura
possvel. No sendo suficiente ainda podemos contar com certa ajuda de alguns scripts, que
impedem a ao de ataques como SQL Injection.
Sero usados trs mtodos de Criptografia em PHP, que so Base64, MD5 e
SHA1,esses mtodos alm de diferirem na maneira que so criptografados, ou seja, no script
Criptografador, se diferem tambm nos aspetos referentes possibilidade de retornar a
varivel criptografada para a varivel real.

MD5 (Digerir mensagem)

Ele produz uma sada de 128 bits ou 16 Bytes.O md5 gera uma string alfa-numrica de
32 caracteres, no importa se voc est gerando o md5 de duas letras ou de um texto de 20
pargrafos o md5 gerado sempre vai ter 32 caracteres.
Voc pode usar o md5 na hora de salvar um dado sigiloso (senhas) o banco Com
isso, ningum tem acesso senha original do cliente. Depois s comparar o md5 do que foi
digitado no campo senha (na hora do login) com o que est armazenado no banco, se bater,
est tudo certo.
Infelizmente o Md5 tem um problema Voc pode, com muita dificuldade (preste
ateno: muita dificuldade), gerar dois md5 iguais. Duas strings diferentes que acabem como
um mesmo md5. Isso rarssimo, mas pode acontecer.
Pra usar o md5 no PHP s usar da seguinte forma:
$string = 'O rato roeu a roupa do rei de Roma';
$codificada = md5($string);
echo "Resultado da codificao usando md5: " . $codificada;
//54cf74d1acdb4037ab956c269b63c8ac

SHA1 (Secure Hash Algorithm - Algoritmo de Resumo Seguro)

24

Este algoritmo recebe como entrada um documento qualquer sob a forma digital com
um tamanho de at 2 elevado a 64 bits (18.446.744.073.709.551.616 bits) ou
2.305.843.009.213.693.952 "Bytes" ou caracteres, e gera como sada um resumo de 160 bits
ou 20 Bytes. Ele um pouco mais lento que o MD5, mas em compensao mais difcil de ser
quebrado.
A outra criptografia de mo nica o Sha1. Ele praticamente idntico ao md5, s
que tem 160 bits, o que acaba criando uma string-resultado maior: 40 caracteres alfanumricos. Outro ponto do Sha1 que, por ser 160 bits e gerar uma cadeia de caracteres
maior, uma coliso (encontrar duas strings que, criptografadas, sejam a mesma coisa) bem
mais rara que numa chave de 128bits.
Usar o Sha1 no PHP exatamente a mesma coisa que o md5, s que mudando o nome
da funo:
$string = 'O rato roeu a roupa do rei de Roma';
$codificada = sha1($string);
echo "Resultado da codificao usando sha1: " . $codificada;
// b186b709f7cf5a1d98d413379a66e511df8d59a4
A funo mais usada nesta famlia, a Sha1, usada numa grande variedade de
aplicaes e protocolos de segurana, incluindo TLS, SSL, PGP, SSH, S/MIME e IPSec.
SHA-1 foi considerado o sucessor do MD5. mais segura que o MD5.

BASE64
Base64 no um hash, de 2 vias. Codificao de dados para a base 64 uma
maneira conveniente de transferir os dados para diferentes aplicativos ou bancos de dados .
Base64 e um mtodo para codificao dos dados para transferncia na Internet. No
unidirecional, e sim mo dupla, o que possibilita a criao de duas funes: uma para
codificar (encode) e outra para descodificar (decode) , ou seja usar uma segunda
funo(decriptao) voc pode descobrir a string original de uma string codificada.
25

Para usar ela no PHP voc tem as duas formas:

<?php
$string = 'O rato roeu a roupa do rei de Roma';
$codificada = base64_encode ($string);
echo "Resultado da codificao usando base64: "
$codificada;
// TyByYXRvIHJldSBhIHJvcGEgZG8gcmVpIGRlIFJvbWE=
echo "<br /><br />";
<?php
$original = base64_decode ($codificada);
echo "Resultado da decodificao usando base64: "
$original;
// O rato roeu a roupa do rei de Roma
// Note que $original vai ser idntica a $string

BASE64 em JAVA
import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;
import java.io.IOException;
public class TesteBase64{
public static void main(String args[]){
BASE64Encoder encoder = new BASE64Encoder();
String code = encoder.encodeBuffer("Teste Base64".getBytes());
//Vai imprimir "Teste Base64 -(codificado)- VGVzdGUgQmFzZTY0"

26

.System.out.println("Teste Base64 -(codificado)- " + code);

BASE64Decoder decoder = new BASE64Decoder();
.try{
byte[] decoded = decoder.decodeBuffer("VGVzdGUgQmFzZTY0");
//Vai imprimir "VGVzdGUgQmFzZTY0 -(decodificado)- Teste Base64"
System.out.println("VGVzdGUgQmFzZTY0 -(decodificado)- " + newString(decoded));
}catch(IOException ex){
}
}
}

BASE64 em ASP
base64String ="base64 code goes here - Wont add it as its huge amount of text"
Set tmpDoc = Server.CreateObject("MSXML2.DomDocument")
Set nodeB64 = tmpDoc.CreateElement("b64")
nodeB64.DataType = "bin.base64" ' stores binary as base64 string
nodeB64.Text = Mid(base64String, InStr(base64String, ",") + 1) ' append data text (all data
after the comma)
vehicleAuditName= "Audit1"
With Response
.Clear
.ContentType = "image/png"
.AddHeader "Content-Disposition", "attachment; filename=" & vehicleAuditName & ".png"
.BinaryWrite nodeB64.NodeTypedValue 'get bytes and write
.end
End With
27

MD5 no Java

import java.math.BigInteger;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import javax.swing.JOptionPane;
public class principal {
//Funo para criar hash da senha informada
public static String md5(String senha){
String sen = "";
MessageDigest md = null;
try {
md = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
BigInteger hash = new BigInteger(1, md.digest(senha.getBytes()));
sen = hash.toString(16);
return sen;
public static void main(String[] args) {
String senha = JOptionPane.showInputDialog("Digite uma senha:");
String saida = "Entrada: " + senha + "\nSenha com MD5: " + md5(senha);
JOptionPane.showConfirmDialog(null,saida, "Resultado",
JOptionPane.CLOSED_OPTION);
}
}

28

MD5 em ASP
<!--#include file="md5.asp"-->
<%
Dim sSeed
Dim sValidEmailAddress
Dim sValidPassword
Dim sValidHash
Dim sEmailAddress
Dim sPassword
Dim sHash

sValidEmailAddress = "user@host.com.br"
sValidPassword = "senha123"
sSeed = Session("auth_seed")
sValidHash = MD5(sSeed & sValidPassword)
sEmailAddress = Request.Form("email")
sPassword = Request.Form("password")
sHash = Request.Form("hash")
%>
<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>
<BODY>
<CENTER>
<H2>Secure Login</H2>
<%
If sSeed = "" Then
29

Response.Write "Sua sesso expirou. Voc tem esperado por muito tempo, ou seu navegador
no suporta cookies."
ElseIf sEmailAddress = "" Then
Response.Write "Voc no introduzir um endereo de e-mail."
ElseIf LCase(sEmailAddress) <> LCase(sValidEmailAddress) Then
Response.Write "Voc digitou um endereo de e-mail no registrado."
ElseIf sHash = "" And sPassword <> "" Then
If sPassword <> sValidPassword Then
Response.Write "A senha digitada no incorreta. (Inseguro)"
Else
Response.Write "Login feito com sucesso!<br>Click <a href=""seguro.asp"">aqui</a> para
continuar.<br>Click <a href=""logoff.asp"">aqui</a> para logout."
' Store credentials in the Session object
Session("autent") = "true"
Session("auth_emailaddress") = sEmailAddress
End If
ElseIf sHash <> "" Then
If sHash <> sValidHash Then
Response.Write "A senha digitada esta incorreta."
Else
Response.Write "Login feito com sucesso!<br>Click <a href=""seguro.asp"">aqui</a> para
continuar.<br>Click <a href=""logoff.asp"">aqui</a> para logout."
Session("autent") = "true"
Session("auth_emailaddress") = sEmailAddress
End If
Else
Response.Write "Ocorreu um erro."
End If
%>
<BR><BR>
30

<A HREF="login.asp">Voltar</A>
</CENTER>
</BODY>
</HTML>

SHA1 em Java
package main;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
public class HashTextTest {
/**
* @param args
* @throws NoSuchAlgorithmException
*/
public static void main(String[] args) throws NoSuchAlgorithmException {
System.out.println(sha1("test string to sha1"));
}

static String sha1(String input) throws NoSuchAlgorithmException {

MessageDigest mDigest = MessageDigest.getInstance("SHA1");
byte[] result = mDigest.digest(input.getBytes());
StringBuffer sb = new StringBuffer();
for (int i = 0; i < result.length; i++) {
sb.append(Integer.toString((result[i] & 0xff) + 0x100, 16).substring(1));
}
return sb.toString();
}
}
31

SHA1 em ASP
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<%
' This CreateObject statement uses the new single-DLL ActiveX for v9.5.0
set crypt = Server.CreateObject("Chilkat_9_5_0.Crypt2")

' Any string argument automatically begins the 30-day trial.

success = crypt.UnlockComponent("30-day trial")
If (success <> 1) Then
Response.Write "<pre>" & Server.HTMLEncode( crypt.LastErrorText) & "</pre>"
End If

Usando MD5
crypt.HashAlgorithm = "md5"
hash = crypt.HashStringENC(s)
Response.Write "<pre>" & Server.HTMLEncode( "MD5: " & hash) & "</pre>"

32

</body>
</html

ETAPA 3
RELATRIO 4 - EVITANDO ATAQUES SQL INJECTION
A SQL - Structured Query Language - largamente usada para interagir com banco de
dados relacionais. Se voc considerar que 90% das aplicaes utilizam banco de dados com
suporte a SQL vai concluir que o uso da SQL quase uma unanimidade por ser prtica , fcil
e porttil.
Ao colocar sua aplicao na Web voc a esta expondo a um acesso mais amplo e
indiscriminado. Afinal qualquer um que tenha acesso a url do site ter acesso a sua aplicao e
aos dados que ela disponibiliza. Pensando na segurana de suas informaes as empresas
investem pesado em firewalls, certificao digital e outros recursos, com o objetivo de se
proteger de invasores.
Para que o controlar o acesso as informaes normalmente restringe-se o acesso aos
usurios cadastrados usando um nome e senha para identificao estes dados so colhidos
atravs de um formulrio de login e so ento verificados com as informaes armazenadas
em um banco de dados dos usurios cadastrados; se estiverem corretas o acesso permitido
caso contrrio o acesso negado.
assim que funciona o home banking na internet e uma infinidade de outras
aplicaes web na qual o acesso restrito.
Voc pode ter o aparato mais moderno em termos de tecnologia de segurana
protegendo o seu site de um ataque hacker e nem se dar conta de que a vulnerabilidade da sua
aplicao esta ali naquele formulrio de login. Ele pode ser a porta de entrada para
ataques maliciosos atravs da injeo de SQL.
A injeo SQL ocorre quando um invasor consegue inserir comandos SQL na
instruo SQL que voc usa no seu script de modo a burlar a restrio e ter acesso ou
danificar as informaes armazenadas no seu banco de dados.
Como ocorre a injeo SQL
Um exemplo de SQL Injection, formulrio de login :
form name="frmLogin"
action="login.asp"
method="post">
Nome : <input type="text" name="nomeUsuario">
Senha: <input type="text" name="senhaUsuario">
<input type="Enviar">
</form>

33

Geralmente quando o usurio clicar no boto - Enviar - o script login.asp ser

executado para efetuar a validao dos dados informados. Abaixo temos um script tpico para
um arquivo de validao de informaes:
<%
dim nomeUsuario, senhaUsuario, consulta
dim conn, rS
nomeUsuario = Request.Form("nomeUsuario")
senhaUsuario = Request.Form("senhaUsuario")
set conn = server.createObject("ADODB.Connection")
set rs = server.createObject("ADODB.Recordset")
consulta = "select count(*) from usuarios where nomeUsuario='" & nomeUsuario & "' and
senhaUsuario='" & senhaUsuario & "'"
conn.Open "Provider=SQLOLEDB; Data Source=(local);Initial Catalog=myDB; User Id=sa;
senhaUsuario="
rs.activeConnection = conn
rs.open consulta
if not rs.eof then
response.write "Acesso Concedido"
else
response.write "Acesso Negado"
end if
%>
Vamos analisar o que ocorre quando um usurio tenta se autenticar. Vamos supor que
ele usurio cadastrado com nome 'Maria' e senha 'abcdef'' , ao informar o nome e a senha e
clicar no boto Enviar o script do arquivo login.asp ser executado. Vamos ver como ficou a
instruo SQL montada neste caso :
select count(*) from usuarios where nomeUsuario='Maria' and senhaUsuario='abcdef '
Neste caso o usurio 'Maria', senha 'abcdef' ser autenticado e ter acesso ao sistema,
se voc usa este tipo de instruo SQL nada esta bem pois o texto final da consulta SQL
depende inteiramente do contedo das variveis , e , se o contedo destas variveis no for
validado e tratado o texto final concatenado poder ser um SQL adulterado atravs de uma
injeo SQL.
Se algum vier a invadir o seu sistema com certeza far um ataque e tentar uma
injeo SQL, e vai comear verificando se voc esta tratando o apstrofe (aspa simples: ').
34

Se voc no sabe a presena de um caractere de apstrofe (') no contedo de uma

varivel concatenada no SQL, ela usada para delimitar strings de texto. Ento suponha que ele
digite os seguintes dados nos campos nome e senha:
nome = tes'te
senha =
Se voc no tratar o apstrofe vai ocorrer um erro de SQL (incorrect Sintax) e vendo
isto o hacker ficar mais animado. Suponha ento que a seguir ele digite os seguintes dados
nome = ' ; drop table users-senha =
Este comando ir excluir a tabela users (se ela existir). E se voc pensa que muito
difcil o hacker adivinhar o nome da sua tabela vou mostrar mais abaixo que ele pode fazer
isto de uma maneira simples. Isto possvel pois o caractere (;) indica o fim de uma consulta
e o comeo de outra em T-SQL , e , o caractere (--) no final da linha faz com que o script ASP
seja executada sem erro.
Continuando o ataque , ele pode tambm informar o seguinte :
nome = admin
senha = ' or 1=1-veja como vai ficar a consulta SQL montada:
select count(*) from usuarios where nomeUsuario='admin' and senhaUsuario='' or 1=1--'
Aqui a consulta ir verificar se o nome do usurio admin e se senha vazio ou 1 for
igual a 1 ( o que verdade) ; bingo, se existir um usurio admin ele entrou no seu sistema.
Ele pode tambm tentar o seguinte :
nome = ' or 1=1-senha =
a consulta SQL montada ser :
select count(*) from usuarios where nomeUsuario='' or 1=1 --' and senhaUsuario=''
e bingo , ele burlou o seu sistema.
O hacker pode tambm tentar o seguinte :
nome = ' OR "='
senha = ' OR "='
e a consulta SQL montada ser :
select count(*) from usuarios where nomeUsuario='' OR "=" AND senhaUsuario='' OR "="
A consulta agora esta fazendo a comparao : OR "=" que sempre verdadeira. Bingo
ele entrou no seu site.
Para saber o nome das tabelas e campos o hacker pode fazer o seguinte :
nome = ' having 1=1-35

senha =
isto pode causar o seguinte erro:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'[Microsoft] [ODBC
SQL Server Driver] [SQL Server] Column 'usuarios.codigo' is invalid in the select list because
it is not contained in an aggregate function and there is no GROUP BYclause./login.asp , line
28
e bingo , o hacker agora sabe que o nome da tabela usurios e o nome do campo relacionado
no formulrio como nome cdigo ento , o que voc acha que ele vai fazer ? Fazer a mesma
coisa para o campo senha e ento ele vai saber o nome da tabela e dos campos relacionados ao
formulrio. Imagine o estrago que ele no ser capaz de fazer agora...
Pensa que ele pode ficar somente nisto. J conhecendo o nome da tabela e das colunas se o
hacker quiser saber o tipo de dados do campo ele pode fazer o seguinte :
nome = ' UNION SELECT SUM(nomeUsuario) FROM usuarios-- senha =
Como o SQL Server vai tentar aplicar a clusula SUM antes de determinar se o
nmero dos campos nas duas colunas igual. Ao tentar fazer um SUM em um campo texto o
sistema pode emitir a seguinte mensagem de erro:
Microsoft OLE DB Provider for ODBC Drivers error '80040e7'[Microsoft] [ODBC
SQL Server Driver] [SQL Server] The Sum or average aggregate operation cannot take a
varchar data type as na argument.
/login.asp , line 109 e bingo de novo , ele agora sabe o tipo de dado do campo nomeUsuario.
Agora sabe o que ele vai fazer ? Vai inserir um usurio com nome senha para se logar , assim:
nome = ' ; INSERT INTO usuarios VALUES('hacker','111111')-senha =
E bingo , ele vai se logar como hacker e senha 111111.

Como evitar uma ataque de injeo SQL

Estabelea uma poltica de segurana rgida e criteriosa limitando o acesso dos

seus usurios. Isto quer dizer que voc deve dar somente os poderes
necessrios aos seus usurios. No de acesso de escrita a tabelas e d somente
acesso as tabelas que o usurio vai precisar;

Faa a validao da entrada de dados no formulrio e no permita os

caracteres invlidos como : (') , (--) e (;) nem de palavras maliciosas
como insert , drop , delete, xp . Abaixo algumas funes que voc pode usar:
Substituindo o apstrofe(') pelo duplo apstrofe ('')
36

<%
Function ExpurgaApostrofe(texto)
ExpurgaApostrofe = replace( texto , "'" , "''")
End function
%> |

Substituindo os caracteres e palavras maliciosas por vazio("").

<%
Function LimpaLixo( input )
dim lixo
dim textoOK
lixo = array ( "select" , "drop" , ";" , "--" , "insert" , "delete" , "xp_")
textoOK = input
for i = 0 to uBound(lixo)
textoOK = replace( textoOK , lixo(i) , "")
next LimpaLixo = textoOK
end Function
%> |
Rejeitando dados maliciosos:
<%
Function ValidaDados( input ) lixo = array ( "select" , "insert" , "update" ,
"delete" , "drop" , "--" , "'")
ValidaDados = true
for i = lBound (lixo) to ubound(lixo)
if ( instr(1 , input , lixo(i) , vbtextcompare ) <> 0 ) then
ValidaDados = False
exit function}
end if
next
end function
%> |

37

Figura 7 - Caracteres de entrada que devem ser evitados

Limite a entrada de texto para o usurio no formulrio de entrada de dados. Se

o campo nome deve ter somente 10 caracteres restrinja a isto a entrada de
dados no formulrio, o mesmo vale para a senha;

Faa o tratamento adequado de erros no permitindo que mensagens de erros

exponham informaes sobre a estrutura dos seus dados;
Faa um log para auditoria dos erros ocorridos e das operaes mais
importantes da aplicao;

Sempre valide entrada de usurio testando tipo, comprimento, formato e

intervalo;

Nunca construa instrues SQL ou Transact-SQL diretamente da entrada do

usurio;

Use procedimentos armazenados (stored Procedures) para validar entrada de

usurio;

Nunca concatene entrada de usurio que no seja validada. A concatenao de

38

cadeia de caracteres o ponto principal de entrada de injeo de script;

Nunca concatene entrada de usurio que no seja validada. A concatenao de

cadeia de caracteres o ponto principal de entrada de injeo de script;

Teste o contedo de variveis de cadeia de caracteres e s aceite valores

esperados.

Rejeite entradas que contenham dados binrios, seqncias de escape e caracteres de

comentrio. Isso pode ajudar a impedir injeo de script e proteger contra exploraes de
excesso de buffer.

39

ETAPA 4
RELATRIO 5 - Evitando ataques RCP e DDOS Ataques DoS (Denial of Service) e
DDoS (Distributed DoS)
De acordo com a definio do CERT (Computer Emergency Response Team), os
ataques DoS (Denial of Service), tambm denominados Ataques de Negao de Servios,
consistem em tentativas de impedir usurios legtimos de utilizarem um determinado servio
de um computador. Para isso, so usadas tcnicas que podem: sobrecarregar uma rede a tal
ponto em que os verdadeiros usurios dela no consigam us-la; derrubar uma conexo entre
dois ou mais computadores; fazer tantas requisies a um site at que este no consiga mais
ser acessado; negar acesso a um sistema ou a determinados usurios.
Os ataques do tipo DoS mais comuns podem ser feitos devido a algumas
caractersticas do protocolo TCP/IP (Transmission Control Protocol / Internet Protocol), sendo
possvel ocorrer em qualquer computador que o utilize. Uma das formas de ataque mais
conhecidas a SYN Flooding, onde um computador tenta estabelecer uma conexo com um
servidor atravs de um sinal do TCP conhecido por SYN (Synchronize). Se o servidor atender
o pedido de conexo, enviar ao computador solicitante um sinal chamado ACK
(Acknowledgement). O problema que em ataques desse tipo, o servidor no consegue
responder a todas as solicitaes e ento passa a recusar novos pedidos.
Outra forma de ataque comum o UPD Packet Storm, onde um computador faz
solicitaes constantes para que uma mquina remota envie pacotes de respostas ao
solicitante. A mquina fica to sobrecarregada que no consegue executar suas funes.

Ataques DDoS
O DDoS, sigla para Distributed Denial of Service, um ataque DoS ampliado, ou seja,
que utiliza at milhares de computadores para atacar uma determinada mquina. Esse um
dos tipos mais eficazes de ataques e j prejudicou sites conhecidos, tais como os da CNN,
Amazon, Yahoo, Microsoft e eBay.
Para que os ataques do tipo DDoS sejam bem-sucedidos, necessrio que se tenha um
nmero grande de computadores para fazerem parte do ataque. Uma das melhores formas
encontradas para se ter tantas mquinas, foi inserir programas de ataque DDoS em vrus ou
em softwares maliciosos.
Em um primeiro momento, os hackers que criavam ataques DDoS tentavam
"escravizar" computadores que agiam como servidores na internet. Com o aumento na
velocidade de acesso internet, passou-se a existir interesse nos computadores dos usurios
comuns com acesso banda larga, j que estes representam um nmero muito grande de
mquinas na internet.
40

Para atingir a massa, isto , a enorme quantidade de computadores conectados

internet, vrus foram e so criados com a inteno de disseminar pequenos programas para
ataques DoS. Assim, quando um vrus com tal poder contamina um computador, este fica
disponvel para fazer parte de um ataque DoS e o usurio dificilmente fica sabendo que sua
mquina est sendo utilizado para tais fins. Como a quantidade de computadores que
participam do ataque grande, praticamente impossvel saber exatamente qual a mquina
principal do ataque.
Quando o computador de um internauta comum infectado com um vrus com
funes para ataques DoS, este computador passa a ser chamado de zumbi. Aps a
contaminao, os zumbis entram em contato com mquinas chamadas de mestres, que por sua
vez recebem orientaes (quando, em qual site/computador, tipo de ataque, entre outros) de
um computador chamado atacante. Aps receberem as ordens, os computadores mestres as
repassam aos computadores zumbis, que efetivamente executam o ataque. Um computador
mestre pode ter sob sua responsabilidade at milhares de computadores. Repare que nestes
casos, as tarefas de ataque DoS so distribudas a um "exrcito" de mquinas escravizadas.
Da que surgiu o nome Distributed Denial of Service.
Dentre as estratgias recomendadas pode-se considerar as seguintes, incrementar a
segurana do host, sendo que a caracterstica principal deste ataque a formao de uma rede
de mquinas comprometidas atuando como masters e agentes, recomenda-se fortemente
aumentar o nvel de segurana de suas mquinas, isto dificulta a formao da rede do ataque.

Figura 8 - Ataque DDOS

Instalar patches
41

Sistemas usados por intrusos para executar ataques so comumente comprometidos via
vulnerabilidades conhecidas. Assim, recomenda-se manter seus sistemas atualizados
aplicando os patches quando necessrio.
Aplicar filtros "anti-spoofing", durante os ataques, os intrusos tentam esconder seus
endereos IP verdadeiros usando o mecanismo de spoofing, que basicamente consiste em
forjar o endereo origem, o que dificulta a identificao da origem do ataque.

Limitar banda por tipo de trfego

Alguns roteadores permitem limitar a banda consumida por tipo de trfego na rede,
nos roteadores Cisco, por exemplo, isto possvel usando CAR (Commited Access Rate). No
caso especfico de um ataque DDoS que lana um flood de pacotes ICMP ou TCP SYN, por
exemplo, voc pode configurar o sistema para limitar a banda que poder ser consumida por
esse tipo de pacotes.
Prevenir que sua rede seja usada como "amplificadora",sendo que algumas das
ferramentas podem lanar ataques smurf (ou fraggle), que utilizam o mecanismo de envio de
pacotes a endereos de broadcasting, recomenda-se que sejam implementadas em todas as
interfaces dos roteadores diretivas que previnam o recebimento de pacotes endereados a tais
endereos, isto evitar que sua rede seja usada como "amplificadora" e estabelecer um plano
de contingncia.
Partindo da premissa que no existe sistema conectado Internet totalmente seguro,
surge que sejam considerados os efeitos da eventual indisponibilidade de algum dos sistemas
e se tenha um plano de contingncia apropriado, se necessrio for.
Um prvio planejamento e coordenao so crticos para garantir uma resposta
adequada no momento que o ataque est acontecendo: tempo crucial! Este planejamento
dever incluir necessariamente procedimentos de reao conjunta com o seu provedor
de backbone.
Testes de Segurana e Instalao de Software Seguros
Nos processos formais de desenvolvimento a disciplina de Teste bem definida.
Existe atualmente at certificaes relacionadas exclusivamente com teste de software. O
teste, nos projetos de software livre, realizado pelos prprios desenvolvedores e por usurios
entusiasmados. Mais de um tero do custo poderia ser evitado com melhorias
na infraestrutura do teste de software.
Esta uma fora muito importante para os projetos de software livre, e se bem
utilizada e orientada pode encontrar problemas de segurana antes do lanamento de uma
nova verso facilmente. Basicamente, tudo o que precisa ser feito explicitamente orientar
todos os usurios e desenvolvedores testando uma verso alfa ou beta que realizem testes
especficos de segurana.
Estes testes podem ser automatizados tambm por ferramentas j existentes
como scanners de vulnerabilidade para aplicaes web, geradores de entrada aleatrias e
Estes testes podem ser distribudos entre grupos de usurios interessados e o processo
vai rapidamente gerar frutos.
42

A anlise de risco e as rvores de ataque podem ser utilizados como guias das partes
que precisam ser mais testadas por segurana, e como o ciclo de desenvolvimento em
software livre contnuo o sistema deve ser realimentado com informaes de
vulnerabilidades encontradas e corrigidas nas verses passadas, testando novamente as
correes para garantir um aproveitamento total do teste.
Durante a fase de implementao a equipe de projeto codifica, testa e integra todos os
mdulos do software, nesta fase muito importante ficar atento as falhas de segurana, para
evitar possveis vulnerabilidades. Para garantir uma vida segura para o software
necessrio seguir um ciclo durante a sua implementao, tal ciclo composto por 4 variveis:

Empregar padres de codificao e teste;

Empregar ferramentas de teste de segurana incluindo fuzzing;
Empregar ferramentas de anlise esttica de cdigo;
Revisar o cdigo.

Bibliografia
43

http://informaticainteligente.blogspot.com.br/2013/08/importancia-do-desenvolvimentode.html
http://datasus.saude.gov.br/noticias/atualizacoes/562-os-resultados-da-pesquisa-nacional-deseguranca-da-informacao-2014-foram-divulgados
http://www.vivaolinux.com.br/artigo/Como-prevenir-o-Buffer-Overflow/
http://www.vivaolinux.com.br/artigo/Como-prevenir-o-Buffer-Overflow/
http://blog.thiagobelem.net/criptografia-no-php-usando-sha512-whirlpool-e-salsa20/
http://www.infowester.com/criptografia.php
http://cliente.estadovirtual.com.br/knowledgebase/69/Como-evitar-ataques-DDoS-em-meuservidor.html

44