Это третья часть серии по веб-безопасности: вторая часть была «Web Security: введение в HTTP», первая "Как работают браузеры — введение в безопасность веб-приложений".

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

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

Привет, Хабр! Меня зовут Павел Липский. Я инженер, работаю в компании Сбербанк-Технологии. Моя специализация — тестирование отказоустойчивости и производительности бэкендов крупных распределенных систем. Попросту говоря, я ломаю чужие программы. В этом посте я расскажу о fault injection — методе тестирования, который позволяет находить проблемы в системе путем создания искусственных сбоев. Начну с того, как я пришел к этому методу, потом поговорим о самом методе и о том, как мы его используем.

Задача

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

1. Специфичное название с сокращениями, которое может быть понятно только кассирам местного супермаркета, либо заядлым покупателям.
2. Запрос на естественном языке, введенный пользователем в поисковую строку.

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

Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.

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

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

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

Каждый день полтора миллиона людей ищут на Ozon самые разные товары, и к каждому из них сервис должен подбирать похожие (если пылесос все-таки нужен помощней) или сопутствующие (если к поющему динозавру нужны батарейки). Когда видов товаров тоже много, решить задачу помогает модель Word2Vec. Разбираемся, как она работает и как создавать векторные представления для произвольных объектов.

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


Так о чём же надо помнить, чтобы делать работу качественно, и SEO-специалисты были довольны вашей работой?

К сожалению в интернете довольно мало информации по миграции реальных приложений и продакшн эксплуатации Percona XtraDB Cluster (далее PXC). Своим рассказом я постараюсь исправить эту ситуацию и рассказать о нашем опыте. Тут не будет пошаговой инструкции по установке и статью следует рассматривать не как замену офф документации, а как сборник рекомендаций.

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



Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

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

Q: Что у нас есть?
A: Статистика, собранная с хостов.

Q: Что мы хотим получить?
A: Топологию сети! Точнее, нужно построить правильную цепочку пиров (хостов) для RingSync.

Нам предстоит придумать алгоритм, который вначале превратит статистику в топологию сети, а затем – в цепочку пиров. Пока алгоритм выглядит так:

статистика –-[*магия*]--> топология сети --[*магия*]--> цепочка пиров

Где-то в голландской студии XD Design работает яростный фанат Старкрафта. Только вместо пилонов он делает… «антиугонные» рюкзаки. Всего их шесть: первый такой рюкзак под названием Bobby появился в 2016 году. Последний, который доехал до Madrobots — особенно большой и просторный. Он называется Bobby XL, и в него наконец-то можно положить ноутбук серьезных размеров.

Есть у нас веб-приложение. Относительно большое и старое — много-много кода, в котором много-много разных запросов к базе данных. При этом мы не гугл, но несколько тысяч запросов в секунду на сервер БД приходится.

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

Стандартный совет как найти, что нагружает MySQL — включить slow-query-log и посмотреть, какие запросы будут туда попадать. Но в MySQL 5.7 по умолчанию присутствует куда лучший инструмент — sys schema, которая агрегирует данные из performance schema и позволяет их получить простыми запросами, буквально вида «Ok, MySQL, покажи мне топ запросов по максимальному суммарному времени выполнения»

ASP.NET MVC — не самый хайповый, но довольно популярный стек в среде веб-разработчиков. С точки зрения (анти)хакера, его стандартная функциональность дает тебе кое-какой базовый уровень безопасности, но для предохранения от абсолютного большинства хакерских трюков нужна дополнительная защита. В этой статье мы рассмотрим основы, которые должен знать о безопасности ASP.NET-разработчик (будь то Core, MVC, MVC Razor или Web Forms).

Фреймворк Bootstrap — это свободный набор инструментов для создания интерфейсов сайтов и веб-приложений. Его возможности ориентированы исключительно на фронтенд-разработку. Bootstrap — проект весьма популярный, о чём, например, говорит то, что он занимает (по состоянию на начало марта 2018-го года) второе место по количеству звёзд на GitHub.

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

Я уже довольно долгое время хочу формализовать все свои мысли, опыт, ежедневно применяемый на практике, и многое другое в одном месте и предоставить их общественности. Уверен, многим этот материал будет полезен. Он посвящен различным моментам в конфигурации серверного ПО Linux и безопасным подходам к созданию сайтов/приложений на php (все же это до сих пор одна из самых популярных связок, хоть её успешно и подвигают другие технологии. Но советы так же легко применимы и к веб-ресурсам на других технологиях).

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

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

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

Двадцать шестого февраля прошла конференция MariaDB M|18, в которой участвовали 330 ИТ-компаний. На конференции выступил представитель ServiceNow. Он поделился кейсом по управлению «85 тысячами БД по всему миру». Среднее количество запросов в час — 25 миллиардов. Как в ServiceNow работают с такими нагрузками, расскажем под катом.

Движущая сила микросервисов

Возможность разрабатывать, развертывать и масштабировать различные бизнес-функции независимо друг от друга — это одно из самых разрекламированных преимуществ перехода на микросервисную архитектуру.

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

Однако, когда дело доходит до тестирования (или, чего похуже, разработки) микросервисов, выясняется, что большинство компаний по-прежнему испытывает привязанность к допотопному способу тестирования всех компонентов вместе. Создание сложной инфраструктуры считается обязательным условием для проведения сквозного (end-to-end) тестирования, при котором набор тестов для каждого сервиса обязательно должен быть выполнен — делается это для того, чтобы убедиться, что в сервисах не появилось регрессий или несовместимых изменений.

В 2018 году в истории ЕГАИС наступает новый этап – обязательный помарочный учет алкогольной продукции. Подготовка к переходу на новую схему работы уже стартовала. С сентября 2017 г. планомерно менялся состав документов и реквизитов ЕГАИС у оптовиков. Теперь пришло время и розницы. Как автоматизировать алкогольную розницу по новым правилам, рассмотрим подробно в этой статье.

Docker начиная с версии 17.05 и выше стал поддерживать многоэтапные сборки (multi-stage builds). С удивлением обнаружил, что никто еще не написал об этом на хабре. Поэтому давайте исправим этот пробел.