Насколько защищена представленная конструкция php?

Question

[Григорий]

Насколько безопасна данная конструкция с точки зрения взлома?
Есть форма логина - который проверяется файлом login.php следующего вида:

<?php

$login = !empty($_POST['login']) ? $_POST['login'] : '';
$password = !empty($_POST['password']) ? $_POST['password'] : '';

if ($login === 'login' && $password === 'password ') {
    echo 'рендер кода страницы с формами для создания новых файлов на сервере'
} else {
    echo 'Неверный логин';
}
?>

Логин пароль временные - основной вопрос по конструкции которая проверяет логин и пароль.
Всё размещается на хостинге.

Answer 1

[FanatPHP]

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

Также код можно сильно сократить. Уже сто лет как в РНР есть сокращенный вариант проверки на isset, плюс можно сразу прервать выполнение, и не делать лишнюю вложенность

<?php

$login = $_POST['login'] ?? '';
$password = $_POST['password'] ?? '';
$hash = '$2y$10$e6RRGG8zFvsE6Bl7at/Vx./igFslOmnLo6poA6N1QoNWrgrkedHqO';

if ($login !== 'login' || !password_verify($password, $hash)) {
    die('Неверный логин');
}
echo 'рендер кода страницы с формами для создания новых файлов на сервере';

Закрывающий тег тоже не нужен

Answer 2

[profesor08]

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

if ($_POST['login'] === 'login' && $_POST['password'] === 'password ')

Но можно использовать filter_input и filter_var

function post($name, $default = null)
{
  return filter_input(INPUT_POST, $name, FILTER_SANITIZE_STRING);
}

echo post("password");

Comments

[John Didact]

if (isset($_POST['login'], $_POST['password']) && $_POST['login'] === 'login' && $_POST['password'] === 'password') {}

и не нужно ничего отключать.

А вообще, для большего извращения, если нужно только строки вывести, то я бы сделал:

echo (isset($_POST['login'], $_POST['password']) && $_POST['login'] === 'login' && $_POST['password'] === 'password') ? 'рендер кода страницы с формами для создания новых файлов на сервере' : 'Неверный логин';

[FanatPHP]

офигеть рекомендация, "отключить отображение предупреждений".

[profesor08]

FanatPHP, в логах все есть

[profesor08]

John Didact, isset это скучно

[FanatPHP]

тупой троллинг
сотри лучше свой ответ целиком

[profesor08]

FanatPHP, ну ну. А если не сотру, то что?

[FanatPHP]

будешь дальше позориться

[profesor08]

FanatPHP, разве, а в чем позор?

[FanatPHP]

в идеях типа "отключим сообщения об ошибках" или "насрем в логи бессмысленных ошибок чтобы труднее было искать важные"

[profesor08]

FanatPHP, бывают ситуации, когда отображение ошибок ничем не поможет, они могут быть скрыты стилями, или сломать разметку и не отобразиться, и ты либо трахаешь себе мозг почему что-то не так, либо смотришь в логах. На продакшене отображение ошибок отключено по умолчанию, и придется смотреть в логах. Поэтому, лично для меня, удобнее смотреть вывод ошибок в консоли, там сразу все понятно, где, что и почему. Править ошибки по их отображению на веб странице это все равно что дебажить код через var_dump, die, exit.

[FanatPHP]

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

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

[profesor08]

FanatPHP,

отключить отображение предупреждений

Что тут не понятного? Бурная фантазия?

Answer 3

[Иван Корюков]

Уязвимость - это когда злоумышленник использует такие варианты параметров, обработку которых разработчик не предусмотрел.
Варианты обработки параметров - это не только когда мы явно сравниваем переменную с чем-то. Например печально известная функция printf() в языке Си принимает шаблон и значения, которые в него надо ставить, если шаблон может ввести пользователь, то он может подобрать такой шаблон, который выдаст больше чем планировал разработчик.
printf - потенциально уязвимая функция.
К потенциально уязвимым функциям можно отнести интерпретирующие функции. Например запрос к БД. Например через одну лишь функцию mysql_query() можно в теории сделать с БД что угодно.
Это "что угодно" ограничивается тем какой запрос передаётся в функцию. Однако если запрос хоть как-то зависит от того что ввёл пользователь, то разработчику надо предусмотреть любые варианты ввода пользователя так, чтобы запрос продолжал делать то что нужно разработчику, а не пользователю.
Но не только лишь божественные интерпретирующие функции кроют в себе опасность. Например сохранение некоторой строки в БД и последующий вывод этой строки на страницу тоже может быть опасным, хотя при записи в БД эта строка безопасна. Я говорю о подстановке js кода в страницу, которая будет показана другому человеку.
Т.е. варианты использования введёного пользователем параметра не ограничиваются той функцией которая непосредственно обрабатывает введённый параметр, но и накапливаются дальше за всё время использования данных, которые когда-то ввёл пользователь.

К чему я это всё?
К тому, что для того чтобысказать уязвим ли этот код, нужно оценить как на него повлияют разные варианты введённого логина и пароля или других параметров, которые возможно есть в этом скрипте.
Я не вижу в этом коде божественных функций, не вижу никакого другого использования введённых параметров кроме их сравнения с литералом. На основании этого могу сказать, что код вполне надёжен.
Конечно, всегда есть опасность того, что, допустим по историческим причинам оператор === для строк имеет особое поведение, когда в строке есть символ 0xFFAA.

Comments

[FanatPHP]

Юноша, тебе не в программисты, а в писатели идти надо.
Накатать страницу текста, и не сказать вообще ничего по теме - это особый талант надо иметь.

оператор === для строк имеет особое поведение, когда в строке есть символ 0xFFAA.

И что это ещё за эротические фантазии?

[Иван Корюков]

FanatPHP, читайте внимательнее и не вырывайте фразы из контекста только для того чтобы казаться умнее за счёт критики дргих.
У меня дано заключение:

На основании этого могу сказать, что код вполне надёжен.

С оператором === приведён выдуманный пример. Выдуманный для php, но вполне реальный для других языков.

Конечно, всегда есть опасность того, что, допустим по историческим причинам оператор === для строк имеет особое поведение, когда в строке есть символ 0xFFAA.

Answer 4

[xmoonlight]

Я лично привык доверять только регуляркам!)
И юзать preg_match() и подобные..

Comments

[John Didact]

В этом случае разве целесообразно использовать регулярки?)

[xmoonlight]

John Didact, вопрос в доверии к исходникам PHP и надёжности в плане безопасности.

Я не знаю как там сработают встроенные функции в PHP (под "капотом"), но одну и ту же регулярку я могу всегда проверить на разных уровнях веб-приложения и затем, использовать для надёжной фильтрации любых данных.

[Дмитрий]

xmoonlight, ну как по мне это параноя, ну и проверки бывают разные, на массив или число, или на объект

[xmoonlight]

Дмитрий, лучше перестраховаться!)