@HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas @InfinitusWeb
Definitivamente enquanto colocar a segurança do servidor em risco o Scriptcase não vale a pena ser usado!
https://www.reclameaqui.com.br/netmake-scriptcase/pedem-que-eu-baixe-a-seguranca-do-servidor-para-que-o-scriptcase-funcione_HuXrWcp0RjwKQKCI
Olha, não sei o por que utilizar a open_basedir como parametrização de segurança.
Pois, se for assim, a shell_exec ativada trás mais riscos.
Basta passar args com Shell , que você consegue criar até contas no servidor, caso sua segurança não esteja bem configurada, e não vai ser um open_basedir vazio ou com valor que vai impedir .
E convenhamos que se a open_basedir fosse confiável o cPanel e Plesk utilizariam essa opção, porém, não usam. Esses aplicativos utilizam um tipo de segurança totalmente diferente e confiável a nível SO.
Pa.: Citando cPanel e Plesk por serem as empresas conceituadas no ramo em questão.
1 Curtida
@MarcoRuben @ MNiceas
Servidores sérios tem o shell e a execução de qualquer coisa nele enjaulando. Então pode executar o que quiser com o shell_exec que não ira abalar todo o servidor. Ok?
Somente será abalado o diretório da hospedagem do cliente.
Não somos tolos. Provedores sérios não baseiam sua segurança somente no open_basedir.
Nosso ponto é que o Scriptcase não está 100% com o open_basedir ativo.
@ MNiceas @MarcoRuben
Mais uma coisa pode ver que neste post:
Tive a hospedagem do meu Scriptcase invadido. Mas usando a mesma configuração de segurança que hoje gera os erros descritos. Somente eu fui afetado. Os outros usuários do servidor não tiveram sua segurança comprometida.
E foi por furo de segurança no Framework.
Não quero que meus usuários ou eu passem atualmente por isto por causa de open_basedir desabilitado.
Pois , foi exatamente isso que falei.
Você citou que em seus servidores liberar o open_basedir é um grande furo de segurança.
Mas agora citou que provedores sérios não se baseiam apenas no open_basedir.
Então, não vejo o por que, de uma configuração a nível de PHP interferir na segurança do servidor, se o cloud Linux (cPanel) como já citado, deixa essa diretiva a nível do PHP vazia, e mesmo assim , qualquer invasão , caso exista, afetará apenas o diretório do usuário em questão. Mesmo que, volto a frisar, a open_basedir esteja vazia.
Assim, podemos concluir que a open_basdir não é um item essencial para aumentar ou diminuir a segurança , mas sim como o servidor está configurado a nível de SO para, como você citou, enjaular a conta do usuário.
Concluindo que ter ou não a open_basedir com valor em um servidor depende da escolha do SysAdmin, e do aplicativo utilizado para controle de contas de usuário e acesso Web.
Que por opinião minha, utilizar o cPanel ou plesk seria uma medida mais confiável e segura do que se basear em aplicativos que dependem da open_basedir para controle de acesso ao arquivos via web.
@MarcoRuben @ MNiceas
Marco a questão de segurança somente prolongaria a discussão e não faria a correção necessária no Scriptcase. Ele tem que funcionar com ou sem o open_basedir ativo. Outros Frameworks funcionam normal aqui com o open_basedir ativo. Não posso citar quais ou acabo expulso do fórum por ferir as regras. É tão complicado pedir que o Scriptcase deixe de procurar arquivos que Não existem? Ele forma caminhos para arquivos que somente podem ser erros de programação. Veja meus vídeos no youtube por favor.
PS: Cpanel
https://documentation.cpanel.net/display/82Docs/PHP+open_basedir+Tweak
Overview
The open_basedir tweak limits the user’s ability to browse the file system with PHP. It prevents PHP’s access to the user’s home directory, the / tmp directory, and some necessary PHP system directories. This helps to protect your system from unauthorized access through PHP.
Tradução:
visão global
O ajuste do open_basedir limita a capacidade do usuário de navegar no sistema de arquivos com PHP. Impede o acesso do PHP ao diretório inicial do usuário, ao tmp / tmp e a alguns diretórios necessários do sistema PHP. Isso ajuda a proteger seu sistema contra acesso não autorizado através do PHP.
Plesk:
It is possible to do that, however, there is always a risk for code to be compromised, which will lead to the bigger damage if open_basedir parameter is set to none instead of webspace root.
Tradução: É possível fazer isso, no entanto, sempre há um risco de comprometimento do código, o que causará maiores danos se o parâmetro open_basedir estiver definido como none vez da raiz do espaço da web.
Bom relato, explicando que existem essas propriedades, como eu citei, no cPanel e Plesk.
No entanto, a diretiva open_basedir não protege contra alguém que possa executar o código (PHP) no servidor.
- Por exemplo, simplesmente executar a função system(‘cat/etc/passwd’) ignorará a configuração do open_basedir. Além disso, nem todas as funções que manipulam arquivos verificam o caminho que está configurado nesta diretiva.
Ou seja, como eu já tinha citado anteriormente, a open_basedir não é um item essencial para aumentar ou diminuir a segurança em um servidor.
Tanto que, utilizando-se do cPanel, é possível alterar este item através do PHP Selector, pois o PHP Selector roda sobre o CageFS , o qual tem uma tecnologia a nível de SO para “enjaular” o usuário do cPanel, diferente do open_basedir que possui a tecnologia a nível web(PHP).
Por exemplo:
If CloudLinux + CageFS is installed (suPHP / suexec environment) and CageFS is enabled for all users,
then all PHP/CGI requests (suPHP / suexec) are processed through the users’ cage
For caged users, it doesn’t matter if open_basedir is set or not, since PHP processes will not be able to break out of /home/
Se o CloudLinux + CageFS estiver instalado (ambiente suPHP/suexec) e o CageFS estiver ativado para todos os usuários, todas as solicitações PHP/CGI (suPHP suexec) são processadas na “jaula dos usuários”.
Para “usuários enjaulados”, não importa se a open_basedir está definida ou não, pois os processos PHP não poderão sair de /home/
Assim, me parece que a open_basedir trás uma sensação de falsa segurança.
Particularmente, eu uso o Scriptcase(RAD) em um servidor de hospedagem compartilhada ( não vou citar nomes, pois vi que você falou sobre regras do forum ).
Este servidor utiliza o cPanel, e sem restrição na open_basedir.
Nunca tive problemas com invasão ( tanto a nível de falha de bibliotecas, quanto a nível de SO ).
@MarcoRuben @ MNiceas @HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas
Cansei a Netmake venceu.
Desejo sorte aos usuários da ferramenta.
Você conseguiu alguma resposta (nova/recente) da NetMake sobre este caso?
- Pensei que estávamos debatendo sobre o impacto da open_basedir em servidores que utilizam o ScriptCase.
Hoje, eu consegui ficar mais ativo nesse fórum, e vi que você tinha colocado uma postagem (acho que bem antiga, mas tava na minha lista de recentes ) sobre a deleção de postagens, o qual era uma desserviço afronta.
Mas, opiniões mudam com o tempo.
- A troca de conhecimentos foi construtiva.
1 Curtida
Será que NM está caindo na real?
Eu ainda não acredito.
Não coloco essa fé toda não.
Mas quem ainda é iniciante não vê problemas.
Essa correção demorou de mais a um custo e desgaste emocional sem sentido.
E não faz mais que a obrigação.
1 Curtida
Será que NM está caindo na real?
Eu ainda não acredito.
Não coloco essa fé toda não.
Mas quem ainda é iniciante não vê problemas.
Essa correção demorou de mais a um custo e desgaste emocional sem sentido.
E não faz mais que a obrigação.
Open_ basedir continua sem solução definitiva.
Vide em:
1 Curtida
Olá Luiz ,
Realmente não migrei para outros frameworks porque tenho muitos projetos no SC e daria trabalho, mas depois de alguns problemas fico reavaliando se não compensaria…
Neste caso, qual ferramenta recomendaria (paga ou open source, não importa )?
E principalmente, tem alguma melhor que entregue PWA ou responsividade que recomende ?
Pelas regras do fórum não podemos comentar sobre outras ferramentas. Desculpe.