Многие приложения используют JSON Web Tokens (JWT), чтобы позволить клиенту идентифицировать себя для дальнейшего обмена информацией после аутентификации.

JSON Web Token – это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON.

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

К примеру, по итогам пентеста в одной компании мы пришли к выводу, что все доступные машины в домене были не ниже Windows10/Windows Server2016, и на них стояли все самые свежие патчи. Сеть регулярно сканировалась, машины хардились. Все пользователи сидели через токены и не знали свои «20-символьные пароли». Вроде все хорошо, но протокол IPv6 не был отключен. Схема захвата домена выглядела так:

mitm6 -> ntlmrelay -> атака через делегирование -> получен хеш пароля локального администратора -> получен хеш пароля администратора домена.

К сожалению, такие популярные сертификации, как OSCP, GPEN или CEH, не учат проведению тестирования на проникновение Active Directory.

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

Итак, для демонстрации используем ноутбук на Kali Linux 2019 и поднятые на нем виртуальные хосты на VMware. Представим, что главная цель пентеста — получить права администратора домена, а в качестве вводных данных у нас есть доступ в корпоративную сеть компании по ethernet. Чтобы начать тестировать домен, нам понадобится учетная запись.

Эта статья является продолжением опубликованной ранее первой части. Если вы еще не успели ознакомиться с ней, рекомендую начать именно с нее.

Я пишу это в основном для себя в будущем, чтобы у меня было куда сослаться, когда кто-нибудь спросит меня, почему я скептичен в отношении веб-компонентов и почему Svelte не компилируется в веб-компоненты по умолчанию. (Тем не менее, он может компилироваться в веб-компоненты, а так же интегрироваться с ними, что подтверждается превосходной оценкой на Custom Elements Everywhere).

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

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

Основная идея проекта — формализация взаимодействия между внутренней ИБ и внешними исследователями, давая четкое указание как и куда направлять информацию об уязвимостях или проблемах безопасности. Формализация взаимодействия — серьезная проблема, не все сайты имеют программы bug bounty, или даже просто указывают контакты специалистов по безопасности. А попытки достучаться через службу поддержки и твиттер зачастую заканчиваются уверениями что «Все так и должно быть», и последующим игнорированием.

Конечно, это будет работать только если компания, размещающая информацию в security.txt, готова проверять и своевременно реагировать на информацию, полученную через этот канал.

Сканеры веб-приложений — довольно популярная сегодня категория софта. Есть платные сканеры, есть бесплатные. У каждого из них свой набор параметров и уязвимостей, возможных для обнаружения. Некоторые ограничиваются только теми, что публикуются в OWASP Top Ten (Open Web Application Security Project), некоторые идут в своем black-box тестировании гораздо дальше.



В этом посте мы собрали восемь популярных сканеров, рассмотрели их подробнее и попробовали в деле. В качестве тренировочных мишеней выбрали независимые точки на двух платформах (.NET и php): premium.pgabank.com и php.testsparker.com.

Мне нужно сделать признание. До того, как я стал респектабельным разработчиком, работающим с такими современными языками, как C# и Java (и тем бурлящим хаосом, который известен нам под именем JavaScript), я был увлечённым фанатом невероятно популярного и неуклюжего Visual Basic.

Моя влюблённость была искренней. Ещё в детстве я учился программировать на языке BASIC. Но не просто на BASIC. Я начинал с потрясающей среды Microsoft под названием QuickBASIC на древней операционной системе DOS. Я всё ещё помню, как набирал белый текст на её бодром голубом фоне.


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


В наши дни QuickBASIC остался лишь ещё одной диковинкой из далёкого прошлого. Хотя так ли это? Новаторский проект под названием QB64 создал современную реплику QuickBASIC. Он запускается на Windows, MacOS и Linux, и не требует эмулятора. При запуске программы в QB64 среда выполняет хитрый трюк — сначала она транслирует код на BASIC в C++, а затем компилирует его.

Классический VB и эра Visual

QuickBASIC был впечатляющей средой для далёких дней текстовых компьютерных систем. Но всё изменилось, когда Microsoft выпустила Windows и погрузила пользователей PC в графический мир кнопок и кликов. Одновременно с выпуском компанией Microsoft Windows 3.0 (первой версии, которая добилась истинного успеха), был выпущен Visual Basic 1.0.

Рисовальная машина за работой, © axisdraw.com

