Pequenas dicas para o XOOPS Protector

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

Como pedido pelo João Barroca aqui vão algumas dicas sobre erros que o XOOPS protector apresenta em seu “guia de segurança” o XOOPS protector:

'register_globals' : on INSEGURO

Esta configuração permite uma variedade de ataques por injeção.
Se seu servidor suportar .htaccess, crie ou edite o .htaccess no diretório em que o XOOPS estiver instalado.

/home/cover/public_html/.htaccess.

Php_flag register_globals off.


'allow_url_fopen' : on INSEGURO

Esta configuração permite que atacantes executem scripts remotamente à vontade.
Para alterar esta opção, é necessário ter permissão de administrador do servidor.
Se você é um administrador do servidor, edite o php.ini ou httpd.conf.
Exemplo de httpd.conf:

php_admin_flag allow_url_fopen off.
Caso contrário, contate o suporte de seu host.


'XOOPS_DB_PREFIX' : XOOPS INSEGURO

O prefixo do seu banco de dados é "xoops", o que o faz vulnerável à SQL injection.
Não se esqueça de ativar "Sanitização forçada em caso de detecção de comentário isolado" e as proteções contra SQL injection nas preferências deste módulo. Clique em Gerenciador de PREFIX e dê um novo nome ao seu banco de dados, Quando você mudar o prefix, altere o conteúdo abaixo em seu /home/cover/public_html/mainfile.php

define('XOOPS_DB_PREFIX', 'xoops');

'mainfile.php' :

Quanto a esta opção no meu sistema não deu erros, mais pelo que vi ele verifica se as opções de CHMODe estão corretas.

'Senha de restauração' :

Esta é a forma de restauração se, por alguma razão, você mesmo for adicionado aos IPs banidos do XOOPS. Dando erro aqui é só trocar a senha no final da área “preferências” do módulo.
Se acontecer o problema acesse XOOPS_URL/modules/protector/admin/rescue.php, e insira a senha definida aqui.Se nenhuma senha for definida nesta opção, o efeito desta opção será anulado. Tenha cuidado!

Acho que é isso! Obrigado a todos e principalmente ao Sm0ka pela ajuda espero que estas dicas ajudem mais alguém.

Um abraço!

Carlos  Participativo De: Lorena S.P.  Postagens: 74

Muito bom.

Deveria estar no FAQ..

maumed  Iniciante   Postagens: 2

Se o seu host não permitir o acesso ao htaccess, e tiver feito o "favor" de deixar register_globals on, use o codigo a seguir para obter o mesmo efeito de desativar o globals pelo htaccess. é só colocar isso logo no inicio do mainfile, ou garantir que seja executado no comeco de todos os scripts.

Se a sua versão do PHP for >= 4.1


If (isset($_REQUEST)) foreach ($_REQUEST as $k => $v) unset(${$k});
If (isset($_FILES)) foreach ($_FILES as $k => $v) unset(${$k});
If (isset($_SESSION)) foreach ($_SESSION as $k => $v) unset(${$k});
If (isset($_ENV)) foreach ($_ENV as $k => $v) unset(${$k});
If (isset($_SERVER)) foreach ($_SERVER as $k => $v) unset(${$k});


Se for menor, ou não souber, use essa versão do codigo.

If (isset($HTTP_POST_VARS)) foreach ($HTTP_POST_VARS as $k => $v) unset(${$k});
If (isset($HTTP_GET_VARS)) foreach ($HTTP_GET_VARS as $k => $v) unset(${$k});
If (isset($HTTP_COOKIE_VARS)) foreach ($HTTP_COOKIE_VARS as $k => $v) unset(${$k});
If (isset($HTTP_FILES_VARS)) foreach ($HTTP_FILES_VARS as $k => $v) unset(${$k});
If (isset($HTTP_SESSION_VARS)) foreach ($HTTP_SESSION_VARS as $k => $v) unset(${$k});
If (isset($HTTP_ENV_VARS)) foreach ($HTTP_ENV_VARS as $k => $v) unset(${$k});
If (isset($HTTP_SERVER_VARS)) foreach ($HTTP_SERVER_VARS as $k => $v) unset(${$k});

Maurício.

Observação: qualquer coisa, avisem! escrevi direto aqui e não testei, mas é simples demais para dar algum prob.

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


Estou esperando mais um pouco para ver se alguém mais quer acrescentar algo e depois monto o FAQ com os creditos para o Bishop e Maumed e mando para lá.
Ok?
João Barroca

