Recomendaes de Segurana para Desenvolvimento de Aplicaes Web

ndice
1. INTRODUO.................................................................................................................................3 1.1 1.2 1.3 2 2.1 2.1.1 2.2 2.2.1 2.3 2.3.1 2.4 2.4.1 2.5 2.5.1 2.6 2.6.1 2.7 2.7.1 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 4 CONTROLE DE VERSO ..............................................................................................................3 OBJETIVO ...................................................................................................................................3 PBLICO - ALVO ........................................................................................................................4 INJEO DE SQL........................................................................................................................4 Recomendaes ....................................................................................................................5 CROSS SITE SCRIPTING...............................................................................................................5 Recomendaes ....................................................................................................................5 ATAQUES A SISTEMAS DE AUTENTICAO .................................................................................6 Recomendaes ....................................................................................................................7 SEQESTRO DE SESSES .............................................................................................................7 Recomendaes ....................................................................................................................8 VISUALIZAO DE ARQUIVOS INDEVIDOS ..................................................................................8 Recomendaes ....................................................................................................................8 EXECUO DE COMANDOS NO SISTEMA OPERACIONAL .............................................................9 Recomendaes ....................................................................................................................9 ELEVAO DE PRIVILGIOS ......................................................................................................10 Recomendaes ..................................................................................................................10 UTILIZAO DO PROTOCOLO HTTPS.......................................................................................10 POLTICA DE SENHAS ................................................................................................................11 UPLOAD DE ARQUIVOS .............................................................................................................11 PRIVILGIOS MNIMOS NO BANCO DE DADOS ...........................................................................12 CRIPTOGRAFIA DAS SENHAS .....................................................................................................12 CAMPOS HIDDEN NO CDIGO HTML........................................................................................12 ATUALIZAO DE SOFTWARES .................................................................................................13 CONFIGURAO DE SOFTWARES ..............................................................................................13

VULNERABILIDADES COMUNS ................................................................................................4

OUTRAS RECOMENDAES ...................................................................................................10

REFERNCIAS..............................................................................................................................13

1. Introduo
As aplicaes web disponibilizadas na rede, sejam elas sites, webservices ou sistemas acessveis via rede, podem ser acessadas por quase quaisquer usurios que possuam conexo com a Internet. Essa facilidade de acesso possibilita o ataque indiscriminado a tais servios, ocasionando, em determinados casos, diversos problemas, tais como: divulgao de dados confidenciais, indisponibilidade do servio por tempo indeterminado, denigrao da imagem da organizao, etc. Ainda baseado na afirmativa do Gartner Group, que informa que mais de 70% dos cyber ataques ocorrem em aplicaes web, e baseado na afirmativa do WhiteHat Security, onde 8 em 10 sites da web possuem srias vulnerabilidades, a necessidade de aumentar a segurana de tais aplicaes torna-se essencial. Infelizmente, a maioria dos desenvolvedores s se preocupa com a segurana da aplicao aps algum problema relacionado mesma, querendo aplicar todas as medidas preventivas somente depois que o software est desenvolvido. Dessa forma, infringe-se uma das primeiras premissas para aumentar a segurana da aplicao: pensar em segurana desde o incio do desenvolvimento do software. Pensando nisso, foi desenvolvido este documento para servir de guia bsico na tarefa de garantir nveis de segurana maiores para sistemas web.

1.1 Controle de Verso

Verso 1.0 1.1 Autor USC - ATI USC - ATI Comentrio Criao do documento Reviso do documento

1.2 Objetivo
O propsito principal deste documento dar uma viso geral das principais falhas encontradas em aplicaes web e apresentar contramedidas para solucionar cada um dos problemas listados. Dessa forma, foge do escopo deste documento entrar em detalhes sobre cada uma das falhas apresentadas ou ainda servir como um manual para realizao de ataques. Na seo de referncias existem vrios links para documentos que tratam com maiores detalhes as vulnerabilidades aqui apresentadas.

1.3 Pblico - Alvo

Como pblico-alvo inclui-se todos os envolvidos no desenvolvimento de aplicaes do Governo do Estado de Pernambuco, desde programadores a gerentes.

2 Vulnerabilidades Comuns
Nesta seo so apresentadas as falhas comumente encontradas em aplicaes web, exibindo a sua descrio e as respectivas recomendaes para evit-las.

