Oturum kaçırmayı önlemenin en iyi yolu nedir?


124

Özellikle bu, sunucudaki bir oturumu tanımlamak için bir istemci oturum tanımlama bilgisi kullanıldığında geçerlidir.

Web sitesinin tamamı için SSL / HTTPS şifrelemesini kullanmanın en iyi yanıtı mıdır ve ortadaki hiçbir kişinin mevcut bir istemci oturumu çerezini koklayamayacağına dair en iyi garantiye sahip misiniz?

Ve belki de ikinci en iyi, oturum tanımlama bilginizde depolanan oturum değerinin kendisinde bir tür şifreleme kullanmaktır?

Kötü niyetli bir kullanıcının bir makineye fiziksel erişimi varsa, geçerli bir oturum çerezi almak için dosya sistemine bakabilir ve bunu bir oturumu ele geçirmek için kullanabilir mi?

Yanıtlar:


140

Oturum değerinin şifrelenmesi sıfır etkiye sahip olacaktır. Oturum tanımlama bilgisi zaten keyfi bir değerdir, şifrelemek sadece koklanabilen başka bir keyfi değer üretecektir.

Tek gerçek çözüm HTTPS'dir. Sitenizin tamamında SSL yapmak istemiyorsanız (belki performans endişeleriniz varsa), hassas alanları koruyan yalnızca SSL ile kurtulabilirsiniz. Bunu yapmak için önce giriş sayfanızın HTTPS olduğundan emin olun. Bir kullanıcı oturum açtığında, normal oturum tanımlama bilgisine ek olarak güvenli bir tanımlama bilgisi (yani tarayıcının bunu yalnızca bir SSL bağlantısı üzerinden ileteceği anlamına gelir) ayarlayın. Ardından, bir kullanıcı "hassas" alanlarınızdan birini ziyaret ettiğinde, onları HTTPS'ye yönlendirin ve bu güvenli çerezin varlığını kontrol edin. Gerçek bir kullanıcı buna sahip olacak, bir oturum korsanı olmayacak.

DÜZENLEME : Bu cevap ilk olarak 2008'de yazılmıştır. Şu anda 2016'dır ve sitenizin tamamında SSL olmaması için hiçbir neden yok. Artık düz metin HTTP yok!


28
HTTPS yalnızca koklamayı önleyecektir. Ancak bir XSS'niz varsa veya oturum kimlikleri kolayca tahmin edilebiliyorsa veya oturum sabitlemesine açıksanız veya oturum kimliği depolamanız zayıfsa (SQL enjeksiyonu?), SSL hiçbir gelişme sağlamayacaktır.
Calimo

5
@Josh Kötü niyetli bir kullanıcının bir makineye fiziksel erişimi varsa, geçerli bir oturum tanımlama bilgisi almak için dosya sistemine bakabilir ve bunu bir oturumu ele geçirmek için kullanabilir mi?
Pacerier

72
Kötü niyetli bir kullanıcının bir dosya sistemine fiziksel erişimi varsa, bir oturumu ele geçirmeleri gerekmez.
Josh Hinman

25
@Josh. Doğru değil, bazen bir kullanıcının bir dosya sistemine sınırlı süreli fiziksel erişimi olabilir. Tuvalete koşan bir iş arkadaşımın kilidinin açık bırakıldığını hayal edin, şimdi tek yapmam gereken o dizüstüne gitmek, EditThisCookie eklentisini yüklemek, EditThisCookie dışa aktarma özelliğini kullanarak plus.google.com'da çerezlerini almak ve şimdi onun hesabına sahibim . Alınan süre: 18 saniye.
Pacerier

1
Oturum kaçırma hakkında konuşurken aklınıza gelen ilk şey bu olduğu için
Google'ın bir

42

SSL yalnızca koklama saldırılarına yardımcı olur. Bir saldırganın makinenize erişimi varsa, güvenli çerezinizi de kopyalayabileceğini varsayacağım.

