Как защитить веб приложение

Обновлено: 06.01.2025

Любой ответственный владелец сайта или его администратор знает об онлайн-безопасности. И даже если кажется, что сейчас всё в порядке, потому что вы позаботились об этом несколько лет назад, скорее всего, вы ошибаетесь. Технологии ушли далеко вперёд, а с ними и повысилась уязвимость веб-ресурсов.

К примеру, об этом свидетельствует факт атаки на крупного провайдера Dyn в октябре 2016 года. Тогда десятки крупных платформ и сервисов оказались недоступны. Как считают аналитики, количество DDoS-атак будет расти в течение следующих лет.

Тотальных способов защиты нет, но можно снизить риск. Здесь собрано 10 наиболее важных рекомендаций по безопасности веб-приложений. Обязательны к ознакомлению.

У вас вряд ли получится долгое время поддерживать безопасность ресурса, если вы не проработаете план обеспечения его защиты. Если у вас есть специалисты по безопасности, обсудите с ними наиболее приоритетные разделы защиты и займитесь устранением уязвимостей.

Следует определить, кто будет проверять исполнение плана, плюс методы обеспечения безопасности. Будет оно выполняться вручную, с помощью облачных решений, или стоит заняться разработкой собственной системы?

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

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

Как много инструментов используется в работе компании? Не знаете? А зря: вероятно, вы тоже используете не совсем "чистые" приложения. Они незаметны до тех пор, пока всё работает хорошо. Рассчитывать на эффективную защиту, не зная точно, какие приложения использует ваша компания, опасно.

На этот этап выделите время и сотрудников. Во-первых, программ может быть много. Во-вторых, некоторые из них работают скрыто. В-третьих, нужно разобраться, какие на самом деле можно использовать, а какие стоит сносить сразу. Советуем определить цель каждого приложения: так заодно можно почистить безопасные, но ненужные. Этот шаг важен ещё и тем, что другие будут в той или иной степени завязаны на него.

После инвентаризации существующих веб-приложений идет их сортировка в порядке важности. Разделите приложения на 3 категории: критические, важные, обычные.

Критические приложения − сюда входят те, что загружены извне и содержат информацию о клиентах. Ими нужно управлять в первую очередь, так как они наиболее интересны хакерам.

Важные приложения − приложения могут быть внутренними или внешними и содержат конфиденциальную информацию.

Обычные приложения − не подвержены серьёзным уязвимостям, но стоит иметь в виду как потенциальный источник утечки.

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

Устранить все уязвимости из всех веб-приложений нереально! Не тратьте на это время. Даже после классификации ваших приложений в соответствии с их важностью потребуется много времени для их тестирования.

Так на каких уязвимостях сосредоточиться? А это зависит от приложений, которые вы используете. Универсальных методов здесь тоже нет, но в следующих разделах мы расскажем о базовых принципах определения критических уязвимостей.

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

Даже после того, как все ваши веб-приложения будут оценены, протестированы и очищены от наиболее проблемных уязвимостей, процесс обеспечения защиты ещё не будет окончен. Каждое веб-приложение имеет определенные разрешения как на локальных, так и на удаленных компьютерах. Они должны быть проанализированы и скорректированы для повышения безопасности.

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

Что делать, если администратор заблокирует нужную функцию? Придётся сообщить ему об этом, объяснить, зачем функция нужна, подождать, пока он снова её активирует. Да, это долго, зато безопасно.

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

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

Момент, который организации пропускают при изучении рекомендаций по обеспечению безопасности веб-приложений, − использование файлов cookie. Они удобны как компаниям, так и пользователям, потому что позволяют запоминать пользователей по сайтам, которые они посещают. Но хакеры могут манипулировать такими файлами, чтобы получить доступ к защищенной информации.

Хотя вам, разумеется, не нужно прекращать использование файлов cookie. Просто измените настройки, чтобы минимизировать риск атак.

Во-первых, никогда не используйте куки для хранения конфиденциальной или критически важной информации − для запоминания паролей пользователей, так как это позволяет хакерам невероятно легко получить несанкционированный доступ.
Кроме того, следует ограничить срок действия файлов cookie. Месяца вполне достаточно.
Наконец, рассмотрите возможность шифрования информации, хранящейся в используемых вами файлах cookie.

Есть еще несколько советов по безопасности веб-приложений, которые стоит рассмотреть. Решите для себя, какие из мер ниже подходят вам, а какие не очень:

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

Обученные сотрудники смогут сами обнаруживать базовые уязвимости. Информирование всех о важности безопасности веб-приложений − это простой способ вовлечь всех в процесс поиска и устранения уязвимостей. Наймите специалиста или договоритесь с кем-нибудь внутри команды, чтобы разъяснить основные принципы безопасности.

