Cách tốt nhất để ngăn chặn chiếm quyền điều khiển phiên là gì?


124

Cụ thể, điều này liên quan đến khi sử dụng cookie phiên khách để xác định phiên trên máy chủ.

Là câu trả lời tốt nhất để sử dụng mã hóa SSL / HTTPS cho toàn bộ trang web và bạn có đảm bảo tốt nhất rằng không có người đàn ông nào trong các cuộc tấn công ở giữa có thể đánh hơi được cookie phiên khách hiện có không?

Và có lẽ tốt nhất thứ hai để sử dụng một số loại mã hóa trên chính giá trị phiên được lưu trữ trong cookie phiên của bạn?

Nếu người dùng độc hại có quyền truy cập vật lý vào máy, họ vẫn có thể xem hệ thống tệp để truy xuất cookie phiên hợp lệ và sử dụng quyền đó để chiếm quyền điều khiển phiên?

Câu trả lời:


140

Mã hóa giá trị phiên sẽ không có hiệu lực. Cookie phiên đã là một giá trị tùy ý, mã hóa nó sẽ chỉ tạo ra một giá trị tùy ý khác có thể được đánh hơi.

Giải pháp thực sự duy nhất là HTTPS. Nếu bạn không muốn làm SSL trên toàn bộ trang web của mình (có thể bạn có lo ngại về hiệu suất), bạn có thể thoát khỏi chỉ với SSL bảo vệ các khu vực nhạy cảm. Để làm điều đó, trước tiên hãy đảm bảo trang đăng nhập của bạn là HTTPS. Khi người dùng đăng nhập, hãy đặt cookie an toàn (có nghĩa là trình duyệt sẽ chỉ truyền nó qua liên kết SSL) bên cạnh cookie phiên thông thường. Sau đó, khi người dùng truy cập vào một trong những khu vực "nhạy cảm" của bạn, hãy chuyển hướng họ đến HTTPS và kiểm tra sự hiện diện của cookie an toàn đó. Một người dùng thực sự sẽ có nó, một kẻ tấn công phiên sẽ không.

EDIT : Câu trả lời này ban đầu được viết vào năm 2008. Bây giờ là năm 2016 và không có lý do gì để không có SSL trên toàn bộ trang web của bạn. Không còn bản rõ HTTP nữa!


28
HTTPS sẽ chỉ ngăn chặn việc đánh hơi. Nhưng nếu bạn có XSS, hoặc ID phiên có thể dễ dàng đoán ra hoặc bạn dễ bị sửa lỗi phiên hoặc lưu trữ ID phiên của bạn yếu (SQL SQL?), SSL sẽ không cải thiện được gì cả.
Calimo

5
@Josh Nếu người dùng độc hại có quyền truy cập vật lý vào máy, họ vẫn có thể xem hệ thống tệp để truy xuất cookie phiên hợp lệ và sử dụng tệp đó để chiếm quyền điều khiển phiên?
Pacerier

72
Nếu người dùng độc hại có quyền truy cập vật lý vào hệ thống tệp, họ không cần phải chiếm quyền điều khiển phiên.
Josh Hinman

25
@Josh. Không đúng, đôi khi người dùng có giới hạn thời gian truy cập vật lý vào hệ thống tệp. Hãy tưởng tượng một máy tính xách tay bị mở khóa bởi một đồng nghiệp đang chạy vào nhà vệ sinh, bây giờ tất cả những gì tôi cần làm là vào máy tính xách tay đó, cài đặt plugin Edit ThisCookie, lấy cookie của anh ấy tại plus.google.com bằng tính năng xuất khẩu Edit ThisCookie và bây giờ tôi có tài khoản của anh ấy . Thời gian thực hiện: 18 giây.
Pacerier

1
Tôi khá chắc chắn rằng google sẽ tích hợp một số tính năng bảo mật vì đây rõ ràng là điều đầu tiên bạn nghĩ đến khi nói về việc chiếm quyền điều khiển phiên
xorinzor

42

