AJAX amplifica riscos de segurança em serviços online?

isto não é exatamente novidade …
claro que permitindo qe métodos no servidor sejam chamados via javascript se esta aumentando a possibilidade de um ataque, claro que isto vai depender de quais métodos do teu sistema tu libere para chamadas via ajax (por exemplo, nunca nada que possibilite a alteração de um usuário ou a vrificação da senha do mesmo deve estar disponivel )

E porque?

E porque?
por que isto poderia ser chamado de outro site via cross site scripting ou algma outra tecnica deste tipo, utilizando a propria sessão do usuário logado no seu site para, por exemplo alterar a senha do usuário e utilizar de forma errada a conta deste usuário.

este é só um exemplo

Oh, Lord… e o Google parece que tah querendo quase fazer um WOS(Sistema Operacional da Web) usando isso…
Aliás, falam que usando o GWT eu teria falhas graves que eu devo prestar atenção até no meu codificar(em Java) para não deixar algumas partes expostas do meu sistema.Alguém sabe algo sobre isso?E como eu devo isolar bunitim as classes na minha APP GWT?Algumas sugestões?

urubatan, mas até onde eu conheço do XMLHttpRequest, o Firefox, e também o IE(ao menos nas suas últimas versões), não permitem fazer requisições cross-domain. Assim como também não permitem acessar informações via-js cross-domain em um, por exemplo, iframe. Poderia exemplificar?

Dei uma olhada na wikipedia mas os exemplos me pareceram sempre ligados à uma brecha do browser.

acho que uma coisa que pode ser feita é ir na barra de endereco e se usar de “javascript:codigoMalicioso” em um browser com uma sessao aberta. Tipo, digamos que na lib js da aplicação há métodos genéricos usados pela aplicacao para interagir com o server. Daria pra chamar esses métodos via barra de endereco. Mas dai, cairiamos na mesma jurisdição dos problemas de segurança de uma aplicação sem AJAX…

mesma coisa que salvar, em um formulario um codigo javascript para fazer alguma coisa disparado por um botão ou algo assim, em cadastros simples desprotegidos.

giuliano, vc estava aquele dia q eu coloquei um alert(oi) dentro de um cadastro da metodista?

AJAX é o rabo que abana o cachorro. Um remendo que virou tecnologia. Chamem com quiser, mas ajax é triste, parece uma reacao desesperada a falta de recursos dos padroes ultrapassados.

Mas funciona, entao eu uso.

O ruim eh que causar DoS em qualquer ajax é mais facil que spoof de dns. Se o mal-intencionado tiver uma banda monstra, o sevidor para, principalmente se for java.

Triste? Se fosse triste não teria causado 1/3 do barulho que fez. Ah não ser é claro que você gostava por exemplo, do Hotmail.

Acho que a última forma que alguém mal intencionado faria DoS seria com Ajax.

Grande Luca!!

Não estou acostumado a responder tópicos por aqui, mas não tem como ignorar um do Luca de la mancha

Estou trabalhando com web 2.0 a um tempo já e vejo tanto risco em segurança em AJAX quanto em web-services, se você decide jogar algo crítico na web disponível para todos é claro que você vai tomar na cabeça.

Os serviços AJAX podem muito bem ser seguros, podem pedir autenticação e serem criptografados.

O que expor e o que não expor é uma decisão cuidadosa a ser tomada.

O GWT e outros frameworks que, como ele, transformam java em javascript são bem legais, eu gosto da maneira de que se programa em WEB como se fosse Swing :). Mas, de novo, deve-se tomar cuidado com o que você vai abrir para a web.

Eu estou muito entusiasmado com web 2.0, a experiência do usuário fica realmente muito melhor e é muito mais rápido de se programar.

O artigo da IDG só fala a mesma coisa que sempre se fala, o problema é o código/programador que faz o serviço. Muita gente acha legal e fácil e usa de qualquer jeito, dai é claro que existirão brechas e não será culpa da tecnologia, mas como errar é humano e culpar alguem pelo seu erro é mais humando ainda, a tecnologia sempre paga o pato.

Ps.: Da um sinal de vida em sampa luca!

peczenyj:

mesma coisa que salvar, em um formulario um codigo javascript para fazer alguma coisa disparado por um botão ou algo assim, em cadastros simples desprotegidos.

giuliano, vc estava aquele dia q eu coloquei um alert(oi) dentro de um cadastro da metodista?

Grande Thiago! hehehe…

claro, to ligado nesse problema. Mas a questão é o seguinte, apartir do momento que tu disponibiliza software para ser usado é lógico que ele sofrerá de problemas de segurança, alguns mais e outros menos, mas todos terão problemas de vulnerabilidade. O indiano la não pegou um Smart Card esquentou e conseguiu hackea-lo? hehehe…

Tudo que pode ser feito, pode ser desfeito.

A Segurança na web ainda não está 100% madura, e como mais novidades vão surgindo e serviços vão surgindo, maiores as possibilidades de encontrar falhas ou brechas, a web 2.0, está no início do seu desenvolvimento.

Só alguns esclarecimentos:

:arrow: Aplicações que usam AJAX não podem ler nem escrever em sistemas de arquivo local.
:arrow: As limitações do JavaScript protegem a aplicação de eventuais ataques.
:arrow: Verificações de domínio dos cross-scripting podem ser úteis para diminuir os ataques.
:arrow: Cross-browser podem aumentar as inconsitências das limitações impostas pelo AJAX.
:arrow: Políticas de acesso remoto devem ser estabelecidas de forma que não possibilite execuções inesperadas.
:arrow: Quando se trabalha com webservices, algumas verificações devem ser feitas em código, pois cada browser trata níveis de privilégio diferenciados.

jmp:

AJAX é o rabo que abana o cachorro. Um remendo que virou tecnologia. Chamem com quiser, mas ajax é triste, parece uma reacao desesperada a falta de recursos dos padroes ultrapassados.

Você tem alguma sugestão melhor?

Tenho trabalhado com AJAX mais de um ano e na minha visão nos próximos meses com o boooom do AJAX deve aumentar bastante as vunerabilidades nos sites/sistemas web. É preciso ter muito mais cuidado que no modelo tradicional web (request/reponse) e ter cuidado que métodos expor é só o começo.

Agora pra quem falou que AJAX é gato… tem gato maior que fazer sistemas usando HTML? mas o ajax vai ajudar matar boa parte dos aplicativos desktop e colocar na WEB isso mais na frente vai servir pra nos despedirmos do HTML que conhecemos hoje e partir pra algo que seja projetado de fato para se desenvolver sistemas.

Eu sinceramente não consigo encontrar um problema de segurança no fato usar ajax. Se você antes já tinha validação de segurança server side(espero que sim), a única coisa que muda(e nem é tanto) é a forma como suas requisições chegam e a resposta que você da.

microfilo:

jmp:

AJAX é o rabo que abana o cachorro. Um remendo que virou tecnologia. Chamem com quiser, mas ajax é triste, parece uma reacao desesperada a falta de recursos dos padroes ultrapassados.

Você tem alguma sugestão melhor?

Se nem as pessoas que ganham para ter solucoes ainda nao apresentaram nada, como eu simples mortal trabalhando o dia inteiro em outras coisas vou ter?

-------------- editado

Acho que os principais problemas do ajax sao:

• interoperabilidade
• aparentemente é sensivel a ataque que cause DoS
• nao eh simples
• geralmente eh lento (cpu e as vezes banda tbm)

Quanto a segurança, acho que não há tantos problemas assim.

Caso de Ajax: o live mail é lindo no meu pc. Porém, o do meu pai eh um 500mhz 128 ram, o live mail fica incrivelmente ruim. Meu pai usa o pc pra redigir documentos e ler emails, e essa tecnologia inevitavelmente vai acabar forçando ele a comprar outro computador.

A mesma coisa acontece com o gmail e flickr. até Instalei linux no pc dele para tentar “resolver” (slackware 4.1), ficou melhor mas nao muito, voltei para o windows.

Quan

Não seria o caso de começar a se pensar em aplicações usando algo estilo OpenLaszlo por exemplo?

Ao invez de requisições via navegador usando javascript, usa-se a tecnologia do Flash, e permite MUITO mais de eventos de formulários do que o proprio Ajax consegue fazer com MUITO, mas MUITO javascript

seria ideal ter opção de ou usar AJAX e ter um pentium 4 de 9Ghz e uma versão html simples pra quem ainda usa um 486 ou tem deficiencias visuais, por exemplo.

Sinceramente nao entendi essa ideia de uma aplicacao envolvendo AJAX demandar mais de maquina. O AJAX, pelo contrario, se bem utilizado pode tornar uma aplicacao mais leve. O GMail mesmo, ao inves de ficar dando refresh e remontando a tela de mensagens inultimente, apenas o faz quando tem mensagem nova. Mudancas pontuais.

Acho que eh mais um problema da aplicacao vs hardware exigido, e nao tanto da tecnologia. Sera que uma aplicacao hipotetica que fica pesada com AJAX funcionaria legal sem ele (para a mesma maquina, obvio)?

Marcio Kuchma

Olá

Infelizmente minha experiência nos 10 meses que passei em Paraty com acesso discado não confirmam isto, muito pelo contrário. O GMaill na maioria das vezes nem entrava. Em muitas vezes entrava muito lentamente com algumas travadas. E na minoria das vezes conseguia ler meus emails normalmente.

Definivamente Ajax não combina com acesso discado.

Quanto à maquinas lentas com acesso de banda larga também tenho experiência e posso dizer que também neste caso Ajax sofre muito. Porém bem menos do que no caso de acesso discado com máquina razoável (AMD Athlon 64 +3400, 1 Gb RAM)

[]s
Luca

Hum, me tira umas dúvidas:

Por que?

Ué, qual a diferença entre fazer um ataque com requisição HTTP normal ou
requisição AJAX? Dependo de como é processada a requisição, a requisição normal pode causar mais travamento…

É verdade, mas o desenvolvimento web em java também não é simples se você não usar um framework simples também.

