6 - Security Misconfiguration Considere annimos atacantes externos, bem como usurios com as suas prprias contas que podem

tentar comprometer o sistema. Considere tambm insiders querendo disfarar suas aes. Atacante acessa contas padro, pginas no utilizadas, falhas no corrigidas, arquivos desprotegidos e diretrios, etc, para ganhar acesso no autorizado ou conhecimento do sistema. Erro de configurao de segurana pode acontecer a qualquer nvel de uma pilha de aplicativos, incluindo a plataforma, servidor web, servidor de aplicao, enquadramento e de cdigo personalizado. Os desenvolvedores e administradores de rede precisam trabalhar juntos para assegurar que toda a pilha est configurado corretamente. Scanners automticos so teis para deteco de manchas em falta, erros de configurao, uso de contas padro, servios desnecessrios, etc Tais falhas freqentemente do ao atacante acesso no autorizado a alguns dados do sistema ou funcionalidade. Ocasionalmente, essas falhas resultar em um comprometimento completo do sistema. O sistema pode ser completamente comprometido sem voc saber. Todos os seus dados podem ser roubados ou modificado lentamente ao longo do tempo. Custos de recuperao pode ser caro. Eu sou vulnervel? Voc j realizou o adequado de segurana em todo o endurecimento pilha aplicativo inteiro? 1. Voc tem um processo para manter todo o seu software at data? Isso inclui o sistema operacional, servidor web / App, DBMS, aplicaes, e todas as bibliotecas de cdigo. 2. tudo deficientes desnecessrios, removido ou no instalado (por exemplo, portos, servios, pginas, contas, privilgios)? 3. So senhas de contas de padro alterado ou desativado? 4. o seu tratamento de erros configurado para evitar rastreamentos de pilha e outras mensagens de erro muito informativas de vazamento? 5. As configuraes de segurana em seus quadros de desenvolvimento (por exemplo, Struts, Spring, ASP.NET) e bibliotecas entendido e configurado corretamente? Um processo repetvel concertada necessria para desenvolver e manter uma configurao de segurana adequada aplicao. Como fao para evitar isso? As recomendaes primrias so estabelecer todos do seguinte: 1. Um processo de endurecimento de repetio que torna mais rpido e fcil de implantar outro ambiente que est devidamente

bloqueados. Desenvolvimento, controle de qualidade, produo e ambientes devem ser configuradas de forma idntica. este processo deve ser automatizado para minimizar o esforo necessrio para configurar um novo ambiente seguro. 2. Um processo para se manter a par de tudo e implantao de novo atualizaes e patches de software em tempo hbil para cada implantado ambiente. Este deve incluir todo o cdigo bibliotecas, assim, que so frequentemente esquecidos. 3. A arquitetura do aplicativo forte que fornece boa separao e de segurana entre os componentes. 4. Considere executar varreduras e fazer auditorias periodicamente para ajudar a detectar erros de configurao de futuros ou patches ausentes. Ataque Exemplo cenrios Cenrio # 1: O aplicativo conta com uma estrutura poderosa como Struts ou Spring. Falhas XSS so encontrados nestas quadro componentes que voc confiar. Uma atualizao lanada para corrigir esses falhas, mas voc no atualizar suas bibliotecas. At que voc faa, atacantes podem facilmente encontrar e explorar essas falhas em sua aplicao. Cenrio # 2: O aplicativo console de administrao do servidor automaticamente instalado e no foi removido. Contas padro no so alterados. Atacante descobre as pginas padro de administrao so em sua servidor, registra com senhas padro, e assume. Cenrio # 3: listagem de diretrio no est ativado em seu servidor. Atacante descobre que ela pode simplesmente listar os diretrios para encontrar qualquer arquivo. Atacante acha e baixa tudo o Java compilado classes, que ela reverte para obter todo o seu cdigo personalizado. ela em seguida, encontra uma falha grave de controle de acesso em sua aplicao. Cenrio 4: configurao do servidor App permite que os rastreamentos de pilha para ser devolvido para os utilizadores, expondo potencialmente falhas subjacentes. Atacantes amar as mensagens de erro adicionais de informao fornecem.