En azından, eski çerezlerin bir süre sonra değerini kaybettiğinden emin olun. Başarılı bir kaçırma saldırısı bile, çerez çalışmayı bıraktığında engellenecektir. Kullanıcının bir aydan daha uzun süre önce oturum açmış bir oturumdan çerezi varsa, parolasını yeniden girmesini sağlayın. Bir kullanıcı sitenizin "çıkış" bağlantısını tıkladığında, eski oturum UUID'sinin bir daha asla kullanılamayacağından emin olun.

Bu fikrin işe yarayıp yaramayacağından emin değilim ama işte: Oturum çerezinize bir seri numarası ekleyin, belki bunun gibi bir dize:

OturumUUID, Seri Numara, Geçerli Tarih / Saat

Bu dizeyi şifreleyin ve oturum tanımlama bilginiz olarak kullanın. Seri numarasını düzenli olarak değiştirin - belki çerez 5 dakikalık olduğunda ve ardından çerezi yeniden yayınlayın. İsterseniz her sayfa görünümünde bile yeniden yayınlayabilirsiniz. Sunucu tarafında, o oturum için yayınladığınız son seri numarasının kaydını tutun. Birisi yanlış seri numaralı bir tanımlama bilgisi gönderirse, bu, saldırganın daha önce yakaladığı bir tanımlama bilgisi kullanıyor olabileceği anlamına gelir, bu nedenle oturum UUID'sini geçersiz kılın ve kullanıcıdan parolasını yeniden girmesini ve ardından yeni bir tanımlama bilgisi göndermesini isteyin.

Kullanıcınızın birden fazla bilgisayarı olabileceğini ve bu nedenle birden fazla etkin oturumu olabileceğini unutmayın. Bilgisayarlar arasında her geçiş yaptıklarında onları tekrar oturum açmaya zorlayan bir şey yapmayın.


Bunun eski bir gönderi olduğunu biliyorum, ancak bir saldırgan "seri numarası" ile ayrılan pencere içinde oturumu ele geçirirse, bunun onu etkilemeyeceğini eklemek istedim.
ezmek

@crush, ancak daha sonra tahsis edilen pencereden sonra saldırgan kilitlenir, değil mi? Yani en azından saldırı penceresi küçüktür (er).
Johanneke

2
Tek sorun, kullanıcı web sitenizi 5 dakikalığına terk ederse, tekrar oturum açmak zorunda
kalacak

21

PHP güvenliği üzerine bir kitap okumayı düşündünüz mü? Şiddetle tavsiye edilir.

SSL sertifikalı olmayan siteler için aşağıdaki yöntemle çok başarılı oldum.

  1. Aynı hesap altında birden fazla oturuma izin vermeyin ve bunu yalnızca IP adresiyle kontrol etmediğinizden emin olun. Bunun yerine, veritabanındaki kullanıcı oturumuyla birlikte depolanan oturum açma sırasında oluşturulan belirteç ve ayrıca IP adresi, HTTP_USER_AGENT vb. İle kontrol edin.

  2. İlişki tabanlı köprüleri kullanma Bir bağlantı oluşturur (ör. Http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) Bağlantı, sayfa yeniden yönlendirildiğinde rastgele oluşturulmuş bir x-BYTE (tercih edilen boyut) rastgele tuzlanmış MD5 dizesiyle eklenir. jeton, istenen bir sayfaya karşılık gelir.

    • Yeniden yükledikten sonra birkaç kontrol yapılır.
    • Kaynak IP Adresi
    • HTTP_USER_AGENT
    • Oturum Jetonu
    • anladın.
  3. Kısa Yaşam süresi oturum kimlik doğrulama tanımlama bilgisi. Yukarıda belirtildiği gibi, oturumların geçerliliğine doğrudan referanslardan biri olan güvenli bir dize içeren bir çerez iyi bir fikirdir. Her x Dakikada bir süresinin dolmasını sağlayın, bu jetonu yeniden yayınlayın ve oturumu yeni Verilerle yeniden senkronize edin. Verilerdeki herhangi bir yanlış eşleşme varsa, kullanıcının oturumunu kapatın veya oturumlarını yeniden doğrulamalarını sağlayın.

Ben hiçbir şekilde bu konuda uzman değilim, bu konuda biraz deneyimim oldu, umarım bunların bir kısmı oradaki herkese yardımcı olur.


4
Tavsiye edebileceğin kitaplar var mı?
Rikki

