Detalhes sobre o importante XOOPS_trust_path e o jeito certo de usar

  • Identifique-se para criar novos tópicos neste fórum
  • Visitantes anônimos não podem postar neste fórum
fbs777  Ocasional   Postagens: 22

Como já vi um post do João Barroca perguntando do porquê do XOOPS_TRUST_PATH, e até uma news da Gisa_Iagami indicando um diretório errado (parece que o texto é do João Barroca, mas a Gisa_Iagami provavelmente não corrigiu porque também não captou o sentido do XOOPS_ROOT_PATH. Pelo jeito, até os melhores também se confundem, mesmo que raramente ) para colocar o xoops_root_path, resolvi criar esse tópico para comentar sobre ele.

Eu vi o readme de instalação do protector do GiJoe e realmente o GiJoe colocou no readme a questão do XOOPS_TRUST_PATH como se todo mundo já soubesse porque e como funciona o danado.

Só que como quase ninguém está familiarizado com o assunto, tem algumas coisas que tem que explicar.

O XOOPS_TRUST_PATH, como dito no readme do protector, é um diretório que você tem criar com um nome qualquer. Vou utilizar xt como exemplo aqui.

O que faltou o GiJoe explicar é que o diretório XOOPS vai FORA da web!

Aqui em localhost em casa, o XOOPS_ROOT_PATH (onde fica o mainfile.php) do XOOPS de teste fica em:

/opt/lampp/htdocs/testes/xoops.

Nesse caso, o diretório xt tem que ficar fora do /opt/lampp/htdocs/, assim fica fora do alcance da web.

No /opt/lampp não dá para colocar porque o user não tem permissão de incluir arquivos, então um lugar viável para colocar o xt pode ser o /opt.
Como eu estou usando em casa, posso até colocar em um diretório da home do user:
/home/kurumin/arquivos/xt.

Então na hora de colocar no mainfile.php, a linha ficaria assim:

Define('XOOPS_TRUST_PATH','/opt/xt');

Ou.

Define('XOOPS_TRUST_PATH','/home/kurumin/arquivos/xt');

No caso de portal online, o importante é deixar o diretório xt FORA do diretório public_html.

Ao invés de deixar:
/home/nomedouser/public_html/xoops.
/home/nomedouser/public_html/xt.

Ou então:
/home/nomedouser/public_html/xoops.
/home/nomedouser/public_html/xoops/xt.

o correto é:
/home/nomedouser/public_html/xoops.
/home/nomedouser/xt


Assim o caminho até os dois protector fica:
/home/nomedouser/public_html/xoops/modules/protector.
/home/nomedouser/xt/modules/protector.

Se não colocar o XOOPS_TRUST_PATH (no caso o XOOPS) fora da public_thml (ou htdocs no caso de utilizar XAMPP), todo o trabalho será inútil, afinal, tanto faz o lugar onde está a pasta se ela está dentro da área destinada à web.

Deixando fora do diretório liberado para web, todos os arquivos ali dentro ficam 100% seguros, aí é impossível alguém conseguir acesso à qualquer arquivo dentro do diretório XOOPS. O único jeito de chegar aos arquivos é por ftp/cpanel.
Claro que não estou levando em conta casos de invasão direta no servidor ou roubo de senha do ftp/cpanel, aí não tem jeito.

Quem der uma olhada no novo protector, vai ver que o GiJoe simplesmente jogou todos os arquivos PHP para dentro do XOOPS_TRUST_PATH, deixando apenas atalhos em PHP dentro do módulo, para ir buscar os "verdadeiros" arquivos PHP fora do alcance da web.

Isso significa que todos os arquivos PHP do módulo estão completamente protegidos de acesso direto via web.

Há muito tempo, o xoops-tips também já tinha demonstrado que usando um XOOPS_TRUST_PATH é possível proteger completamente as senhas que ficam normalmente no mainfile.php
Nesse caso, pode ser criado um arquivo PHP dentro do XOOPS_TRUST_PATH e deixar as senhas lá, e no mainfile.php original, dá para incluir o caminho para o arquivo e no lugar das senhas pode colocar as variáveis que definem as senhas no arquivo protegido de acesso direto via web.
No caso, o xoops-tips ainda aconselha a deixar o diretório XOOPS e os subdiretórios com permissão 705 ao invés do padrão 755 para aumentar a segurança mais ainda, mas na época eu tinha testado deixar em 705 mas aí dava erro.

