24
Marcelo Machado Fleury #GOPHP, #GOJAVA, #PSL-GO, #FUG-BR, #CISSP-BR … [email protected] http://marcelomf.blogspot.com

Segurança em SOA

Embed Size (px)

DESCRIPTION

Palestra apresentada no IT Meeting 2008 na sala da CONSOFT em Goiânia/GO.

Citation preview

Page 1: Segurança em SOA

Marcelo Machado Fleury… #GOPHP, #GOJAVA, #PSL-GO, #FUG-BR, #CISSP-BR …[email protected]://marcelomf.blogspot.com

Page 2: Segurança em SOA

Padrões/Conceitos/Siglas e mundo real

Ataques X Defesas - Footprint - Sniffing, Data Tampering, Replay-Attack's, MITM

- Ataques de força bruta, XDOS- Escalonamento de privilégios- Code Injection- Parsing Attack's

Conclusão

Page 3: Segurança em SOA

Padrão de arquitetura aberto que possibilita disponibilizar os seus negócios como serviços. Esses serviços podem ser consumidos por aplicações terceiras. A tecnologia mais utilizada hoje para disponibilizar serviços na web, são os webservices.

Page 4: Segurança em SOA

Maneiras de prover a comunicação entre aplicações através de XML(json, yaml, txt...).

A finalidade pode ser para aplicações B2B, middleware's, AJAX, interface para sistemas legados, etc..

Entre as empresas que possuem webservices públicos, podemos citar;Yahoo, Ebay, Bloglines, Google, Bacen...

Page 5: Segurança em SOA

UDDI - Universal Description, Discovery and Integration

SOAP - Simple Object Access Protocol WSDL - Web Services Description

Language REST - Representational State Transfer WADL - Web Application Description

Language XMLRPC - Xml Remote Procedure Call DTD - Document Type Definition XSD - Xml schema Definition XML - eXtensible Markup Language JSON - JavaScript Object Notation

Page 6: Segurança em SOA

FootprintSniffing, Data Tampering, Replay-

Attack's, MITMAtaques de força bruta, XDOSEscalonamento de privilégiosCode InjectionParsing Attack's

Page 7: Segurança em SOA

Footprint - Levantar informações sensíveis do alvo, tais como;

- Sistema operacional- Linguagem utilizada- Pontos de acesso- Métodos aceitos- Tipos de dados

- Entrada- Saída

Possíveis soluções;- Segurança por obscuridade ?- Alteração/Omissão de banner's de

serviços- Alteração/Omissão de extensões

Page 8: Segurança em SOA

Sniffing; Capturar o trafego da rede. Data Tampering; Interceptação/Alteração

de dados, seja para explorar falhas especificas(buffer, stack, integer overflow, XSS) ou para injetar informações indesejadas(node's xml/html...).

Replay-Attack's; Interceptação e utilização de dados que autenticam um usuário em um determinado serviço. Uma vez de posse desses dados, um atacante pode se passar por um usuário legitimo.

MITM; O homem do meio... um atacante se faz passar por um individuo valido. "A" quer conversar com "B", "X" intercepta a conversa e passa a conversar com "A" e "B", se passando por "A", logo; "A" <--> "X" <--> "B“.

Page 9: Segurança em SOA

Possíveis soluções;-Switch ? ARP-POISONING-Ssl/RSA ? MITM- Utilização de criptografia no

payload.- WS-Security; Certificação digital/

x.509!-Utilização de tokens de sessão.

Page 10: Segurança em SOA

Ataques de força bruta; De posse de um dicionário, um atacante força a sua autenticação.

XDOS; Um atacante afim de indisponibilizar o serviço, passa a realizar requisições em volume, aumentando o processamento do servidor e trafego de rede.

Page 11: Segurança em SOA

Possíveis soluções;- WS-Security/Policy/Trust;

Validação de pedidos de autenticação, impondo limites de tentativas de autenticação de um determinado host por um determinado tempo. Após isso, gera-se logs e se necessário, troca-se o usuário e senha.

IDS/IPS Firewall

Page 12: Segurança em SOA

De posse de usuário com acessos limitados, o atacante possui novos horizontes e passa explorar novas vulnerabilidades até então não acessíveis.

Possíveis soluções;- Privilegio mínimo - Elementos devem

ter seus próprios usuários, com permissões específicas. Pode ser aplicado a nível de kernel(lids, apparmor, grsec), sistema operacional(chown/chmod), banco de dados(GRANT), aplicação(RBAC). Deve-se não só oferecer a estrutura para o acesso devido, como também garantir que a mesma não foi bypassada.

- Chrooting

Page 13: Segurança em SOA

SQLXPATHXSS/JSONXML

Page 14: Segurança em SOA

SELECT * FROM usuarios WHERE login='coitado' AND senha='amor'

SELECT * FROM usuarios WHERE login= '' OR 1=1 AND senha='' OR 1=1

Page 15: Segurança em SOA

//usuarios/usuario[login/text()='coitado' and senha/text()='amor']

//usuarios/usuario[login/text()='' or 1=1 and senha/text()='' or 1=1]

Page 16: Segurança em SOA

eval("[1, 2, 3]"+";alert('era uma vez');//']");

Page 17: Segurança em SOA

<usuarios>

<usuario> <login>gazela</login>

<senha>amor</senha></usuario

<usuario><login>joao_do_chapeu_preto</login><senha>g0st0d1550</senha> </usuario>

</usuarios>

Page 18: Segurança em SOA

Possíveis soluções;Validação server-side de qualquer dado de entrada, seja oriundo de um usuário ou de um sistema. Validação não só de tipos, mas tamanho, range e conteúdo(regex), aplicação de quotes escapes.

WAF - Web Application Firewall

Page 19: Segurança em SOA

Inserção de elementos recursivos e/ou complexos no payload.

Injeção de dados em volume no payload.

Injeção de código malicioso no schema, afim de obter dados sensíveis ou dificultar o trabalho do parser.

Page 20: Segurança em SOA

Possíveis soluções;- Utilizar validação de dados(XSD), tipos, tamanho máximo, numero máximo de elementos.

Validação do XSD, sempre que possível, utilizar somente o XSD do servidor para parsear os dados.

Page 21: Segurança em SOA
Page 22: Segurança em SOA

SDL – Processos bem definidos aliados a metodologia de desenvolvimento, possui como foco único e exclusivo a segurança, exigindo um SOC(Centro de operações de segurança) e analises finais de segurança.

OWASP/CLASP Um 'framework" com processos bem definidos e flexíveis ao ponto de viabilizar relacionamentos não custosos com a metodologia de desenvolvimento de software utilizada pela empresa.

Page 23: Segurança em SOA
Page 24: Segurança em SOA

BATE-PAPO

Marcelo Machado [email protected]://marcelomf.blogspot.com