1
Özellikle OP'nin PHP hakkında özel olarak hiçbir şey söylemediğini düşünürsek, sadece genel bir güvenlik kitabına bakmanın daha iyi olduğunu söyleyebilirim (özellikle farklı diller arasındaki güvenlik sadece uygulama detaylarında farklılık gösterdiğinden, ancak kavramlar aynı kaldığından).
matts1

2017'de facebook / gmail vb. kullanıcılarınızdan nefret etmediğiniz sürece aynı hesap altında (özellikle mobil cihazlarda) birden fazla oturuma izin verir, # 1 biraz modası geçmiş.
cowbert

20
// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();

// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);

// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
    end_session();
    header("Location: login.php");
    // add some fancy pants GET/POST var headers for login.php, that lets you
    // know in the login page to notify the user of why they're being challenged
    // for login again, etc.
}

Bunun yaptığı şey, kullanıcının oturumu hakkındaki 'bağlamsal' bilgileri, tek bir oturumun ömrü boyunca değişmemesi gereken bilgi parçalarını yakalamaktır. Bir kullanıcı aynı anda hem ABD'de hem de Çin'de bilgisayar başında olmayacak, değil mi? Dolayısıyla, IP adresi aynı oturum içinde aniden değişirse ve bu, bir oturumun ele geçirilmesi girişimini kuvvetle ima ederse, oturumu sonlandırarak ve kullanıcıyı yeniden kimlik doğrulaması yapmaya zorlayarak oturumu güvence altına almış olursunuz. Bu, hack girişimini engeller, saldırgan aynı zamanda oturuma erişim kazanmak yerine oturum açmak zorunda kalır. Kullanıcıyı denemeden haberdar edin (biraz yukarı çekin) ve vola, Biraz rahatsız + bilgilendirilmiş kullanıcı ve oturum / bilgileri korunur.

Proxy'lerin / ağların arkasındaki sistemler için bir oturumun benzersizliğini yakalamak üzere elimizden gelenin en iyisini yapmak için Kullanıcı Aracısı ve X-FORWARDED-FOR'u ekliyoruz. Bundan daha fazla bilgiyi kullanabilirsiniz, yaratıcı olmaktan çekinmeyin.

% 100 değil, ama oldukça etkili.

Bir kullanıcı bir web sitesinden ayrıldığında ve geri döndüğünde oturumları korumak, sürelerini sona erdirmek için yapabileceğiniz daha çok şey var ve onları tekrar oturum açmaya zorlayabilir. Boş bir HTTP_REFERER (alan URL çubuğuna yazılmıştır) yakalayarak ayrılan ve geri dönen bir kullanıcıyı tespit edebilir veya HTTP_REFERER'daki değerin alanınıza eşit olup olmadığını kontrol edebilirsiniz (kullanıcı, sitenize ulaşmak için harici / hazırlanmış bir bağlantıyı tıkladı) site).

Oturumları sona erdirin, süresiz olarak geçerli kalmalarına izin vermeyin.

Çerezlere güvenmeyin, çalınabilirler, oturum kaçırma saldırısının vektörlerinden biridir.


3
Daha önce, belirli (oldukça büyük, ancak teknik olarak geri) bir ISS'nin, kullanıcıların bağlantılarını yeniden yönlendirmeye dayalı olarak zaman zaman kullanıcının tarayıcısının IP'sini değiştirdiği bir durumla karşılaştım. Bu, REMOTE_ADDR kontrolünün bizim için yanlış negatifler döndürmesini sağladı.
goofballLogic

Neden bir karma oluşturma zahmetine giresiniz? $_SESSION['ident'] = $aip . $bip . $agent;aynı derecede güvenli olacaktır.
Dan Bray

2
Hareket halindeyken web sitenizi kullanan ve bir erişim noktasından diğerine geçen Mobil kullanıcılarınız varsa, IP'leri değişmeye devam edecek ve hesaplarından çıkış yapmaya devam edecekler.
Kareem

Vekiller ve VPN'ler ne olacak? Bir TOR proxy'si kullanan herkesin hesaplarından sürekli olarak çıkışları olacaktır .. aslında her birkaç dakikada bir.
Bradley

