Форум PHP

Здравствуйте,
не первый день разбираюсь вопросом, как обезопасить данные вводимые пользователем в форме, но как грамотно это сделать не знаю. Моих мозгов хватает только чтобы сделать что-то типо этого:

$name = (isset($_POST['name'])) ? addslashes(strip_tags(trim(mysql_real_escape_string($_POST['name'])))) : '';

Далее $name добавляется в базу. Слышал многие профи уже имеют готовые функции для очистки данных полученных от пользователя. Может кто-то поделится, кому не жалко, или внесет свои поправки, так как у меня много форм как цифровых так и строковых.
Заранее благодарен!

<? echo addslashes(mysql_real_escape_string('st"ring'));

Ошибку:

Warning: mysql_real_escape_string(): No such file or directory in - on line 3 Warning: mysql_real_escape_string(): A link to the server could not be established in - on line 3

вижу(. Как быть?

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

На счет каши, понял, виноват. Можно посмотреть, как вы проверяете данные форм от пользователя?

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

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

Я это понял, спасибо. Можно увидеть ваш сценарий для обработки данных уже для помещения в базу?

Да какой сценарий, помнить пока надо о такой пакости как магические кавычки, и лучше отключать их. Зная тип данных, поступайте соответствующее, числовые приводить к intereg, строковые экранировать. Удалять слеши, а вот теги, так нужно знать, что функция может возвратить некорректный результат.

простите,а зачем addslashes

mysql_real_escape_string() вызывает библиотечную функцмю MySQL mysql_real_escape_string, которая добавляет обратную косую черту к следующим символам: \x00, \n, \r, \, ', " и \x1a.

Читать умеете? Что дальше написано?

а дальше это где именно?

Вам что еще и ссылку дать, или может все таки потрудитесь сами прочесть и вникнуть?

ерунду вы какую-то слышали. всё зависит от того, какого рода данные заносятся в базу данных. если например это целое число, то имеет смысл делать приведение к целому числу с помощью (int) или intval, если это строка, то имеет смысл обрезать пробелы по краям и т.д. но есть одно правило для всех заносимых данных в базу - их нужно экранировать. делается это с помощью встроенных в php функций. все, что начинается с mysql_, использовать не желательно. лучше разберитесь с PDO или на худой конец c mysqli
addslashes и mysql_real_escape_string это вообще адская бессмысленная смесь.

а скажите, разве в большинстве случаев для строки, не достаточно использовать
htmlspecialchars с ENT_QUOTES


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

htmlspecialchars с ENT_QUOTES помещая в базу?

htmlspecialchars используется ТОЛЬКО для вывода пользовательских данных, которые могут представлять опасность и больше ни для чего. никогда не ассоциируйте эту функцию с базой данных

подскажите
а чем плохо поместить в БД " вместо " ?

при условии что в тексте нет и ненужно служебных символов типа ссылок и изображений

А если потребуется разбор текста?
Если вы считаете, что htmlspecialchras именно для этих целей самая удобная, то что мелочится тогда, пропускайте через htmlentities, чтобы всем страшно было.

да нет, просто у меня целевые поля
для небольших блоков где не предполагалось ничего кроме букв и цифр там одно - html chars
а для содержания самой страницы там - real string

спасибо за ответ.

Это значит, что вы не совсем понимаете смысла этой функции, и поступая таким образом просто сознательно вносите в базу мусор, а требуется экранирование.

возможно,
и книги были не те в которых это писали
а вообще меня тупо харило потом убирать слеши + сивол &
но мусора нет, не думаю что из возможных записей типа - 1комнатная квартира/Дом
каким то чудом туда полезут кавычки.
и

вот читаю инет нигде непишут использование addslahes с real_escape_string
одновременно.
real_escape_string экранизирует на utf-8 всегда

Экранирование, это один лишний байт, а ваше никчемное htmlspecialchars, это несколько байт, вот и мусорите не понятно для чего. К тому же это может сказаться на неудобства при определенных операциях (сами подумайте каких). Вирус, если его не запустить, может так и "прожить вечно в инкубационном периоде". И база может безболезненно хранить "страшные вещи", надо только понимать это, и не чертыхаться от боязни. А экранирование служит не для того, что превратить один байт в длинную козявку для хранения, а для иных целей.

>вот читаю инет нигде непишут использование addslahes с real_escape_string

А где вы тут увидели, что ему кто-то советует применять такое?

да я понял понял 1 байт 5 байт
это ясно.
а так же очевидно что не все парятся над этим. это проблема каждого в отдельности

меня больше напрягает когда пользователь используя ckeditor и не понимая ничего соотвесвенно
пихает в БД просто тонну пустых ненужных тегов

для: volodumir (15.03.2014 в 18:19)


<?
echo addslashes(mysql_real_escape_string('st"ring'));

ваш короткий пост ввиде ответа

вот этого я не понял

А чего непонятно?
Я ему дал строку кода. Что она выведет на экран?
Можно ли будет по этому выводу понять, что он пишет полнейшую чушь?

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

PS. Визуальные редакторы необходимы когда это нужно, и не противопоказано в базе хранить html-код.

я не про хтмл как таковой а про вставки типа

<div>   <div style="text-align:">     <span style="color:">       <span style"font-weight:">          текст      </span>    </span>   </div> </div> <span style="font-size:">&nbsp;</span> <p>&nbsp;</p> текст <h1>текст</h1> <h1>еще текст</h1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; текст &nbsp;

и тд и тп
в таком хаусе и семантика хромает и куча байт вообще левого кода

или еще круче не очищенный от вордовских тегов текст, который порой вызывает в разметке смарти ошибки...

Что-то вы тесто месите. Левый такой код или нет, это понятие относительное, а что касается семантики и мусора Word, то htmlspacialchars уж никак не специалист в этом вопросе.

а вы прочтите что я написал выше.

Прочел и ответил, и если в контексте темы этой, то и не понятно к чему это.

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

За совет с PDO спасибо.

Подскажите, пожалуйста, можно ли средствами PDO проверить тип строки integer?

нет, зачем вам это?

Честно говоря сам не знаю, использовать is_numeric() безопасно непосредственно для $_POST? Перед самим добавлением цифр через PDO.

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

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

Если не использовать эмулированные подготовленные запросы, то получится деградация производительности.

так никто и не говорит, что не использовать. речь то шла конкрентно про параметры

Ну в общем да, будет смотреть, значит и в prepare() воткнется, где и разъясняется интересуемое )

Скажите, пожалуйста, на сколько данный код безопасен?

//Не именованные метки try { $stmt = $db->prepare("INSERT INTO test (label,color) VALUES (?,?)"); $stmt -> execute(array('perfect','green')); } catch(PDOException $e){ echo 'Error : '.$e->getMessage(); exit(); } //stmt - это "дескриптор состояния"   //Именованные метки $stmt = $db->prepare("INSERT INTO test (label,color) VALUES (:label,:color)"); $stmt -> execute(array('label'=>'perfect', 'color'=>'green'));   //Еще вариант $stmt = $db->prepare("INSERT INTO users (firstname, lastname, email) VALUES (:firstname, :lastname, :email)"); $stmt->bindParam(':firstname', $firstname); $stmt->bindParam(':lastname', $lastname); $stmt->bindParam(':email', $email); $firstname = "John"; $lastname = "Smith"; $email = "john@test.com"; $stmt->execute();

код полностью безопасен. вместо

$stmt->bindParam(':firstname', $firstname);  $stmt->bindParam(':lastname', $lastname);  $stmt->bindParam(':email', $email);

лучше отдайте массив методу execute

Спасибо, а почему лучше?

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