Электронная подпись в России впервые появилась в январе 2002 года вместе с принятием первого закона «Об электронной цифровой подписи» (1-ФЗ). Затем, спустя 9 лет, в апреле 2011 появился новый закон «Об электронной подписи» (63-ФЗ). Спустя еще 8 лет, в начале лета 2019, в СМИ стали появляться леденящие душу публикации о том, как с помощью электронной подписи воруют квартиры, как мошенники оформляют на ничего не подозревающих граждан фиктивные фирмы, и так далее, и тому подобное.

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

Так часто бывает, что техники оптимизации, хорошо работающие для обычной десктопной или мобильной графики, не всегда дают нужный эффект в случае WebGL. В этой статье я собрал (а точнее перевёл на русский язык и изложил в текстовом виде нашу презентацию с Verge3Day) те методы повышения производительности, которые хорошо себя зарекомендовали при создании интерактивных веб-приложений.

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

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

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

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

В список вошли утилиты, предлагаемые резидентами GitHub и участниками тематических тредов на Reddit, — Sysbench, UnixBench, Phoronix Test Suite, Vdbench и IOzone.

Четыре месяца назад на change.org была создана петиция с призывом к руководству Яндекса — автор петиции просит обратить внимание на доступность интерфейсов сервисов Яндекса для слепых и слабовидящих пользователей. Утверждается, что до 2014 года сервисы Яндекса были хорошо оптимизированы для слепых пользователей и совместимы с программами экранного доступа. Впоследствии ситуация начала ухудшаться:

Трудности для каждого незрячего и слабовидящего пользователя начинаются уже при создания аккаунта, но я опишу здесь лишь две наиболее важные и критичные:

1. Слепой человек не может защитить свой аккаунт. При создании ящика на сайте passport.yandex.ru есть возможность задать секретный вопрос для восстановления пароля, но в настоящее время список с вариантом выбора вопроса не озвучивается программой экранного доступа, а значит выбрать ничего нельзя и восстановить утерянный пароль или защититься от потенциальных взломщиков я не могу.

2. Яндекс отказывается предоставлять поддержку слепым и слабовидящим: формы обратной связи, также называемые «Написать в поддержку», имеют список тем обращения, где требуется выбрать какую-то одну. Как вы уже могли догадаться, из этого списка с помощью клавиатуры невозможно ничего выбрать, а значит, нельзя отправить сообщение.

Привет, меня зовут Василий Богонатов. Я один из тех, кто приложил руку и голову и вложил свою душу в сервис распределённых персистентных очередей сообщений Yandex Message Queue. Сервис вышел в общий доступ в конце мая, но внутри Яндекса он уже давно и активно используется в разных продуктах.

Сегодня я хочу рассказать читателям Хабра об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.

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

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

Многие, когда речь заходит о jQuery, говорят так: «Просто пользуйтесь обычным JavaScript. Библиотека jQuery вам не нужна». Что тут сказать? Я не нуждаюсь во многих вещах, но, несмотря на это, хорошо, когда они есть. Так и jQuery. Я в этой библиотеке не нуждаюсь, но её, определённо, приятно иметь под рукой.

Сайты наподобие You might not need jQuery (YMNJQ) продвигают идею, в соответствии с которой от jQuery очень легко избавиться. Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!

Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

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

«Поймай меня, если сможешь». Так называется фильм Стивена Спилберга. Я смотрел, интересно. Но не правда, хоть и основано на реальных событиях.

В действительности, «поймай меня, если сможешь» — это такая игра. Я вижу эту игру каждый день, и даже участвую в ней. И чувствую себя примерно так же, как герой фильма Спилберга – тот, которого Том Хэнкс играет. Я чувствую себя идиотом. Беспомощным идиотом, которого обманывают, глядя в глаза, каждый день. У меня есть власть, но все, что я могу с ее помощью сделать – уволить. Хотя, и это не помогает – приходит новый сотрудник, и игра начинается снова.

Слышали, наверное, такое красивое высказывание: если вы пригласили на работу квалифицированного специалиста, то надо делать то, что он говорит, а не говорить ему, что делать. А вы пробовали делать то, что говорят эти квалифицированные специалисты? Я пробовал. И скажу прямо: это полная чушь.

Встроенный инструмент тестирования Google Lighthouse оценивает доступность (accessibility) сайтов по шкале от 0 до 100. Похвально стремиться к максимальной читаемости контента, но оценка 100 не означает, что сайт идеально доступен. Для доказательства я провёл небольшой эксперимент.

Всегда приятно видеть, как люди хвастаются в твиттере своими оценками Lighthouse: это значит, что они заботятся о качестве.



Lighthouse награждает лучшие сайты зелёным кружочком с цифрой 100, которую вы с гордостью показываете клиентам и друзьям.