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

Избегайте использования register_globals

(В определенном порядке)

1. Всегда проверяйте, что глобальные регистры отключены
2. Всегда проверяйте, что магические кавычки выключены
3. Убедитесь, что вы понимаете атаки SQL-инъекций
4. Отключить отчет об ошибках в производстве

EDIT: для «новичков» там это принципиально, почему (и поскольку у меня есть время, чтобы объяснить это):

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

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

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

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

• Межсайтовый скриптинг (XSS) Wiki , Google
• Cross-Site Request Forgery (XSRF / CSRF) Wiki , Google (благодарение ладье)
  • Викиреальность сеанса, Google
• SQL Injection (SQLi) Wiki , Google
• Выключение сообщений об ошибках в производственных средах
• Храните код «включить» в каталог, который не доступен для Интернета (либо запретите доступ, либо сохраните его за пределами веб-сайта)
• Вот статья, которую я написал о сохранении паролей в безопасном режиме , и если вы не хотите, чтобы я с ним поступил, проверьте ссылки внизу.
• В моей статье также содержится ссылка, но, учитывая ее отдельную ссылку, это документ, опубликованный MIT под названием The DOs и DON'Ts Client Authentication в Интернете ^[PDF] . Хотя часть его информации (рекомендация использовать хеш-файл MD5 для одного) несколько устарела, просто из-за того, что мы-знаем-теперь и что мы знали, тогда общие принципы очень сильны и должны быть рассмотрены.
• Одна из ссылок «Руки» напомнила мне еще один важный набор ограничений
  • Отключить глобальные регистры (теперь это значение по умолчанию, поэтому я не упоминал об этом раньше)
  • При работе с файловыми is_uploaded_file() обязательно используйте is_uploaded_file() для проверки того, что файл был загружен, и move_uploaded_file() вместо copy() или rename() .
    • Прочтите этот раздел руководства PHP, если вам нужно знать, почему (и вы это делаете).
• Поскольку я уже упоминал его дважды, проверьте ответ Rooks ( https://stackoverflow.com/questions/2275771/what-are-the-most-important-safety-precautions-that-a-php-developer-needs- to-know # 2275788 ), поскольку он включает ссылку на документ, содержащий (не-PHP-специфическую) информацию о наиболее важных проблемах безопасности (и, следовательно, это, вероятно, правильный ответ).

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

http://phpsec.org/

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

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

1. Всегда дезинфицировать и проверять данные, переданные со страницы
2. В сочетании с # 1 всегда должным образом избегайте выхода
3. Всегда выключайте display_errors в процессе производства
4. Если используется бэкэнд БД, используйте драйвер, который поддерживает / эмулирует подготовленные операторы и использует без предубеждений 🙂

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

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

Прочтите верхнюю часть OWASP .

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

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

http://phpsecurity.org/

Посмотрите на исправление Suhosin Hardening и проверьте уязвимости безопасности, которые он адресует .

Руководство PHPSec дает хороший обзор.

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

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

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

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

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

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

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

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