2.1 Injeo de SQL

O objetivo deste ataque inadvertidamente consultar, inserir, remover ou alterar os dados do banco de dados. Para isso, o atacante insere comandos SQL atravs dos parmetros de entrada da aplicao, para serem concatenados com o cdigo SQL original, e assim, executar outro comando SQL. O atacante, geralmente, utiliza formulrios que no realizam tratamento na entrada de dados dos usurios para injetar SQL no cdigo da aplicao. Abaixo exibido um exemplo de uma aplicao imaginria, escrita em ASP utilizando o banco de dados SQL Server, que realiza a seguinte consulta para autenticao dos usurios:
Select * From Usuario Where login='& login &' And senha = '& senha &'

O atacante poderia inserir nos campos login e senha os seguintes valores respectivamente, ' or 1=1 -- e 123, resultando no cdigo:

Select * From Usuario Where login='' or 1=1 -- ' And senha = '123';

Dessa forma, a aplicao executar uma consulta SQL que retornar um conjunto com todos os usurios do sistema, pois a expresso or 1=1 torna o comando verdadeiro e a expresso -- comenta o restante do cdigo. Como vrios sistemas de autenticao utilizam apenas o primeiro usurio da lista retornada, que freqentemente um administrador do sistema, o atacante ento seria autenticado no sistema com as credencias deste super-usurio.

2.1.1 Recomendaes
Para contornar esse problema, a principal recomendao realizar uma validao de todos os dados de entrada, principalmente no lado do servidor, a fim de evitar a utilizao de caracteres maliciosos. A validao de dados realizada somente no lado do cliente pode ser facilmente contornada copiando a pgina e removendo o cdigo de validao, geralmente feito em javascript. A poltica de validao recomendada a ser implementada a de permitir somente caracteres previamente selecionados e negar todo o resto das entradas. Isso pode ser alcanado, por exemplo, atravs do uso de expresses regulares. Finalmente, recomenda-se utilizar Prepared Statement ou Stored Procedures nos comandos SQL. O principal objetivo impedir que os dados de entrada afetem a sintaxe do comando SQL, separando a lgica do cdigo dos dados informados. Alm de aumentar a segurana, a aplicao tambm beneficiada com um aumento no desempenho do comando a ser executado.

2.2 Cross Site Scripting

Cross site scripting (geralmente referenciado por XSS) ocorre quando um atacante utiliza uma aplicao web para enviar cdigo malicioso que ser acionado posteriormente por uma ao de um usurio regular. O cdigo malicioso est, na maioria das vezes, sob a forma de script. O ataque j est bastante difundido e ocorre em qualquer aplicao web que utilize a entrada do usurio, sem validao, na sada gerada pela aplicao. Um possvel ataque, utilizando esta vulnerabilidade, a descoberta do cookie de sesso do usurio, permitindo ao atacante seqestrar tal sesso e ter o controle total de sua conta. Outros ataques incluem a divulgao de arquivos de usurios, a instalao de cavalos de tria, o redirecionamento do usurio para outra pgina ou site e a modificao do contedo de pginas.

2.2.1 Recomendaes
O ponto principal para prevenir esta vulnerabilidade nas aplicaes a confirmao de que o contedo de pginas dinamicamente geradas no contenha scripts indesejados. Isso pode ser alcanado filtrando-se toda a entrada do usurio na aplicao, incluindo cookies, urls e dados transmitidos via POST e GET. Alm disso, interessante tambm filtrar a sada do servidor web para o usurio, pois um atacante poderia inserir um script hostil diretamente no banco de dados ou em um momento em que a aplicao no possua filtragem dos dados. Dessa forma, qualquer dado persistente que seja transmitido entre o navegador e o servidor web deve ser filtrado, a fim de atingir todo o escopo do problema. Para realizar a filtragem dos dados recomenda-se utilizar uma abordagem positiva, que consiste em negar todas as entradas com exceo

dos dados previamente escolhidos. Por exemplo, no h necessidade de um campo do tipo data no formulrio receber entradas com valores diferentes de nmeros e talvez barras / (para separar dia, ms e ano). Dessa forma, o desenvolvedor no ter que adivinhar ou atualizar todas as formas de entradas maliciosas para negar todos os caracteres especficos. A abordagem positiva da filtragem de dados a recomendada pois existem vrias formas de representar o mesmo caractere. Por exemplo, a seguinte tabela abaixo lista algumas formas de representar o caractere <, que dependendo do contexto pode ser hostil. Representao do caractere < %3C &#0060 &#0060; &#x003c &lt &#00060 &#00060; &#x0003c &lt; &#000060 &#000060; &#x00003c &LT &#0000060 &#0000060; &#x000003c &LT; &#60; &#x3c &#x3c; &#060 &#060; &#x03c