Outra vantagem do XOOPS_TRUST_PATH é que dá para duplicar os módulos facilmente, mas aí já é outra história

O que não dá para entender é porque nenhum cms usa o método de TRUST_PATH por padrão para proteger completamente os arquivos PHP de acesso direto via Web (pelo menos o arquivo de senhas de BD).
A não ser que tenha algum host (do tipo gratuito) que não deixa criar um diretório fora do dir. public_html...

João Barroca  Participativo De: Rio de Janeiro, Brasil  Postagens: 98

Grande!
O erro não foi da Gisa_Iagami não - foi meu. Eu que expliquei errado no fórum de traduções. Pq não sabia.
Esse post é 1000 - podia ir pros artigos ou dicas ou faq, não tenho certeza.
Obrigado fbs!
[eu não queria responder - mas não podia passar em branco.]
Abraços.
João Barroca

ini  Ocasional   Postagens: 28

Fábio: simplesmente excelente! Parabéns.

Um cafézinho para atualizar o módulo nas instalações por aí ... Hehehe: é a vida.
Ainda bem que o Fábio nos ajudou.

João Barroca  Participativo De: Rio de Janeiro, Brasil  Postagens: 98

Opa!
Realmente é excelente - tenho que editar lá no fórum de traduções.
B.

Gislaine  Ocasional   Postagens: 36

XOOPS_TRUST_PATH

Quem baixou a versão 3 do protector viu que tem uma coisa diferente nele em relação aos outros módulos: a questão do XOOPS_TRUST_PATH.

Tanto aqui no XOOPS quanto no próprio xoops.org quase ninguém conhecia o termo antes (que aliás, foi inventado pelo próprio GiJoe), e como o próprio GiJoe não explica direito no readme do módulo (como se todo mundo já soubesse porque e como funciona o danado), a confusão foi geral.

O XOOPS_TRUST_PATH, como dito no readme do protector, é um diretório que você tem que criar com um nome qualquer. Vou utilizar xt como exemplo aqui.

Você já ouviu aquela história que "window$ seguro é window$ desconectado/offline"?

Pois é, nesse caso é praticamente o mesmo, o que faltou o GiJoe explicar é que o diretório XOOPS vai FORA da web!

Aqui em localhost em casa, o XOOPS_ROOT_PATH (onde fica o mainfile.php) do XOOPS de teste fica em:

/opt/lampp/htdocs/testes/xoops.

Nesse caso, o diretório xt tem que ficar fora do /opt/lampp/htdocs/, assim fica fora do alcance da web.

No /opt/lampp não dá para colocar porque o user comum não tem permissão de incluir arquivos, então um lugar viável para colocar o XOOPS pode ser o /opt.
Como eu estou usando em casa, posso até colocar em um diretório da home do user:
/home/kurumin/arquivos/xt.

Então na hora de colocar no mainfile.php, a linha ficaria assim:

Define('XOOPS_TRUST_PATH','/opt/xt');

Ou.

Define('XOOPS_TRUST_PATH','/home/kurumin/arquivos/xt');

No caso de portal online, o importante é deixar o diretório XOOPS FORA do diretório public_html.

Ao invés de deixar:
/home/nomedouser/public_html/xoops.
/home/nomedouser/public_html/xt.

Ou então:
/home/nomedouser/public_html/xoops.
/home/nomedouser/public_html/xoops/xt.

o correto é:
/home/nomedouser/public_html/xoops.
/home/nomedouser/xt


Assim o caminho até os dois protector fica:
/home/nomedouser/public_html/xoops/modules/protector.
/home/nomedouser/xt/modules/protector.

Se não colocar o XOOPS_TRUST_PATH (no caso o XOOPS) fora da public_thml (ou htdocs no caso de utilizar XAMPP), todo o trabalho será inútil, afinal, tanto faz o lugar onde está a pasta se ela ainda está dentro da área destinada à web.

