Эта статья одна из трех публикаций, посвященных проверке надежности Web приложений. В первой части описывается проверка надежности и анализ Web приложений, способы организации их работы, взаимодействия с пользователями, а также стандартные ошибки разработчиков, способные дать доступ к данным и системе.
Эта статья одна из трех публикаций, посвященных
проверке надежности Web приложений. В первой части описывается проверка надежности
и анализ Web приложений, способы организации их работы, взаимодействия с пользователями,
а также стандартные ошибки разработчиков, способные дать доступ к данным и
системе.
Примичание: предполагается, что читатель
знаком с архитектурой HTTP протокола, HTTP Get и Post запросами, и значениями
полей заголовков. Эту информацию можно получить из RFC2616 .
Web приложения становятся все более распространенными
и еще в большей мере сложными, и, таким образом, важными для всех видов онлайн
бизнеса. Наряду с общими вопросами безопасности, уязвимости в Web приложениях
возникают в основном из-за некорректного запроса со стороны клиента и/или
из-за недостаточной проверки вводимых данных, реализуемых на уровне приложений.
Истинную природу Web приложений – возможность
сопоставлять, обрабатывать и распространять информацию по Интернет – можно
реализовать двумя способами. Первый и самый очевидный – Web приложения доступны
по своей природе всем. Это делает безопасность посредством сокрытия таких
приложений невозможной и повышает требования к устойчивости кода. Второй,
самый важный для перспективы проверки надежности; ведется передача элементов
данных посредством HTTP запросов – протокола, который может выполнять множество
задач по шифрованию и инкапсуляции.
Почти все среды разработки Web приложений (включая
ASP и PHP, которые будут использоваться для примеров) предоставляют использование
данных разработчику таким образом, что невозможно определить способ их перехвата,
и вследствие, какой вид подтверждения и проверки должен быть использован.
Поскольку среды разработок различны, и состоят из многих видов программируемого
содержания, подтверждение ввода и логический контроль являются ключом к решению
проблем с безопасностью Web приложений. Это касается и идентификации, и обеспечения
верного домена для каждого определенного пользователем элемента данных, так
же, как и полное понимание источника всех элементов данных для обозначения
потенциальных данных, определенных пользователем.
Главная задача: Подтверждение ввода
Задачи подтверждения ввода могут вызвать сложности
при расположении их в объемной базе с большим количеством взаимодействий пользователей
между собой, что, собственно, и является главной причиной, принуждающей разработчиков
использовать методологию проверки безопасности для решения этих проблем. Web
приложения все же не имеют иммунитета к обычным формам атак. Непрофессиональные
методы аутентификации, логические просчеты, непредусмотренное обнаружение
скрытой информации, обычные бинарные ошибки приложений (переполнение буфера)
встречаются очень часто. Анализируя Web приложения на предмет наличия уязвимостей,
все вышесказанное должно учитываться; должны также применятся методичный процесс
проверки ввода/вывода (метод «черного ящика»), по возможности, вместе с аудитом
кода (методом «белого ящика»).
Что же на самом деле представляет из себя Web
приложение?
Web приложение является приложением, включающим
в себя набор скриптов, расположенных на Web сервере и взаимодействующих с
базами данных или другими ресурсами динамического содержимого. Они становятся
более распространенными, так как позволяют поставщикам услуг и их клиентам
быстро обмениваться информацией часто, независимо от платформ, посредством
инфраструктуры Интернета. Примерами таких приложения являются поисковые и
почтовые системы, онлайн магазины и порталы.
Как это выглядит для пользователя?
Web приложения часто взаимодействуют с пользователями
используя элементы ФОРМЫ и переменные GET или POST (даже кнопка «Нажми здесь»
обычно является подтверждением формы). При использовании переменных GET данные
из формы могут быть видны в самом URL запросе, в то время, как POST запросы
требуют изучения кода страницы формы или перехвата и расшифровки запроса для
получения данных, введенных пользователем.
Пример HTTP запроса для обычного Web приложения
GET /sample.php?var=value&var2=value2 HTTP/1.1   
| HTTP-METHOD REQUEST-URI PROTOCOL/VERSION
Session-ID: 361873127da673c
| Session-ID Header
Host: www.webserver.com
| Host Header
| Two carriage return line feeds
Каждый элемент данного запроса может быть использован
Web приложением, обрабатывающим данный запрос. REQUEST-URI указывает единицу
кода, которая будет приведена в действие строкой запроса: перечень разделенных
пар &variable=value обозначают параметры ввода. Это основная форма ввода
данных для Web приложений. Заголовок Session-ID является обозначением установки
сессии с клиентом как первичная форма аутентификации. Host Header обычно используется
для различения виртуальных хостов, принадлежащих одному IP адресу и обычно
фильтруется Web сервером, но находится, согласно теории, внутри домена Web
приложения.
Для проверки надежности нужно использовать все
возможные методы ввода, дабы вызвать критические условия для приложения. Не
следует полагаться на ограниченные возможности, которые дают броузер или различные
инструменты. Очень просто создавать HTTP запросы используя такие утилиты,
как curl , или
консольные скрипты пользуясь netcat .
Процесс тестирования Web приложения, используя метод черного ящика, дает возможность
обнаружить каждый элемент данных, определяя ожиданный ввод, взаимодействуя
с ним и повреждая его, а также анализируя вывод приложения на предмет наличия
нестандартного поведения.
Фаза сбора информации
Отпечатки
Один из первых шагов проверки надежности приложения
– это определение среды его разработки и функционирования, включая язык скриптов,
программное обеспечение Web сервера, операционную систему. Эти важные детали
очень просто получить от сервера используя следующие методы:
1.      Исследования ответа на HTTP запросы –
HEAD и OPTIONS
Заголовок и любая страница полученная в следствии
запроса HEAD или OPTIONS содержит обычно строку SERVER: или детальное описание
версии программного обеспечения Web сервера, и, возможно, описание скриптов
или операционной системы.
OPTIONS / HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 04 Jun 2003 11:02:45 GMT
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: none
DASL:
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND,
PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private
2. Исследование формата и надписей на страницах,
сообщающих об ошибках (404/и другие)
Некоторые приложения (такие как ColdFusion) имеют
стандартные, а значит, легко узнаваемые страницы сообщающие об ошибках и выдают
версию программного обеспечения и язык скриптов. Исследователь должен внимательно
изучить получаемые страницы и использовать полученную информацию от различных
запросов(POST/PUT/и т.д.) для сбора информации о сервере.
Ниже приведен пример страницы, сообщающей об 404
ошибке приложения ColdFusion:
3. Тест на распознавание типов фалов/расширений/директорий
Многие Web сервисы (например Microsoft IIS) будут
вести себя по разному на запрос к известному и поддерживаемому файловому разрешению
и к неизвестному. Проверяющий должен попытаться запросить файлы с обычными
разрешениями (ASP, .HTM, .PHP, .EXE) и проследить за необычными ответами или
кодами ошибок.
4. Исследование исходных кодов доступных страниц.
Исходный код непосредственно доступных страниц
может дать исчерпывающую информацию о приложении
В данной ситуации разработчик, похоже, использует
MS Visual Studio 7. Средой может быть, в данном случае, Microsoft IIS 5.0
с .NET framework.
5. Управление вводом для поиска ошибок в скриптах.
В данном примере очевидная переменная (ItemID)
была изменена для наблюдения за Web приложением:
1.      Отпечатки сервиса и TCP/ICMP
Используя обычные средства для снятия отпечатков – Nmap
и Queso – или более
популярные Amap и WebServerFP , проверяющий может получить более точные данные
об операционной системе и Web приложении по отношению к другим методам. NMAP
и Queso исследуют способ реализации TCP/IP данного хоста для определения сведений
об операционной системе, в некоторых случаях, о версии ядра и патчах. Такие
приложения полагаются на данные, полученные от HTTP заголовков сервера для
определения ПО.
Скрытые элементы формы и анализ кода
Во многих случаях разработчики требуют защищенный
от изменений ввод данных, таких, как переменные пользователя, которые создаются
динамически, приписываются клиенту и требуются в дальнейших запросах. Для
того, чтобы скрыть данные от глаз пользователя и возможно от их изменения,
часто используются тэги в форме с атрибутом HIDDEN. К сожалению, эти тэги
не видны лишь в представляющейся пользователю на обозрение части страницы,
но их легко обнаружить, заглянув в сам код.
Существует множество примеров плохо написанных
систем заказов, которые позволяют пользователям сохранять локально копию запроса
подтверждаемой страницы, редактировать скрытые переменные, например, цену
или счет за доставку, и повторно делать свой заказ. Web приложения не требуют
аутентификации или поверки подтверждения формы и заказ может быть выполнен
с большой скидкой!
Такие методы практикуются сейчас на многих сайтах.
Обычно, в скрытых полях содержится нечувствительная информация, или данные
в них зашифрованы. Небрежное отношение к информации в таких полях – способ
изменения и управления данными для проверяющего.
Все коды страниц должны быть по возможности проанализированы
на предмет обнаружения чувствительной или полезной информации, по невнимательности
оставленной разработчиком – это могут быть активные элементы на странице,
указатели на включенные или прилинкованные скрипты и содержание, неправильные
разрешения на запись/чтение для файлов или каталогов. Все относительные приложения
и скрипты должны быть проверенны, и по возможности, подробно рассмотрены.
Javascript и другие клиентские приложения могут
также дать много информации о внутреннем устройстве Web приложения. Такую
информацию можно получить пользуясь методом черного ящика. Также с помощью
метода белого ящика (или аудита кода) можно получить доступ к логическому
построению приложения. Для метода черного ящика эта информация является роскошью,
которой следует воспользоваться для атак:
Предполагается, что приложение старается ограничить
значение количества до 255 – максимального значения поля tinyint в большинстве
СУБД. Было бы логично обойти клиентскую сторону проверки и вставить длинное
числовое значение в переменную quantity запроса GET/POST, а затем проследить
за действием приложения.
Определение механизма аутентификации
Один из больших недостатков Web приложений – отсутствие
устойчивого механизма аутентификации. Самой частой ошибкой разработчиков является
определение эффективности механизма аутентификации. Следует заметить, что
условия проведения аутентификации зависят от протоколов, языков и форматов
– HTTP, HTTPS, HTML, CSS, JavaScript, и т.д – используемых приложениями и
зависящим от платформы, на которой работает приложение и от его архитектуры.
НТТР обеспечивает два метода аутентификации Basic и Digest.
Оба являются серией НТТР запросов и ответов, в которой клиент запрашивает
ресурс, сервер требует аутентификацию, и клиент повторяет запрос согласно
требованиям аутентификации. Разница между двумя методами аутентификации состоит
в ном, что при методе Basic посылается серверу простой текст, а при
Digest, хешированный, который используется сервером как криптографический
ключ.
В природе проблемы передачи данных открытым текстом
при использование метода Basic при НТТР аутентификации нет ничего неправильного,
и эта проблема может быть решена использованием HTTPS. Проблема на самом деле
заключается в двух вещах.
1. С тех пор, как Web сервер начал обрабатывать
запрос на аутентификацию, сложно управлять Web приложением без взаимодействия
с базой данных аутентификации Web сервера. Поэтому очень часто используются
обычные методы аутентификации.
2. Разработчики часто делают ошибки в правильном
определении к каждому средству доступа к ресурсу и соответственно используют
неправильный алгоритм.
Проверяющий должен стараться выяснить сам механизм
аутентификации и средство его применения к каждому ресурсу Web приложения.
Многие среды разработок для Web предлагают возможность использования сессий,
где пользователю записывается куки, или НТТР заголовок Session-ID содержит
псевдо-уникальную строку для идентификации их статуса. Такие средства могут
быть уязвимыми к таким атакам, как брутфорс, разбор строки, если она состоит
из просто из хеша или связанной строки из известных элементов.
Каждая попытка должна быть сделана с целью получить
доступ к ресурсу используя каждую входную точку. Проблемы возникнут, если
ресурсы уровня администратора требуют аутентификацию, как например главное
меню, или страница портала с последующими уровнями. Например, Web приложение
осуществляет доступ ко многим документам для прошедшего аутентификацию пользователя,
каждый документ представлен ссылкой на ресурс:
http://www.server.com/showdoc.asp?docid=10
Также, для доступа к меню требуется аутентификация,
скрипт showdoc.asp сам по себе не требует аутентификации и предоставляет любому
нужный документ. Это может позволить атакующему просто указать id документа
и в GET запросе и получить желаемую страницу. Как элементарно это не звучит,
но эта ошибка самая частая.
Заключение
В этой статье мы описали методы проверки надежности
и в целом рассмотрели структуру Web приложений, а также методы контроля ввода
данных со стороны пользователей. Мы также показали важность использования
отпечатков для целевой среды и понимания скрытой части Web приложений. Вооружившись
этой информацией, проверяющий сможет провести ряд тесов для поиска и использования
уязвимостей. Следующие статьи этого цикла опишут способы атак посредством
изменения кода и содержания, таких, как PHP/ASP code injection, SQL injection,
Server-Side Includes и межсайтовый скриптинг..
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
valid cvv shop legit cvv shop