SeVlad: Вот это номер.. Понятия "XSS", "SQL-инекции" и тд ничего не говорят?
А вам?
Какое отношение имеет XSS к записи в базу, о которой мы говорим? Защита от SQL-инъекции имеют отношение к pdo-функциям или к более древнему подходу в виде mysqli_real_escape_string(). Но никак не к strip_tags.
Всё остальное - это магические пасы.
Sitealert: В базе может сохраняться результат вложенного запроса SELECT. Который можно будет прочитать в том месте, где этот текст выводится.
Здесь речь о вводе данных в базу. Очистка вывода или экранирование - это отдельная тема.
Но если честно я не совсем понял от относительно "результат вложенного запроса SELECT" - можете пример привести.
_SP_: И ээ... вы предлагаете пихать в него непонятно откуда пришедший json ?
Теоретически Mysql поддерживает работу c json. Если говорить о других базах, то Mongodb через json и работает, там все запросы на основе массивов идут.
DiKiJ: У меня все базы - текстовые. Одна строка - одна запись. Я еще вырезаю двойные пробелы и переносы строк. )) Привычка максимально все контролировать.
Я тут добавлю, что у каждой базы свои моменты по экранированию, у той же монги аналогом SQL-инъекций является передача массивов вместо целых и строк. Но это вопросы, которые решаются на этапе отправке через соответствующие иснтрументы. strip_tags и htmlspecialchars в рамках задачи ТС не имеют смысла, так как база не выполняет код.
При выводе в браузер - да, тут нужно переводить в html-сущности.
> Я еще вырезаю двойные пробелы и переносы строк
По идее, здесь важен вопрос именно экранирования. То есть, \n должно быть заменено на \\n и тогда длинные тексты будут иметь практически первоначальный вид после получения из базы. Но этот момент нужно протестировать.
---------- Добавлено 10.12.2019 в 14:26 ----------
SeVlad: Речь не о возможности что-то сделать подключившись, а о получении доступа с пом таких грязных запросов и хранением их в базе.
Опишите, пожалуйста, способ каким образом можно получить доступ к помощью пхп- или хтмл-тегов, которые будут в тексте, сохраняемом в базе?
DiKiJ: Сейчас смотрю, используют mysql_real_escape_string() от sql инъекций.
Это не сейчас, использование этой функции устарело очень давно. Более того, начиная с php 7.0.0, который уже немного устарел, эта функция вообще удалена и её вызов будет вызывать ошибку.
---------- Добавлено 10.12.2019 в 10:57 ----------
Сейчас вместо этой функии mysqli_real_escape_string(), но лучше использовать семейство pdo.
SeVlad, как раз ваш вариант очень редкий и может быть использован с сильными оговорками. Мы не знаем как нам в дальнейшем придётся обрабатывать данные.
В случае какого-то простенького хоумпейджа - это не важно, но для какого-то более-менее сложного проекта этот подход не годится.
И здесь не вопрос именно валидации данных в форме, тут могут свои проверки, а в дополнительной обработке уже полученных данных перед сохранением в базу (кроме средств по типу pdo_). Данные могут хранится одновременно в нескольких базах и мигрировать между ними по ряду условий.
SeVlad, объясните.
Вот это номер.. Понятия "XSS", "SQL-инекции" и тд ничего не говорят?
А вам?
Какое отношение имеет XSS к записи в базу, о которой мы говорим? Защита от SQL-инъекции имеют отношение к pdo-функциям или к более древнему подходу в виде mysqli_real_escape_string(). Но никак не к strip_tags.
Всё остальное - это магические пасы.
В базе может сохраняться результат вложенного запроса SELECT. Который можно будет прочитать в том месте, где этот текст выводится.
Здесь речь о вводе данных в базу. Очистка вывода или экранирование - это отдельная тема.
Но если честно я не совсем понял от относительно "результат вложенного запроса SELECT" - можете пример привести.
И ээ... вы предлагаете пихать в него непонятно откуда пришедший json ?
Нет, конечно. Я ж о теоретизировании :)
Не разбирая на поля ? Смысла в этом ноль.
Теоретически Mysql поддерживает работу c json. Если говорить о других базах, то Mongodb через json и работает, там все запросы на основе массивов идут.
Но это теоретизирование :)
У меня все базы - текстовые. Одна строка - одна запись. Я еще вырезаю двойные пробелы и переносы строк. )) Привычка максимально все контролировать.
Я тут добавлю, что у каждой базы свои моменты по экранированию, у той же монги аналогом SQL-инъекций является передача массивов вместо целых и строк. Но это вопросы, которые решаются на этапе отправке через соответствующие иснтрументы. strip_tags и htmlspecialchars в рамках задачи ТС не имеют смысла, так как база не выполняет код.
При выводе в браузер - да, тут нужно переводить в html-сущности.
> Я еще вырезаю двойные пробелы и переносы строк
По идее, здесь важен вопрос именно экранирования. То есть, \n должно быть заменено на \\n и тогда длинные тексты будут иметь практически первоначальный вид после получения из базы. Но этот момент нужно протестировать.
---------- Добавлено 10.12.2019 в 14:26 ----------
Речь не о возможности что-то сделать подключившись, а о получении доступа с пом таких грязных запросов и хранением их в базе.
Опишите, пожалуйста, способ каким образом можно получить доступ к помощью пхп- или хтмл-тегов, которые будут в тексте, сохраняемом в базе?
Я подозреваю, что и на большинстве шаредах можно подключиться к "соседнему акку" зная данные коннекта.
Если кто-то подключится к вашей базе, то он и так туда запишет, что захочет.
Сейчас смотрю, используют mysql_real_escape_string() от sql инъекций.
Это не сейчас, использование этой функции устарело очень давно. Более того, начиная с php 7.0.0, который уже немного устарел, эта функция вообще удалена и её вызов будет вызывать ошибку.
---------- Добавлено 10.12.2019 в 10:57 ----------
Сейчас вместо этой функии mysqli_real_escape_string(), но лучше использовать семейство pdo.
С остальным справится strip_tags и htmlspecialchars
Зачем перед добавлением в базу делать strip_tags и htmlspecialchars?
Мне интересно какая база рендерит html? Хотя допускаю, что возможно такая есть, но это не MySQL :)
SeVlad, как раз ваш вариант очень редкий и может быть использован с сильными оговорками. Мы не знаем как нам в дальнейшем придётся обрабатывать данные.
В случае какого-то простенького хоумпейджа - это не важно, но для какого-то более-менее сложного проекта этот подход не годится.
И здесь не вопрос именно валидации данных в форме, тут могут свои проверки, а в дополнительной обработке уже полученных данных перед сохранением в базу (кроме средств по типу pdo_). Данные могут хранится одновременно в нескольких базах и мигрировать между ними по ряду условий.
Как результат, трафик снизился с 10 000 до 8 000.
С какого именно поисковика?
1. Указание в Тайтле названия сайта никаких бонусов не приносит, только размывает BM25 заголовка страницы.
Все свои утверждения проверяю через Page Audit
<title>Page Audit – поисковое продвижение сайтов, SEO продвижение для сайта в 2020</title>
А зачем название сайта добавлено в тайтл вашего сайта?