Отличный способ получить обратную связь от сообщества − ввести программу вознаграждений. Даже если вы управляете компанией, в которой работают лучшие специалисты по безопасности, они могут не определить все потенциальные угрозы.

Такую практику реализуют и в крупных компаниях вроде Google, Microsoft или Amazon.

Как видим, поддержание передовых методов обеспечения безопасности веб-приложений − коллективная работа. Конечно, можно предпринять более простые шаги, которые в моменте закроют образовавшиеся проблемы. Однако по мере роста приложений, они становятся все более громоздкими для отслеживания, с точки зрения безопасности. Использование рекомендаций из статьи поможет обеспечить безопасность ваших приложений для пользователей в долгосрочном периоде.

Веб-приложения — неотъемлемая часть рабочего процесса большинства организаций — АБС системы банков, CRM, 1C и другие программы, которыми ежедневно пользуются сотрудники. Они аккумулируют в себе огромное количество данных, обладающих коммерческой ценностью. Поэтому способствовать обеспечению безопасности веб-приложений — одна из ключевых задач для минимизации финансовых и репутационных рисков бизнеса.

Зачем нужна защита web-приложений?

Безопасность веб-приложений — это защитные меры, при которых злоумышленник не сможет получить доступ к конфиденциальным данным как извне при попытке взлома, так и внутри компании через нелегитимный доступ.

А если инсайдером окажется привилегированный пользователь — он не сможет воспользоваться конфиденциальными данными, так как его нетипичное поведение будет расценено как аномалия, и об этом немедленно будет оповещена служба информационной безопасности.

Веб-приложения становятся финансово-привлекательными не только для их разработчиков, но и для желающих нелегально воспользоваться данными, хранящимися в них. Виды и число атак на них растут в геометрической прогрессии. Атаки можно условно поделить на две категории угроз ИБ:

нарушение конфиденциальности информации;

нарушение доступности информации.

Наиболее распространенная угроза безопасности web-приложений — это эксплуатация уязвимостей, а при популяризации приложения в интернете — не избежать и DDoS-атак. Для взлома и вывода приложения из строя могут использоваться различные инструменты как любительские, так и профессиональные кибератаки и использование автоматических систем сканирования для эксплуатации уязвимостей.

Первый шаг злоумышленника при попытках атак — сканирование с помощью различных утилит. Это может увидеть администратор по частому обращению с одного IP-адреса к разным страницам и большому числу ошибок 404. Поэтому безопасность веб-приложений начинается с непрерывного мониторинга.

Защита веб-приложений актуальна в любых условиях — в том числе и внутри периметра компании. В большинстве случаев доступ к ним имеют не только офисные работники, но и удаленные сотрудники, которые нередко заходят в них с личных компьютеров в обход VPN. И если не обеспечить непрерывный мониторинг доступа к запросам и ответам, может произойти утечка ценной информации.

Чем грозит утечка конфиденциальной информации из веб-приложения?
Риски делятся на две основные группы:

Например, «горячие» лиды из CRM могут быть перепроданы прямым конкурентам нечестным сотрудником. Утечка клиентской базы, в результате которой клиентские данные оказались в продаже на черном рынке или выложены в публичный доступ, подрывает доверие к организации и влечет ответственность в виде штрафных санкций регуляторов.

Поэтому использование веб-приложений в бизнесе и в работе с конфиденциальными данными невозможно без продуманной всесторонней защиты от всех типов существующих угроз и предиктивным подходом к безопасности.

Как обеспечить безопасность web-приложений?

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

Прямой способ защиты приложений — межсетевой экран или брандмауэр. Для большего числа веб-приложений применяется прикладной сетевой экран Web Application Firewall (WAF). Если же мы говорим о бизнес-приложениях, которые содержат базы коммерческих и персональных данных, — то здесь требуется другой тип защиты — брандмауэр баз данных Database Firewall (DBF). Это позволяет защитить конфиденциальные данные на разных уровнях.

Применение специализированных решений по информационной безопасности позволяет обнаружить и предотвратить атаки на прикладном и сетевом уровне и реализовать комплекс мер, чтобы обеспечить доступность и непрерывность работы web-приложений за счёт защиты от различных классов атак.

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

К основным мерам относятся:

проверка данных на соответствие стандартам протоколов;

контроль трафика на основе нейронных сетей;

защита от SQL-инъекций;

протекция от межсетевого скриптинга (XSS);

контроль доступа к конфиденциальным данным.

