A NetMake tem conhecimento que o SQL Builder, incluído no Scriptcase, tem um (sério) problema de XSS (testado nas versões 7 e 8 )?
À primeira vista, XSS pode não parecer tão perigoso… mas esta brecha pode levar à muitos problemas, inclusive roubo de sessão do Scriptcase, onde o usuário pode entrar no ambiente do Scriptcase e visualizar/alterar as aplicações.
Isso é sério… a NM então precisa tomar providências!!!
Primeiro, se há algum risco, ele só ocorrerá se o SC estiver instalado em um domínio disponível na internet.(Hospedado em um provedor por exemplo). Acredito que a grande maioria utiliza o Sc instalado localmente em seu computador, o que restringe o suposto problema.
Segundo, o “hacker” teria que ter acesso ao item do menu para acessar a página do SQL Builder. Se este hacker conseguir bular o menu e entrar direto na página do sqlbuilder não teria acesso aos bancos de dados pois não houve seleção de u projeto.
Terceiro, pode até ser que a NM não tenha se preocupado com SQL Injection, o que acho difícil, mas não seria simples promover um ataque desses.
E por ultimo, se Hacker é bom não há sistema de segurança realmente seguro.
Haroldo não me refiro a SQL Injection, me refiro à XSS (Cross-Site Scripting). O “hacker”, como você chama, não precisa ter acesso ao “item do menu”, e nem acessar o SQL Builder.
O que acontece é que quando se executa uma consulta (SELECT) no SQL Builder, ele não exibe o resultado (na tela) em texto puro… o resultado é interpretado como HTML. Se tiver qualquer conteúdo que possa ser interpretado como HTML, ele vai interpretar. Dessa forma é possível executar código javascript e com isso roubar/falsificar os cookies, ou seja, a sessão (login) do usuário. Além de também abrir espaço para outro problema: CSRF (Cross-Site Request Forgery).
Se quer fazer um teste, insira este valor em uma tabela qualquer e depois faça um SELECT nesse registro (SELECT usando o SQL Builder):
INSERT INTO tabela(campo) VALUES('Tes <script>alert(123)</script> te')Quando o SQL Builder exibir o valor, o browser vai interpretar o conteúdo como HTML e mostrar a caixa do alert. Claro que esse é só um exemplo…
A mesma coisa acontece se você tem um formulário com input(text), textarea ou campo de upload de arquivos que aceite arquivos com conteúdo de texto (e o arquivo seja salvo em banco de dados). Se o usuário cadastrar algo que possa ser interpretado como HTML, quando fizer o SELECT no SQL Builder, o valor vai ser interpretado.
E sobre estar instalado em um domínio disponível na internet, mesmo que esteja em uma intranet ou computador local, ainda pode ser prejudicado pelo CSRF.
E quando descobri este problema, ainda vi outra coisa que a NetMake precisa tomar conhecimento: a “trava” de quantidade de usuários logados pode ser burlável clonando a sessão do usuário.
Os proprios nevagadores mais atualizados estão bloqueando XSS. Faça um teste no Chrome.
Eu fiz. Versão 51.0.2704.103 m. Na primeira vez que o script no meio do conteúdo é executado (através do SELECT) ele é bloqueado, nas próximas vezes ele é executado normalmente.
E no Firefox, Versão 47.0, é executado normalmente.
Estranho, não consegui fazer instrução via script, mesmo por via de segunda tentativa. Como estais fazendo?
Ahhh… entendi agora. Você esta jogando dentro do SQL Builder, blz… Mas onde isso pode influenciar na aplicação gerada pelo SC e a mesma em produção? Pois estava pensando que era nas aplicações já geradas pelo SC, não me atentei ao SQL Builder.
Eu uso o SC local, e mesmo usando ele no servidor web não tem como eu usar o XSS sem ao menos ter acesso ao SQL Builder pela autenticação de usuário. Como uma pessoa (um hacker por exemplo) vai usar o XSS no SQL Builder sem ser pela autenticação?
Na verdade o hacker não usaria o SQL Builder… ele só precisa cadastrar esse texto com o script em algum campo (ex: tela de cadastro), e quando o programador usar o SQL Builder para buscar esse registro, o script vai ser executado.
Suponhamos que você tenha uma página para o usuário se cadastrar, com campos como nome, endereço, etc. No campo endereço, ele digita algo como “Rua ”… quando o programador fizer um SELECT no SQL Builder que retorne este registro, o script vai ser executado. Se tiver tags HTML (como img, video, iframe, etc) no meio do texto, também vão ser interpretadas.
O alert é só um exemplo… a pessoa pode adicionar uma requisição ajax que envie os cookies do usuário (nesse caso seria do usuário logado no scriptcase) para algum servidor dele, e tendo os cookies a pessoa consegue “falsificar” a sessão (vai conseguir entrar no ambiente do scriptcase sem precisar logar). Ou então um script que simule a requisição que o scriptcase faz quando você exclui um projeto e deletar seu projeto. As possibilidades são inúmeras, porque o hacker teria acesso praticamente completo ao seu scriptcase.
Esse mesmo problema do conteúdo ser interpretado como HTML pode acontecer nas aplicações… mas nas aplicações cada campo possui a opção “Mostrar conteúdo HTML”, em que se estiver marcado, o valor não é interpretado como HTML, e sim como texto puro (e é o que deveria acontecer no SQL Builder).
O INSERT que eu fiz no vídeo foi apenas para simular uma tela de cadastro (ou seja, simular um usuário cadastrando aquele texto)…
Entendi, até ai tudo bem, mas o usuário não estará previamente autenticado ? E geralmente o usuário é um técnico habilitado a mexer no SQL Build do SC e de confiança da empresa, sinceramente não consigo identificar o “perigo” que isso pode causar.
[font=verdana, arial, helvetica, sans-serif]O usuário ao qual me refiro é o usuário final da aplicação (o que usa a aplicação em outra empresa ou em casa). Através dessa brecha, ele pode fazer com que o programador execute comandos javascript sem saber (já que o SQL Builder executa qualquer script que o usuário insira em um campo qualquer), como chamar funções do Scriptcase (gerar aplicações, deletar aplicações, etc) ou falsificar/clonar a sessão de login do Scriptcase (aí ele teria acesso completo ao ambiente do Scriptcase caso ele esteja disponível online).[/font]
[font=verdana, arial, helvetica, sans-serif]A premissa do XSS é que o “hacker” não executa nada, mas ele faz com que outra pessoa execute. O quão perigoso é essa execução depende dos privilégios que essa outra pessoa tem (como por exemplo um administrador do sistema, ou nesse caso o programador no ambiente do Scriptcase, que tem permissão de visualizar/alterar/excluir aplicações e projetos).[/font]
Vlw por compartilhar, toda melhora na segurança é bem vinda, já enviou para:
bugs@netmake.com.br
Obrigado pela recomendação Jailton!
Acreditei que por ser o fórum oficial houvesse algum funcionário tomando conta e que pudesse reportar o problema para os responsáveis.
Mas como não foi o caso… acabei de reportar o problema para o endereço que você me passou.
Valeu!
Prezados,
Na release v8.1.038, fizemos algumas mudanças na segurança das aplicações geradas.
http://www.scriptcase.com.br/changelog-scriptcase/
Em relação ao SQLBuilder, estaremos verificando e posteriormente corrigindo nas próximas versões. Porém, a citação de Haroldo está correto.
“O “hacker” teria que ter acesso ao item do menu para acessar a página do SQL Builder. Se este hacker conseguir bular o menu e entrar direto na página do sqlbuilder não teria acesso aos bancos de dados pois não houve seleção de u projeto.”
A citação do Haroldo não está correta, visto que quem usa o SQL Builder é o programador, e não o “hacker”.
A única coisa que o “hacker” precisa fazer é inserir o texto contendo o script em um campo de uma aplicação qualquer, e quando o programador fizer um SELECT nessa informação pelo SQL Builder, o script vai ser executado.
Em momento nenhum o “hacker” precisa acessar o ambiente do Scriptcase. Ele só precisa inserir a informação através de uma aplicação de formulário. Só isso. Quem vai executar o script não é o “hacker”, é o programador (mas sem saber!).
Isso é XSS. O hacker não executa nada, ele apenas insere informação (através de um simples cadastro). Ele faz com que outra pessoa execute.
Esta aqui ja responde tudo, si tu deixar vai poder si não , não.
simples
Alias Anderson, si este é o problema porque então usar SC?
@Yuri Esteves
Estas alterações na v8.1.038 parecem ótimas. O token deve ajudar bastante! Mas acredito que elas sejam apenas para a aplicação gerada pelo Scriptcase, certo? E não dentro do ambiente do Scriptcase (SQL Builder)…?
Essa nova opção, ao que me parece, se refere apenas às aplicações. Essa opção existe no SQL Builder? Comentei anteriormente sobre a opção “Mostrar conteúdo HTML” que resolveria o problema, mas ela só existe para campos de aplicações (no SQL Builder ela não existe).
Minha intenção é apontar algo que pode ser melhorado, porque não adianta muito a aplicação desenvolvida estar segura, se houver brecha em outro lugar. Não sei qual o nível de seriedade das aplicações que você desenvolve, mas se você não se importa com a qualidade e a segurança de suas aplicações, é uma escolha sua. Mas eu me importo. Segurança é requisito mínimo para qualquer software.
Sua sugestão é que, ao invés de corrigir o provável problema, eu deixe de usar o Scriptcase? Se eu estiver equivocado quanto ao problema que estou relatando e ele não existir, ok. Então me mostre que o problema não existe ou apresente fatos. Porque até o momento, os testes que fiz comprovam que o problema existe sim.
Gravei este outro vídeo, talvez te ajude a entender melhor o problema.
https://youtu.be/NFZX3VNoHBg
ahh agora deu pra entender o que tu queria explicar.
antes de ficar fazendo pipoca mostra de uma vez a que se refere rsrs
dai não fica comprido o tema.
Me retrato em quanto a minha resposta no post anterior
1 video vale mais que 1000 palavras rsrsr