Kullanıcı giriş yaptığında ne php oturumda saklamak gerekiyor?

9 Cevap php

Kullanıcı giriş Şu anda, ben 2 seans yarattı.

$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name

Böylece, yapman gerektirir bu sayfa, ben sadece bunu:

if(isset($_SESSION['logged_id'])){
// Do whatever I want
}

Herhangi bir güvenlik boşluklar var mı? Yani, benim oturumu kesmek kolaydır? İnsanlar nasıl oturumu kesmek nedir? ve onu nasıl engelleyebilirim?

EDIT:

Sadece bu bulundu:

http://www.xrvel.com/post/353/programming/make-a-secure-session-login-script

http://net.tutsplus.com/tutorials/php/secure-your-forms-with-form-keys/

Sadece bağlantıları, bu yöntemler yeterli iyi bulundu? Lütfen görüşler verin. Ben yine de henüz iyi cevabı yok.

9 Cevap

Terminology

  • User: Bir ziyaretçi.
  • Client: belirli bir makinede yüklü bir özellikle web yapabilen yazılım.


Understanding Sessions

Lütfen oturum güvenli hale getirmek için nasıl anlamak için, ilk seans nasıl çalıştığını anlamak gerekir.

Kullanıcının bu kod parçası görelim:

session_start();

En kısa sürede bu çağrı olarak, PHP PHPSESSID (varsayılan) adında bir çerez için bakacağız. Buldum değilse, bir tane oluşturun:

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3

Bu bulunursa, o PHPSESSID değerini alır ve daha sonra karşılık gelen oturum yükler. Bu değer, bir session_id adlandırılır.

Yani müşteri bilecek tek şeydir. Eğer oturum değişkeni içine eklemek ne olursa olsun sunucuda kalır ve müşteriye transfer asla. Eğer $_SESSION içeriğini değiştirmek eğer değişken değişmez. Her zaman onu yok edene kadar aynı kalır ya da zaman aşımına. Bu nedenle, istemci bu bilgileri alır veya gönderir asla gibi karma veya başka yollarla $_SESSION içeriğini karartmak için denemek için işe yaramaz.

Sonra, yeni bir oturum durumda, değişkenleri koyacaktır:

$_SESSION['user'] = 'someuser';

İstemci bu bilgileri görmek asla.


The Problem

Kötü niyetli bir kullanıcı session_id başka bir kullanıcı çalınca bir güvenlik sorunu ortaya çıkabilir. Kontrol çeşit olmadan, o zaman o kullanıcı kimliğine bürünmek için ücretsiz olacak. Biz benzersiz müşteri (kullanıcı değil) tanımlamak için bir yol bulmalıyız.

Bir strateji (en etkili) oturumu başlatan istemci IP oturumu kullanan kişinin IP olarak aynı olup olmadığını kontrol içerir.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}

// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    die('Session MAY have been hijacked');
}

Bu strateji ile sorunu bir istemci (uzun süreli oturum) bir yük dengeleyici veya kullanıyorsa kullanıcı dinamik IP var, bu yanlış bir uyarı tetikleyecek olmasıdır.

Başka bir strateji, istemci ve kullanıcı kontrol maddesi içerir:

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}

// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
    die('Session MAY have been hijacked');
}

Bu stratejinin olumsuz istemci (bazı kullanıcı aracısı) ekler tarayıcı bulunuyor veya bir addon yükler yükseltmeleri durumunda, kullanıcı aracısı dizesi değişecek ve bunun yanlış bir uyarı tetikleyecek olmasıdır.

Başka bir strateji, her 5 istekleri session_id döndürmektir. Bu şekilde, session_id teorik kaçırıldı olmak için yeterince uzun kalmak değil.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['count'] = 5;
}

// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
    session_regenerate_id();
    $_SESSION['count'] = 5;
}

Dilediğiniz gibi bu stratejilerin her birleştirmek olabilir, ama aynı zamanda downsides birleştirir.

