Segurança contra invasões e outras ameaças

Configuração PHP / Ambiente / Performance
#6

Encontrei o tópico:
http://www.scriptcase.com.br/forum/index.php/topic,6103.msg28118.html#msg28118
Verifiquem se o servidor de vocês faz listagem de pasta.
Se o negócio do seu cliente é secreto ele não vai querer deixar documentos expostos.
O scriptcase tem um tempo certo para fazer limpeza da pasta tmp.
Mas até estes tempo passar, se a listagem estiver habilitada.
Qualquer um pode ter acesso aos documentos gerados em pdf e etc.
Isto vale para qualquer versão do SC.

#7

Pessoal,
Hoje fico com medo de deixar o scriptcase desenvolvimento direto na web.
Temos pasta sem proteção.
Exemplo:

  1. http://seudominio.com.br/pastaondescritpcasedesenvolvimentoestainstalado/config.php
    Ele mostra onde e que banco de dados você está usando e permite mudar os parâmetros de conexão.
    Totalmente sem proteção. Qualquer um na web pode mudar.
  2. http://seudominio.com.br/pastaondescritpcasedesenvolvimentoestainstalado/prod
    Não sei oque acontece se o sujeito mudar tudo ai.
    Mas totalmente sem proteção. Senha padrão: scriptcase.

A netmake pode se posicionar sobre estas situações?

Obrigado

Segurança - Invasão
#8

Fiz teste no meu em produção aqui e não deu acesso.
IIS com listagem desabilitada.

#9

Tambem fiz teste no prod e mesma coisa. não aceita a senha scriptcase.

#10

Eu não costumo deixar meu ambiente de desenvolvimento na web. Fica no meu computador mesmo.

#11

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.

#12

Jean,

A minha mobilidade é o meu notebook… rsrsrs mas entendi tua posição.

#13

Jean com a listagem desabilitada não tem perigo.

#14

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?

#15

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.

#16

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

#17

[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.

#18

Parabéns pela dica Alexandre.

#19

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.

#20

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;
       }

}
#21

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.

#22

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.

#23

Haroldo,
Vou tentar fazer como sugerido por você!
Se não conseguir peço ajuda.

#24

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:

  1. root,
  2. admin,
  3. 12345,
  4. senha,
  5. password
  6. 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.

#25

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