ДЗ 2

[Fedasov]

1. Защита от SQL Injections

В нашем проекте используется библиотека sqlx от jmoiron, которая предоставляет механизмы для защиты от SQL-инъекций. Она обеспечивает защиту от SQL-инъекций с помощью подготовленных операторов (prepared statements) и плейсхолдеров (placeholders). Ниже приведены ключевые моменты, демонстрирующие, как sqlx помогает предотвратить SQL-инъекции:

• sqlx поощряет использование подготовленных операторов, которые позволяют разделять SQL-код и данные. Это означает, что входные данные пользователя никогда не интерпретируются как часть SQL-запроса. Вместо этого они передаются как значения, что предотвращает возможность инъекции вредоносного SQL-кода.

stmt, err := db.Preparex("SELECT * FROM users WHERE name = ?")
if err != nil {
    // Обработка ошибки
}
err = stmt.Queryx(&users, name)
if err != nil {
    // Обработка ошибки
}

• sqlx использует плейсхолдеры, обозначаемые вопросительными знаками (?), для представления входных данных в подготовленных операторах. Это гарантирует, что входные данные всегда будут правильно экранированы и обработаны как значения, а не как часть SQL-кода.

name := "admin' --evil-injection"
err := db.Get(&user, "SELECT * FROM users WHERE name = ?", name)
if err != nil {
    // Обработка ошибки
}

• sqlx также поддерживает использование шаблонов запросов, которые позволяют безопасно внедрять входные данные в SQL-запросы. Это обеспечивает дополнительный уровень абстракции, предотвращая прямое выполнение SQL-кода.

query := db.Rebind(`SELECT * FROM users WHERE name = {{:.}}`)
err := db.Get(&user, query, "admin' --evil-injection")
if err != nil {
    // Обработка ошибки
}

2. Пулл соединений и параметры соедений

В нашей базе данных установлено максимальное количество подключений равное 100:

 max_connections 
-----------------
 100
(1 row)

Что означает что мы можем всего сделать только 100 подключений и не более иначе будет ошибка. Но и 100 подключений тоже нельзя делать, т.к. количество подключений может расти и мы должны оставить место для них.
Поэтому мы можем установить в приложении максимально возможное количество открытых соединений до БД из нашего пула. Мы выбрали 10, т.к. у нас маленькие нагрузки и сервер, на котором приложение запускается слабенький.

db.SetMaxOpenConns(10)

Так же установили максимальное количество свободных соединений, которые могут храниться в пуле и ждать пока их используют. Это чтобы мы не подключались заново и переиспользовали соединения:

db.SetMaxIdleConns(10)

Параметр указывает, на каких сетевых интерфейсах PostgreSQL будет слушать соединения:
listen_addresses = 'localhost'

3. Настройка параметров сервера и клиента: Тайм-ауты, Логгирование и протоколирование медленных запросов

Для управления подключениями и обеспечения должного уровня безопасности и стабильности, нам важно настроить различные тайм-ауты и параметры логгирования. Это помогает предотвратить проблемы с производительностью и DOS-атаки.

Мы настройки тайм-ауты для запросов и блокировок. Мы установили statement_timeout в 30000 мс (30 секунд). Это ограничивает время выполнения любого отдельного SQL-запроса. Если запрос превышает этот лимит, он будет автоматически отменен. Это помогает предотвратить замедление всей системы из-за одного «вечного» запроса.

statement_timeout = 30000

Аналогично, lock_timeout установлен в 5000 мс (5 секунд). Если запрос не может получить необходимую блокировку в течение этого времени, он будет отменен. Это помогает предотвратить сценарии "взаимной блокировки" или "ожидания".

lock_timeout = 5000

Мы также включили логгирование медленных запросов. Установка параметра log_min_duration_statement в 1000 мс (1 секунда) приведет к тому, что каждый запрос, занимающий более 1 секунды, будет записан в лог. Это очень полезно для выявления и оптимизации медленных запросов.

log_min_duration_statement = 1000

Для более тонкого контроля мы подключили расширения pg_stat_statements и auto_explain. pg_stat_statements собирает статистику обо всех выполненных SQL-запросах, что позволяет нам точно знать, какие запросы занимают больше всего времени, и работать над их оптимизацией. Расширение auto_explain автоматически создает планы объяснения для запросов, которые превышают заданную длительность. Это позволяет нам лучше понимать, что делает каждый запрос и как он может быть оптимизирован.

shared_preload_libraries = 'pg_stat_statements, auto_explain'

pg_stat_statements.max = 10000
pg_stat_statements.track = all

auto_explain.log_min_duration = 5000  # 5 секунды
auto_explain.log_analyze = on