2.3 Ataques a sistemas de autenticao

Para garantir a acessibilidade das informaes nos sistemas por pessoas que possuam a autorizao para tal, vrias aplicaes implementam um controle de autenticao, obrigando o usurio a informar login/senha vlidos para acessar o sistema. Apesar desse controle, freqentemente os desenvolvedores dos sistemas exibem informaes de erros detalhadas, na tentativa de ajudar os usurios, como por exemplo, Usurio no cadastrado ou Senha invlida. Abaixo so listados os principais problemas provenientes dessas mensagens de erro: Enumerao de logins vlidos: Nesta tcnica vrios usurios vlidos do sistema podero ser listados, facilitando o ataque de dicionrio ou de fora bruta. Isso possvel devido mensagem de erro informar se determinado usurio existe ou no no sistema. Ataque de dicionrio: Esta tcnica utiliza a poltica da tentativa e erro baseado num dicionrio de palavras, na qual o atacante poder utilizar este conjunto de palavras nos campos de login e senha a fim de se autenticar no sistema. Com a descoberta de logins vlidos (item anterior), o processo de descoberta da senha reduz-se drasticamente. Ataque de fora bruta: Esta outra tcnica baseia-se na mesma idia do ataque de dicionrio, mas ao invs de utilizar um dicionrio de palavras, utiliza todas as possibilidades de formaes de palavras, elevando muito o tempo de descoberta de pares de usurio/senha vlidos. Da mesma forma que o item anterior, caso o atacante possua logins vlidos o tempo gasto neste processo de autenticao ser reduzido consideravelmente.

2.3.1 Recomendaes
O primeiro passo evitar mensagens de erros detalhadas, como nos caso exibidos. As mensagens de erros devem ser especficas o suficiente para informar o problema ao usurio, e restritas o mximo para no disponibilizar informaes que facilitem o ataque de pessoas mal intencionadas. Para que sejam evitados ataques de dicionrio ou de fora bruta, pode-se utilizar um controle de logins mal sucedidos, estipulando-se um limite na quantidade de erros de login, bloqueando o usurio por um perodo de tempo ou pode-se utilizar CAPTCHA1. Abaixo exibido um exemplo do uso de CAPTCHA, na qual s aparece aps algumas tentativas erradas.

Figura 1 Exemplo de CAPTCHA do site www.gmail.com

2.4 Seqestro de sesses

A fim de garantir um controle de autenticao dos usurios na aplicao, muitos sistemas web utilizam cookies para guardar um identificador nico do usurio, evitando assim, que o usurio informe as suas credenciais para cada solicitao enviada ao servidor. Por exemplo, quando um usurio se autentica em uma aplicao web, o sistema valida seu login e senha e associa um cookie ao usurio solicitante. Quando o usurio solicita outra pgina, ao invs de informar novamente o login e senha, o servidor captura o cookie e verifica qual usurio possui o identificador informado, carregando a pgina solicitada no
1 CATPCHA um mecanismo para gerao de testes com a finalidade de verificar se o usurio uma pessoa ou um sistema, na qual geralmente so utilizadas imagens contendo letras e nmeros e um campo onde o usurio informa o contedo da imagem.

caso do identificador estar associado a um usurio ou negando o acesso em caso contrrio. O ataque pode surgir quando captura-se ou adivinha-se o cookie de outro usurio. Ento, torna-se possvel acessar a aplicao e se passar pelo usurio que est associado quele cookie capturado. Isso pode acontecer de vrias maneiras: Atravs de outros ataques que consigam capturar o cookie, como por exemplo, Cross Site Scripting. Caso a comunicao dos dados no seja criptografada, ou seja, caso seja utilizado HTTP ao invs de HTTPS (HTTP sobre SSL). Se o cookie estiver armazenado no cache do navegador.

