Protegendo Sua Aplicação - Mini Livro - Uaihebert

http://uaihebert.
com/protegendo-sua-aplicacao-mini-livro
Sumrio
No que se baseia segurana? .................................................................................................... 3 Publico Alvo ............................................................................................................................... 5 Ataques Internos.................................................................................................... 5 Ataque interno proposital ....................................................................................... 6 Concluso.............................................................................................................. 6 Um bom hacker sempre tem tempo ......................................................................................... 7 Cuidado com a informao retornada .................................................................... 7 Cuidado com o tamanho da mensagem retornada .............................................. 10 Firewall/SSL no faz mgica................................................................................ 10 Tipos de ataques e sugestes para evit-los........................................................................... 11 SQL Injection ....................................................................................................... 11 JPQL Injection e HQL Injection ............................................................................ 12 Cross-Site scripting (XSS) ................................................................................... 13 Brute Force Attack ............................................................................................... 14 Man In The Middle ............................................................................................... 16 XPath Injection .................................................................................................... 16 LDAP Injection ..................................................................................................... 17 DoS ou DDoS ...................................................................................................... 18 Slow DoS ............................................................................................................. 18 Cuidado com os dados ............................................................................................................ 19 Protegendo a entrada de dados........................................................................... 19 Protegendo a sada de dados .............................................................................. 19 Cuidados com o Client Side.................................................................................................. 22 Fique atento a URL.............................................................................................. 23 Testes Tcnicos................................................................................................... 24 Validaes ............................................................................................................................... 24 Validando dados .................................................................................................. 24 Cuidado com arquivos ......................................................................................... 25 Sempre d o menor privilgio possvel ................................................................................... 25 Trate os erros do projeto ........................................................................................................ 27 Cuidados com bibliotecas de terceiros ................................................................................... 28 Verso do Projeto.................................................................................................................... 29 Preste ateno com o LOG ...................................................................................................... 29 Separe seu projeto das camadas ............................................................................................ 30 Comentrios nem sempre so saudveis................................................................................ 31
http://uaihebert.com/protegendo-sua-aplicacao-mini-livro Sempre valide seu cdigo........................................................................................................ 31 Tenha um CheckList ................................................................................................................ 32 Cuidado com a equipe de TI .................................................................................................... 32 Exposio dos dados ........................................................................................... 33 Cuidado com o cdigo escrito .............................................................................. 34 Futuro ex-funcionrio.............................................................................................................. 34 Code Review / Pair Programming ........................................................................ 34 Fique atento a terminologia ................................................................................. 35 Proteja a senha do modo correto ........................................................................................... 35 Boas prticas para controle de acesso .................................................................................... 36 Esconda o boto/link, mas proteja o cdigo ......................................................... 36 Conhea a necessidade do seu usurio .............................................................. 37 Sempre oculte ..................................................................................................... 37 Polticas de Segurana............................................................................................................. 38 Evitando falhas de cdigos e/ou frameworks ......................................................................... 39 No exponha tecnologias desnecessariamente ................................................... 39 Nunca misture os tipos ........................................................................................ 39 Utilize chaves nos IFs........................................................................................ 39 Inteiros com Flutuantes........................................................................................ 40 Sempre programe defensivamente ...................................................................... 40 Por hoje s ............................................................................................................................ 42
http://uaihebert.com/protegendo-sua-aplicacao-mini-livro
No que se baseia segurana?

Infelizmente falar de segurana de projetos no simples, esse termo um termo muito amplo e possvel encontrar diversas definies. Umas definies interessantes so da Microsoft (links no final) sobre o que abranger quando falamos de segurana de projetos. Abaixo podemos listar as bases da segurana de projetos citadas pela Microsoft (haver comentrios e linhas a mais que eu escrevi abaixo):
Autenticao: Quem voc? Essa ao determina se a chamada ao nosso projeto vem de uma fonte conhecida. Uma fonte conhecida poderia ser uma pessoa, um celular, um browser, um hacker, etc. Existem diversos projetos que no necessitam de um login, por exemplo: Google, uaiHebert.com, etc. No s por que uma requisio est sem dados de login (usurio autenticado, login, senha, etc), que ela no pode ter um perfil conhecido. Para requisies de usurios no logados um perfil como NAO_LOGADO seria ideal. As vantagens de ter um perfil para quem no est logado seria:
o
Podemos ter uma linguagem em comum na hora de debates sobre o projeto, a seguinte frase poderia aparecer: essa nova funcionalidade poderia ser acessada por um NAO_LOGADO?. O perfil NAO_LOGADO poderia ser filtrado em determinadas reas do projeto: Perfil NAO_LOGADO no poder ter acesso a tela X. Em caso de auditoria poderamos ter diversos registros de navegaes salvos para algum do perfil NAO_LOGADO.
Autorizao: Voc pode fazer isso? Uma chamada que vem de um perfil conhecido (ou no no caso de usurios de perfil NAO_LOGADO) e que foi validada por um processo de autenticao, pode ou no realizar determinada ao. Um usurio poderia apenas ter acesso de leitura, enquanto um gerente poderia ter acesso as aes de CRUD do projeto. Falhas de autorizaes poderiam levar a gravssimos problemas, perda de dinheiro para a empresa, quebra de confiana para com o usurio, etc. Auditoria: Haver quem fiscalize o projeto? O que ser fiscalizado? Existem projetos que colocam todas as informaes do projeto (dados do request, dados do usurio, etc) em um banco de dados/arquivos de texto e, ao acontecer algum problema, colocam algum funcionrio para analisar aquela quantidade enorme de registros. Muitas vezes a enorme massa de dados causa preguia/indisposio na hora de buscar algum problema, o que pode ocasionar erros na procura de falhas de segurana. Sempre deixar disponvel para o auditor (seja um profissional em auditoria ou um desenvolvedor) as informaes de um modo bastante direto e objetivo. Salvar as informaes importantes em lugares separados importante para conseguir analisar uma possvel fraude, por exemplo, um cliente que alega que no solicitou a troca de plano e processa a empresa. Note que o trabalho de auditoria pode vir a ajudar na questo da segurana e na questo da evoluo do projeto.
Confidencialidade: tambm conhecida como privacidade, confidencialidade o conceito de somente ter acesso a determinada informao somente quem pode ter. Uma pessoa s poder ver as fotos de outra se for permitido. Outra preocupao tambm : os dados esto protegidos na hora do envio e do recebimento da informao? Estamos protegendo a informao de modo que ningum no meio do caminho consiga roubar a informao? Veja a imagem abaixo:
Qual a garantia que temos de que a informao enviada a mesma recebida? O que precisamos fazer para que o User Request Data no seja interceptado? preciso ter o cuidado de proteger as informaes enviadas pelo usurio, no deixar que nenhum dado confidencial seja exposto.
Integridade: A informao recebida est exatamente ao que o foi enviado? Imagine que uma pessoa, cheia de maldade no corao, interceptou um request enviado por um usurio e alterou o email enviado (usu@rio.feliz.com) para o email dele (pur@maldade.com). A partir da todos os comunicados que seriam recebidos pelo nosso usurio feliz iriam para o hacker do mal; uma vez que o hacker tenha em mos os comunicados enviado e ele poderia simplesmente encaminhar o email para nosso usurio feliz e continuar com a farsa. preciso sempre ter certeza de que a informao enviada chegue completa e sem alteraes. Disponibilidade: a aplicao sempre deve estar disponvel para requisies de chamadas confiveis. Durante um ataque de DoS (veremos mais a frente) preciso manter o servio disponvel para os usurios confiveis e de algum modo impedir que o projeto falhe.
Note que os conceitos vistos tratam os aspectos de como a aplicao deve se comportar, mas e com relao aos funcionrios que trabalham com a aplicao? Como devemos tratar ataques internos? Que tipo de cdigo pode prejudicar a segurana do nosso projeto? Todos os pontos vistos acima e as perguntas levantadas nesta pgina sero detalhadas mais a frente nesse post.
Publico Alvo
Toda vez que um desenvolvedor for criar um projeto ou at mesmo aumentar a segurana de um projeto existente, necessrio levantar qual ser o pblico alvo do projeto. Um projeto que aberto para o mundo precisa ter mais cuidados do que um projeto que rodar em uma intranet sem acesso externo. Essa informao necessria para um levantamento de requisitos mais aproximado da realidade. Um projeto que rodar apenas em uma Intranet inicialmente no teria a necessidade de uma proteo contra Brute Force ou XSS, por exemplo, no comeo do projeto. Caso o projeto fique acessvel para toda internet, seria necessrio pensar em todas as possibilidades de ataques e o que fazer quando eles acontecerem. Ataques Internos preciso sempre pensar que ataque interno pode acontecer. Podemos pensar em ataque interno em duas categorias: acidental e proposital. Um ataque interno acidental seria quando um usurio inexperiente poderia clicar em um arquivo zipado chamado alterarSenhaDoBanco.exe. O melhor jeito de tratar esse problema seria pensando: que tipo de dano esse ataque me causaria. Alguns pontos a se pensar so:
A mquina do banco de dados e/ou servidor do projeto est exposta a um usurio inexperiente? Um usurio consegue fazer um ping ou acessar a mquina via FTP, SSH ou por pastas? A mquina tem todas as portas de comunicao abertas? Uma soluo seria deixar habilitada, para todos os usurios do projeto, apenas a porta 80 ou 8080 ou a porta que realmente utilizada.
O projeto tem um local de backup em comum com usurios inexperientes? O ideal ter ambientes separados para evitar que um hacker no copie dados do usurio e da aplicao. Imagine o dano que um virus DELETE ALL poderia fazer em seus backups.
Da rede local possvel que qualquer um abra um tnel para outra rede? Uma soluo para esse tipo de problema : utilizar firewall para evitar que esses tipos de conexes no sejam facilmente iniciadas; usurio que no precisam de tnel no precisam desse recurso liberado.
Se possvel deixe o projeto em uma rede separada. O projeto em uma rede e ambientes separados dos demais usurios da empresa evitar ataques internos acidentais.
Ataque interno proposital Pode haver tambm o chamado ataque interno proposital. Esse tipo de ataque pode partir de um funcionrio que est com raiva com a empresa, algum funcionrio que quer tirar proveito de alguma situao ou at mesmo prejudicar outro funcionrio. Um funcionrio que no do setor de TI, mas que pode entender de programao, poderia por exemplo, aumentar seu banco de horas apenas com um update; tudo que ele precisaria seria a URL do banco de dados e disparar um Brute Force Attack at encontrar uma senha vlida. E voc acha difcil algum conseguir roubar a URL do banco? Bastaria ele puxar papo com algum de TI, falar que est interessado em projetos + banco de dados e se mostrar simptico. Em pouco tempo o usurio maldoso estaria sentado ao lado de algum de TI, observando tudo apenas para aprender como o dia a dia de algum de TI. E facilmente ele conseguiria ver a URL de conexo e at mesmo ter acesso a senha. Proteja a TI de funcionrios de outros setores. S por que a pessoa a dona da empresa, e no entende nada de TI, que ela precisa ter usurio e senha a todos os ambientes da empresa; caso voc seja obrigado a dar acesso, usurio, senha a pessoas fora do setor deixe isso claro por emails, memorando ou papeis que deixem algum ciente da responsabilidade. Assim voc estar protegido contra problemas futuros de roubo de senhas ou uso indevido. Concluso A vantagem de se determinar quem o pblico alvo que voc ter idia do que deve entrar no planejamento do projeto, e em qual etapa. Quando o projeto acessado apenas de uma rede fechada, algumas features de segurana podem ser postergadas ou at mesmo ignoradas; uma proteo contra o ataque XSS (veremos ainda nesse post) poderia ser entregue nas etapas finais do projeto, por exemplo. Quando temos um projeto aberto ao mundo preciso ter cuidado em sempre ter presentes protees contra os ataques. Proteo contra XSS, por exemplo, seria primordial no comeo do nosso projeto. Um projeto recm lanado que j apresenta problemas de invases ter dificuldades em obter credibilidade e confiana do usurio.
Um bom hacker sempre tem tempo

