Закон Динамических Отрицаний Финагла :
Все, что может пойти не так, будет — в самый неподходящий момент.
Что означает «Защитное программирование»?
Проще говоря, защитное программирование — это программирование с намерением предвидеть вероятные точки отказа. Цель состоит в том, чтобы обойти эти вероятные проблемы до того, как они возникнут. Вы видите проблему, верно? Есть что-то сложное с советом «ожидай неожиданного», и оно становится во много раз хуже, когда кто-то изменяет его, «ожидая неожиданного и пытаясь предотвратить его».
Давайте посмотрим на некоторые практические примеры.
Условные заявления
Это одно из самых простых мест для защитного программирования и место, где легче всего быть довольным. Во многих случаях при программировании на PHP вам просто не понадобится «другой» случай.
Гипотетически, вы работаете над функцией и нуждаетесь в условном. У вас есть только три возможных состояния для вашей конкретной переменной на данный момент — и у вас есть те, которые покрыты в блоке, как это:
if($var == a){ } else if($var == b){ } else if($var == c){ } Вы говорите, что у вас нет других возможностей, и вы переходите к своему коду. Позволь мне остановить тебя там. Я знаю, что вы знаете, что нет других возможностей. И я тебе верю. Но иногда (неожиданные) вещи случаются. Мы забываем о чем-то. Мы смотрим на ошибки. Мы заканчиваем тем, что повторно используем немного кода вне его первоначально предназначенной области. И вдруг у нас возникают утечки и иногда молчаливые сообщения об ошибках, потому что здесь нет зацепки. Используйте else блоки. Используйте default по default в switch . Используйте их, чтобы вернуть или записать ошибку, чтобы вы знали, что произошло, если это когда-нибудь произойдет. Это может быть лишняя пара строк кода, но оно того стоит, когда происходит что-то, чего вы не ожидали.
Никогда не доверяйте вводу пользователя
Вы слышали это заявление раньше? У большинства программистов есть. Это немного расплывчато, обобщенно, конечно. Но это правда. Вы никогда не должны доверять пользовательскому вводу. Это не означает, что вы предполагаете, что все пользователи сумасшедшие хакеры, чтобы уничтожить ваше приложение с помощью одного набора хорошо продуманных команд. Там нет необходимости для паранойи. Но вы должны предполагать, что пользователи не знают ваш код. Они не знают, какие параметры вам нужно заполнить или как долго может быть ввод. Они не знают, какие типы файлов они могут загрузить (даже если приложение сообщит им) или какого размера. И иногда они — бот или хакер, и они будут пытаться запускать сценарии в своих входах. Иногда даже из входов за стеной входа в систему. Как вы знаете, когда вы можете доверять таким вещам, как аутентификация или капчи, чтобы обеспечить безопасный барьер, прежде чем пользователи придут на формы ввода?
Ответ: никогда.
Если вы никогда не доверяете пользовательскому вводу, то у вас никогда не будет взлома, потому что вы доверяете пользовательскому вводу. Видеть? Поэтому всегда проверяйте свои входные данные и всегда проверяйте, используете ли вы соответствующие методы при обработке данных, особенно при сохранении их в базе данных или извлечении их для отображения. В этом отношении — не доверяйте вводу вообще, даже когда откуда-то кроме ваших пользователей — проверка ввода всегда ваш друг. Проверьте Survive the Deep End: PHP Security и изучите возможность использования библиотеки проверки .
Предположения о вашем коде
Ничего не предполагай. Если две предыдущие темы нас чему-то учат, так это то, что мы не должны делать никаких предположений. Как программисты, особенно когда мы слишком долго фокусируемся на одном проекте, мы начинаем предполагать многое. Мы начинаем предполагать, что пользователь знает некоторые вещи, которые мы знаем. Не обязательно технические подробности, но функциональные подробности о программе. Мы предполагаем, что пользователь будет знать, насколько большими могут быть файлы, потому что… мы уже знаем этот факт. Или что они будут знать, что для сценария рассылки … но нет, они понятия не имеют об этом. Иногда это может иметь большее значение для работы переднего плана, но очевидно, что вы по-прежнему имеете дело с поведением пользователя и пользовательским вводом в бэкэнде, так что стоит подумать.
Другое ошеломляющее предположение, которое делают многие программисты, — это предположение об очевидной природе наших функций, классов или любого другого фрагмента кода, над которым мы работаем в любой момент времени. Программист-защитник постарается тщательно продумать не только обычную документацию и описание того, что делает функциональность, но и документировать любые предположения, которые он делает относительно ввода, параметров, вариантов использования или любых других подобных вещей. Потому что мы все люди, и мы иногда забываем вещи позже. Мы также, скорее всего, когда-нибудь получим поддержку, расширение или замену нашего кода. Если не что иное, вспомните, что программирование происходит в мире, полном технологических изменений. Если ваше приложение все еще существует в течение нескольких лет, возможно, его придется обновить до более новой версии PHP и потерять часть его функциональности, или любое количество компонентов, с которыми оно взаимодействует, может измениться и потребовать изменений в вашем собственном коде. Это очень сложно предсказать, поэтому хорошие комментарии и документация очень важны.
Туннельное зрение
Еще одна вещь, которая может заставить нас забыть как о хорошей практике комментирования, так и о стандартах, это туннельное зрение. Туннельное зрение часто случается с программистами. Вы знаете это чувство. Вы решаете проблему, вы в канавке. Вы чувствуете себя изолированными в своем собственном маленьком мире, с вашей музыкой (или ее отсутствием), и вы просто кодируете, и внезапно прошло два часа с тех пор, как вы в последний раз проверяли часы, и вы понимаете, что написали бесчисленные строки кода без каких-либо комментариев. Это случается со всеми нами в тот или иной момент, но важно в какой-то момент поймать это и добавить, где это уместно.
Согласованность в синтаксисе и именовании
Согласованность — это некая серая область, которая больше углубляется в стандарты кодирования и тому подобное, но она имеет отношение к защитному программированию. В PHP есть стандарты, которым можно следовать, чтобы упростить ваш код для тех, кто может его просматривать, или для вашего будущего использования. Но часто никто не делает ваш код стандартным. Однако, независимо от того, кодируете ли вы какой-то набор стандартов или нет, вы должны, по крайней мере, быть внутренне согласованными, потому что это сделает вас менее подверженным ошибкам. Это особенно относится к небольшим синтаксическим ошибкам, которые отнимают много времени, чтобы вернуться и исправить после перехвата. Если вы всегда используете один и тот же интервал, одинаковые форматы и синтаксис, соглашения об именах и т. Д., Вы с меньшей вероятностью допустите ошибку, которая приведет к неправильному прочтению вашего собственного кода. Вы также с большей вероятностью сможете быстро отсканировать и найти то, что вам нужно найти.
Вывод
Помимо поведения и действий пользователя, не думайте о своей программе вообще. Предположения являются одним из главных врагов защитника. Не думайте, что вам не понадобится регистр по умолчанию или другое утверждение. Не избегайте создания соответствующих пользовательских сообщений об ошибках, предупреждений, журналов и всего остального, что вам нужно, только потому, что вы полагаете, что они не понадобятся. Ваши предположения часто верны — но нас это не волнует. То, что нас волнует, это времена, когда они ошибаются . Всегда планируйте так, как будто вам может понадобиться вернуться к своему коду через несколько часов, недель, месяцев или даже лет, или, как это сделает кто-то другой, — и документируйте его соответствующим образом. Не думайте, что его никогда не нужно будет обновлять, расширять или поддерживать. В лучшем случае это наивно, а в большинстве случаев небрежно. Иногда просто держать идею о защитном программировании в глубине души может помочь вам более эффективно и безопасно оценивать, планировать и программировать.