7 Insecure Cryptographic Storage Considere os usurios do seu sistema. Eles gostariam de ter acesso a dados protegidos no so autorizados para? E sobre os administradores internos? Os atacantes no costumam quebrar a criptografia. Eles quebrar outra coisa, como encontrar as chaves, obter cpias de dados em texto puro, ou acessar dados atravs de canais que automaticamente descriptografar. A falha mais comum nesta rea simplesmente no est a criptografia de dados que merece criptografia. Quando a criptografia utilizada, a gerao de chaves e armazenamento inseguro, no rotativa de chaves, e uso de algoritmo fraco comum. Uso de hashes fracos ou sem sal para proteger senhas tambm comum. Atacantes externos tm dificuldade em detectar tais falhas devido ao acesso limitado. Eles costumam explorar outra coisa deve primeiro a obter o acesso necessrio. Falha frequentlycompromises todos os dados que deveriam ter sido criptografados. Tipicamente esta informao inclui dados sensveis, tais como registros de sade, credenciais, dados pessoais, cartes de crdito, etc Considere o valor de negcio dos dados perdidos e de impacto para sua reputao. Qual a sua responsabilidade legal, se tal dado exposto? Considere tambm o dano sua reputao. Eu sou vulnervel? A primeira coisa que voc tem que determinar que os dados so sensvel o suficiente para exigir criptografia. Por exemplo, senhas, cartes de crdito, registros de sade e pessoais informaes devem ser criptografadas. Para todos esses dados, verifique se: 1. Ele criptografado em toda parte armazenada a longo prazo, particularmente em backups de dados. 2. Somente usurios autorizados podero acessar cpias do descriptografados dados (ou seja, A4 de controle de acesso Veja e A8). 3. Um algoritmo de criptografia forte padro usado. 4. Uma chave forte gerado, protegidos contra acesso e mudana chave planejado. E mais ... Para um conjunto mais completo de problemas para evitar, veja os requisitos ASVs sobre criptografia (V7). Como fao para evitar isso? Os perigos completas de criptografia inseguro so muito alm do escopo deste Top 10. Dito isto, para todos os dados sensveis que merece criptografia, fazer tudo o que se segue, no mnimo: 1. Considerando as ameaas que voc pretende proteger esses dados de (por exemplo, ataque interno, o usurio externo), certifique-se criptografar todos os dados em repouso de uma maneira que defende contra estas ameaas.

2. Certifique-se de backups offsite so criptografados, mas as teclas so gesto e feito separadamente. 3. Assegurar a adequada fortes algoritmos padro e chaves fortes so usados, e gerenciamento de chaves est no lugar. 4. Assegurar as senhas so hash com um padro forte algoritmo e um sal apropriado usado. 5. Assegurar que todas as chaves e senhas so protegidos contra o acesso no autorizado. Ataque Exemplo cenrios Cenrio # 1: Uma aplicao criptografa cartes de crdito em uma banco de dados para evitar a exposio aos usurios finais. No entanto, o banco de dados definido para consultas automaticamente descriptografar contra o crdito colunas de carto, permitindo uma falha de injeo SQL para recuperar todos os cartes de crdito em texto puro. O sistema deve ter sido configurado para permitir que apenas aplicaes back-end para descriptografar eles, no o aplicativo da Web front-end. Cenrio # 2: Uma fita de backup feita de sade criptografado registros, mas a chave de criptografia o mesmo backup. o fita nunca chega ao centro cpia de segurana. Cenrio # 3: O banco de dados usa o hash de senha sem sal para armazenar senhas de todos. Uma falha de upload de arquivos permite que um atacante para recuperar o arquivo de senhas. Todos os hashes sem sal pode ser ataque de fora bruta em 4 semanas, enquanto hashes devidamente salgados teria levado mais de 3000 anos.

8 - Failure to Restrict URL Access Qualquer pessoa com acesso rede pode enviar o seu pedido de um pedido. Couldanonymous usurios acessar uma pgina privada ou usurios regulares uma pgina privilegiado? Atacante, que um usurio do sistema autorizado, simplesmente altera a URL para uma pgina privilegiada. concedido acesso? Usurios annimos podem acessar pginas privadas que no so protegidos. Os aplicativos no so sempre protegendo as solicitaes de pginas corretamente. s vezes, a proteo URL gerenciado atravs de configurao, eo sistema est errada. s vezes, os desenvolvedores devem incluir o cdigo verifica adequadas, e eles forget.Detecting tais falhas fcil. A parte mais difcil identificar quais pginas (URLs) existem para atacar. Essas falhas permitem que os atacantes para acessar funes no autorizadas functionality.Administrative so alvos principais para este tipo de ataque. Considere o valor de negcio das funes expostas e os dados que process.Also considerar o impacto de sua reputao se esta vulnerabilidade se tornou pblica. Cenrio Ataque exemplo O atacante simplesmente fora navega para URLs de destino. Considerar os seguintes URLs que so ambos supostamente para exigir autenticao. Direitos de administrador tambm so necessrios para o acesso a pgina "admin_getappInfo". http://example.com/app/getappInfo http://example.com/app/admin_getappInfo Se o atacante no est autenticado, e acesso a qualquer pgina concedida, ento o acesso no autorizado era permitido. Se um autenticada, no-admin do usurio, permitido o acesso ao "Admin_getappInfo" da pgina, esta uma falha, e pode levar a atacante a mais indevidamente protegidos pginas de administrao. Tais falhas so freqentemente introduzidas quando os links e botes simplesmente no so exibidos para usurios no autorizados, mas o aplicao no proteger as pginas que tm como alvo. Eu sou vulnervel? A melhor maneira de descobrir se um aplicativo no pde ser acesso URL corretamente restringir para verificar cada pgina. Considerar para cada pgina, a pgina suposto ser pblico ou privado. Se uma pgina privada: 1. a autenticao necessria para acessar essa pgina? 2. suposto ser acessvel a qualquer autenticado do usurio? Se no, uma verificao de autorizao feito para assegurar a usurio tem permisso para acessar essa pgina?