Certa vez enquanto eu participava de um curso sobre segurana ouvi a seguinte afirmao do especialista: at mesmo a menor variao no nmero de bytes retornado na resposta de um request feito ao servidor ser analisado por um hacker. Um bom hacker ter a pacincia de escovar os bytes retornados, HTTP Headers, campos escondidos e qualquer outra informao que possa ser vlida. Analisando a afirmao acima possvel pensar no seguinte: o que nossos projetos tm retornado aos usurios? ou quando uma RuntimeException acontece, qual a resposta enviada ao usurio?. Quando eu falo de resposta ao usurio eu no digo apenas o texto exibido, mas digo tambm sobre headers, campos escondidos, etc. preciso estar atento a esses detalhes, pois um bom hacker vai gastar seu tempo investigando cada detalhe do seu projeto. Supondo um projeto onde apenas a tela de login seja possvel acessar sem um usurio e ou senha vlida, veja algumas coisas que um hacker poderia analisar ou tentar (veremos mais a frente):

SQL Injection XSS Bytes recebidos Variao das mensagens recebidas Brute Force Attack Campos escondido
Note que apenas com uma pgina diversos tipos de ataques e anlises de dados podem acontecer. Cuidado com a informao retornada preciso sempre analisar a informao que retornada ao usurio. No comeo da internet era muito comum encontrar a seguinte mensagem ao errar o usurio na hora do login: usurio incorreto; a mensagem vista poderia levar um hacker a tentar alterar o usurio at certar um, que seria quando a seguinte mensagem apareceria: senha incorreta. O problema agora que um hacker j conseguiu ter um login vlido ao nosso projeto, bastaria tentar diversas senhas at conseguir uma vlida. O problema visto acima seria facilmente resolvido com a mensagem: usurio e/ou senha invlidos. Note que no foi preciso aumentar a proteo do cdigo ou at
mesmo criar diversas regras de segurana. Um hacker nunca saberia se ele conseguiu ou no um login vlido por causa da mensagem acima. Outro problema de mensagem retornada seria que, ao excluir um usurio, exibir um texto como: Voc no tem permisso para excluir um registro. Apenas usurio com o papel de ADMIN pode excluir. necessrio mesmo que um usurio fique sabendo que existe o papel de ADMIN? Por que expor o modelo de negcio do projeto sem necessidade? Voc poderia ter uma mensagem como: Voc no tem permisso para excluir ou at mesmo No foi possvel excluir o registro agora, caso o erro persista, entre em contato por email e informe o cdigo 3345981UAI. A vantagem da segunda opo que voc vai ter idia de qual usurio est tentando fazer alguma ao ilegal, pois ele vir at voc. Um exemplo que encontrei recentemente foi do jogo Candy Crush. Uma amiga ao jogar encontrou a seguinte mensagem de erro:
Veja que foi exibido a URL que o aplicativo utiliza para fazer a conexo com o servidor. Era necessrio mesmo? Por que um usurio precisa ver essa mensagem to tcnica? O que uma pessoa que entende alguma coisa de programao poderia
fazer com essa mensagem? Ele poderia simplesmente disparar diversas chamadas e encontrar falhas de segurana. Por curiosidade eu chamei a URL no browser e olha o que foi retornado:
Qual a necessidade disso? Expor todos os mtodos da classe? Se quando eu chamei a URL sem parmetros toda essa informao me foi passada, o que aconteceria seu eu comeasse a passar parmetros na URL? Um bobeira de uma mensagem de erro no tratado pode causar graves problemas ao seu projeto.
Cuidado com o tamanho da mensagem retornada preciso ter cuidado com o tamanho da mensagem retornada ao usurio. Imagine que toda vez que algum erro acontea, o usurio ser levada a uma tela que exista apenas o texto: desculpe, aconteceu um comportamento inesperado. Independente do erro o usurio sempre ir para a mesma tela com a mesma mensagem, ou algo bem prximo variando apenas uma pequena poro do texto. Apesar da soluo de tela com uma mensagem ser uma tima soluo, um bom hacker analisar a quantidade de bytes retornados em cada resposta; com essa informao em mo ele poder realizar diversos tipos de erros e testes para descobrir o que pode estar variando nos bytes retornados, em que caso ele poderia causar dados corrompidos no projeto ou at mesmo se ele conseguiria derrubar o projeto provocando erros. Um modo para tratar a mensagem retornada sempre ter uma tela/campo padro variando apenas o texto exibido, validar se os headers enviados so sempre os mesmos e sem nenhuma informao desnecessria. Firewall/SSL no faz mgica Existem pessoas que pensam que com um bom firewall e utilizando SSL (HTTPS na URL) j esto com seus problemas resolvidos, afirmar isso um erro enorme. Firewall configurado corretamente pode impedir hackers de invadirem a rede, navegar no servidor, etc. Ao utilizar SSL (HTTPS) podemos evitar o ataque do tipo Man in the Midle (veremos na prxima pgina). So duas ferramentas muito boas pare evitar determinados tipos de ataque, mas existem diversos outros tipo que facilmente passariam por essas defesas: Injection (SQL, XPATH, LADP), XSS, dados incorretos enviados, falha em regras de negcio por cdigo no corretamente programado, etc. Tome cuidado ao achar que a responsabilidade proteo do projeto deve ficar apenas na Infra. Creio que toda a equipe do projeto deveria ser envolvida quando o assunto segurana.
Tipos de ataques e sugestes para evit-los

