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

Какие инструменты нужны тестировщику? Об этом мы сегодня порассуждаем в этой статье, в основе которой — доклад Юлии Атлыгиной с прошлого Heisenbug. Видеозапись доклада доступна по ссылке.

Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

«Пирамида тестов» — метафора, которая означает группировку тестов программного обеспечения по разным уровням детализации. Она также даёт представление, сколько тестов должно быть в каждой из этих групп. Несмотря на то, что концепция тестовой пирамиды существует довольно давно, многие команды разработчиков по-прежнему пытаются неправильно реализовать её на практике должным образом. В этой статье рассматривается первоначальная концепция тестовой пирамиды и показано, как её воплотить в жизнь. Она показывает, какие виды тестов следует искать на разных уровнях пирамиды, и даёт практические примеры, как их можно реализовать.

Не так давно в моём учебном заведении прошёл пилотный Хакатон для студентов. Тематика заданий была связана с информационной безопасностью, в том числе шифрованием данных.

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

Дисклеймер 1. Ни ссылок, ни имен, ни пруфов не будет. Как известно, в Интернете можно найти подтверждение или опровержение любому тезису, поэтому не вижу большого в том смысла, покуда это не диссертация, а мнение. Моя цель — предоставить другую точку зрения, основанную на личностном опыте веры на личном опыте.

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

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



Одна из центральных площадей г. Праги (Staroměstské náměstí)

В мае прошлого года на Positive Hack Days VII впервые прошел конкурс HackBattle. Наш стенд привлек большое внимание аудитории. Тогда в соревновании приняло участие почти 100 специалистов по информационной безопасности, а посмотреть финал в большом зале пришло так много зрителей, что невозможно было протолкнуться к сцене (подробнее — в прошлогоднем отчете). Воодушевленные таким интересом со стороны профессионального сообщества, мы решили провести HackBattle 2.0 на PHDays 8. Рассказываем, как прошло соревнование в этом году, а также публикуем задачи из конкурса, чтобы вы попробовали их решить.

На Positive Hack Days 8 в очередной раз прошел старый добрый конкурс по взлому банкоматов Leave ATM Alone. В распоряжении участников были два банкомата, аппаратная часть была предоставлена нашим партнером по банковской безопасности Альфа-Банком. Специально для соревнования мы настроили банкоматы и заложили в них уязвимости. За 15 минут нужно было обойти средства защиты и извлечь деньги из устройства. Призовой фонд составил 40 000 ₽. Попробовать обойти защиту пришли около 40 участников. Леонид Кролле, организатор конкурса и специалист отдела исследований безопасности банковских систем Positive Technologies, рассказал, как это было, и подробно разобрал задания.



Участники конкурса Leave ATM Alone

В распоряжении участников было два банкомата. На одном из них установлено программное обеспечение аpplication сontrol от наших партнеров, предотвращающее запуск недоверенных приложений. Оно не дает запустить ни одно приложение, которое требуется для снятия наличности (привет, Cutlet Maker, BubbleMaker и nemagiya!).

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

Кабели подключения от банкомата и тестового процессинга находятся снаружи, с возможностью подключиться к ним с помощью сетевого шнура (LAN).

Все уведенные из системы деньги игроки забирали себе.

Любые собеседования специфичны. Они отличаются от компании к компании; кроме того, если HR любит использовать нестандартный подход к делу, то у одного и того же специалиста не будет двух одинаковых собеседований. Пройти этот этап трудоустройства бывает очень непросто даже на родном языке — что уж говорить об иностранных.

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

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

• Хотите скрыть наличее у вас некоторых сервисов?
• В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
• Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
• SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

Изображение: DAVID HOLT, CC BY 2.0

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

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

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

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

В то же время есть много чрезвычайно популярных заголовков, которые вообще не новые и не очень полезные. Мы можем это доказать с помощью HTTP Archive, проекта под управлением Google и спонсируемого Fastly, который каждый месяц при помощи WebPageTest скачивает 500 000 сайтов и выкладывает результаты в BigQuery.

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

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

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