Bunu göz ardı etseniz bile, IP adresleri istemci tarafından manipüle edilebilir, bu nedenle bu, bir saldırganı caydırmak için fazla bir şey yapmaz.
Bradley

9

Liu, Kovacs, Huang ve Gouda tarafından bu makalede açıklanan Secure Cookie protokolünü deneyin :

Belgede belirtildiği gibi:

Bir istemci ve bir sunucu arasında çalışan güvenli bir tanımlama bilgisi protokolünün şu dört hizmeti sağlaması gerekir: kimlik doğrulama, gizlilik, bütünlük ve yeniden oynatma karşıtı.

Dağıtım kolaylığı konusunda:

Verimlilik açısından, protokolümüz herhangi bir veritabanı araması veya açık anahtar kriptografisi içermez. Konuşlandırılabilirlik açısından, protokolümüz mevcut bir web sunucusuna kolayca yerleştirilebilir ve İnternet tanımlama bilgisi spesifikasyonunda herhangi bir değişiklik gerektirmez.

Kısacası: güvenli, hafif ve benim için harika çalışıyor.


9
Bağlantınız protokolün bir özelliğidir - bir uygulamaya bir bağlantınız var mı? Bu harika olurdu, teşekkürler.
Adam

9

Oturum kaçırmayı% 100 engellemenin bir yolu yoktur, ancak bazı yaklaşımlarla bir saldırganın oturumu ele geçirme süresini azaltabiliriz.

Oturum kaçırmayı önleme yöntemi:

1 - her zaman ssl sertifikasıyla oturum kullanın;

2 - oturum tanımlama bilgisini yalnızca HTponly true olarak ayarlanmış şekilde gönderin (javascript'in oturum tanımlama bilgisine erişmesini önleyin)

2 - oturum açma ve oturumu kapatma sırasında oturum yenileme kimliğini kullanın (not: her istekte oturum yenilemeyi kullanmayın çünkü ardışık ajax isteğiniz varsa, birden çok oturum oluşturma şansınız olur.)

3 - bir oturum zaman aşımı ayarlayın

4 - tarayıcı kullanıcı aracısını bir $ _SESSION değişkeninde saklayın ve her istekte $ _SERVER ['HTTP_USER_AGENT'] ile karşılaştırın

5 - bir belirteç çerezi ayarlayın ve bu çerezin sona erme süresini 0 olarak ayarlayın (tarayıcı kapanana kadar). Her istek için tanımlama bilgisi değerini yeniden oluşturun (ajax isteği için token tanımlama bilgisini yeniden oluşturmayın). EX:

    //set a token cookie if one not exist
    if(!isset($_COOKIE['user_token'])){
                    //generate a random string for cookie value
        $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

        //set a session variable with that random string
        $_SESSION['user_token'] = $cookie_token;
        //set cookie with rand value
        setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
    }

    //set a sesison variable with request of www.example.com
    if(!isset($_SESSION['request'])){
        $_SESSION['request'] = -1;
    }
    //increment $_SESSION['request'] with 1 for each request at www.example.com
    $_SESSION['request']++;

    //verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
    if($_SESSION['request'] > 0){

        // if it's equal then regenerete value of token cookie if not then destroy_session
        if($_SESSION['user_token'] === $_COOKIE['user_token']){
            $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

            $_SESSION['user_token'] = $cookie_token;

            setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
        }else{
            //code for session_destroy
        }

    }

            //prevent session hijaking with browser user agent
    if(!isset($_SESSION['user_agent'])){
        $_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
    }

    if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
      die('session hijaking - user agent');
    }

not: belirteç tanımlama bilgisini ajax isteği ile yeniden oluşturmayın not: yukarıdaki kod bir örnektir. not: kullanıcılar oturumu kapatırsa, oturumun yanı sıra çerez simgesi de yok edilmelidir

6 - Oturum kaçırmayı önlemek için kullanıcı ipini kullanmak iyi bir yaklaşım değildir çünkü bazı kullanıcılar her istekte ip değişmektedir. GEÇERLİ KULLANICILARI ETKİLENEN

7 - Kişisel olarak oturum verilerini veritabanında saklıyorum, hangi yöntemi benimseyeceğiniz size kalmış

