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

Как вы помните, у Алисы и Боба есть медицинские имплантаты: устройство для измерения инсулина у Алисы и кардиостимулятор у Боба. Оба являются «смарт-устройствами», то есть к ним можно подключиться через смартфон. Устройство Алисы работает через Bluetooth, а кардиостимулятор Боба – через Wi-Fi. Одним из самых очевидных способов уменьшить поверхность атаки было бы не приобретать «смарт-версии» таких устройств. Однако в данном случае делать это уже поздно. Тем не менее Алиса могла бы отключить «видимость» Bluetooth у своего прибора для измерения инсулина, а Боб – скрыть SSID своего кардиостимулятора.

Жесткое кодирование означает программирование значений в коде вместо получения их естественным путем (от пользователя, из базы данных, API и т. д.). Например, если в разработанном вами приложении-калькуляторе пользователь вводит 4 + 4, нажимает Enter и на экране появляется 8, вы, скорее всего, решите, что калькулятор работает. Однако если пользователь вводит 5 + 5 и нажимает Enter, а на экране все равно отображается 8, это может говорить о возникновении ситуации жесткого кодирования.

Почему жесткое кодирование является потенциальной проблемой безопасности? Причина двоякая: вы не можете доверять выходным данным приложения, а значения, которые были жестко закодированы, часто имеют конфиденциальный характер (пароли, ключи от API, хеши и т. д.). Любой, кто зайдет в исходный код, будет иметь доступ к этим жестко закодированным значениям. Жесткое кодирование в исходном коде секретов, требующих постоянной сохранности, – далеко не безопасное решение.

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

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

Довольно часто разработчики забывают об этом уроке и полагаются на доверие из-за сложившихся условий. Например, к выпущенному вами интернет-приложению применяются чрезвычайно строгие меры безопасности. Внутри вашей сети (в обход брандмауэра) веб-приложение постоянно вызывает API (#1), который затем вызывает другой API (#2), изменяющий данные в соответствующей базе. Часто разработчики не утруждают себя аутентификацией (подтверждением личности) в первом API или проверкой API (#1) на наличие у приложения права на вызов той части API, к которой оно обращается. А если они и выполняют такую проверку, то часто применяют меры безопасности только для API #1, но не для API #2. В результате кто или что угодно в вашей сети может вызвать API #2, включая злоумышленников, которых там быть не должно, внутренние угрозы или даже случайных пользователей (рис. 1.7).

Рис. 1.7. Пример вызова API приложением и при необходимости аутентификации

Вот несколько примеров.

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

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

• Обычный пользователь приложения расстроен и многократно стучит по клавиатуре, случайно вводя гораздо больше данных, чем следовало. Если приложение правильно проверяет вводимые данные, оно отклонит их, так как количество символов превышает допустимый предел. Однако, если приложение не проверит эти данные, возможно, они перегрузят переменные или будут переданы в базу данных, следствием чего станет сбой. Без проверки соответствия получаемых данных ожиданиям (число в числовом поле, дата в поле даты, соответствующее количество вводимых символов и т. д.) приложение может перейти в неизвестное состояние со множеством ошибок безопасности. Приложение ни в коем случае не должно переходить в неизвестное состояние.

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

Решение заключается в создании удобных средств защиты. Хотя очевидно, что без доступа в интернет все наши приложения стали бы безопаснее, такая защита от угроз в интернете была бы непродуктивной. Необходимо проявить творческий подход и найти самый простой способ, но при этом и самый безопасный.

Вот примеры удобства и безопасности.

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

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