Основная проблема безопасности PHP

Question

Итак, я не являюсь разработчиком бэкэнд, но мне нужно разработать базовый пароль. (Совершенно необоснованный) клиент специально сказал, что ему нужен только ввод пароля. Никакое имя пользователя или какая-либо другая информация не может быть передана. Поскольку нет ни одного пользователя, есть только один пароль, который я закодировал непосредственно в скрипте. Выглядит что-то наподобие:

$password = $_POST['password'] 

if ($password == 'mypass') { 

do something.... 

} 

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

Answer 1

Является ли это уязвимым для какого-то инъекционного взлома?

Нет, потому что вы ничем не вводите ничего.

Есть ли еще какие-то огромные дыры в безопасности, о которых я должен беспокоиться?

• Он имеет очень низкую энтропию, злоумышленник просто автоматически пытается случайные пароли не должно быть слишком много проблем при получении. Вы, вероятно, знаете об этом.
• Если ваш сервер был когда-либо нарушен и/или обнаружен исходный код, жесткий пароль будет раскрываться и использоваться мгновенно. Вы могли бы хотя бы соль и хеш, чтобы это не допустить.

Answer 2

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

Я бы предложил хешировать ваш пароль и использовать srtcmp вместо оператора ==.

Answer 3

Существует сценарий, в котором это открыто для атаки, от которого вы можете или не можете пострадать.

Ваш пример требует, чтобы пользователь отправлял пароль и, что важно, не указывал, что он поддерживает сеанс на стороне сервера. Если сеанс не использовался, это будет означать, что будут защищены только страницы, содержащие этот код и на которые будет отправляться пароль.

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

например. Если ваш сайт был страницы в

1. http://example.com/общественного
2. http://example.com/admin/частного & защищенного
3. http://example.com/admin/users.phpчастного & не защищен

malicous пользователь может получить доступ к/администратору/пользователям .php напрямую, полностью mventing вашего механизма авторизации.

Answer 4

Всегда используйте одностороннее хеширование, где это возможно, для хранения в таблице db или жесткого кодирования. Вместо жесткого кодирования текстового пароля вы можете жестко задавать хеш-значение MD5 пароля. Затем вычислите хэш ввода от пользователя, а затем сравните оба. Таким образом, вы действительно боитесь, что кто-то украдет ваш код и проведет с ним пароли.