1

www.isc2.org
Introduo
Informativos tcnicos publicados anteriormente pelo (ISC)
discutiram os fundamentos da segurana de software do ponto
de vista de diferentes interessados. Em resposta a solicitaes de
leitores, este informativo tcnico discutir a segurana de software
da perspectiva do desenvolvedor.
No livro Hacking: the Art of Exploitation (Hacking: A Arte da
Explorao), o autor Jon Erickson expressa de forma precisa
e sucinta que a compreenso da tcnica de escrita de cdigo
ajuda aqueles que o exploram e que a compreenso da
explorao ajuda aqueles que o escrevem. Em outras palavras, o
desenvolvedor de software deve primeiramente entender como
o seu cdigo pode ser explorado (cdigo inseguro) para depois
usar esse conhecimento na escrita de cdigos que no quem
sujeitos explorao (cdigo seguro). Assim como no tratamento
de doenas, o mdico deve primeiramente diagnosticar o
problema central antes de tratar os sintomas, ao desenvolver
um software resistente a hackers preciso entender, antes de
qualquer coisa, o que constitui um cdigo inseguro, para depois
abordar suas possveis vulnerabilidades.
Apresentando a (In)segurana de Cdigo
De qualquer maneira, preciso entender desde o incio que
segurana de software mais do que simplesmente a escrita
de um cdigo seguro. No cenrio atual de segurana, as
consideraes devem ir alm da mera funcionalidade para levar
em conta tambm requisitos de segurana. H diversas fontes
de informao sobre segurana de software que so dignas de
nota. Algumas dessas merecem ser citadas, como a srie Hacking
Exposed (Hacking Revelado), 19 Deadly Sins of Software Security
(19 Pecados Mortais em Segurana de Software), Exploiting
Software (Explorando Software), Building Secure Software
(Construindo um Software Seguro) e Writing Secure Code
(Escrevendo Cdigos Seguros). Embora essas fontes sejam
consideradas de leitura obrigatria para todos os desenvolvedores
de software, outras fontes como a Chronology of Data Breaches
(Cronologia das Quebras de Segurana de Dados) e listas de bugs
de segurana e de divulgao completa mostram evidncias de
que os aplicativos de software produzidos nos dias de hoje ainda
contm um grande nmero de vulnerabilidades. As quebras de
segurana so meramente sintomas de projeto e programao
insegura e, a menos que os desenvolvedores de software sejam
treinados para criar arquiteturas de software seguras e identicar
o que constitui um software inseguro, provvel que a tendncia
do surgimento desenfreado de softwares com vulnerabilidades de
segurana continue.
A discusso sobre quem realmente o responsvel pela
insegurana de software interminvel. As opinies so vrias.
dos editores ou da organizao como um todo? Alguns acham
que a culpa deve ser atribuda a quem escreve o cdigo. Mas sem
fornecer treinamento adequado queles que escrevem os cdigos
sobre como escrever cdigos seguros ou como no escrever
cdigos inseguros, no justo colocar a culpa totalmente neles.
Este autor de opinio que a insegurana de software deve ser
atribuda a todos os envolvidos no ciclo de desenvolvimento do
software, e os desenvolvedores aqueles que escrevem o cdigo
podem representar um papel vital no desenvolvimento de
softwares seguros.
Cdigo INSECURE
Como diz o provrbio chins, toda longa jornada comea com
o primeiro passo. A jornada para desenvolver softwares seguros
comea com o primeiro passo ao identicar o que torna um
cdigo inseguro. Portanto, o que cdigo inseguro? Cdigo
inseguro aquele vulnervel a ataques de segurana. Para
facilitar a vida do leitor, a palavra insecure (inseguro em ingls)
pode ser usada como um acrstico para descrever estruturas
de programao e cdigos que so vulnerveis a quebras de
segurana. A lista a seguir no tem a inteno de ser exaustiva no
que se refere quilo que constitui um cdigo inseguro, mas sim
uma compilao das estruturas de programao mais comumente
observadas que tornam o software inseguro.
Cdigo (In)seguro
Mano Paul, CSSLP, CISSP, AMBCI, MCAD, MCSD, Network+, ECSA
A insegurana de software deve ser atribuda a
todos os envolvidos no ciclo de desenvolvimento
do software, e os desenvolvedores aqueles que
escrevem o cdigo podem representar um papel
vital no desenvolvimento de softwares seguros.
2
www.isc2.org
Caractersticas de Cdigo Inseguro
I Injeo de cdigo
A injeo do cdigo malicioso permite que os dados fornecidos
pelo usurio mal intencionado sejam executados como cdigo.
H diversos tipos de ataques de injection: contra bancos de dados
(por exemplo, SQL Injection), contra estruturas de diretrios
(por exemplo, LDAP Injection) e at contra o prprio sistema
operacional (por exemplo, comandos no sistema operacional
injection). Validao ou ltragem inadequada pode resultar em
ataques de injection.
A falta de validao de dados fornecidos pelo usurio a
principal razo que possibilita os ataques de injection, resultando
em graves consequncias. Brechas como a divulgao de
informaes sensveis (quebra de condencialidade), adulterao
e manipulao de estruturas e rvores de diretrio (quebra de
integridade), DoS (Denial-of-Service quebra de disponibilidade),
burla da vericao de autenticao e autorizao (check bypass),
e mesmo a execuo de cdigo remoto tornam-se possveis.
Outra possibilidade que no deve ser omitida a de estruturas
de cdigo que dependem de dados fornecidos pelo usurio
para montar dinamicamente as queries a serem executadas
dinamicamente no backend. H diversas tcnicas de codicao
defensiva contra ataques de injection. Uma opo o
saneamento das entradas de dados, que pode ser conseguido
pela restrio a um determinado conjunto de entradas vlidas ou
pela proibio e remoo de quaisquer padres e caracteres de
entrada invlidos.
Uma segunda opo o uso de queries parametrizadas, quer
dizer, que no sejam geradas dinamicamente. Elas usam os dados
fornecidos pelo usurio como parmetros. Quando aplicadas com
a arquitetura correta, podem ajudar tambm no desempenho.
Os padres de codicao no devem admitir a construo
dinmica de queries no cdigo com vistas a reduzir a possibilidade
de ataques de cdigo inoculvel e isso deve ser denido como
obrigatrio.
O artigo All Input Data is Evil So Make Sure You Handle It
Correctly and with Due Care (Todos os dados de entrada
so maldosos ento, certique-se de trat-los corretamente e
com o devido cuidado) escrito por Dino Esposito e publicado
na revista CoDe uma boa referncia e, conforme sugerido
apropriadamente pela segunda metade do ttulo, extremamente
importante ser capaz de identicar ataques de injection e tomar
as providncias necessrias (devido cuidado) para trat-los.
N Ausncia de mecanismos de No Repdio
Em um mundo altamente interconectado e mvel, imperativo
que a autenticidade da origem do cdigo e de transaes
comerciais e administrativas crticas seja incontestvel. O no
repdio a garantia que a origem do cdigo aquela que ele
diz ter. a capacidade de vericao da autenticidade da origem
do cdigo. Isso especialmente importante, visto que os cdigos
podem ser transferidos a partir de um local remoto e executados
no sistema local. O assim chamado cdigo mvel, deve conter
prova de sua origem para vericao de autenticidade, o que
pode ser conseguido por meio de cdigos com assinatura digital.
A assinatura digital o processo pelo qual os cdigos (executveis,
scripts etc.) so digitalmente marcados para assegurar que no
tenham sido adulterados e que so originados de um editor vlido.
A assinatura digital conhecida tambm como embalagem shrink-
wrap digital.
O no repdio garante tambm que as aes tomadas pelo
cdigo no possam ser recusadas. A funcionalidade de auditoria
de cdigo um mecanismo para garantir que o repdio no
seja possvel. Como mnimo absoluto, para transaes comerciais
e administrativas crticas, o cdigo deve ser escrito de forma a
registrar as aes tomadas, incluindo data/hora e outros detalhes
pertinentes, como o usurio ou o processo que est realizando a ao.
S Cdigo sujeito a Spoofng
Spoong o ato de personicar outro usurio ou processo.
Cdigo sujeito a spoong aquele que permite ataques de
spoong. Ataques de spoong permitem que o imitador realize
aes com o mesmo nvel de conana que o usurio vlido
que est sendo imitado. Revelao acidental de informaes,
adulterao de dados, esgotamento de recursos, burla da
autenticao, contorno de vericaes de autenticidade e
excluso ou manipulao de registros de auditoria so todas
possveis consequncias do spoong. O spoong foi observado
em casos onde a base do cdigo no era segmentada para ser
executada sob diferentes contextos de execuo dependentes do
nvel de conana (privilgio) do chamador do cdigo. Isso viola
o princpio do mnimo mecanismo comum que arma que os
mecanismos comuns a diversos usurios/processos no devem
ser compartilhados. Com somente um contexto de execuo
para todo o cdigo, um agressor poderia imitar uma identidade
e executar o cdigo como se fosse um usurio vlido com
permisso.
Identicadores de sesso previsveis, senhas gravadas, credenciais
em cache e permisso de imitao de identidades so
vulnerabilidades de codicao comuns que podem resultar
em ataques de spoong. A gura 1 mostra um exemplo de
congurao que possibilita a personicao de um usurio
especco. Alm do fato dessa personicao ser permitida, o
nome de usurio e a senha esto gravados na linha de cdigo
Injeo de cdigo
Ausncia de mecanismos de No Repdio
Cdigo sujeito a Spoofng
Tratamento inadequado de Excees e Erros
Cdigo com Criptografa vulnervel
Funes e rotinas inseguras/no Utilizadas no cdigo
Cdigo sujeito a engenharia Reversa
Necessidade de privilgios Elevados para execuo
Caracterstica
I
N
S
E
C
U
R
E
3
www.isc2.org
em texto puro, o que tambm no recomendvel. A gura
2 um exemplo que ilustra como a identidade de um usurio
autenticado imitada em cdigo.
Cdigos sujeitos a spoong podem resultar em diversos
comprometimentos da segurana, sendo mais comum o
sequestro e reproduo de sesses. Um agressor pode imitar a
identidade de um usurio vlido e assumir o controle de uma
sesso j estabelecida entre o cliente e o servidor e depois
reproduzir a ao. Caso haja alguma razo comercial vlida para
permitir a personicao, tais aes devero ser detalhadamente
monitoradas e auditadas. Devem ser tomadas precaues para
garantir que o cdigo no permita ataques de personicao e
spoong.
E Tratamento inadequado de Excees e Erros
Qualquer desenvolvedor de software entende que muito
difcil fazer um cdigo livre de erros. Excees e erros so
inevitveis. Entretanto, no tratar excees e erros ou trat-los
inadequadamente so opes inaceitveis quando se trata de
segurana de software.
Cdigos que revelam detalhes explcitos so um exemplo de
tratamento inadequado de excees e erros.
Um exemplo simples de erro explcito a mensagem Nome de
usurio invlido durante uma tentativa de autenticao. Mesmo
uma mensagem simples como essa contm mais informaes do
que necessrio. Uma mensagem como Login invlido seria
suciente. Essa mensagem de erro no explcita deixa o agressor
em dvida se invlido o nome de usurio ou a senha, diferente
do caso anterior onde o agressor sabe que o nome de usurio.
Mensagens de erro no explcitas que no mostram detalhes
abertos da exceo aumentam consideravelmente o trabalho do
agressor que quiser tentar entrar no sistema. No entanto, isso
pode ter um efeito negativo na soluo de problemas e suporte
ao usurio. Desta forma, as consideraes de projeto devem ser
ponderadas de maneira que o software seja adequadamente
explicito nas mensagens, mas sem revelar detalhes. O tratamento
inadequado de excees e erros pode resultar na revelao
da arquitetura interna, do uxo, tipo e valores de dados e dos
caminhos do cdigo. Durante um exerccio de reconhecimento,
um agressor pode usar as informaes coletadas de uma
mensagem de erro explcita ou dos detalhes de uma exceo
para levantar o perl do software. A gura 3 ilustra como uma
exceo no tratada pode revelar a existncia de uma conta de
login chamada SecuRiskLabUser, alm de revelar detalhes do stack
da exceo, fornecendo informaes ao agressor que podem ser
usadas para levantar o perl do software.
A ausncia de uma rotina abrangente de tratamento de excees
e o mero repasse das informaes de exceo brutas para o
front-end ou cliente outro exemplo de tratamento inadequado
de excees ou erros. Quando uma exceo ocorre, o cdigo
deve trat-la explicitamente.
Alm do mais, os ativos no devem ser postos em risco em caso
de falha, o que um princpio de proteo contra falhas (fail-safe
ou fail-secure em ingls). As decises devem ser baseadas em
permisses explcitas e no em excluses.
Figura 1. Congurao para personicar um determinado usurio
Figura 2. Personicando um usurio autenticado no cdigo
Figura 3. Mensagem de erro que revela detalhes do nome da conta em exceo
4
www.isc2.org
importante garantir que erros e excees sejam tratados de
forma no explcita, sem revelar mais informaes do que o
necessrio e sem violar os princpios de proteo contra falhas.
C Cdigo com Criptografa vulnervel
Desenvolvedores so, essencialmente, os solucionadores de
problemas criativos, so aqueles que utilizam suas habilidades e
conhecimento tecnolgico na criao de solues para problemas
e necessidades de negcios. Os desenvolvedores buscam o
aperfeioamento das funcionalidades existentes. Infelizmente, sabe-
se que isso tambm pode ser um tiro pela culatra, especialmente
no contexto da criptograa, conforme evidenciado por diversas
implementaes medocres de criptograa personalizada
observadas em revises de cdigo.
Tais revises revelam que as funcionalidades de criptograa no
cdigo so, na maioria das vezes, desenvolvidas internamente em
vez de serem aperfeioadas a partir de algoritmos existentes de
criptograa comprovados e validados. Isso contradiz o princpio
de projeto seguro ao promover os componentes existentes para
minimizar a exposio a ataques.
Alm disso, mesmo quando algoritmos de criptograa
comprovados so utilizados, os detalhes da implementao
permanecem inseguros. Os algoritmos de criptograa utilizam
um valor secreto, conhecido como chave, para criptografar
(converter texto puro em texto cifrado) e descriptografar
(converter texto cifrado em texto puro). A essncia da fora de
uma implementao de criptograa no est necessariamente
na robustez do algoritmo em si, mas na forma como a chave
derivada e tratada. O uso de nmeros no aleatrios para derivar
a chave de criptograa torna a proteo criptogrca fraca e
inecaz. Algumas vezes, senhas em cdigo ASCII no aleatrias
e fceis de adivinhar so empregadas na derivao da chave de
criptograa, o que deve ser evitado. Outro problema comum
que as chaves no so armazenadas de forma segura. Foram
observadas chaves codicadas diretamente nas linhas de cdigo.
Isso a mesma coisa que trancar a porta e deixar a chave na
fechadura, proporcionando uma proteo mnima, se que
proporciona alguma proteo.
Deve-se dar ateno especial ao escolher o algoritmo, vericando
o histrico de robustez. Uma vez escolhido, deve-se usar
Geradores de Nmeros Aleatrios (GNA) e Geradores de
Nmeros Pseudo-Aleatrios (GNPA) para derivar a chave de
criptograa para codicao e decodicao. As chaves derivadas
devem ser armazenadas de forma segura.
U Funes e rotinas inseguras/no Utilizadas no cdigo
As funes inseguras so consideradas inerentemente perigosas.
Essas funes so aquelas desenvolvidas sem necessariamente
levar em considerao as implicaes de segurana. O uso de
tais funes no garante ao programador nenhuma proteo de
segurana. Pode resultar em vulnerabilidades que permitiriam que
um potencial agressor corrompesse a memria do sistema e/
ou conseguisse controle total sobre o sistema. Uma das razes
atribudas aos notrios ataques de buffer overrun o uso de
funes inseguras no cdigo. Diversos boletins e atualizaes de
segurana que abordam essas funes j foram publicados.
Funes inseguras so encontradas predominantemente em
sistemas-legado e linguagens de programao de geraes
anteriores. Dois exemplos comuns em linguagem C so as funes
strcpy e strcat. Como essas funes no realizam vericaes de
comprimento/tamanho (tambm conhecidas como vericaes
de limites), um agressor poderia fornecer dados de entrada
de tamanho arbitrrio, excedendo a capacidade dos buffers de
memria. A gura 4 mostra um exemplo da funo insegura
strcpy em linguagem C, sendo utilizada para copiar os dados de
entrada para um buffer de memria local. Se no houver uma
vericao de limites e os dados de entrada fornecidos pelo
usurio contiverem mais caracteres do que a capacidade do
buffer de memria local, o resultado ser um buffer overow na
memria local.
Atualmente, os editores de linguagens de programao esto
evitando funes inseguras em favor de alternativas mais seguras,
como as funes strncpy e strncat que permitem a vericao
de comprimento/tamanho pelo desenvolvedor. Outra estrutura
insegura de codicao, observada em revises de cdigo, a
presena de funes no utilizadas, representadas por trechos
de cdigo redundantes que no so mais utilizados para tratar
nenhuma funcionalidade.
Mudanas nos negcios, avanos tecnolgicos e o receio de causar
incompatibilidade com verses anteriores so algumas das razes
para que funes no utilizadas sejam deixadas no cdigo. Isso
aumenta a exposio relativa do cdigo a ataques.
Easter eggs outro exemplo clssico de funes no utilizadas.
Em software, um Easter eggs um cdigo oculto que pode causar
uma alterao de comportamento do programa (por exemplo,
a exibio de uma mensagem, a reproduo de um som etc.)
quando determinadas condies so satisfeitas (por exemplo, uma
sequncia de cliques do mouse ou de teclas etc.). Normalmente,
o Easter eggs incuo, mas tambm aumentam a exposio
do cdigo a ataques e, portanto, podem sofrer consequncias
de segurana potencialmente graves. O risco de perder clientes,
de introduzir novos bugs e de impactos no desempenho que
podem resultar em esgotamento de recursos, ou seja, impacto
na disponibilidade (juntamente com o risco de parecer um
Figura 4. Uso da funo insegura strcpy em linguagem C
5
www.isc2.org
eggomanaco!) so alguns dos efeitos negativos do Easter eggs.
O interessante artigo Favorite software Easter Eggs (Ovos de
Pscoa de Software Favoritos) publicado na IT World mostra o lado
sinistro do Easter eggs de software. O melhor a fazer minimizar
a exposio relativa do cdigo a ataques e isso signica evitar o uso
de funes inseguras, removendo funes no utilizadas que no
possam ser rastreadas por uma matriz de acompanhamento de
requisitos, evitando, assim, a codicao de Easter eggs.
R Cdigo sujeito a engenharia Reversa
O aclamado trabalho do IEEE intitulado Reverse Engineering
and Design Recovery: A Taxonomy (Engenharia Reversa e
Recuperao de Projetos: Uma Taxonomia) dene engenharia
reversa como o processo de anlise de um sistema para
identicar seus componentes e o respectivo interrelacionamento
para criar uma representao do sistema em outra forma ou em
um nvel mais alto de abstrao. Em resumo, a engenharia reversa
de software ou reverso o processo de ir de trs para diante a
partir do sistema ou do cdigo para determinar o projeto interno
ou detalhes de implementao. A reverso do software pode ser
realizada no nvel de sistema ou de cdigo.
Cdigos no obscurecidos ou sem assinatura digital so facilmente
revertidos. O obscurecimento de cdigo o processo de tornar
seu funcionamento difcil de entender e o cdigo resultante
algumas vezes chamado de encoberto. O obscurecimento
obtido pela convoluo do cdigo para que, mesmo de posse
do cdigo fonte, este no possa ser entendido. Os programas
de obscurecimento podem operar no cdigo fonte, no cdigo
objeto ou em ambos, com o propsito principal de impedir a
engenharia reversa. A gura 5 mostra as verses no obscurecida
e obscurecida de um simples programa de impresso HelloWorld.
A assinatura digital do cdigo (discutida anteriormente) outra
tcnica contra a engenharia reversa que oferece mais proteo
do que o obscurecimento. Vericar o cdigo quanto existncia
de debuggers e enganar os decompiladores utilizando dados no
referentes a instrues ou bytes inteis so outras tcnicas contra
a engenharia reversa.
Deve-se reconhecer que tais tcnicas contra a reverso s podem
dicultar a reverso, mas no necessariamente impedi-la. No
obstante, imperativo que o cdigo seja protegido o mximo
possvel contra os riscos da engenharia reversa. O livro Reversing
- Secrets of Reverse Engineering (Reverso Segredos da
Engenharia Reversa) de Eldad Eilam uma fonte de informao
excelente para os interessados em escrever cdigos irreversveis.
E Necessidade de privilgios Elevados para execuo
O princpio do menor privilgio arma que um usurio ou
processo deve receber somente o nvel mnimo necessrio de
direitos de acesso (privilgios) pelo menor tempo necessrio para
que o usurio ou processo conclua a operao. Embora, algumas
vezes um cdigo que executado normalmente em um ambiente
de desenvolvimento menos seguro apresente soluos ou deixe de
funcionar em um ambiente de produo mais restrito. A soluo
usual para tais casos aumentar o nvel de privilgio sob o qual o
cdigo possa ser executado ou remover a vericao de nvel de
privilgio. Nenhuma dessas solues recomendvel do ponto
de vista de segurana. Elas poderiam conduzir a uma evaso das
permisses, permitindo que usurios e processos com privilgios
menores executem cdigos para os quais no esto autorizados.
Adicionalmente, um outro exemplo clssico de cdigo inseguro
o cdigo que pode ser explicitamente congurado para ser
executado com privilgios elevados (administrativos) pelo
programa.
Figura 5. programa HelloWorld antes e depois do obscurecimento
Before
After
6
www.isc2.org
As diferenas de congurao entre os ambientes de
desenvolvimento e de produo devem ser garantidas para que
o cdigo possa ser executado com o menor nvel de privilgios,
independentemente do ambiente. Tambm imperativo
garantir que os cdigos congurados explicitamente para serem
executados com privilgios elevados sejam cuidadosamente
monitorados (auditados) e administrados.
Concluso
No escreva cdigos inseguros um dos oito hbitos seguros
discutidos em 8 Simple Rules for Developing More Secure Code
(8 Regras Simples para Desenvolver Cdigos Mais Seguros). Sem um
entendimento completo do que constitui um cdigo inseguro, seria
injusto esperar que os desenvolvedores escrevessem cdigos mais seguros.