Mecanismos de segurana externas freqentemente fornecem autenticao e autorizao cheques para acesso pgina. Verifique se eles esto configurados corretamente para cada pgina. Se o cdigo nvel de proteo usado, verifique se a proteco ao nvel cdigo est em colocar em cada pgina necessria. Os testes de penetrao tambm pode verificar se a proteo adequada no lugar. Como fao para evitar isso? Impedir o acesso no autorizado URL requer a seleo de um abordagem para exigir autenticao adequada e apropriada autorizao para cada pgina. Freqentemente, essa proteco fornecido por um ou mais componentes externos cdigo da aplicao. Independentemente do mecanismo (s), todos do Recomendam-se: 1. As polticas de autenticao e autorizao ser o papel base, para minimizar o esforo necessrio para manter estes polticas. 2. As polticas devem ser altamente configurvel, a fim de minimizar os aspectos difceis codificados da poltica. 3. O mecanismo de aplicao (s) deve negar o acesso por padro, exigindo subsdios explcitos para usurios especficos e funes para acesso a cada pgina. 4. Se a pgina est envolvido em um fluxo de trabalho, certifique-se as condies so no estado adequado para permitir o acesso.

9 - Insufficient Transport Layer Protection Considere qualquer pessoa que pode monitorar o trfego de rede de seus usurios. Se o aplicativo est na internet, quem sabe como os usurios acess-lo. No se esquea de volta o trfego dos usurios finais connections.Monitoring rede pode ser difcil, mas s vezes fcil. A dificuldade principal reside no monitoramento de trfego de rede adequada, enquanto os usurios esto acessando o site vulnervel. Aplicaes freqentemente no proteger o trfego de rede. Eles podem usar SSL / TLS durante a autenticao, mas no em outros lugares, expor os dados e as identificaes de sesso para interceptao. Expirado ou certificados configuradas incorretamente tambm podem ser used.Detecting falhas bsicas fcil. Basta observar o trfego do site da rede. Falhas mais sutis exigem inspeccionar o design do aplicativo e da configurao do servidor. Tais falhas expor dados individuais dos usurios e pode levar ao roubo de conta. Se uma conta de administrador foi comprometido, todo o site poderia ser exposto. Configurao SSL pobre tambm pode facilitar ataques de phishing e MITM. Considere o valor de negcio dos dados expostos no canal de comunicao em termos de confidencialidade e as necessidades de integridade, e da necessidade de autenticar ambos os participantes. Ataque Exemplo cenrios Cenrio # 1: Um site simplesmente no usar SSL para todas as pginas que requer autenticao. Atacante simplesmente monitora rede trfego (como um fio aberta ou a cabo o seu bairro modem de rede), e observa uma vtima autenticado cookie de sesso. Invasor, ento, replays este bolinho e d sobre a sesso do usurio. Cenrio # 2: Um site foi configurado incorretamente certificado SSL que faz com que avisos do navegador para seus usurios. Os usurios tm que aceitar tais avisos e continuar, a fim de usar o site. Isso faz com que os usurios se acostumar com esses avisos. Ataque de phishing contra clientes do site atrai-los para um local ssia que no tem um certificado vlido, o que gera avisos similares navegador. Uma vez que as vtimas so acostumados a tais advertncias, eles procedem e usar o phishing site, dando senhas ou outros dados confidenciais. Cenrio 3: Um site simplesmente usa o padro ODBC / JDBC para o conexo com o banco, no percebendo todo o trfego est em claro. Eu sou vulnervel?

