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

Configuração PHP / Ambiente / Performance
#2

Foi a ‘NSA’ que apagou o POST… hhehee

http://www.scriptcase.com.br/forum/index.php/topic,10138.new.html#new

#3

Verdade jailton,
A NSA é poderosa.
Gente! Se vocês fazem algo para aumentar a segurança no SC / Sistema contribua com estes tópico

#4

Conteúdo tão rico e o pessoal ainda apaga? Vai entender né… (risos). Concordo plenamente com o Alexandre. Segurança a cada dia deve ser revisado e atualizado, pois a cada segundo tem um “chinês”/“Indiano”/“Brasileiro”/Etc… hacker estudando técnicas hacker (invasões, vírus, spans, etc) … “Enquanto você dorme um chinês trabalha”… Vi isso em uma faixa de caminhão, e pensei: Lógico, lá é dia e aqui é noite! Apesar que o sentido do autor não era o que minha lógica dizia. hehehe…

#5

Uma das coisas que me preocupa o temporário da _lib.
Eu agora faço publicação avançada com outro nome para o diretório _lib.
Pois todo relatório pdf por mais secreto que seja cai nesta pasta.
E fica lá pelo período determinado para ser limpo.
Neste meio tempo!?
Já postei isto no fórum, mas o tópico foi moderado nos links de exemplo e agora não encontro mais.

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