Ne yazık ki, hiçbir çözüm aptal kanıtıdır. Lütfen session_id tehlikeye ise, hemen hemen için yapılır. Yukarıdaki stratejileri sadece stop-boşluk önlemlerdir.

Bu çok saçma.

(Genellikle cross site scripting saldırısı ile) birinin SessionId (otomatik olarak bir tarayıcı tarafından web sunucusuna gönderilen bir çerez olan) yakaladığını zaman oturum kaçırma oluşur.

Birisi örneğin bu gönderdi:

Yani kullanıcı oturum açtığınızda:

// not the most secure hash! $_SESSION['checksum'] = md5($_SESSION['username'].$salt);

Ve hassas bir alana girmeden önce:

if (md5($_SESSION['username'].$salt) != $_SESSION['checksum']) {
handleSessionError(); }

Bu yanlış olan ne ile Lets go

  1. Tuzlar - Yanlış, ama anlamsız değil. Kimse tuzlu ise kimin umurunda, lanet md5 çatlıyor
  2. OTURUM saklanan aynı değişkenin MD5 ile bir oturum değişkeni md5 karşılaştırarak - Eğer oturumda oturumu karşılaştırarak ediyoruz. Şey kaçırıldı ise, bu hiçbir şey yapacağız.
$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name
$_SESSION['hash']      = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']);

// user's name hashed to avoid manipulation

Kimler tarafından manipülasyon kaçının? büyülü oturumu periler? Sunucu tehlikeye sürece oturum değişkenleri değiştirilmiş olmayacaktır. Hash (kullanıcı arayüzleri biraz uzun alabilirsiniz) güzel bir 48 karakter dizesi içine dize yoğunlaşmasına sadece gerçekten var.

En azından ancak şimdi yerine OTURUM verilerine OTURUMU kontrol, onlar (tarayıcı tanımlayan bir dize olan) HTTP_USER_AGENT kontrol ettik, bazı istemci verileri kontrol ediyoruz, bu muhtemelen sizi korumak için yeterli daha fazla olacaktır ama gerçekleştirmek zorunda kişi zaten someway daki SessionId almış ise, şans da kötü adamlar sunucuya bir istek gönderilir ve kötü adam kullanıcı ajan verilir, öylesine akıllı bir hacker kullanıcı ajan parodi ve bu korumayı yenilgi olacaktır ettik vardır.

Eğer üzgün gerçeği vardı olsun Hangi.

Kısa sürede oturum kimliği tehlikeye gibi, sen yoksun. Sen isteğin uzak adresini kontrol ve tüm istekleri aynı kalır (benim yaptığım gibi) ve müşteri tabanının% 99 için mükemmel bir iş olacak emin olabilirsiniz. Sonra bir gün yük dengeli vekil sunucular ile bir ağ kullanan bir kullanıcı bir çağrı alırsınız, istekleri (hatta bazen yanlış ağda) farklı IP'ler bir grup ile buradan geliyor olacak ve o kaybetme olacak onun oturumu sağ ve merkez sol.

Ben ikinci bir 'logged_in' gerekiyor sanırım?

Oturum güvenliği ile ilgili bazı kaynaklar:

phpsec

shiflett

Sen javascript (XSS-> crossside betik saldırısı) üzerinden oturumları çalabilir .. Her zaman oturumu güvenli bir salted MD5 Hash kullanmalısınız.

Oturum ele önlemek için, user agent koymak gerekir

$ _SERVER ['HTTP_USER_AGENT']

de karma içine.

Sizin örnekte:

$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name
$_SESSION['hash']      = md5($YOUR_SALT.$username.$ _SERVER ['HTTP_USER_AGENT']); // user's name hashed to avoid manipulation

Oturumu kullanmadan önce, doğru karma kullandığından emin olun:

if (!$_SESSION['hash']==md5($YOUR_SALT.$username.$ _SERVER ['HTTP_USER_AGENT'])){
  die ('session hash not corrected')
}

