Vetor $_SESSION para outro fim

[Sacomé 0]

Vai falando galera, é o seguite, não vou mais trabalhar com session no meu sistema para locadora não vou falar sobre o sistema porque não é necessário aqui, mas o sistema precisa de segurança máxima mesmo.

 

Não vou mais trabalhar com sessão porque ficar lutando contra roubo de sessão é um tremendo desgaste, por isso, eu vou criar meu próprio sistema de sessão.

 

Após abandonar o velho session_start(); ficaram os vetores $_SESSION['etc...']; mais eles estão em muitas páginas e não quero ficar excluindo-os de página em página.

 

Será que mesmo que acho difícil termos problemas em usar esse vetor como se fosse um array normal, $_SESSION pode ter qualquer valor mesmo sem session_start(); porque session não passa de uma variavel global

$_SESSION['forum']='ibasters';
echo $_SESSION['forum'];

 

A pergunta é: será que tem problema de usar esse vetor do sistema como se fosse um array normal;

 

______________________

[visitante_php 0]

at onde sei, o $_SESSION sao pra variaveis de sessoes...claro que da pra você fazer sua propria funcao de sessao, ou guardar as sessoes no banco de dados..., ou seja, $_SESSION so com session_start, e nao necessariamente precisa usar o session com logins...um exemplo claro eh um carrinho de compras...

[Txai 1]

olha, ele foi feito para uma finalidade, eu te aconselho a ler sobre ele bem afundo, entender o pq ele foi feito, e como ele funciona, pois como não sabemos como funciona(ou irá funcionar) seu sistema, apenas você saberá dizer, pois você saberá os propósitos as quais estará usando aquela variável, e dependendo da situação poderá ser ganho/perda de processamento ou perda/ganho de usabilidade, então, minha opnião, pesquise sobre a variável global $_SESSION e como ela é tratada, e você saberá o que melhor fazer com ela...

 

http://www.php.net/manual/pt_BR/reserved.variables.session.php

 

abraço!

[Sacomé 0]

olha, ele foi feito para uma finalidade, eu te aconselho a ler sobre ele bem afundo, entender o pq ele foi feito

Estamos aqui tentando encontrar problemas em usar $_SESSION como um vetor normal e não o que é $_SESSION.

{$i++},atribuite()_SESSION[sYSTEM_CLEAN_OVERALL]

 

$_SESSION é um variável global como qualquer outra, a diferença é que o sistema a deixa disponível em todo seu script, dentro de funções etc.

 

Se você definir um valor para $_SESSION['tal']='aaa'; então $_SESSION['tal']; será "aaa".

 

O mesmo para $_GET; $_SESSION é igual a $_GET, $_POST etc. $_GET['tal']='aaa'; $_GET['tal'] será "aaa"

 

__________________

[visitante_php 0]

assim como $_POST e $_GET sao variaveis superglobais, você so pega dados de $_GET se enviar um formulario por metodo get, e $_POST em formulario enviado por metodo post, a $_SESSION so ira pegar os dados se iniciar a sessao, e claro a sessao nao serve apenas pra login

[Sacomé 0]

assim como $_POST e $_GET sao variaveis superglobais, você so pega dados de $_GET se enviar um formulario por metodo get, e $_POST em formulario enviado por metodo post, a $_SESSION so ira pegar os dados se iniciar a sessao

 

Amigo, tudo que é colocado antes de =, o que vem depois será o valor, não existe isso de pegar, Eu não to querendo enviar nada.

 

Vou definir $_GET['etc..']='etc...'; pra pegar na mesma página, ou $_SESSION no caso e não por form, você não sabe nem como é o sistema já está falando bobagem.

[Henrique Barcelos 290]

Não dá pra usar $_SESSION sem inicializar a sessão. Normalmente, isso gera um warning. Você pode até desativar esse warning, mas eu não recomendo.

[William Bruno 1501]

Após abandonar o velho session_start(); ficaram os vetores $_SESSION['etc...'];

não faz sentido você retirar o session_start(); e manter a superglobal $_SESSION.

O roubo de sessão vai continuar 'sendo possível', se você usar o $_SESSION. (pelo menos até onde sei)

 

 

A pergunta é: será que tem problema de usar esse vetor do sistema como se fosse um array normal;

e existe alguma utilidade nisso ? Ao meu ver está apenas violando a legibilidade do script. Ao usar algo da forma com a qual não foi criado para.

 

se você quer criar o teu próprio sistema de sessão, então você precisa de algum lugar para persistir os dados.

Seja em um txt na raiz do sistema, um banco de dados ou algo do gênero.

 

 

 

Quero deixar claro que apenas deixar de usar 'session_start()', não vai te deixar mais seguro contra 'roubo de sessão'.

[Sacomé 0]

Fala WBruno, cara, estou procupado com roubo de sessão, já protejo bem meus sistemas contra XSS, mas existe programas que usam o Active-X do IE, para funcionar como navegador e pegar todos os pacotes.

 

Eu não quero por exemplo ter que pedir a data de nascimento da pessoa e outros dados, para não acabar com a navegabilidade do sistema.

 

Cara você sabe um esquema forte contra roubo de sessão, se não vou ter que apenas complicar a vida dos invasores.

 

__________________________

[Bruno Augusto 417]

Sacomé,dá uma olhada nesse tópico e você vai ver, se é que já viu, que você pode armazenar dados que apenas sessões poderiam armazenar E te proporcionar essa "flexibilidade" de diferentes formas, bastante que você criasse seu próprio handler.

 

Se você quer simplesmente usufruir da "super-globalidade" proporcionada pelos arrays super-globais, dá uma estudada sobre Singleton Registry, um padrão de projeto que "resolve" essa questão.

 