Eu concordo que ele não é tão rápido quanto uma requisição HTTP normal, mas não sei se podemos dizer que é lento!

500 mhz é uma configuração de vários anos atras trantando-se de informática. Seu pai não conseguiria redigir um texto com ferramentas mais modernas (i.e, as ultimas versões o OpenOffice ou do MS Office).

Olá

Em se tratando de máquinas usadas para desnvolver sistemas concordo contigo.

Porém, pelo que tenho visto nas empresas nos setores administrativos e de atendimento ao público, máquinas assim com Windows 98 ainda são bem comuns, mesmo em São Paulo.

No resto do Brasil sei que é pior ainda pois trabalhei com uma aplicação de cartão de crédito em Java que tinha enorme dificuldades devido às limitações dos micros do comércio em Santa Catarina, Rio Grande do Norte e São José do Rio Preto/SP.

[]s
Luca

Sinceramente, não sei de onde tiraram isso do ajax ser mais lento. Trafegam muito menos dados em requisições de dados via ajax do que com post normal. Outra coisa que tem que se tomar cuidado é os memory leeks que vão comendo memória do micro em questão. Se não me engano, algo bem planejado em ajax não promove memory leek(Acho que é o DOM que causa isso). Na verdade, o real motivo do ajax foi tornar a coisa toda mais dinamica, pra que eu preciso receber uns ~10K de html se eu posso receber muito menos que isso pra atualizar dados em uma tela?

Olá

Em Paraty o GMail na maioria das vezes não é lento, é estacionado. A tela do GMail fica mais de 3 minutos em branco antes de ser preenchida ou mostrar mensagem de erro.

O GMail se fosse feito para o mercado brasileiro cheio de Telemares, precisaria de uma interface alternativa que funcionasse com acesso discado.

[]s
Luca

o motivo de ele tornar mais lento é o processamento exigido para transformar os dados em XML e o XML de retorno em dados novamente.

o mesmo motivo que faz com que WebServices sejam muito pesados e desaconselhaveis se tu tiver o controle sobre as duas pontas da aplicação, e não tiver um ótimo motivo para usa-los

Opa

Luca:

O GMail se fosse feito para o mercado brasileiro cheio de Telemares, precisaria de uma interface alternativa que funcionasse com acesso discado.

[]s
Luca

urubatan:

Opa

Luca:

O GMail se fosse feito para o mercado brasileiro cheio de Telemares, precisaria de uma interface alternativa que funcionasse com acesso discado.

[]s
Luca

ele tem uma interface HTML Puro e tem também uma interface para celulares (que até tenho usado bastante via GPRS )

Aqui em ny muita gente usa dial up, muita mesmo. Eu nao pago internet pq o povo aqui ainda nao aprendeu a colocar senha no wireless deles. (vizinhos)

Por experiencia propria, o hotmail funciona mais rapido no brasil do que em ny. (nao faço a minima ideia pq)

Pelo menos as pessoas que conheço, odeiam tanto gmail quanto hotmail. Soh continuo usando hotmail pq “preciso” manter o endereço e nao me vinculo a um provedor.

Luca:

Olá
Em se tratando de máquinas usadas para desnvolver sistemas concordo contigo.

Porém, pelo que tenho visto nas empresas nos setores administrativos e de atendimento ao público, máquinas assim com Windows 98 ainda são bem comuns, mesmo em São Paulo.

No resto do Brasil sei que é pior ainda pois trabalhei com uma aplicação de cartão de crédito em Java que tinha enorme dificuldades devido às limitações dos micros do comércio em Santa Catarina, Rio Grande do Norte e São José do Rio Preto/SP.

[]s
Luca

Concordo, cada caso é um caso…
Então Luca, o que eu quiz dizer é que não da pra exigir que um computador antigo rode aplicações modernas, sejam elas web ou desktop. Não sei se deixei isso bem claro…
O que acha? Falaria que o Firefox, OpenOffice, Eclipse, etc, são lentos? Eu diria que eles foram feitos para uma geração mais moderna de computadores do que um Lentium 500 mhz.
E, para todos os efeitos, o Gmail tem um versão menos turbinada. Não sei se ainda fica pesado numa conexão dial-up.

Acho que para falar de performance, tempo de resposta e escalabilidade de AJAX temos que dividir as aplicações em 2 tipos, as otimizadas via ajax, e as web 2.0.

Aplicações que usam ajax para otimizar a experiencia do usuário apenas são muito mais eficiente e possuem um tempo de resposta imbativel perto das páginas no modelo clássico. Sites web 2.0 não deveriam nem abrir para quem não tem um PC moderno em banda larga de verdade - que começa em 1 mbit.

o motivo de ele tornar mais lento é o processamento exigido para transformar os dados em XML e o XML de retorno em dados novamente.

o mesmo motivo que faz com que WebServices sejam muito pesados e desaconselhaveis se tu tiver o controle sobre as duas pontas da aplicação, e não tiver um ótimo motivo para usa-los

Como tu dissestes, “tiver um ótimo motivo para usa-los”. Aqui no sistema que estou trabalhando atualmente, acho que 98% do volume de dados que trafegam são metadados…