Внедрение программно-аппаратных комплексов снижает риски несанкционированного доступа к критичной информации и эксплуатации уязвимостей системного ПО. Более того, наличие специализированных решений по информационной безопасности позволяет обеспечить законодательные требования по защите персональных данных, а также банковских стандартов (СТО БР) и стандарта безопасности данных индустрии платежных карт PCI DSS в вопросах защиты веб-приложений.

Применение специализированных систем защиты web-приложений позволит своевременно обнаруживать и предотвращать попытки несанкционированных действий злоумышленников как внутри организации, так и извне.

Кроме выявления и блокировки атак для защиты данных в приложениях требуется непрерывный мониторинг доступа к базам данных и анализ поведения пользователей и систем. Эти функции обеспечивают решения класса DAM (database activity monitoring). Рассмотрим подробнее принцип работы таких решений.

DAM и DBF — классы систем для защиты веб-приложений

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

Согласно исследованию «Гарда Технологии», базы данных страховых и финансовых компаний оказываются на черном рынке преимущественно из автоматизированных систем, работающих через приложения. Риски утечек могут оцениваться в миллионы долларов. Прибавьте сюда штрафные санкции от регуляторов за нарушение закона о персональных данных и снижение уровня доверия клиентов. Поэтому игнорировать вопрос защиты веб-приложений при веде́нии бизнеса — опрометчивое решение.

Как говорили выше, чтобы защитить бизнес-приложения от современных угроз, одного WAF и сигнатурных средств недостаточно. Требуются специализированные решения для обеспечения безопасности баз данных. Средства по защите баз данных и веб-приложений относятся к классам Database firewall (DBF) / Database Activity Monitoring (DAM) – это аппаратно-программные комплексы для мониторинга, аудита и контроля доступа к информации и защиты от целевых атак на них. Есть решения, объединяющие в себе функциональные возможности по мониторингу, аудиту и защите от атак на базы данных.

В качестве основных функций систем DAM/DBF выделим следующие:

защита от внешних атак;

выявление уязвимостей БД;

обнаружение неучтенных конфиденциальных данных в базах приложений;

проверка данных на обезличенность при передаче;

тотальный контроль всех запросов к БД и настраиваемые политики безопасности;

построение профилей пользователей и выявление подозрительной активности;

автоматическое сканирование БД на наличие конфиденциальной информации;

расследование инцидентов безопасности;

предотвращение утечек данных.

Обеспечение информационной безопасности веб-приложений с помощью специализированных систем — это комплексная задача бизнеса и возможность нивелировать риски.

Отечественное решение для информационной безопасности веб-приложений

Первое российское решение для обеспечения безопасности веб-приложений классов DBF и DAM стал аппаратно-программный комплекс «Гарда БД» от производителя систем информационной безопасности «Гарда Технологии».

«Гарда БД» изначально разрабатывалась как система защиты баз данных и веб-приложений. И большинство практических кейсов как раз связано с CRM, 1C, банковскими АБС и другими приложениями, которые используются в ежедневной практике работы сотрудников.

Это система аудита и блокировки сетевого доступа к базам данных и бизнес-приложениям. За счет непрерывного мониторинга обращений к базам данных и веб-приложениям детектирует подозрительные действия в реальном времени.

Систему отличает скорость анализа трафика свыше десяти Гбит/с, что позволяет мгновенно реагировать на аномалии и информировать об этом службу безопасности, ни один подозрительный запрос или атака не останутся незамеченными.

АПК «Гарда БД» — прогрессивное решение, которое позволяет предотвратить инциденты уже по первым признакам аномального поведения пользователей и систем и обеспечить защиту web-приложений от всех видов угроз. Для тестирования системы в организации предусмотрен бесплатный пилотный проект. Уже за первый месяц работы системы удается предотвратить инциденты информационной безопасности в бизнес-приложениях.

Общедоступные веб-приложения интересны хакерам как ресурсы или инструменты заработка. Спектр применения полученной в результате взлома информации широкий: платное предоставление доступа к ресурсу, использование в бот-сетях и т. д. Личность владельца не важна, так как процесс взлома автоматизирован и поставлен на поток. Стоимость информации пропорциональна известности и влиятельности компании.

Если задаться целью, уязвимость в приложении найдётся. В отчете о хакерских атаках на сайты за 2018 год эксперты Google сообщили о том, что количество взломанных ресурсов увеличилось на 32% по сравнению с 2017 годом, и это не предел. Помните об этом и отбросьте заблуждения о неприступности своих веб-ресурсов, когда планируете работы по информационной безопасности.

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

