В настоящее время в работе бизнеса различных отраслей стали очень распространены веб-приложения [2, c. 39], которые во многом повторяют логику и устройство аналогичных продуктов компаний, разработанных для какой-либо конкретной операционной системы. Такая ситуация также наблюдается во многих сферах, особенно там, где требуется обеспечение доступа к разработанному программному обеспечению практически с любого устройства, имеющего выход в интернет. Однако из-за такого подхода по созданию полностью аналогичных приложений не учитываются многие особенности работы интернет-браузеров, которые в свою очередь создают множество потенциальных возможностей для воздействия на данные со стороны злоумышленников [1, c. 60], а также необходимость создания корректного контроля доступов, тем самым ограничивая область действий потенциального пользователя. Данная проблема является как никогда актуальной сейчас, поскольку теперь практически любое программное обеспечение имеет свой аналог в виде веб-приложения и многие из них подвержены воздействию злоумышленников.
Текущие проблемы при использовании и разработки веб-приложений
Из-за того, что при разработке веб-приложений зачастую не учитывают их ключевые особенности, а именно то, что в силу своего строения доступ к ним может быть получен буквально с любого устройства, имеющего интернет-браузер, и у компаний, которые решают проводить полномасштабную интеграцию таких решений в свою корпоративную сеть, может возникнуть множество неочевидных проблем.
Одной из таких проблем является некорректная настройка маршрутизации в итоговом продукте, позволяющая потенциальным пользователям, не имеющим необходимого уровня доступа с помощью прямых ссылок просматривать ресурсы, доступ к которым для них не предусмотрен. Такие ошибки в проектировании практически всегда достаточно дорого обходятся компании, если доступ к таким ресурсам был получен недобросовестным пользователем, который в свою очередь можем поделиться данной уязвимостью с третьими лицами и тем самым подвергнуть колоссальному риску расположенную там информацию.
Вместе с этим также стоит упомянуть, что немаловажную опасность представляет собой недостаточная фильтрация входящей информации в базу данных, расположенную на сервере. Это связано в первую очередь с тем, что потенциальный нарушитель способен ввести в форму какой-либо SQL-запрос и получить в ответ необходимую конфиденциальную информацию из базы. Такая атака называется инъекцией, и она может причинить большой ущерб практически любому продукту, в частности если соответствующая фильтрация или валидация данных вовсе отсутствует.
Также имеется риск некорректной проектировки архитектуры веб-приложения, как пример разрешение пользователям загружать файлы любого формата без какой-либо проверки со стороны клиента, тем самым повышается шанс эксплуатации такой уязвимости со стороны злоумышленников, способных развернуть на стороне сервера исполняемый файл с каким-либо вредоносным кодом.
Стоит также упомянуть, что в большинстве случаев во время разработки веб-приложений редко уделяется достаточное время построению безопасной конфигурации самого приложения и из этого как раз вытекает множество проблем, напрямую связанных с общим уровнем безопасности. В такой ситуации, когда текущие настройки веб-приложения или же сервера не отвечают должным требованиям безопасности, колоссальным образом возникает риск утечки данных или же вовсе компрометации связок логинов и паролей для доступа к административным панелям со стороны серверной части или чего-либо еще.
Использование уязвимых или же вовсе устаревших компонентов также может сильно повлиять на общий уровень веб-приложения. Такая проблема возникает, когда в разработке применяются непроверенные фреймворки или же сторонние решения, уже имеющие в своем исходном коде ошибки безопасности. Злоумышленники же могут воспользоваться достаточно распространенными инструментами, позволяющими производить поиск и успешно находить некорректно сконфигурированные веб-приложения, например поисковая система Shodan IoT.
Нельзя также не отметить, что ошибки идентификации и аутентификации являются в настоящее время одной из ведущих проблем в области разработки веб-приложений, поскольку многие команды разработки не придают должного значения выстраиванию корректного процесса авторизация и аутентификации пользователей приложения. Возможность установки «слабого пароля», как например «123456», и отсутствие ограничений на количество попыток входа может потенциально создать множество проблем для общего уровня защищенности веб-приложения, поскольку злоумышленнику не составит труда методом перебора подобрать корректный пароль и тем самым скомпрометировать чьи-либо конфиденциальные данные. Тем более такая ситуация может усугубляться, если реализованное приложение обращается с финансовыми операциями или же вовсе повторяет логику работы уже существующего продукта и имеет достаточно большого объема базу данных со сведениями о пользователях. Вместе с этим также стоит отметить, что далеко не всегда в веб-приложениях со стороны интерфейсы производится хеширование и обезличивание логинов, чтобы в случае компрометации базы данных не получилась такая ситуация, когда злоумышленники будут иметь доступ к множеству аккаунтов.
Ошибки логирования и мониторинга безопасности могут потенциально создать множество проблем для конечного продукта, размещенного в сети интернет, поскольку если система не производит корректной фиксации аномальных событий, напрямую касающихся безопасности, или же вовсе такие механизмы отсутствуют. Данная проблема является одной из наиболее критичных во многом из-за того, что если мониторинг безопасности работает некорректно или же отсутствует вовсе, то из-за этого атаки злоумышленников могут оказаться незамеченными. Это в свою очередь снизит вероятность оперативного реагирования на возникающие инциденты в реальном времени и обнаружение угроз в целом. Пример такой ситуации может послужить ситуация, когда при многократных попытках неудачной аутентификации не происходит логирования и каких-либо ограничений со стороны интерфейса для предотвращения подбора пароля, и тем самым у злоумышленника появляется множество возможностей для реализации атак.
Нельзя также не отметить, что всегда существует вероятность подделки запросов на стороне сервера (server-side request forgery, SSRF), то есть, когда злоумышленник заставляет сервер отправлять запросы к каким-либо внутренним ресурсам или же вовсе внешним сайтам. Такой подход достаточно часто применяется потенциальными злоумышленниками, для проведения атак на внутренние ресурсы, доступ к которым извне ограничен. Как пример, если серверная часть веб-приложения не имеется достаточной защиты от SSRF, злоумышленник потенциально может заведомо ввести зловредный URL-адрес, заставляющий сервер произвести отправку запроса к собственным внутренним ресурсам и в последствии получить оттуда конфиденциальные данные.
Подход к реализации веб-приложений, обеспечивающий защищенный обмен данными
Учитывая особенности и тенденции развития современных веб-приложений можно выработать следующий подход, включающий в себя следующие аспекты, которые в свою очередь должны быть обязательно проверены еще на этапе разработки программного обеспечения, чтобы обезопасить его и предотвратить множественные ошибки в последствии.
В первую очередь необходимо проводить регулярный мониторинг маршрутизации, а также проектировать контроль уровней доступа на основе принципа наименьших привилегий, чтобы пользователи имели только права, необходимые для выполнения их непосредственных задач. Также необходимо проводить корректную маршрутизацию внутри веб-приложения с целью недопущения доступа недобросовестных пользователей к конфиденциальным данным.
Для предотвращения эксплуатации уязвимостей, связанных с SQL-инъекциями [3, c. 66], необходимо применять на серверной части следующие подходы, а именно:
• Использовать параметризированные запросы или же ORM (object-relational mapping) для проведения работы с базой данных;
• Проводить валидацию и корректную фильтрацию входных данных;
• Применение во всем продукте принципа наименьших привилегий, тем самым ограничивая права доступа к базе данных тем сотрудникам, которым эти права не являются необходимыми для выполнения должностных обязанностей.
Следующим по важности шагом для обеспечения должного уровня защищенности в приложении является корректная настройка полного перечня компонентов, используемых в веб-приложении, а также установка разграничения прав доступа внутри системы, чтобы избежать компрометации ценной информации или же ее конфиденциальности. В случае же недостаточно защищенного простого приложения может хватить и базовых мер, описанных в разделе о клиент-серверной архитектуре, однако если приложение потенциально будет взаимодействовать с конфиденциальной информацией и будет являться высоконагруженным, то таких мер не хватит для защиты в полной мере.
Трехуровневая архитектура защиты данных
Вместе с этим также нельзя не отметить, что аутентификация [4, c. 147] пользователей является слабым звеном любых приложений, в том числе и реализованных с помощью веб-технологий. Именно поэтому при современном проектировании таких решений учитывается то, что за всю отображаемую логику и общее поведение пользователя будет отвечать исключительно серверная часть, а клиент будет служить лишь прослойкой между непосредственным пользователем и сервером. Данная особенность является несомненным преимуществом веб-решений, поскольку при авторизации пользователя в системе проверка пароля на корректность и общее соответствие прав будет происходить на удаленном сервере, а клиент в свою очередь лишь отобразит результат такой проверки и в случае, если все в порядке, то пропустит пользователя дальше. Лишь при таком условии реализации приложений получается добиться максимального уровня защищенности.
Также должен активно применяться и быть выстроен процесс безопасной разработки [6, c. 101] программного обеспечения с повсеместным использованием различных анализаторов кода, позволяющих проверить весь исходных код на наличие различного вида ошибок, потенциально способных привести к появлению уязвимостей.
Однако в случае, если архитектура [5, c. 233] уже была выстроена ранее, и компания не имеет возможности вносить изменения в уже написанный код, то наиболее эффективным решением будет являться применение WAF (Web Application Firewall). В случае его применения HTTP-трафик от потенциальных пользователей веб-приложения будет идти не напрямую к серверной части, а через WAF, где он будет подвергаться декодированию и множеству проверок на наличие атак. В пассивном же режиме будут доступны лишь функции мониторинга и создания оповещений об атаках.
Стоит также упомянуть о том, что WAF может содержать в себе различные модули, в том числе и модули, позволяющие проводить динамический анализ потенциальных уязвимостей защищаемого веб-приложения, тем самым обеспечивая еще более полноценную защиту для конфиденциальных данных и общего состояния системы.
Как итог, в современном защищенном веб-приложении должна применяться трехуровневая архитектура защиты данных и вышеперечисленные меры, в полной мере обеспечивающие решение большинства проблем, связанных с безопасностью и рисками утечки данных (рисунок).
Заключение
Таким образом, были рассмотрены основные проблемы при разработке веб-приложений в настоящее время, а также, с учетом тенденций развития и общего уровня защищенности большинства приложений в интернете, был предложен современный подход к реализации веб-приложений на основе клиент-серверной архитектуры, обеспечивающий защищенный обмен данными.
Описанный подход в свою очередь позволяет избежать большинства уязвимостей, которые могут возникнуть в процессе разработки продуктов, а также позволить обеспечить безопасность на всех этапах производства программного обеспечения, рассчитанного на работу в сети интернет в качестве веб-приложения.