CSRF (Сross Site Request Forgery) в переводе на русский — это подделка межсайтовых запросов. Михаил Егоров (0ang3el) в своем докладе на Highload++ 2017 рассказал о CSRF-уязвимостях, о том, какие обычно используются механизмы защиты, а также как их все равно можно обойти. А в конце вывел ряд советов о том, как правильно защищаться от CSRF-атак. Под катом расшифровка этого выступления.


О спикере: Михаил Егоров работает в компании Ingram Micro Cloud и занимается Application security. В свободное время Михаил занимается поиском уязвимостей и Bug hunting и выступает на security-конференциях

Дисклаймер: приведенная информация является сугубо мнением автора, все совпадения случайны.


В том, что CSRF-атаки работают виноват этот Cookie-монстр. Дело в том, что многие веб-приложения используют куки (здесь и далее считаем уместным называть cookies по-русски) для управления сессией пользователя. Браузер устроен так, что, если у него есть куки пользователя для данного домена и пути, он их автоматически отправляет вместе с HTTP-запросом.

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

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


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

Статья отражает личный опыт автора – заядлого программиста микроконтроллеров, которому после многолетнего опыта микроконтроллерной разработки на языке С (и немного на С++) довелось участвовать в крупном Java-проекте по разработке ПО для ТВ-приставок под управлением Android. В ходе этого проекта удалось собрать заметки об интересных различиях языков Java и C/C++, оценить разные подходы к написанию программ. Статья не претендует на роль справочника, в ней не рассматривается эффективность и производительность Java-программ. Это скорее сборник личных наблюдений. Если не указано иное, то речь идет о версии Java SE 7.

Статья опубликована 9 декабря 2014 года
Обновление от 2018 года: RenéRebe сделал на базе этой статьи интересное видео (часть 2)

В минувшие выходные я участвовал в Ludum Dare #31. Но даже до объявления тем конференции из-за своего недавнего увлечения я хотел сделать олдскульную игру под DOS. Целевой платформой выбрана DOSBox. Это самый практичный способ запуска DOS-приложений несмотря на то, что все современные процессоры x86 полностью обратно совместимы со старыми, вплоть до 16-битного 8086.

Я успешно создал и показал на конференции игру DOS Defender. Программа работает в реальном режиме 32-битного 80386. Все ресурсы встроены в исполняемый COM-файл, никаких внешних зависимостей, так что игра целиком упакована в бинарник 10 килобайт.

• https://github.com/skeeto/dosdefender-ld31
• DOSDEF.COM (10 КБ, v1.1.0, работает в DOSBox)

Ведущий исследователь Том Корт из компании Context, предоставляющей услуги информационной безопасности, рассказывает о том, как ему удалось обнаружить потенциально опасный баг в коде клиента Steam.

Внимательно следящие за безопасностью PC-игроки заметили, что недавно Valve выпустила новое обновление клиента Steam.

В этом посте я хочу оправдаться за то, что мы играем в игры на работе рассказать историю связанного с этим бага, существовавшего в клиенте Steam не меньше десяти лет, который до июля прошлого года мог приводить к удалённому выполнению кода (remote code execution, RCE) во всех 15 миллионах активных клиентов.

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

Мы заявили Valve об уязвимости 20 февраля 2018 года, и, к чести компании, она устранила её в бета-ветке меньше 12 часов спустя. Исправление было перенесено в стабильную ветку 22 марта 2018 года.

За несколько недель до форума Positive Hack Days прошел традиционный конкурс «Конкурентная разведка». В этом году мы опирались на проведенный аудит безопасности и киберугроз ICO, во время которого приходилось для уменьшения рисков анализировать всю внешнюю инфраструктуру, включая команду организаторов, разработчиков и консультантов. Мы создали наш конкурс по мотивам реальных проектов.