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

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

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

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

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

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

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

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

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

http://phpsec.org/

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

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

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

Предупреждение: Эта функция УСТАРЕЛА в PHP 5.3.0 и УДАЛЕНА в PHP 5.4.0.

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

http://phpsecurity.org/

• Межсайтовый скриптинг (XSS) Wiki , Google
• Подделка межсайтовых запросов ( XSRF / CSRF) Wiki , Google (спасибо Rook)
  • Session Fixation Wiki , Google
• Внедрение SQL (SQLi) Wiki , Google
• Отключение сообщений об ошибках в производственных средах
• Храните любой «включаемый» код в каталоге, который недоступен в Интернете (либо запретить доступ или оставить его за пределами корневого каталога)
• Вот статья, которую я написал о безопасном хранении паролей , и если вы не хотите верить мне на слово, проверьте ссылки на дно.
• В моей статье также есть ссылка на статью, опубликованную M.I.T. называется Что можно и чего нельзя делать при аутентификации клиентов в Интернете ^[PDF] . Хотя некоторая его информация (например, рекомендация использовать хеш MD5) несколько устарела просто из-за того, что мы знаем сейчас по сравнению с тем, что мы знали тогда, общие принципы очень сильны, и их следует учитывать.
• Одна из ссылок Ладьи напомнила мне о другом важном наборе ограничений
  • Отключить глобальные регистры (сейчас это значение по умолчанию, поэтому я не упоминал об этом раньше)
  • При загрузке файлов обязательно используйте is_uploaded_file () , чтобы проверить, что файл был загружен, и move_uploaded_file () вместо copy () или rename () .
    • Прочтите этот раздел Руководства по PHP , если вам нужно знать, почему (и вы знаете).
• Поскольку я упоминал его дважды, ознакомьтесь с Ответом Грача ( https://stackoverflow.com/questions/2275771/what-are-the-most-important-safety- меры предосторожности, которые-a-php-developer-need-to-know # 2275788 ), поскольку он включает ссылку на документ, который содержит (не относящуюся к PHP) информацию о наиболее важных проблемах безопасности (и поэтому, вероятно, правильный ответ).

(В произвольном порядке)

1. Всегда проверяйте, что глобальные регистры выключены
2. Всегда проверяйте, что магические кавычки выключены
3. Убедитесь, что вы понимаете Атаки с использованием SQL-инъекций
4. ВЫКЛЮЧИТЕ отчет об ошибках в производстве

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

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

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

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

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

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

Сколько из вас, пользователей окон, сказали окнам, что они в порядке, чтобы позвонить домой и убедиться, что ваша копия подлинна?

0.

Здесь много высоких и сильных ответов «мой компьютер - это мой домен», и суть в том, что он грубый, а не противозаконный. Скорее, его обыденность. Держите раскрытие в лицензионном соглашении, и вы готовы пойти.

не используйте «Register Global Variables» и фильтруйте пользовательский ввод для xss и инъекций

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

Прочитайте верхний 10 OWASP .

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

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

не используйте "Register Global Variables" и фильтруйте пользовательский ввод для xss и инъекций

1. Всегда санируйте и проверяйте данные, передаваемые со страницы
2. В сочетании с #1, всегда правильно экранируйте ваш вывод
3. Всегда выключайте display_errors в production
4. При использовании бэкенда DB используйте драйвер, который поддерживает/эмулирует подготовленные операторы и используйте без предубеждений :-)