bishop  Iniciante   Postagens: 0

Maumed,

No protector mostra que esta tudo certo ou continua dando o erro de inseguro? porque cloquei o segundo bloco e não mudou nada.

Um abraço!

jlan  Iniciante   Postagens: 0

Boa noite Maurício.

se a sua versão do PHP for >= 4.1

If (isset($_REQUEST)) foreach ($_REQUEST as $k => $v) unset(${$k});
If (isset($_FILES)) foreach ($_FILES as $k => $v) unset(${$k});
If (isset($_SESSION)) foreach ($_SESSION as $k => $v) unset(${$k});
If (isset($_ENV)) foreach ($_ENV as $k => $v) unset(${$k});
If (isset($_SERVER)) foreach ($_SERVER as $k => $v) unset(${$k});

Como a minha versão do PHP no host local e no servidor remoto é superior à 4.1, coloquei este código, inicialmente, no host local (funcionou perfeitamente), porém, ao colocá-lo no servidor remoto, simplesmente, o "'register_globals" permanece ativado (on).
Alguém sabe o que pode está acontecendo para não ser efetivada esta mudança no servidor remoto?
Att. jlan.

Gislaine  Ocasional   Postagens: 36

Opa Jlan

Você colocou isto no arquivo htaccess do raiz de teu portal ou alterou o seu maifile?

jlan  Iniciante   Postagens: 0

.
Coloquei no mainfile.
Att. jlan.

Gislaine  Ocasional   Postagens: 36

E agora acho que faltou incluir em algum outro script que precisa especialmente disto.
Eu vou mudar temporariamente o register global de meu servidor remoto Linux para testar isto e volto com a resposta
Perai.

jlan  Iniciante   Postagens: 0

Ok Gisa_Iagami...

Gislaine  Ocasional   Postagens: 36

Onde é que nois estava mesmo,. rss perdi até o rumo agora, Argentina 3 x 0 Brasil e fim de primeiro tempo, a coisa está preta.

Esta mensagem você ainda não tem neh?

'allow_url_fopen' : on INSEGURO
Esta configuração permite que atacantes executem scripts remotamente à vontade.
Para alterar esta opção, é necessário ter permissão de administrador do servidor.
Se você é um administrador do servidor, edite o php.ini ou httpd.conf.

Bom, dentro do XOOPS protetor deveria ter resolvido, mas não deu para testar no meu servidor. Acho que so vai dar para ver amanha sorry

jlan  Iniciante   Postagens: 0

Esta mensagem você ainda não tem neh?

'allow_url_fopen' : on INSEGURO
Esta configuração permite que atacantes executem scripts remotamente à vontade.
Para alterar esta opção, é necessário ter permissão de administrador do servidor.
Se você é um administrador do servidor, edite o php.ini ou httpd.conf.

Esta mensagem aparece também...
Att. jlan.

maumed  Iniciante   Postagens: 2

jlan,

Esse codigo não muda a diretiva register_globals (ela continuara on), porem produz o mesmo efeito de desativa-la. o register_globals transforma os valores desses arrays($_POST, $_GET, etc) em variaveis globals. o que o script faz é destruir essas variaveis globais criadas automaticamente, o que impede que alguém tente injetar dados no script (a razao da inseguranca do globals on).

Assim, embora o protector continue dizendo que é inseguro, você ainda não esta mais vulneravel aos ataques devido a essa diretiva estar on.
Maurício

jlan  Iniciante   Postagens: 0

Obrigado maumed.
Eu pensava que o código iria mudar o status para off.
Valeu.
Att. jlan.

bishop  Iniciante   Postagens: 0

Gallera,

Não sei se no de vocês aconteceu mais colocando o'segundo bloco de script, quando entro em adm, e aparece a tela para escolher qual opção, clicando-se na opção volta sempre para a tela e não entra na opção, retirei estes comando e entrou normalmente. oque pode ser?

Um abraço!

Bishop.
Coversbr.cjb.net

izzy  Iniciante   Postagens: 0

Nussssss, nunca vi isso... qual versão de XOOPS Protector que tu está usando?

bishop  Iniciante   Postagens: 0

a 2.4

izzy  Iniciante   Postagens: 0

Eu utilizo essa versão e nunca tive problema parecido.

Coloque o screenshot para a gente ver isso ae.

maumed  Iniciante   Postagens: 2

é esta dando essa pane mesmo.

O problema é que aquele trecho de codigo deve ser a primeira coisa a ser inserida, para evitar esse tipo de situação... na area administrativa do XOOPS, ele usa coisas assim:


If (isset($_POST['fct'])) {
$fct = trim($_POST['fct']);
}
If (isset($_GET['fct'])) {
$fct = trim($_GET['fct']);
}
If (isset($fct) && $fct == "users") {
$xoopsOption['pagetype'] = "user";
}
Include "../../mainfile.php";


Ele traz variaves para o escopo global, o que na minha opiniao é uma pessima pratica em programação... O mesmo efeito pode ser obtido usando uma referencia a $_REQUEST['fct'], embora esse trecho seja de todo estranho, com variaveis passadas via get sobrepondo as passadas via post.

Enfim, o fato é que na hora que chama o mainfile (e aquele trecho de codigo), essas variaveis são destruidas e o script acha que nenhum parametro foi informado.

Soluções?

Tentar encontrar um arquivo que seja incluido no inicio de todos os arquivos (os que estão na sequencia do mainfile não servem) ou esquecer a ideia rs. A opção de tentar identificar se é um arquivo administrativo é furada... esse problema pode estar em outros módulos. Para quem *precisa* de globals off em algum módulo especifico, senão ele não funciona ou dá problema, coloca no inicio dos arquivos dele manualmente.

Estando realmente no inicio do arquivo (ou melhor, sendo os primeiros comandos executados na página, considerando os includes/etc), não dá problema.
Nenhum.
Maurício

bishop  Iniciante   Postagens: 0

maumed,

Que dizer? snifff...

costacafj  Iniciante   Postagens: 0

comunidade, essas dicas brotando estão uma beleza. Continuem assim!

maumed  Iniciante   Postagens: 2

o que é ironico é que isso aqui.


If (isset($_POST['fct'])) {
$fct = trim($_POST['fct']);
}
If (isset($_GET['fct'])) {
$fct = trim($_GET['fct']);
}


é uma gambiarra para "simular" um globals on... Na minha opiniao, é um estilo de programação meio pobre. O "ironico" é que isso esta na gestão do XOOPS... A gente fica aqui preocupado em como resolver coisas no geral, pensando mais em termos de módulos, e da de cara com isso no core.

Falando em termos de programação ruim, até algo assim talvez fosse melhor:

If (isset($_GET['fct']) && !isset($_POST['fct'])) $_POST['fct'] = $_GET['fct'];


E depois utilizar as referencias a $_POST['fct']... Mas tenhamos fé! a versão 2.2 vai nos redimir rs.
Maurício

ini  Ocasional   Postagens: 28

bishop escreveu:

'register_globals' : on INSEGURO

Esta configuração permite uma variedade de ataques por injeção.
Se seu servidor suportar .htaccess, crie ou edite o .htaccess no diretório em que o XOOPS estiver instalado.

/home/cover/public_html/.htaccess.

Php_flag register_globals off.


Qual é a permissão para o arquivo .htaccess? 644 está bom?

João Paulo  Participativo   Postagens: 142

ini, você conseguiu criar um arquivo .htaccess para colocar dentro do diretório do xoops? Se conseguiu, como eu faço um e quais os códigos coloco dentro deste arquivo?

Valeu ini e a todos do XOOPS

ini  Ocasional   Postagens: 28

Para fazer o arquivo .htaccess, receita do bolo:

-Abra o bloco de notas do windows, ou qualquer editor de textos;
-cole o seguinte código nele:

php_flag register_globals off 

-clique em "salvar como" e então em tipo de arquivo escolha "todos os arquivos", no campo "nome do arquivo" digite .htaccess não esquece do pontinho(.)
-agora é só enviar via FTP para a pasta, no servidor, onde está o XOOPS.

João Paulo  Participativo   Postagens: 142

Oba, Valeu pela dica ini, fiz o que você disse e deu certo, agora o protector está quase tudo "OK", só falta o tal do "'allow_url_fopen' : on INSEGURO", mas já entrei em contato com o administrador do HOST e ainda estão tranferindo meu Ticket de um lado para outro.

'register_globals' : off ok.

'allow_url_fopen' : on INSEGURO
Esta configuração permite que atacantes executem scripts remotamente à vontade.
Para alterar esta opção, é necessário ter permissão de administrador do servidor.
Se você é um administrador do servidor, edite o php.ini ou httpd.conf.
Exemplo de httpd.conf:
Php_admin_flag allow_url_fopen off.
Caso contrário, contate o suporte de seu host.

'XOOPS_DB_PREFIX' : ok.

Ir para o Gerenciador de PREFIX