Caso o cdigo seja vtima de uma quebra de segurana, o cdigo
em si pode ser considerado inocente, mas esse tipo
de indulgncia no ser estendido ao indivduo, equipe ou
organizao que escreveu o cdigo. Dessa forma, essencial que
todos os que escrevem cdigos tornem um hbito incorporar
segurana ao cdigo que escrevem.
Enumerar todas as formas de evitar a escrita de cdigos inseguros
e/ou como escrever cdigos seguros iria muito alm do escopo
deste trabalho. Em vez disso, ele deve ser visto meramente como
um alerta para a escrita de cdigos seguros e para os tremendos
riscos de no faz-lo.
Assim como um jogo de xadrez produz um nmero innito
de movimentos uma vez que o jogo seja iniciado, com um
nmero limitado de gambitos de abertura, o entendimento
das caractersticas dos cdigos inseguros um dos primeiros
movimentos para assegurar que o cdigo seja escrito de forma a
ser resistente a hackers. Cdigo inseguro signica xeque-mate.
essencial que todos os que escrevem
cdigo tenham como hbito incorporar
segurana no cdigo que escrevem.
A escrita de cdigos seguros tem o benefcio
adicional de produzir um cdigo de qualidade
funcional, confvel e menos propenso a erros.
Caractersticas de um Cdigo Seguro
Valida os dados de entrada
No permite a construo dinmica de queries usando
dados fornecidos pelo usurio
Audita e registra funes crticas para o negcio
assinado digitalmente para verifcar a autenticidade de
sua origem
No usa identifcadores de sesso previsveis
No codifca segredos nas linhas de programao
No coloca credenciais em cache
adequadamente instrumentado
Trata excees de forma explcita
No revela excesso de informaes nos erros
No reinventa funcionalidades existentes e usa algoritmos
de criptograa comprovados
No usa algoritmos de criptografa frgeis
Usa derivao de chaves criptogrfcas por aleatoriedade
Armazena as chaves criptogrfcas de forma segura
No usa APIs banidas e funes inseguras
obscurecido ou encoberto
feito para ser executado com um mnimo de privilgios
7
www.isc2.org
Injeo de codigo