Vamos detalhar agora sobre ataques famosos que podem acontecer e como fazer para proteger nossos projetos. Infelizmente em pouco tempo essa lista vai estar desatualizada, pois o hacker sempre estar um passo a nossa frente Sempre! SQL Injection Creio que esse o ataque mais famoso e muito utilizado. Podemos considerar que um projeto que est vulnervel a esse ataque precisa urgentemente de alteraes em seus cdigos e seus desenvolvedores tambm necessitam de um treinamento bsico sobre segurana. Assim como esse erro um erro bobo de acontecer, para evit-lo muito simples. Veja o cdigo a seguir:
public Customer findCustomer(String customerName)throws Exception {
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
try { Connection conn = null; String url = "jdbc:mysql://133.144.5.177:4405/"; String dbName = "project"; String driver = "com.mysql.jdbc.Driver"; String userName = "root"; String password = "root"; try { Class.forName(driver).newInstance();
conn = DriverManager.getConnection(url + dbName, userName, password)
Statement st = conn.createStatement(); String query = "SELECT * FROM
customer where customer_name=" + cust
ResultSet res = st.executeQuery(query);
Customer customer = buildCustomer(res); return customer; } catch (Exception e) { throwDataBaseError(e); } } finally {
http://uaihebert.com/protegendo-sua-aplicacao-mini-livro 20 21 22 23 24 25
} } conn.close();
O problema est justamente quando temos a concatenao de String: customerName= + customerName. Esse cdigo funciona perfeitamente se o usurio escrever apenas o nome dele como devido: Jos. Agora, e se o hacker colocar como nome dele o seguinte valor: Jos or Maria. O que aconteceria? Seria retornado o cliente Jos e Maria ao mesmo tempo. O que aconteceria se ao invs de colocar or Maria fosse feito um comando SQL como delete ou update? Todos os usurios existentes no projeto seriam retornados. Uma grave falha de segurana que poderia acontecer, mas que pode ser facilmente solucionada com o cdigo abaixo:
1 2 3
preparedStatement.setString(1, customerName); PreparedStatement preparedStatement = conn.prepareStatement("SELECT * FROM
cust
Agora est sendo utilizada a classe PreparedStatement para a consulta, e ela no entender o texto Jos or Maria como comando de consultas mas sim como um texto simples. E por mais simples e funcional que o ataque aparenta ser, mais ainda simples o modo de como evitar, grandes empresas/instituies j tiveram dados roubados por causa desse ataque. Grandes quais? Governo Americano, Sony, Nokia, Linkedin, Yahoo E isso desde o ano passado at o dia de hoje que fomos informados pela mdia. Na URL a seguir possvel encontrar uma listagem de grandes empresas que sofreram com esse ataque:http://codecurmudgeon.com/wp/sql-injection-hall-ofshame/. JPQL Injection e HQL Injection Existem pessoas que se acham seguras por utilizar o JPA (ou o Hibernante puro). Saiba que essa sensao de segurana invlida e voc estar sujeito a um ataque. A JPQL abaixo poderia sofrer com injeo:
1
String queryText = select c from Customer c where c.name = + customerName;
Note que o mesmo problema de concatenar String acontece tambm com JPA/Hibernate. Para solucionar esse problema com JPA basta utilizar parmetros na consulta, assim como feito com JDBC:
1 2 3 4 5 6 7
List<Customer> customers = query.getResultList(); query.setParameter("name", customerName); TypedQuery<Customer> query = em.createQuery(queryText, Customer.class); String queryText ="SELECT c FROM Customer c where c.name = :name";
No importa a tecnologia que voc est utilizando para acessar o DB, sempre tenha em mente concatenar String muito perigoso. Cross-Site scripting (XSS) Esse tipo de ataque acontece quando os dados enviados ao projeto no so tratados. Imagine um input onde o usurio pode salvar no banco de dados seu nome. Um usurio sem ms intenes digitaria o nome, Jos por exemplo, e o projeto se comportaria sem problemas ao exibir o nome dele. Imagine agora que o um hacker ao invs de escrever o nome dele, simplesmente escreveria algo como: <script>alert(uai?)</script>. O que aconteceria quando o nome desse usurio fosse listado na pgina com o comando: ${usuario.nome}? O script inserido pelo usurio no lugar do nome seria executado pelo browser, pois ao invs de exibir um nome ele estaria escrevendo na pgina um comando javascript. exatamente desse modo que funciona o XSS, injetando cdigo Javascript em seu projeto e fazendo com que seu projeto execute esse cdigo para diversas outras pessoas. Um exemplo disso aconteceu com o Twitter onde pessoas comearam a twittar coisas sem querer (http://status.twitter.com/post/1161435117/xss attack-identified-and-patched). Existem diversos tipos de XSS: persistente, no persistente, refletido, etc. No veremos como cada um funciona, mas veremos na prtica como resolver esse problema independente do tipo do ataque. O primeiro pronto a se tratar para esse tipo de problema justamente a hora de exibir as informaes para o usurio. Se utilizarmos apenas ${texto} para exibir as
informaes estaremos sujeitos ao ataque; o browser pegar o valor do ${texto} e exibir para o usurio como se fosse um cdigo HTML; caso o valor vindo seja um script javascript esse script ser executado normalmente. Para evitar esse primeiro problema simples, voc poderia utilizar a funo de escape. Se fosse no JSF, poderia ser feito como:
1
<h:outputText value=#{usuario.nome} />
E para os que trabalham com Struts, SpringMVC, Stripes ou qualquer outro framework ActionBased bastaria utilizar o cdigo abaixo para evitar o ataque XSS, o detalhe que apenas a biblioteca core JSTL foi utilizada:
1 2 3
<c: out value=${usuario.nome} /> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Com a simples soluo acima j seria possvel evitar o problema do XSS, e nenhum Javascript malicioso seria executado. E quando seu front end no est usando nenhum framework como SpringMVC ou JSF? Nesse caso uma boa ajuda seriam frameworks que existem com essa funo. possvel utilizar utiliza frameworks Javascript que ajudam na hora de tratar uma String:
o o
AntiSamy https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project Coverity Security Library https://github.com/coverity/coverity-security-library
Outra opo tambm seria tratar o valor enviado em classes Java. O framework abaixo uma boa soluo:
o
jsoup http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer
E caso seja da vontade da equipe tratar o input de modo manual, bastaria criar um Filter JEE e analisar as Strings presentes no request. Caso algum comando Javascript seja encontrado bastaria tratar o input do modo desejado. Brute Force Attack Esse tipo de ataque quando um hacker que descobrir determinada informao por meio de diversas tentativas.
Imagine que um hacker sabe que existe o usurio jose.de.arimateia cadastrado no projeto. O hacker tentaria diversas senhas ou diversas combinaes de letras para tentar descobrir a senha vlida. Um usurio chamado jose.de.arimateia talvez seja difcil ter em seu projeto, mas e um usurio chamado admin, administrador, root, etc. Um hacker poderia fazer um projeto que tentasse senhas como: a, ab, abc, abcd Um hacker tem todo tempo do mundo para deixar o cdigo rodando e, eventualmente, descobrir a senha. Outro modo interessante de que possvel encontrar sites que mostram quais so as senhas mais utilizadas no mercado:

http://www.telegraph.co.uk/technology/internet-security/10303159/Most-common-andhackable-passwords-on-the-internet.html http://www.cbsnews.com/news/the-25-most-common-passwords-of-2012/
Sabendo quais so as senhas mais utilizadas no mercado um hacker poderia simplesmente tentar essas senhas. Caso no tenha sucesso ele poderia tentar outro usurio at encontrar um. Um hacker que descobre o padro do nome de usurio das empresas poderia facilmente realizar um ataque para cada funcionrio. Como descobrir a lista de funcionrios de uma empresa? Linkedin seria uma boa fonte de pesquisa. Todos os funcionrios no estaro listados no Linkedin, mas basta que apenas 1 funcionrio tenha sua senha nas listas dos links acima para que a segurana seja quebrada. O projeto que utilizar uma criptografia fraca em seu banco de dados estar sujeito a um maior dano caso seus dados sejam roubados. Imagine que um hacker consiga roubar todo os logins e suas respectivas senhas criptografadas com MD5. MD5 hoje no uma criptografia segura, e pode ser facilmente quebrada. Existem sites que facilmente mostram o valor de um MD5: http://www.md5online.org/md5decrypt.html. possvel tambm encontrar diversos sites que listam senhas em MD5 j encontradas na net: http://forum.md5decrypter.co.uk/topic870mdhashed-passwords-list.aspx. Algumas aes podem ser tomadas para evitar um Brute Force Attack realizado em seu projeto:

Adicionar no site algum tipo de segurana de validao do usurio, algo como um CAPTCHA Definir uma quantidade de tentativas para logar. Se o usurio errar 5x a senha, ele no poder mais logar por um dia ou at entrar em contato com o suporte
A equipe de infra pode identificar se determinado IP est com muitas tentativas de login e bloque-lo por determinado tempo. Aumentar o tempo de retentativa de login. No primeiro erro o usurio j pode tentar novamente. Aps o segundo erro, ele ter que esperar 5s, etc.
Inclusive esse um tipo de ataque que pode vir junto do DoS (ou DDoS) que veremos mais a frente. Man In The Middle Man In The Middle quando uma pessoa consegue interceptar uma requisio feita a um servidor. Imagine que um usurio far uma requisio ao servidor e um hacker conseguir interceptar os pacotes enviados e ver o que foi enviado ou at mesmo alterar. Para evitar esse tipo de ataque basta utilizar SSL em suas conexes. Sabe quando voc acessa um site e no endereo aparece escrito HTTPS? Essa conexo segura serve para evitar que algum fique entre o servidor e o usurio. Essa proteo feita no servidor e no no cdigo. XPath Injection XPath Injection acontece quando dentro de um XML utilizado para validao de dados, uma informao maliciosa adicionada. Imagine que o XML abaixo utilizado para realizao do login:
1 2 3 4
<user> <username>uai@google.com</username> <password>ahuid98317</password> </user>
Imagine que o comando a seguir utilizado para realizao do login do usurio: //users/user[username/text()='&LOGIN&' and password/text()='&PASSWORD&' ]. Note que a partir de agora o mesmo problema do SQL Injection pode acontecer. Algum poderia simplesmente passar o login como Jos de Arimatia or 1=1 que o restante da consulta ser ignorado. Note que a consulta pararia sempre na condio 1=1 que sempre retornaria true e o password nunca seria validado. Para evitar esse tipo de erro sempre trate o valor enviado pelo usurio. No importa quem seja o usurio do projeto, o melhor nunca confiar na informao enviada pelo usurio.
Outra soluo seria utilizar o a biblioteca XQuery; ela funciona como o PreparedStatement ou a Query do JPA. Com a biblioteca XQuery possvel evitar que cdigos maldosos enviados pelo usurio no sejam processados. Caso voc quei-ra tratar manualmente os valores que esto chegando bastaria remover do request, enviado pelo usurio, os seguintes parmetros/caracteres (e similares):

< > / = = * ? /
LDAP Injection Assim como os outros ataques de injeo vistos acima, esse ataque tambm visa inserir caracteres invlidos. A soluo seria eliminar do request enviado pelo usurio valores que poderiam causar problemas. Veja a lista abaixo:

/ \ \\ Espao em branco no comeo e fim do valor # < > , ; + * ( ) \u0000 Unicode NULL caracter
DoS ou DDoS Voc j viu na mdia aqueles tipo de reportagens: Anonymous promete derrubar o facebook ou grupo hacker tira site do governo do ar? Em geral so ataques DoS que significam Denial of Service ou DDoS: Distributed Denial of Service. A cada requisio feita ao servidor uma sesso criada e o ID dessa sesso retornado ao usurio; quando esse usurio faz outra chamada ao servidor o ID da sesso enviado novamente e o servidor consegue identificar que uma sesso j existe e que no ser necessrio criar outra. Agora imagine se 100 requisies sem ID de sesso chegam O servidor criaria uma sesso para cada request que chegar e com isso teria 100 espaos na memria ocupados. E se comearem a chegar 100 requisies por segundo, quanta memria seria ocupada em questo de 30 segundos? Aps algum tempo, seu servidor ser derrubado por falta de memria por causa de todas as sesses criadas. A soluo para esse problema cabe muito ao pessoal da infra-estrutura e no a quem desenvolve o projeto. Eles poderiam desviar o fluxo de determinado IP ou faixa de IP para uma pgina esttica que no cria Sesso. Se for um usurio vlido ele clicar em um boto que o mandar para o projeto. Outra soluo seria bloquear o IP do ofensor. Slow DoS J o Slow DoS ao invs de enviar diversas requisies por segundo, ele envia requisies bem devagar. A entrega de pacotes enviados demora muito e isso faz com que o servidor fique com canais abertos esperando a entrega de todos os pacotes; uma vez que muitos canais esto sendo abertos, e nenhum canal sendo fechado, o servidor parar de responder. Novamente uma soluo que cabe ao pessoal de infra-estrutura agir. Eles podem ver o request que est demorando muito para chegar, at mesmo acima de uma determinada mdia, e abortar essa requisio. Podero tambm bloquear o IP do ofensor.
Cuidado com os dados

preciso ter todo o cuidado possvel com os dados do nosso projeto. Basta que uma informao maliciosa entre em nosso projeto para que possamos ter problemas de segurana. Problemas tambm acontecem quando dados problemticos so exibidos. Protegendo a entrada de dados Nunca confie no usurio! Essa frase deveria estar escrita em todo monitor de todo desenvolvedor. Proteger dados no significa apenas verificar se o usurio est tentando fazer algum tipo de Injection, mas significa tambm validao das regras de negcio. Imagine um aplicativo mvel que realiza a transaes financeiras com carto de crdito. O JSON enviado para confirmao de compra seria algo como:
1 2 3 4 5 6 7
{ customerId: 32, creditCardId: 446519, productId: 592-AAB, value: 42, descount: 5 }
Veja que no cdigo acima temos dados possveis para realizar a compra de algum produdo. Se nosso projeto fosse utilizado apenas por usurios confiveis, no haveria problema em receber essa informao e processar o pedido de compra. Como estamos partindo da premissa que no podemos confiar em qualquer informao enviada pelo usurio, o que garante que o customer de id 32 realmente tem o carto de id 446519? O que aconteceria se o customer 32 utilizasse o creditCardId=155? Ou ento, o que aconteceria se o request viesse com o discount = 50 ou 42? A compra sairia de graa? Ou seria necessrio retornar dinheiro para o usurio? Para segurana de outros usurios e dos dados do projeto sempre bom que toda informao enviada seja validada. Protegendo a sada de dados Por diversas vezes imaginamos que: basta proteger a entrada de dados que estamos salvos de qualquer tipo de ataque. Veja a imagem abaixo:
Uma imagem que demonstra um servidor que acessa apenas o seu prprio banco de dados. Imagine que uma nova rotina ser implementa onde o uaiServer buscar informaes de um servidor de uma empresa parceira.
O que no garante que o outro servidor que est sendo consultado no ter sofrido um ataque hacker? Voc simplesmente estaria importando dados maliciosos de outros projetos para dentro do seu. E outra situao tambm poderia acontecer:
Como visto acima possvel que outro projeto de sua empresa comece a chamar o mesmo banco de dados utilizado pelo seu projeto. O que no garante que dados maliciosos sero inseridos? possvel que o outro projeto tenha sofrido um ataque e agora est espalhando vulnerabilidades. Para evitar as situaes listadas acima seria necessrio tratar os dados enviados aos usurios seja em classe Java e/ou frameworks javascript e/ou taglibs como visto na pgina anterior.
Cuidados com o Client Side

Infelizmente diversos projetos no do a devida ateno ao lado cliente do projeto quando falamos de segurana. Empresas contratam equipes de testes para avaliar se a funcionalidade est sem defeito, se o boto est no lugar certo, mas geralmente no executam testes tcnicos (veremos mais a frente) para validar se o projeto est seguro. Existem cuidados simples que podemos tomar para podermos um lado cliente mais seguro. O primeiro cuidado que devemos ter : cuidado com regras de negcio no lado do cliente. Colocar validaes de inputs do lado do cliente normal e vlido, o problema quando essa validao expe regras de negcio. Veja a imagem abaixo:
O site acima um servio pblico disponvel em minha cidade, apenas com os campos alterados para que no seja identificado ( =P ). Vou cham-lo de UAI_SITE. Note que uma mensagem de erro exibida no UAI_SITE, mas no foi feita nenhuma chamada Ajax ao servidor. O campo que foi validado um ID do produto utilizado junto com o ID do usurio para criar um request vlido. A validao do cdigo do produto foi feita simplesmente utilizando Javascript e, com isso, um hacker tem acesso regra de negcio e facilmente conseguiria criar cdigos vlidos; tendo os cdigos vlidos em mo um hacker poderia fazer um Brute Force Attack para descobrir um user id vlido. Talvez o desenvolvedor no tivesse a maldade de expor a regra de negcio, ou at mesmo teve a boa inteno de poupar uma chamada ao servidor. Existem casos onde melhor ter uma chamada a mais em um servidor do que expor suas regras de negcio ao mundo. Veremos mais a frente neste post sobre validaes do lado do cliente. O segundo cuidado que devemos ter : todos os recursos devem ser carregados corretamente.
uma boa prtica ter validao de campos do lado do cliente, e em um projeto Web muito comum utilizar Javascript para realizar essas validaes. sempre bom validar se determinado campo est preenchido, se um formato de data est valido, se algum campo tem o tamanho mnimo necessrio, etc. Em alguns momentos podemos utilizar bibliotecas com cdigos prontos para facilitar essa rotina tediosa de verificar se um input est preenchido. O problema quando o cdigo Javascript no corretamente carregado. Veja a imagem abaixo do que aconteceu ao carregar o UAI_SITE:
Todas as validaes de dados que utilizassem alguma funo do JQuery no funcionariam. Toda vez que um projeto for para produo necessrio validar se no existem erros como de Javascript. O ltimo tpico que veremos : cuidado com informao salva no cliente. Um bom hacker vasculhar todas as pginas que tiver acesso procurando por campos escondidos. No seja inocente de achar que s por que o campo est escondido nada acontecer. Caso uma informao sensvel necessite ser retornada ao cliente, tenha a certeza de que essa informao est sendo criptografada ou realmente protegida de alguma forma. Tome cuidado quando dados do usurio esto sendo retornado para a tela. Um cuidado simples no retornar a senha do usurio para a tela. Enviar a senha em texto aberto para deixar um que input HTML ofusque o valor um erro grave, bastaria o hacker analisar a resposta enviada pelo servidor. Fique atento a URL Cuidado com dados que aparecem na URL. Nunca exponha na URL coisas desnecessrias, como por exemplo, usurio, senha, perfil do usurio ou cdigos da regra de negcios. Imagine a URL a seguir: http://site/user/2/profile/2
Um usurio poderia ficar tentado a trocar a URL acima para: http://site/user/2/profile/3, http://site/user/3/profile/2 e at mesmo para http://site/user/3/profile/3. Se nenhuma validao for feita haver falha de segurana. Um hacker poderia simplesmente navegar em todos os registros da aplicao. Note que para simular a falha acima no seria necessrio ser um hacker, um usurio sem conhecimento tcnico poderia alterar a URL e tentar explorar uma falha de segurana. Uma soluo para esse problema seria sempre validar se os valores que chegam so vlidos. Testes Tcnicos sempre bom ensinar a equipe de testes um modo para tentar burlar as regras de negcio. Mostrar a eles como burlar um JSON ou coisa parecida poderia ajudar a facilitar a detectar provveis erros de regra de negcio. Ferramentas como JMeter, Postman (plugin do Chrome) ou o Swagger so ferramentas fceis de usar e que poderiam ser manipuladas por algum que no entendesse de programao. Bastaria um rpido treinamento de como executar a chamada e como os dados devem ser criados e pronto, a equipe de QA poderia realizar diversos testes que a equipe de desenvolvimento pode ter deixado de fazer.
Validaes
necessrio tratar as informaes de nosso projeto como o bem mais valioso. Basta uma informao errada para termos dados corrompidos, relacionamentos quebrados, prejuzo financeiro, etc. Para tratar com o devido respeito os dados do nosso projeto precisamos sempre validar as informaes antes de salv-las. Precisamos ter a certeza de que nossas informaes esto com os dados necessrios. Mas, onde validar? Validando dados Primeiro lugar que sempre deve haver validao na camada de negcio. Note que eu disse camada de negcio e no no Controller. Existem desenvolvedores que o nico lugar que deixam validaes no Controller e isso um grande erro. Imagine que uma determinada regra de negcio deva ser utilizada para execuo de diversas rotinas, mas a chamada vem de outro Controller. Os dados podero ser persistidos corrompidos.
Validar se os dados esto validos apenas na camada de negcio nem sempre uma boa soluo, pois pode sobrecarrega-lo. Sempre tenha a validao do lado do cliente seja web, mobile, outro servio, etc. Entretanto, nunca confie que validao do lado do cliente ser suficiente. Validaes do lado do cliente podem ser facilmente burladas, e requisies, podero ser simuladas at mesmo de fora do projeto. A vantagem de ter a validao do lado do cliente : chamadas para verificar se determinado campo est vazio no sero disparadas para o servidor, mas sim resolvidas do prprio cliente. Sempre tenha cuidado ao validar suas informaes. Cuidado com arquivos muito comum ter sites que recebem arquivos enviados por usurios, s vezes, apenas fotos. Ser que o arquivo que acabou de chegar, realmente o que se espera? O que no garante que o arquivo que acabou de chegar no um executvel? Ou algum tipo de arquivo que poderia ser disparado por alguma rotina? Para burlar um upload de um arquivo bastaria trocar o header do request enviado e pronto, algum poderia enviar um arquivo EXE como se fosse um PNG. Para se proteger desse ataque necessrio que, antes de salvar o arquivo em disco, seja validado qual o tipo do arquivo que acabou de chegar. Uma tima opo para ajudar nessa validao utilizar o framework Apache Tika (http://tika.apache.org/). Esse problema pode acontecer caso o nvel de permisso utilizado para executar a aplicao seja muito poderoso, um usurio root por exemplo (veremos isso mais a frente). Finalizando, tome cuidado com arquivos que acabaram de chegar. Apenas limitar o tipo de arquivo (por exemplo, aceitar apenas *.png) no cliente e determinar o tipo de Content-Type para o request no suficiente. Essas protees podem ser facilmente burladas.
Sempre d o menor privilgio possvel

Infelizmente quando diversos projetos so criados nunca pensado em qual privilgio envolver o projeto. Ao falar de privilgio no projeto, vamos falar de tudo desde a infra-estrutura at o comportamento da aplicao.
Privilgio de usurios: no tem por que um usurio j comear tendo acesso a todas as reas do projeto e a recursos que ele nunca utilizar. O ideal programar
j sabendo ao certo o que o usurio pode ou no fazer/acessar. Uma vez que fique claro o papel de cada usurio dentro do projeto ficar mais fcil o QA (rea de testes) realizar o executar os testes, podendo apontar assim falhas de segurana. Sempre deixe o usurio trabalhar apenas com o que ele precisa, ele nem precisa saber que determinado MENU existe no projeto caso no seja ele o responsvel por administrar/acessar. Privilgio do servidor: quando nosso servidor executado ele executado com o perfil que dispara seu incio. Se voc faz login com o usurio jose.de.arimateia, e ele tem permisso de root, essa aplicao ser executada como root. necessrio mesmo que a aplicao rode como root? Imagine um projeto que recebe upload de fotos, mas um hacker envia um arquivo *.sh. Caso o projeto execute esse script o cdigo do arquivo *.sh ter a permisso de fazer o que quiser, pois ele tem o privilgio de root. Tome cuidado com a permisso dada ao servidor, preferencialmente, ele deve ter o poder de alterao apenas dentro de usa pasta e nada mais. uma m prtica utilizar um perfil de root (super user) para executar o projeto. Privilgio do banco de dados: assim como falado do privilgio do servidor, podemos falar com relao ao privilgio do banco de dados. Existe a necessidade de executar com privilgio root? Existem banco de dados que podem executar comandos no sistema operacional, e caso um hacker consiga realizar SQL Injection em seu projeto ele conseguiria fazer o banco de dados afetar o SO. Privilgio do desenvolvedor: todo desenvolvedor precisa de acesso em produo? Todo desenvolvedor precisa ter privilgio de root em rea sensveis da empresa? Em meu primeiro emprego na capital eu apaguei uma pasta de trabalho de uma semana inteira da equipe. Eu precisaria ter esse tipo de acesso? E quantas histrias j so conhecidas de perda de dados em produo por algum erro de desenvolvedor? Outro detalhe importante : a mquina do desenvolvedor deve acessar produo? Empresas podem ter prejuzo com desenvolvedor que tem acesso direto a produo, pois sem saber um desenvolvedor pode disparar um teste que afeta produo. Eu creio que um desenvolvedor possa ter acesso em produo para que ele possa analisar dados, procurar problemas, etc; eu tambm creio que todo desenvolvedor poderia ter apenas acesso de leitura tanto para o log do servidor como para o banco de dados, se necessrio.
Consideraes finais:
Sempre tenha mapeado quais diretrios seu projeto precisa acessar. Se seu servidor recebe upload de arquivos, deixe que o servidor tenha permisso apenas do seu diretrio e do diretrio que receber os arquivos. Um servidor com permisso exagerada poderia apagar arquivos de outros diretrios, escrever arquivos onde no
se deve ou at mesmo alterar variveis de projeto do servidor quando atacado com sucesso por um hacker. Cuidado com senhas fracas. Imagine que seu servidor pode ter sempre algum tentando acessar. Senhas fracas para o acesso ssh, acesso remoto ou at mesmo pelo prprio projeto poder servir de porta de entrada para um atacante. Cuidado com usurios muitos comuns. Quantos aqui j no viram um usurio chamado admin ou administrator em algum projeto? Ou ento no sistema operacional? Tenha cuidado com nomes de usurios fracos e simples, isso ser mais uma facilidade para um hacker disparar um DoS no projeto.
Trate os erros do projeto

Tenha a certeza de que nenhuma exceo aparecer na tela do usurio de modo no amigvel. A pior coisa possvel seria um stacktrace (mensagem de erro gerado pelo prprio projeto), aparecer diretamente ao usurio final. O tratamento de erro fundamental por dois motivos: 1. Perda de credibilidade. Um projeto que existe erros no tratados ao usurio perde a credibilidade, e qualquer problema que venha a acontecer o usurio dir que culpa do projeto mesmo que seja erro de negcio. Em que isso afeta o projeto? O usurio pode comear a usar o projeto de modo desleixado e adicionando dados incompletos; um usurio insatisfeito poderia simplesmente pensar: por que me dar o trabalho de fazer tudo certo se o projeto s mostra erro estranho o tempo todo?. 2. Prato cheio para hacker. Uma vez que um hacker tenha acesso ao cdigo detalhado de uma mensagem de erro, ele conseguir trabalhar em cima do projeto simulando erros e at mesmo vendo se na mensagem de erro contm dados importantes. At mesmo as grandes empresas podem cometer esse tipo de descuido. Veja a imagem abaixo:
Essa imagem de um site que pertence a Microsoft. Note que a ip do banco de dados, usurio, senha foram exibidos. Imagine o dano que essa falha poderia causar. Sempre trate os erros da aplicao (esperados ou no).
Cuidados com bibliotecas de terceiros

comum em projetos utilizarmos bibliotecas de terceiros, mas at onde levamos em considerao a segurana? J parou para pensar que nas bibliotecas que utilizamos podem haver Memory Leak (problema de estouro de memria em Java), falhas em consulta de banco de dados (SQL Injection) e outras coisas mais? Sempre fique atento a notcia dos frameworks de seu projeto. Conseguir notcias hoje em dia no difcil, basta querer. O framework Spring, por exemplo, tem um feed de notcias que pode ser seguido para atualizaes. Nem sempre atualizar necessrio, mas em alguns momentos, pode ser crtico. Fique atento aos repositrios utilizados. Existem pessoas que para utilizar determinada biblioteca no pensa duas vezes em adicionar um repositrio desconhecido ao projeto. Imagine se o servidor onde esse repositrio se encontra atacado. No lugar do JAR existente um hacker adicionar um JAR batizado. Uma entrada para ataque hacker poderia ser aberta em seu projeto sem ningum imaginar.
Verso do Projeto
comum em projetos desktop/mobile encontrar em algum lugar a verso do projeto definida. Para um projeto Web essa informao seria realmente necessria? Vamos tomar, por exemplo, o WordPress que uma plataforma famosa de blogs. Em sua verso 3.1.3 estava com uma falha de segurana onde um hacker conseguia fazer um SQL Inejction. Rapidamente uma nova verso foi lanada para corrigir esse problema, mas tomando por base que a verso 3.1.3 era conhecida por essa falha de segurana pergunto: o que impede que um hacker procure blogs que ainda esto na verso 3.1.3 e realize o ataque?. Tome cuidado ao expor a verso do seu projeto. Um hacker pode estar monitorando as verses do seu projeto, e poderia inclusive, mapear data e horrio comum de subidas do seu projeto. Aps uma subida de verso o melhor momento para se descobrir falhas de segurana.
Preste ateno com o LOG

comum encontramos projetos que tm um registro detalhado, de tudo que acontece, salvo em um arquivo LOG ou banco de dados; so registrados no arquivo de LOG os dados que vieram na requisio, estgios do processamento de uma requisio e a resposta ao request processado. Tenha cuidado para no registrar dados privados do tipo: senha do usurio ou nmero do carto de crdito ou at mesmo o CVV (nmero secreto que fica atrs do carto de crdito). Esses dados devem ser evitados de serem salvos em LOG por dois motivos: 1) Um funcionrio mal intencionado poderia pegar essas informaes e comear a utilizar erroneamente 2) Imagine se um hacker tivesse acesso aos arquivos de LOG
Uma prtica que pode ajudar no caso de arquivos de LOG roubados evitar salvar as entradas de erros como [ERROR] ou coisa do tipo. Se todas as entradas foram salvas apenas como [INFO] isso dificultar um hacker a encontrar os problemas e potenciais pontos de ataque do seu projeto.
Separe seu projeto das camadas

Existem diversos projetos que ao irem para produo vo dentro do mesmo artefato (no caso do Java, um arquivo do tipo war ou ear). Uma boa dica seria separar a camada de visualizao da camada de negcios em servidores diferentes. Vamos imaginar um projeto onde teremos dois artefatos sendo um para a VIEW e outro para o negcio. A VIEW ser responsvel para sempre responder os requests dos usurios, mesmo que o servidor de negcios esteja fora do ar. O servidor de negcios ser responsvel pelas regras de negcio e o acesso ao banco de dados. As vantagens de separar a camada de negcios da camada de visualizao so: 1) Em caso de ataque seria possvel bloquear j a parte de negcio modo mais rpido, sem ter que parar o acesso do usurio ao projeto. Uma mensagem de erro mais amigvel seria exibida ao invs de um 404 ou qualquer outro erro de indisponibilidade. Um hacker poderia conseguir acesso a maquina do projeto de view, mas ainda no teria o devido acesso a maquina das regras de negcios. 2) possvel fazer deploy separadamente. Caso uma correo fosse feita no cdigo de regras de negcio a view no precisaria parar para que o deploy de negcio fosse feito. 3) Ter mquinas separadas possibilita focar os melhores recursos de Hardware para a parte que est tendo mais trabalho. Existem vrias tcnicas possveis para realizar a comunicao entre view e negcio quando se encontram em camadas diferentes: RMI, SOAP, RESTFul (com XSTL ou sem). Para aqueles que j trabalham com o servio separado da VIEW necessrio ter o cuidado de no expor a mquina do servio diretamente para web, deixar que apenas a mquina da view fique em contato direto com a mquina de servio. Se necessrio disparar algum servio da mquina da servio, seja uma rotina ou at mesmo alguma consulta manual, pode-se criar acessos via SSH ou por VPN. Evite que seu servidor de servios tenha porta direta com a web, o ideal que a camada de view seja utilizada como Proxy.
Comentrios nem sempre so saudveis

