В общем уже сам нашел отличия от официальной версии 1.4.14:
# diff jquery.scrollto.js ~/jquery.scrollTo-1.4.14/jquery.scrollTo.js
42,44c42
<
< if ('scrollingElement' in document) return document.scrollingElement;
<
---
>
189c187
< }));
\ No newline at end of file
---
> }));
Если кто-нибудь подскажет, зачем добавлена эта строчка, буду очень признателен.
Вы не поняли главного, что безопасность всегда обеспечивается принципом: «все что не разрешено — запрещено», а не «все что не запрещено — разрешено», который реализован у вас.
На счёт скрипта проверяющего все возможные расширения config.php — ситуация скорее параноидальная (без обид).
Да ну что вы такое говорите, вот беглым поиском пара строчек с access логов моего продуктивного сервера (и такая дребедень постоянно):
Эээ нет. Вы кажется не поняли.
1. Директива try_files позволяет из директории сервера скачать любой файл. Именно для это вы добавляете вот этот костыль
location ~ \.(tpl|xml|log|sql)$ {
deny all;
}
— это очень плохой подход. Вы не можете знать о том, какие еще файлы могут оказаться в директориях движка и как доступ к ним может повлиять на безопасность. Пример: есть скрипты сканирующие стандартные директории типа config/ на предмет артефактов: config.php запрещен, ок, но у вас например не запрещены такие файлы как .swp .bak .~ и т.д., которые могут создаваться редакторами. А как насчет .gz? .backup? .old? Уверены? А если еще какой-то разработчик будет работать в директории он ничего не оставит? Поэтому такой подход очень плохой. Я запускаю скрипт который будет раз в минуту проверять создание копий config.php со всеми возможными расширениями, и как только он появится у меня будет пароль от БД. (примеров может быть сколько угодно).
2. Вот этот локейшен
location ~ \.php$ {
— разрешает выполнение ЛЮБОГО php файла в серверной директории. То есть представим такую ситуацию — в какой-нибудь поставке какого-нибудь плагина просто тупо лежит уязвимый php скрипт. Да можно хоть специально его туда подложить и раздавать на каких-нибудь левых ресурсах (например раздавать бесплатно платный плагин). Другой пример: предположим каким-то образом разрешена загрузка файлов с расширением php во временные директории внутри серверной директории и мы можем узнать имя файла после загрузки.
И самое главное что все это закрывается элементарно.
Не используйте try_files — это создает проблемы с безопасностью. К тому же зачем вам проверять листинг директории? Не используйте локейшены с шаблоном по *.php — еще одна дырка, ди и они вам вообще не к чему. Или у вас на одном server_name несколько движков с доступом по index.php?
И не придется городить костыли, типа таких (кстати почему только tpl и php)?
Мой комментарий был для автора, я предложил объяснение почему у него все нормально отображается, тогда как у других пользователей проблемы с шрифтами. Но возможно причина в другом.
Что будет если после '#' или '@' идет тег или имя пользователя с пробелом или другими не буквенными символами? При редактировании (например пишу '#' + 2 символа) я так понимаю выпадающий список с подсказкой не появляется?
Вы зашли на сайт. Открылась сессия. Ваша сессионная кука по умолчанию живет 1440 сек. При отсутствии активности сессия вычищается на сервере скриптом или сборщиком мусора. Далее, если стояла галочка «запомнить меня», то на сервере в табличку сессий или куда-то еще должна была записаться строчка с персистентной кукой (здесь кажется это называется ключ сессии). Если вы повторно заходите на сайт, то первым делом сессия открывается заново, с перегенерацией session_id или без (конкретно в лайвстрите насколько я помню без). Скрипт обнаруживает, что сессия уже дропнулась (нет user_id). Если при этом у вас в куках установлена вторая кука с ключом, то скрипт смотрит в табличку и если сессия такая существует он заново устанавливает вам user_id в сессию, после чего вы считаетесь полностью авторизованным.
Писать что-либо в сессию и проверять бессмысленно, сессия снова дропнется. Этот прием защищает только если злоумышленник украдет вашу сессионную куку и нарисуется в итервале времени жизни сессии на сервере. Если же он украл персистентную куку (ключ сессии) то он спокойно зайдет, переоткрыв новую сессию. На другой чаше весов испорченный пользовательский опыт.
Надо делать как я сказал выше — писать IP в таблицу сессий, закрывать старые и открывать новые, принудительно закрывать при смене IP, проверять помимо прочего не закрылась ли сессия.
Ну и кагбэ сессия на сервере живет очень не долго. К примеру на дебиане это по умолчанию 1440 сек. Через этот интервал времени на сервере сессии уже нет и проверять нечего. Нужно работать с таблицей сессий и закрывать персистентную сессию, или сессии (то что с галочкой «запомнить меня» открывается).
Не делайте так по умолчанию хотя бы. IP может меняться в рамках даже одной сессии, если пользователь включил сжатие трафика в Chrome (пока это есть только в мобильном) или Opera, если используются прокси, или анонимайзеры. Сталкивался с провайдерами которые почти каждый раз выдавали динамический IP. Постоянно скидывалась сессия и приходилось перелогиниваться. Другая банальная ситуация — вы пошли в кафе и решили проверить личку подключившись к WiFi.
Теперь внимание, UserAgent — включает номер версии, который будет меняться после каждого обновления браузера, что так же будет приводить к сбросу.
Испортите user experience. Лучше реально выявлять и закрывать XSS.
Все просто, к «сайту на ЛС» (shophelp.ru) прилагается форум с 185 тыс пользователей (shophelp.ru/forum). Часть из них, вероятно, боты, но порядок конечно впечатляет. Так что сайт не на ЛС, а на vBulletin скорее.
Знак охраны авторского права (ст. 127 ГК РФ, т.н. «копирайт») ставится для того, чтобы показать что исключительное авторское право на это произведение защищено. Его использование не обязательно. Авторское право возникает автоматически с момента создания результата интеллектуальной деятельности, и никак от знаков охраны не зависит. Продавая шаблон на сайте, автор явно выразил свое намерение передать права в некотором объеме другому лицу (заключить лицензионный договор), и если в лицензии нет об этом особого положения, или положения о запрете кастомизаций, автор не вправе требовать установки такого копирайта. (Или наоборот, покупатель может быть вправе требовать оплаты рекламы.)
Кстати говоря, в случае кастомизации, если это разрешено, или как-то отдельно не оговаривается лицензией, из исходного шаблона создается (уже покупателем) новый результат интеллектуальной деятельности, авторским правом на который, в объеме переработки обладает покупатель, как его автор. При условии соблюдения авторских прав на исходное произведение. То есть копирайт автора шаблона будет вообще не уместен.
# diff jquery.scrollto.js ~/jquery.scrollTo-1.4.14/jquery.scrollTo.js 42,44c42 < < if ('scrollingElement' in document) return document.scrollingElement; < --- > 189c187 < })); \ No newline at end of file --- > }));Если кто-нибудь подскажет, зачем добавлена эта строчка, буду очень признателен.
Да ну что вы такое говорите, вот беглым поиском пара строчек с access логов моего продуктивного сервера (и такая дребедень постоянно):
(домен изменен)
1. Директива try_files позволяет из директории сервера скачать любой файл. Именно для это вы добавляете вот этот костыль
location ~ \.(tpl|xml|log|sql)$ { deny all; }— это очень плохой подход. Вы не можете знать о том, какие еще файлы могут оказаться в директориях движка и как доступ к ним может повлиять на безопасность. Пример: есть скрипты сканирующие стандартные директории типа config/ на предмет артефактов: config.php запрещен, ок, но у вас например не запрещены такие файлы как .swp .bak .~ и т.д., которые могут создаваться редакторами. А как насчет .gz? .backup? .old? Уверены? А если еще какой-то разработчик будет работать в директории он ничего не оставит? Поэтому такой подход очень плохой. Я запускаю скрипт который будет раз в минуту проверять создание копий config.php со всеми возможными расширениями, и как только он появится у меня будет пароль от БД. (примеров может быть сколько угодно).
2. Вот этот локейшен
location ~ \.php$ {— разрешает выполнение ЛЮБОГО php файла в серверной директории. То есть представим такую ситуацию — в какой-нибудь поставке какого-нибудь плагина просто тупо лежит уязвимый php скрипт. Да можно хоть специально его туда подложить и раздавать на каких-нибудь левых ресурсах (например раздавать бесплатно платный плагин). Другой пример: предположим каким-то образом разрешена загрузка файлов с расширением php во временные директории внутри серверной директории и мы можем узнать имя файла после загрузки.
И самое главное что все это закрывается элементарно.
Не используйте try_files — это создает проблемы с безопасностью. К тому же зачем вам проверять листинг директории? Не используйте локейшены с шаблоном по *.php — еще одна дырка, ди и они вам вообще не к чему. Или у вас на одном server_name несколько движков с доступом по index.php?
И не придется городить костыли, типа таких (кстати почему только tpl и php)?
location ~* /templates/.*\.(tpl|php)$ { deny all; }Писать что-либо в сессию и проверять бессмысленно, сессия снова дропнется. Этот прием защищает только если злоумышленник украдет вашу сессионную куку и нарисуется в итервале времени жизни сессии на сервере. Если же он украл персистентную куку (ключ сессии) то он спокойно зайдет, переоткрыв новую сессию. На другой чаше весов испорченный пользовательский опыт.
Надо делать как я сказал выше — писать IP в таблицу сессий, закрывать старые и открывать новые, принудительно закрывать при смене IP, проверять помимо прочего не закрылась ли сессия.
Теперь внимание, UserAgent — включает номер версии, который будет меняться после каждого обновления браузера, что так же будет приводить к сбросу.
Испортите user experience. Лучше реально выявлять и закрывать XSS.
Кстати говоря, в случае кастомизации, если это разрешено, или как-то отдельно не оговаривается лицензией, из исходного шаблона создается (уже покупателем) новый результат интеллектуальной деятельности, авторским правом на который, в объеме переработки обладает покупатель, как его автор. При условии соблюдения авторских прав на исходное произведение. То есть копирайт автора шаблона будет вообще не уместен.