Ausncia de mecanismos
de No Repdio

Cdigo sujeito a
Spoofng



Tratamento inadequado
de Excees e Erros



Cdigo com Criptografa
vulnervel


Funes e rotinas
inseguras/no Utilizadas
no cdigo


Cdigo sujeito a
engenharia Reversa

Necessidade de privilgios
Elevados para execuo
Caracterstica
I
O que ?
Exemplos de
cdigo inseguro Como resolver
Cdigo que possibilita
ataques por injeo de cdigo
maliciosos por permitir que
dados fornecidos pelo usurio
sejam executados como
cdigo.
Autenticidade da origem
e das aes do cdigo
discutvel.

Cdigo que possibilita
ataques de spoofng.



Cdigo que revela mensajes
de error explcitos y detalles
de excepciones o que queda
abierto en caso de falla.


Cdigo que usa algoritmos
de criptografa frgeis ou
personalizados e trata a
chave de forma insegura.


Cdigo que aumenta a
exposio a ataques pelo uso
de rotinas inseguras ou por
conter rotinas no usadas.

Cdigo que permite a
determinao da arquitetura
interna.



Cdigo que viola o princpio
de privilgios mnimos.
N
S
E
C
U
R
E
No validao dos dados
de entrada, construo
dinmica de queries.