possvel encontrar desenvolvedores que comentam tudo em seu cdigo, e, se possvel, comentariam o prprio comentrio. De acordo com o livro Clean Code o cdigo deve ser claro e fcil de ser lido, de modo que nem o comentrio seria necessrio para explicar o que acontece dentro do mtodo. No vou entrar em detalhes sobre boas prticas de programao, mas vou falar apenas que:comentrios podem ser nocivos ao projeto. Existem comentrios que podem levar a erros de programao ou levar informao do projeto para um hacker. O primeiro momento que um comentrio poderia ser nocivo quando o comentrio est desatualizado. Imagine que o seguinte comentrio encontrado em um cdigo: /* Mtodo que processar e salvar o registro no DB */. Imagine que um desenvolvedor faz uma refatorao desse mtodo para que seja apenas realizado o processamento, mas no comentrio no foi removido o texto que fala sobre salvar o registro no DB. Quem ler o comentrio vai acabar pensando que o mtodo faz duas coisas quando na verdade faz apenas uma. Outro problema de documentao em excesso quando comentrios so expostos no cdigo detalhando a regra de negcio. O problema dessa abordagem que na hora de empacotar o cdigo e enviar para produo um hacker poderia vasculhar o cdigo procurando por um comentrio que possa esclarecer algo. Quando o cdigo de uma classe java compilado seus comentrios so retirados, mas e quanto aos comentrios que esto presentes no HTML e arquivos XML? preciso ter cuidado com os comentrios que aparecero nos arquivos, e principalmente nos arquivos HTML pois qualquer um ter acesso ao que est escrito.
Sempre valide seu cdigo

