Какие проблемы безопасности я должен искать в PHP

Я только начинаю изучать PHP, я давно разрабатываю веб-приложения в ASP.Net. Мне было интересно, есть ли какие-либо ошибки PHP, специфические, которые я должен искать.

Итак, мой вопрос - вот какие советы по безопасности, которые должен знать каждый разработчик PHP.

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

Ответы

Ответ 2

(Без особого порядка)

РЕДАКТИРОВАТЬ: Для "новичков" там это основная причина (и, поскольку у меня есть время, чтобы объяснить это):

  • Регистрировать глобальные переменные является аберрацией. Это лучшая дыра в безопасности. Например, если register_globals включен, url http://www.yourdomain.com/foo.php?isAdmin=1 объявит $isAdmin как глобальную переменную без необходимого кода. Я не знаю, почему эта "особенность" проделала путь к PHP, но люди, стоящие за этим, должны иметь следующую татуировку на лбу: "Я изобрел PHP Register Globals", чтобы мы могли бежать от них, как вредители, когда мы см. их!

  • Волшебные кавычки - еще одна немая идея, которая сделала это способом PHP. В основном, когда ON PHP автоматически избегает кавычек ( "становиться" и "становиться" ), чтобы помочь с атаками SQL-инъекций. Концепция неплохая (помочь избежать атак атаки), но экранирование значений all GET, POST и COOKIE делает ваш код настолько сложным (например, каждый раз при отображении и данных приходится выполнять unescape). Плюс, если в один прекрасный день вы отключите этот параметр OFF, не внося никаких изменений в свой код, все ваши коды и/или данные будут разбиты и (даже более) уязвимы для инъекционных атак (да, даже когда ON вы уязвимы).

  • Данные ваших данных - ваша самая ценная вещь на вашем сайте. Вы не хотите, чтобы люди возились с ним, поэтому предохраняйте себя и читайте об этом и с учетом этого.

  • Снова это может привести к проблемам безопасности. Сообщение об ошибке может дать подсказки для взлома того, как работает ваш код. Кроме того, эти сообщения ничего не значат для ваших посетителей, поэтому зачем их сеять?

Ответ 3

  • Скрипты между сайтами (XSS) Wiki, Google
  • Подделка запроса на межсайтовый запрос (XSRF/CSRF) Wiki, Google (спасибо Ладье)
  • SQL Injection (SQLi) Wiki, Google
  • Отключить сообщения об ошибках в производственных средах
  • Храните какой-либо код "include" в каталоге, недоступном для веб-сайта (либо запретите доступ, либо сохраните его за пределами веб-сайта).
  • Вот статья, в которой я писал о сохранении паролей безопасным способом, и если вы не хотите, чтобы я взял слово за это, проверьте ссылки внизу.
  • Также связан в моей статье, но, учитывая его собственную отдельную ссылку, это документ, опубликованный M.I.T. называемый ДО и DON'T аутентификации клиентов в Интернете [PDF]. Хотя часть его информации (рекомендация использовать хеш файл MD5 для одного) несколько устарела, просто из-за того, что мы-знаем-теперь и что мы знали, тогда общие принципы очень сильны и должны быть рассмотрены.
  • Одна из ссылок в Rooks напомнила мне еще один важный набор ограничений
    • Отключить глобальные регистры (теперь это значение по умолчанию, поэтому я не упоминал об этом раньше)
    • При работе с файловыми загрузками обязательно используйте is_uploaded_file(), чтобы проверить, что файл был загружен, и move_uploaded_file() вместо copy() или rename().
  • Поскольку я уже упоминал его дважды, откройте Ответы на ладони (fooobar.com/questions/172233/...) как он содержит ссылку на документ, содержащий (не-PHP-специфическую) информацию о наиболее важных проблемах безопасности (и, следовательно, это, вероятно, правильный ответ).

Ответ 4

здесь есть ссылка на хорошие методы программирования безопасности PHP.

http://phpsec.org/

Большинство проблем безопасности вращаются вокруг пользовательского ввода (естественно) и удостоверяются, что они вас не заглушают. Всегда проверяйте правильность ввода.

http://htmlfixit.com/cgi-tutes/tutorial_PHP_Security_Issues.php

Ответ 5

  • Всегда очищать и проверять данные, переданные со страницы
  • В сочетании С# 1 всегда должным образом избегайте выхода
  • Всегда отключайте display_errors в процессе производства
  • Если использование бэкэнда БД использует драйвер, который поддерживает/эмулирует подготовленные инструкции и использует без ущерба: -)

Ответ 6

не использовать "Регистрировать глобальные переменные" и фильтровать пользовательский ввод для xss и инъекций

Ответ 7

Язык Vs Программист. Вы можете написать самую серьезную уязвимость, и вы не получите сообщение об ошибке или ошибке. Уязвимости могут быть такими же просто, как добавление или удаление 2 символов в вашем коде. Существуют сотни различных типов уязвимостей, которые влияют на PHP-приложения. Большинство людей думают о XSS и Sql Injection, потому что они самые популярные.

Прочитайте OWASP top 10.

Ответ 8

Если вы используете базу данных mysql, убедитесь, что вы вызываете mysql_real_escape_string при отправке данных в базу данных

Ответ 9

Существует множество мер предосторожности. Я могу порекомендовать книгу Криса Шифлетта: PHP и безопасность веб-приложений.

http://phpsecurity.org/

Ответ 12

Большинство проблем безопасности, связанных с PHP, исходят из использования переменных unparsed "out" (GET/POST/COOKIE). Люди помещают такие данные непосредственно в пути к файлам или sql-запросы, что приводит к утечке файлов или SQL-инъекциям.

Ответ 13

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

http://www.owasp.org/index.php/PHP_Top_5

Ответ 14

  • Всегда закрывайте SQL-соединение.
  • Всегда выпускать результаты SQL.
  • Всегда скрестите все переменные, помещенные в базу данных.
  • При удалении или удалении из sql используйте ограничение 1 на всякий случай.
  • При разработке убедитесь, что у вас есть блокировка вещей, чтобы сохранить нежелательный выход. Если он открыт, и вы знаете, что сейчас не загружать страницу, потому что это может сломать что-то, это не значит, что другие люди это делают.
  • Никогда не используйте Admin или Root в качестве имени вашего сервера.

Ответ 15

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

Ответ 16

Часто вводные учебники вообще не говорят о проверке данных от пользователей. Как и во всех средах программирования, никогда не доверяйте данным, которые вы получаете от пользователей. Научитесь использовать такие функции, как is_numeric(), isset() и mysql_real_escape_string() для защиты вашей системы.

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

Ответ 17

Всегда используйте POST, а не GET для важных данных...