Executveis no assinados
digitalmente e ausncia de
auditoria.


Identifcadores de sesso
previsveis, senhas codifcadas
no programa, credenciais
em cache e possibilidade de
personifcao de identidade.



Errores explcitos,
excepciones no tratadas,
abierto por falla.



A chave no derivada nem
tratada de forma segura.






Funes de API banidas,
Easter eggs.



Cdigo no obscurecido,
executveis sem assinatura
digital.


Contas administrativas.
Validao dos dados
de entrada, queries
parametrizadas.


Assinatura digital do cdigo.




Tratamento de sesses,
cache e senhas, tratamento
de personifcao de
identidade.




Mensajes de error no
explcitos, tratamiento
explcito de excepciones,
bloqueo de Try-Catch-Finally,
proteccin contra fallas.

No usar algoritmos frgeis
e no padronizados e
criptografa personalizada.
Usar GNA e GNPA para
derivao da chave.

No usar funes de
API inseguras e banidas,
validao dos dados de
entrada, remoo de rotinas
no utilizadas e Easter eggs.

Obscurecimento do cdigo
(encobrimento), assinatura
digital no cdigo.



Confgurao do ambiente,
cdigo confgurado
explicitamente para ser
executado com um mnimo
de privilgios.
Resumo dos Conceitos Inseguros
8
www.isc2.org
Sobre a (ISC)