SSL chỉ giúp với các cuộc tấn công đánh hơi. Nếu kẻ tấn công có quyền truy cập vào máy của bạn, tôi sẽ cho rằng họ cũng có thể sao chép cookie bảo mật của bạn.

Ít nhất, hãy chắc chắn rằng các cookie cũ sẽ mất giá trị sau một thời gian. Ngay cả một cuộc tấn công chiếm quyền điều khiển thành công cũng sẽ bị cản trở khi cookie ngừng hoạt động. Nếu người dùng có cookie từ một phiên đăng nhập hơn một tháng trước, hãy yêu cầu họ nhập lại mật khẩu. Đảm bảo rằng bất cứ khi nào người dùng nhấp vào liên kết "đăng xuất" trên trang web của bạn, UUID phiên cũ sẽ không bao giờ được sử dụng lại.

Tôi không chắc ý tưởng này có hoạt động hay không nhưng ở đây sẽ: Thêm số sê-ri vào cookie phiên của bạn, có thể là một chuỗi như thế này:

PhiênUUID, Số sê-ri, Ngày / Giờ hiện tại

Mã hóa chuỗi này và sử dụng nó làm cookie phiên của bạn. Thường xuyên thay đổi số serial - có thể khi cookie được 5 phút và sau đó phát hành lại cookie. Bạn thậm chí có thể phát hành lại nó trên mỗi lượt xem trang nếu bạn muốn. Về phía máy chủ, hãy ghi lại số thứ tự cuối cùng bạn đã cấp cho phiên đó. Nếu ai đó đã từng gửi cookie với số sê-ri sai, điều đó có nghĩa là kẻ tấn công có thể đang sử dụng cookie mà họ đã chặn trước đó để vô hiệu hóa phiên UUID và yêu cầu người dùng nhập lại mật khẩu của họ và sau đó cấp lại cookie mới.

Hãy nhớ rằng người dùng của bạn có thể có nhiều máy tính để họ có thể có nhiều hơn một phiên hoạt động. Đừng làm điều gì đó buộc họ phải đăng nhập lại mỗi lần họ chuyển đổi giữa các máy tính.


Tôi biết đây là một bài viết cũ, nhưng chỉ muốn bao gồm rằng nếu kẻ tấn công chiếm quyền điều khiển phiên trong cửa sổ được phân bổ bởi "số sê-ri" thì điều này sẽ không ảnh hưởng đến anh ta.
nghiền nát

@crush, nhưng sau đó kẻ tấn công sẽ bị khóa sau khi cửa sổ được phân bổ, phải không? Vì vậy, ít nhất là cửa sổ tấn công là nhỏ (er).
Johanneke

2
Vấn đề duy nhất là nếu người dùng rời khỏi trang web của bạn trong 5 phút, họ sẽ phải đăng nhập lại
elipoultorak

21

Bạn đã xem việc đọc một cuốn sách về bảo mật PHP chưa? Rất khuyến khích.

Tôi đã có nhiều thành công với phương pháp sau cho các trang web không được chứng nhận SSL.

  1. Không cho phép nhiều phiên trong cùng một tài khoản, đảm bảo bạn không kiểm tra điều này chỉ bằng địa chỉ IP. Thay vì kiểm tra bằng mã thông báo được tạo khi đăng nhập được lưu trữ với phiên người dùng trong cơ sở dữ liệu, cũng như địa chỉ IP, HTTP_USER_AGENT, v.v.

  2. Sử dụng các siêu liên kết dựa trên Relation Tạo một liên kết (ví dụ: http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) Liên kết được gắn với chuỗi MD5 được tạo ngẫu nhiên x-BYTE (kích thước ưa thích) mã thông báo tương ứng với một trang được yêu cầu.

    • Khi tải lại, một số kiểm tra được thực hiện.
    • Tạo địa chỉ IP
    • HTTP_USER_AGENT
    • Mã thông báo phiên
    • bạn sẽ có được điểm.
  3. Cookie xác thực phiên đời ngắn. như đã đăng ở trên, một cookie chứa một chuỗi bảo mật, là một trong những tham chiếu trực tiếp đến tính hợp lệ của phiên là một ý tưởng hay. Làm cho nó hết hạn sau mỗi x phút, phát hành lại mã thông báo đó và đồng bộ hóa lại phiên với Dữ liệu mới. Nếu có bất kỳ kết quả sai nào trong dữ liệu, hãy đăng xuất người dùng hoặc yêu cầu họ xác thực lại phiên của họ.

