Как защититься от sql иньекции?

Question

[Дмитрий Кузьменко]

С сегодняшнего дня обнаружел а базе вот такое.
Собственно вопрос, это атака на базу? Как от нее защититься?
Сайт написан на чистом php все запросы к базе руками прописаны, без фреймворков и прочего.

Comments

[cha-cha]

Вы что, пароли в отктытом виде храните?

[Дмитрий Кузьменко]

Да сайт жутко косяченый, дыр масса

[Роман Дубинин]

cha-cha, где вы увидели пароли в открытом виде?

[Дмитрий Кузьменко]

Роман Дубинин, Верно он написал, там сам пароль в md5, но есть столбец который пишет пароль в открытую, вроде как для восстановления забытого пароля

[ThunderCat]

Дмитрий Кузьменко,

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

ШИКАРНО... ладно, будем считать это легаси и ошибками молодости.

По теме: переход на пдо и препаред стэйтмент. Да, долго и геморойно, но надо.

[Дмитрий Кузьменко]

ThunderCat, А может проще переписать например на Laravel или Yii2. Там функционала не так уж и много.

[ThunderCat]

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

[Роман Дубинин]

Дмитрий Кузьменко, на вопрос "Где?" можно было бы и пальцем ткнуть)) Я решительно не понимаю, в каком столбце там пароли. Только если в первом, но там всего две ячейки видно без инъекций и вот вообще непонятно, как cha-cha по нима догадался, что это пароли...

[Дмитрий Кузьменко]

Роман Дубинин, На скрине последний столбец)) Там как раз в открытом виде они лежат, я уже этот столбец искоренил))

Answer 1

[Станислав Шендаков]

Использовать PDO

Answer 2

[Вадим]

Учитывая, что оно у вас сохранилось в базу, а не выполнилось - там уже какая то защита есть.
А если по делу, то используйте prepared statements и PDO.

Comments

[Дмитрий Кузьменко]

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

[Вадим]

Что бы что то сказать надо видеть код. Где данные этого поля в запрос добавляются.
Но в общем случае, используйте prepared statements, они же подготовленные выражения и инъекции не пройдут.

[Роман Дубинин]

Вадим, точнее вот также как на скрине запишутся в базу)

[Вадим]

Роман Дубинин, ну я про это и написал в ответе.

Answer 3

[Stimulate]

Экранировать входящие данные.

Answer 4

[Uno]

Будь я доктором технических наук, рекомендовал бы Вам перманентный бессрочный бан по ip данным скрипт-кидям, от нервов, так сказать =)
Олавливать их по словам SELECT, UPDATE или INSERT во входящих данных не сложно.

Comments

[Radjah]

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

[Uno]

Павел, так защита то работает. Пэйлоад прошёл как экранированная строка. Что тут ещё лечить?

[Xadok]

Noizefan zzz, update и insert не имеет сильно смысла от скрипт кидди. Select довольно часто является флагов для инъекции и посмотрите сколько способов обхода файрволла, где идёт отлов по словам. Спойлер он не работает на 99%.

Answer 5

[oldpyron]

Я вот согласен с предыдущими ребятами - если коннектор самописный, то надо экранировать входящие в запрос данные. Но, ИМХО, экранировать не слова, а служебные для sql знаки: точка с запятой, одинарные и двойные кавычки и что-то там еще - ибо давно это у меня было, да и гуглится легко.