O International Information Systems Security Certication

Consortium, Inc. [(ISC)
2
] (Consrcio Internacional de
Certicao de Segurana para Sistema da Informao) o
padro reconhecido no mundo inteiro para a certicao de
prossionais de tecnologia da informao. Fundado em 1989, o
(ISC) j certicou mais de 60 mil prossionais de segurana da
informao em mais de 130 pases. Sediado em Palm Harbor,
Flrida, EUA e com escritrios em Washington, D.C., Londres,
Hong Kong e Tquio, o (ISC)
2
emite o certicado Certied
Information Systems Security Professional (CISSP

) e outras
centralizaes relacionadas e as credenciais de Certied Secure
Software Lifecycle Professional (CSSLP

), Certication and
Accreditation Professional (CAP

) e Systems Security Certied

Practitioner (SSCP

) para aqueles que atendem aos requisitos de

competncia necessrios.
O CISSP do (ISC) e centralizaes relacionadas e as certicaes
CAP e SSCP esto entre as primeiras credenciais de tecnologia da
informao a atender os rigorosos requisitos da norma ANSI/ISO/
IEC 17024, uma referncia global de avaliao e certicao de
prossionais. O (ISC) tambm oferece um programa de ensino
prossional permanente, um portfolio de produtos e servios
educacionais baseados no CBK