Tôi không có nghĩa là một chuyên gia về chủ đề này, tôi đã có một chút kinh nghiệm trong chủ đề cụ thể này, hy vọng một số điều này sẽ giúp bất cứ ai ngoài đó.


4
Có cuốn sách nào bạn muốn giới thiệu không?
Rikki

1
Đặc biệt là OP không nói rõ về PHP một cách cụ thể, tôi sẽ nói rằng tốt hơn là chỉ xem một cuốn sách bảo mật chung (đặc biệt là bảo mật giữa các ngôn ngữ khác nhau chỉ khác nhau về chi tiết triển khai, nhưng các khái niệm vẫn giống nhau).
mat1

trong năm 2017, ngay cả facebook / gmail, v.v ... cho phép nhiều phiên trong cùng một tài khoản (đặc biệt là với thiết bị di động) trừ khi bạn ghét người dùng của mình, # 1 hơi lỗi thời.
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.
}

Những gì nó làm là nắm bắt thông tin 'theo ngữ cảnh' về phiên của người dùng, những mẩu thông tin không nên thay đổi trong suốt vòng đời của một phiên. Một người dùng sẽ không đến máy tính ở Mỹ và Trung Quốc cùng một lúc, phải không? Vì vậy, nếu địa chỉ IP thay đổi đột ngột trong cùng một phiên có nghĩa là mạnh mẽ cố gắng chiếm quyền điều khiển phiên, vì vậy bạn bảo mật phiên bằng cách kết thúc phiên và buộc người dùng phải xác thực lại. Điều này cản trở nỗ lực hack, kẻ tấn công cũng buộc phải đăng nhập thay vì giành quyền truy cập vào phiên. Thông báo cho người dùng về nỗ lực (ajax it up a bit) và vola, Hơi khó chịu + người dùng được thông báo và phiên / thông tin của họ được bảo vệ.

Chúng tôi sử dụng Tác nhân người dùng và X-FORWARDED-FOR để làm hết sức mình để nắm bắt tính duy nhất của phiên đối với các hệ thống đằng sau proxy / mạng. Bạn có thể sử dụng nhiều thông tin hơn sau đó, hãy thoải mái sáng tạo.

Nó không phải là 100%, nhưng nó khá hiệu quả.

Bạn có thể làm nhiều hơn để bảo vệ phiên, hết hạn chúng, khi người dùng rời khỏi trang web và quay lại buộc họ phải đăng nhập lại. Bạn có thể phát hiện người dùng rời đi và quay lại bằng cách chụp HTTP_REFERER trống (tên miền đã được nhập vào thanh URL) hoặc kiểm tra xem giá trị trong HTTP_REFERER có bằng tên miền của bạn hay không (người dùng đã nhấp vào liên kết bên ngoài / được tạo để nhận Địa điểm).

Hết hạn phiên, đừng để chúng vẫn còn hiệu lực vô thời hạn.

Đừng dựa vào cookie, chúng có thể bị đánh cắp, đó là một trong những phương tiện tấn công để chiếm quyền điều khiển phiên.


3
Tôi đã gặp phải tình huống trước khi một ISP nhất định (khá lớn, nhưng lạc hậu về mặt kỹ thuật) sẽ thay đổi IP của trình duyệt của người dùng theo thời gian dựa trên việc định tuyến lại các kết nối của người dùng của họ. Điều này làm cho kiểm tra REMOTE_ADDR trả lại âm tính giả cho chúng tôi.
goofballLogic

