Проясните пожалуйста вопрос. Правильно-ли я понимаю ? Вопрос безопасности данных получаемых скриптом из вне, встаёт только в связи с наличием кавычек или двойных кавычек - символов способных создать разрыв кода при подстановке переменных ? Сюда-же можно отнести ещё несколько потенциально опасных символов..... Если их просто вырезать из строки - то проблема отпадает сама собой ? Верно-ли я понимаю ?
я их не вырезаю, использую https://github.com/plohoyav/php_mysql_upros чтобы все данные экранировались при занесении в базу
@Karabas_il, неправильно понимаешь. Для переменных php нет никаких опасных символов. Память никакой код не выполняет. Опасность представляет выполнение с данными, записанными в памяти. Если ты пишешь строковое значение прямо в коде, то да, нужно экранировать апострофы в коде. Если ты получаешь из вне, то в память оно и так нормально запишется. А уже дальше, если ты эти переменные подставляешь в запросы, то тут возникает опасность, что запрос испортится из-за данных. Пример: Код (PHP): mysqli_query($link, "insert into `users` set `name`='$_POST[name]'"); Если тебе передадут имя Вася, то запрос будет выглядеть перед передачей на исполнение в базу данных Код (Text): insert into `users` set `name`='Вася' Это корректный запрос, он выполнится. А вот если передадут имя Жанна д'Арк, то уже получится запрос Код (Text): insert into `users` set `name`='Жанна д'Арк' В ответ на этот запрос база данных пошлёт тебя не совсем цензурно Вот чтоб этого избежать, используют экранирование апострофов и других потенциальных спец. символов в строке с помощью функций или используют подготовленные запросы. Это применяется только при подстановку значений в sql-запросы, поскольку в переменной. повторюсь, может висеть совершенно любое значение, пока оно там висит, оно безобидно. Вот как только ты его куда-то на выполнение передаёшь (будь то SQL-сервер, или, к примеру, функция eval (которую применять крайне не рекомендуется), то здесь могут возникнуть проблемы, и есть способы их решения. --- Добавлено --- P.S. Как дополнительный плюс, экранируя специальными функциями передаваемые в базу значения переменных, мы получаем защиту от SQL-инъекций
@mkramer Спасибо за столь развёрнутый ответ. Я это всё понимаю, просто видимо не корректно выразился. Имелось ввиду, что банальное удаление(вырезание опасных символов(в данном случае пусть будет вариант с SQL и одинарными кавычками) полностью решает проблему ? Конечно, если всё-ж писать кавычки в БД то их надо экранировать или применять другие способы.... Я спрашивал именно про тупое удаление неугодных символов, как то : ' , " , ` , x22, x27, x60 . Если я их вырезаю - это решает вопрос безопасности или есть варианты обхода такого метода ?
Если ты вырезаешь кавычки, ты портишь данные. Не надо вырезать, надо правильно вставлять в бд. Код (Text): "Та осень была загадочна," - вспоминал Размановский В таких данных нет попытки тебя атаковать, а если ты сделаешь своё обрезание, ты испортишь пунктуацию текста. --- Добавлено --- Не надо портить данные, надо правильно с ними работать
Это всё философия не относящаяся к теме. Есть достаточно много данных не подразумевающих пунктуационных художеств. Скажем логин и пароль стоящие на входе в систему ИМХО должны чётко и жёстко ограничивать наборы используемых символов, а не зависить от того как и что отфильтрует та или иная функция.
@Karabas_il, опасных для чего? Непосредственно для корректности запроса? Обратные апострофы в строковых значениях экранировать не нужно. Они могут быть опасны только в именах или в произвольных вставках. Из обычного апострофа и кавычки можно экранировать только что-то одно, если значения гарантированно обрамляются чем-то другим. Что касается др. символов, посмотрите на состав экранируемых в real_escape_string символов. --- Добавлено --- Это вы тут философствуете. А вам дело говорят. --- Добавлено --- Это понятно. Но если у вас нет четкого понимания, что «опасные» символы вы в дальнейшем ни при каких условиях не будете разрешать в логинах и т.п., то экранирование данных под запросы лишним не будет.
Уж тогда mysqli_real_escape_string..... Но : Код (Text): Lets take another canonical example, $id = "1; DROP TABLE users;" $id = mysqli_real_escape_string($link, $id); $query = "SELECT * FROM users where id = $id"; with no less harmful result: SELECT * FROM users WHERE id =1;DROP TABLE users; -- ' https://phpdelusions.net/sql_injection#whatis По этому в набор символов нужно добавить ещё точку с запятой ; x3B
А я что написал? Походу вы совсем не догоняете. Если не сделаете ="$id", много чего добавлять придется --- Добавлено --- Форма =$id допустима только для числовых проверенных по всем признакам значений.
Резюмирую: 1. валидация и подготовленные запросы на входе, правильное выставление кодировок etc., экранирование на выходе. Всего и всегда. Пусть что хотят то и шлют, жизнь удалась. 2. Порезать данные костылем, защитившись от одного вектора атаки и получив ложную уверенность в том что на этом всё, целую страницу гадать что с этим не так. Я даже хз что выбрать, вот прям не знаю...
Зачем? Особенно пароль, который никогда не должен писаться в базу в неизменном виде, только в виде хеша.
@mkramer ты заработал тысячу лайков. грац! --- Добавлено --- @Karabas_il Ты имеешь право не слушать никого, только себя. Ты сам в ответе за свою попаболь.
Это не философия, это совет от опытного человека. Вандалить данные нельзя. Это закон. Кто его нарушает - безрукий павиан, которому самое место в подмастерьях у джуна, не более, и которому надлежит сидеть на попе смирно и внимательно слушать. Зачем? Это мой любимый вопрос, когда кто-то говорит об ограничении набора символов для логина и, особенно, пароля. Зачем? Я теперь не слезу с тебя, пока не ответишь аргументированно и без воды. Уважаемый товарищ теоретик, как давно вы последний раз работали с БД в php, если не знаете, что в mysqli выполнение мультизапросов отключено по умолчанию и вообще вынесено в отдельную функцию на всякий случай? --- Добавлено --- Может я не прав, конечно, но когда в коде английский язык перемешан с русским, это уже звоночек, что в продакшене такой код использовать крайне нельзя, потому как уровень программиста ну...невысок. Если, конечно, это не твой репозиторий и тогда ты сам на себя берешь ответственность, покуда сам себе доверяешь. А где работа с транзакциями? Обработка ошибок? Обслуживание подключения? ( Маловатобудет. Транзакции так вообще мастхев. Должен быть выбор, использовать их или нет для запроса.
Защиту от не верных данных нельзя так называть. Если тебе вместо цифры 5 приходит строка "5 рублей", то только идиот её отбросит полностью, а не вырежет из неё нужную цифру.
Не надо путать тему этого топика с валидацией. Как по вашему бы работал этот форум, если бы у него удалялись "опасные" символы?
@Karabas_il, безопасность и валидация данных под задачу - разная тема. Для защиты от SQL-инъекций и XSS-атак, надо экранировать/использовать плейсхолдеры при работе с запросами, пропускать через htmlentities при выводе. Это всё. Другой разговор, что задача может подразумевать проверку вводимых данных на корректность (к примеру, чтобы в поле цена пользователь не писал "хрень какая-то"). Это не безопасность, эта проверка вводимых данных на соответствие условию задачи. Если бы форум вырезал кавычки, мы бы не могли здесь публиковать код
да обыкновенно. Вот тебе пример: я пишу ;delete * from users; и почему-то на форуме таблица и не удаляется, и мой текст остаётся таким же, как я написал и я может быть хочу себе ник сделать ";delete * from users;" ну вот нравится мне такой. Почему это ты его обрезать должен? Я хочу такой ник и никакой другой.
Администрация форума разрешила публикацию кода и т.п. А могла не разрешать. Если-б к примеру форум был иной тематики - форум поэтов, к примеру. ))) --- Добавлено --- К сожалению, на поставленый вопрос ни кто не захотел отвечать....
1) Да, если вы укажете все специальные символы, которые могут заруинить запрос и привести к sql injection. 2) Да. По большему счету, если человеку отрубить руки, ноги и закрыть кляпом рот, то зла он никому не причинит. Кстати, предлагаю Вам отсеивать буквы "а" и "е", они недостаточно округлые и потенциально приводят состояние данных в бд в неподобающий вид. Ведь зачем они нужны, в целом. Смлю прдположить, что вы можт прочитть этот ткст и бз этих букв.
@Karabas_il, твой вопрос мне напоминает одну бредовую книжку, "PHP глазами хакера". Там, чтобы защититься от SQL-инъекций, предлагается из данных вырезать слова select, delete, insert, union и далее по списку