Deixando fora do diretório liberado para web, todos os arquivos ali dentro ficam 100% seguros, aí é impossível alguém conseguir acesso à qualquer arquivo dentro do diretório XOOPS. O único jeito de chegar aos arquivos é por ftp/cpanel.
Claro que não estou levando em conta casos de invasão direta no servidor ou roubo de senha do ftp/cpanel, aí não tem jeito.

Quem der uma olhada no novo protector, vai ver que o GiJoe simplesmente jogou todos os arquivos PHP para dentro do XOOPS_TRUST_PATH, deixando apenas atalhos em PHP dentro do módulo, para ir buscar os "verdadeiros" arquivos PHP fora do alcance da web.

Isso significa que todos os arquivos PHP do módulo estão completamente protegidos de acesso direto via web.

Parece que a próxima geração do XOOPS já vai incluir o XOOPS_TRUT_PATH por padrão, então no futuro não será preciso fazer um hack no mainfile.php para incluir essa opção.

Proteger dados do mainfile

O mainfile.php guarda os dados de login de banco de dados, por isso é o arquivo que mais precisa de proteção.

Para uma proteção maior aos dados usados pelo mainfile, é possível colocar os dados fora do alcance da web, mais ou menos como acontece no caso do XOOPS_TRUST_PATH.

Atenção: o mainfile não é lugar para "brincar"; um mínimo detalhe errado e o portal fica fora do ar. Por isso faça backup do mainfile.php atual, assim se der algum problema dá para voltar rapidamente como estava antes.

Essa dica não depende do XOOPS_TRUST_PATH comentado acima, mas no caso de já ter o XOOPS_TRUST_PATH funcionando, pode-se utilizar a mesma pasta dele.

Primeiro, crie um arquivo PHP com um nome qualquer, como seguro.php e dentro deste arquivo coloque:


< ? php.
$dbxt_user = "root"; // nome do user do database.
$dbxt_passwd = "SENHA"; // senha do db.
$dbxt_name = "BANCO"; // nome do db.
$dbxt_host = "localhost"; // nome do host.
$dbxt_prefix = "PREFIXO"; // prefixo das tabelas.
$dbxt_mysql = "mysql"; // nome do mysql.
? >


Detalhe importante: Não deixe nenhum espaço em branco ou linha em branco depois do ?>

No lugar de SENHA, BANCO, e PREFIXO, coloque o que está definido no mainfile.php, referente a cada um deles. No caso do root, localhost e mysql, normalmente é sempre isso mesmo que fica no mainfile, mas se no seu mainfile tiver com valor diferente, coloque exatamente como está no seu mainfile.

Os valores que ficam antes do = de cada linha pode ser do jeito que você quiser, desde que comece com $ e não tenha caracteres especiais, espaço em branco, etc.

Os dados importantes do mainfile já estão no arquivo seguro.php, agora coloque o arquivo seguro.php dentro do diretório xt do XOOPS_TRUST_PATH. Poderia ser em outra pasta qualquer fora da public_html, mas se já tiver o XOOPS_TRUT_PATH, fica mais fácil utilizar ele mesmo.