Tại sao phải tạo ra một hàm băm? $_SESSION['ident'] = $aip . $bip . $agent;sẽ được an toàn.
Dan Bray

2
Nếu bạn có người dùng Di động sử dụng trang web của bạn khi đang di chuyển và chuyển từ điểm truy cập này sang điểm truy cập khác, IP của họ sẽ tiếp tục thay đổi và họ sẽ tiếp tục đăng xuất khỏi tài khoản của họ.
Kareem

Còn proxy và VPN thì sao? Bất cứ ai sử dụng proxy TOR sẽ liên tục đăng xuất khỏi tài khoản của họ .. cứ sau vài phút thực tế.
Bradley

Ngay cả khi bạn bỏ qua điều đó, địa chỉ IP có thể bị khách hàng thao túng, do đó, điều này sẽ không ảnh hưởng nhiều đến kẻ tấn công.
Bradley

9

Hãy thử giao thức Cookie bảo mật được mô tả trong này bài viết của Liu, Kovacs, Huang và Gouda:

Như đã nêu trong tài liệu:

Một giao thức cookie an toàn chạy giữa máy khách và máy chủ cần cung cấp bốn dịch vụ sau: xác thực, bảo mật, toàn vẹn và chống phát lại.

Để dễ triển khai:

Về hiệu quả, giao thức của chúng tôi không liên quan đến bất kỳ tra cứu cơ sở dữ liệu hoặc mật mã khóa công khai nào. Về khả năng triển khai, giao thức của chúng tôi có thể dễ dàng được triển khai trên một máy chủ web hiện có và nó không yêu cầu bất kỳ thay đổi nào đối với đặc tả cookie Internet.

Tóm lại: nó an toàn, nhẹ, hoạt động với tôi chỉ tuyệt vời.


9
Liên kết của bạn là một thông số kỹ thuật của giao thức - bạn có liên kết đến việc triển khai không? Đó sẽ là lời cảm ơn tuyệt nhất.
Adam

9

Không có cách nào để ngăn chặn phiên chiếm quyền điều khiển 100%, nhưng với một số cách tiếp cận, chúng tôi có thể giảm thời gian cho kẻ tấn công chiếm quyền điều khiển phiên.

Phương pháp ngăn chặn chiếm quyền điều khiển phiên:

1 - luôn luôn sử dụng phiên với chứng chỉ ssl;

2 - chỉ gửi cookie phiên với httponly được đặt thành true (ngăn javascript truy cập cookie phiên)

2 - sử dụng id tái tạo phiên khi đăng nhập và đăng xuất (lưu ý: không sử dụng tái tạo phiên theo từng yêu cầu vì nếu bạn có yêu cầu ajax liên tiếp thì bạn có cơ hội tạo nhiều phiên.)

3 - đặt thời gian chờ phiên

4 - lưu trữ tác nhân người dùng trình duyệt trong biến $ _SESSION so sánh với $ _SERVER ['HTTP_USER_AGENT'] tại mỗi yêu cầu

5 - đặt cookie mã thông báo và đặt thời gian hết hạn của cookie đó thành 0 (cho đến khi trình duyệt được đóng). Tạo lại giá trị cookie cho mỗi yêu cầu. (Đối với yêu cầu ajax không tạo lại cookie mã thông báo). VÍ DỤ:

    //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');
    }

lưu ý: không tạo lại cookie mã thông báo với ghi chú yêu cầu ajax: mã ở trên là một ví dụ. lưu ý: nếu người dùng đăng xuất thì mã thông báo cookie phải bị hủy cũng như phiên

6 - không nên sử dụng ip người dùng để ngăn chặn việc chiếm quyền điều khiển phiên vì một số người dùng thay đổi ip với mỗi yêu cầu. R USNG NGƯỜI SỬ DỤNG CÓ GIÁ TRỊ

7 - cá nhân tôi lưu trữ dữ liệu phiên trong cơ sở dữ liệu, tùy thuộc vào phương pháp bạn áp dụng