Прежде чем искать уязвимости вручную проверьте приложение автоматизированными средствами. Они выполняют тесты на проникновение, пытаются его взломать, например, при помощи SQL-инъекции.

Ниже приведена подборка бесплатных инструментов.

Приложения и фреймворки

OpenVAS сканирует узлы сети на наличие уязвимостей и позволяет управлять уязвимостями.
OWASP Xenotix XSS Exploit Framework сканирует ресурс на возможность эксплуатации XSS-уязвимостей.
Approof от Positive Technologies проверяет конфигурацию веб-приложения, сканирует на наличие уязвимых компонентов, незащищенных чувствительных данных и вредоносного кода.

Онлайн-сервисы

Перед сканированием веб-приложения онлайн-сервисами обратите внимание на условия использования. Некоторые из них публикуют отчеты о проверенных сайтах в открытом виде.

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

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

Если на сайте есть страницы, которые доступны только после аутентификации, попробуйте выдать себя за другого пользователя. Для этого измените параметры URL (например, ID пользователя) или значения Cookie.

Обновляйте программное обеспечение

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

Если ресурс работает на базе движка стороннего производителя (CMS или форума), устанавливайте исправления безопасности сразу после выпуска. Большинство разработчиков информируют об обновлениях через рассылку или RSS-канал с описанием исправленных проблем. WordPress и Umbraco, кроме того, уведомляют о доступных обновлениях при входе в панель управления.

Многие разработчики используют менеджеры пакетов (например, Composer, NPM или RubyGems), чтобы устанавливать зависимые компоненты для приложений. В этих пакетах также обнаруживают уязвимости, поэтому следите за их обновлением. Чтобы автоматически получать уведомления о проблемах безопасности пакетов проекта, используйте инструменты вроде Gemnasium.

Предотвратите SQL-инъекции

SQL-инъекция представляет собой выполнение произвольного запроса к базе данных приложения с помощью поля формы или параметра URL. В случае использования стандартного языка Transact SQL возможно вставить вредоносный код. В результате чего будут получены, изменены или удалены данные таблиц. Чтобы предотвратить это, используйте параметризованные запросы, которые поддерживаются большинством языков веб-программирования.

Если злоумышленник изменит значение parameter на ' OR '1'='1 , запрос примет следующий вид:

Так как '1' равен '1' , атакующий получит доступ ко всем данным таблицы. Это позволит выполнить произвольный запрос, добавив в конец выражения SQL.

Уязвимость этого запроса легко устранить с помощью параметризации. Например, для приложения, написанного с использованием PHP и MySQLi, он выглядит так:

Предотвратите межсайтовый скриптинг

Межсайтовый скриптинг (XSS) — тип атаки на веб-ресурсы, заключающийся во внедрении в страницу сайта вредоносного кода, который выполняется на компьютере пользователя, изменяет страницу и передаёт украденную информацию злоумышленнику.

Особенно подвержены этому виду атаки современные веб-приложения, где страницы построены из пользовательского контента, интерпретируемого фронтенд-фреймворками вроде Angular и Ember. В эти фреймворки встроена защита от межсайтового скриптинга, но смешанное формирование контента на стороне сервера и клиента создает новые комплексные атаки: внедрение директив Angular или хелперов Ember.

При проверке сосредоточьтесь на пользовательском контенте, чтобы избежать некорректной интерпретации браузером. Это похоже на защиту от SQL-инъекций. При динамической генерации HTML-кода используйте специальные функции для изменения и получения значений атрибутов (например, element.setAttribute и element.textContent ), а также шаблонизаторы, которые выполняют экранизацию специальных символов автоматически.

Политика безопасности содержимого (CSP) — ещё один инструмент защиты от XSS-атак. CSP — заголовки сервера, определяющие белый список источников, откуда разрешена загрузка данных для разных типов ресурсов. Например, запрет запуска скриптов со стороннего домена или отключение функции eval() . Благодаря политикам CSP даже при внедрении вредоносного кода в страницу его выполнение становится невозможным. На официальном сайте Mozilla размещено руководство по CSP с примерами конфигураций.

Проверяйте и шифруйте пароли

Храните пароли в виде хэша, причём лучше использовать алгоритмы одностороннего хэширования, например, SHA. В этом случае для авторизации пользователей сравниваются хэшированные значения. Если злоумышленник взломает ресурс и получит хэшированные пароли, ущерб будет снижен за счёт того, что хэш имеет необратимое действие и получить из него исходные данные практически невозможно. Но хэши на популярные пароли легко перебираются по словарю, поэтому используйте также «соль», уникальную для каждого пароля. Тогда взлом большого количества паролей становится ещё медленнее и требует больших вычислительных затрат.