2.4.1 Recomendaes
Apesar do uso de HTTPS garantir a criptografia dos dados transmitidos entre o cliente e o servidor, ainda possvel capturar o cookie dos usurios atravs de outro ataque, neste caso, o Cross Site Scripting. Portanto, a eliminao dessa vulnerabilidade j diminui consideravelmente o risco de ocorrer um seqestro de sesso. Alm disso, ainda so recomendados alguns itens: Utilizao de um valor pequeno para o tempo de expirao do cookie. Evitar utilizar cookies persistentes, impedindo assim que um atacante o roube, caso tenha acesso fsico ao computador do usurio. Separar os cookies de autenticao dos cookies de personalizao, que so utilizados para armazenar as preferncias dos usurios.

2.5 Visualizao de arquivos indevidos

Algumas aplicaes mantm arquivos em locais imprprios ou mantm arquivos que no deveriam estar na aplicao. Alguns exemplos do primeiro tipo so arquivos de configurao e informaes sigilosas. Exemplos do segundo tipo so: arquivos com senhas (da aplicao ou do banco de dados), arquivos com o cdigo-fonte acessvel. Em ambos os casos a divulgao destas informaes pela aplicao pode tornar a aplicao suscetvel a outros ataques ou permitir que dados confidenciais sejam disponibilizados.

2.5.1 Recomendaes
A recomendao mover os arquivos de configurao (ex: .cfg, .conf, .ini, etc.), de backup (ex: .bak, .old, etc.) e sigilosos (ex:, .class, .log, .xls, .pdf, .mdb, .tar.gz, etc.) para uma pasta que no seja acessvel pela web e implementar na aplicao um controle de acesso aos arquivos sigilosos.

Caso a disponibilizao de arquivos sigilosos seja necessria, recomenda-se que a prpria aplicao oferea essa funcionalidade, respeitando a autenticao e a autorizao do usurio solicitante. Os demais tipos de arquivos, configurao e backup, no devem ser acessados via web.

2.6 Execuo de comandos no Sistema Operacional

Esta tcnica de ataque permite a execuo de comandos do Sistema Operacional atravs da manipulao nas entradas de dados da aplicao. Isso possvel quando a aplicao no valida corretamente a entrada do usurio antes de us-la no sistema. Dessa forma, todos os comandos iro executar com as mesmas permisses do servio que executou o comando, seja ele o servidor web, o banco de dados, etc. Algumas aplicaes web incluem parmetros informando um arquivo que ser exibido para o usurio. Caso no seja feita a validao de entrada informada pelo usurio, um atacante pode modificar o valor do parmetro executando um comando do sistema operacional. Os exemplos abaixo exibidos so de uma aplicao fictcia rodando sobre um sistema operacional baseado em Unix. Essa aplicao possui uma pgina para exibio de arquivos solicitados pelo usurio, de modo que o nome do arquivo informado no parmetro arquivo da url. Dessa forma, o atacante poderia trocar o valor dessa varivel por um cdigo malicioso. O cdigo original exibido abaixo:
http://exemplo/teste.php?id=15&arquivo=relatorio.pdf

Alterando-se o valor para ; rm r *, o atacante consegue remover todos os arquivos e diretrios do diretrio corrente e abaixo dele.
http://exemplo/teste.php?id=15&arquivo=; rm r *

Um outro modo, que algumas aplicaes web utilizam so as funes exec, que permitem a execuo de comandos do sistema operacional. Caso a aplicao permita a introduo de dados pelo usurio que sejam usados em tais funes sem a devida validao, um atacante poderia executar comandos do sistema operacional remotamente.

2.6.1 Recomendaes
Como estas funes podem oferecer falhas crticas infra-estrutura da empresa, recomenda-se que todos os dados provindos do usurio e utilizados como parmetro nestas funes sejam validados antes de serem executados. Tambm utilize, se possvel, chamadas a bibliotecas ao invs de processos externos (exec(), system(), etc.) com a finalidade de recriar a funcionalidade desejada. Alm disso, certifique-se que a aplicao executada com o mnimo

de privilgios possvel para funcionar corretamente, a fim de restringir o efeito da execuo de cdigos maliciosos. Caso a aplicao no faa uso de tais funes e caso seja possvel, recomenda-se o bloqueio da execuo das chamadas de sistema atravs da configurao do servidor web.

2.7 Elevao de privilgios

