Лекция
Это окончание невероятной информации про web-приложения.
...
определенный
контроль, есть три дополнительных пути мониторинга web-приложений, каждый из которых
позволяет по-новому взглянуть на активность приложения:
• Сетевой мониторинг. Мониторинг сетевой активности между пользователями и webсервером. Эта категория включают WAF, системы обнаружения вторжений, анализаторы
пакетов и другие внешние инструменты. Инструменты общей сетевой безопасности и
другие инструменты для сниффинга могут перехватывать весь сетевой трафик, но они имеют
небольшую совместимость и не могут выделить из общего трафика специфические пакеты
web-приложения. Просто просмотра трафика недостаточно для того, чтобы понять, что
пользователи пытаются сделать в приложении – требуется интерпретация. Если же решение
умеет анализировать специфический трафик web-приложений и способно проводить
аудит активности сети, то мы называем такое решение Web Application Monitoring (WAM
– Мониторинг web-приложения). Мониторинг сети легко интегрировать, так как он не
требует внесения изменений в приложение, и он может только просматривать исходящий и
входящий трафик приложения. Это может быть полезно для выявления традиционных атак
стека приложений, но гораздо менее полезно, когда трафик коррелируется с операциями
более высокого уровня.
• Аудит приложений и сбор логов. Сбор и анализ логов и внутренней активности приложения.
Приложения собственной разработки, равно как и сторонней, чаще всего имеют возможности
по внутреннему аудиту и сбору логов, но все они отличаются по принципу сбора, принципу
описания событий и формату записей. При этом вы все равно можете не получать полной
картины того, что происходит в приложении, так как вы ограничены лишь теми данными,
которые были добавлены в механизм логирования программистами. Для крупных и
распространенных корпоративных приложений, таких как SAP, мы уже видели сторонние
инструменты, которые позволяют добавить в них мониторинг или механизмы интерпретации
внутренних логов. Общие инструменты логирования и SIEM также могут быть использованы
для сбора и интерпретации событий (с определенными ограничениями) активности webприложений, при условии генерации журналов событий.
• Database Activity Monitoring (DAM – мониторинг активности базы данных). DAM используют
разныеметодыдлярегистрациисобытийсвязанных собращениямивбазуданныхигенерации
предупреждений при нарушении политик. Благодаря мониторингу активности между webприложением и базой данных (или внутри нее) DAM может обеспечить более точное
изучение и использование данных, а также предоставить дополнительную информацию
о взаимодействии в рамках системы при многоступенчатых транзакциях в рамках бизнеспроцессов. Некоторые DAM имеют плагины для основных типов приложений (например, SAP
и PeopleSoft) для интерпретации событий базы данных в события активности приложения.
Учитывая активное взаимодействие подавляющего большинства web-приложений с базами
данных, этот подход к мониторингу является достаточно эффективным для отслеживания
активности и поиска нарушений политик безопасности.
WAF может использоваться для мониторинга, но специализированные средства предоставляют
больше возможностей по контролю активностей и позволяют выявить недостатки и нарушения,
которые не являются очевидными только при контроле HTTP-трафика. Фокус WAM сосредоточен
на источниках данных, их анализе, регистрации активности и генерации предупреждений о
подозрительных событиях, в то время как WAF больше направлен на выявление и блокирование
уже известных атак. Имеются значительные отличия между WAF и WAM в таких областях как
хранение активностей, агрегирование данных из различных источников и их анализ, а потому
выбор лучшего решения зависит от специфических требований. Также стоит отметить, что
решения по мониторингу web-приложений пока еще трудно назвать зрелыми – большая их часть
находится на раннем этапе эволюции.
WAF + Оценка уязвимости
Некоторые вендоры уже начали предлагать гибридные решения, которые объединяют в себе
функционал продуктов для оценки уязвимости и WAF. Как уже упоминалось ранее, одной из
сложностей при временном блокировании определенных уязвимостей с помощью WAF, является
выявление этой уязвимости создание сигнатуры для ее блокирования. Объединив инструменты
дляоценки сWAF мы можем автоматизировать процесс созданияи применения новых политик при
выявлении новой уязвимости. Такая модель подразумевает выявление уязвимости и мгновенную
передачу данных WAF для того, чтобы тот мог заблокировать определенные возможности.
В этом разделе мы попытаемся объединить все части касающиеся безопасности web-приложений
и сделать некую инструкцию, которая позволит вам разработать систему безопасности
подходящую для вашей организации. Безопасность web-приложений – это не тот случай, когда
есть универсальный рецепт. Риски, размер и сложность приложений у всех разные, равно как
и информированность о вопросах безопасности пользователей и сотрудников, а самое главное
цели использования web-приложений у каждой организации свои.
Для того чтобы дать какие-то практические рекомендации, мы должны подходить к разработке
web-приложения с точки зрения неких типичных задач. Поэтому мы выбрали три сценария для
представления общих проблем с безопасностью web-приложений, с которыми сталкиваются
компании, и рассмотрим каждый их них через призму системы безопасности. Мы обсудим
web-приложения большой корпорации, ориентированные на работу с внешними пользователями,
первое приложение средней по размеру компании, а также организации больше среднего
размера, задача которой состоит в обеспечении защищенности внутреннего web-приложения.
Сначала мы опишем среду для каждого приложения, а затем опишем общую стратегию и
конкретные рекомендации.
Крупная компания с web-приложениями ориентированными
на взаимодействие с внешними пользователями.
В первом сценарии мы рассмотрим крупную компанию с несколькими ориентированными на
внешних пользователей web-приложениями. Они разрабатывались для того чтобы стать единой
точкой взаимодействия с клиентами, сотрудниками и бизнес-партнерами. Основными драйверами
безопасности в данном случае являются: противодействие мошенничеству, соответствие
требованиям регуляторов и обеспечение отказоустойчивости для обеспечения непрерывности
бизнес-процессов. Вторичные драйверы: сохранение репутации, готовность к атакам, сохранение
активов и данных, а также снижение расходов на содержание. Главный вопрос здесь не в
необходимости обеспечения безопасности, а в том какими средствами этого добиваться. Большая
часть корпоративных приложений имеют серьезные недостатки в коде и, если быть полностью
честными, то основные задачи в данном сценарии в том, чтобы минимизировать риски, которые
несут эти недостатки. Ни один продукт “с прилавка”, разработанный сторонними специалистами,
не сможет волшебным образом решить все имеющиеся проблемы безопасности, поэтому
вам необходимо инвестировать не только, но и в совершенствование собственные процессы
разработки, чтобы с каждым новым релизом приложения становились все лучше с точки зрения
безопасности.
Предположим, что наша выдуманная крупная компания имеет существующую систему
безопасности, команду разработчиков с некоторой степенью зрелости в понимании вопросов
безопасности, но вопрос решения проблем даже в такой ситуации не бесспорен. У компании уже
может быть специалист по безопасности в штате, но в процессе разработке еще не выстроены
процессы оценки безопасности и идентификации проблем. Типичный специалист по безопасности
чаще всего исходит из своего опыта защиты сетей и не имеет опыта безопасной разработки и не
уделяет особого внимания коду web-приложений. Будем считать, что система безопасности
включает использование инструментов по оценке уязвимости, и они проверяют код на базовые
атаки с использованием SQL-инъекций и атак на переполнение буфера. В целом безопасность
обеспечивается силами пары сторонних продуктов и усилиями специалиста по безопасности,
указывающего на недостатки в безопасности, которые исправляются в будущих обновлениях.
Рекомендации
Стратегия в данном случае сводится к необходимости включения вопросов безопасности на
уровне разработки, сместив акцент с внешних продуктов на внутренние продукты и обучение
персонала. Инструменты выбираются и приобретаются для решения конкретных недостатков
в навыках команды разработчиков и организационных процессах. WAF используется для того,
чтобы обеспечивать безопасность на время разработки обновлении, закрывающих выявленные
уязвимости.
Обучение и отладка процессов. Область, которая даст максимальный эффект в виде повышения
уровня безопасности – это улучшение знаний и навыков команды разработчиков. Главные
недостатки, отмечаемые OWASP, а также другими источниками, указывают на проблемы, которые
могут быть решены путем надлежащего написания кода и тестирования… но только в том случае,
если команда разработчиков знает что и как нужно делать. Обучение помогает разработчикам
выявлять ошибки и проблемы в коде и эффективно снижает количество недостатков в каждом
последующем цикле разработки. В развитии персонала можно сосредоточиться на повышении
навыков всех разработчиков, а не полагаться на одного или двух выделенных специалистов,
которые будут сосредоточены на анализе безопасности.
Безопасный цикл разработки приложений. Должен стать одним из приоритетных требований
при разработке приложения, включая в себя определенные требования к коду, проверке и
тестированию на разных этапах разработки web-приложения. В противном случае добиться
должного уровня будет невозможно, так как все силы будут брошены на доработку возможностей
и функционала. Безопасность должны быть частью спецификации продукта и требований к нему,
а каждая фаза разработки должны завершаться проверкой на соблюдение этих требований и
соответствие спецификации. Это означает, что тесты на безопасности в процессе разработки
должно выполняться так же, как и тестирование перед выпуском релиза. Обученные разработчики
вполне могут обеспечить анализ кода и разработать тестовые сценарии для проверки, но
дополнительные инструменты для автоматизации процессов тестирования и задач по проверке
все же необходимы.
Наследуемый код приложения. Есть решение проблемы наследуемого кода. Одной из
серьезных проблем – это наследуемый код, который, вполне вероятно, имеет проблемы с
безопасностью. Есть несколько вариантов решения этой проблемы, но основными шагами в
любом случае будут: 1) Выявление недостатков и проблем в коде (сканирование кода, оценка
уязвимости и тестирование на проникновение), 2) Расстановка приоритетов по исправлению
выявленных недостатков, 3) Планирование по устранению каждой найденной уязвимости.
Общие методы исправления уязвимостей включают: 1) Переписывание сегментов кода, 2)
методы инкапсуляции (например, интерфейс), 3) Дополнение существующего кода путем
создания процедур проверки путей/методов во время исполнения, 4) временное защита при
помощи настройки политик WAF, 5) Перемещение SQL-процессов и проверок в базу данных, и 6)
прекращение использования небезопасных функций. Мы рекомендуем использовать статические
или динамические инструменты для первоначальной проверки кода. Эти инструменты являются
экономически целесообразными, подходят для сканирования больших объемов кода и позволяют
достаточно эффективно выявить ошибки. Они обнаруживают и приоретизируют недостатки,
позволяя избежать пользовательских ошибок, которые неизбежны при ручном сканировании.
Инструменты для анализа также позволяют персоналу получить некоторые дополнительные
знания об уязвимостях, в том числе с примерами на разных языках. Полученные в результате
аргументы о 16 тысячах небезопасных вхождений IFRAME – это, конечно, не весело, но придется
принять и понять проблему, прежде чем она будет решена.
Внешние проверки. Периодические внешние проверки – оценка уязвимости, тестирование на
проникновениеипроверкаисходногокода –настоятельнорекомендуются. Опытныенепредвзятые
специалисты, имеющие опыт в анализе угроз, могут выявить те недостатки, которые были
пропущены во время внутренних сканирований, а также могут помочь в обучении разработчиков
иным векторам атак. Запланируйте внешнее тестирование на проникновение один раз в квартал
или полугодие – знания и опыт хороших консультантов выходит далеко за рамки основных
угроз, а потому их работа с приложением поможет выявить даже неочевидные уязвимости,
которые могут быть использованы злоумышленниками. Мы также рекомендуем использовать
инструменты статического анализа для внутренней проверки кода в рамках прохождения
тестов контроля качества и внутренним тестированием на проникновение непосредственно
перед развертыванием – это позволит провести стресс-тесты приложения без страха вывести
из строя “боевое” приложение. Крупные обновления также должны пройти внешний тест на
проникновение до того как будут установлены.
Блокирование. Это одна из областей, необходимость в которой напрямую зависит от специфики
вашей организации. В случае с корпоративным приложением в использовании WAF является
очень важной частью системы безопасности. Он обеспечивает базовую защиту и дает сотрудникам
возможность спокойно и без паники разбираться с выявленными уязвимостями в действующей
системе. Конечно, возможен вариант, что объем кода вашего приложения не очень велик и
особой потребности в WAF нет, но для больших компаний WAF это не опция, а обязательная
части системы защиты web-приложения. Циклы разработки и обновления приложения в таких
компаниях слишком долгие, чтобы можно было обеспечить быструю реакцию на найденную
новую уязвимость. Мы рекомендуем использовать гибридные модели, которые обеспечивают
функции WAF и оценки уязвимости, потому что такая комбинация позволяет значительно
облегчить разработку и внедрение новых политик для WAF. WAF – это недешево, поэтому мы
не можем рекомендовать его использование всем. Но все же, именно этот инструмент обладает
гибкостью и позволяет бороться не только с существующими, но и будущими угрозами.
В общем, мы рекомендуем вам принять меры для повышения уровня безопасности в каждой
части процесса разработки и развития приложения. Фокусировка на совершенствовании
начальных этапов разработки приложения (выработка требований, архитектура, дизайн) принесут
наибольшее количество пользы с точки зрения безопасности. Для приложений, которые уже
эксплуатируются, мы рекомендуем введение внешних проверок и, если бюджет позволяет,
использование WAF. Оценка уязвимости и тестирование на проникновение имеют наиважнейшее
значение, независимо от того, новое это приложение или нет, а WAF очень важен для быстрой
реакции на выявление новой уязвимости. Учитывая, что риски крупных предприятий выше, а
решение любой проблемы сложнее, важно понимать, что и инвестиции в безопасность должны
быть серьезными. Требования безопасности, а также их изменения должны быть официально
зафиксированы для каждой стадии жизненного цикла приложения – а проверка выполнения этих
требований проводится на каждом значимом этапе.
Компания среднего размера и соответствие требованиям PCI
Если мы говорим о безопасности web-приложений и наличии каких-либо требований, то стоит
обратиться к Payment Card Industry’s Data Security Standard (PCI-DSS). Фактически это единственный
стандарт, определяющий специфические требования к безопасности web-приложений. Мы,
конечно, можем ворчать о неоднозначности этих требований и способах их улучшить, но не
можем не признать, что PCI в данный момент является главным драйвером для безопасности
web-приложений на сегодняшний день. Поэтому в качестве второго сценария мы взяли
компанию средних размеров, которой необходимо обеспечить соответствие их web-приложения
требованиям данного стандарта.
Профиль этой нашей компании – торговля. Большая часть прибыли генерируется посредством
онлайн-продаж. Коммерческий web-сайт относительно новый (менее 3 лет), а команда
разработчиковдостаточномалаинеимеетдостаточноспецифическихнавыковвинформационной
безопасности. То есть понимание ньюансов хакерских атак не является их сильной стороной.
Соответствие PCI является основной задачей, хотя понятно, что кроме выполнения основных
требований есть необходимость и в защите от некоторых видов атак. Позитивные моменты:
объем кода web-приложения невелик и, так как большая часть прибыли генерируется именно
посредством web-приложения, руководство всячески поддерживает инициативы по повышению
уровня защищенности.
В двух словах, стандарт PCI-DSS – это стандарт безопасности для компаний, обрабатывающих
транзакции платежных карт в рамках интернет-коммерции. С точки зрения правил безопасности
– это самые однозначные и понятные требования, включающие специфические требования к
средствам обеспечения безопасности и процессам работы с данными платежных карт. При этом
имеется у стандарта и определенная гибкость, которая выражается в необходимости соответствия
духу требований. То есть, если ваши решения и отличаются от рекомендованных PCI-DSS, но
они обеспечивают должный уровень безопасности, то они имеют право на одобрение. Мы
сосредоточимся на выполнении требований указанных в пунктах 6.6 и 11.3, но также будет
обращаться к разделу 10 и компенсирующим элементам управления.
Рекомендации
Наша стратегия будет сфокусирована на образовании и изменении процессов разработки для того
чтобы включить безопасность в цикл разработки. Дополнительно мы предлагаем использовать
услугу тестирования на проникновение, что позволит быстрее выявить проблемные области
web-приложения. Для начала сфокусируйтесь на выполнении требований, а уже затем можно
подумать о вариантах развития защиты на случай роста компании. Не бойтесь пользоваться
сторонней помощью для решения разных задач, это касается и выполнения требований PCI, и
общих вопросов безопасности приложений.
Тренинги, образование и улучшение процессов. Опять же, максимальный упор мы делаем
на образование и тренинги для персонала, в том числе для менеджмента проекта. Несмотря
на то, что это требует достаточно солидных временных затрат, он позволяет ощутимо повысить
уровень безопасности и является эффективным с экономической точки зрения (за счет улучшения
качества кода, что снижает затраты на доработку в перспективе). Правильно написанный код не
требует исправлений в дальнейшем. Кроме того, процесс улучшения кода будет постоянным, что
позитивно скажется не только на безопасности, но и на качестве приложения в целом. В общем,
если кода не много, то именно образование и тренинги являются лучшим путем для относительно
небольшой компании и принесут максимум преимуществ.
Внешняя помощь. Подружитесь с аудитором или наймите его в качестве консультанта, который
поможет подготовить и провести проверку на соответствие PCI-DSS. Аудитор не просто даст
специфические рекомендации по отдельным требованиям PCI, он предоставит экспертную оценку,
поможет в толковании некоторых неоднозначных моментов, окажет содействие в разработке
стратегии и убережет от необдуманных и неэффективных трат.
Раздел 11.3.2. 11.3 Тестирование на проникновение сети и web-приложения. В данном сценарии
мы рекомендуем внешнее тестирование на проникновение – не только потому, что это
требование стандарта DSS, но также потому, что независимый эксперт изучит ваше приложение
позиции максимально близкой к хакерской. Тем более в дальнейшем ограниченный бюджет
наверняка заставит выбирать между WAF и анализом кода в пункте 6.6, и тестирование на
проникновение поможет сделать вам правильный выбор. Если же анализ кода уже проводится,
то можно утверждать (возможно, безосновательно), что он является некой компенсирующей
мерой, позволяющей выполнить требования данного раздела, но мы все равно рекомендуем
использовать тестирование на проникновение. Внешнее тестирование дает гораздо больше,
чем список специфических уязвимостей, предлагая также идентификацию рисков и выявление
сомнительного поведения приложения.
Раздел 6.6. Наши самые большие споры касаются рекомендации использования WAF или
анализа кода для удовлетворения требований PCI, указанных в разделе 6.6. Фактически стандарт
рекомендует использовать и то и другое, но широко известно, что это весьма дорого. Покупка
WAF – это быстрый путь удовлетворить требования раздела 6.6, обеспечив базовый мониторинг
и базовую платформу для блокирования атак в будущем. Но контраргументов у этого варианта
достаточно – это и уже упомянутая и цена и достаточно сложную и кропотливую работу по
настройке политик. С другой стороны, анализ кода квалифицированным специалистом по
безопасности поможет выявить слабые места в коде приложения, а также помочь в обучении
команды разработчиков указывая на конкретные недостатки. Внешний анализ позволяет быстро
оценить ситуацию, в которой вы находитесь, и понять что вам нужно для того, чтобы эту ситуацию
улучшить. К недостаткам анализа кода можно отнести стоимость работ, время необходимое для
выявления и исправления недостатков, а кроме того, постоянную изменяемость кода, которая
требует повторных проверок.
И все же мы рекомендуем выбрать WAF. Привлечение команды профессионалов по безопасности
для анализа кода – это, конечно, эффективный путь выявления недостатков, но его ценность
заметно снижается, ведь во многом схожие данные дают периодические тесты на проникновение,
необходимость проведения которых, как мы помним, отражена в разделе 11.3.2. Кроме того,
даже при относительно небольшом или среднем количестве кода, время на коррекцию всех
недостатков может оказаться достаточно большим, что не позволит пройти аттестацию на
соответствие требованиям PCI в достаточно сжатые сроки. Обратите внимание, что данная
рекомендация действительна только для данного сценария. При других исходных данных, к
примеру, при наличии более опытного персонала и изначально лучшего качества кода, мы могли
пойти совсем по другому пути для достижения необходимого результата.
Мониторинг.Мониторингактивностибазыданных(DAM)–этохорошийвыбордляудовлетворения
требований раздела 10, в соответствии с которым необходимо обеспечить полный мониторинг
доступа к данным платежных карт. Web-приложения используют реляционную базу данных для
хранения номеров платежных карт, транзакции и другие связанные с ними данные. Продукты
класса DAM охватывают всю сетевую и консольную активность на платформе базы данных и
обеспечивают целенаправленный и экономически эффективный контроль на всех уровня
доступа к данным кредитных карт. Рассмотрите именно этот вариант, который будет хорош как
для аудиторов, так и для специалистов по безопасности.
В нашем последнем сценарии мы рассмотрим внутреннее web-приложение, предназначенное
для партнеров и сотрудников в рамках среднего или крупного бизнеса. Хотя это и не выглядит как
серьезная проблема, но даже для компании со штатом в 100 человек, внутреннее web-приложение
можетбытьвесьмакритичнойточкойсточкизрениябизнеса. Используяданныерабочегопроцесса,
HR, бухгалтерского учета, продаж и других критичных IT-систем, эти приложения обеспечивают
эффективную поддержку сотрудников и партнеров компании. Учитывая доступность из webприложения почти всех данных компании, обеспечение их конфиденциальности и целостности
является очень важной задачей. Общее мнение относительно защиты таких систем чаще всего
сводятся к тому, что они находятся внутри периметра, а потому не подвержены типичным атакам,
но это мнение довольно части приводит к катастрофе. Ведь в том случае, если злоумышленник
преодолеет внешний барьер (или окажется инсайдером), то приложение будет практически
беззащитным. То есть, не стоит полагаться лишь на сетевую безопасность, необходимо обеспечить
хотя бы базовый уровень защиты самого web-приложения и контроль доступа.
Определить базовый уровень защитыприложения,исправить серьезные уязвимости,максимально
использовать преимущества обучения, тренингов и усовершенствования процесса написания
кода, для того чтобы повысить его качество.
Оценка уязвимости и тестирование на проникновение. Сканирование web-приложений для
оценки уровня защищенности, проверки установки обновлений и недостатков в конфигурации
– это первый из рекомендованных шагов, который позволит выявить основные уязвимости.
Инструменты оценки защищенности являются самым экономически эффективным путем для
определениябазовойбезопасностиивывода ее на приемлемыйуровень. Тесты на проникновение,
традиционно могут помочь в оценке потенциальных рисков и расстановке приоритетов при
исправлении выявленных уязвимостей.
Образование тренинги и совершенствование процессов. В данном сценарии эти возможности
станут, пожалуй, даже более актуальными, чем в других, хотя бы потому, что бизнесу труднее
найти обоснования для инвестиций в безопасность приложения, чем в случае с внешними
приложениями.
Мониторинг. Контроль и выявление подозрительной активности – это доступный, но эффективный
способ выявления проблем. Мы считаем, что WAF в таком случае будет слишком дорогим
решением, а потому настоятельно рекомендуем более экономически эффективный способ сбора
и анализа активности. Программное обеспечение для мониторинга, которое подключается к
web-приложению, зачастую может быть очень эффективным и стоить вполне разумных денег, но
бремя анализа всех собираемых данных в данном случае ляжет на вашу команду разработчиков.
Мониторинг активности баз данных может быть эффективен для защиты критической информации
в бэк-енде и это более разумный выбор, нежели WAM.
Наши рекомендации на самом деле весьма специфичны и сильно зависят от особенностей
организации и ситуации с web-приложениями. Мы выбрали сценарии для того чтобы
продемонстрировать мотивирующие факторы в сочетании с текущим состоянием защищенности
web-приложения и руководством по выбору инструментов услуг и изменением внутренних
процессов. Но так как приложения поддерживают значительное количество бизнес-функций,
процесспоповышениюуровнюзащищенностидолженпроходитьприсодействииимаксимальном
внимании со стороны не только технического персонала, но и ответственных за бизнес-процессов,
а также менеджера проектов. Это, без сомнения осложнит процесс, но движение вперед должно
происходить только при понимании и поддержке всех заинтересованных лиц.
В любом случае мы должны помнить, что безопасность это часть общего процесса развития, и
наша главная рекомендация для любого сценария – это стремится обеспечить максимальную
экономическую эффективность и стараться минимизировать риски сбоя или любого отклонения от
нормальной работы. Также важно помнить, что преобразование web-приложения не произойдет
в одночасье. Мы не можем себе позволить такую роскошь, как остановка всех обновлений в
ожидании момента, когда команда разработчиков исправит все недостатки в безопасности, а
потому не нужно забывать, что сторонние продукты и услуги могут оказать неоценимую помощь
для решения насущных проблем.
Исследование, описанное в статье про web-приложения, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое web-приложения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Криптоанализ, Виды уязвимости и защита Информации
Часть 1 Web-приложения. Безопасная разработка , развертывание и использование
Часть 2 Инструменты статического анализа - Web-приложения. Безопасная разработка , развертывание и
Часть 3 Подводим итоги - Web-приложения. Безопасная разработка , развертывание и использование
Комментарии
Оставить комментарий
Криптоанализ, Виды уязвимости и защита Информации
Термины: Криптоанализ, Виды уязвимости и защита Информации