Технологический Болт Генона

Forwarded from Information Security Memes

Алиса, по какому адресу шеллкод записывать?

996 views19:13

Forwarded from There will be no singularity

Рейтинг частотности правил SQL анализатора holistic.dev

За 10 дней прошедших с момента публичного релиза многие из вас откликнулись на призыв протестировать наш сервис, за что вам большое спасибо!
И чтобы как-то отметить эту знаменательную дату (та-дам!), расскажем что же чаще всего мы находили в ваших запросах:

5. like-dynamic-template
4. select-naked
3. de-morgan-laws
2. limit-offset-without-orderby
1. column-not-in-index

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

На пятом месте like-dynamic-template (performance/architect)
Такое правило срабатывает в ситуациях, когда в LIKE или ILIKE встречаются динамические значения. Это плохо влияет и на производительность (индекс, даже если он есть не будет использован) и так себе с точки зрения архитектуры.

На четвертом select-naked (performance/architect/security)
Срабатывает, когда у SELECT нет никаких ограничивающих или группирующих условий.

 SELECT a FROM t

например. Это плохо тем, что будут возвращены значения из всех строк таблицы, что может быть довольно большим объемом данных и это не будет быстро. А во-вторых, что ты такое хранишь в этой таблице, что тебе понадобилось вытащить все данные?

Третье место de-morgan-laws (architect)
Законы де Моргана - это правила раскрытия отрицания в булевой алгебре:
NOT (A OR B) = NOT A AND NOT B
NOT (A AND B) = NOT A OR NOT B
Правило срабатывает, когда встречается отрицание булевых выражений. Почему это может быть проблемой?
В булевой алгебре все немного проще, чем в SQL. NOT это не всегда отрицание в прямом понимании этого слова.
Например, NOT (a IS TRUE) это не a = FALSE, как могло бы показаться. NOT (a IS TRUE) это a = FALSE OR a IS NULL.
Если вы пишете запросы руками, то при дальнейшем чтении понимание таких конструкций будет затруднено.
Избегайте отрицания булевых выражений!

Второе место limit-offset-without-orderby (architect)
Для многих это будет сюрпризом, но в Postgresql нет сортировки по умолчанию. Т.е. порядок строк в результате не гарантирован. Об этом честно написано в документации - "if sorting is not chosen, the rows will be returned in an unspecified order".
Если вы хотите взять первые N строк, то стоит определить порядок, по которому будет понятно где именно находится это самое начало.
На этом месте скорее всего был бы NOTICE select-without-orderby, но он еще не в проде :)

Если в вашем приложении порядок следования строк может влиять я бизнес процессы, крайне рекомендую проверить ваши запросы хотя бы руками (но лучше через holistic.dev)!

И призовое место - column-not-in-index (performance)
Это, конечно, предсказуемо. Правило срабатывает при нахождении колонок, которые не упоминаются в индексах.
Это не говорит о том, что индексы в запросе не используются. Чтобы ответить на такой вопрос, требуется еще немало поработать (я обещал рассказать об этом в ближайшее время).
Само по себе появление такого issue не смертельно. Возможно, эти колонки используются в фильтрации после применения индекса.
В любом случае обратить внимание на эти колонки не будет лишним. Может быть вы обнаружите действительно проблемные места.

1.08K views08:33