Coloquei entre aspas porque, ao que tudo indica com o andar da carruagem, você vai acabar fazendo gambiarra, e não não seria certo apoiar uma prática dessas, afinal, seu sistema e, consequentemente seu bolso (ou de seus clientes, se for o caso) é que soferiam com isso. :thumbsup:

 

No mais, eu apenas te aconselho a não "prostituir" os array super-globais. Eles são nativos e são populados automaticamente de acordo com a requisição feita. Não os viole tentando solucionar um ou outro problema que com certeza conta com diversas soluções mais adequadas.

 

Quanto à discussão paralela, os tópicos foram desaprovados, tornando-os invisíveis para o público. Se se fizer necessário, os mesmos serão excluídos, mas reaprovados não.

 

Os desaprovados mais "leves", foram apenas editados para que não quebrassem o fluxo da conversa.

[Sacomé 0]

Sacomé,dá uma olhada nesse tópico e você vai ver, se é que já viu, que você pode armazenar dados que apenas sessões poderiam armazenar E te proporcionar essa "flexibilidade" de diferentes formas, bastante que você criasse seu próprio handler.

 

E o nível de segurança é de quanto por cento que é o que importa, já "flexibilidade" depende de todo um projeto e não apenas de uma área do projeto, se você implementar sem fazer de novo tudo do zero poderá ocorrer do sistema ficar muitos menos robusto e apresentando até falhas.

 

________

[Bruno Augusto 417]

Eu não vejo como garantir 100% a segurança de um sistema.

 

Existem N fatores a se considerar. Olha só um breve resumo:

 

• Sessões são armazenadas em arquivos no servidor, mas ainda assim, arquivos físicos.
   
  
  1. Se você contratar uma empresa de hospedagem, existe SIM a possibilidade de algum funcionário acessar o sistema operacional do servidor e copiar os arquivos. É improvável haver essa quebra de segurança, mas é possível.
      
     
  2. Se você optar por ter um servidor dedicado
      
     
     1. 
        
     2. Se esse servidor dedicado pertencer à uma empresa de hospedagem, caímos na possibilidade do funcionário salafrário acitado acima.
         
        
     3. Se com "dedicado", você quiser "o seu bebê", terá de ter um servidor inteiro na sua casa, ligado com um bom link de Internet, 24h por dia, prevenido contra falta de energia e etc. Ainda assim vai ter que considerar suas habilidades como Administrador de servidor e redes e manter seu pequeno Frankenstein 100% atualizado contra brechas de acesso e vulnerabilidades que possam gerar uma brecha.
        

   

  Agora, independente da forma como seu site é hospedado:

   

  • Se você criptografar os dados de sessão, vai precisar de uma criptografia de duas vias, afinal, você vai precisar ler os dados a partir dela. Então, MCrypt seria uma boa.
     
    
    1. Por ser uma criptografia de duas vias, a própria biblioteca oferece um meio de descriptografar, bastando que o meliante saiba o algoritimo usado e a chave criptográfica utilizada
        
       

        

       [*]Se você não criptografar, cai na mesma, porém o trabalho do hacker/cracker será menos difícil.

       Pode parecer Teoria da Consipiração, mas acho que elucida bem os pontos principais, afinal não mencionei, até mesmo por não ter conhecimentos profundos na área, sobre scanners, sniffers, rootkits e etc.

        

       A diferença é que já que você já tem uma estrutura pronta, com sessões, usando o descrito no tópico citado, vai ter permitir continuar com a estrutura intocada e, assim, você poderá criar outras formas de segurança que se complementem.

        

       Claro, adaptações serão necessários, mas pelo menos você não vai fazer as coisas de forma errada.

        

       :thumbsup:

    
    
  • Se você codificar, encriptar e obfuscar seu código, com IonCube ou Zend Guard, essas informações ficarão quase impossíveis de se encontrar. Eu disse QUASE, mas se o seu site possuir informações que realmente valham a pena, como dados de cartão de crédito e o invasor conseguiu acesso ao servidor, é óbvio que ele vai tentar reverter com Engenharia Reversa.
     
    
  • Se você não codificar o sistema, além da tarefa de descriptografar os dados da sessão se tornar mais fácil, o seu sistema inteiro estará vulnerável, permitindo que seja feita uma cópia num pendrive e estudado para outras formas de invadir os dados sem toda essa parafernalha tecnológica.
    

[visitante_php 0]

vou citar uma ferramenta muito usada para auditoria de segurança em sistemas, acunetix vulnerability web scanner, excelente...vera que q a seguranca do seu sistema nao depende apenas de seu codigo...

[William Bruno 1501]

[*]Se você contratar uma empresa de hospedagem, existe SIM a possibilidade de algum funcionário acessar o sistema operacional do servidor e copiar os arquivos. É improvável haver essa quebra de segurança, mas é possível.

ai que entra em jogo a escolha de uma empresa de hospedagem idônea e séria.

 

Nenhuma "das grandes", faria uma coisa desse tipo.

Para que trabalha em uma empresa de hospedagem(meu caso), é muito absurdo ouvirem coagitar esse tipo de especulação.

 

 

Isso é algo muito sério, previsto até em contrato jurídico. "Quebra de segurança" para fins maliciosos, por funcionários da empresa de hospedagem, deve ser a última das suas preocupações.. (desde que você não hospede em qualquer fundo de quintal).

[Bruno Augusto 417]

Pois é, você já me disse isso uma vez.

 

E justamente por isso disse que é improvável, mas não impossível.

 

Agora se a empresa responde judicialmente por um furto de informações de seus data centers, eu já não sei.