Nesta vulnerabilidade, a idia central a de adquirir mais permisses que o atribudo ao usurio do sistema. Para evitar que usurios indevidos acessem recursos das aplicaes web, estas comumente utilizam um controle de autorizao para saber se determinado usurio possui permisso de acesso ao recurso solicitado. Esta vulnerabilidade pode ser encontrada em aplicaes web que realizam esse controle apenas atravs de menus dinamicamente criados, especficos para cada grupo de usurios, no verificando a requisio no lado do servidor, permitindo assim que o atacante acesse uma pgina, proibida para ele, bastando apenas informar o endereo diretamente na barra de endereos.

2.7.1 Recomendaes
Todo controle deve ser validado, no mnimo, no lado do servidor, podendo tambm ser validado no lado do cliente, para efeito de apresentao e otimizao da aplicao. Qualquer recurso protegido do sistema s poder ser acessado atravs de usurios devidamente autenticados e autorizados. Portanto, revise o cdigo da aplicao e verifique se todos os recursos protegidos possuem tal controle implementado. Utilize ainda o conceito do privilgio mnimo2, para executar os processos que mantm a aplicao.

3 Outras Recomendaes
Alm dos itens apresentados anteriormente, outros itens com o mesmo grau de importncia devem ser levados em conta. Abaixo, so exibidos os pontos a serem verificados com sua respectiva descrio.

3.1 Utilizao do protocolo HTTPS

O protocolo HTTP no oferece grau algum de segurana para a comunicao de dados. Com a ampliao da internet e devido necessidade

2 Privilgio mnimo representa o conceito que utiliza o mnimo de permisses necessrias para efetuar o servio requisitado.

10

de trfego de dados seguros, foi implementado HTTPS3 para prover vrios servios de segurana para as aplicaes e usurios das mesmas. Os principais servios oferecidos so: confidencialidade4 da informao entre o servidor e o cliente atravs da criptografia e a autenticao5 do servidor para o cliente atravs de certificados digitais.

3.2 Poltica de senhas

Um dos elos fracos de qualquer aplicao que necessite de autenticao so as senhas. Vrios usurios utilizam senhas fracas, possibilitando que um ataque de fora bruta descubra um par de login / senha vlido. Para contornar esse problema, recomenda-se que o sistema implemente uma poltica de senhas, impedindo que senhas fracas sejam admitidas. Como exemplo, pode-se requisitar que o usurios informe uma senha com no mnimo 8 caracteres, utilizando letras maisculas, minsculas, smbolos e nmeros, sendo trocada periodicamente. Para maiores informaes sobre polticas de senhas, veja o folder Dicas de Segurana: Escolhendo e protegendo suas senhas USC / ATI.

3.3 Upload de arquivos

Vrios sistemas permitem aos seus usurios enviar arquivos para a aplicao com diversas finalidades, dentre elas a centralizao de documentos no sistema, a incluso de arquivos no e-mail, o armazenamento remoto de arquivos, etc. Apesar dos benefcios, esta funcionalidade geralmente apresenta algumas vulnerabilidades srias ao sistema. O principal ponto a ser verificado a extenso do arquivo enviado ao servidor. Extenses como .exe, .bat, .cmd, .src, .dll, .vb, .vbs, .asp, .php, .js, .jsp, etc. so tidas como suspeitas e devem ser bloqueadas pela aplicao. A abordagem normalmente utilizada permitir somente as extenses previamente selecionadas e negar todas as demais extenses. Ainda recomendado utilizar uma partio especfica para o armazenamento dos arquivos enviados, que seja diferente da partio do sistema operacional e do servidor web, com isso evita-se a falta de espao para os arquivos do sistema operacional e o acesso direto aos arquivos pela web, respectivamente. Para completar, caso o sistema permita, especifique uma quota de tamanho total por usurio para o envio de arquivos, impossibilitando que usurios mal-intencionados acabem todo o espao da partio destinado para o upload.

3 HTTPS (HyperText Transfer Protocol Secure) o protocolo HTTP sobre SSL ou TLS. 4 A confidencialidade diz que a informao s est disponvel para aqueles devidamente autorizados. 5 Autenticao a capacidade de garantir que um usurio de fato quem ele diz ser.

11

3.4 Privilgios mnimos no Banco de dados

