Перевод «beb» на русский
The Russian Highways’ representatives have also held a number of meetings with the representatives of the Federal Construction and Transport Office of the Free State of Thuringia, Engineering Chamber of the Free State of Thuringia, BEB‘s Engineering Group, as well as the Bauhaus University.
Представители «Автодора» также провели ряд рабочих встреч с сотрудниками Федерального ведомства Земли Тюрингия по строительству и транспорту, инженерной палаты Земли Тюрингия, инженерной группы ВЕВ, а также университета Bauhaus.
Перевод «beb» на русский
C Alicia de mensajera, quien quiere vacunarse este invierno pero va a tener un beb dentro de dos meses.
В. Эльвире, которая хотела бы пройти иммунизацию этой зимой, но через два месяца она ожидает рождения ребенка.
Este es nuestro beb. nuestro perro.
Это наш ребёночек. Собака, то есть.
Usted debe escuchar, vamos beb? Vamos, hermosa.
Вы должны услышать их, Давай, детка Давай, красивая.
Soldados de Plomo Fundido masas que fueron los beb? s superan rupias seis millones y Carmel nombre y luego lo que ha dicho aqu? de Detector de divisas?
Литой свинец Солдаты масс, которые были дети перерастают шесть миллионов рупий и Кармель имя и то, что вы сказали здесь Детекторы валют?
¿Cuánto? — Que yo. había beb.
Вот так сразу предполагаешь, что. я.
Y yo les dije la Tor?, no lo llame la infertilidad, el beb? no llaman a los ni? os, cuando no bebe no es una mujer sin fruto, es una mujer sin ra? ces
И я сказал им Тору, не называйте это бесплодие, ребенок не призываю к детям, когда ни один ребенок не является женщиной без фруктов, это женщина без корней
HISTORIA de los BeB Mucha gente sabe que la construcción de modelos de barcos es un arte muy antiguo.
Немногие знают что постройка моделей кораблей — очень древнее искусство.
Estamos actualizando periódicamente nuestra base de datos, tan pronto como cualquier vuelo low-cost desde el aeropuerto Benbecula (BEB) esté disponible, le dejaremos saber.×
Мы периодически обновляем нашу базу данных, поэтому как только какие-то дешёвые перелёты из аэропорт Сан-Хосе (SJI) в Белиз появятся в продаже, мы сразу дадим вам знать.×
Porque yo beb el vodka.
Потому что водку выпил я.
Algunos vinos se beb.
А еще вино пьют.
Bill, es tu beb.
Билл, это твой ребенок.
¿Qué sucede cuando usted beb.
Что происходит когда бью.
Y esto, pronto lo ver? s venir aqu? a pie. mi beb? . m? o, est? en el tejado, poco Moshiko dime, mam? tengo hambre!
А это, скоро вы увидите его прийти сюда пешком. Hktnzi К. шахты, находится на крыше, маленький Мошико скажи мне, мама, я голодный!
Luego Sabios dicen Midrash, dos? ngeles vienen, dan a este beb? s? mola y miel y un d? a ella va a visitar al beb? en el campo, su cuerpo,
Тогда мудрецы говорят Мидраш, два ангела приду, этого ребенка манной крупы и мед и в один прекрасный день она собирается посетить ребенка в поле, его тело,
El desarrollo de camiones eléctricos a batería (BEB) y autobuses que pueden funcionar con combustibles alternativos (híbridos) está experimentando un crecimiento continuo a fin de cumplir con los límites de emisiones de CO2 dispuestos a nivel mundial.
Грузовые автомобили, работающие на аккумуляторных источниках питания, и автобусы, работающие на альтернативном топливе, (гибридные автобусы) все чаще разрабатываются с учетом мировых ограничений на выбросы CO2.
Business English for Beginners (BEB) proporciona inglés de negocios práctico para las personas que desean trabajar con el inglés en el futuro y para quienes piensan traba. [+]
Деловой английский для начинающих (ВЕВ) предоставляет практический деловой английский для людей, которые хотят работать с английским языком в будущем, и тех, кто планирует раб. +
Возможно неприемлемое содержание
Примеры предназначены только для помощи в переводе искомых слов и выражений в различных контекстах. Мы не выбираем и не утверждаем примеры, и они могут содержать неприемлемые слова или идеи. Пожалуйста, сообщайте нам о примерах, которые, на Ваш взгляд, необходимо исправить или удалить. Грубые или разговорные переводы обычно отмечены красным или оранжевым цветом.
Зарегистрируйтесь, чтобы увидеть больше примеров. Это просто и бесплатно
Ничего не найдено для этого значения.
Предложить пример
Больше примеров Предложить пример
Новое: Reverso для Windows
Переводите текст из любого приложения одним щелчком мыши .
Скачать бесплатно
Перевод голосом, функции оффлайн, синонимы, спряжение, обучающие игры
Результатов: 22 . Точных совпадений: 22 . Затраченное время: 48 мс
Помогаем миллионам людей и компаний общаться более эффективно на всех языках.
Веб-сервисы в теории и на практике для начинающих
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
- SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
- REST (Representational State Transfer)
- XML-RPC (XML Remote Procedure Call)
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
+-------------+------------------+ | Field | Type | +-------------+------------------+ | code | int(10) unsigned | | charcode | char(3) | | description | varchar(100) | | value | int(10) unsigned | | base | tinyint(1) | +-------------+------------------+
Таблица номиналов обмена (exchange):
+------------+------------------+ | Field | Type | +------------+------------------+ | id | bigint(20) ai | | rate_date | timestamp | | rate_value | float | | code | int(10) unsigned | +------------+------------------+
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
([A-Z]+)(\d+)(.+?)(\d+\.\d+)/i', $content, $m) == false) < throw new Exception( 'Can not parse data!'); >/** * Preformatting data to return; */ $data = array(); foreach ($m[1] as $k => $code) < $data[] = array( 'code' =>$code, 'charcode' => $m[2][$k], 'value' => $m[3][$k], 'description' => $m[4][$k], 'rate_value' => $m[5][$k] ); > return $data; > public static function run() < $data = self::getData(); /** * Sets default currency if not exists */ if (!Doctrine::getTable( 'Currency')->find( 980)) < $currency = new Currency(); $currency->setCode( 980) ->setCharcode( 'UAH') ->setDescription( 'українська гривня') ->setValue( 1) ->setBase( 1) ->save(); > foreach ($data as $currencyData) < /** * Updating table of currencies with found values */ if (!Doctrine::getTable( 'Currency')->find( $currencyData['code'])) < $currency = new Currency(); $currency->setCode( $currencyData['code']) ->setCharcode( $currencyData['charcode']) ->setDescription( $currencyData['description']) ->setValue( $currencyData['value']) ->setBase( 0) ->save(); > /** * Updating exchange rates */ $date = date( 'Y-m-d 00:00:00'); $exchange = new Exchange(); $exchange->setRateDate( $date) ->setRateValue( $currencyData['rate_value']) ->setCode( $currencyData['code']) ->save(); > > > ?>
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
0 10 * * * /usr/bin/php /path/to/grabber.php
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
find( $code); $exchange = $currency->getExchange( $date); return $exchange ? (float)$exchange->getRateValue() : null; > /** * Retrievs all available currencies * * @return array - list of all available currencies */ public function getCurrencyList() < return Doctrine::getTable( 'Currency')->findAll()->toArray(); > > ?>
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
setClass( 'CurrencyExchange'); $server->handle(); ?>
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
getExchange( 840, date( 'Y-m-d')); ?>
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
setClass( 'CurrencyExchange'); $server->handle(); ?>
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
?method=getExchange&code=840&date=2008-11-29
?method=getExchange&arg1=840&arg2=2008-11-29
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
getExchange( 840, date( 'Y-m-d'))->get(); if ($result->isSuccess()) < echo 'USD exchange: ' . $result->response; > ?>
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.
Как начать заниматься багхантингом веб-приложений
Компании могут проверять свои продукты, сервисы или инфраструктуру на реальность взлома разными способами: это и пентест (тестирование на проникновение), и редтиминг (Red Team, проверка возможностей компании по выявлению и предотвращению вторжения), и bug bounty (набор условий, в соответствии с которыми белые хакеры получают от организаций вознаграждение за уязвимости, найденные в их IT-сетях, системах и приложениях). Дыры в программном обеспечении могут обернуться убытками для компаний и компрометацией персональных данных (а иногда и финансовыми потерями) для пользователей.
В этой и следующих статьях мы подробно пройдемся по теме bug bounty и расскажем о том, как прокачаться в багхантинге веб- и мобильных приложений.
Первая статья будет особенно интересна самым маленьким начинающим багхантерам. Но и те, кто уже зарабатывал на этом, смогут найти для себя что-то новое.
Дисклеймер
Имейте в виду, эта статья носит информационный характер и посвящена легальному поиску уязвимостей в информационных системах. Мы не призываем к совершению противоправных действий и обращаем внимание третьих лиц на необходимость во всех случаях соблюдать действующее законодательство и правила соответствующей программы по поиску уязвимостей. Неправомерный доступ к компьютерной информации влечет за собой юридическую ответственность.
Информационные технологии стремительно развиваются, появляется огромное количество сервисов и приложений, в том числе и в составе критической инфраструктуры; растет сложность как их разработки, так и обслуживания. Вместе с этим повышаются различные риски, в частности риски появления уязвимостей и их эксплуатации злоумышленниками.
Для начала определимся с терминами:
- Багхантер (bug hunter) — исследователь безопасности, легально ищущий уязвимости в программном обеспечении. Сейчас в открытом доступе есть масса учебных материалов, видеоуроков и тренировочных площадок, которые помогут стать багхантером любому человеку. И эта статья станет хорошим дополнением в этом списке.
- Багхантинг (bug hunting) — этичный (легальный и ответственный) поиск багхантерами уязвимостей, за которые вендор может выплатить денежную награду, выдать памятный подарок и упомянуть в зале славы.
- Вендор (vendor) — разработчик продукции или услуг.
- Баг баунти (bug bounty) — программа, по которой багхантеры получают от компаний вознаграждение за найденные в их IT-сетях, системах и приложениях уязвимости.
- Скоуп (scope) — разрешенная область действий, устанавливаемые программой bug bounty границы, в рамках которых разрешено производить багхантинг. В него могут входить IP-адреса, CIDR-диапазоны, домены, поддомены, десктопные и мобильные приложения.
Платформы bug bounty
Свои программы bug bounty обычно объявляют владельцы и разработчики сайтов, сервисов и программного обеспечения, чтобы поощрить исследователей безопасности сообщать об уязвимостях, особенно о таких критически опасных, как RCE. Делать это они могут на собственных ресурсах, продвигая их своими силами. Но если компания хочет сразу привлечь большое количество независимых исследователей безопасности, то она размещает свои программы на платформе bug bounty.
Платформа bug bounty — это агрегатор, объединяющий на своей площадке программы самых разных компаний и позволяющий исследователям безопасности выбирать себе проект. При размещении на платформе компании публикуют список ресурсов, за отчет о недостатках защищенности в которых они готовы платить. А белые хакеры, заинтересованные в решении интересных задач, публичном признании и получении награды, обеспечивают объективность и достоверность исследований.
Среди наиболее известных платформ можно выделить Bugcrowd, HackerOne, Vulnerability Lab, BountyFactory и Synack. Платформы есть и в СНГ: standoff365, bugbounty.ru (Россия), bugbounty.kz (Казахстан), bugbounty.by (Беларусь) и т. д.
В начале этого года многие иностранные платформы bug bounty, в том числе и крупнейшая в мире — HackerOne, отказались от сотрудничества с российскими белыми хакерами и исключили из числа своих клиентов российские компании.
В этой статье мы приводим данные о стоимости отдельных видов уязвимостей на примере платформы HackerOne, так как именно на ней на данный момент собрана самая обширная статистика.
Градация знаний и опыта
В области информационной безопасности существует условная градация знаний и опыта:
- Начинающий багхантер знакомится с теоретическими и практическими основами работы веб-приложений, узнает, что такое информационная безопасность и какие бывают виды атак и уязвимостей. Одновременно с этим он начинает участвовать в программах bug bounty, чтобы заработать рейтинг (багхантеров с высоким рейтингом приглашают в приватные программы с ограниченным количеством участников), получить денежное вознаграждение и бесценный опыт.
- Опытный багхантер постоянно стремится углублять свои навыки и опыт, активно участвует в публичных и приватных программах bug bounty, посещает тематические конференции, может быть участником команды в соревнованиях по взлому систем с заранее заложенными уязвимостями — Capture the Flag (CTF).
- Багхантер с многолетним опытом также участвует в различных программах bug bounty, ищет уязвимости и новые техники их эксплуатации в крупнейших мировых продуктах, выступает на конференциях и делится своим опытом.
Приведем пару ярких достижений багхантеров. Есть примеры, когда багхантеры с многолетним опытом, действуя в интересах, в том числе, и мировых IT-гигантов, находили критические уязвимости или выявляли новые методики атак, использующие нестандартную технику эксплуатации, с помощью которых можно было захватить серверы компаний. К примеру, багхантер alexbirsan обнаружил проблему путаницы зависимостей в цепочке поставок, которая приводила ко взлому Apple, Microsoft и десятки других компаний. О результатах исследований багхантер сообщал компаниям. Каждая организация, которая была подвергнута атаке, предоставила ему разрешение на проверку своей безопасности либо в публичной программе вознаграждения, либо в частной форме. Другим ярким примером является багхантер albinowax, который обнаружил технику HTTP Request Smuggling. Она позволяла отправлять двусмысленный запрос, который по-разному обрабатывался frontend- и backend-серверами приложения, что могло дать киберпреступнику возможность получить доступ к пользовательским данным.
Что касается денежного вознаграждения в bug bounty, то и тут есть яркие примеры. Первым, кто заработал 1 миллион долларов на американской площадке HackerOne, был багхантер Santiago Lopez, а другой багхантер inhibitor181 первым заработал на этой же площадке уже 2 миллиона долларов.
С чего начинается багхантинг
Чтобы начать искать уязвимости за вознаграждение, нужно как минимум иметь базовые теоретические и практические знания. А чтобы вознаграждения (как денежные, так и репутационные) становились больше, необходимо постоянно углублять и накапливать эти знания и актуализировать полученный опыт. Упорный труд, концентрация, желание изучать новое и самосовершенствоваться принесут бенефиты в виде денежного вознаграждения и признания в обществе багхантеров.
Технические темы, которые мы рекомендуем изучить будущему багхантеру в обязательном порядке:
- ОС — работа с Linux/Windows, командной строкой Bash/PowerShell, TCP/IP — Model, HTTP/S — Protocol, Port/Socket;
- программирование — один из языков программирования, например Python, Ruby, PHP, Java, JavaScript, и желательно умение пользоваться отладчиком;
- разметка — работа с HTML-разметкой;
- СУБД — реляционные PostgreSQL/MySQL;
- веб-серверы — конфигурация и эксплуатация Nginx, Apache2;
- понимание принципов работы frontend/backend, frameworks;
- вспомогательное ПО — BurpSuite, Metasploit, Docker, netcat, sqlmap, nmap, ffuf, dirbuster.
Примеры самых часто встречающихся уязвимостей
Опираясь на наш отчет, посвященный анализу уязвимостей и угроз веб-приложений в 2020–2021 гг., выделим часто встречающиеся уязвимости и атаки на пользователя в веб-приложениях, которые достаточно просты в эксплуатации:
- Внедрение кода. Одним из видов этого класса уязвимостей является внедрение SQL-кода (SQL Injection). Злоумышленник может вмешиваться в формирование SQL-запроса приложения к базе данных. Как правило, это позволяет злоумышленнику несанкционированно получить информацию. Полученная информация может быть как системной (версия СУБД, наименование и структура таблиц, столбцов), так и пользовательской (ФИО, телефоны, адреса электронной почты, пароли, личные сообщения). Существует несколько видов SQL Injection: in-band, inferential, out-of-band.
- Некорректная нейтрализация входных данных при генерировании веб-страниц (межсайтовое выполнение сценариев). Одной из атак на пользователя является Cross-Site Scripting (XSS). Результат атаки — выполнение вредоносного JavaScript-кода в браузере жертвы. Злоумышленник может похитить cookies пользователя, произвести редирект на фишинговую страницу, отрисовать любое содержимое на текущей странице, считать нажимаемые пользователем клавиши и многое другое. Существует несколько видов XSS: reflected, stored, dom.
- Подделка межсайтового запроса (CSRF). Атака, позволяющая злоумышленнику выполнить от лица жертвы различные запросы на сервер в уязвимой системе, в том числе и критического действия. Результатом может служить несанкционированная смена персональных данных — почты, телефона, пароля, а также выполнение других действий — отправка личных сообщений, публикация постов, перевод денежных средств.
Полезный инструментарий
Использование дополнительного программного обеспечения позволяет ускорить и упростить работу багхантера. Первое, о чем хотелось бы упомянуть, — это BurpSuite от компании PortSwigger. Это программное обеспечение является одним из лучших в своем классе для сканирования уязвимостей, тестирования на проникновение и обеспечения безопасности веб-приложений. Существует бесплатная версия несколько инструментов. Рассмотрим некоторые из них:
- Proxy — перехватывающий веб-прокси, который служит посредником между браузером и веб-приложением. С его помощью багхантер во время своих исследований может перехватывать, изменять и проверять идущий в обоих направлениях трафик.
- Intruder — инструмент, который может использоваться исследователем для проведения автоматизированных и настраиваемых атак.
- Repeater — инструмент для ручной обработки и повторной отправки запросов, а также анализа ответов от приложения.
- Decoder — инструмент для выполнения ручного или интеллектуального кодирования и декодирования данных приложения.
- Extender — инструмент, позволяющий исследователю загружать свои и сторонние расширения Burp.
Другой инструмент, называемый швейцарским ножом белого хакера, пентестера и багхантера, — Metasploit от компании Rapid7. Он является модульным, расширяемым и изначально уже содержит большое количество модулей различного направления: эксплойты, полезные нагрузки, энкодеры и т. д.
Для автоматизации обнаружения и использования уязвимостей SQL Injection и захвата серверов баз данных можно использовать инструмент с открытым исходным кодом — sqlmap. Он содержит большое количество функций. Приведем наиболее важные из них (с остальным функционалом можно ознакомиться на официальном сайте):
- полная поддержка MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, Informix, MariaDB, MemSQL, TiDB, CockroachDB, HSQLDB, H2, MonetDB, Apache Derby, Amazon Redshift, системы управления базами данных Vertica, Mckoi, Presto, Altibase, MimerSQL, CrateDB, Greenplum, Drizzle, Apache Ignite, Cubrid, InterSystems Cache, IRIS, eXtremeDB, FrontBase, Raima Database Manager, YugabyteDB и Virtuoso;
- полная поддержка шести методов SQL Injection: вслепую на основе логических значений (boolean-based blind), вслепую на основе времени (time-based blind), на основе ошибок (error-based), на основе запросов UNION (UNION query-based), стекированных запросов (stacked queries) и внеполосных запросов (out-of-band queries);
- автоматическое распознавание форматов хешей паролей и проверка их на взламываемость с помощью атаки по словарю.
Для сканирования больших сетей, их исследования и аудита безопасности можно использовать программное обеспечение с открытым исходным кодом — nmap. Для него существует и графическая обертка — zenmap.
Для быстрого фаззинга веб-приложения (обнаружения директорий, файлов и параметров) стоит посмотреть в сторону инструмента ffuf с открытым исходным кодом. Его использование должно проходить с явным указанием небольшого количества потоков. Это необходимо для того, чтобы не подвергать высоким нагрузкам исследуемую цель. В противном случае это может привести к замедлению выполнения запросов у других клиентов и к отказу в их обслуживании.
Но все же самым главным является труд, усердие и понимание того, как работают технологии. Багхантеру необходимо совершенствовать свое мастерство, пополнять опыт драгоценными знаниями, отслеживать и изучать новые техники атак и уязвимости.
«Быстрый старт» на настоящих примерах
После того как изучена теоретическая база (самые популярные уязвимости, наиболее часто используемые сценарии атак, базовый список инструментария), самое время закрепить полученные знания на примерах старых версий настоящих систем с открытым исходным кодом, в которых уже были обнаружены уязвимости.
Еще раз повторимся, рассматриваемые ниже примеры исследуются исключительно на старых версиях ПО и речь идет об уязвимостях, которые закрыты или устранены.
Уделим внимание внедрению кода, а именно — SQL Injection. Эту уязвимость рассмотрим на примере MantisBT версии 2.24.3. Эксплойт этой уязвимости CVE-2020-28413 опубликован в специализированном разделе на сайте MantisBT. Поэтому воспроизвести атаку с использованием BurpSuite для перехвата запроса и его повторения, а также sqlmap для более автоматизированного получения информации из базы данных может каждый желающий.
Имеется учетная запись пользователя observer:SEk7AnRiF5 с ролью доступа «Наблюдатель».
Необходимо настроить прокси между браузером и BurpSuite, а после — перехватить POST-запрос на сценарий /api/soap/mantisconnect.php с указанными данными для авторизации пользователя observer.
Согласно эксплойту, уязвимым параметром SQL Injection будет являться значение тега access. Отправляется легитимный, ничего не нарушающий HTTP-запрос:
В ответ сервер возвращает 200-й статус и запрашиваемую информацию:
Однако если заменить значение 1 на одинарную кавычку (‘) в теге access, то в данном случае сервер, согласно эксплойту, должен вернуть 500-й статус с ошибкой о некорректности сформированного приложением и исполняемого базой данных SQL-запроса. Отправление запроса с одинарной кавычкой:
Действительно, сервер отвечает 500-м статусом, а в теле ответа содержится подтверждение наличия уязвимости SQL Injection:
Теперь имеет смысл воспользоваться ранее упомянутым инструментом — sqlmap, с помощью которого можно автоматизировано получить информацию из базы данных, эксплуатируя найденную уязвимость SQL Injection.
Сперва необходимо скачать sqlmap и в его корень папки поместить последний выполняемый запрос с одинарной кавычкой (‘) в текстовом файле с именем, к примеру request. Вместо одинарной кавычки следует поставить звездочку (*), для того чтобы sqlmap знал, какой параметр в запросе необходимо эксплуатировать.
По умолчанию MantisBT именует базу данных как bugtracker. Зная это, мы можем запросить список таблиц, которые находятся в ней:
Результатом будет служить несанкционированное получение списка всех таблиц в базе bugtracker, к которым также можно обращаться и получать их содержимое.
На HackerOne уязвимости SQL Injection оцениваются так:
Пришло время поговорить про атаки на пользователя. В нашем примере будет рассмотрена атака на пользователя «Межсайтовое выполнение сценариев» (XSS) и «Подделка межсайтового запроса» (CSRF).
В начале рассмотрим атаку на пользователя «Межсайтовое выполнение сценариев» (XSS) на примере системы с открытым исходным кодом GitBucket. Для версии 4.37.1 существует публичный эксплойт, с помощью которого авторизованный злоумышленник имеет возможность внедрить вредоносный JavaScript-код на определенные страницы, при просмотре которых он будет исполняться. Выполнение JavaScript-кода в браузере жертвы может привести к краже cookies, редиректу на другую страницу, внедрению кейлогера (вредоносного ПО для отслеживания нажимаемых клавиш), отрисовки формы авторизации с последующей кражей логина и пароля. В рассматриваемой системе при атаке на администратора имеется возможность полностью скомпрометировать сервер.
Покажем метод внедрения вредоносного JavaScript-кода. Для начала авторизованный злоумышленник должен создать свой репозиторий.
После создания репозитория в нем необходимо создать «вопрос» (issues), в заголовке которого злоумышленником размещается вредоносная нагрузка: «>
Далее при посещении главной страницы или страницы злоумышленника (вкладка Public activity) будет исполнен внедренный JavaScript-код в браузере пользователя.
На HackerOne можно посмотреть, насколько опасными могут быть XSS-атаки и как высока может быть награда за их обнаружение.
Рассмотрим другую атаку на пользователя — «Подделка межсайтового запроса» (CSRF) — на примере системы с открытым исходным кодом GitLab. Подделка межсайтового запроса означает, что злоумышленник на контролируемом сайте размещает HTML-форму, которая будет отправлена в уязвимую систему от лица авторизованного в системе пользователя, которого злоумышленник заманил на свой сайт. Последствиями этой атаки может быть смена персональных данных (имя, телефон, почта, пароль), выполнение каких-либо действий, например перевод денежных средств на счет злоумышленника в уязвимой банковской системе или публикация комментариев от лица атакуемого пользователя.
В данном случае уязвимость позволяет создавать сниппеты (/dashboard/snippets) от лица атакуемого пользователя. Перед демонстрацией убедимся, что у текущего пользователя отсутствуют его сниппеты.
На основе публично доступного эксплойта по приведенным выше ссылкам злоумышленник создает на контролируемом сайте страницу с HTML-формой следующего содержания:
После того как авторизованный в системе GitLab пользователь перейдет на сайт злоумышленника с размещенной там формой, от имени этого пользователя выполнится запрос в систему GitLab и будет создан сниппет. После отправки формы сервер вернет ответ, который говорит о том, что сниппет был успешно создан и атака «Подделка межсайтового запроса» на пользователя была проведена.
У атакуемого пользователя появился сниппет с содержимым, которое контролировал злоумышленник.
А вот так оценивают CSRF-атаки на HackerOne:
Российская платформа для багхантинга
Наибольшее количество программ и максимальные выплаты сегодня можно найти на платформе The Standoff 365 Bug Bounty. После запуска на платформе были размещены 16 программ bug bounty, в том числе «Азбуки вкуса», Rambler&Co, VK, Дзена, Skillbox и GeekBrains. В программах VK максимальные награды достигают 1,8 млн рублей за критические уязвимости (и первые выплаты уже одобрены).
Чтобы участвовать в программах bug bounty, багхантеру нужно зарегистрироваться на удобной ему площадке, выбрать понравившуюся программу, внимательно прочитать ее правила, изучить скоуп и начать искать уязвимости. Обнаружив уязвимость или возможность проведения атаки, исследователь пишет отчет, отправляет его и ждет ответа.
Награда будет зависеть от уровня опасности уязвимости. Приведем в качестве примера суммы вознаграждений программы bug bounty от компании VK:
Как и везде, в багхантинге существует конкуренция. Багхантеры сталкиваются с ней, когда, например, отправляют отчет об уязвимости, а его не принимают, устанавливая статус «Дубликат». Эта ситуация означает, что другой багхантер сообщал об этой уязвимости ранее и сейчас, скорее всего, уже идет процесс ее устранения.
Как отправить отчет
Рассмотрим, как отправить отчет, на примере программы bug bounty от Positive Technologies. Ее описание вы найдете здесь. На странице необходимо нажать кнопку «Сдать отчет» и выбрать пункт «Об уязвимости»:
После этого багхантер попадет на страницу отправки отчета об уязвимости. Описание отчета состоит из нескольких пунктов:
- Название — короткое описание того, что нашел багхантер.
- Уровень опасности — он зависит от найденного типа уязвимости — не указан, низкий, средний, высокий, критический.
- CVE — база данных общеизвестных уязвимостей информационной безопасности. Она располагается по этому адресу. В случае, когда багхантер находит уязвимость, которая уже общеизвестна и имеет свой номер CVE, этот номер следует указать при оформлении отчета.
- Описание — детальное описание уязвимости, подробные шаги по ее воспроизведению и рекомендации по устранению.
- Файлы — здесь можно прикрепить дополнительные файлы мультимедиа (видео, скриншоты).
Продемонстрируем пример заполнения отчета о разобранной ранее уязвимости — SQL Injection в MantisBT версии 2.24.3 (CVE-2020-28413):
Заключение
Рост заинтересованности все большего количества компаний в результативной кибербезопасности делает профессию багхантера все более популярной и востребованной. В эпоху глобальной цифровизации, когда сложность и размер приложений постоянно растут, риск появления уязвимостей и их эксплуатации хакерами становится все выше. Внедрение программ bug bounty, как на уровне отдельной компании, так и на уровне специализированной площадки, поможет исправлять уязвимости до того, как ими сможет воспользоваться злоумышленник.
Важно продвигать такие понятия, как наступательная информационная безопасность, этичный хакинг и багхантинг, наряду с обучением программированию. Обширная база доступных учебных материалов позволяет стать багхантером любому человеку. Самое главное — это начать учиться, углублять полученные знания и набирать драгоценный опыт.
Заключительным аккордом перечислим интернет-ресурсы, книги и площадки, которые, на наш взгляд, помогут в изучении багхантинга:
- The Standoff — это киберпространство, в котором воссоздаются операционные и бизнес-процессы, существующие в реальных промышленных, энергетических, транспортных и финансовых компаниях (пространство создано компанией Positive Technologies);
- WebSecurityAcademy — бесплатная онлайн-площадка для обучения веб-безопасности от создателей BurpSuite;
- HackTheBox — масштабная онлайн-платформа для обучения кибербезопасности;
- Pentesterlab и Vulnhub — коллекции уязвимых систем, которые могут быть использованы для тестирования на проникновение и понимания принципов уязвимостей;
- Hacktricks — сборник хакерских трюков и техник, которые встречались в CTF и реальных приложениях;
- GTFOBins — тщательно отобранный список двоичных файлов Unix, которые можно использовать для обхода локальных ограничений безопасности в неправильно настроенных системах;
- The Web Application Hacker’s Handbook — книга о том, как обнаруживать и использовать недостатки безопасности в веб-системах;
- BugBounty Writeups — список отчетов по программам bug bounty;
- OWASP (Open Web Application Security Project) — открытый проект в области обеспечения безопасности в веб-приложениях.
Алексей Соловьев
Старший специалист группы анализа защищенности веб-приложений компании Positive Technologies
��Что еще интересного о багхантинге есть в нашем блоге:
- Как начать заниматься багхантингом веб-приложений. Часть 2
- Как начать заниматься багхантингом веб-приложений. Часть 3
- Как багхантеру искать XSS-уязвимости через наложение парсеров: исследование Positive Technologies
- Как багхантеры ищут уязвимости: лайфхаки и неочевидные нюансы
- Охота за багами: как прокачаться этичному хакеру, чтобы больше зарабатывать на поиске уязвимостей