безопасно или небезопасно потенциально видеть их PHP session_id () - PullRequest
Новая
       9

безопасно или небезопасно потенциально видеть их PHP session_id ()

0 голосов
/ 18 декабря 2018

На моем сайте есть jquery, который отправляет запрос из формы входа в мой API.Вот jquery: 

function doLogin()
{
  var userEmail = $("#email").val();
  var userPassword = $("#password").val();

  $.post(
    "https://api.linkenfest.co.uk/access/login/<?= $referrer ?>",
    {
      email: userEmail,
      password: userPassword
    }
  ).done(function( data ){
    var status   = data.data.status;
    var referrer = data.data.referrer;
    var message  = data.data.message;
    var session  = data.data.session;

    alert( message );

    if( status == 200 ){
      window.location.replace( referrer + "?session=" + session );
    }
  }
);

При возвращении успеха ответ от моего API выглядит следующим образом: 

{
  "status": 200,
  "data":{
          "status": 200,
          "referrer": "page.php",
          "message": "Successful login",
          "session": "o3vo1uram0k2mojmbd45pmicr2"
      }
}

Как видно из моего ответа, он включает в себя полученное значениеот php session_id()

Я хотел бы узнать, открывается ли предоставление этой информации пользователю для уязвимости безопасности на сайте.

Значение идентификатора сеанса используется для запуска сеансапосле window.location.reload

Спасибо.

1 Ответ

0 голосов
/ 19 декабря 2018

Как уже отмечали другие в комментариях, клиент, получающий идентификатор сеанса, является стандартным способом управления сеансами - как еще он мог бы отправить его в последующих запросах?Но это имеет значение, как клиент получает его.

Обратите внимание, что приведенный выше код, скорее всего, уязвим.

  1. "https://api.linkenfest.co.uk/access/login/<?= $referrer ?>" - это отражается XSS, если $ referrerзаголовок рефери от запроса.Как и в контексте Javascript, недостаточно просто html-кодирования, вам необходимо javascript-кодирование.

  2. window.location.replace( referrer + "?session=" + session ) - Технически, это открытое перенаправление на параметр referrer.Это не легко использовать, хотя.Лучше всего по-прежнему проверять его (желательно на сервере - который может быть уже на месте).

  3. Слабое управление сеансом, идентификатор сеанса доступен для Javascript.Хотя в некоторых случаях это приемлемо, принятие этого риска должно быть осознанным решением.Идентификатор сеанса обычно (и традиционно) устанавливается в файле cookie httpOnly.Единственное исключение, когда это невозможно сделать, - это когда маркер должен быть отправлен в другой источник.Но в этом случае это не семантический идентификатор сеанса, и должно быть найдено правильное решение единого входа.

  4. Идентификатор сеанса является конфиденциальной информацией, и поэтому его не следует отправлять вURL-адрес.Проблема с URL-адресом заключается в том, что он регистрируется в нескольких местах (браузер пользователя запомнит его и сохранит на диск, он будет зарегистрирован на промежуточных прокси-серверах и в журналах целевого сервера. Это все места, откуда злоумышленник можетбыть в состоянии получить его. Лучше не посылать конфиденциальную информацию в URL, но либо в заголовке (cookie также является просто заголовком), либо в случае необходимости тело запроса также в порядке.

  5. URL-адрес назначения (api.linkenfest.co.uk) уязвим для входа в систему csrf, если он позволяет вам войти таким образом.

Также, глядя на это с более широкой точки зренияВ перспективе я полагаю, что вы используете API в качестве провайдера идентификации для входа в систему. Для этого вам следует использовать стандартный протокол, такой как OpenID Connect, а не изобретать велосипед, потому что, как вы можете видеть выше, этосовсем не просто.

...