Sempre utilize ferramentas que possam validar seu cdigo. Existem ferramentas grtis que fazem toda a validao do cdigo para aumentar o nvel de qualidade do projeto. Cito as seguintes ferramentas abaixo (conhecidas como analisadores de cdigo esttico):
FindBugs
PMD CheckStyle ESC/Java
As ferramentas citadas acima so gratuitas e servem para fazer anlises e mostrar pontos que poderiam gerar problema no cdigo. Essas ferramentas so customizveis podendo eliminar regras que no fazem sentido ao projeto. Existem plugins que podem adicionar essas ferramentas analisadoras a sua IDE. possvel tambm utilizar ferramentas de testes automatizados para validarem as regras de negcio e rodar os analisadores de cdigo esttico. possvel configurar frameworks como Sonar e Jenkins para realizar testes automatizados e tambm executar os analisadores de cdigos estticos. A configurao das ferramentas citadas acima pode dar trabalho, mas ao final do processo seu projeto estar mais protegido contra falhas de implementao.
Tenha um CheckList
importante sempre ter uma lista de validaes necessrias. Ao falar de CheckList podemos levantar os seguintes itens:
o o
Veja se todos os recursos foram carregados com sucesso arquivos Javascript, mdulos da aplicao, integraes do projeto Valide se as regras de negcio esto ativas: Regras que j foram quebradas devem ter uma maior ateno Quais configuraes bsicas de cada servidor? Ao subir um servidor novo tenha certeza de ter uma lista de configuraes necessrias. Validar variveis de ambiente, configuraes para load balance e demais ajustes podem ficar em uma lista de verificao.
A rotina de ps deploy, alm de um CheckList, poderia ter um caderno de testes para validao de regras de segurana, e a certeza de que nenhum bug foi adicionado. S por que todos os testes no apresentaram erros em DEV ou HOMOLOG no significa que erros no aparecero em produo.
Cuidado com a equipe de TI

