SQL-инъекция в штрих-коде?

На одном фотосайте как-то нашёл забавную уязвимость, можно было вставлять html код в EXIF информацию снимка.

Да нет, сканер ведь не напрямую к компу подсоединен, в нем есть база данных по товарам, которую он в своих мозгах инкрементирует, а на этот код он просто ругнется что такого товара нет в базе и все. Да и слишком уж он длинный для сканера, не влезет. А вот на кассе этот код пикнуть — может что и выйдет

да, база данных там внутри далеко не sql, что-то совсем плюшевое

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

в обмен между терминалом и основной БД инъекция точно не попадёт — там синхронизация по внутренним артикулам товаров, а не по штрихкоду.

Работать не будет, по ряду причин, некоторые из которых назвали выше:
1. Сканер не работает с базой напрямую. ТСД например имеет свою базу, и только потом обмен с базой сервера. При WiFi режиме — обмен идет через процедуры, которые вряд ли пропустят. Да и обмен идет не по штрихкодам, а артикулу или ID товара в базе.
2. Сканер читает штриховой код EAN-13, редко другие, очень редко Code 128, как здесь. Маловероятно что сканер поймет этот код. В магазинах обычно дико экономят на оборудовании и вряд ли купят сканер или ТСД читающий все кода.
3. Есть административное и четкое указание какой код читать, ну по крайней мере в тех организаций, с которыми я сталкивался. Читается всегда код с товара, а не с ценника. Во первых не ценник несут на кассу, а товар, во вторых — ценника может и не быть.
4. Видно что код не тот. На кодах магазина внизу пишут артикул, как правило, тут его нет.

На кассе тоже маловероятно….

а я печатал идентичные ценники с заниженной ценой на весовой товар :)

Я можеть отстал от реальности, но ранше эти сканера подклучались к порту клавиатури и все что он считивает идеть как ввод с клавиатури. а уж куда вод перенаправляится это уже от програми зависит и невижу почему этот сценарий неможеть быть реальный. Незнаю как в Росси, но на западе даже очень крупние сети стараится использовать решение по дешевле…

http://www.irongeek.com/xss-sql-injection- … e%2BReader

http://www.irongeek.com/i.php?page=securit … e%2BReader

Через клаву, поле для ввода больше 13 цифр не пропускает.

Через клаву, поле для ввода больше 13 цифр не пропускает.

Комментарий для oldTV:

Давайте подробнее

Я вообще-то работаю в области автоматизации розничной торговли… не могу себе представить, чтобы текст, прочитанный сканером штрихкода хоть где-нибудь воспринимался как sql-предложение. Это может быть код ean или количество. Ну, может быть, вес товара, хотя обычно вес интегрируется по определённым правилам в состав ean-13. Но чтобы таким образом вводились sql-предложения? Да ещё с ценников или этикеток? Это просто невероятно. Кстати, с той базой, с которой я работаю, шутка «drop table products» не пройдёт. Соответствующая таблица называется goods. Ещё в одной известной мне системе таблица называется не products, а product. Хотя конечно сама идея выглядит смешно, для Первого апреля покатит :)

блин, придётся напечатать десяток-другой вариантов и пойти тестировать в боевых условиях.
Настенные терминалы, которые говорят тебе цену по штрихкоду — прекрасная цель (-:

Либо автор считает всех разработчиков идиотами либо он сам не осведомлен что стандартной практикой является не составление строки с параметрами в запросе а пользование плэйсхолдерами
insert into a (col_a, col_b) values (?, ?)
select * from products where prod_id = ?
Все параметры передаются отдельно и корректно обрабатываются.
По другому пишет только школьники.

Работал в рознице. Идея не реальная. Сканер считывает лишь идентификатор (артикул, инв. номер, количество) вся остальная информация — в базах. Ввести SQL со штрих-кода это забавная (и красивая) шутка не более :)

В нормальных БД, в отличие от MySQL, есть динамические параметры, через которые сделать SQL-инъекцию невозможно. Непонятно, что мешает разработчикам MySQL сделать то же самое вместо извращений с кавычками.

А еще в нормальных БД есть внешние ключи, которые на дадут удалить все из справочника при условии, что хотя бы один товар где-либо используется.

Комментарий для Евгения Степанищева:

procedure TForm1.CoolProc (s: string; id: integer);
begin
pFIBQuery1.SQL.Text := 'update GOODS set name=:name where id=:id';
pFIBQuery1.ParamByName ('name').Value := s;
pFIBQuery1.ParamByName ('id').Value := id;
pFIBQuery1.ExecQuery;
end;

Комментарий для Евгения Степанищева:

То есть от СУБД это не зависит

Зависит. В данном случае это обертка вызовов API клиентской библиотеки СУБД.

Если в MySQL есть динамические параметры, почему их не используют, а формируют текст запросов вручную и постоянно нарываются на sql-инъекции?

Комментарий для Евгения Степанищева:

Что такое этот загадочный биндинг? И как в PHP использовать эти динамические параметры?

Комментарий для Евгения Степанищева:

Не помню, где я в первый раз услышал «динамические параметры». Общеупотребительный термин. А я про биндинг впервые слышу. Видимо, программирование приложений БД и программирование в интернете разные миры.