Повышение безопасности веб-приложений на основе сеанса php - PullRequest
Новая
       22

Повышение безопасности веб-приложений на основе сеанса php

1 голос
/ 26 января 2020

У меня есть веб-приложение, которое я хочу улучшить в своей безопасности fl aws, я прочитал много статей об этом, но некоторые вопросы до сих пор остаются без ответа. Я ценю вашу помощь.

Прежде всего, у меня есть экран входа в систему. После того, как пользователь вводит свои учетные данные, они проверяются в базе данных (они правильно хэшированы;)), и, если это удается, сервер создает переменную сеанса 

//Jhon id = 1    
$_SESSION["userID"]= '1';

В начале каждого файла php (например, панель инструментов. php) У меня есть следующий код: 

       session_start();
        if(isset($_SESSION['userID'])) {
            if($_SESSION["userID"]==""){header("location:login.php");}
        }else{
            header("location:login.php");
        } 
?>
    <html ...

Для улучшения обслуживания я хочу включить этот код во внешний файл php, например 

include('inc/restricted.php');
?>
        <html ...

My Два основных вопроса:

1) Если злоумышленник попытается повредить или запретить доступ к ограниченным. php, обнаружатся ли остатки приборной панели. php? Можно ли сделать что-то подобное? Если это так, как я могу исправить это так, как я могу включить код безопасности в качестве внешнего файла?

2) Как видите, значения моих переменных сеанса просты (целые числа), должен ли я их изменить хешировать значения? Я думал, что сеанс php был сохранен на стороне сервера, но я читал о некоторых php переменных сеанса, хранящихся в файлах cookie, и теперь я беспокоюсь о возможности создания повара ie со случайным числом и предоставленным доступом.

1 Ответ

2 голосов
/ 26 января 2020
  1. Это возможно, если код в этом файле небезопасен. Поскольку мы не видим этого, невозможно сказать, как это могло быть скомпрометировано. Но, вообще говоря, веб-запрос не должен иметь возможности контролировать ваш код php, если у вас нет крайне небезопасных настроек.
  2. Значения не имеют значения. Данные, хранящиеся в $_SESSION, никогда не хранятся на клиенте, только на сервере. Это контролируется в php интерфейсом session.handler (по умолчанию он хранится в виде простого текстового файла на вашем сервере в session.save_path).

Вещи, которые обычно делают сеансы небезопасными почти всегда являются результатом плохо написанного кода или плохо сконфигурированного сервера.

Ниже перечислены некоторые вещи, которые вы можете сделать для повышения безопасности своих сеансов:

  1. Всегда используйте session_regenerate_id(true) при входе пользователя в систему ( это предотвращает атаки с фиксацией сеанса ).

  2. Всегда удаляйте готовку сеанса ie на клиенте при входе в систему user out ( см. первый пример в http://php.net/session-destroy). Это предотвращает атаки захвата сеанса, когда пользователь входит в систему, например, с компьютера publi c, так как сеанс не всегда может быть мгновенно удален на стороне сервера, а cook ie позволяет клиенту повторно запускать TTL сеанса на сервере.

  3. Передавать файлы cookie сеанса только через безопасное соединение (см. session.cookie_secure

  4. Чтобы предотвратить появление некоторых векторов XSS и CSRF, рассмотрите возможность использования session.cookie_httponly и session.cookie_samesite, чтобы предотвратить атаки злоумышленников JS.

  5. Всегда используйте CSRF-токены вместе со всеми запросами на изменение, чтобы защитить пользователя от компрометации его доступа строго через сеансы. Это дополнительный уровень безопасности.

Просто помните, что это не является неограниченным списком. Безопасность построена по слоям и требует много продуманных вариантов использования и целей.

...