Как безопасно работать с sql?

Question

[v- smerti]

Привет. В интернете не нашел не чего по поводу защиты от sql инъекций в golang. Сейчас есть код

rows, err := DB.Query("SELECT * FROM dev_method WHERE name=?", ps.ByName("methods"))
	if err != nil {
		status.Code503(w, r)
	}
	defer rows.Close()
	bks := make([]*dev_method, 0)
	for rows.Next() {
		bk := new(dev_method)
		err := rows.Scan(&bk.id, &bk.id_menu, &bk.name, &bk.description)
		if err != nil {
			status.Code503(w, r)
		}
		bks = append(bks, bk)
	}
	if err = rows.Err(); err != nil {
		status.Code503(w, r)
	}

какие в нём есть уязвимости и если есть то как их исправить?

Answer 1

[Александр Павлюк]

Запрос тут вполне нормально формируется, с использованием плейсхолдеров. SQL-иньекции быть не может, ибо "?" заменяется на значение через эскейпинг.

Answer 2

[Кирилл]

это напрямую зависит от используемого драйвера, go database/sql за это не отвечает https://golang.org/src/database/sql/sql.go?s=25224...

можно сделать "драйвер" который какраз "заменяет значение через эскейпинг" и привет иньекция

судя по плейсхолдеру это у вас mysql, если используете go-sql-driver то все ок

https://github.com/go-sql-driver/mysql/blob/master...
https://github.com/go-sql-driver/mysql/blob/master...

он использует "подготовленный" запрос, на сервер "отдельно" уйдет запрос и отдельно данные, в запрос ничего драйвер не запихает

Comments

[v- smerti]

github.com/go-sql-driver/mysql

[Oleg Shevelev]

4gophers.ru/article/go-i-sql-bazy-dannyh в меру полезная статья, однако я хочу обратить ваше внимание на очень занятную ссылку, go-database-sql.org/surprises.html там как раз о подготовленных запросах говорится и причина почему их не стоит использовать без напильника.

Теория же SQL инъекций везде одинаковая, меняется только язык программирования и подход к написанию SQL запросов, а так - всё как везде.

[v- smerti]

Oleg Shevelev: ну я и работаю с пример с первой ссылки так то :)

[Oleg Shevelev]

Владимир Грабко: про подготовленные запросы это было скорее для Кирилл, у вас в коде обычные запросы.

[v- smerti]

Oleg Shevelev: сори

[Кирилл]

Oleg Shevelev: ok, давайте о теории и напильниках. Собственно чтоб разобраться что тут и как нужно понимать "механику" работы между приложением и СУБД. С одной стороны понятно что автор go-database-sql.org всю жизнь писал скрипты на Perl и PHP для облегчения работы DBS, с другой стороны не очень, т.к. во внутренностях тогоже MySql он должен разбираться чуть более чем полностью.

Дак вот: между приложением и СУБД устанавливается соединение, когда мы пишем SELECT * FROM dev_method WHERE name=? мы как бы говорим серверу о своем намерении что-либо сделать, он "проверяет" данный запрос и смотрит что делать дальше; плейсхолдер "?" для MySql говорит о том что для данного запроса будут и данные, поэтому он "выбирает их и вставляет в бд", это может быть 1 набор или n-е количество (prepared), все ок. Иньекция - это изменение того самого нашего "намерения", если данные "вставляются" на стороне нашего ПО, то можно "переписать" запрос на валидный с точки зрения СУБД и дропнуть там все на что прав хватит. Поэтому: данные отдельно/ запрос отдельно - хорошо, вставлять в запрос данные - плохо.

О напильниках:

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

"Просто и на пальцах":

Го пулит соединения с СУЬД, если принудительно соединение не закрывать то оно возвращается в пул.

Сюрпризный момент:

db.Query/Exec etc... выбирают соединение из пула, поэтому:

db.Begin()
db.Exec()
db.Commit()

вполне себе могут быть выполнены в разных соединениях что как бы все поломает, но, как написанно в документации делать так не стоит, а стоит "закрепить" за собой соединение до заврешения обработки пачки бизнес логики

tx:= db.Begin() // открываем транзакцию, объект db в tx закрепляет за собой соединение

tx.Query()/Exec()/etc...

tx.Commit()/Rollback() / закрываем транзакцию и возвращаем соединение в пул

Все просто и логично

[Oleg Shevelev]

Кирилл: только вы при этом назвали разработчика go-sql-driver/mysql (или database/sql всё таки?) школьником который ничего не умеет, при этом у репозитария 25 контрибьютеров со всего мира и код написан вполне хорошо. Я читал код и правил по этому так и говорю. Школьник написать такое за пару дней просто с нуля не сможет.

Суть же моего посыла к сюрпризному материалу в том мало кто о таких вещах задумывается пока им в сотый раз не напомнишь.

По поводу SELECT с вопросиком - сам по себе вопрос в селекте не делает его подготовленым, если не указать его в вызове нужной функции
func (db *DB) Prepare(query string) (*Stmt, error)
Это на тот случай если кто-то прочитает и впадёт в заблуждение на сей счёт.

Вообще, момент с пулом коннектов и подготовленными запросами не освещён в документации должным образом, тот кто пришёл из PHP и некоторых других (включая Си) языков могут предположить что соединение там одно. Раз одно вызывается значит одно и есть и в случае чего даже делать свой пул поверх. Либо предположить (а потом не позаботиться проверить), что все подготовленные запросы устанавливаются автоматически на все соединения и движок сам за этим следит (это был бы хороший вариант, но опять таки не очевидный).

Вы-то какими пользуетесь?

[Кирилл]

Oleg Shevelev: я об авторе go-database-sql.org, он собственно и не школьник, Baron Schwartz должен знать "всю кухню", поэтому удивительны эти "surprises"

SELECT с вопросиком "по механике" тотже Prepare (пруф https://github.com/go-sql-driver/mysql/blob/master..., т.е. он отсылает на сервер запрос и отдельно данные - это нормальный режим работы с СУБД который легко посмотреть tcpdump'ом например ;) Prepare отличается от него только тем что сервер СУБД будет ожидать поступление n-го количества запросов с данными

У нас https://github.com/lib/pq + https://github.com/jmoiron/sqlx

Пул не освещен в документации Go т.к. его работа это и работа sql-драйвера стороннего вендора, поэтому они о нем ничего написать и не могут, это забота автора драйвера, Go только предлагают использовать общий api database/sql