Подвержен ли запрос SQL атаке по времени?

Question

[swaro]

В моем проекте реализован самописный механизм сессий, который хранит идентификаторы в хешированном виде в базе данных postgresql (скажем, есть специальная таблица sessions с условными колонками user_id и session_key_hashed, где обе колонки индексируются). Каждый реквест php обращается к бд с запросом вида

select user_id from sessions where session_key_hashed = ?

где плейсхолдер = hash(algo, $_COOKIE["session_key"]). Может ли этот запрос быть подвержен атаке по времени?

Comments

[Дмитрий]

У вас же подготовленные выражения

[ThunderCat]

Дмитрий, Вопрос не про инъекции.

Answer 1

[freeExec]

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

Comments

[swaro]

Получается, индексы никак не меняют ситуацию?

[freeExec]

swaro, меняют по сравнению с чем?

Answer 2

[ThunderCat]

Не проще ли дописать дату создания сесcии и в запросе указывать интервал не более (жизни сессии)/(N суток)?
Алсо, можно удалять старые записи, если они не нужны для каких-либо статистик/метрик.

Comments

[trijin]

это ухудшит скорость запроса.
Но согласен с временем жизни, но в запрос включать только статус, а его проставлять в через крон от времени последнего использования.

[ThunderCat]

trijin,

это ухудшит скорость запроса.

Оу, рили? Интересны аргументы, почему?

[trijin]

ThunderCat, сравнительные > < медленнее чем "=" по индексу. тем более будет работать только один из индексов либо по времени, либо по хешу. даже при смешаном.

Статус же можно добавить в индекс на первое место - что вероятно даже ускорит проход по индексу

[ThunderCat]

trijin, так как задача сводится к перебору ключей и подбору непросроченного, то выбирать сразу непросроченные ускоряет выборку, так как ключи все равно нужно перебирать, а ключи по времени хорошо индексируются, в силу вариативности. И если у вас будет 50 ключей разбросанных по таблице, которые все равно потом надо ордерить по дате в поисках последней записи, то выборка из ограниченного по времени интервала будет быстрее. И то, только при некоторых условиях. Вы не знаете ни размера таблицы, ни настроек сервера, ни каких-либо вещей, которые в сферическом запросе в вакууме были бы быстрее или медленнее. Так что утверждать что это в какую-то сторону изменит скорость запроса может только весьма уверенный в себе недоучка.
Ниже несколько аргументов, и советов как и почему так как вы предлагаете нельзя делать:

тем более будет работать только один из индексов либо по времени, либо по хешу. даже при смешаном.

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

но в запрос включать только статус, а его проставлять в через крон от времени последнего использования.

Почему все "самые умные" всегда пытаются решать вопросы просроченности через крон? Вас мало били за использование внешних механик вместо встроенных? Или вы никогда не работали с проектом сложнее блога? Никогда не используйте внешние механизмы проверки, если имеете возможность сделать это средствами отслеживания разницы в датах.

Статус же можно добавить в индекс на первое место - что вероятно даже ускорит проход по индексу

Статус (кроме того что он отсутствует в таблице) внесет в запрос низкоселективную выборку, индекс по этому полю практически бесполезен. Грубо говоря, так как статус у вас либо 1 либо 0, то результатом будет всегда выборка перебором, как более быстрая, так как индексов на 2 значения особо не построишь.