Ее нет, потому что прямо сейчас никто ее не создал. Это не значит, что не придет ботнет из пары сотен тысяч узлов и ее не создаст. Не значит, что завтра не упадет промежуточный маршрутизатор и не прилетят потом разом данные за пол-дня.
Вы может и уйдете — а код останется, нельзя оставлять в коде такие грабли.
Есть механизмы синхронизации между потоками — надо их использовать, иначе потом плавающие race conditions будут ловить годами, вспоминая о вас с нежностью.
А почему синхронизация с помощью sleep а не с помощью мутексов, например? sleep'ом проблема не решается, а скрывается. Если где-то есть возможность хорошо загрузить процессор и выполнить heap spray, то подобная синхронизация может привести к слепому выполнению кода на сервере.
Там такой переход от знаний о вредоносных сайтах к репутации (внезапно файлов), но почему-то через картинку с профилем хоста. Если имеются ввиду только черные списки вредоносных сайтов, то вопрос снимается.
Для IPv4 поддерживать репутационные базы, которые покрывают очень большой процент хостов достаточно просто. Для IPv6 пока не очень получается — слишком разреженное пространство, слишком большие диапазоны, слишком много бардака.
Это не так, X-Content-Type-Options: nosniff отключает автоопределение типа загруженного контента браузером. Некорректное определение типа может приводить к HTML-инъекциям (включая XSS) через форматы, которые не являются HTML-форатами, например javscript, json и т.п.
Как видите, ID передаётся в открытом виде, в то время как с куками он скрыт в заголовке HTTP-запроса.
Он и в заголовках передается в открытом виде. Проблема не в передаче в открытом виде, а в том, что при передаче через URI идентификатор сеанса может быть доступен третьим сторонам через Referer, утечь в разные счетчики/статистики, виден в истории просмотра и т.д.
Strict-Transport-Security… Этот заголовок сообщает браузеру, что с ресурсом надо работать только по HTTPS, т.е. отправляется при первом редиректе с HTTP на HTTPS (чтобы исключить mitm по HTTP. Естестственно, не защищает, если посещение ресурса происходит впервые для браузера).
Нет, это не так. Strict-Transport-Security сам по себе не производит редиректа. Strict-Transport-Security: должен отдаваться только в HTTPS-версии сайта, в HTTP-версии он не работает. Должен быть И редирект в HTTPS-версию И заголовок Strict-Transport-Security.
Достаточно ли силён алгоритм шифрования, и часто ли происходит его обновление?
Сторого говоря, к атакам information disclosure/leakage (утечка чувствительных данных) это прямого отношения не имеет. Слабые алгоритмы шифрования и MitM — это отдельный класс атак.
10. Невалидированные редиректы
Суть в том, что пользователи, доверяя вашему сайту могут переходить по любым ссылкам. Вы часто встречали сообщение вроде «Вы покидаете наш сайт, переходя по ссылке ...», так вот это и есть не что иное, как простейшая защита от подобного рода уязвимостей. Злоумышленник может воспользоваться подобного рода редиректами через ваш сайт на угодные ему страницы.
Описана другая атака. Open redirect это возможность перенаправить пользователя на другой сайт по ссылке на ваш без каких-либо дополнительных ссылок. Т.е. когда делается 301/302 редирект или его аналог через location в джаваскрипт и т.п. по аргументу, который указан в URL, например.
Тема CSRF не раскрыта, а это самая частая уязвимость и может быть весьма важной.
Вместо конкретного случая PHP include следует рассмотреть общий случай — SSI (server-side include).
Михаил, Вы, возможно, ошиблись записью, потому что буквально в соседней, посвященной biz.mail.ru тусуется руководитель проекта Олег Паринов, которому можно рассказать про ваши потребности. Мне представить необходимость иметь 8000 папок в среднем в одном ящике сложно, а он не только запросто это представит, но еще продумает, как это должно работать, чтобы было удобно, опишет и реализует.
А здесь, если хотите, можем об ошибках поговорить, причем за деньги.
Синхронизуются все папки, которые отдаются по IMAP. Те, что имеют более высокий уровень вложенности синхронизуются во второй.
С какого сервиса синхронизация производится? Если какой-нибудь публичный, можем проверить.
Бороться роботами с роботами — это нормально, но бороться роботами с людьми все-таки не хорошо. Есть много хороших специалистов, которые занимаются какой-то узкой областью. Человек может не знать что такое XSS и отрапортовать переполнение буфера при разборе письма, например :)
Если есть желание, можно попробовать поиграться, например, с Oauth и попробовать угнать сеанс пользователя через XSS в центре авторизации. Мы знаем похожий вектор, но он требует дополнительных, не очень вероятных действий от пользователя. Если получится найти вектор, позволяющий сделать это автоматически — мы или поднимем премии за XSS в центре авторизации, если он неустранимый, или выплатим премию как за уязвимость, если он устранимый.
Звучит парадоксально — но в следствии разделения доступа, прямой ипакт от XSS в почте оказался выше, т.к. есть возможность доступа к письмам. Для XSS в центре авторизации прямого импакта нет — куки центра авторизации HTTP Only и угнать сеанс пользователя через XSS нельзя, с домена центра авторизации нет доступа к проектным доменам, т.е. к письмам получить доступ тоже нельзя.
Нет, это прокатит только для библиотек, которые грузятся в процессе выполнения приложения через LoadLibrary. Но не прокатит для библиотек, которые подключаются через динамическую линковку при старте приложения (а их большинство), т.к. динамическую линковку в Windows выполняет не само приложение и библиотека будет загружена раньше, и DllMain выполнен раньше, чем начнет работу код приложения и будет возможность проверить целостность библиотеки. Скорее всего, есть какой-нибудь способ проверить уже загруженную библиотеку до того, как сработает DllMain, но все равно это пляски с бубном и наколенные решения. Гораздо проще и правильней подписать свои библиотеки и на уровне системы не разрешать загрузку неподписанных.
Я полностью с Вами согласен и чуть ниже написал то же самое. Чтобы это работало на практике, в десктопной системе не должно быть способа загрузить и выполнить приложение другим способом.
Но «должен» и то как сейчас на практике распространяется софт — это ведь разные вещи, да?
Вы может и уйдете — а код останется, нельзя оставлять в коде такие грабли.
Есть механизмы синхронизации между потоками — надо их использовать, иначе потом плавающие race conditions будут ловить годами, вспоминая о вас с нежностью.
Для IPv4 поддерживать репутационные базы, которые покрывают очень большой процент хостов достаточно просто. Для IPv6 пока не очень получается — слишком разреженное пространство, слишком большие диапазоны, слишком много бардака.
Это не так, X-Content-Type-Options: nosniff отключает автоопределение типа загруженного контента браузером. Некорректное определение типа может приводить к HTML-инъекциям (включая XSS) через форматы, которые не являются HTML-форатами, например javscript, json и т.п.
Он и в заголовках передается в открытом виде. Проблема не в передаче в открытом виде, а в том, что при передаче через URI идентификатор сеанса может быть доступен третьим сторонам через Referer, утечь в разные счетчики/статистики, виден в истории просмотра и т.д.
Нет, это не так. Strict-Transport-Security сам по себе не производит редиректа. Strict-Transport-Security: должен отдаваться только в HTTPS-версии сайта, в HTTP-версии он не работает. Должен быть И редирект в HTTPS-версию И заголовок Strict-Transport-Security.
Сторого говоря, к атакам information disclosure/leakage (утечка чувствительных данных) это прямого отношения не имеет. Слабые алгоритмы шифрования и MitM — это отдельный класс атак.
Описана другая атака. Open redirect это возможность перенаправить пользователя на другой сайт по ссылке на ваш без каких-либо дополнительных ссылок. Т.е. когда делается 301/302 редирект или его аналог через location в джаваскрипт и т.п. по аргументу, который указан в URL, например.
Тема CSRF не раскрыта, а это самая частая уязвимость и может быть весьма важной.
Вместо конкретного случая PHP include следует рассмотреть общий случай — SSI (server-side include).
А здесь, если хотите, можем об ошибках поговорить, причем за деньги.
С какого сервиса синхронизация производится? Если какой-нибудь публичный, можем проверить.
Когда бага интересная это вообще как глоток воздуха, с ней и разбираться приятно.
Да и вообще мы за любые баги признательны в пределах разумного.
а, если не секрет, что за сумма (спрос/предложение) и с какой биржи?
А почему не очевиден вариант проверять все, что грузится через LoadLibrary?
Но «должен» и то как сейчас на практике распространяется софт — это ведь разные вещи, да?