Cms

Segurança - os 25 erros de programação mais perigosos

, Saiu no portal da SANS a lista criada com o consenso entre vários profissionais e empresas do ramo de segurança e desenvolvimento descrevendo os 25 erros de programação mais perigosos para o desenvolvimento seguro. Eu vou traduzir os nomes e informação básicos mas o melhor é ler o artigo na íntegra, em inglês.
Os erros estão separados em três categorias: Interação insegura entre componentes, Gerenciamento arriscado de recursos, Defensas porosas.
Categoria: Interação insegura entre componentes

1. Validação Imprópria de Entradas: Entradas que recebem dados e os aceitam mesmo sem certificar que eles são do tipo/formato esperado.
2. Codificação ou Escape Impróprios de Saída: Saídas que não são codificadas ou escapadas corretamente são a maior fonte de ataques de injeção de código.
3. Falha ao Preservar a Estrutura da Busca, SQL (conhecido como Injeção de SQL): Se os atacantes podem influenciar as procuras SQL do seu programa, então eles podem controlar o seu banco de dados.
4. Falha ao Preservar a Estrutura do Código da Página (conhecido como "Cross-site Scripting"): Assim como o anterior, se os atacantes podem injetar código ou scripts em sua página, eles podem controlar a página.
5. Falha ao Preservar a Estrutura de Comandos do Sistema Operacional: Se você permitir que entradas ilegais sejam passadas para aplicativos do sistema operacional, o atacante pode controlar o servidor.
6. Transmissão de Dados Sensíveis em Texto Puro: Senhas, dados de cartão e qualquer informação considerada sensível deve ser criptografada.
7. Falsificação de Requisição Entre Sites: Um atacante pode criar uma requisição que é enviada a outro site forjando a origem e fazendo o mesmo partir de um usuário inocente, aproveitando credenciais de autenticação e acessos.
8. Condição de Corrida: Atacantes vão sempre procurar por condições de corrida no software para conferir se alguma informação importante não é obtida no processo.
9. Vazamento de Informações em Mensagens de Erro: Atacantes vão procurar por mensagens de erro que descrevam mais que o necessário, como nomes de campos SQL, objetos e bibliotecas sendo utilizadas.

Categoria: Gerenciamento arriscado de recursos:

1. Falha ao Limitar Operações aos Limites de um Buffer de Memória: O conhecido buffer overflow.
2. Controle Externo de Dados Sensíveis: Informações críticas que são mantidas fora de um banco de dados por questões de performance não deviam ser facilmente acessíveis por atacantes.
3. Controle Externo de de Caminho ou Nome de Arquivo: Quando você usa dados externos para montar um nome de arquivo ou caminho de gravação, você está se arriscando a ser atacado.
4. Caminho de Procura Inseguro: Se o caminho de procura de recursos estiver em algum lugar sob controle de um atacante, bibliotecas ou código pode ser inserido a revelia.
5. Falha ao Controlar a Geração de Código: Caso o atacante consiga influenciar a geração de código dinâmico (se geração de código dinâmico for utilizada no programa) ele poderá controlar todo seu código.
6. Download de Código sem Verificação de Integridade: Se você executa código obtido por download, você confia na fonte. Atacantes podem aproveitar esta confiança.
7. Desligamento ou Liberação Impróprias de Recursos: Arquivos, conexões e classes precisam ser corretamente encerradas.
8. Inicialização Imprópria: Dados, bibliotecas e sistemas inicializados incorretamente podem abrir margens para problemas.
9. Cálculos Incorretos: Quando o atacante tem algum controle sobre as entradas usadas em operações matemáticas, isso pode gerar vulnerabilidades.

Categoria: Defensas porosas:

1. Controle de Acesso Impróprio: Se você não garante que seus usuários estão fazendo apenas o que deviam, os atacantes irão se aproveitar de sua autenticação.
2. Uso de um Algoritmo Criptográfico Quebrado ou Vulnerável: Utilização de algoritmos fracos ou comprometidos levam a falhas de criptografia e vulnerabilidades.
3. Senha no Código: deixar um usuário e uma senha no próprio código traz inúmeros problemas.
4. Permissão de Acesso Insegura para Recurso Crítico: Configurações, arquivos de dados e bancos de dados devem ter suas permissões de acesso protegidas.
5. Uso de Valores Insuficientemente Aleatórios: Se você usa tipos de segurança que dependem de aleatoriedade, usar um gerador aleatório insuficiente só vai causar problemas.
6. Execução com Privilégios Desnecessários: Se seu programa precisa de privilégios elevados para executar suas funções, ele deve abrir mão destes direitos assim que ele termina de executar as ações que precisavam dos privilégios.
7. Aplicação de Segurança do Lado do Servidor pelo Cliente: Atacantes podem usar engenharia reversa em um cliente de software e escrever seus próprios clientes removendo testes e aplicações de segurança.

underpop.co.cc: Segurança: os 25 erros de programação mais perigosos

Marcadores: CMS, Cracking, Defacement, Download, PHP, Programming, Scripts, Security, Senha, SQL, Vulnerabilidade, XSS

---

# 8/07/2009 07:57:00 PM, Comentários, Links para esta postagem,

O que é XOOPS?

, XOOPS é um Sistema de Gerenciamento de Conteúdo, em inglês, Content Management System (CMS). Pronuncia-se foneticamente como "czups" ou "zoo'ps" e é um acrônimo de "eXtensible Object Oriented Portal System".

Sua maior característica é a facilidade de operação e o fato de existirem uma infinidades de módulos que possibilitam agregar mais funções ao portal que se deseja criar. É uma ferramenta poderosa, flexível e fácil de usar na criação e administração dos mais variados tipos de sites. Pode ser usado para criar desde pequenas páginas até portais médios ou grandes. Todas as ações são efetuadas através de uma interface web simples e funcional, deixando aos administradores, praticamente só a tarefa de gerenciar o conteúdo do site.

O software facilita a atualização, alteração e o gerenciamento de publicações eletrônicas em rede, pois as páginas da publicação são geradas dinamicamente, a partir de um banco de dados.

Principais características