Yaklaşımımda bir hata bulursanız lütfen beni düzeltin. Eğer seansta huysuzluğu önlemek için başka yollarınız varsa lütfen bana söyleyin.


merhaba, oturum kaçırmayı önlemeye çalışıyorum (ASP.NET'te) ve yukarıda önerilen tüm adımları dikkate aldım. Yaklaşık olarak çalışıyor ancak InPrivateBrowsing / incognito tarayıcı modunu kullandığımda oturum Hijacked. Lütfen sessionId dizesine eklemek için başka bir şey önerebilir misiniz?
Vishwanath Mishra

4

Oturum kimlikleri için artan tamsayılar kullanmadığınızdan emin olun. Bir GUID veya rasgele oluşturulmuş başka bir uzun karakter dizisi kullanmak çok daha iyidir.


3

Oturum kaçırmaya karşı koruma oluşturmanın birçok yolu vardır, ancak bunların tümü ya kullanıcı memnuniyetini azaltır ya da güvenli değildir.

  • IP ve / veya X-FORWARDED-FOR kontrolleri. Bunlar işe yarar ve oldukça güvenlidir ... ancak kullanıcıların acısını hayal edin. WiFi olan bir ofise gelirler, yeni IP adresi alırlar ve oturumu kaybederler. Tekrar giriş yapmalıyım.

  • Kullanıcı Aracısı kontrolleri. Yukarıdakinin aynısı, tarayıcının yeni sürümü çıktı ve bir oturumu kaybedersiniz. Ek olarak, bunların "hacklenmesi" gerçekten çok kolaydır. Bilgisayar korsanlarının sahte UA dizeleri göndermesi önemsizdir.

  • localStorage belirteci. Oturum açtığınızda bir belirteç oluşturun, bunu tarayıcı deposunda saklayın ve şifreli tanımlama bilgisinde (sunucu tarafında şifrelenmiş) saklayın. Bunun kullanıcı için hiçbir yan etkisi yoktur (localStorage, tarayıcı yükseltmeleri boyunca devam eder). O kadar güvenli değil - sadece belirsizlik yoluyla güvenlik. Ek olarak, onu daha da gizlemek için JS'ye biraz mantık (şifreleme / şifre çözme) ekleyebilirsiniz.

  • Tanımlama bilgisi yeniden yayınlanıyor. Muhtemelen bunu yapmanın doğru yolu budur. İşin püf noktası, bir seferde yalnızca bir müşterinin çerez kullanmasına izin vermektir. Bu nedenle, aktif kullanıcı her saat veya daha az bir çerez yeniden düzenlenir. Yenisi verilirse eski tanımlama bilgisi geçersiz olur. Hack'ler yine de mümkündür, ancak yapılması çok daha zordur - hacker veya geçerli kullanıcı erişim reddedilecektir.


1

Oturum açma aşamasında, istemci ve sunucunun gizli bir tuz değeri üzerinde anlaşabileceğini düşünelim. Daha sonra sunucu her güncellemede bir sayım değeri sağlar ve istemcinin (gizli tuz + sayım) karması ile yanıt vermesini bekler. Potansiyel korsanın bu gizli tuz değerini elde etmenin bir yolu yoktur ve bu nedenle bir sonraki karmayı üretemez.


3
Ama bu tuzu kimsenin çalamayacağı müşteri tarafında nasıl saklamak istersiniz?
Dcortez

1

AFAIK, web sunucusunda depolandığı için oturum nesnesine istemcide erişilemez. Ancak, oturum kimliği bir Çerez olarak saklanır ve web sunucusunun kullanıcının oturumunu izlemesine izin verir.

Oturum kimliğini kullanarak oturumun ele geçirilmesini önlemek için, istek nesnesi içindeki web sunucusunda erişilebilen, iki özniteliğin, uzak adres ve uzak bağlantı noktasının bir kombinasyonu kullanılarak oluşturulan bir karma dizeyi oturum nesnesi içinde depolayabilirsiniz. Bu özellikler, kullanıcı oturumunu kullanıcının oturum açtığı tarayıcıya bağlar.

Kullanıcı aynı sistemde başka bir tarayıcıdan veya gizli moddan oturum açarsa, IP adresi aynı kalır, ancak bağlantı noktası farklı olacaktır. Bu nedenle, uygulamaya erişildiğinde, kullanıcıya web sunucusu tarafından farklı bir oturum kimliği atanacaktır.

Aşağıda, oturum kimliğini bir oturumdan diğerine kopyalayarak uyguladığım ve test ettiğim kod var. Oldukça iyi çalışıyor. Bir boşluk varsa, bunu nasıl simüle ettiğinizi bana bildirin.

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpSession session = request.getSession();
    String sessionKey = (String) session.getAttribute("sessionkey");
    String remoteAddr = request.getRemoteAddr();
    int remotePort = request.getRemotePort();
    String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
    if (sessionKey == null || sessionKey.isEmpty()) {
        session.setAttribute("sessionkey", sha256Hex);
        // save mapping to memory to track which user attempted
        Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
    } else if (!sha256Hex.equals(sessionKey)) {
        session.invalidate();
        response.getWriter().append(Application.userSessionMap.get(sessionKey));
        response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId()); 
        response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
        return;
    }
    response.getWriter().append("Valid Session\n");
}