'mainfile.php' : patched ok.

'Senha de restauração' : ok

Valeu XOOPS

fora  Regular De: -  Postagens: 48



Estou usando o XOOPS Protector em meu portal e depois que instalei este módulo, notei algumas coisas estranhas no meu portal.
Por exemplo, quando você faz login, é redirecionado para o user.php, muito bem, após realizar o login, o user.php é chamado mais a página fica em branco.

Fora isso, acho que não notei nada de estranhou. Alguém enfrentou esse problema?

Abraços.

João Paulo  Participativo   Postagens: 142

XOOPS , entrei em contato com o servidor onde meu portal está hospedado e pedi que editassem o php.ini, agora o XOOPS protector está OK:

'allow_url_fopen' : off ok.

Só que depois dessa alteração o módulo ms_weather deichou de funfa:



Já desinstalei, excluí os aquivos do servidor, madei e instalei de novo, só que não adiantou o problema continua.

Algúem pode ajudar, alguma dica?

Valeu pessoal do XOOPS

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

prezado guaru,
O Wilson já falou algo sobre uma config do servidor para ler HTML - dé uma vasculhada que tem o post dele.
Agora... se isso tudo aconteceu ha pouco tem que se ter [sabe-se Deus porque] paciencia para o yahoo conectar de novo...
Explicação pessima ne?
Enfim... desculpa ai, mas foi o que aconteceu comigo.
Abração

Gislaine  Ocasional   Postagens: 36

Guaru escreveu:
XOOPS , entrei em contato com o servidor onde meu portal está hospedado e pedi que editassem o php.ini, agora o XOOPS protector está OK:

'allow_url_fopen' : off ok.

Só que depois dessa alteração o módulo ms_weather deichou de funfa:



Já desinstalei, excluí os aquivos do servidor, madei e instalei de novo, só que não adiantou o problema continua.

Algúem pode ajudar, alguma dica?

Valeu pessoal do XOOPS

Well, este módulo em especial deve estar usando fopen e aí não vai funcionar mesmo.

Você está usando o módulo XLD do XOOPS também?
Xld é o módulo que captura rss mas possui também alguma coisa que utiliza o fopen e aí também vai dar pau ou não irá mostrar as pesquisas no portal.
Esta diretiva pode anular muita coisa no portal, agora quem souber mais detalhes avise aí XOOPS

João Paulo  Participativo   Postagens: 142

Você está usando o módulo XLD do XOOPS também?
Xld é o módulo que captura rss mas possui também alguma coisa que utiliza o fopen e aí também vai dar pau ou não irá mostrar as pesquisas no portal.

Realmente, instalei o módulo xhld para testar e também não funcionou.
Acho que vou pedir para administradores do host alterarem de novo o php.ini.

Valeu XOOPS

Gislaine  Ocasional   Postagens: 36

Guaru faça isto então e talvez, eu digo talvez você resolverá 2 problemas.

Um seria o seu e outro seria o meu e aí podemos tirar a enquete que está aqui no portal me deixando de cabelos brancos, rss XOOPS

João Paulo  Participativo   Postagens: 142

OKKKK, já entrei em contato com o pessoal onde meu portal está hospedado e já alteraram o 'allow_url_fopen' : off para "ON", agora meu XOOPS protector ficou assim:

'register_globals' : off ok.

'allow_url_fopen' : on INSEGURO
Esta configuração permite que atacantes executem scripts remotamente à vontade.
Para alterar esta opção, é necessário ter permissão de administrador do servidor.
Se você é um administrador do servidor, edite o php.ini ou httpd.conf.
Exemplo de httpd.conf:
Php_admin_flag allow_url_fopen off.
Caso contrário, contate o suporte de seu host.

'XOOPS_DB_PREFIX' : pesca ok.

Ir para o Gerenciador de PREFIX

'mainfile.php' : patched ok.

'Senha de restauração' : ok

Agora os módulos que usam fopen voltaram a funcionar normalmente.

Valeu XOOPS

CCV_Pinto  Iniciante   Postagens: 0

mas uma duvida: deixar on não pode ser inseguro?

O meu aqui está on tb... dae no FTP achei um arquivo php.ini.. seria só eu edita-lo? mas faço como?

E como que eu vejo o log do protector para saber se houve tentativa de invasão?

Abraços

  Pesquisa avançada






Entrada

Codinome:


Senha:





Perdeu a senha?  |Cadastre-se!


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

Associados: 0
Anônimos: 39

outros...

Banner XOOPS Cube