а как вы защищаете игровой сервер от SQL injection? [РЕШЕНО]

[Guyver]

у меня самописный сервер.

есть у меня такая паранойя, называется SQL иньекции.

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

но вдруг есть общепринятые правила по этому поводу .. необходимо и достаточно как говорится.

[Lman]

Насколько я знаю, если твоя игрушка соединяеться напрямую к SQL серверу, то никакие проверки в игре не спасут.
Какой нибудь хакер просто проанализирует трафик, который будет содержать реквизиты доступа и текст самих запросов, после будет подключаться и отправлять любые запросы из своей собственной проги даже не запуская саму игру.

Поэтому между игровым клиентом и БД обязательно нужна прослойка на сервере, например PHP скрипт, с которым будет соединяться клиент и в котором будут проверяться все данные.

[Guyver]

вы видимо слабо понимаете что такое SQL иньекция ... и как она делается ..

где вы видите хоть строчку о том что клиент цепляется напрямую? (сервер на ПХП это круто да ... 5/5 и протокол http да ? =) )

так и быть раскрою тему немного.

допустим у нас есть чат .. допустим чат сервером пишется/логируется в базу ...

я злоумышленник. я начинаю исследовать ваш сервер на вшивость и в чате начинаю писать всякие клёвые штуки .. предпологая что у вас записи валятся каким нибудь insert into ..

пример иньекции

hello'; update users set password='12345' where id=100500

это пример из пальца и наскоком .. но надеюсь теперь ясно что такое иньекция?

[gnoblin]

По-моему решение простое - использовать параметризированные запросы, я их использовал в mysql-коннекторе.
Я могу быть и не прав!

[sp00n]

Можно попробовать все символы ' заменить на свой управляющий символ:) типа в базу будет заноситься
hello(kavichka); UPDATE ...
ну а дальше уже при чтении истории чата менять наоборот
или ; - она то по люому в инъекции будет для окончания предыдущей команды

[Guyver]

gnoblin
да, разумеется, у меня параметризованные команды .. но боязно чёто (чёрный ящик ... что там творится в этих параметрах - хз) )) .. хотя может это из разряда паранойи

п.с. я тебе писал в личку как запустить мою поделку, чтобы заценить ГУИ .. тыж хотел.


sp00n
да я вот в начале предположил что закрывать управляющие символы .. ' и " (у разных провайдеров разное встречается .. и кстати именно поэтому юзаю параметризованные команды) ... ; не катит .. во первых у MySQL другой синтаксис ... во вторых если даже закроем ; а всё ост. будет оке, то при запросе будет краш .. да мы выкрутимся трай кетчем, но не по людски это =)


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

[gnoblin]

гуи я вроде смотрел (спс!) - если честно меня тогда больше интересовал код

я думаю что не стоит верить мифам и легендам,
а просто взять и проверить - достаточно ли использовать ТОЛЬКО параметризированные запросы (и зря не говородить вставку доп символов если параметризированные запросы и так защищают от проблемы инжекта).

[sp00n]

У себя я решил просто, потому как архитектура проекта не предусматривает хранения иной строковой информации полученной от пользователя, кроме логина. А в правилах создания имени логина просто указал на недопустимость пробелов и спец символов (кавычки, точки с запятой, слэши). Но вот насчет чата, Вы заставили меня задуматься - пока что чат храню в логе, а не в БД, но кто его знает, что там дальше будет
И да, как писал gnoblin - быстрее просто взять и проверить

[eric]

1) Хранимые процедуры
2) Подготовленные выражения (gnoblin+1)
3) Распределение уровня доступа на уровне БД (рут - отдельно, для игроков - отдельно, выставить доступ на уровне таблиц по необходимости операций, рут не использовать)
4) Избегать динамически формируемых запросов в процедурах или жестко проверять/приводить к типу.

Желательно применять все 3 первых пункта.

[Guyver]

1) Хранимые процедуры
2) Подготовленные выражения (gnoblin+1)
3) Распределение уровня доступа на уровне БД (рут - отдельно, для игроков - отдельно, выставить доступ на уровне таблиц по необходимости операций, рут не использовать)
4) Избегать динамически формируемых запросов в процедурах или жестко проверять/приводить к типу.

Желательно применять все 3 первых пункта.

1 - а чем они тут помогут ? =) ... в любом случае даже если инсерт в процедуре, ей на вход мы подаём юзер строку .. а там можно чёрта лысого ... (или давайте пример где она спасёт)
2 - не подготовленные а параметризованные .. тут я уже согласился и благо юзаю это не задумываясь уже давно
3 - простите .. что ? ... у нас есть игровой сервер ... он под рутом как ни крути сидит на базе. пакеты прилетают в игровой сервер, он выполняет действия... на кой чёрт юзера ваапще пускать в базу? этож муветон.. тут как раз сервер-рут и больше никого в SQL сервер не пускать. я даже SQL внешние конекты запретил как таковые. только локал хост.
4 - отлично .. тип - строка от юзера ... и что ?! ) (неясно к чему речь о приведении типов)

тут шла речь об иньекции. это когда юзер подсовывает адекватный SQL код в поле ввода в клиенте.. а сервер его нечаянно исполняет.

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

[gnoblin]

Про ограничение прав доступа, кстати, грамотное замечание - чтобы после инжекта злоумышленник не смог дропнуть вам какую-нить важную таблицу (т.е. это "последняя линия обороны" типа).

[Guyver]

ну не дать игровому серверу права на дроп таблиц и создание/удаление/изменение учёток в сиквеле это единственно что можно сделать. создание записей, удаление, апдейты ... всё это нужно уметь.

[eric]

Я дал рекомендации, а уже ваше дело как вам к ним относиться и как что называть.

[DbIMok]

на хабре обзорная статья

[Toshik]

3 - простите .. что ? ... у нас есть игровой сервер ... он под рутом как ни крути сидит на базе. пакеты прилетают в игровой сервер, он выполняет действия... на кой чёрт юзера ваапще пускать в базу? этож муветон.. тут как раз сервер-рут и больше никого в SQL сервер не пускать. я даже SQL внешние конекты запретил как таковые. только локал хост.

Навскидку:
1-й коннект под рутом - типа управляющий, чары, статы, мир и т.п.
2-й коннект под ограниченным доступом - логирующий (чаты, действия и.т.п)