Критерии оценки экрана веб-приложений - Программирование, компьютеры и кибернетика дипломная работа
Главная
Программирование, компьютеры и кибернетика
Критерии оценки экрана веб-приложений
Разработка критериев оценки экрана веб-приложений. Основные подходы к защите веб-приложений. Анализ российских нормативных документов. Зарубежная практика выбора экрана веб-приложений. Разработка и обоснование общих требований к механизмам защиты.
посмотреть текст работы
скачать работу можно здесь
полная информация о работе
весь список подобных работ
Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
На сегодняшний день можно уверенно говорить о том, что веб-технологии прочно вошли в жизнь любого бизнеса, являясь наиболее удобным способом предоставления информации: коммерческие и государственные структуры весьма активно предоставляют свои услуги, используя публичные и частные сети для всех видов пользователей. Преимущества такого подхода очевидны - улучшаются наиболее критичные показатели бизнес-процессов: производительность, оперативность, доступность, стоимость и т.п.
Но с ростом возможностей веб-приложений происходит и увеличение совокупной стоимости обрабатываемой в системе информации, а также возрастает вероятность эксплуатации уязвимостей в развивающемся функционале прикладного обеспечения. Последние исследования показывают, что веб -приложения наиболее подвержены атакам со стороны хакеров, являясь при этом как самой их целью, так и отправной точкой для целенаправленной атаки на всю сеть предприятия. Такое развитие событий драматически увеличивает риски информационной безопасности.
Для уменьшения рисков использования веб-приложений в организациях используются специальные системы защиты, экраны веб-приложений. Аналогично системам предотвращения вторжений, они обрабатывают данные на входе и выходе от защищаемого сервиса и с помощью сигнатурного, эвристического и интеллектуального анализа предотвращают эксплуатацию уязвимостей.
Однако, внедрение и эксплуатация системы защиты веб-приложений для большинства служб защиты информации на предприятии -- это серьезная проблема. Связано это в первую очередь с тем, что до последнего времени проблематика защиты веб-приложений была полностью отдана разработчикам или другим службам информационной поддержки, так как считалось, что никто кроме них не сможет устранить те самые ошибки, которые и приводят к появлению уязвимостей. Такой подход работал, пока организация обслуживала только одно или два веб-приложения и могла закрывать издержки по обеспечению процесса анализа исходного кода, валидации конфигураций, и тестирования для каждого из веб-приложений. Но сегодня большой бизнес обслуживает десятки и даже сотни веб-приложений. При таких обстоятельствах говорить о кропотливой работе с каждым веб-приложением, к сожалению, не приходится. Необходима более масштабируемая мера, которой и является экран веб-приложений, и, как и любое другое инфраструктурное решение по защите информации, оно уже входит в сферу компетенций именно службы защиты информации, которая начинает решать проблему внедрения и обслуживания такой системы с подбора наиболее подходящего решения.
Выбор продукта, это сложная задача, которой и посвящена данная работа, следует учитывать множество факторов, которые могут быть важны как в целом для продукта, как инфраструктурного решения, так и специализированные факторы, имеющие ценность в редких и исключительных случаях, но важных с точки зрения защищаемых веб-приложений.
В данной работе разработаны наиболее актуальные критерии экрана веб-приложений, которые смогут стать вспомогательным или основным инструментом при определении технических требований к выбираемому продукту с тем, чтобы выбранное решение максимально подходило для организации, решало поставленные задачи и покрывало наиболее актуальные угрозы.
ГЛАВА 1. ПОДХОДЫ К РЕШЕНИЮ ЗАДАЧИ ЗАЩИТЫ ВЕБ-ПРИЛОЖЕНИЙ
· Осведомление о цикле безопасной разработке, передача необходимых знаний о его процессах
· Выполнение планов реагирования на инцидент
Экран веб-приложений может быть реализован как облачный сервис, программное обеспечение для веб-сервера, программно-аппаратный комплекс железное или виртуальная машина для сред виртуализации. Развитие рынка веб-приложений пока складывается так, что облачный сервис востребован в среднем и малом бизнесе, для крупного бизнеса актуален программно-аппаратный комплекс. Экран веб-приложений как модуль веб-сервера, так и остался, по сути, в зачаточном состоянии и больше подходит для энтузиастов, чем для бизнес-задач. Хотя шансы его развития в будущем крайне большие, связано это с тем, что устанавливая экран веб-приложений непосредственно на веб-северве, мы экономим ресурсы поддерживающей работы приложения инфраструктуры на дешифрацию, парсинг, и обработку запроса. Дело в том, что остальные режимы внедрения экрана веб-приложения подразумевают двойное выполнение данных процедур, сначала на экране, а затем уже и непосредственно на самом приложении. Помимо фактора экономии ресурса, агентский экран веб-приложений эффективен с точки зрения безопасности, так как позволяет избежать ошибок нормализации при интерпретации запроса.
Зачем же потребовалось выводить экран веб-приложений в отдельный класс устройств? Ведь по сути решение может вписаться в класс продуктов межсетевых экранов прикладного уровня. Тут же появляется вопрос: почему именно веб-приложений, которая так все поменяла, хотя и до этого средства экранирования поддерживали протоколы HTTP/HTTPs? Ответ на эти вопросы кроется в модели OSI, которая группирует закономерности, протоколы и механизмы для каждого из семи уровней по типу межсетевого взаимодействия. Традиционно считается, что прикладной уровень -- это последний уровень модели и выше него располагаются только данные конечных приложений, которые не могут быть формализованы и сгруппированы. Однако с развитием стандартов представления информации прикладными сервисами уже можно говорить о том, что, частично, данные, которыми оперируют определенные группы приложений, хорошо формализуются, и правила их представления, по сути, являются некими проприетарными протоколами или, упрощенно говоря, закономерностями. Таким образом, можно говорить о появлении нового уровня межсетевого взаимодействия, который скрыт для классических межсетевых экранов прикладного уровня. Новый класс устройств -- экран веб-приложений -- характеризуется способностью понимать группы протоколов и зависимостей, свойственных для веб-приложений, которые строятся над прикладными протоколами http/https.
Классическое размещение экрана веб-приложений в сети -- в режиме обратного прокси-сервера, перед защищаемыми веб-cерверами. В зависимости от производителя могут поддерживаться и другие режимы работы -- например, прозрачный прокси-сервер, мост или даже пассивный режим, когда продукт работает с репликацией трафика. После установки экрана веб-приложений и пуска продуктивного трафика сразу же начинает работу основной компонент защиты -- машинное обучение, в ходе которого составляется эталонная модель коммуникации с объектом защиты, и таким образом формируется «белый» список допустимых идентификаторов доступа. На данный момент в веб-приложениях используются три типа идентификатора доступа: HTTP-параметры (в представлениях типа: Raw, XML, JSON), идентификатор ресурса (URL, URN), идентификатор сессии (cookie). Задача экрана веб-приложений состоит в определении допустимых значений идентификаторов для веб-приложения. Из определенных значений впоследствии будет состоять эталонная (позитивная) модель. Включение конкретных значений идентификатора в модель осуществляется на основе применения математико-статистического алгоритма, который с помощью выборки продуктивного трафика оценивает эти значения как допустимые. Когда все ресурсы веб-приложения добавлены в позитивную модель, администратор системы должен убедиться в отсутствии значимого количества ложно-позитивных срабатываний и переключить систему в режим блокировки. Помимо машинного обучения в набор функций экрана веб-приложений обычно входят следующие типовые механизмы защиты: валидация протокола; сигнатурный анализ; защита от инъекций и XSS (зачастую проприетарная); возможность создания собственных правил защиты; DDoS-защита; интеграция с репутационными и фрод-сервисами; интеграция с прочими устройствами в ландшафте ИБ компании. Приоритетом для производителя экрана веб-приложений является фокус на собственных исследовательских центрах, которые генерируют обновления политик безопасности с учетом актуальных угроз веб-приложениям. Так появляются, например, сигнатуры атак, присущие для конкретных веб-фреймворков и систем контроля контента или проприетарные механизмы защиты от XSS и SQL-инъекций.
Противодействие известным и неизвестным уязвимостям
Проверка большого количества приложений
Фильтрация запросов по белым и черным спискам
Атематическое закрытие обнаруженных уязвимостей
Особенно интересен случай с автоматическим закрытием обнаруженных уязвимостей. Когда экран веб-приложений интегрирован с процессами тестирования безопасности приложений, владельцы веб-инфраструктур получают возможность публиковать приложения, содержащие даже критически опасные уязвимости. Достигается эта возможность с помощью использования технологии виртуального обновления, когда отчеты анализатора загружаются в экран веб-приложений. Это позволяет не задерживать запуск приложения до фактического устранения выявленных уязвимостей, но при этом гарантирует необходимый уровень безопасности приложения. Работа технологии виртуальных обновлений основана на интерпретации отчета анализатора для механизмов защиты экрана веб-приложений: формируются дополнительные правила фильтрации, исключающие уязвимости, найденные анализатором.
Подводя итог, безопасность приложений -- это наиболее сложный аспект информационных систем. С одной стороны, новая функциональность и постоянная доступность приложений -- это залог финансовых достижений, с другой, растущая возможность компрометации приложений, которая ставит под угрозу весь бизнес. Необходимо соблюдать хрупкий баланс между внедрением контрмер и целостностью протекающих бизнес-процессов.
Безопасность веб-приложений на предприятии, может гарантироваться только в случае, если:
· продуктивные веб-приложения созданы и живут в цикле безопасной разработки;
· установлен экран веб-приложений, который закрывает веб-приложение от известных, но еще не закрытых в цикле разработке уязвимостей, сдерживает эксплуатацию неизвестных;
· Функционирует центр безопасности. Производится постоянный мониторинг и тюнинг WAF. Сочлененные правильным образом технологии, процессы и люди, готовы начать реализацию дополнительных контрмер.
ГЛАВА 2. РАЗРАБОТКА КРИТЕРИЕВ ОЦЕНКИ ЭКРАНА ВЕБ-ПРИЛОЖЕНИЙ
Экраны веб-приложений -- это относительно новое средство защиты информации, и до недавнего времени никаких упоминаний о его применении в Российских нормативной базе не было. В связи с этим производители таких устройств могли получить сертификат от Федеральной службы по техническому и экспертному контролю только на соответствие техническим условия и на не декларированные возможности. Однако, Федеральная служба по техническому и экспертному контролю выпустила информационное сообщение об утверждении требований к межсетевым экранам от 28 апреля 2016г. N 240/24/1986. В которым, были определены требования для новых типов межсетевых экранов, среди которых и требования для экранов веб-приложений, классифицированного как межсетевой экран уровня веб-сервера.
Межсетевой экран уровня веб-сервера (тип «Г») - межсетевой экран, применяемый на сервере, обслуживающем сайты, веб-службы и веб-приложения, или на физической границе сегмента таких серверов (сервера). Межсетевые экраны типа «Г» могут иметь программное или программно-техническое исполнение и должны обеспечивать контроль и фильтрацию информационных потоков по протоколу передачи гипертекста, проходящих к веб-серверу и от веб-сервера;
Требование по контролю и фильтрации информационных потоков по протоколу передачи гипертекста (HTTP), проходящих к веб-серверу и от веб-сервера явно недостаточно для того, чтобы сформулировать правильное техническое задание или критерии оценки экранов веб-приложений поэтому есть смысл обратиться к зарубежным практикам.
Первым значимым драйвером рынка экранов веб-приложений стало обновление стандарта безопасности индустрии платежных карт PCI DSS в части требования 6.6 в 2008 году. В результате обновления у сертифицирующихся организаций появилась альтернатива при обеспечении информационной безопасности своих веб-приложений: организация может сама выбирать -- либо поддерживать бизнес-процессы по анализу защищенности веб-приложений (внедрению процессов цикла безопасной разработки), либо внедрять и обслуживать экран веб-приложений. Новый вариант стандарта и определил первые ключевые требования для систем экранирования веб-приложений. Выполнение данных требований до сих пор актуально для многих разработчиков, так как стандарт особенно важен в финансовой и банковских сферах.
Общие требования к экрану веб-приложений по версии PCI DSS:
· системные компоненты экрана веб-приложений должны соответствовать требованиям PCI DSS;
· возможность реагирования на угрозы, описанные в OWASP Top Ten;
· инспектирование запросов и ответов на соответствии с политикой безопасности, журналирование событий;
· предотвращение утечки данных -- инспекция ответов сервера на наличие критичных данных;
· применение как позитивной, так и негативной модели безопасности;
· инспектирование всего содержимого веб-страниц, включая HTML, DHTML и CSS, а также нижележащих протоколов доставки содержимого (HTTP/HTTPS);
· инспектирование сообщений веб-сервиса (SOAP, XML);
· инспектирование любого протокола или конструкции данных, использующихся для передачи данных веб-приложения вне зависимости от того, является ли он проприетарным или стандартизованным (как для входящих, так и исходящих потоков данных);
· защита от угроз, направленных непосредственно на экран веб-приложений;
· поддержка SSL\TLS-терминации соединения;
· предотвращение или обнаружение подделки идентификатора сессии;
· автоматическое скачивание обновлений сигнатур атак и применение их;
· возможность установки режима отказоустойчивости;
· поддержка устройством клиентских SSL-сертификатов;
· поддержка аппаратного хранения ключей.
Данные требования сформулировали представление о том, как должны выглядеть экраны веб-приложений, но малое количество критериев, расплывчатые формулировки и не структурированность предъявляемых требований, не позволяют использовать эти требования в качестве оценивающих эффективность экрана веб-приложений, так как не могут быть использованы для сравнения разных решений между собой.
Более серьезно к формированию критериев для экранов веб-приложений сделал проект Web Application Firewall Evaluation Criteria ( WAFEC ) , который поддерживался сразу двумя профильными организациями, это, Open Web Application Security Project ( OWASP ) и Web Application Security Consortium ( WAFEC ) . Данный проект преследовал две основные цели, это помочь в общем понимании роли экрана веб-приложений в защите их, и предоставить инструмент для обоснованного выбора соответствующего продукта класса экран веб-приложений. Первая версия выпущенного документы появилась на свет в 2006 году и была широко распространена в области защиты веб-приложений. В 2013 году команда вновь собралась, для того, чтобы выпустить вторую версию документа, но до сих пор так и не получилось сформировать новые требования для экранов веб-приложений, в то время как критерии из первой версии документа успели устареть и во многом уже не отражают эффективность экранов веб-приложений, так как не учитывают новые угрозы, уязвимости и появившееся технологии защиты с 2006 года. Однако несмотря на эти проблемы, изданный документ WAFEC представляет собой хорошо организованный документ, с четкой и понятной структурой на основе которой можно продолжить трансформацию документа, убрать устаревшие критерии и добавить актуальные. Переработка критериев с учетом результатов исследования представленной в данной магистерской диссертации представлены в Приложении 1.
При описании общих требований к экрану веб-приложений, правильно будет ориентироваться на тот функционал, который уже присутствует у большинства решений рынка, в виду того, что каждый производитель поддерживает достаточно большие и затратные процессы по исследованию проблематики защиты приложений, и реализовывает наиболее актуальные механизмы защиты. Соответственно, места пересечения по функционалу среди нескольких производителей и можно будет определить, как базовый функционал или общие требования. При анализе производителей рынка экранов веб-приложений, были рассмотрены такие решения, как:
· Imperva Web Application Firewall ;
· F5 Application Security Manager ;
· Positive Technologies Application Firewall .
Проанализировав основные лидирующие продукты на мировом рынке, можно сформировать список защитных механизмов, которые обычно присущи WAF:
· машинное обучение эталонной модели;
· пользовательские правила выявления нелегитимных запросов;
· защита от атак типа «Отказ в обслуживании»;
· интеграция со сторонними решениями.
Проверка протокола -- это базовый механизм пассивной защиты от потенциальных атак, которые производятся с использованием нетипичного применения возможностей HTTP. Его цель состоит в том, чтобы оставить злоумышленникам как можно меньше места для маневра, ограничив запрос специальными проверками. В первую очередь это проверка HTTP-заголовков на соответствие RFC, однако этого недостаточно, и производители идут дальше, используя ограничения по «лучшим практикам» и собственным правилам, сформулированным в процессе анализа возможных уязвимостей. Обычно применяются следующие ограничения:
· длина и количество заголовков, параметров;
· отсутствие недопустимых значений.
Машинное обучение является ключевым механизмом защиты, и именно на него делают основную ставку производители экранов веб-приложений при разработке и продвижении своих решений. Машинное обучение эталонной модели представляет из себя процесс внесения идентификаторов доступа веб-приложения в специальную модель, с последующим сравнением к ней поступающих запросов. Сопоставление запросов с выученной эталонной моделью помогает предотвращать эксплуатацию как известных, так и неизвестных уязвимостей. Механизмы защиты на основе машинного обучения различаются по:
Примеры описывающие характеристики машинного обучения приведены в таблице 3.
Таблица 3 - Характеристики машинного обучения.
Помимо идентификаторов доступа из запроса пользователя, различные реализации позволяют вносить дополнительные сведения, которые повышают эффективность обучения. Например, могут учитываться следующие данные:
· запросы от доверенных узлов (зона тестирования);
· тип параметра: dynamic, static, hidden, read-only;
Сердце машинного обучения, математический аппарат, нацеленный на обнаружение аномалий в самом глубоком понимании прикладного обеспечения. Например,
· метод опорных векторов ( Support Vector Machine );
· нейронные сети ( Neural Networks );
· скрытая модель Маркова ( Hidden Markov Model ).
Во избежание рекурсивного обучения в машинном обучении должны применяться понятные критерии готовности элемента к внесению его в эталонную модель. Например, это могут быть следующие критерии:
· количество запросов, содержащих обучаемый элемент;
В ходе цикла разработки защищаемое веб-приложение постоянно меняет свою модель поведения. Несоответствие выученной эталонной модели с реальной приводит к блокировке клиентских запросов. Для того чтобы этого не случалось, каждый механизм машинного обучения снабжается техникой по оптимизации эталонной модели. Могут использоваться следующие техники:
· интерфейс ручной корректировки модели;
· привлечение “учителя” для машинного обучения;
· эвристический анализ запросов нарушающих текущую модель, с последующей её оптимизацией.
Машинное обучение -- это сложный совокупный процесс, необходимость в конфигурировании которого может зависеть как от количественных показателей трафика, так и от качественных характеристик веб-приложения. Например, может возникнуть потребность в конфигурировании:
· математических параметров алгоритма обучения.
Машинное обучение может быть разработано для построения модели:
Так же, в зависимости от обучения, модель может содержать различные объекты, в типичной реализации оптимально считается содержать:
· параметры прикладных сущностей (HTTP, XML/JSON entity);
Сигнатурный анализ -- одна из самых старых и востребованных технологий обеспечения защиты приложений. Связано это с тем, что атаки на веб-приложения в большинстве случаев производятся на основе уже известных уязвимостей с использованием готовых инструментальных средств. Причем интенсивность таких атак в открытом интернете настолько велика, что публичные веб-приложения подвергаются им практически ежеминутно. В теории механизм защиты, основанный на машинном обучении и составляющий эталонную модель, перекрывает необходимость использования сигнатурного анализа. Некоторые производители экранов веб-приложений в связи с этим отказываются от концепции наработок сигнатур. Однако есть ряд ситуаций, когда данный механизм защиты крайне полезен -- например, в период обучения эталонной модели сигнатуры являются дополнительным рубежом защиты от эксплуатирования известных уязвимостей. Кроме того, запросы, которые были признаны нелегитимными, не подаются на вход процессу машинного обучения, что делает обучение более чистым. Экран веб-приложений должен обладать широкой и актуальной базой сигнатур для всех разновидностей веб-приложений. Более того, производителю желательно содержать собственный исследовательский центр, который будет агрегировать актуальные угрозы, чтобы своевременно формировать обновления.
Специализированные механизмы защиты Эффективность фильтрующих средств защиты существенно зависит от степени перекрытия одних и тех же угроз различными механизмами. Объясняется это тем, что всегда существует некоторая вероятность, в пределах которой исследуемые атаки могут остаться незамеченными для конкретного алгоритма защиты. Вероятность обнаружения атаки, если ее исследуют множество различных алгоритмов, резко понижается. Это наглядно демонстрируется при попытках теоретически спроектировать обход механизмов защиты экрана веб-приложений. К примеру, рассмотрим упоминавшийся ранее механизм защиты «машинное обучение эталонной модели». Он не гарантирует защиты в том случае, если возможно произвести атаку, контекст которой лежит в заданных пределах отклонения от эталонной модели. Происходит это потому, что данный механизм защиты не имеет возможности определить тип воздействия на веб-приложение. Тип нелегитимного воздействия может определяться с помощью сигнатурного анализа, однако атака, использующая 0day-уязвимость, с легкостью преодолеет такой защитный механизм. Таким образом возможность появления ложно-негативных событий для каждого из механизма защиты вполне осязаема, тогда как вероятность угрозы проведения атаки, которая будет комбинировать несколько условий обхода различных механизмов защиты, становится на порядок меньше. К примеру, комбинированным условием обхода двух выше рассмотренных механизмов защиты является атака, эксплуатирующая 0day-уязвимость, контекст которой не нарушает отклонения от эталонной модели машинного обучения. Для снижения вероятности ложно-негативных событий современные экраны веб-приложений не ограничиваются комбинированием двух вышерассмотренных механизмов защиты. Их количество может достигать нескольких десятков, но в отличие от механизма машинного обучения задача исследования этих алгоритмов существенно более узка; зачастую она сводится к обнаружению конкретного типа атак. Такие механизмы защиты носят названия по типу атаки на веб-приложение, которую они обнаруживают. В зависимости от реализации WAF они могут быть как-либо сгруппированы в общей политике безопасности или разнесены в отдельные ее части. Рассмотрим специализированные механизмы защиты, используемые современными экрана веб-приложений, для обнаружения наиболее распространенных атак на веб-приложения.
Возможность инъекции возникает, когда веб-приложение посылает недостаточно проверенные данные из запроса клиента на вход интерпретатору команд смежной функциональной системы, в общей информационной. Целью атаки могут быть следующие смежные системы: СУБД, операционная система, LDAP-сервер, XPath-интерпретатор и прочие. Это позволяет злоумышленникам манипулировать смежными функциональными системами. Обнаружение инъекции производится с помощью нескольких техник:
1. Токенизация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. Если валидные для синтаксиса целевой системы токены найдены, запрос клиента признается потенциально опасным.
2. Контроль ответов веб-приложения -- в ответах веб-приложения происходит поиск служебной информации целевой системы, попавшей туда вследствие неправильно обработанного вывода. При обнаружении такой информации в ответе он признается зловредным, а запрос -- нелегитимным.
3. Создается группа сигнатур, характеризующих попытки манипуляции с целевой системой. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным
Возможность нарушения управления сессиями возникает вследствие неправильной разработки данного функционала в веб-приложении. Позволяет злоумышленникам компрометировать идентификаторы сессий (например, cookies) с целью получить несанкционированный доступ к веб-приложению с правами другого пользователя. Обнаружение происходит за счет слежения за идентификаторами сессии.
1. Определение допустимых идентификаторов сессии. Если в запросе найдены ранее неизвестные идентификаторы сессий или значение этих идентификаторов отличается от допустимого значения, запрос признается нелегитимным.
2. Фиксация read-only идентификаторов сессии. При нахождении в запросе измененного идентификатора сессии, который по логике веб-приложения не может изменяться на стороне клиента, запрос признается нелегитимным.
3. Контроль клиентов на предмет подмены идентификаторов сессии. При нахождении в запросе идентификатора сессии, принадлежащего другому клиенту, запрос признается нелегитимным.
4. Определение попыток перебора идентификаторов сессии. При превышении объективно возможного порога запросов в секунду с разными идентификаторами сессий от одного клиента запросы признаются нелегитимными.
Также существуют техники проактивной защиты:
1. криптографическая подпись идентификаторов сессии;
2. шифрование идентификаторов сессии.
Возможность межсайтового выполнения сценариев возникает, когда веб-приложение формирует свой ответ из недостаточно проверенных данных из запроса клиента. Межсайтовое выполнение сценариев позволяет злоумышленнику красть идентификаторы сессий клиентов, производить дефейс веб-страниц, перенаправлять клиентов на другие ресурсы. Для защиты от XSS используются следующие техники.
1. Токенезация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. При нахождении валидных для синтаксиса языка программирования токенов запрос клиента признается потенциально опасным.
2. Внедрение Content Security Policy (CSP). CSP-заголовок -- относительно новый способ обеспечения безопасности HTTP-коммуникаций. Данный заголовок для каждого ответа определяет возможные источники ресурсов, из которых может состоять веб-страница, отображаемая браузером клиента. Некоторые WAF обладают техникой автоформирований правил CSP.
3. Анализ ответов. Содержание ответа сравнивается с принятыми из запроса данными. При обнаружении однозначных данных в паре запрос-ответ транзакция признается нелегитимной.
4. Внедрение в ответы веб-приложения специального JavaScript-кода, контролирующего отображение страницы в браузере клиента, особенно эффективно при определении DOM-based XSS.
5. Создается группа сигнатур, характеризующих попытки межсайтового исполнения сценариев. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.
Возможность незащищенного прямого обращения к объектам возникает, когда веб-приложение не имеет системы управления доступом для публикуемых объектов. Данная атака позволяет злоумышленникам получить несанкционированный доступ к информации. Для определения наличия уязвимости к данной атаке используются следующие техники.
1. Определение попыток перебора объектов. При превышении объективно возможного порога запросов объектов в секунду от одного клиента запросы признаются нелегитимными.
2. Контроль переходов по веб-страницам. При обнаружении запросов объектов, ссылки на которые не были предоставлены в предшествующем ответе, запрос признается нелегитимным. Существуют более сложные реализации данной техники, сводящиеся к построение графу допустимых переходов.
3. Создается группа сигнатур, характеризующих попытки прямого обращения к объектам. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.
Возможность эксплуатирования небезопасной конфигурации возникает, когда системные администраторы и разработчики не меняют стандартные настройки компонентов информационной системы. Или же они по причине своей некомпетентности иногда вносят не рекомендованные c точки зрения безопасности настройки. Данная атака позволяет злоумышленнику полностью компрометировать систему.
Для определения ошибок конфигурирования информационных систем на базе веб-приложений существует целый класс средств защиты «Сканеры уязвимостей». Они, используя статический, динамический и интерактивный анализ, определяют возможные уязвимости в веб-приложениях; особенно хорошо они определяют уязвимости, реализации которых строятся на неправильной конфигурации. Обосновывается это простотой поиска таких ошибок автоматизированными мерами. Отчеты сканеров уязвимостей возможно загрузить в экране веб-приложений и реализовать алгоритм «виртуального обновления» -- данный механизм защиты самостоятельно сформирует необходимые правила защиты от найденных уязвимостей.
Возможность утечки критичных данных появляется в случае, когда разработчики веб-приложения не закладывают выделенные для критичных сведений меры по защите информации: сильная криптография, дополнительная аутентификация, управление доступом. Злоумышленник, проэксплуатировавший такую уязвимость, получает доступ к критичной информации.
Для ее обнаружения в ответах веб-приложения происходит поиск
Критерии оценки экрана веб-приложений дипломная работа. Программирование, компьютеры и кибернетика.
Реферат: Классификация антивирусных средств
Мәңгілік Ел Болу Үшін Эссе
Курсовая работа по теме Анализ проведения деловой оценки персонала на ООО 'Ювелир-Карат'
Сочинение По Тексту Логинова
Бунты Xvii Века Историческое Сочинение
Реферат: Overview Of The Four Main Women Characters
Курсовая работа: Традиции ислама
Сердце Его Строение И Функции Реферат
Реферат по теме Маралий корень (левзея сафлоровидная)
Крузенштерн Реферат По Географии Для 5 Класса
Реферат: Значение петровских реформ для развития русской культуры. Оценка петровских реформ в истории отечественной общественной мысли
Реферат Окружающий
Курсовая работа по теме Особенности Я-концепции подростков с игровой компьютерной зависимостью
Реферат На Тему Сутність Римського Права
Список Коротких Рассказов Для Итогового Сочинения
Курсовая работа: Экологическая структура населения жужелиц (Caleoptera, Carabidae) плодовых садов
Будет Ли Отмена Итогового Сочинения 2022
Реферат по теме Хозяйственный учет и возникновение двойной бухгалтерии
Курсовая работа по теме Технологія вирощування баклажанів у відкритому ґрунті та організація їх продажу
Курсовая работа: Анализ финансового состояния предприятия по материалам торгового дома Валенсия
Ритуалы и предрассудки и способы их языкового выражения - Культура и искусство курсовая работа
Проблема розширення Європейського Союзу на сучасному етапі розвитку міжнародних відносин - Международные отношения и мировая экономика курсовая работа
Судебное разбирательство - Государство и право курсовая работа