importante sempre pensar que a equipe de TI pode se tornar uma porta de entrada para ataque hacker.
Exposio dos dados Pode acontecer que um funcionrio, sem querer, exponha informaes sensveis da empresa. Veja a triste histria abaixo:
possvel ver na imagem acima uma pessoa que acabou por expor usurio/senha e teve todo o banco de dados apagado. Imagine se a pessoa copiou o banco de dados antes de apagar? Qual seria o tamanho do dano? Infelizmente no possvel monitorar todas as atividades de todos os funcionrios, mas possvel orientar a equipe sobre o que poderia e o que no poderia ser postado em fruns. Eu no creio, e abomino a idia, de que bloquear a utilizao de fruns seja a soluo para esse problema. O ideal seria enviar um informativo equipe deixando claro para evitar colocar usurio/senha/caminho de banco de dados, etc. Cuidado com o cdigo escrito bom reforar atravs de bate papos que o que est sendo escrito no apenas um pedao de cdigo qualquer, mas sim algo importante que pode impactar todo o projeto. A cada dia que passa um desenvolvedor pode ficar mais insensvel com o cdigo que escreve e alguns detalhes comearem a escapar, bugs aparecer, etc. Sempre reforce a necessidade de um cdigo de boa qualidade.
Futuro ex-funcionrio
Esse um tipo de funcionrio que merece toda a ateno. Indiferentemente se a pessoa se demitiu ou foi demitida pela administrao preciso ter cuidado. Infelizmente j ouvi diversos relatos de ex-funcionrios que deixaram cdigos maliciosos no projeto, ou at mesmo porta de entrada nos servidores da empresa. Infelizmente em caso de demisso preciso que essa pessoa tenha seus acessos restritos imediatamente, e seus passos rastreados. Tome conta do seu projeto, afinal, o funcionrio sair e provavelmente voc ser responsvel pelo legado dele. Code Review / Pair Programming Infelizmente Code Review e Pair Programming so prticas no muito adotadas, mas que ajudam na proteo e evoluo do projeto. Code Review e Pair Programming so tcnicas de metodologias geis onde mais de um desenvolvedor fica responsvel pelo cdigo salvo no repositrio (procure na internet por mais detalhes, pois ambas as tcnicas tm comportamentos diferentes).
A vantagem de realizar o Code Review e/ou Pair Programming que conhecimentos so transmitidos e a questo de segurana passada de uma pessoa mais experiente em determinado assunto para outra pessoa mais novata. Essa uma prtica excelente para investir. Fique atento a terminologia Tenha cuidado para que uma regra de negcio ou funcionalidade no tenha mais de um termo, isso pode causar confuso. Imagine que a funcionalidade de desativar um usurio ser entregue na prxima verso do projeto, mas desenvolvedores comeam falar em: desativar usurio, apagar usurio, alterar perfil do usurio, etc. Diversos termos para a mesma funcionalidade/regra pode levar a erros de implementaes no futuro, pessoas podem achar que esto falando da mesma coisa quando na verdade no esto. Pode ser que um desenvolvedor esteja falando sobre apagar um usurio quando o outro acha que o assunto apenas desativar um usurio.
Proteja a senha do modo correto