A melhor maneira de descobrir se um aplicativo tem suficiente proteo da camada de transporte verificar que: 1. SSL usado para proteger todo o trfego de autenticao relacionado. 2. SSL usado para todos os recursos em todas as pginas privadas e servios. Isto protege todos os dados e tokens de sesso que so trocados. SSL Mixed em uma pgina deve ser evitado uma vez que faz com que os avisos de usurio no navegador, e pode expor ID de sesso do usurio. 3. Somente algoritmos fortes so suportados. 4. Todos os cookies de sesso tem sua flag "seguro" para o navegador nunca os transmite em claro. 5. O certificado de servidor legtima e corretamente configurado para o servidor. Isso inclui ser emitido por um emitente autorizado, no expirou, no foi revogado, e corresponde a todos os domnios do local utiliza. Como fao para evitar isso? Fornecer proteo da camada de transporte adequado, pode afetar o site design. mais fcil exigir SSL para o site inteiro. Para motivos de desempenho, alguns sites usam SSL apenas no privado pginas. Outros usam SSL apenas no 'crticas' pginas, mas isso pode expor IDs de sesso e outros dados sensveis. No mnimo, fazer todo o seguinte: 1. Exigir SSL para todas as pginas sensveis. Non-SSL solicitaes para estas pginas devem ser redirecionado para a pgina SSL. 2. Defina o sinalizador "seguro" em todos os cookies sensveis. 3. Configure o seu fornecedor de SSL para suportar apenas forte (por exemplo, FIPS 140-2 compliant) algoritmos. 4. Verifique se o seu certificado vlido, no expirado, no revogada, e corresponde a todos os domnios usados pelo site. 5. Conexes de back-end e outro tambm deve usar SSL ou outras tecnologias de criptografia.

10 - Unvalidated Redirects and Forwards Considere qualquer um que pode enganar os usurios para submeter um pedido para o seu site. Qualquer site ou alimentao HTML outros que seus usurios utilizam poderia fazer isso. Ligaes atacante invalidado redirecionar vtimas e truques para clicar nele. As vtimas so mais propensos a clicar sobre ele, desde que a ligao para um site vlido. Atacante metas inseguro frente para ignorar as verificaes de segurana. Aplicaes frequentemente redireccionar os utilizadores para outras pginas, ou utilizar para a frente interna de um modo semelhante. s vezes, a pgina de destino especificado em um parmetro de no validadas, permitindo que atacantes para escolher a pgina de destino. Detectando redirecionamentos desmarcados fcil. Procure redirecionamentos onde voc pode definir a URL completa. Encaminha desenfreadas so mais difceis, uma vez que segmentar as pginas internas. Tais redirecionamentos pode tentar instalar vtimas de malware ou truque para revelar senhas ou outras informaes confidenciais. Encaminha inseguras podem permitir desvio de controle de acesso. Considere o valor de negcio de manter a confiana de seus usurios. E se eles so de propriedade de malware? E se os atacantes podem acessar internas nicas funes? Ataque Exemplo cenrios Cenrio # 1: A aplicao tem uma pgina chamada "redirect.jsp" o que leva um nico parmetro chamado "url". O atacante artesanato uma URL maliciosa que redireciona os usurios para um site malicioso que executa phishing e instala malware. http://www.example.com/redirect.jsp?url=evil.com Cenrio # 2: O aplicativo usa para a frente a encaminhar pedidos entre as diferentes partes do local. Para facilitar isto, algumas pginas usar um parmetro para indicar onde o usurio deve ser enviadas se uma transao for bem sucedida. Neste caso, o invasor artesanato uma URL que vai passar o controle do aplicativo de acesso verificar e, em seguida, encaminhar o atacante para um administrativo funo que ela normalmente no seria capaz de acessar. http://www.example.com/boring.jsp?fwd=admin.jsp Eu sou vulnervel? A melhor maneira de descobrir se um aplicativo tiver qualquer invalidado redireciona ou encaminha : 1. Examine o cdigo para todos os usos de redirecionar ou para a frente (chamado uma transferncia em. NET). Para cada uso, identificar se o URL de destino includo em quaisquer valores de parmetro. Se assim for, verificar o