Modelos Smarty: Smarty (http://smarty.php.net) é uma ferramenta de templates para PHP que foi incorporada ao XOOPS desde a versão 2.0. Ela possibilita aos administradores um ótimo controle do layout do site, mesmo com pouco conhecimento de PHP. Usando o HTML básico, CSS (Cascading Style Sheets) e as tags do Smarty, os designers podem personalizar seus temas e templates em minutos. Com as tags do Smarty os programadores podem também escrever scripts pequenos que possibilitam o uso de dados do site e dos utilizadores (nome do site, slogan, url do site, nomes e ID´s dos utilizadores, etc) dentro do código HTML do tema ou dos templates usados. O Smarty também implementa um sisteam de "cache" que armazena temas e templates, possibilitando uma rápida recuperação dos dados. Este recurso aumenta muito a velocidade de carregamento de qualquer site XOOPS.

Permissões de acesso baseado em Grupos: XOOPS possui um sistema de registro de utilizadores - você pode opcionalmente exigir que o utilizador se registre para poder acessar certas áreas ou funções do site. Por exemplo, muitos sites requerem que o utilizador se registre para poder enviar notícias, postar nos fóruns, acessar uma sessão de downloads, etc. Os direitos de acesso e administração de um site XOOPS, são configurados num sistema de permissão bem flexível baseado em "grupos de utilizadores". Os grupos criados por padrão são: utilizadores anônimos, membros ou utilizadores registrados e webmasteres ou administradores. Logicamente você pode criar quantos grupos forem necessários para gerenciar seu site, dando a eles os direitos e permissões que quiser, incluindo:

• Quais os blocos que podem ser vistos
• Quais os módulos que podem ser acessados
• Quais os módulos que podem ser administrados
• Quais os aspectos do sistema que podem ser modificados

Gerenciamento de associados: O XOOPS inclui ferramentas para um gerenciamento de utilizadores muito fácil e seguro. Estas ferramentas possibilitam a busca por utilizadores seguindo vários critérios, enviar e-mail e mensagens privadas para eles, além de todas as configurações de permissões de acesso e utilização de funções características a cada grupo.
Enviar email para os utilizadores é um processo bem simples. Caso necessite, você pode enviar os emails para um grupo por vez.

Suporte a Múltiplos Idiomas: Todo o idioma do sistema pode ser facilmente alterado apenas instalando-se um novo pacote de tradução.
Os arquivos de idioma podem ser facilmente encontrados e modificados graças a característica modular do XOOPS. Criar arquivos de tradução adicionais para novos módulos é bem simples. Basta copiar uma pasta de linguagem e traduzir o texto.

Gerenciador de Imagens: As Imagens podem ser categorizadas e enviadas ao site através desta ferramenta. O Gerenciador de Imagens se abre em uma nova janela e possibilita uma maior comodidade para posteriormente, inserir as imagens enviadas em quaisquer conteúdos. Existe ainda um sistema de permissões controlando as dimensões da imagem, seu peso e acesso dos grupos de utilizadores a diferentes categorias de imagens criadas.
O gerenciador de Imagens possibilita o envio de imagens que podem ser usadas em qualquer lugar do site.

Fonte: XOOPS Brasil.

Marcadores: CMS, computers, CSS, html, XOOPS

---

# 8/12/2008 04:06:00 PM, Comentários, Links para esta postagem,

XOOPS Cube Legacy 2.1.5

XOOPS Cube Legacy (Package_Legacy) 2.1.5 está disponível. Agradecemos todos os contribuintes que tentou testar a RC1, RC2 e rc3 de um mês. 2.1.5 é pequena atualização de versão 2.1.4. Esta versão corrige uma falha importante e algumas correções de bugs, e inclui algumas correções. 2.1.4 A versão anterior tinha um erro gramatical em torno de URL. Este bug desencadeou a alguns problemas AJAX módulos, alguns usuários aplicar uma correção para o bug quente. Mas 2.1.5 contém a fixar. Portanto, mesmo se você aplicar uma correção para o bug quente para 2.1.4, você pode atualizar para 2.1.5, sem medidas especiais.

Esta versão tentou conter muitas correções para se tornar manutenção última versão, assim RC ensaio, foi muito longa. Até que, ao que parece, é muito estável 2.1.5. Se você estiver usando Package_Legacy 2.1.x, não existem razões que você não atualizar seu site a 2.1.5. Se você estiver usando uma distribuição pacote de Package_Legacy, talvez uma das novas versões desses pacotes serão desbloqueadas, assim que você deve aguardar os seus anúncios.

O projeto já recebeu novas informações e novos patches para mais melhorias. Portanto, o projeto irá manter os esforços na cabeça do Package_Legacy módulo do CVS.

== Upgrade de 2.1.4 a 2.1.5 ==
Remover mainfile.php e / diretório de instalar o pacote para não quebrar o seu ambiente atual. Em seguida, enviar arquivos do pacote para o servidor. Por último, fazer atualização módulos indicando ícone vermelho no módulo de gestão do painel de controle. Você pode fechar o site no painel de controle para ocultar a sua readaptação.

== Upgrade de 2.1.5 RC, RC2 e rc3 a 2.1.5 ==
Remover mainfile.php e / diretório de instalar o pacote para não quebrar o seu ambiente atual. Em seguida, enviar arquivos do pacote para o servidor. Por último, fazer atualização cinco módulos --- legado, usuário, legacyRender, stdCache, pm (se você usar), no módulo de gestão do painel de controle. Você pode fechar o site no painel de controle para ocultar a sua readaptação.

Funcionários == ==
-- Aaki
-- Fugafuga
-- GIJOE
-- Gusagi
-- JardaR
-- Jidaikobo
-- Kilica
-- Maconha
-- MAT
-- Mikhail
-- Minahito
-- Nbuy (aka Nobu)
-- Nobunobu
-- Okuhiki
-- Onokazu
-- Tohokuaiki
-- Tom_G3x

Mudanças == ==
[Bug Fix - De Bug Tracker]
-- Fix Bug # 1950018 - charset Problema no css.php
-- Fix Bug # 1950017 - PathDisclo em legacyRender / admin / css.php
-- Fix Bug # 1944713 - Divulgação PATH? em Legacy_Controller:: _parseUrl ()
-- Fix Bug # 1939992 - inválido xhtml modelos no legado módulo.
-- Fix Bug # 1938443 - ID é definida em múltiplos TplsetList
-- Fix Bug # 1924223 - O pedido que inclui URL não pode ser processado.
-- Fix Bug # 1971682 - Não foi possível ler a partir de um PM removido usuário.
-- Fix Bug # 1971718 - cookie caminho sempre se torna '/'.
-- Fix Bug # 1987219 - Remover inválidos arquivos a partir do diretório extra.
-- Fix Bug # 1989801 - cleanup referência ao anúncio variável em sala de aula / tree.php.
-- Fix Bug # 1990481 - inválido REGEXP em User_AbstractUserEditForm classe.
-- Fix Bug # 1992732 - $ xoopsConfig não referer mXoopsConfig, em alguns casos.
-- Fix Bug # 2003440 - X_UACTLINK está faltando utilizado em algumas línguas.
-- Fix Bug # 2008857 - nível usuário vazio quando edita usuário cujo teor não nos 0,1,5
-- Fix Bug # 2010090 - Desaparecidos Tipo de conteúdo em MailHeader por # 1729813.
-- Fix Bug # 2011775 - Quando um usuário apaga sua conta, principal não é criada.
-- Fix Bug # 2017164 - Não é possível registrar nova conta por # 2011775

[Outras Mudanças / Acessórios]
-- Patch # 1868259 - acrescentar a alt smaily icons@legacy_xoopsform_opt_smileys.html
-- Patch # 1897607 - html / instalação / include / functions.php
-- Patch # 1961603 - português traduções: fixar bugs e acessórios.
-- Patch # 1992777 - xoopsmailerlocal.php para zh-tw.
-- Patch # 2011199 - checo mensagem catálogo para XCL.
-- Patch # 2016023 - Pacote Legacy 215rc patch FR e PT erro tipográfico.
-- (Exceção Patch) Melhorar LostPassAction.

Marcadores: CMS, Cube, Legacy, webdev, XOOPS

---

# 7/30/2008 12:00:00 AM, Comentários, Links para esta postagem,

xoops-modulo-protector

Introdução. O Básico

• Nota 1: Não existe nada 100% SEGURO na Internet. Nos CMS que operam com banco de dados - XOOPSMySQL. Você pode utilizar softwares próprios para isso, como o MySQLDumper , ou realizar backups utilizando o próprio phpmyadmin do CPANEL. Inclusive - é essencial fazer-se backups regulares do site [e sempre que houver alguma modificação], e especialmente do Banco de Dados, no caso
• Nota 2: Nos CMS [e sistemas de fórum como phpbb, IPB, vBulletin, woltlab e outros] em geral, os arquivos que guardam os dados de configuração do banco de dados [usuário do banco de dados, senhas, informaçõs do administrador, por exemplo] são dos mais importantes para o sistema: e os que devem - por conter dados confidenciais - ser mais protegidos. No XOOPS este arquivo é o mainfile.php . De forma geral sempre que se for alterar um arquivo deve-se fazer backup em primeiro lugar: nas alterações que veremos abaixo (incluindo alterar o mainfile.php) isto é essencial. Uma linha errada e seu XOOPS IRÁ PARAR DE FUNCIONAR. Se você tiver o backup do(s) arquivos à mão, você pode restaurar o(s) arquivo(s) pelo backup e depois - com tranqüilidade - acertar o que estava errado.
  

Parte I. Antes de Instalar o Protector ... Criando XOOPS_TRUST_PATH

Para publicar um site na web é necessário que os arquivos estejam dentro de uma pasta [public_html] [www] ou, ainda, [httpdocs]. Isso gera um problema para a segurança no caso de arquivos vitais do sistema.

O conceito do Xoops_Truth_Path, é criar uma pasta que fique fora da visão web [do acesso por web], ou seja, fora da pasta [httpdocs] ou [public_html][www] e onde os arquivos possam ficar armazenados com menor risco.

O nome Xoops_Truth_Path é apenas uma referência - como você verá nas figuras abaixo.. Imp: Qualquer nome poderá ser usado por você. Os exemplos abaixo são da visualização da estrutura básica de pastas em um painel tipo Plesk [figura 1] ou Cpanel [figura 2].

Figura 1 [Plesk]



Figura 2 [Cpanel]



Repare que nesse caso, a pasta xtrustpath (nome escolhido no exemplo, mas você pode colocar o nome de sua preferência) está fora da pasta www [ou public_html ou httpdocs], que é onde os arquivos de um site ficam.

Essa pasta será utilizada nos próximos passos, "Instalando o Protector" e "Protegendo seu arquivo mainfile.php". Alguns módulos [em especial os criados por Gijoe - veja seu site clicando aqui- também requerem esta pasta para instalação, portanto sempre que for instalar um módulo, verifique as instruções para saber como proceder.

O que estamos dizendo é que você deve CRIAR [usando seu programa de FTP, ou pelo painel de controle do seu host] uma pasta como demonstrado acima.

Tendo você já feito isso ... está na hora de alterar o mainfile.php do seu XOOPS. Lembrou de fazer um backup deste fundamental arquivo? Não? Então faça ANTES do próximo passo.

Para alterar o mainfile.php de forma a usar o recurso XOOPS_TRUST_PATH você deve incluir a linha:

define('XOOPS_TRUST_PATH', '/caminho/xoopstrustpath*');

antes da linha:

// XOOPS Virtual Path(URL)

(* onde xoopstrustpath deve ser trocado pelo nome de sua pasta e '/caminho/' pelo caminho [path] de seu servidor. [Você percebeu que trocamos o nome xtrustpath para xoopstrustpath, não é? É claro que você deve usar o nome que criou para sua pasta com seu XOOPS_TRUS_PATH.]

Uma última lembranaça: ...Não esqueça do ponto e vírgula no fim e cuide para manter as aspas!)

Vejamos isto com imagens ...

1. O mainfile.php ANTES de incluir o código definindo o caminho para o XOOPS_TRUST_PATH ...

Agora o mainfile já com o caminho para XOOPS_TRUST_PATH definido...



Nota: Lembre também de ler os arquivos de explicações que acompanham cada módulo. [pagebreak] Parte II . Instalando o Protector
Neste momento você já alterou o seu mainfile para operar com XOOPS_TRUST_PATH. Vamos ao segundo passo: instalar o Protector. Antes de mais nada verifique se você tem a última versão do Protector,
1. Visualização inicial:


2. Vamos olhar o conteúdo da pasta html [figura 1] e da pasta xoops_trust_path [figura 2] :

Pasta html:



Pasta XOOPS_TRUST_PATH:



Faça upload via FTP (COPIE), da seguitne forma:

Copie o conteúdo da pasta html/modules/protector (com sua estrutura de pastas e arquivos) para dentro de XOOPS_ROOT_PATH/modules/
Copie o conteúdo de xoops_trust_path/modules/protector (com sua estrutura de pastas e arquivos) para dentro de XOOPS_TRUST_PATH/modules/
Torne a pasta(e arquivos) em XOOPS_TRUST_PATH/modules/protector/configs com permissão de escrita [CHMOD 777]

Finalmente: Instale o módulo.

Agora temos que alterar o mainfile para o pré-check e post-check funcionarem. Voltemos ao mainfile então. Procure onde está a linha

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

Você irá incluir uma linha antes e depois dela. Veja a figura abaixo:



Se tudo correu bem, você irá ver que a configuração do mainfile está correta na 'Central de Segurança' do módulo. À esta altura você já deve estar se perguntando ... 'não seria interessante proteger o mainfile todo?'

Parte III: Protegendo o mainfile.php
Relembrando...

O mainfile.php é o arquivo que guarda toda a informação essencial do seu site, incluídas aí a senha e nome do usuário do seu banco de dados. E o nome do banco de dados, e o path [caminho físico] do seu site! Se você percebeu, ao editá-lo para instalar o protector, uma boa parte do que existe de fundamental a ser protegido está ali.E todos que já operaram com XOOPS SABEM que o mainfile está na raiz do seu site. Ou deveria estar. Mais uma razão para nos perguntarmos ... que tal tirar o mainfile da possibilidade de ser acessado pela WEB?

Movendo o mainfile
Na verdade é muito simples... Faça uma cópia do seu arquivo mainfile.php usado no site, e coloque essa cópia para a pasta 'xtrustpath'[veja Parte II].
Depois, substitua todo o conteúdo do mainfile.php original por :

Código PHP: require_once('/caminho/xtrustpath/mainfile.php') --> Assim o mainfile.php que fica no xoops vai servir apenas como atalho para buscar o "verdadeiro" mainfile ... que está fora da web! Simples não?

'Evolução' de um mainfile.php de exemplo: abaixo os detalhes...

Usaremos para esse exemplo um site que está hospedado em um servidor com cPanel:
O login do cPanel será : seulogincpanel ;
Banco de Dados: nome: nomebd ;
Usuário e senha desse banco de dados: nomeusuariobd e senhausuariobd;
Path: /home/seulogincpanel/public_html
O site é: http://meusite.com.br

Mainfile antes de qualquer alteração - fizemos a instalação normal do XOOPS e ele está assim:

Código PHP: if ( !defined("XOOPS_MAINFILE_INCLUDED") ) {
define("XOOPS_MAINFILE_INCLUDED",1); // XOOPS Physical Path
// Physical path to your main XOOPS directory WITHOUT trailing slash
// Example: define('XOOPS_ROOT_PATH', '/home/daeqhos/public_html');
define('XOOPS_ROOT_PATH', '/home/seulogincpanel/public_html');

// XOOPS Virtual Path (URL)
// Virtual path to your main XOOPS directory WITHOUT trailing slash
// Example: define('XOOPS_URL', 'http://meusite.com.br');
define('XOOPS_URL', 'http://meusite.com.br');
define('XOOPS_CHECK_PATH', 1);

// Protect against external scripts execution if safe mode is not enabled
if ( XOOPS_CHECK_PATH && !@ini_get('safe_mode') ) {
if ( function_exists('debug_backtrace') ) {
$xoopsScriptPath = debug_backtrace();
if ( !count($xoopsScriptPath) ) {
die("XOOPS path check: this file cannot be requested directly");
}
$xoopsScriptPath = $xoopsScriptPath[0]['file'];
} else {
$xoopsScriptPath = isset($_SERVER['PATH_TRANSLATED']) ? $_SERVER['PATH_TRANSLATED'] : $_SERVER['SCRIPT_FILENAME'];
}
if ( DIRECTORY_SEPARATOR != '/' ) {
// IIS6 may double the \ chars
$xoopsScriptPath = str_replace( strpos( $xoopsScriptPath, '\\\\', 2 ) ? '\\\\' : DIRECTORY_SEPARATOR, '/', $xoopsScriptPath);
}
if ( strcasecmp( substr($xoopsScriptPath, 0, strlen(XOOPS_ROOT_PATH)), str_replace( DIRECTORY_SEPARATOR, '/', XOOPS_ROOT_PATH)) ) {
exit("XOOPS path check: Script is not inside XOOPS_ROOT_PATH and cannot run.");
}
} // Database
// Choose the database to be used
define('XOOPS_DB_TYPE', 'mysql'); // Table Prefix
// This prefix will be added to all new tables created to avoid name conflict in the database. If you are unsure, just use the default 'xoops'.
define('XOOPS_DB_PREFIX', 'xoops'); // Database Hostname
// Hostname of the database server. If you are unsure, 'localhost' works in most cases.
define('XOOPS_DB_HOST', 'localhost'); // Database Username
// Your database user account on the host
define('XOOPS_DB_USER', 'seulogincpanel_nomedousuariobd'); // Database Password
// Password for your database user account
define('XOOPS_DB_PASS', 'senhausuariobd'); // Database Name
// The name of database on the host. The installer will attempt to create the database if not exist
define('XOOPS_DB_NAME', 'nomebd'); // Use persistent connection? (Yes=1 No=0)
// Default is 'Yes'. Choose 'Yes' if you are unsure.
define('XOOPS_DB_PCONNECT', 0); define('XOOPS_GROUP_ADMIN', '1');
define('XOOPS_GROUP_USERS', '2');
define('XOOPS_GROUP_ANONYMOUS', '3'); foreach ( array('GLOBALS', '_SESSION', 'HTTP_SESSION_VARS', '_GET', 'HTTP_GET_VARS', '_POST', 'HTTP_POST_VARS', '_COOKIE', 'HTTP_COOKIE_VARS', '_REQUEST', '_SERVER', 'HTTP_SERVER_VARS', '_ENV', 'HTTP_ENV_VARS', '_FILES', 'HTTP_POST_FILES', 'xoopsDB', 'xoopsUser', 'xoopsUserId', 'xoopsUserGroups', 'xoopsUserIsAdmin', 'xoopsConfig', 'xoopsOption', 'xoopsModule', 'xoopsModuleConfig', 'xoopsRequestUri') as $bad_global ) {
if ( isset( $_REQUEST[$bad_global] ) ) {
header( 'Location: '.XOOPS_URL.'/' );
exit();
}
}
if (!isset($xoopsOption['nocommon']) && XOOPS_ROOT_PATH != '') {
include XOOPS_ROOT_PATH."/include/common.php";
} }
-->

Com todas as alterações: XOOPS_TRUS_PATH criado como pasta 'aleluia' FORA da WEB...

Código PHP: if ( !defined("XOOPS_MAINFILE_INCLUDED") ) {
define("XOOPS_MAINFILE_INCLUDED",1); // XOOPS Physical Path
// Physical path to your main XOOPS directory WITHOUT trailing slash
// Example: define('XOOPS_ROOT_PATH', '/home/daeqhos/public_html');
define('XOOPS_ROOT_PATH', '/home/seulogincpanel/public_html');
// definindo o XOOPS_TRUST_PATH - basico para o protector
define('XOOPS_TRUST_PATH','/home/seulogincpanel/aleulia');
// XOOPS Virtual Path (URL)
// Virtual path to your main XOOPS directory WITHOUT trailing slash
// Example: define('XOOPS_URL', 'http://meusite.com.br');
define('XOOPS_URL', 'http://meusite.com.br'); define('XOOPS_CHECK_PATH', 1);
// Protect against external scripts execution if safe mode is not enabled
if ( XOOPS_CHECK_PATH && !@ini_get('safe_mode') ) {
if ( function_exists('debug_backtrace') ) {
$xoopsScriptPath = debug_backtrace();
if ( !count($xoopsScriptPath) ) {
die("XOOPS path check: this file cannot be requested directly");
}
$xoopsScriptPath = $xoopsScriptPath[0]['file'];
} else {
$xoopsScriptPath = isset($_SERVER['PATH_TRANSLATED']) ? $_SERVER['PATH_TRANSLATED'] : $_SERVER['SCRIPT_FILENAME'];
}
if ( DIRECTORY_SEPARATOR != '/' ) {
// IIS6 may double the \ chars
$xoopsScriptPath = str_replace( strpos( $xoopsScriptPath, '\\\\', 2 ) ? '\\\\' : DIRECTORY_SEPARATOR, '/', $xoopsScriptPath);
}
if ( strcasecmp( substr($xoopsScriptPath, 0, strlen(XOOPS_ROOT_PATH)), str_replace( DIRECTORY_SEPARATOR, '/', XOOPS_ROOT_PATH)) ) {
exit("XOOPS path check: Script is not inside XOOPS_ROOT_PATH and cannot run.");
}
} // Database
// Choose the database to be used
define('XOOPS_DB_TYPE', 'mysql'); // Table Prefix
// This prefix will be added to all new tables created to avoid name conflict in the database. If you are unsure, just use the default 'xoops'.
define('XOOPS_DB_PREFIX', 'xoops'); // Database Hostname
// Hostname of the database server. If you are unsure, 'localhost' works in most cases.
define('XOOPS_DB_HOST', 'localhost'); // Database Username
// Your database user account on the host
define('XOOPS_DB_USER', 'seulogincpanel_nomedousuariobd'); // Database Password
// Password for your database user account
define('XOOPS_DB_PASS', 'senhausuariobd'); // Database Name
// The name of database on the host. The installer will attempt to create the database if not exist
define('XOOPS_DB_NAME', 'nomebd'); // Use persistent connection? (Yes=1 No=0)
// Default is 'Yes'. Choose 'Yes' if you are unsure.
define('XOOPS_DB_PCONNECT', 0); define('XOOPS_GROUP_ADMIN', '1');
define('XOOPS_GROUP_USERS', '2');
define('XOOPS_GROUP_ANONYMOUS', '3'); foreach ( array('GLOBALS', '_SESSION', 'HTTP_SESSION_VARS', '_GET', 'HTTP_GET_VARS', '_POST', 'HTTP_POST_VARS', '_COOKIE', 'HTTP_COOKIE_VARS', '_REQUEST', '_SERVER', 'HTTP_SERVER_VARS', '_ENV', 'HTTP_ENV_VARS', '_FILES', 'HTTP_POST_FILES', 'xoopsDB', 'xoopsUser', 'xoopsUserId', 'xoopsUserGroups', 'xoopsUserIsAdmin', 'xoopsConfig', 'xoopsOption', 'xoopsModule', 'xoopsModuleConfig', 'xoopsRequestUri') as $bad_global ) {
if ( isset( $_REQUEST[$bad_global] ) ) {
header( 'Location: '.XOOPS_URL.'/' );
exit();
}
}
include XOOPS_TRUST_PATH.'/modules/protector/include/precheck.inc.php' ;
if (!isset($xoopsOption['nocommon']) && XOOPS_ROOT_PATH != '' ) {
include XOOPS_ROOT_PATH."/include/common.php";
}
include XOOPS_TRUST_PATH.'/modules/protector/include/postcheck.inc.php' ;
}}
-->

E finalmente com a transmutação do mainfile [e cópia do original para a pasta 'aleluia' - NÃO ESQUEÇA DE FAZER BACKUP], temos :

require_once('/home/seulogincpanel/aleluia/mainfile.php')

underpop.online.fr: xoops modulo protector
underpop.online.fr: xoops modulo protector

Related articles by Zemanta

• The Best Online Commerce Solution For Developers (butterflymedia.ro)
• 3 windows applications for XOOPS Cube environment (sunday-lab.blogspot.com)
• Rapid Weaver 3.5 public beta 1 (sunday-lab.blogspot.com)
• How to change your customer's passwords in PLESK (5min.com)
• The snapshot of next XOOPS Cube released, with documents (sunday-lab.blogspot.com)
• Reimagining file distribution: universal downloads (istartedsomething.com)
• extoolsD Project (sunday-lab.blogspot.com)

Marcadores: CMS, Cube, Download, FTP, MySQL, PHP, Protector, Release, Security, Windows, XOOPS

---

# 11/19/2006 12:00:00 AM, Comentários, Links para esta postagem,