PHP oturum güvenliği konusunda bir rehber bulabilirsiniz here.

You can store the IP address, browser signature, etc. to identify the user. At each request, check it against the current values to see if anything suspicious happened.

Bazı insanlar kesinlikle dinamik IP adreslerini kullanan sağlayıcıları arkasında farkında olun, bu yüzden bu insanlar sık ​​sık dışarı günlüğe alabilirsiniz.

Temelde SID tahmin ya da çeşitli yöntemler kullanarak çalmak oturumda tespit, önlemek için. HAYIR olsun oturum mantığı nasıl sophistacated, kesinlikle bir dereceye kadar çalmak sessid karşı savunmasız olacaktır. Eğer önemli bir şey yapmak kimliği her şey yeniden var bu yüzden. Bunu bir post yapmak veya yönetici, ilk çalıştırma oturum regenerate-id bir ayarı değiştirmeden olacaksın Örneğin. Sonra korsan tekrar hack sürecinde gitmek zorunda. Bu temelde hacker diye boşa tüm zaman bir kimlik ile çekilmiş bir zaman verir.

http://us.php.net/manual/en/function.session-regenerate-id.php

Yoksa her öylesine id değiştirmek uyuyabilirsin

if ($ _SESSION ['sayaç'] == 3) {session_regenerate_id (); $ _SESSION ['sayaç'] == 0}

Ayrıca, $ _SERVER ['HTTP_USER_AGENT'] çok güvenilir değildir. Onlar ajanlar yaygın olarak bu kullanılır biliyorum bc hackerlar için uygun çünkü bu nedenle bunu sadece kaçınıyorum, ama. Bunun yerine $ _SESSION ['id_token'] kullanmayı deneyin = sha1 (dosya bellek, dosya adı, zaman gibi bazı çılgın bilgisi).

Bu, bazı iyileştirmeler kırmak için zor yapmak için yapılabilir, olağan log-in kodudur. Öncelikle, kullanıcı adı ve zaman günlük olarak veya alternatif olarak, önceden tanımlanmış bir dize (veya tuz) ile bir sağlama yapabilir ve bu oturumda depolamak ve karşılaştırın.

Yani kullanıcı oturum açtığınızda:

// not the most secure hash!
$_SESSION['checksum'] = md5($_SESSION['username'].$salt);

Ve hassas bir alana girmeden önce:

if (md5($_SESSION['username'].$salt) != $_SESSION['checksum'])
{
  handleSessionError();
}

Varsayılan olarak, seans genellikle sunucu tarafında dosyaları olarak saklamak, ve bir çerez başvurmak için hangi dosya hatırlamak kullanıcının tarayıcısına alınır. Bu oturum hack gelince, nedense korsan çerez bilgileri kullanarak, oturum açma veya oturum verileri değiştirmek başardı çoğaltmak için yeterli bilgi almak.

Ek güvenlik için veritabanlarını kullanarak kendi oturum yönetimini kod olabilir. Bazı sıkı CMS, Joomla gibi, aynı IP kaydeder. Ancak, bazı ISS kullanan kişiler için bu sorunlara neden

SugarCRM inşa ederken ben bu sorunla karşılaşmış oldu, ben izlenir ve (bazı diğer şeyler yanında) kullanıcının IP adresini valide. Ben sadece IP adresinin ilk üç bölümü karşılaştırıldı. Bu, lokal olarak değişken IP adresleri çoğu için izin verdi. Ben de mümkün IP adresi büyük bir varyasyon yaygın tesisler için IP adresi doğrulama kapatmak için yapılmış. Ben sadece IP adresinin başlangıcını karşılaştırarak uygulamanız için böyle ciddi bir sınırlama eklemeden güvenliği ile size yardımcı olur sanırım.

Example: "###.###.###.---" Only the portion of the IP address marked with '#' would be verified.

192.168.1.101
192.168.1.102
192.168.1.XXX

Herkesin eşit kabul edilir.

Jacob