通过GET在脚本中分配sid（会话ID）是危险的吗？

Question

I have seen that I can change the browser and continue to keep the information stored in the session if I assign it with session_id(sid).

I have prepared the following script and it works correctly to keep the session of the sid that I want.

<?php
    echo(session_id());
    if ((isset($_GET['sid'])) && ($_GET['sid'] != session_id())) {
        session_destroy();
        session_id($_GET['sid']);
        session_start();
    }
    echo('<br/>' . session_id());
?>

<pre><?= print_r($_SESSION); ?></pre>
<pre><?= print_r($_COOKIE); ?></pre>

Possible problems and solutions:

- Problem 01: Any string used in $_GET['sid'] ends up generating a session and therefore a file in C:/PHPSSID/sess_xxxxx. Someone could generate a loop and fill the server with content.

Solution: Is it possible to check if a sid exists? If the session exists then it is used otherwise nothing is done. But I have not found any function similar to session_id_exists. I think the only possibility would be to manually check if the file exists manually. Is there another solution?

- Problem 02: In addition to the previous problem. Are there any more security breaches? Is it easy for someone to generate the existing sid from another user? I think it generates 26 digits.

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

Answer 1

You can force the server to accept only existing session identifiers using the session.use_strict_mode setting. From the docs:

session.use_strict_mode boolean

session.use_strict_mode specifies whether the module will use strict session id mode. If this mode is enabled, the module does not accept uninitialized session ID. If uninitialized session ID is sent from browser, new session ID is sent to browser. Applications are protected from session fixation via session adoption with strict mode. Defaults to 0 (disabled).

Note: Enabling session.use_strict_mode is mandatory for general session security. All sites are advised to enable this. See session_create_id() example code for more details.

That said, this is problematic for a lot of reasons. For example, you open yourself up to spying/man-in-the-middle attacks, among other problems. As explained by the Open Web Application Security Project:

Which is the best way to transmit session ids- in cookies, or URL or a hidden variable?

Transmitting session IDs in the URL can lead to several risks. Shoulder surfers can see the session ID; if the URL gets cached on the client system, the session ID will also be stored; the session ID will get stored in the referrer logs of other sites. Hidden variables are not always practical as every request might not be a POST. Cookies are the safest method as cookies do not get cached, are not visible in the W3C or referrer logs, and most users anyway accept cookies.

If you don't rate-limit people or use a WAF (Web Application Firewall), an attacker could theoretically brute-force IDs until they hit a real one, perhaps even an administrator. Depending on how securely you generate your IDs, that might be unrealistic or very practical.