PDF можно просматривать, если есть PDF-плагин в браузере. В Chrome/Safari плагин есть по умолчанию, в остальных браузерах появляется при установке Adobe Reader.
указатель на структуру {
serial number
хэштейбл
счетчик
kqueue, pipe или futex — любой из них
}
В потоке, который что-то пишет:
loop{
если сохраненный в потоке serial number отличается от текущего {
— блокирую мутекс
уменьшаю сохраненный в потоке счетчик.
Если сохраненный в потоке счетчик равен 0 — шлю событие через футекс, очередь или пайп
сохраняю локально в потоке текущие serial number и указатель на структуру
увеличиваю сохраненный в потоке счетчик
— разблокирую мутекс
}
использую сохраненный в потоке хэштейбл
}
в потоке, который сериализует/ротейтит/удаляет:
loop {
— блокирую мутекс
сохраняю старые указатели на хэш, счетчик, queue/pipe/futex
создаю новые хэш, счетчик, queue/pipe/futex
инкременчу serial
— разблокирую мутекс
пока(счетчик!=0)жду событие от kqueue/pipe/futex
сериализую/освобождаю старые хэш, счетчик, queue/pipe/futex
жду остаток секунды
}
итого — раз в секунду одна блокировка мутекса на каждый поток + раз в секунду одно создание+запись+чтение kqueue pipe или futex. По-моему никаких особых нагрузок нет, лишних саящих потоков тоже нет.
Кстати, sleep это системный вызов, вполне сравнимый с мутексом по тяжести.
Ее нет, потому что прямо сейчас никто ее не создал. Это не значит, что не придет ботнет из пары сотен тысяч узлов и ее не создаст. Не значит, что завтра не упадет промежуточный маршрутизатор и не прилетят потом разом данные за пол-дня.
Вы может и уйдете — а код останется, нельзя оставлять в коде такие грабли.
Есть механизмы синхронизации между потоками — надо их использовать, иначе потом плавающие 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 нельзя, с домена центра авторизации нет доступа к проектным доменам, т.е. к письмам получить доступ тоже нельзя.
статические данные:
мутекс (постоянный),
указатель на структуру {
serial number
хэштейбл
счетчик
kqueue, pipe или futex — любой из них
}
В потоке, который что-то пишет:
loop{
если сохраненный в потоке serial number отличается от текущего {
— блокирую мутекс
уменьшаю сохраненный в потоке счетчик.
Если сохраненный в потоке счетчик равен 0 — шлю событие через футекс, очередь или пайп
сохраняю локально в потоке текущие serial number и указатель на структуру
увеличиваю сохраненный в потоке счетчик
— разблокирую мутекс
}
использую сохраненный в потоке хэштейбл
}
в потоке, который сериализует/ротейтит/удаляет:
loop {
— блокирую мутекс
сохраняю старые указатели на хэш, счетчик, queue/pipe/futex
создаю новые хэш, счетчик, queue/pipe/futex
инкременчу serial
— разблокирую мутекс
пока(счетчик!=0)жду событие от kqueue/pipe/futex
сериализую/освобождаю старые хэш, счетчик, queue/pipe/futex
жду остаток секунды
}
итого — раз в секунду одна блокировка мутекса на каждый поток + раз в секунду одно создание+запись+чтение kqueue pipe или futex. По-моему никаких особых нагрузок нет, лишних саящих потоков тоже нет.
Кстати, sleep это системный вызов, вполне сравнимый с мутексом по тяжести.
Вы может и уйдете — а код останется, нельзя оставлять в коде такие грабли.
Есть механизмы синхронизации между потоками — надо их использовать, иначе потом плавающие 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?