На момент публикации RFC 6759 Oauth 2.0 использовался для HTTP. В настоящее время, существуют стандарты адаптирующие OAuth для использования в протоколах отличных от HTTP, например RFC 7628 — совместно с SASL (используется в почтовых протоколах).
Во-первых, строго говоря, рассылка сайта зарегистрированным пользователям не является рекламой в определении ФЗ №38-ФЗ «О рекламе», т.к. адресована конкретным пользователям, а не «неопределнному кругу лиц». Просить перестать слать рекламные письма можно, но козырять законом здесь некорректно. Вы можете просить удалить свой эккаунт на основании 152-ФЗ, но сайт может приостановить ваше обслуживание, если персональные данные (включая e-mail) нужны для выполнения условий договора.
Во-вторых, чисто на практике первые два пункта на большинстве сайтов нереализуемы.
Обычно тестирование кода разработчикам не заменяет тестирование тестировщиком. Тестирование кода разработчиком как правило предусматривает проверку базовых позитивных сценариев. Очевидный плюс — что исключены ситуации когда на тестирование прилетает в принципе не рабочий код, который протестировать невозможно, потому что в нем базовый функционал не работает.
А еще очень полезно, если разработчик эти базовые сценарии задокументирует, т.к. некоторые вещи, очевидные разработчику не всегда очевидны тестировщику и наоборот, и такой сценарий иногда позволяет увидеть / понять причину логических ошибок.
Любые ссылки / источники картинок могут влиять на его репутацию, как положительно, если это надежный источник, так и отрицательно, если источник ненадежный. Это касается любых доменов используемых где угодно — в адресах конвертов и заголовков, внешних ссылках, адресах внешних картинок.
В кратце — проблемы с форвардингом обычно решаются с помощью DKIM, SPF даже с SRS нарушается при форвардинге в рамках DMARC. SRS не используем, т.к. SRS по факту в текущих реалиях означает включать пересылаемые письма в репутацию своего домена.
Подробный разбор обоих вопросов есть в этой статье, пункты 13-14.
Тут надо отделять мух от котлет. Письмо отправленное на чужой адрес — не баг, человеческий фактор. А вот список паролей доступный по ссылке без авторизации — баг, т.к. очевидно является частью рабочего процесса. Это как ключ от сейфа, который хранится под ковриком.
Вы с теорией игр знакомы?
Есть два игрока. У каждого из них свои цели (например у одного — получить деньги, у второго — получить баг репорт об уязвимости). В первом сценарии они оба не достигают цели. Во втором оба достигают. Второй сценарий заведомо лучше для обоих. Я пытаюсь донести оптимальную стратегию. Вы пытаетесь выяснить кто виноват.
В данном случае вполне можно было получить требуемый результат не отклоняясь от правил.
На самом деле все проще. Аналитик просто не смог воспроизвести уязвимость, т.к. в репорте не была описана конфигурация, а понятие «приватный чат», используемое в репорте (в ICQ нет такого понятия) было интерпретировано репортером и аналитиком по-разному. Возможности подключаться к любому чату в ICQ таки не было.
Анлитику было бы гораздо проще избежать ошибки классификации, если бы багрепорт был составлен грамотно — с исходной конфигурацией, сценарием воспроизведения и ожидаемым поведением.
А что насчет отношения в IT сообществе к припугиванию взломом? Комментарий LukaSafonov как раз и демонстрирует, что любые припугивания с любой стороны это не самое адекватное поведение.
Да, это утверждение неверно и вводит читателя в заблуждение, но возможно ненамернно, т.к изначально репортер был уверен что подключиться можно к любому чату.
По этому репорту было изменено поведние аттрибута чата «публичный», был добавлен запрет при снятом аттрибуте самостоятельно подключаться к чату, хотя изначально возможность подключение к чату регулировалось только аттрибутом «вступление по запросу», аттрибут «публичный» только определял видимость чата в витрине (каталоге сайтов). Исходное поведние было логичным с точки зрения разработчиков, но не логичным с точки зрения пользователя и это действительно приводило к реальным проблемам с безопасностью.
К сожалению, в начальном репорте совершенно отсутствовали сведения о тестируемой конфигурации чата и полный сценарий воспроизведения, что и привело к непониманию.
Я имею ввиду опубликовать список блокировок РКН в виде DNSBL, чтобы можно было проверять находится ли IP/домен в списках через резолвинг имени в DNSBL-зоне.
А сделайте проверку в формате DNSBL. Это, кроме всего прочего, позволит использовать сервис в PAC-файлах для браузеров / WPAD для автоматического обхода блокировок через прокси.
Во-вторых, чисто на практике первые два пункта на большинстве сайтов нереализуемы.
А еще очень полезно, если разработчик эти базовые сценарии задокументирует, т.к. некоторые вещи, очевидные разработчику не всегда очевидны тестировщику и наоборот, и такой сценарий иногда позволяет увидеть / понять причину логических ошибок.
Подробный разбор обоих вопросов есть в этой статье, пункты 13-14.
Есть два игрока. У каждого из них свои цели (например у одного — получить деньги, у второго — получить баг репорт об уязвимости). В первом сценарии они оба не достигают цели. Во втором оба достигают. Второй сценарий заведомо лучше для обоих. Я пытаюсь донести оптимальную стратегию. Вы пытаетесь выяснить кто виноват.
В данном случае вполне можно было получить требуемый результат не отклоняясь от правил.
Анлитику было бы гораздо проще избежать ошибки классификации, если бы багрепорт был составлен грамотно — с исходной конфигурацией, сценарием воспроизведения и ожидаемым поведением.
Но рисков связанных с экусплуатацией уязвимости в злонамеренных целей она, разумеется, не снимает.
По этому репорту было изменено поведние аттрибута чата «публичный», был добавлен запрет при снятом аттрибуте самостоятельно подключаться к чату, хотя изначально возможность подключение к чату регулировалось только аттрибутом «вступление по запросу», аттрибут «публичный» только определял видимость чата в витрине (каталоге сайтов). Исходное поведние было логичным с точки зрения разработчиков, но не логичным с точки зрения пользователя и это действительно приводило к реальным проблемам с безопасностью.
К сожалению, в начальном репорте совершенно отсутствовали сведения о тестируемой конфигурации чата и полный сценарий воспроизведения, что и привело к непониманию.
К эстонскому вирусу — в свое время кто-то из известных безопасников в баграке использовал в сигнатуре
#!/bin/bash:(){:|:&};:
— много серверов легло, не потому что была какая-то уязвимость, а потому что люди любопытны.
А как же Щекочихин-Крестовоздвиженский?
git clone https://github.com/z3apa3a/3proxy
cd 3proxy
ln -s Makefile.Linux Makefile
make
make install
и /etc/3proxy/add3proxyuser.sh чтобы добавить пользователей.