Nếu bạn tìm thấy sai lầm trong cách tiếp cận của tôi xin vui lòng sửa chữa cho tôi. Nếu bạn có nhiều cách hơn để ngăn chặn phiên làm việc, xin vui lòng cho tôi biết.


xin chào, tôi đang cố gắng ngăn chặn chiếm quyền điều khiển phiên (trong ASP.NET) và xem xét tất cả các bước trên mà bạn đề xuất. Nó hoạt động gần đúng nhưng khi tôi sử dụng chế độ InPrivateBrowsing / ẩn danh của trình duyệt thì phiên bị tấn công. Bạn có thể đề nghị thêm bất cứ điều gì để thêm vào chuỗi sessionId không?
Vishwanath Mishra

4

Đảm bảo bạn không sử dụng số nguyên tăng dần cho ID phiên. Tốt hơn nhiều để sử dụng GUID hoặc một số chuỗi ký tự được tạo ngẫu nhiên dài khác.


3

Có nhiều cách để tạo ra sự bảo vệ chống lại việc chiếm quyền điều khiển phiên, tuy nhiên tất cả chúng đều làm giảm sự hài lòng của người dùng hoặc không an toàn.

  • Kiểm tra IP và / hoặc X-FORWARDED-FOR. Những công việc này, và khá an toàn ... nhưng hãy tưởng tượng nỗi đau của người dùng. Họ đến một văn phòng có WiFi, họ nhận được địa chỉ IP mới và mất phiên. Phải đăng nhập lại.

  • Đại lý người dùng kiểm tra. Tương tự như trên, phiên bản mới của trình duyệt đã bị loại và bạn mất một phiên. Ngoài ra, đây là những thực sự dễ dàng để "hack". Việc tin tặc gửi các chuỗi UA giả là chuyện nhỏ.

  • mã thông báo localStorage. Khi đăng nhập, tạo mã thông báo, lưu trữ trong bộ lưu trữ của trình duyệt và lưu trữ vào cookie được mã hóa (được mã hóa ở phía máy chủ). Điều này không có tác dụng phụ cho người dùng (localStorage vẫn tồn tại thông qua nâng cấp trình duyệt). Nó không an toàn - vì nó chỉ bảo mật thông qua che khuất. Ngoài ra, bạn có thể thêm một số logic (mã hóa / giải mã) vào JS để làm mờ thêm nó.

  • Cookie phát hành lại. Đây có lẽ là cách đúng đắn để làm điều đó. Bí quyết là chỉ cho phép một khách hàng sử dụng cookie tại một thời điểm. Vì vậy, người dùng hoạt động sẽ được cấp lại cookie mỗi giờ hoặc ít hơn. Cookie cũ bị vô hiệu nếu cái mới được ban hành. Việc hack vẫn có thể xảy ra, nhưng khó thực hiện hơn nhiều - cả tin tặc hoặc người dùng hợp lệ sẽ bị từ chối truy cập.


1

Chúng ta hãy xem xét rằng trong giai đoạn đăng nhập, máy khách và máy chủ có thể đồng ý về một giá trị muối bí mật. Sau đó, máy chủ cung cấp một giá trị đếm với mỗi bản cập nhật và mong muốn khách hàng phản hồi với hàm băm của (số muối + số bí mật). Kẻ tấn công tiềm năng không có cách nào để có được giá trị muối bí mật này và do đó không thể tạo ra hàm băm tiếp theo.


3
Nhưng làm thế nào để bạn muốn lưu trữ muối này ở phía khách hàng mà không ai có thể đánh cắp nó?
Dcortez

1

AFAIK đối tượng phiên không thể truy cập tại máy khách, vì nó được lưu trữ tại máy chủ web. Tuy nhiên, id phiên được lưu trữ dưới dạng Cookie và nó cho phép máy chủ web theo dõi phiên của người dùng.