Agora, no mainfile.php, coloque antes de qualquer linha válida (depois das linhas de copyright que começam com //) a seguinte linha:
 include ("/home/nomedouser/xt/S3gur0.php");


Depois, nas linhas que correspondem aos dados que foram incluidos no seguro.php, mude os valores, de acordo com seu respectivo substituto:
 // Database.
// Choose the database estou be used.
define('XOOPS_DB_TYPE', $dbxt_mysql);

// Table Prefix.
// This prefix will be added estou all new tables created estou avoid name conflict in the database. If you are unsure, just use the default 'xoops'.
define('XOOPS_DB_PREFIX', $dbxt_prefix);

// Database Hostname.
// Hostname of the database server. If you are unsure, 'localhost' works in most cases.
define('XOOPS_DB_HOST', $dbxt_host);

// Database Username.
// Your database user account on the host.
define('XOOPS_DB_USER', $dbxt_user);

// Database Password.
// Password for your database user account.
define('XOOPS_DB_PASS', $dbxt_passwd);

// Database Name.
// The name of database on the host. The installer will attempt estou create the database if not exist.
define('XOOPS_DB_NAME', $dbxt_name);


Detalhe importante: no mainfile normal, os nomes e senhas ficam dentro de aspas "", e no arquivo seguro.php também devem ficar dentro de aspas, mas no mainfile modificado, repare que não deve ser colocado aspas.

Com isso, o mainfile.php passa a ir buscar no arquivo seguro.php (que está fora do alcance da web) os nomes e senhas.

Link Original do Artigo: Entenda o XOOPS_TRUST_PATH e como proteger os dados do mainfile

Comentem XOOPS

Angelo dos Santos  Iniciante De: Nova Iguaçu, RJ, Brasil  Postagens: 7

galera.. estou tentando fazer isso ae com o protector e não estou conseguindo... fiz assim... conforme o vídeo disponibilizado.

Define('XOOPS_ROOT_PATH', '/home/utilizador/public_html/');
Define('XOOPS_ROOT_PATH', '/home/utilizador/XOOPS_TRUST_PATH/');

E aparece na página dos módulos para eu instalar no local isso:

Set XOOPS_TRUST_PATH into mainfile.php

Que que eu faço?

Angelo dos Santos  Iniciante De: Nova Iguaçu, RJ, Brasil  Postagens: 7

no index que fica na pasta principal do XOOPS .. o index do protector está assim.


Require '../../mainfile.php' ;
If( ! defined( 'XOOPS_TRUST_PATH' ) ) die( 'set XOOPS_TRUST_PATH in mainfile.php' ) ;

$mydirname = basename( dirname( __FILE__ ) ) ;
$mydirpath = dirname( __FILE__ ) ;
Require $mydirpath.'/mytrustdirname.php' ; // set $mytrustdirname.

If( @$_GET['mode'] == 'admin' ) {
require XOOPS_TRUST_PATH.'/modules/'.$mytrustdirname.'/admin.php' ;
} else {
require XOOPS_TRUST_PATH.'/modules/'.$mytrustdirname.'/main.php' ;
}

?>

Por isso manda essa msg... mas pq?

Angelo dos Santos  Iniciante De: Nova Iguaçu, RJ, Brasil  Postagens: 7

Affeeee.

POutz... que erro.

ANTES
Define('XOOPS_ROOT_PATH', '/home/utilizador/public_html/');
Define('XOOPS_ROOT_PATH', '/home/utilizador/XOOPS_TRUST_PATH/');

DEPOIS consertado.

Define('XOOPS_ROOT_PATH', '/home/utilizador/public_html/');
Define('->XOOPS_TRUST_PATH<-', '/home/utilizador/XOOPS_TRUST_PATH/');

A setinha é meramente ilustrativa..rsrs.

Perdoe-me.

Gilvan Mendonça  Iniciante De: João Pessoa - PB - Brasil  Postagens: 9

Como ficaria neste exemplo dado no readme.html do módulo?

define('XOOPS_GROUP_ADMIN', '1');
define('XOOPS_GROUP_USERS', '2');
define('XOOPS_GROUP_ANONYMOUS', '3');

include( XOOPS_ROOT_PATH . '/modules/protector/include/precheck.inc.php' ) ;
if (!isset($xoopsOption['nocommon']) && XOOPS_ROOT_PATH != '' ) {
        include XOOPS_ROOT_PATH."/include/common.php";
}
include( XOOPS_ROOT_PATH . '/modules/protector/include/postcheck.inc.php' ) ;

1 - Tentei usando o exemplo acima e o site ficou fora do ar.
2 - Preciso copiar o módulo protector para a pasta xt/modules/protector?
3 - minhas pastas:

/home/login-do-ftp/public_html/modules/protector
/home/login-do-ftp/xt/modules/protector

Obrigado

  Pesquisa avançada






Entrada

Codinome:


Senha:





Perdeu a senha?  |Cadastre-se!


Quem nos visita
Há 50 visitantes neste momento... (24 na seção Fóruns)

Associados: 0
Anônimos: 50

outros...

Banner XOOPS Cube