As empresas hoje possuem em sua infra-estrutura um arsenal de feramentas tais como Firewall, IDS/IPS, DMZ, Bastion Hosts e afins para se defender de invasões internas e externas.
Entretanto, o que muitas vezes é negligenciado é a segurança das aplicações que rodam na Rede, que por uma série de razões oferecem inúmeras brechas de segurança que torna inútil toda esta parafernália eletrônica.
Construir uma aplicação nos dias de hoje não requer tanto conhecimento técnico quanto antes. Rotinas em Action Script, por exemplo, estão implementadas em controles Flash e podem ser embutidos com o clicar e arrastar de um desenvolvedor que, na maioria das vezes, entende muito mais de Design do que de programação propriamente dita. A Segurança fica a cargo da empresa que disponibilizou a ferramenta, a Adobe no caso, que muitas vezes pode ter deixado escapar brechas de segurança que a maioria dos usuários da ferramenta não tem como fechar.
Server Side versus Client Side
Se estamos falando de um código que roda "dentro do Server", este ainda está protegido dentro da infra-estrutura de Segurança criada para a Rede, apesar de que todos os mecanismos abaixo da camada 7 são Content Blind (cegos para o Conteúdo) e não conseguirão detectar códigos maliciosos ou comportamentos anômalos na Aplicação.
Entretanto, aplicações que executam código do lado client "cospem" seus executáveis para fora da rede e oferecem maior perigo (como é o caso dos arquivos Flash). Já que o . SWF está na máquina do usuário mal-intencionado este tem todo o tempo do mundo para livremente procurar por uma falha conhecida para poder explora-la num ataque.
Segurança versus Tempo
Mesmo no caso de programadores profissionais que tem conhecimento técnico suficiente para sanitizar o seu código, há um outro entrave para que as Aplicações sejam seguras, o tempo.
Geralmente a Software House trabalha com um orçamento apertado, gastar mais algumas horas no hardening da aplicação implica num custo maior para o cliente e num prazo de entrega mais dilatado, o que pode fazer com que o cliente opte por um concorrente que entregue o serviço num menor intervalo de tempo e ainda por cima, mais barato (o pessoALL pensa que Software é como o pãozinho que é fornecido pela padaria da esquina !)
A maior defesa para este tipo de ameaça é criar um bom código. Entretanto, encontrar erros de lógica nas aplicações que abrem portas para invasores pode ser algo muito complexo. Segue abaixo algumas sugestões de onde procurar ferramentas e maiores informações sobre o assunto
http://www.swftools.com/tools-category.php?cat=840
http://unixwiz.net/techtips/sql-injection.html
http://www.softwareqatest.com/qatweb1.html#OTHER
Entretanto, o que muitas vezes é negligenciado é a segurança das aplicações que rodam na Rede, que por uma série de razões oferecem inúmeras brechas de segurança que torna inútil toda esta parafernália eletrônica.
Construir uma aplicação nos dias de hoje não requer tanto conhecimento técnico quanto antes. Rotinas em Action Script, por exemplo, estão implementadas em controles Flash e podem ser embutidos com o clicar e arrastar de um desenvolvedor que, na maioria das vezes, entende muito mais de Design do que de programação propriamente dita. A Segurança fica a cargo da empresa que disponibilizou a ferramenta, a Adobe no caso, que muitas vezes pode ter deixado escapar brechas de segurança que a maioria dos usuários da ferramenta não tem como fechar.
Server Side versus Client Side
Se estamos falando de um código que roda "dentro do Server", este ainda está protegido dentro da infra-estrutura de Segurança criada para a Rede, apesar de que todos os mecanismos abaixo da camada 7 são Content Blind (cegos para o Conteúdo) e não conseguirão detectar códigos maliciosos ou comportamentos anômalos na Aplicação.
Entretanto, aplicações que executam código do lado client "cospem" seus executáveis para fora da rede e oferecem maior perigo (como é o caso dos arquivos Flash). Já que o . SWF está na máquina do usuário mal-intencionado este tem todo o tempo do mundo para livremente procurar por uma falha conhecida para poder explora-la num ataque.
Segurança versus Tempo
Mesmo no caso de programadores profissionais que tem conhecimento técnico suficiente para sanitizar o seu código, há um outro entrave para que as Aplicações sejam seguras, o tempo.
Geralmente a Software House trabalha com um orçamento apertado, gastar mais algumas horas no hardening da aplicação implica num custo maior para o cliente e num prazo de entrega mais dilatado, o que pode fazer com que o cliente opte por um concorrente que entregue o serviço num menor intervalo de tempo e ainda por cima, mais barato (o pessoALL pensa que Software é como o pãozinho que é fornecido pela padaria da esquina !)
A maior defesa para este tipo de ameaça é criar um bom código. Entretanto, encontrar erros de lógica nas aplicações que abrem portas para invasores pode ser algo muito complexo. Segue abaixo algumas sugestões de onde procurar ferramentas e maiores informações sobre o assunto
http://www.swftools.com/tools-category.php?cat=840
http://unixwiz.net/techtips/sql-injection.html
http://www.softwareqatest.com/qatweb1.html#OTHER
excelente artigo sobre segurança Adilson. Uma forma que as empresas utilizam para se protegerem é a criação de uma camada Web, funcionando principalmente como Proxy. Tendo assim um webserver na linha de frente de seu ambiente. Todas as requisições partem dele em direção aos servidores aplicacionais, quando eles existem. Outrossim é que implementar segurança em uma aplicação muitas vezes causa perda de performance. Dai a não implementação na grande maioria dos casos.
ResponderExcluirSe pararmos para pensar, talvez o problema seja muito mais humano do que tecnológico.
ResponderExcluirDevemos escolher com muito cuidado a plataforma que iremos trabalhar. J2EE fala justamente da camada que o amigo Gustavo comentou. Devemos especificar muito bem o que é base de dados, regra de negócio e camada Web.
O tempo: fazer o levantamento de custo x benefício. Uma loja virtual de grande porte, deve investir muito seus esforços numa boa estrutura, desenvolvimento.
Mas o site da padaria da esquina de nossa casa, que não presta nenhum serviço online, será que o custo x benefício não ficaria muito prejudicado? Sem falar no tempo de concepção da aplicação...