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

[Alergy]

Не понимаю зачем вообще логировать чат в таблице.
Как показывает практика, модератор может следить за чатом но смотреть логи до этого дело не доходило.

а вообще можно шерстить строку на вхождение основных операторов мускула например .

[Toshik]

Не понимаю зачем вообще логировать чат в таблице.

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

[Valter]

Ответ прост защита от SQL инъекций - регулярные выражения. Если использовать php они там уже встроены, ничего придумывать не надо. Если Вы используете к примеру c++ для своего сервера. Там это дело не встроено придётся писать самому. Обработкой таких последовательностей (как вариант) занимаются конечные автоматы, есть ещё другие способы, но конечные автоматы вроде самые легкие. Советую почитать про них, если разберётесь, то спокойно будете обрабатывать любую последовательность символов на те или иные признаки.

Хотя я где-то читал, что написать свой конечный автомат сможет программист любой квалификации. На тот момент я осознал, что я совсем не программист и что мне учиться и учиться . Так что дерзайте.

[Woolf]

А сервер на чём, извините? Для java - решение простейшее - не использовать запросы в стиле "insert into users (name) values ("+username+")" а использовать

Код: Выделить всё

         qry = "INSERT INTO users (name) VALUES(?)";

         PreparedStatement pstmt = db.getConnect().prepareStatement(qry);

         pstmt.setString(1, username);
                        pstmt.executeUpdate();


И все инъекции курят в сторонке )

[Guyver]

мужики, переливаете из пустого в порожнее не читая предидущих постов ...
какие регэкспы ... причём тут конечные автоматы? ...

А сервер на чём, извините? Для java - решение простейшее - не использовать запросы в стиле "insert into users (name) values ("+username+")" а использовать
.....
.....
И все инъекции курят в сторонке )

это и есть параметризация запросов (то на чём порешили на 1й странице в 1х постах) ... какбэ .... браво

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

[Neodrop]

Можно хранить тексты в бинарном контейнере и чихать на то, что в них наваял злоумышленник. Нэ ?

[sp00n]

Можно хранить тексты в бинарном контейнере и чихать на то, что в них наваял злоумышленник. Нэ ?

Можно и в тексте хранить, но оригинальный тескт кодировать/шифровать. Единственный минус в обоих случаях - это просмотр человеком данных таблицы без конвертера обратно в читаемый текст

[Neodrop]

Шифровать особо не нужно. Достаточно заменить все "e" на что-нить типа Ъ

[sp00n]

Действительно. Или на русские "е", "о" и пр. Спасиб

[gnoblin]

такс, не понял про Ъ...

[Neodrop]

Подумай есчо.

[Guyver]

если это будет именно иньекция ... в синтаксисе SQL ... то получится подстановка битого (не валидного) запроса ... (при замене части символов)

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

или менять все управляющие символы тогда уж .. в синтаксисе SQL ... такие как ", ', ;.
таким образом мы обломаем начало самой иньекции.

либо шифровать так, чтобы мать родная не узнала .. и то рискуем нарваться на управляющие символы после шифрования.
опять же нужно строку передавать как параметр в запросе а не как кусок текста.

[Neodrop]

Беседа смахивает на "Как защитить хреново спроектированный код от злоумышленника".
Я вообще не понимаю сути проблемы. Есть десяток путей для того, чтобы никогда не столкнуться с этой проблемой.