|
Страница 7 из 7
Неизвестность для постороннего (НДП)
Я хотел бы рассеять распространённый миф об НДП. Состоит он в том,
что якобы посредством такой неизвестности нельзя обеспечивать
безопасность. Как упоминалось ранее, НДП не является чем-то, что
предлагает адекватную защиту, и на что стоит полагаться. Тем не менее,
это не означает, что с помощью такой неизвестности совершенно не может
быть обеспечена безопасность. Наоборот, уже имея в качестве основы
безопасный механизм управления сессией, НДП может предложить небольшую
степень дополнительной надёжности.
Помочь может простое использование вводящих в заблуждение имён
переменных для уникального идентификатора и "отпечатков пальцев". Вы
можете также передавать ложные данные, для того чтобы сбить с пути
потенциального атакующего и ввести его в заблуждение. На эти техники
для защиты, безусловно, полагаться никогда не стоит, но вы не даром
потратите время, если организуете немного НДП в вашем собственном
механизме. Для тех, у кого нет базового понимания безопасности сессий,
вероятно, лучше всего поддерживать миф об НДП, иначе кто-нибудь может
быть введён в заблуждение, поверив в то, что она даёт достаточный
уровень защиты.
Важное замечание Б.С: добавлено в апреле 2004-го с подачи RomikChef'а после обсуждения
статьи на webscript.ru.
Ещё раз (это важно!):
(a) если отпечаток класть в сессию (как сделано в листинге 5), то никакого
третьего пункта мы не получаем, и для ВСД нужно выполнить лишь первые два (автор
говорит об этом выше), так как предоставив идентификатор сессии, атакующий автоматически предоставит и отпечаток;
(б) (об этом автор не упоминает) вариант передачи отпечатка в куках отпадает
вообще, так как пользователи с отключёнными куками не смогут работать; остаётся передавать отпечаток GET-ом,
и тогда:
(в) для пользователей с отключёнными куками GETом будет передаваться и
идентификатор сессии, а значит, раз атакующий смог пройти первый пункт и узнать
идентификатор, - то он знает и отпечаток, и третий пункт мы снова не получаем (автор сам говорит и об этом);
(г) (это самое главное и единственный случай, когда мы получаем третий пункт!)
для тех, кто разрешил куки, действительно будет "обеспечен дополнительный
уровень защиты" (о чём тоже говорит автор), но (автор не упоминает об этом), как
и для пункта (в) передача отпечатка GETом требует от разработчика "руками"
делать то, что в случае с идентификатором сессии автоматически делается
включением session.use_trans_sid, т.е. автодополнять отпечатком ссылки и формы.
Кроме того, если и реализовывать пункт (г), то класть в отпечаток заголовки
особого смысла нет (ведь при реализации второго пункта защиты в сессию можно
положить и несколько заголовков); вероятно, вполне достаточно будет и секретного
префикса с идентификатором.
Резюме
Я надеюсь, что вы извлекли кое-что для себя из этой статьи. В
особенности, теперь у вас должно быть базовое понимание того, как
работает web, как достигается возможность сохранения состояния, чем в
действительности являются куки, как работают PHP сессии и некоторые
техники, которые вы можете использовать для улучшения надёжности ваших
сессий.
Если у вас есть какие-либо вопросы или комментарии, — моя контактная информация доступна на моём web-сайте shiflett.org ; также вы можете размещать ваши отзывы на эту статью в форуме PHP Magazine'а forum.php-mag.net.
Я хотел бы услышать о ваших собственных методах безопасного управления
сессией и я надеюсь, что эта статья обеспечит вводную информацию,
которая понадобится вам для поддержки собственного творчества. |