Что касается валидации, установите ограничение на минимальную длину пароля, а также делайте проверку на совпадение с логином, e-mail и адресом сайта.

Контролируйте процесс загрузки файлов

Загрузка пользователем файлов на веб-сайт, даже если это просто смена аватара, несёт в себе угрозу информационной безопасности. Загруженный файл, который, на первый взгляд, выглядит безобидно, может содержать скрипт и при выполнении на сервере откроет злоумышленнику доступ к сайту.

Даже если установлено ограничение на тип (например, только изображения), относитесь к загружаемым пользователями файлам с подозрением. Расширение или MIME-тип легко подделать, чтение заголовка или использование функций проверки размера изображения не дают 100% гарантии, в большинство форматов изображений возможно внедрить код PHP, который будет выполнен на сервере.

Чтобы это предотвратить, запретите исполнение загружаемых файлов пользователями. По умолчанию веб-серверы не пытаются выполнить файлы с расширениями изображений, но не стоит полагаться только на расширение. Известны случаи, когда файл image.jpg.php обходил эту проверку.

Способы ограничения доступа:

переименовывать или изменять расширения файлов при загрузке;
изменять разрешения, например, на chmod 0666 ;
создать файл .htaccess (см. пример ниже), который откроет доступ только к указанным типам файлов.

Меры защиты веб-приложений для владельцев собственных серверов:

Настройте межсетевой экран, в том числе на блокировку неиспользуемых портов.
При наличии доступа к серверу из локальной сети создайте демилитаризованную зону (DMZ), открыв доступ из внешнего мира только к портам 80 и 443.
При отсутствии доступа к серверу из локальной сети используйте защищённые методы (SFTP, SSH и др.) для передачи файлов и управления сервером извне.
Если возможно, выделите отдельный сервер для баз данных, который не будет напрямую доступен из внешнего мира.
Отграничьте физический доступ к серверу.

Чтобы держать руку на пульсе проекта, установите систему мониторинга ошибок. Например, Sentry, которая автоматически получает ошибки от обработчиков в коде приложения и через форму от пользователей, а также предоставляет панель для управления ими в реальном времени.

Проверяйте входящие данные

Контролируйте данные, полученные с веб-форм, как на стороне клиента, так и на стороне сервера. В браузере проверяются простые ошибки вроде незаполненного обязательного поля или текста, введённого в числовое поле. Эти проверки обходятся, поэтому контроль на стороне сервера обязателен. Отсутствие проверки на стороне сервера приводит к эксплуатации злоумышленником инъекций и других видов атак.

Распределяйте права доступа к файлам

Разрешения файла (file permissions) определяют КТО и ЧТО может с ним делать.

В *nix системах у файлов 3 варианта доступа, которые представляются в виде цифр:

«Read» (4) — чтение содержимого файла;
«Write» (2) — изменение содержимого файла;
«Execute» (1) — выполнение программы или скрипта.

Чтобы установить множественные разрешения, достаточно сложить их числовые значения:

«Чтение» (4) + «запись» (2) = 6;
«Чтение» (4) + «запись» (2) + «выполнение» (1) = 7.

При распределении прав пользователи делятся на 3 типа:

«Owner» (владелец) — создатель файла (изменяем, но может быть только один);
«Group» (группа) — группа пользователей, которые получают разрешения;
«Others» (прочие) — остальные пользователи.

Установка владельцу прав доступа на чтение и запись, группе — на чтение, прочим — запрет доступа выглядит так:

Чтение	Запись	Выполнение
Владелец	2	4	0
Группа	0	4	0
Прочие	0	0	0

Итоговое представление: 640 .

Для каталогов аналогично, но флаг «выполнить» значит сделать рабочей директорией.

При установке CMS-разрешения, как правило, устанавливаются корректно с точки зрения безопасности. Однако в Интернете часто советуют решать проблемы прав доступа установкой на все файлы значения 666 или 777 . Этот совет помогает решить проблему, но открывает серьёзную уязвимость, потому что всем появляется право изменить (вставить вредоносный код) или удалить файлы на сервере. Распределяйте права доступа к файлам на сервере в соответствии с задачами пользователей.

Если задаться целью, уязвимость в приложении найдётся. В отчете о хакерских атаках на сайты за 2016 год эксперты Google сообщили о том, что количество взломанных ресурсов увеличилось на 32% по сравнению с 2015 годом, и это не предел. Помните об этом и отбросьте заблуждения о неприступности своих веб-ресурсов, когда планируете работы по информационной безопасности.