Nunca salve senha de usurio em banco de dados sem estar criptografada. Uma senha no protegida por uma criptografia um dos piores erros que uma aplicao pode ter. Existem pessoas que criptografam senha um uma lgica criada por ele mesmo, e isso uma pssima prtica. O ideal utilizar algoritmos seguros que j existem no mercado para realizar a criptogafia. Existem algoritmos de criptografia que j foram validadas matematicamente por diversas pessoas como sendo segura; uma funo de criptografia caseira poderia ser facilmente quebrada. Ao usar uma funo de criptografia j existente no mercado possvel ter a certeza de que o cdigo seguro, e caso algum quebre, a notcia correr e ser possvel tomar medidas de proteo. preciso ter cuidado com algoritmos de criptografia fracos que j foram quebrados. Veja a listagem abaixo dos algortimos que j so considerados como desatualizados:
MD4
MD5 SHA Chaves simtricas com um tamanho menor que 128-bits ARC e RC4 (ou qualquer tipo de cipher stream) Block ciphers usado no modo Electronic Code Book (ECB)
Uma boa funo de criptografia seria a SHA-256 que ainda no foi quebrada e recomendada. Tome muito cuidado com MD5 que comumente utilizada em tutoriais encontrados na internet.
Boas prticas para controle de acesso