do (ISC)
2
, um compndio de
tpicos de segurana da informao, e responsvel pelo grupo
(ISC) Global Information Security Workforce Study. Para mais
informaes visite o site www.isc2.org
Sobre o Autor
Mano Paul, CSSLP, CISSP, AMBCI, MCAD, MCSD, Network+, ECSA
o CEO e presidente da Express Certications and SecuRisk
Solutions, grupo de empresas especializadas em treinamento
prossional, certicao, produtos de segurana e consultoria
de segurana. Sua experincia em segurana inclui o projeto
e desenvolvimento de programas de segurana de software
da conformidade codicao, gerenciamento de riscos de
segurana de aplicativos, estratgia e administrao de segurana
e apresentao de sesses, treinamentos e outras atividades
educacionais de conscientizao sobre segurana.
Atualmente est escrevendo o Guia Ocial da (ISC)
2
para
certicao CSSLP, co-autor do manual Information Security
Management (Gerenciamento de Segurana da Informao),
escreve periodicamente para revistas de certicao,
desenvolvimento de software e segurana e tem contribudo
com diversos tpicos para a rede Microsoft Solutions Developer
Network. Apresentou-se em diversas conferncias nacionais e
internacionais de segurana e orador convidado e membro
do conselho do CSI (Computer Security Institute Instituto de
Segurana de Computadores), Catalyst (Burton Group), TRISC
(Texas Regional Infrastructure Security Conference Conferncia
Regional de Infraestrutura de Segurana do Texas), SC World
Congress e conferncias de segurana de aplicativos OWASP
(Open Web Application Security Project). Pode ser encontrado
pelos e-mails
mano.paul@expresscertications.com y mano.paul@
securisksolutions.com.
a Erickson, J, Hacking: The Art of Exploitation, No Starch Press. ISBN 1593270070
b The Chronology of Data Breaches.
http://www.privacyrights.org/ar/ChronDataBreaches.htm
c CoDe Magazine All Input is Evil- So Make Sure You Handle It Correctly and
with Due Care.
http://www.code-magazine.com/article.aspx?quickid=0705061
d Saltzer, J.H and Schroeder, M.D, The Protection of Information in
Computer Systems.
http://web.mit.edu/Saltzer/www/publications/protection/
e Favorite Software Easter Eggs, IT World.
http://www.itworld.com/print/64689
f Chikofsky, E. J & Cross, J. H. Reverse engineering and design recovery:
A taxonomy. IEEE Software, 7(1):13-17, January 1990.
g HelloWorld Obfuscation Image Reference.
http://oreilly.com/pub/a/mac/2005/04/08/code.html
h Eilam, E., Reversing: Secrets of Reverse Engineering, Wiley. ISBN 0764574817
i 8 Simple Rules For Developing More Secure Code., Microsoft Developer
Network (MSDN)

http://msdn.microsoft.com/en-us/magazine/cc163518.aspx
2009, (ISC)
2
Inc. (ISC), CISSP, ISSAP, ISSMP, ISSEP, CAP, SSCP e CBK so marcas
registradas e CSSLP uma marca registrada da (ISC), Inc.
03/10