Когда вы совершаете покупки по ссылкам на нашем сайте, мы можем получать партнерскую комиссию. Вот как это работает.
Эта статья впервые появилась в выпуск 227 журнала .net – самого продаваемого в мире журнала для веб-дизайнеров и разработчиков.
В прошлом году произошло множество взломов веб-приложений, в результате которых были украдены миллионы личных данных. Возможно, вы не сможете остановить решительных хакеров, но, следуя некоторым основным правилам и процедурам, вы может помешать вашему приложению стать для них легкой задачей — или для обычного скрипт-кида.
Аутентификация
Веб-приложения представляют собой сложный набор проблем безопасности для разработчиков. Природа HTTP без сохранения состояния означает, что отслеживание состояния сеанса каждого пользователя становится обязанностью приложения. Предварительно приложение должно иметь возможность идентифицировать пользователя с помощью той или иной формы аутентификации. Учитывая, что все последующие решения по авторизации основаны на личности пользователя, важно, чтобы процесс аутентификации безопасен, и что механизм обработки сеанса, используемый для отслеживания аутентифицированных пользователей, в равной степени безопасен. хорошо защищен. После аутентификации пользователь не должен иметь возможности вмешиваться в параметры или процессы, которые могут привести к раскрытию конфиденциальной информации.
Аутентификация — это процесс проверки доступа пользователя к приложению. Есть три аспекта, которые следует учитывать:
- Определите, где в вашем приложении требуется аутентификация — обычно при пересечении уровня доступа. Существует три основных уровня: публичный, частный и привилегированный. Каждый из них необходимо идентифицировать в приложении и обеспечить соответствующую безопасность.
- Подтвердите, кем является пользователь. Пользователи обычно аутентифицируют себя с помощью имен пользователей и паролей.
- Идентифицировать пользователя при последующих запросах. Для этого требуется некоторая форма токена аутентификации.
Многие веб-приложения используют механизм паролей для аутентификации пользователей, когда пользователи предоставляют имя пользователя и пароль в форме HTML. Вопросы, которые следует рассмотреть:
- Передаются ли имена пользователей и пароли в виде открытого текста по незащищенному каналу? В этом случае злоумышленник может перехватить учетные данные с помощью программного обеспечения для мониторинга сети. Контрмерой здесь является защита канала связи с помощью Secure Sockets Layer (SSL).
- Как хранятся учетные данные? Если вы храните имена пользователей и пароли в виде открытого текста, в файлах или в базе данных, вы создаете проблемы. Убедитесь, что все данные пользователя зашифрованы. За последний год произошло множество громких утечек данных, которых можно было бы избежать с помощью шифрования.
- Как проверяются полномочия? Нет необходимости хранить пароли пользователей, если единственной целью является проверка того, что пользователь знает значение пароля. Вместо этого вы можете сохранить верификатор в виде хэш-значения и повторно вычислить хэш, используя значение, введенное пользователем, во время процесса входа в систему.
- Как идентифицируется аутентифицированный пользователь после первоначального входа в систему? Требуется какая-либо форма билета аутентификации, например файл cookie. Если он отправлен по незащищенному каналу, злоумышленник может перехватить файл cookie и использовать его для доступа к приложению, что называется перехватом сеанса. Firesheep (см. рамку напротив) — это расширение Firefox, которое демонстрирует это, перехватывая незашифрованные файлы cookie.
Если ваше приложение входит в число подавляющего большинства, требующих аутентификации, следует следовать нескольким рекомендациям, чтобы ограничить риск взлома:
Используйте политики блокировки учетных записей для учетных записей конечных пользователей.
Отключите учетные записи конечных пользователей или запишите события в журнал после заданного количества неудачных попыток входа в систему. Будьте осторожны, чтобы политики блокировки учетных записей не могли быть использованы во время атак типа «отказ в обслуживании». Например, во время теста на проникновение я провел перебор пароля в форме входа. Я не получил доступа, но сумел вывести из строя сервер из-за того, что приложение регистрировало каждую неудачную попытку. Решением было заблокировать IP-адрес после пяти неверных попыток входа в систему.
Поддержка сроков действия пароля
Пароли не должны быть статичными и должны меняться в рамках планового обслуживания по истечении срока действия пароля. Это может доставлять неудобства пользователям, но они должны оценить дополнительный уровень безопасности, который вы обеспечиваете.
Возможность отключения учетных записей
Если система скомпрометирована, возможность намеренно аннулировать учетные данные или отключить учетные записи может стать средством предотвращения дополнительных атак.
Не храните пароли в хранилищах пользователей
Если вам необходимо проверить пароли, нет необходимости хранить пароли. Вместо этого сохраните одностороннее хеш-значение, а затем пересчитайте хеш с использованием паролей, предоставленных пользователем.
Требовать надежные пароли
Прежде всего убедитесь, что злоумышленникам будет непросто взломать пароли. Существует множество рекомендаций, но обычно требуется минимум восемь символов, состоящих из прописных и строчных букв, цифр и специальных символов. Независимо от того, используете ли вы платформу для обеспечения их соблюдения или разрабатываете собственную проверку, этот шаг необходим для противодействия атакам методом перебора, при которых злоумышленник пытается взломать пароль посредством систематических проб. и ошибка. Используйте регулярные выражения для надежной проверки пароля.
Не пересылайте пароли по сети в открытом виде.
Пароли в виде открытого текста, пересылаемые по сети, уязвимы для подслушивания. Чтобы устранить эту угрозу, защитите канал связи, например, используя SSL для шифрования трафика.
Защитите файлы cookie аутентификации
Украденный файл cookie аутентификации приравнивается к украденному логину. Защитите билеты аутентификации с помощью шифрования и безопасных каналов связи. Кроме того, ограничьте интервал времени, в течение которого билет аутентификации остается действительным, чтобы противостоять угрозе подделки. которые могут возникнуть в результате атак повторного воспроизведения, при которых злоумышленник захватывает файл cookie и использует его для получения незаконного доступа к вашим сайт. Уменьшение времени ожидания файлов cookie не предотвращает атаки повторного воспроизведения, но ограничивает время, в течение которого злоумышленник может получить доступ к сайту с использованием украденных файлов cookie.
Манипулирование параметрами
При атаках с манипулированием параметрами злоумышленник изменяет данные, передаваемые между клиентом и веб-приложением. Это могут быть данные, отправленные с использованием строк запроса, полей формы, файлов cookie или заголовков HTTP. Следующие методы помогут защитить манипулирование параметрами вашего веб-приложения:
Удалить значения параметров из URL-адреса
Убедитесь, что конечные пользователи не могут изменять значения параметров, передаваемые в URL-адресе, через адресную строку браузера. Например,
Проверка всех значений, отправленных от клиента
Если у вас есть предопределенные значения в полях формы, с помощью прокси-сервера пользователи могут изменять значения и отправлять их обратно, чтобы получать другие результаты. Протестируйте собственное приложение, используя прокси-сервер, например WebScarab. WebScarab — это платформа для анализа приложений, которые взаимодействуют с использованием протоколов HTTP и HTTPS. Он написан на Java и поэтому переносим на многие платформы. WebScarab имеет несколько режимов работы, реализованных рядом плагинов.
В наиболее распространенном использовании WebScarab действует как перехватывающий прокси-сервер, позволяя оператору просматривать и изменять запросы, созданные браузер перед их отправкой на сервер, а также просматривать и изменять ответы, возвращаемые с сервера, до того, как они будут получены браузер. WebScarab может перехватывать как HTTP, так и HTTPS-коммуникации.
Не доверяйте информации HTTP-заголовка
Заголовки HTTP отправляются в начале HTTP-запросов и HTTP-ответов. Ваше веб-приложение должно быть уверено, что оно не основывает свои решения по безопасности на информации в заголовках HTTP, поскольку злоумышленнику легко манипулировать заголовками. Например, поле реферера в заголовке содержит URL-адрес веб-страницы, с которой поступил запрос. Не принимайте никаких решений по безопасности на основе значения поля реферера, например, для проверки исходил ли запрос со страницы, созданной веб-приложением, поскольку это поле легко фальсифицировано.
Управление исключениями
Безопасная обработка исключений может помочь избежать некоторых атак типа «отказ в обслуживании» на уровне приложения. также может использоваться для предотвращения возврата ценной информации системного уровня, полезной для злоумышленников, в клиент. Например, без надлежащей обработки исключений такая информация, как сведения о схеме базы данных, версии операционной системы, стек трассировки, имена файлов и информация о пути, строки SQL-запросов и другая информация, представляющая ценность для злоумышленника, могут быть возвращены в клиент.
Хороший подход — разработать централизованное решение для управления и регистрации исключений, а также рассмотреть возможность предоставления перехватчиков. в вашу систему управления исключениями для поддержки инструментов и централизованного мониторинга, чтобы помочь системе администраторы.
Следующие методы помогут вам защитить управление исключениями вашего веб-приложения:
Не передавайте информацию клиенту
В случае сбоя не раскрывайте информацию, которая может привести к раскрытию информации. Например, не раскрывайте детали трассировки стека, включающие имена функций и номера строк, в случае отладочных сборок (которые не следует использовать на рабочих серверах). Вместо этого возвращайте клиенту общие сообщения об ошибках.
Записывать подробные сообщения об ошибках
Отправляйте подробные сообщения об ошибках в журнал ошибок. Отправляйте потребителю вашего сервиса или приложения минимальную информацию, например общую ошибку. сообщение и собственный идентификатор журнала ошибок, который впоследствии можно сопоставить с подробным сообщением в событии. журналы. Убедитесь, что вы не регистрируете пароли или другие конфиденциальные данные.
Перехват исключений
Используйте структурированную обработку исключений и перехватывайте условия исключений. Это позволит избежать несогласованности вашего приложения, которая может привести к раскрытию информации. Это также помогает защитить ваше приложение от атак типа «отказ в обслуживании». Решите, как распространять исключения внутри вашего приложения, и убедитесь, что вы уделяете особое внимание тому, что происходит на границе приложения.
Краткое содержание
Безопасность должна быть в центре внимания каждого разработчика приложений. Разработка вашего приложения с самого начала с высоким уровнем безопасности поможет предотвратить несанкционированную утечку данных. и защитить пользователей, а учет лучших практик даст вам основу, необходимую для достижения этот.
Находить 30 лучших примеров JavaScript в Креативный блок.