Existem projetos onde algumas aes ou reas que no devem estar acessveis a todos os usurios. Para determinar se usurios podem ou no acessar determinado recurso utilizado o conceito de perfil do usurio. Por exemplo: um usurio com perfil ADMINISTRADOR poderia executar qualquer funo do projeto; um usurio com perfil GERENTE poderia apenas controlar aes de seus funcionrios. Alguns desenvolvedores pensam que basta esconder o boto que nenhum problema acontecer, outros desenvolvedores resolvem bloquear tudo e s liberar o que o usurio precisar. Abaixo veremos tcnicas que ajudaro a determinar acessos de segurana por perfil de usurio. Esconda o boto/link, mas proteja o cdigo Imagine que apenas o usurio do perfil GERENTE poderia editar as horas extras de um funcionrio. Para evitar que um funcionrio edite suas prprias horas extras o desenvolvedor poderia esconder o boto. Bastaria utilizar um cdigo javascript, classe css, scriplet ou qualquer coisa utilizando o valor do objeto do usurio: user.isManager(). O valor recuperado seria utilizado de algum modo pela pgina para definir se o link seria ou no escondido. O problema acontece quando um funcionrio ganancioso, que quer ter mais horas extras sem trabalhar, ao passar atrs do monitor do gerente viu a seguinte URL:http://project/user/33/workedHours. O que aconteceria se uma pessoa com o perfil USUARIO tentasse acessar o projeto digitando a URL diretamente no browser? Nunca proteja seu projeto apenas escondendo um recurso, sempre valide cada regra ao ser acessada. necessrio que, para cada request de acesso as horas extras de um funcionrio, uma validao de segurana fosse executada no servidor. Nunca confie que ao esconder algo da tela do usurio a proteo estar completa.
Conhea a necessidade do seu usurio Ao invs de bloquear tudo e depois ir liberando aos poucos seria melhor saber o que o usurio precisa. A vantagem de investir um pouco de tempo para entender o que o usurio precisa justamente amenizar a experincia do usurio. Um usurio que tem a necessidade de sempre solicitar acesso a determinado recurso no projeto, pode acabar no gostando do projeto e trat-lo de qualquer modo. Existe tambm o problema de um usurio com muita permisso desnecessria que poderia esquecer seu computador desbloqueado e qualquer pessoa poderia navegar no projeto. Uma boa soluo para esse problema seria estudar quais acessos determinada pessoa ou papel dentro da empresa necessita ter, e criar o conceito de grupos ou papeis dentro do projeto especficos. Grupos dentro do projeto teriam permisses pr-determinadas e a chance de acertar o que casa usurio necessita aumentaria. Sempre oculte No existe motivo para exibir algo que o usurio no possa acessar. Aplicaes desktop costumam deixar um menu desabilitado visvel. O problema de deixar um menu visvel e bloqueado que um usurio pode comear fazer de tudo para habilitar aquele menu. Existem casos que o fluxo da tela claro quando determinado boto ficar habilitado. No caso de um formulrio onde o boto Salvar fica desabilitado enquanto os campos no forem corretamente preenchidos, seria perfeitamente normal utilizar essa abordagem. Imagine agora uma aplicao corporativa onde est sendo exibido o seguinte menu de modo desabilitado: editar horas extras de todos funcionrios. Qual a necessidade de exibir essa funo desabilitada para usurios sem permisso se apenas um gerente teria acesso a ela? Se um usurio nunca poder habilitar determinada opo, qual a necessidade de deixar a opo visvel? Uma opo desabilitada pode levar usurios comuns a tentarem habilitar dessa opo, e mostrar a hackers opes que ele nem precisava saber que existiria. Se possvel, sempre oculte o que o usurio no deve ver.
Polticas de Segurana
Toda projeto necessita de uma poltica de segurana, alguns exemplos seriam: tamanho de senha, quem poderia criar usurios, quantas pessoas devem aprovar determinada ao at que seja executada. O problema comea quando a poltica de segurana est muito restrita incmoda. Ter acesso somente por digital seria uma poltica restrita que no seria incmoda, basta o usurio colocar o dedo em um sensor que o problema est resolvido. Um dos maiores problemas que vamos falar aqui a questo de polticas de segurana aplicadas a senhas. Uma poltica de senha muito restrita um exemplo clssico de problemas com falha de segurana. O maior problema de segurana nesse caso viria do prprio usurio do projeto. Imagine um projeto onde uma senha vlida tem que ter no mnimo uma letra caps alto, ter um nmero, ter um smbolo como !@#$%*, tem que ser trocada de 3 em 3 meses e no pode ser nenhuma das 5 senhas ltimas utilizadas. O problema dessa abordagem que o usurio comea a sabotar as senhas, ser muito fcil que suas senhas comecem a ser algo como: SENHa1!, SENHa2!, SENHa3!. Um hacker que descobre uma senha muito usada por um usurio (at mesmo de um site de notcias), poderia comear a testar valores sequenciais para invadir o projeto. Outro problema de senha muito restrita post it. Usurios que tm dificuldade com computadores, mas precisam utilizar o projeto, podem justamente colocar a senha em um post it no monitor. Bastaria uma pessoa mal intencionada passar pelo lugar onde se encontra o post it, ver essa senha, e comear fazer o que quiser com o usurio da pessoa. importante ter em mente que necessrio ter algum tipo de poltica de segurana no projeto. Uma boa prtica seria no ter muias regras restritivas, mas impedir que a senha fosse algo como: data de aniversrio, data de casamento, nome do cnjuge ou qualquer outra varivel que possa ser descoberta facilmente por algum que no seja da empresa.
Evitando falhas de cdigos e/ou frameworks

No exponha tecnologias desnecessariamente Nunca misture os tipos Veja o cdigo abaixo:
1 2 3 4 5 6
boolean result = // methodh that returns true System.out.print(result ? charValue : 1); System.out.print(result ? charValue : i); char charValue = 'A'; int i = 1;
O que poderia dar errado no cdigo acima? O primeiro valor a ser impresso seria A, mas o segundo 65! Note que na primeira condio foi utilizado o nmero 1 diretamente e com isso o Java comparou esse nmero com um CHAR. O problema da segunda opo que o Java jogou o tipo de CHAR para int e o problema ocorreu. A soluo para esse problema justamente no misturar os tipos na hora de uma comparao. Esse tipo de problema poderia levar a bugs extremamente difceis de detectar. Toda vez que for necessrio comparar valores utilize o mesmo tipo. Utilize chaves nos IFs muito fcil e simples fazer um IF como abaixo:
1 2
if(tax == 43) executeMethod();
O problema do cdigo acima que uma pessoa novata em Java e no projeto poderia tentar fazer algo como:
1 2 3
if(tax == 43) executeMethod(); runOtherMethod();
algo simples, mas que poderia facilmente acontecer em um projeto onde se tem pessoas novatas na linguagem programando. Adicionar chaves ao comeo e final de um mtodo no vai deixar o cdigo ilegvel, mas pelo contrrio, deixar o cdigo mais fcil de ler:
http://uaihebert.com/protegendo-sua-aplicacao-mini-livro 1 2 3 4
} runOtherMethod(); if(tax == 43){ executeMethod();
Mesmo uma pessoa novata, ao ver o cdigo acima, entenderia que para executar o mtodo caso o if retornasse true, bastaria colocar a chamada ao outro mtodo dentro do if. Inteiros com Flutuantes Evite realizar operaes matemticas entre tipos de nmeros diferentes. Haver perda de preciso ao misturar Double com Integer, por exemplo. Sempre converta Integer/Long para Float/Double quando for realizar uma operao que misture os dois. Sempre programe defensivamente Veja o cdigo abaixo:
1 2 3 4 5 6 7 8 9 10 11 12
} catch (...) { // other exception } } catch (SecurityException x) { // access denied <code>okToAccess</code> = false; try { openTheFile(); boolean okToAccess = true;
Qual o problema do cdigo acima? Caso algum erro acontea que no seja do tipo SecurityException um usurio conseguir acesso ao recurso, pode ser que ele no deveria ter acesso, mas alguma outra exceo aconteceu e com isso um acesso indevido acontecer. Uma boa soluo seria:
http://uaihebert.com/protegendo-sua-aplicacao-mini-livro 1 2 3 4 5 6 7 8 9 10 11 12
} catch (...) { // other exception } } catch (SecurityException x) { // access denied try { openTheFile(); accessGranted = true;
boolean okToAccess = false;
Veja que primeiro o acesso negado e, somente aps todas as validaes de segurana, que o acesso ao recurso estaria liberado. Isso tambm poderia ser considerado boa prtica para diversos outros aspectos como: um mtodo onde precisamos saber se determinado usurio deve ou no ler determinado dado j pode comear com permisso negada e, aps as validaes de segurana, o usurio teria o acesso liberado.
Por hoje s
Como eu disse no comeo, no sou nenhum especialista no assunto, apenas estou compartilhando coisas que aprendi durante leitura ou vivenciei no dia a dia do desenvolvimento. Espero que o post tenha ajudado a esclarecer dvidas e gui-los para uma soluo mais prxima do seu problema. Abaixo as referncias do material que utilizei:

http://msdn.microsoft.com/en-us/security/aa570401.aspx http://www.sans.org/reading-room/whitepapers/securecode/secure-software-developmentcode-analysis-tools-389 http://www.safecode.org/publications/SAFECode_Dev_Practices1108.pdf https://blogs.akamai.com/2013/09/slow-dos-on-the-rise.html http://en.wikipedia.org/wiki/Brute-force_attack Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs
Qualquer dvida basta postar, at mais. At a prxima! \o_

Protegendo Sua Aplicação - Mini Livro - Uaihebert

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Protegendo Sua Aplicação - Mini Livro - Uaihebert

Caricato da

Copyright:

Formati disponibili

http://uaihebert.

No que se baseia segurana?

Um bom hacker sempre tem tempo

Tipos de ataques e sugestes para evit-los

conn = DriverManager.getConnection(url + dbName, userName, password)

Statement st = conn.createStatement(); String query = "SELECT * FROM

customer where customer_name=" + cust

ResultSet res = st.executeQuery(query);

Customer customer = buildCustomer(res); return customer; } catch (Exception e) { throwDataBaseError(e); } } finally {

AntiSamy https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project Coverity Security Library https://github.com/coverity/coverity-security-library

Cuidado com os dados

Cuidados com o Client Side

Sempre d o menor privilgio possvel

Trate os erros do projeto

Cuidados com bibliotecas de terceiros

Preste ateno com o LOG

Separe seu projeto das camadas

Comentrios nem sempre so saudveis

Sempre valide seu cdigo

PMD CheckStyle ESC/Java

Cuidado com a equipe de TI

Proteja a senha do modo correto

Boas prticas para controle de acesso

Evitando falhas de cdigos e/ou frameworks

boolean okToAccess = false;

Qualquer dvida basta postar, at mais. At a prxima! \o_

Potrebbero piacerti anche