1. Segurança de Aplicações WEB e
Open Source
10 dicas de segurança para desenvolvedores
AlexandreMarcolino
2. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
A segurança de um sistema inicia da primeira linha de código ?
NÃO !
10 dicas de segurança para desenvolvedores
3. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
10 dicas para orientar
você a
desenvolver/projetar
aplicações de forma
mais segura.
10 dicas de segurança para desenvolvedores
4. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
01 – O Arquiteto de Segurança
Profissional capacitado em segurança que irá determinar as diretrizes a serem
seguidas para garantir a segurança de sua aplicação, dados e servidores.
Desenvolvedores desenvolvem. Arquitetos de segurança não.
Arquitetos de segurança querem fechar tudo. Aplicações WEB são PÚBLICAS.
Deve ser estabelecido então um consenso sobre o nível de RISCO.
10 dicas de segurança para desenvolvedores
5. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
02 – Autenticação
A primeira coisa que uma aplicação precisa ter bem desenvolvida é o módulo
de autenticação de usuário.
Existem frameworks ótimos no mercado, pagos e não pagos, que cuidam
exclusivamente disso.
Opensource – OpenAM ( Antigo OpenSSO, descontinuado pela Oracle/Sun )
Exemplo-openAM.txt
10 dicas de segurança para desenvolvedores
6. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
03 – Gerenciamento de Sessão
Aplicações WEB são ASSÍNCRONAS, isto é, cada transação desconecta o
usuário do servidor ao fim da execução.
Isto delega à camada CLIENTE ( Insegura e não controlável ) a informação
sobre a autenticação, autorizações e estado de utilização da aplicação.
Não transfira DADOS. Coloque um ID na sessão e mantenha uma relação
IDxDADOS em uma TABELA!
Criptografe os DADOS e o ID com um hash ( segredo ) mutante, que é
alterado todo dia pelo menos sem intervenção humana.
WADI – Framework que gerencia o ID da sessão, para aplicações WEB
10 dicas de segurança para desenvolvedores
7. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
04 – Controle de Acesso
Controle de Acesso é a política de o que pode ser acessado por quem!
Não é o DESENVOLVEDOR que define isso.Não se dê ao trabalho de decidir
quem acessa o que.
Coloque o seu MENU de opções em uma tabela e associe grupos de acesso
aos MENUS. Seus programas ficarão mais limpos e fáceis de permissionar.
Não crie grupos demais. Não foque permissionamento em grupos ou
usuários, tenha os dois. Coloque o usuário como precedente.
Mantenha em LOG todas as alterações de permissionamento, registrando
quem deu o ACESSO a QUEM! Isso pode salvar seu emprego.
Mantenha os LOGS de ACESSO a salvo. Isso pode salvar seu emprego.
10 dicas de segurança para desenvolvedores
8. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
05 – Validação de dados de Entrada
Basta ter tempo e imaginação ( conhecimento técnico é obrigação )
para descobrir uma forma de injetar código em um formulário WEB.
Campos do tipo ALFANUMÉRICOS são os mais vulneráveis.
Crie validações em duas camadas:
a) Com javascript, antes de submeter a página já elimine os
&$%| e outros caracteres maliciosos, usados para injeção de código.
b) Antes de sair submetendo ao banco, busque na string
palavras chave. Afinal ninguém se chama DROP SYSTEM CASCADE;Framework utilizando Struts 1.2
struts-config.xml
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/technology/WEB-INF/
validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>
Código em Java do plugin
package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {
private String username;
private String password;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}
Publicação do objeto (struts-config.xml de novo )
<form-beans>
<form-bean name="logonForm"
type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>
Arquivo validation.xml
<form-validation>
<formset>
<form name="logonForm">
<field property="username"
depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>
CUIDADO COM TUDO NO XML! Lembre-se, XML é case sensitive!
10 dicas de segurança para desenvolvedores
9. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
06 – Codifique sua saída
Uma saída codificada impede que um atacante saiba como injetar
código ou colher dados de sua aplicação.
Exemplo de errado:
https://www.google.com/a/webviva.com.br/ServiceLogin?service=mail&passive=true&rm=false&contin
ue=http://mail.google.com/a/webviva.com.br/<mpl=googlemail
Exemplo certo:
https://painel.host.uol.com.br/painel.php?fn=authUser&gr=35&a=8c57776b63174afa529a253814e1bd
e72e316fab|d4de5c0447858bb08ee0760043a6abb8589a8a39&x=XOmoVd124LaIf03i2sgD|d4de5c044
7858bb08ee0760043a6abb8589a8a39&z=d4de5c0447858bb08ee0760043a6abb8589a8a39&t=0&pane
lOpen=inicio
10 dicas de segurança para desenvolvedores
10. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
07 – Criptografia ( SSL, TLS, etc... ) e certificados digitais
Algo tão simples e tão no dia a dia que a galera simplesmente deixa
de usar por displiscência, igual a preservativos!
OpenSSL é seu amigo!
10 dicas de segurança para desenvolvedores
11. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
08 – LOG e Tratamento de Erros
Armazenar os LOGS de forma simples, de fácil acesso e compreensão,
preservados e gerenciados adequadamente.
SYSLOG-NG
Não cuspa o erro no LOG só porque você é capaz de saber o que ele
significa. Crie uma transação única que trata todos os erros e documenta
eles adequadamente nos LOGS. Isso servirá como uma evidência real.
Guarde junto com o seu erro TUDO QUE PUDER sobre o que o usuário
estava transacionando. E sincronize isso com o registro da AUDITORIA da
aplicação. Você vai me agradecer um dia.
10 dicas de segurança para desenvolvedores
12. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
08 – LOG e Tratamento de Erros
Log MUITO RUIM:
[Thread-4986] 26-04-2012 11:56:36.736 > ERROR (?:?) - Ocorreu erro no tratamento ou envio do
socket do BANCO XXXX br.com.sistema.cartao.exception.IFException: Ocorreu erro ao efetivar o
bloqueio do cartão PL - CPF 71304421734 at br.com.
sistema.cartao.business.IFBusiness.efetivaBloqueioCartaoPL(IFBusiness.java:664)
at br.com. sistema.cartao.if.socket.ComunicadorIF.run(ComunicadorIF.java(Compiled Code))
at java.lang.Thread.run(Thread.java(Compiled Code))
Caused by: br.com. sistema.cartao.if.exception.IFException: O cliente 71304421734 não será
desbloqueado porque não está aguardando desbloqueio. At br.com.
sistema.cartao.if.business.IFBusiness.efetivaBloqueioCartaoPL(IFBusiness.java:631)
... 2 more
10 dicas de segurança para desenvolvedores
13. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
08 – LOG e Tratamento de Erros
Log MELHORZINHO:
2012-04-26 13:09:27,452 ERROR br.com.neurotech.shr.util.NUtils - [Frontend] [erro] => StackTrace da Exceção: [26/04/2012 13:09:27]
........................................................
- Id da Exceção: #133545656744625137141665
- Nome da Classe: br.com.neurotech.excecoes.ExcecaoSistema
- Servidor: mari111 - 128.1.30.49
- CPF do Usuário: 1607680475
- Nome do Usuário: MARIA LUCIANA OLIVEIRA DE SOUSA
- Login do Usuário: L506_MARIAL
- Filial do Usuário: 506
- Debug: br.com.neurotech.cadastro.sql.DAOGenericBD | pSql = SELECT CCM_DOCUMENTO.DOC_COD
| pExcecao = java.sql.SQLSyntaxErrorException: ORA-01722: invalid number
[ORA-01722: invalid number
]
- Data Hora: 26/04/2012 13:09:27
- Stack Trace:
java.sql.SQLSyntaxErrorException: ORA-01722: invalid number
10 dicas de segurança para desenvolvedores
14. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
09 – Proteção dos Dados
Backup
Não adianta a aplicação ser segura e as fitas ficarem na mesa do operador.
Não adianta a aplicação ser segura e o backup não existir.
SGBD de VERDADE – PostgreSQL, MySQL, Oracle...DB2.
Se a aplicação é aderente às melhores práticas de segurança, a solução de
banco tem que acompanhar isso. O ideal é que o usuário que loga no sistema
seja o que existe no banco e ambos tenham seus repositórios de usuários
aderentes a solução de SSO escolhida.
10 dicas de segurança para desenvolvedores
15. Segurança de Aplicações WEB e Open Source
AlexandreMarcolino
10 – Proteção das Comunicações
Redes de dados controladas e certificadas.
Se você pretende usar WIFI, Criptografia.
Internet, Firewall, IDS, Proxy Reverso para um filtro inicial de conexões
indesejadas e outros ativos de segurança devem fazer parte do aparato de que
sustenta as comunicações.
Na rede INTERNA, na comunicação entre a Aplicação e o SGBD, criptografa.
Não é exagero. Cada elo da corrente é importante.
10 dicas de segurança para desenvolvedores
16. Sim, eu quero saber mais!
facebook.com/AlexandreMarcolino
twitter.com/ajmarcol
www.owasp.org
AlexandreMarcolino