Để ngăn chặn chiếm quyền điều khiển phiên bằng id phiên, bạn có thể lưu trữ chuỗi băm bên trong đối tượng phiên, được thực hiện bằng cách sử dụng kết hợp hai thuộc tính, addr từ xa và cổng từ xa, có thể được truy cập tại máy chủ web bên trong đối tượng yêu cầu. Các thuộc tính này ràng buộc phiên người dùng với trình duyệt nơi người dùng đăng nhập.

Nếu người dùng đăng nhập từ một trình duyệt khác hoặc chế độ ẩn danh trên cùng một hệ thống, addr IP sẽ giữ nguyên, nhưng cổng sẽ khác. Do đó, khi ứng dụng được truy cập, người dùng sẽ được máy chủ web gán một id phiên khác.

Dưới đây là mã tôi đã triển khai và kiểm tra bằng cách sao chép id phiên từ phiên này sang phiên khác. Nó hoạt động khá tốt. Nếu có một kẽ hở, hãy cho tôi biết bạn đã mô phỏng nó như thế nào.

@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");
}

Tôi đã sử dụng thuật toán SHA-2 để băm giá trị bằng cách sử dụng ví dụ được đưa ra tại SHA-256 Hashing tại baeldung

Mong muốn được bình luận của bạn.


@zaph Tôi xin lỗi, nhưng tôi đã không thêm câu trả lời để đạt được đại diện. Điểm không phải là mã hóa SHA-2. Nhưng thực tế là tôi đã có thể phát hiện việc sử dụng Cookie phiên id của người dùng khác vào phiên của người dùng khác, tức là chiếm quyền điều khiển phiên như trong câu hỏi ban đầu. Tôi đã thử nghiệm giải pháp của tôi và thấy nó hoạt động. Nhưng tôi không phải là chuyên gia về vấn đề này, vì vậy tôi muốn cộng đồng kiểm tra xem câu trả lời của tôi có đủ tốt không. Có lẽ bạn có thể xem đoạn mã của tôi làm gì và quyết định xem nó có trả lời câu hỏi không. Cảm ơn!
Jzf

@zaph Cảm ơn bạn đã chỉ ra sai lầm. Tôi đã cập nhật câu trả lời của tôi theo đề nghị của bạn. Vui lòng xóa phiếu bầu của bạn xuống nếu bạn nghĩ rằng câu trả lời là hữu ích.
Jzf

0

Để giảm rủi ro, bạn cũng có thể liên kết IP gốc với phiên. Bằng cách đó, kẻ tấn công phải ở trong cùng một mạng riêng để có thể sử dụng phiên.

Kiểm tra các tiêu đề người giới thiệu cũng có thể là một tùy chọn nhưng chúng dễ bị giả mạo hơn.


7
không, bạn không thể sử dụng IP gốc, vì nó có thể thay đổi - thông qua IP động, đã thay đổi khi người dùng tạm thời bị ngắt kết nối hoặc thông qua việc sử dụng (ẩn hoặc rõ ràng) của trang trại proxy. Ngoài ra, những kẻ tấn công phiên đến từ cùng một ISP có thể sử dụng cùng một proxy & IP như một người dùng hợp pháp ...
Olaf Kock

1
PHP-Nuke có một trang tốt về cách tiếp cận phiên của họ và họ nói chi tiết về cách kết nối nó với IP không hoạt động với tất cả các ISP phpnuke.org/
Kẻ

4
Thay đổi Ip là rất phổ biến với các nhà cung cấp internet di động. Với Vodafone, IP của tôi thay đổi với MỌI yêu cầu.
Blaise

1
Một phần của một bài viết cũ nhưng để thêm điều này. IP là như một ý tưởng tồi. Như người dùng di động đã đề cập có xu hướng chuyển vùng IP. Một số ISP trước đây cũng có IP chuyển vùng (như AOL) tuy nhiên phương pháp này hiện đang trở nên phổ biến hơn với sự thiếu hụt IP của IPv4. Các ISP như vậy bao gồm Plus net và BT
Peter

-15

Bảo vệ bằng:

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

12
Tôi không thấy những gì bạn đang làm ở đây.
samay
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.