В чем особенность экранирования в запросах к БД?

Особенности и стратегии экранирования в SQL-запросах

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

Основные риски без экранирования

1. SQL-инъекции:

-- Пример уязвимого запроса
query := "SELECT * FROM users WHERE login = '" + userInput + "' AND password = '" + password + "'"

-- Если userInput = "' OR '1'='1", запрос всегда вернёт данные
-- Результирующий запрос:
SELECT * FROM users WHERE login = '' OR '1'='1' AND password = 'anything'

1. Нарушение структуры запроса:
   • Некорректные кавычки ломают синтаксис SQL
   • Специальные символы (%, _ в LIKE) могут вызывать неожиданное поведение
   • Разделители (;) позволяют выполнять несколько команд

Специфика экранирования в различных контекстах

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

-- 1. Строковые литералы (требуют экранирования кавычек и спецсимволов)
WHERE name = 'O''Reilly' -- Кавычка экранируется удвоением

-- 2. Числовые литералы (требуют валидации типа)
WHERE id = 42 -- Простая проверка, что значение - число

-- 3. Идентификаторы таблиц/столбцов (требуют обрамления)
SELECT * FROM `order` -- Ключевые слова и идентификаторы с спецсимволами

-- 4. LIKE-паттерны (экранирование % и _)
WHERE name LIKE '100\% discount' -- Экранирование символов подстановки

Практические подходы к экранированию в Go

1. Использование плейсхолдеров (наиболее предпочтительный метод)

// Параметризованные запросы
rows, err := db.Query("SELECT * FROM users WHERE email = ? AND status = ?", email, status)

// Именованные параметры (в некоторых драйверах)
rows, err := db.NamedQuery("SELECT * FROM users WHERE email = :email", map[string]interface{}{"email": email})

2. Ручное экранирование (когда плейсхолдеры невозможны)

// Для идентификаторов
func escapeIdentifier(name string) string {
    return "`" + strings.ReplaceAll(name, "`", "``") + "`"
}

// Для LIKE-паттернов
func escapeLike(pattern string) string {
    pattern = strings.ReplaceAll(pattern, `\`, `\\`)
    pattern = strings.ReplaceAll(pattern, `%`, `\%`)
    pattern = strings.ReplaceAll(pattern, `_`, `\_`)
    return pattern
}

3. Библиотеки для построения запросов

// Использование sqlbuilder или squirrel
sb := sqlbuilder.Select("id", "name").From("users")
sb.Where(sb.Equal("status", "active"))
sb.Where(sb.Like("email", "%@example.com"))

query, args := sb.Build()
rows, err := db.Query(query, args...)

Особенности работы с разными СУБД в Go

1. PostgreSQL:

// Использует нумерованные плейсхолдеры $1, $2
db.Query("SELECT * FROM users WHERE id = $1 AND name = $2", id, name)

1. MySQL:

// Использует позиционные плейсхолдеры ?
db.Query("SELECT * FROM users WHERE id = ? AND name = ?", id, name)

1. SQLite:

// Поддерживает и позиционные, и именованные плейсхолдеры
db.Query("SELECT * FROM users WHERE id = ? AND name = ?", id, name)

Расширенные сценарии и ограничения

Когда плейсхолдеры не работают:

// Динамические имена таблиц/столбцов
tableName := "user_" + region
query := fmt.Sprintf("SELECT * FROM %s WHERE id = ?", escapeIdentifier(tableName))
db.Query(query, userID) // Только значение через плейсхолдер!

// Динамический ORDER BY
orderBy := "name"
direction := "DESC"
// НЕДОПУСТИМО: db.Query("SELECT * FROM users ORDER BY ? ?", orderBy, direction)
// Вместо этого валидируем допустимые значения:
allowedColumns := map[string]bool{"name": true, "email": true, "created_at": true}
if allowedColumns[orderBy] && (direction == "ASC" || direction == "DESC") {
    query := fmt.Sprintf("SELECT * FROM users ORDER BY %s %s", orderBy, direction)
    db.Query(query)
}

Best Practices для Go-разработчиков

1. Всегда используйте подготовленные выражения (db.Prepare) для повторяющихся запросов:

stmt, err := db.Prepare("SELECT * FROM users WHERE email = ?")
defer stmt.Close()

// Многократное безопасное использование
row1 := stmt.QueryRow("alice@example.com")
row2 := stmt.QueryRow("bob@example.com")

1. Валидируйте и нормализуйте данные до экранирования:

// Проверка email перед использованием в запросе
func isValidEmail(email string) bool {
    return emailRegex.MatchString(email) && len(email) <= 255
}

1. Используйте ORM и query builder с осторожностью:

// GORM автоматически экранирует значения, но не идентификаторы
db.Where("email = ?", userInput).Find(&user) // Безопасно
db.Table("user_" + region).Find(&users) // Опасность SQL-инъекции!

1. Аудит и мониторинг:
   • Включайте логирование запросов с параметрами (не значениями!)
   • Используйте статический анализ кода (например, gosec)
   • Регулярно проводите penetration testing

Заключение

Экранирование в Go требует понимания контекста данных в запросе и использования соответствующих инструментов. Параметризованные запросы через database/sql решают 95% проблем, но для динамических идентификаторов и сложных сценариев необходимо дополнительное ручное экранирование с валидацией белых списков. Ключевой принцип: никогда не доверяйте пользовательскому вводу и всегда явно указывайте, как данные должны интерпретироваться СУБД. Современные практики в Go делают безопасное экранирование не сложной задачей, а естественной частью разработки при использовании стандартных библиотек и паттернов.