в принципе, на этом можно и остановится. нет смысла обсуждать код который написан просто так, без понимания как он вообще должен работать. он не решает реальную задачу - валидацию Имени и Фамилии. он проверяет чтото, что даже автор кода незнает что он проверяет. он не пропускает то что должен пропускать. исходную задачу код решить не может. следовательно рано проверять какуюто безопасность. глупо проверять безопасность у формы, если она ещё даже не работает как должна.
PHP: if (preg_match('/\W/u', $imja)) $imja='Vasja'; Открываем документацию и смотрим какие значения может вернуть функция preg_match. Возвращает 1, если есть совпадение с шаблоном, 0 если нет, или FALSE в случае ошибки. Теперь смотрим какие это могут быть ошибки https://www.php.net/manual/ru/function.preg-last-error.php Поврежденные данные UTF-8 приводят к PREG_BAD_UTF8_ERROR и функция возвращает FALSE. http://sandbox.onlinephpfunctions.com/code/94f22c78b3ef1629a39bf53bc46fc02c77f2f6e1 PHP: $imja="!@#\x80"; if (preg_match('/\W/u', $imja)) $imja='Vasja'; var_dump($imja); Ещё песочница http://tpcg.io/LDcp7I PHP: $id=1; $imja=""; $familija="' /*\x80*/ -- '"; При таких значениях один запрос может стереть имена и фамилии всех юзеров. Код (Text): UPDATE test SET imja='', familija='' /*�*/ -- '' where id=1
Вот @Emilien и сломал потенциально все ваши сайты, сделанные за 20 лет. Так что считайте свой код правильным и идеальным дальше.
1. Добро пожаловать в монгу. 2. Не знаете как работает база. То, что вы указали в пхпмайадминчике 11 - ничего не значит. Реально ограничение в 11 символов сработает только в одном случае. При некой правильной настройке поля. Параметр не указываю, гугл в помощь. 3. Я передумал сотрудничать даже за 1 евро.
Это круто. Это я не знал. А без u сработает? Вот так: if(preg_match('/\W/',$imja))$imja='Vasja'; --- Добавлено --- Без u - срабатывает. То есть мой метод применим только если нет Юнкода. Круто. Спасибо вам --- Добавлено --- Для Юнкода нужно чтоб переделать всё наоборот? Сейчас попробую. --- Добавлено --- Работает: Код (Text): $imja="'ж!@#\x80"; #$imja="hhhhhh"; if (preg_match('/\w/u', $imja)) ; else $imja='Vasja'; print $imja; --- Добавлено --- @Emilien, вы единственный из тех кто мне тут писал - с которым можно поговорить. Спасибо ещё раз. А в моём новом написании нет уязвимостей? --- Добавлено --- Вы даже не поняли что: 1. Это только для Юнкода. 2. Это только для Самописов. Я даже вспомнить не могу сейчас - есть ли у меня самописы. Я всё пишу на Друпале
Переписал код: PHP: <?php $mysqli = new mysqli("localhost", "root", "root", "CODINGGROUND"); $mysqli->query(" CREATE TEMPORARY TABLE test ( id INT NOT NULL, imja varchar(64) NOT NULL, familija varchar(64) NOT NULL ) "); $mysqli->query("INSERT INTO test VALUES (1, 'Ivan', 'Ivanov')"); $id=1; $imja="!!! sql !!!'/*\x80*/'"; $familija="Прохоров"; if (preg_match('/\D/', $id)) $id=103; if (preg_match('/\w/u', $imja)); else $imja='Vasja'; if (preg_match('/\w/u', $familija)); else $familija='Pupkin'; $r = $mysqli->query("UPDATE test SET imja='$imja', familija='$familija' where id=$id"); $r = $mysqli->query("SELECT * FROM test where id=$id")->fetch_object(); print_r($r); --- Добавлено --- Теперь это самы безопасный код в мире для Юнкода. До этого - был самый безопасный код в мире не для Юнкода. --- Добавлено --- А ещё ведь можно написать соответствие 0 или 1. Это даже правильней. Сейчас напишу
Нет. С FALSE код получается больше и менее наглядный --- Добавлено --- Чтоб понимать механизмы. Неужели вам это не интересно? Я прям балдею от того что я сегодня узнал про ошибки Юнкода. Это ведь круто! --- Добавлено --- Для всех. Жду 3 дня. Если не сломаете - пойдём дальше
я даже не могу вспомнить случая что бы мне когда нибудь понадобились не подготовленные запросы в мускуле))
И. Самое главное. Я вообще не вижу тут сложностей - Наоборот. Огромное упрощение кода. --- Добавлено --- Выше есть пример. Если хотите конструктивно участвовать в дискуссии - пишите код. Всё остальное - словеса.
Для начала вам нужно понять базовый механизм: наличие / отсутствие эксплойта не является критерием существования уязвимости. Вам могут предоставить конкретную реализацию, как сделал @Emilien, могут не предоставить, могут просто не захотеть тратить время на её поиски - всё это не имеет значение. Уязвимость с довольно большим набором векторов атаки уже существует. Всё. Словоблудие - это попытки оспорить этот простой и очевидный всем, кроме вас, факт.
угон машины - это УГОЛОВНОЕ преступление противоугонные системы НЕ НУЖНЫ --- Добавлено --- есть встроенные инструменты, которые развивались долгие годы и отдебажены до блеска а, твои ссаные регулярки (в качестве защиты от взлома) уже взломали дважды, а ты всё их отстаиваешь тебе никак не вдолбить в голову, что есть инструменты, которые защищают на 99.9% а ты не идеален и поэтому твоя регулярка может иметь уязвимости просто за счет человеческого факотора то что твои говносайты не взломали ни разу за 20 лет - это потому что ты нахер никому не упал взлом - это работа а работать просто так ни кто не хочет
И весь сыр бор, потому что подготовленное выражение сделать, и не парится - ну очень сложно. Если кто-то дойдёт до этого места, ещё раз: Всегда задавайте кодировку соединения с БД. для mysqli - mysqli::set_charset, для PDO сейчас можно прямо в DSN указывать, смотрите в доках Всегда используйте подготовленные запросы (mysqli:: prepare, PDO:: prepare). Любите фреймворки/пакеты, которые это делают за вас Теперь SQL-инъекции вам не страшны Если заказчиком отдельно прописано условие на логин, пароль, имя пользователя и т.п., прямым текстом в ТЗ, есть смысл проверить его с помощью регулярных выражений, что не отменяет всего вышеперечисленного. Т.е. даже если вы проверили регуляркой, всё равно работаем с БД через подготовленные запросы. Завтра требования изменятся, и новая регулярка может пропустить потенциально опасные символы.
привет)) я как сел за ларку)) не могу остановится ее любить)) она воплощение всех моих мечт о всех моих велосипедах))
Код на Ларке: Код (PHP): public function edit(User $user) { return view('users.edit', compact('user')); } public function update(User $user, Request $request) { $input = $request->validate([ 'first_name' => 'required', 'last_name' => 'required', ]); $user->update($input); return redirect()->route('users.show', [$user]); } И никаких проблем.
Так. Стоп. Я всегда задаю кодировку соединения. Всегда. Иначе на нерусских серверах - кракозябры. Я всегда прописываю кодировку в Базе - по той же причине Что получится при попытке записать в такую Юнкодную Базу неюнкодных символов? Сейчас протестирую на реальной базе --- Добавлено --- Не понимаю. На реальной базе ничего не ломается! Даже в первом варианте. Почему?
Даже думать не хочу. Даже мой первоначальный вариант рабочий. Вот: http://prohorov-andrej.ru/u/bez.php --- Добавлено --- Второй вариант: http://prohorov-andrej.ru/u/bez2.php
HTML такой же будет. Показаны методы контроллера, которые делают всю чистую работу. Черновая, типа подготовленных выражений, скрыта в глубинах фреймворка. Модель будет что-то вроде PHP: class User extends Model { protected $fillable = ['first_name', 'last_name']; }
То есть ради формы с 3 полями нужно городить несколько файлов и подключать фреймворк. Я правильно вас понял?
Написать пару файлов - это не страшно, особенно если в одном из них три строчки. Я файлов не боюсь. Хуже, когда в один всё свалено, чем когда на много разбито. Но, ещё раз, вы всё исходите из предположения, что в проекте только эта форма. А я и @ElisDN - что эта форма является частью нормального проекта. Если проект будет из одной формы, я не буду подключать фреймворк, напишу уж подготовленный запрос самостоятельно. Но обычно в проекте гораздо больше, чем одна форма, вы не находите? В одном месте будет форма для создания юзера, в другом месте надо вывести список юзеров с пагинацией, в третьем месте надо найти юзера по частичному имени, и всё это уже сделано во фреймворке. Вот, к примеру, как будет в методе контроллера выглядеть пагинация: PHP: class UsersController { // Другие методы контроллера // ... public function usersList() { return view("users.list", User::paginate(20)); } } Всё. Laravel сам произведёт вычисления количества страниц, сам посчитает смещение, сам сделает нужный запрос. Ещё раз. Если задача ограничивается обработкой одной формы - напишу один запрос руками, не развалюсь. Подготовленный, обычно через PDO, мне больше нравится, как там подготовленные запросы реализованы - можно передать все параметры прямо в PDOStatament::execute(), а не биндить по одному. Если в проекте предполагается делать что-то ещё, то воспользуюсь тем, что умные люди уже всё сделали за меня. Но я уже давно не занимаюсь задачами, ограничивающимися одной несчастной формой. --- Добавлено --- @ElisDN тоже не занимается проектами из одной формы
Это где я писал? Я сайты на Друпале делаю. Там про это думать вообще не нужно. Я это всё спросил именно потому, что изредка бывает что нужна простенькая форма. --- Добавлено --- Я это писал. Там 3 строчки кода и 1 запрос.
А посчитать количество страниц, и проверить, не превышает ли запрошенная? Если что, я тоже могу написать это без фреймворка, формула элементарная, согласен. Хочу ли - другой вопрос. --- Добавлено --- А, плюс Laravel ещё сам просчитывает smart пагинацию, чтоб не выводить все 100 номеров страниц. Вот это уже я самостоятельно делать не люблю. Где пропустить, где не пропустить, и т.п.