Eu não costumo deixar meu ambiente de desenvolvimento na web. Fica no meu computador mesmo.
Eu deixo por questão de mobilidade. No entanto é em servidor próprio onde eu mesmo cuido da segurança.
Em 3 anos usando SC ainda não tive nenhum incidente.
Jean,
A minha mobilidade é o meu notebook… rsrsrs mas entendi tua posição.
Jean com a listagem desabilitada não tem perigo.
Somente para centralizar os assuntos sobre segurança. Resposta ao tópico: http://www.scriptcase.com.br/forum/index.php/topic,10830.0.html
Para injeção de código temos a macro sc_sql_injection.
Esta macro é usada para proteger o campo/variável contra “sql injection”.
http://www.scriptcase.com.br/docs/pt_br/v8/macros-scriptcase/macros-scriptcase#sc_sql_injection
cito: http://www.scriptcase.com.br/forum/index.php/topic,6067.msg28006.html#msg28006 e http://www.scriptcase.com.br/blog/o-que-e-sql-injection/
Agora fica a pergunta… E quando a injeção de código é com outras finalidades?
O scriptcase fornece proteção.
Por exemplo a injeção de código para fazer um deface em uma página. Tem proteção?
Cito: http://www.scriptcase.com.br/blog/tela-login-scriptcase/
Sera que tem proteção contra todos estes injections?
Contrariando o blog do scriptcase:
“A melhor parte do módulo de segurança é que todas as aplicações de seu sistema e seu banco de dados estrão protegidos 100% contra qualquer tipo de ataque, a senha do módulo de segurança por padrão é encriptografada usando MD5, que é um algoritmo que utiliza uma função hash amplamente utilizado.”
Acho que nenhum sistema é 100% seguro.
Alguns links sobre o assunto:
http://php.net/manual/pt_BR/security.database.sql-injection.php
http://pt.slideshare.net/rafajaques/construindo-uma-aplicao-php-prova-de-balas
http://pt.kioskea.net/faq/7326-php-erros-comuns-injecao-sql-xss-upload
http://wiki.locaweb.com/pt-br/Protegendo_seu_site_e_seus_formulários
http://www.assimsefaz.com.br/sabercomo/como-fazer-php-injection
http://www.webmaster.pt/blindando-codigo-php-638.html
http://finslab.com/enciclopedia/letra-a/a-injecao-de-codigo.php
http://www.devmedia.com.br/evitando-sql-injection-em-aplicacoes-php/27804
http://en.wikipedia.org/wiki/Code_injection
[size=12pt]Atualizando o tópico pois corre no grupo do whatsapp um relato sobre conseguir tudo que foi desenvolvido no Scriptcase quando é usada a instalação padrão com sqlite com um servidor disponível na internet.[/size]
Isto não é uma falha de segurança do SCRIPTCASE e sim do administrador do site que deixou esta falha de segurança em aberto.
Há maneiras de proteger um banco sqlite num servidor web.
Mas fica a sugestão a netmake de podermos escolher o diretório onde instalar o arquivo sqlite do scriptcase IDE.
Suponho que o relato no grupo do whatsapp seja o método de baixar a base principal do Scriptcase: XX_XXXXXXXXXX.db. Que está em sqlite.
Bem, quando usamos sqlite o ideal e deixar a base num lugar inacessível no servidor. Mas o scriptcase não permite escolher o lugar onde irá ficar sua base sqlite.
Ou seja se a pessoa colocar o link certo baixará toda a base do scriptcase com senhas, projetos e tudo o mais.
[size=12pt][b]Como resolver sem ter que instalar o scriptcase novamente usando outro banco de dados?
Use .htaccess[/b][/size]
[size=12pt]Em nosso servidor nossos usuários tem como proteger diretórios de forma simples pelo ISPCONFIG. E podemos auxiliar nossos usuários nesta configuração[/size]
Ao tentar acessar o aplicativos ou mesmo fazer download da base XX_XXXXXXXXXX.db o acesso será bloqueado e somente liberado mediante usuário e senha específico.
Eu mesmo uso este tipo de proteção no meu scriptcase desenvolvimento pois prefiro sqlite que facilita o backup.
Não vou ensinar como fazer .htaccess para autenticação de forma manual pois tem vários tutoriais na internet como este http://www.devin.com.br/htaccess/
Observação: .htaccess somente funciona com Apache.
No Nginx tem como fazer mas não é tão simples e somente usando módulos de terceiros.
Logo, não tem como garantir a segurança. No nginx use o Scriptcase IDE instalado com MySQL por exemplo.
Parabéns pela dica Alexandre.
Pois é Fui eu quem levantou a questão , e demonstrei o problema rsrs “gerei panico na galera”.
Mas sim vale lembrar que é problema do ADMINISTADOR e não do Scritpcase.
Tem outras coisas , por exemplo é possível alterar o nome do SQLITE da Instalação sem perder os dados, ou ate mesmo (pra quem é mais entendido de DBA) pode migrar o SQLITE para MySQL , e sem precisar reinstalar o Scriptcase é possível alterar a conexão dele.
No nginx tem como evitar o download de alguns arquivos. Isso já inibe alguns acessos. Ex:
server {
...
# Evita download de .zip
location ~ \.zip$ {
rewrite / permanent;
}
# Evita o download de qualquer arquivo da pasta files
location ~ ^/(?P<files>.*)/ {
rewrite / permanent;
}
# Evita o download de extensões zip e abc dentro da pasta files
location ~ ^/(?P<files>.*)/(.*?)\.(zip|abc)$ {
rewrite / permanent;
}
}Obrigado pelas contribuições no tópico.
Willian o pessoal se preocupa com roubo dos códigos fontes mais pelos direitos autorais.
Eu me preocupo com roubo das informações dos meus clientes.
Roubo dos meus códigos é minha propriedade intelectual vazando. Somente isto.
Dados dos clientes é um processo nas minhas costas.
E lógico que tendo meus fontes fica mais fácil estudar como obter os dados dos meus clientes.
Mas, não quer dizer necessariamente que possuir o código fonte terá acessos aos dados.
Sómente como comentário.
Se uma aplicação estiver com o botão excluir por exemplo desabilitado (escondido), se inspecionar o elemento de qualquer botão na barra de ferramentas e troca o valor da onclick para
nm_atualiza (‘excluir’) , basta clicar no botão para excluir o registro, isso serve para outros comando também.
por isso que não desejam que o registro seja excluso adicionem no evento onbeforeDelete uma mensagem de erro, mesmo escondendo o botão.
Haroldo,
Vou tentar fazer como sugerido por você!
Se não conseguir peço ajuda.
Bom dia,
Quero ressucitar o tópico, pois neste ano de 2017 vi usuários do Scriptcase colocando senhas no banco de dados, ambiente de produção do Scriptcase e etc, com tamanho senso de segurança que eu pensei: Tá pedindo para ser invadido.
Vi senhas como estas:
- root,
- admin,
- 12345,
- senha,
- password
- aaaa
E por ai vai.
Sei que senha é pessoal e cada um escolhe a que quiser.
Mas pessoal vamos colocar a mão na consciência.
Se você for colocar senhas fáceis assim é melhor jogar gasolina no servidor e tacar fogo.
Porque o dia que invadirem, roubarem ou apagarem tudo o efeito será o mesmo.
PS: o arquivo diagnosis.php é bom para ver se o servidor está ok ou mesmo diagnosticar erros.
Mas é um furo de segurança.
Se tiver ele no PROD ou em desenvolvimento na WEB -> Apague.
Atenção usuários do Scriptcase instalado em distros GNU/Linux.
Grave falha no Systemd
https://sempreupdate.com.br/falhas-do-systemd-afetam-distribuicoes-gnu-linux/
Cito:
“Uma nova falha no escalonamento de privilégios do Systemd afeta a maioria das distribuições GNU/Linux. Pesquisadores de segurança descobriram três vulnerabilidades no Systemd, um famoso gestor de inicialização e serviço de sistema para a maioria dos sistemas operacionais Linux. As falhas permitem que invasores locais ou programas maliciosos tenham acesso root ganho sem privilégios para os sistemas de destino.”
Atualizem seu sistemas.
2 Curtidas
@HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas @InfinitusWeb
Para quem deseja proteger o seu servidor com open_ basedir agora terá a notícia que não deve fazê-lo.
O Scriptcase mais uma vez desprotegido.
https://www.reclameaqui.com.br/netmake-scriptcase/pedem-que-eu-baixe-a-seguranca-do-servidor-para-que-o-scriptcase-funcione_HuXrWcp0RjwKQKCI
1 Curtida
@PedroLucas @yuri_esteves @marcia.scriptcase @HenriqueB @yuri.castro
Hoje venho falar do adminer.
Meu antivírus pode ter anunciando um falso positivo.
Assim como o vírus total:
Mas deve ser somente um aviso para as vulnerabilidades encontradas no adminer.
Para quem já foi invadido por haver software de terceiros não atualizados no Framework do Scriptcase vai minha pergunta:
Com as vulnerabilidades do adminer expostas na internet, a netmake mantém este software atualizado na sua última versão?
Vide: Procurar no google por: adminer.php vírus ou adminer.php vulnerability ou adminer.php hacker scan
Enfim é seguro hoje usar o SCRIPTCASE 9.4.xxx com o adminer no seu framework ?
Principalmente com esta vulnerabilidade aqui:
Vi que no Scritpcase a biblioteca é anterior a esta versão.
1 Curtida
Alguma novidade sobre a vunerabilidade XSS no adminer?
@PedroLucas @yuri_esteves @marcia.scriptcase @HenriqueB @yuri.castro
Já houve correção nesta vulnerabilidade que afeta 9.9.008?
1 Curtida