parmetro (s) so validados para conter apenas uma permitido destino, ou elemento de um destino. 2. Alm disso, o site de aranha para ver se ele gera todos os redirecionamentos (HTTP resposta cdigos 300-307, tipicamente 302). Olhar para Os parmetros fornecidos antes da redireccionado para ver se eles parecem ser um alvo URL ou um pedao de tal URL um. Se assim, alterar o URL de destino e observar se o site redireciona para o novo alvo. 3. Se o cdigo no estiver disponvel, verifique todos os parmetros para ver se eles olha como parte de um redirecionamento ou encaminhar o URL de destino e testar aqueles que o fazem. Como fao para evitar isso? O uso seguro de redirecionamentos e encaminha pode ser feito em um nmero de maneiras: 1. Basta evitar o uso de redirecionamentos e encaminhamentos. 2. Se for usado, no envolvem parmetros do usurio para o clculo do destino. Isso pode ser feito normalmente. 3. Se os parmetros de destino no podem ser evitados, assegurar que o valor fornecido vlido e autorizado para o usurio. Recomenda-se que quaisquer de tais parmetros de destino ser um valor de mapeamento, ao invs de o URL real ou parte da URL, e que o cdigo do lado do servidor traduzir esse mapeamento para o URL de destino. Os aplicativos podem usar para substituir a ESAPI sendRedirect () mtodo para garantir que todos redirecionar destinos so seguros. Evitar tais falhas extremamente importante, eles so um dos alvos prediletos de fraudadores que tentam ganhar a confiana do usurio.

A1-Injeco Falhas na injeo, tais como SQL, sistemas operacionais e injeo LDAP, ocorrem quando os dados no confiveis enviado a um intrprete como parte de um comando ou consulta. Dados hostis do atacante pode enganar o interpretador para executar comandos mal intencionados ou acessar dados no autorizados. A2-Cross Site Scripting (XSS) Falhas XSS ocorrem sempre que uma aplicao obtm as informaes no confiveis e envia para um navegador da Web sem a devida validao e escapar. O XSS permite aos atacantes executarem scripts no navegador da vtima que pode seqestrar sesses de usurios, sites desfigurar, ou redirecionar o usurio para sites maliciosos. A3-quebrado de autenticao e gerenciamento de sesso Funes relacionadas com a aplicao de autenticao e gerenciamento de sesso no so freqentemente implementados corretamente, permitindo que atacantes comprometam senhas, chaves ou tokens de sesso explorar falhas de implementao outros a assumir identidade de outros usurios. A4-Insegura Direta referncias de objeto A referncia de objeto direto ocorre quando um desenvolvedor expe uma referncia a um objeto de implementao interna, como um arquivo, diretrio ou chave de banco de dados. Sem uma verificao de controle de acesso ou outra proteo, os atacantes podem manipular estas referncias para acessar dados no autorizados. A5-Cruz do Site Request Forgery (CSRF) Um ataque CSRF fora um registrados no navegador da vtima para enviar uma solicitao HTTP forjado, incluindo cookies da vtima sesso e qualquer outra informao de autenticao automaticamente includo, para uma aplicao web vulnervel. Isso permite que o invasor forar o navegador da vtima para gerar pedidos da aplicao vulnervel pensa so pedidos legtimos da vtima.

A6 Security Misconfiguration Boa segurana requer ter uma configurao segura definida e implantada para a aplicao, frameworks, servidor de aplicaes, servidor web, servidor de banco de dados e plataforma. Como muitos no so mantidos como padres de segurana todas essas configuraes devem ser definidas, implementadas e isso inclui manter todos os softwares atualizados, incluindo todas as bibliotecas de cdigo utilizados pela aplicao. A7- Insecure Cryptographic Storage Muitas aplicaes web no protegem adequadamente seus dados sensveis, tais como cartes de crdito, SSNs e credenciais de autenticao, com criptografia apropriada ou hash. Os atacantes podem roubar ou modificar dados to mal protegidos para realizar roubo de identidade, fraude de carto de crdito, ou outros crimes. A8- Failure to Restrict URL Access Muitas aplicaes web devem verificar direitos de acesso de URL antes de tornar as ligaes protegidas. No entanto, os aplicativos precisam realizar o controle de acesso semelhante para verifica cada vez que essas pginas so acessadas, ou os atacantes sero capazes de forjar URLs para acessar essas pginas escondidas de qualquer maneira.

A9- Insufficient Transport Layer Protection Aplicaes freqentemente no conseguem autenticar, criptografar e proteger a confidencialidade e integridade de trfego de redes sensveis. Quando o fazem, por vezes, suportam somentes alguns algoritmos fracos que usam certificados expirados ou invlidos, ou usados incorretamente.

A10- Unvalidated Redirects and Forwards Aplicativos da Web freqentemente redirecionam e encaminham os usurios para outras pginas e sites, utilizando dados no confiveis para determinar as pginas de destino. Sem validao adequada, os atacantes podem redirecionar vtimas a sites de phishing ou malware, ou encaminhar para acessar pginas no autorizadas.