Baeldung'da SHA-256 Hashing'de verilen örneği kullanarak değeri hash etmek için SHA-2 algoritmasını kullandım

Yorumlarınızı dört gözle bekliyoruz.


@zaph Özür dilerim, ancak cevabı tekrar kazanmak için eklemedim. Önemli olan SHA-2 şifrelemesi de değil. Ancak, başka bir kullanıcının oturum kimliği Çerezinin başka bir kullanıcının oturumunda kullanımını tespit edebilmiş olmam, yani orijinal soruda olduğu gibi oturum kaçırma. Çözümümü test ettim ve işe yaradığını buldum. Ama bu konuda uzman değilim, bu yüzden topluluğun cevabımın yeterince iyi olup olmadığını kontrol etmesini istiyorum. Belki kod pasajımın ne yaptığını görebilir ve soruyu cevaplayıp cevaplamadığına karar verebilirsiniz. Teşekkürler!
Jzf

@zaph Hatayı işaret ettiğiniz için teşekkür ederiz. Cevabımı önerinize göre güncelledim. Cevabın yararlı olduğunu düşünüyorsanız, lütfen olumsuz oyunuzu kaldırın.
Jzf

0

Riski azaltmak için, kaynak IP'yi oturumla da ilişkilendirebilirsiniz. Bu şekilde, bir saldırganın oturumu kullanabilmesi için aynı özel ağ içinde olması gerekir.

Yönlendirme başlıklarını kontrol etmek de bir seçenek olabilir, ancak bunlar daha kolay sahteciliğe sahiptir.


7
hayır, dinamik IP'ler aracılığıyla, bir kullanıcının bağlantısı geçici olarak kesildiğinde değiştirilebileceği için veya bir proxy çiftliğinin (örtük veya açık) kullanımıyla değiştirilebileceği için kaynak IP'yi kullanamazsınız. Ayrıca, aynı ISS'den gelen oturum korsanları yasal bir kullanıcıyla aynı proxy ve IP'yi kullanabilir ...
Olaf Kock

1
PHP-Nuke, oturum yaklaşımları hakkında iyi bir sayfaya sahip ve IP'ye bağlanmanın tüm ISS'lerle
Sembiance

4
İplerin değiştirilmesi mobil internet sağlayıcılarında çok yaygındır. Vodafone ile IP'm HER istekle değişir.
Blaise

1
Biraz eski bir gönderi ama bunu daha da ileri götürmek için. IP'ler belirtildiği gibi kötü bir fikirdir. Belirtildiği gibi, mobil kullanıcılar IP'leri dolaşma eğilimindedir. Geçmişte bazı ISS'lerin de dolaşım IP'leri (AOL gibi) vardı, ancak bu yaklaşım IPv4 IP'lerinin yetersizliği ile birlikte şimdi daha popüler hale geliyor. Bu tür ISS'ler arasında Plus net ve BT
Peter

-15

Şununla koruyun:

$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;

12
Burada ne yaptığını göremiyorum.
samayo
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.