Hoje, vrias aplicaes estabelecem uma conexo com um banco de dados e por conseqncia requerem um usurio e senha para acessar este repositrio. Infelizmente, muitos desses usurios so administrativos, permitindo que operaes no necessrias aplicao possam ser executadas. Como boa prtica de segurana, recomenda-se utilizar um usurio de banco de dados especfico para a aplicao, com o mnimo de privilgios necessrios para rodar o sistema completamente, impedindo dessa forma que funes desnecessrias possam ser executadas na base de dados da aplicao ou at mesmo que outras bases de dados possam ser afetadas, nos casos em que o atacante consiga ter acesso s credenciais do banco de dados ou consiga injetar comandos SQL.

3.5 Criptografia das senhas

Este item refere-se s senhas armazenadas nos bancos de dados utilizadas em sistemas de autenticao da aplicao. O problema principal da guarda de senhas em texto plano a possibilidade de algum utiliz-las indevidamente na aplicao em questo ou em outras aplicaes, nos casos de usurios que possuem a mesma senha em diversos sistemas. Por isso, recomenda-se utilizar um algoritmo de hash6 de acesso pblico, amplamente utilizado e testado, a fim de garantir uma maior segurana s senhas da aplicao. Para isso, podem ser utilizados alguns algoritmos de amplo reconhecimento e disponveis em vrias linguagens de programao, que podem ser utilizados para alcanar essa necessidade. Dentre tais algoritmos, pode-se listar: RIPEMD-160, SHA256, SHA384 e SHA512, ordenados pelo grau de segurana, do menor para o maior. No utilize os algoritmos MD5 e SHA1, j que possvel quebrar os mesmos.

3.6 Campos hidden no cdigo HTML

Algumas aplicaes utilizam campos escondidos no cdigo HTML para controle interno da aplicao, seja para armazenar uma opo do usurio ou at para definir o nvel de acesso do usurio. Independente da finalidade pretendida pelo campo, uma pessoa mal intencionada poderia modificar o valor deste parmetro facilmente, permitindo assim situaes desastrosas. Para evitar essa situao, verifique o objetivo destas variveis escondidas e tenha certeza de que caso sejam modificadas no afetaro a segurana da aplicao.

O algoritmo de hash gera, a partir de uma entrada qualquer, uma mensagem de tamanho fixo, nica e irreversvel. Por nica, entende-se que duas entradas diferentes dificilmente tero o mesmo hash (resultado do algoritmo).

12

3.7 Atualizao de softwares

A atualizao dos softwares que oferecem o suporte a aplicao to importante para a segurana da aplicao, do servidor e da rede quanto s demais recomendaes apresentadas neste documento. Dessa forma, verifique por atualizaes no site do desenvolvedor dos softwares utilizados pela sua aplicao para evitar que vulnerabilidades alheias sua aplicao sejam utilizadas.

3.8 Configurao de softwares

Manter os softwares atualizados no basta. A configurao correta essencial para evitar problemas futuros. Um dos erros cometidos com freqncia a utilizao da mesma configurao do ambiente de desenvolvimento para o ambiente de produo. Determinadas configuraes so prprias para cada ambiente, como por exemplo, a ativao de debug. Esta opo s deve estar habilitada no ambiente de desenvolvimento, para efeito de manuteno da aplicao, evitando-se que possveis informaes sensveis sobre a estrutura do aplicativo sejam divulgadas. Diversos aplicativos fornecem uma senha padro para administrao e testes. Um dos primeiros passos da configurao do software modificar a senha inicial ou padro.

4 Referncias
Tempest technologies http://www.tempest.com.br/ OWASP (The Open Web Application Security Project). Vrios artigos, ferramentas, etc. sobre segurana em aplicaes web. http://www.owasp.org/ Spett, Kevin. SQL Injection: Are your web applications vulnerable? http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf#search =%22white%20paper%20sql%20injection%22 Friedl, Steve. SQL Injection Attacks by Example http://www.unixwiz.net/techtips/sql-injection.html Spett, Kevin. Blind SQL Injection: Are your web applications vulnerable? http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf#search =%22spi%20dynamics%20blind%20sql%20injection%22 Cross Site Scriptting FAQ

13

http://www.cgisecurity.com/articles/xss-faq.shtml Ollmann, Gunter. Paper: HTML Code Injection and Cross-site scripting http://www.technicalinfo.net/papers/CSS.html Denial of Service Attacks http://www.cert.org/tech_tips/denial_of_service.html The CAPTCHA Project http://www.captcha.net/

14