Здравствуйте,
возникла такая ситуация недавно. Браузер был заражен и вставлял код со своими реферальными и аффилиатными ссылками на сайт инстанта любой ветки. Углубившись в проблематику стал вопрос, ведь мало кто застрахован он такого заражения, безобидный вирус лишь заменяет код Вашей рекламы на Вашем сайте и прибыль получает себе. Это касается только тех сайтов используемых незащищенное соединение т.е. без SSL
Уважаемый @SmartControl предложил вариант решения данной проблемы при помощи установки кода Content Security Policy (CSP) на сайте, который блокирует все сторонние скрипты и ссылки не из белого каталога. Установка довольно проста, но в ручном режиме.
Вот и переходим к делу. Хотелось бы автоматизировать данный код и внедрить его в нами любимую CMS. Сам я не силен в написании подобного.
Возможно кто то решал данный вопрос и есть наработки или готовое решение в виде компонента. Таких счастливчиков просьба отозваться) Всем нам это очень поможет если не сейчас, то точно перестрахует в будущем, ведь все мы хотим монетизировать трафик со своих сайтов а не отдавать свой потенциальный или реальных доход нехорошим дядям)
Заранее благодарен за подключение в обсуждение и любую помощь.
InstantCMS 2.X
Разработка компонента CSP
#1
10 сентября 2017 в 00:55
#2
10 сентября 2017 в 04:57
возникла такая ситуация недавно
И вот ответ
то касается только тех сайтов используемых незащищенное соединение т.е. без SSL
Ставить бесплатный SSL и вопрос будет закрыт.
Вот и переходим к делу. Хотелось бы автоматизировать данный код и внедрить его в нами любимую CMS. Сам я не силен в написании подобного.
Вот и отзыв с Хабра о этой защите
Пробовали внедрять на своих проектах. В итоге по статистике собранных отчетов мы помогали 0.5% пользователей (т.е. блокировали действительно вредоносные расширения) и мешали примерно 30% пользователей, т.е. в зависимости от браузера (особенно этим грешит Firefox) при заявленной поддержке данной технологии что-нибудь идет не так и JavaScript (особенно inline) перестает работать. На мобильных платформах вообще практически не поддерживается.
Вы только первый коммент прочитали, а дальше не пошли?)) -у меня работает на нескольких крупных проектах больше года, с мобильными пользователями все нормально и инлайн javascript работает. Может быть им не хватило компетенции настроить, чтобы все работало корректно?Вот и отзыв с Хабра о этой защите
Ваш совет тоже не супер. Посмотрите сначала поддержку браузерами этого бесплатного SSL. Ставить лучше платный (он гарантирует лучшее покрытие, бОльше клиентов смогут открыть ваш сайт) и тщательно подобранный. Вот например ссылка, вроде хороший бренд и неплохие сертификаты, а ставить их не стоит уже… С сертификатами все сложнее и дороже.Ставить бесплатный SSL и вопрос будет закрыт.
Подходить надо с умом и тщательно проверяя — тут согласен. Нельзя просто поставить что-нибудь и как-нибудь (будь то CSP или SSL) и будь что будет.
Вот еще ссылка про CSP — Опыт внедрения на Яндекс.Почте
По поводу поддержки браузерами надо читать аккуратно — пост не новый, сейчас конечно все поменялось немного в лучшую сторону.
Сегодня в 06:21
Вы только первый коммент прочитали, а дальше не пошли?))
И дальше читал, и еще пару штук тем почитал. И не увидел особо ничего.
Ваш совет тоже не супер. Посмотрите сначала поддержку браузерами этого бесплатного SSL.
Поддержка 100%. Написал про Lets Encrypt. Стоит и на своих сайтах и на клиентских прекрасно) При этом получить его — 5 минут времени. Совет отличный и самое простое. А про тот ssl я даже не переходил ибо уже знаю, в том числе и про то, что он уже проходит процедуру замены ssl. Это как раз таки больше знак о безопасности.
#5
10 сентября 2017 в 11:00
@SmartControl, дал очень хороший совет, просто ссылку дал не на самую свежую статью))
Например даже год назад было "The W3C specification allows for 9 directives." W3C поддерживало уже 9 директив.
И конечно поддержка сразу появилась на WP с отчетами и разными настройками, блокировками и тд.
Так что имеет смысл использовать,
Например даже год назад было "The W3C specification allows for 9 directives." W3C поддерживало уже 9 директив.
default-src
The default-src is the default policy for loading content. If another setting is blank then this setting will be used.
script-src
Defines valid sources of JavaScript.
style-src
Defines valid sources of stylesheets.
img-src
Defines valid sources of images.
connect-src
Applies to XMLHttpRequest (AJAX), WebSocket or EventSource.
font-src
Defines valid sources of fonts.
object-src
Defines valid sources of plugins. Stops your site becoming the source of drive-by attacks.
media-src
Defines valid sources of audio and video.
frame-src
Defines valid sources for loading frames.
sandbox
Enables a sandbox for the requested resource similar to the iframe sandbox attribute.
form-action
The form-action restricts which URLs can be used as the action of HTML form elements.
frame-ancestors
Whether to allow embedding the resource using a frame, iframe, object, embed, etc. in non-HTML resources.
plugin-types
Restricts the set of plugins that can be invoked by limiting the types of resources that can be embedded.
report-uri
URL to post information on violations of the policies you set.
Each directive can take one or more of the following values:
*
Allows loading resources from any source.
‘none’
Blocks loading resources from all sources.
‘self’
Refers to your own host.
‘unsafe-inline’
Allows inline elements, such as functions in script tags, onclicks, etc.
‘unsafe-eval’
Allows unsafe dynamic code evaluation such as JavaScript eval()
data:
Allow loading resources from data scheme – usually inline images.
https:
Only allows loading resources from HTTPS: on any domain
www.example.com
Allow loading resources from this domain, using any scheme (http/https)
*.example.com
Allow loading resourcs from any subdomain under example.com, using any scheme (http/https)
www.example.com
Allows loading resources from this domain using this scheme.
/path/to/file/
Allows loading any file from this path on this domain.
/path/to/file/thefile
Allows loading this one file on this domain.
The default-src is the default policy for loading content. If another setting is blank then this setting will be used.
script-src
Defines valid sources of JavaScript.
style-src
Defines valid sources of stylesheets.
img-src
Defines valid sources of images.
connect-src
Applies to XMLHttpRequest (AJAX), WebSocket or EventSource.
font-src
Defines valid sources of fonts.
object-src
Defines valid sources of plugins. Stops your site becoming the source of drive-by attacks.
media-src
Defines valid sources of audio and video.
frame-src
Defines valid sources for loading frames.
sandbox
Enables a sandbox for the requested resource similar to the iframe sandbox attribute.
form-action
The form-action restricts which URLs can be used as the action of HTML form elements.
frame-ancestors
Whether to allow embedding the resource using a frame, iframe, object, embed, etc. in non-HTML resources.
plugin-types
Restricts the set of plugins that can be invoked by limiting the types of resources that can be embedded.
report-uri
URL to post information on violations of the policies you set.
Each directive can take one or more of the following values:
*
Allows loading resources from any source.
‘none’
Blocks loading resources from all sources.
‘self’
Refers to your own host.
‘unsafe-inline’
Allows inline elements, such as functions in script tags, onclicks, etc.
‘unsafe-eval’
Allows unsafe dynamic code evaluation such as JavaScript eval()
data:
Allow loading resources from data scheme – usually inline images.
https:
Only allows loading resources from HTTPS: on any domain
www.example.com
Allow loading resources from this domain, using any scheme (http/https)
*.example.com
Allow loading resourcs from any subdomain under example.com, using any scheme (http/https)
www.example.com
Allows loading resources from this domain using this scheme.
/path/to/file/
Allows loading any file from this path on this domain.
/path/to/file/thefile
Allows loading this one file on this domain.
Так что имеет смысл использовать,
Эхх, ну давайте немного продолжим.Поддержка 100%. Написал про Lets Encrypt.
1. Про 100 это заблуждение. Если бы было все так просто, то вопросов бы не возникало. На официальном сайте Let's Encrypt есть полный список браузеров, которые поддерживают сертификат — я нашел тут. И, конечно, это не 100%.
2. Срок жизни Let's Encrypt всего 90 дней. После этого срока он умирает и его надо продлевать. Если хостер сделает это за вас или сможете настроить cron — отлично. Если нет, то ручками, ручками..
3. На виртуальный хостинг, который их не поддерживает не поставите.
И что интересно, даже на форуме Let's Encrypt советуют настраивать CSP. Не нужно выбирать, надо делать и то, и другое. Сначала можно сделать бесплатный вариант (CSP), а потом купить нормальный сертифитикат (если домен позволяет) или разбираться с бесплатным.
И после всего этого — я ж не против SSL. У меня есть сайты и на https, один на Let's Encrypt (бесплатный), еще один на Comodo (платный). Но это не то решение, которое на 100% удовлетворит всех. Тут есть свои минусы и свои плюсы. И на этих сайтах сначала было внедрено CSP, а потом уже через какое-то время установлены сертификаты.
Да, есть такое… То что первое выскочило в поиске, то и скинул.@SmartControl, дал очень хороший совет, просто ссылку дал не на самую свежую статью))
Я тоже видел под WP плагины, но еще не созрел чтобы это транслировать на InstantCMS — конечно это нужно сделать рано или поздно)И конечно поддержка сразу появилась на WP с отчетами и разными настройками, блокировками и тд.
Так что имеет смысл использовать,
#7
10 сентября 2017 в 11:42
Срок жизни Let's Encrypt всего 90 дней. После этого срока он умирает и его надо продлевать. Если хостер сделает это за вас или сможете настроить cron — отлично. Если нет, то ручками, ручками..
Слушайте ну для вас смешно такое писать. В ISP встроено авто продление, есть масса вариантов делать его автоматически других. Какими ручками?
На виртуальный хостинг, который их не поддерживает не поставите.
А еще если не сесть в автомобиль, то можно долго идти до пункта назначения. Понимаете? Возьмите нормальный ресурс для работы.
Кириллические домены (.рф) не поддерживает.
У меня порядка 50 кириллических доменов у клиентов на серверах. И все работают с этим SSL) Драма у вас прямо с аргументами.
И что интересно, даже на форуме Let's Encrypt советуют настраивать CSP. Не нужно выбирать, надо делать и то, и другое.
Нужно понимать, что CSP может вызвать проблемы и исходя из этого уже думать. А вот SSL проблем не создаст и защиту даст более гарантированную.
Во первых CSP в паре с SSL усиливает защиту.Нужно понимать, что CSP может вызвать проблемы и исходя из этого уже думать. А вот SSL проблем не создаст и защиту даст более гарантированную.
Во вторых криво поставленный SSL даст те же проблемы от криво поставленного CSP или в разы больше. И Наоборот, никаких проблем не будет при корректной установки обоих
И как всегда в таких спорах — ни кто же не заставляет использовать :)
#9
10 сентября 2017 в 11:56
Во первых CSP в паре с SSL усиливает защиту.
Привык читать прежде чем делать. Прочитал что больше проблем для посетителей чем толку — решил себе не заморачиваться. А каждый уже сам решает, что ему важнее. Но это не просто поставить защиту, здесь проблем от него может быть больше чем толку.
Вашу категоричность мне не побороть)Слушайте ну для вас смешно такое писать. В ISP встроено авто продление, есть масса вариантов делать его автоматически других. Какими ручками?
Я просто стараюсь реальней смотреть на вещи и понимаю, что не всем нужен тот же ISP. Если трафик до 3000-5000 уников/сутки, то можно и на виртуальном пожить без проблем, не переплачивая за сервер. Кэширование и оптимизацию никто не отменял.В ISP встроено авто продление
А вообще да — ребят, переводите все свои сервера с сайтами (у меня самого сайты раскиданы по пяти серверам и ISP есть только на одном, бедааа) на ISP и ставьте Let's Encrypt.
Более того, даже лишняя запятая в htaccess может вызвать проблемы, и отсутствие robot.txt и обновление до инстанта 2,8,1. Это же web… тут проблемы на каждом шагу. Добавлю еще, что переход на SSL для старых проектов это не самое веселое, что может быть в жизни вебмастера. А CSP настроить можно без потери трафика и смены протокола.Нужно понимать, что CSP может вызвать проблемы
letsgo, вы предлагаете хорошее решение (правда, не для всех рабочее и зависимое от железа и софта сервере) — но зачем с такой убежденной категоричностью отбрасывать все остальные?) — ладно, не буду продолжать… Цель же комментов не вас убедить, а дать инфу тем, кто об этом не думал и не знал про такие настройки.
#11
10 сентября 2017 в 13:32
Вашу категоричность мне не побороть)
Дело не в категоричности. Вы указали довод, который был неверен. Получение Lets Encrypt давно автоматизированно на многих платформах. И для безопасности это важный момент.
и понимаю, что не всем нужен тот же ISP
Любой нормальный хостер уже автоматизировал получение SSL из Lets Encrypt и его авто обновление.
Более того, даже лишняя запятая в htaccess может вызвать проблемы, и отсутствие robot.txt и обновление до инстанта 2,8,1
Лишь бы метеорит не вызвало)
Вы тут написали страстей. При нормальной оптимизации используют Nginx + PHP-FPM а там, как известно htaccess вообще не работает. но зачем с такой убежденной категоричностью отбрасывать все остальные?)
Чтобы понимали все стороны этого решения. Не категорично, но дав повод задуматься.
Добавлю еще, что переход на SSL для старых проектов это не самое веселое, что может быть в жизни вебмастера. А CSP настроить можно без потери трафика и смены протокола.
Почти все сайты перевёл и старые и новые. В итоге месяц выпадения и всё возвращается. Гугл кстати SSL приветствует, особенно важно там, где есть конкуренция. По второму: можно настроить — если прямо таки железная необходимость, но понимая, что могут быть и негативные последствия.
#12
11 сентября 2017 в 12:16
Цель же комментов не вас убедить, а дать инфу тем, кто об этом не думал и не знал про такие настройки.
Спасибо.
что переход на SSL для старых проектов это не самое веселое,
Весомый аргумент. Для интернет магазинов выпадение даже на месяц не вариант. Тем более что может быть месяц а может быть и неопределенный срок.
#13
11 сентября 2017 в 16:05
Тем более что может быть месяц а может быть и неопределенный срок.
Нда уж) Вот уж действительно. Больше месяца не было разрыва, во вторых для магазина SSL это не просто рекомендация а уже как бы строгое правило, а в третьих то что при CSP — треть посетителей не смогут нормально использовать сайт не смутило?
И четвертое — магазины как раз таки не имеют 100% завязки на поисковики, там разные каналы траффика, которые не пострадают настолько, как магазин будет слетать в позициях из за отсутствия SSL. Сейчас еще мягкий период, дальше будет хуже без SSL.
а в третьих то что при CSP — треть посетителей не смогут нормально использовать сайт не смутило?
Да откуда ж у вас такие сказки? — ну правда… какая треть, почему не четверть или половина. Можно ругать и не соглашаться, но про "треть" это же просто ерунда… Давайте пруфлинк что-ли. Весь мир подключает CSP и все нормально, а вот у нас почему-то должно все рухнуть.
И согласен, и не согласен. Зависит от того, что собой представляет интернет-магазин. Если там есть регистрация-авторизация и прием платежей, то ДА — SSL надо. Но SSL не отменяет CSP, это вообще разные вещи. Никак не связанные и не заменяющие друг друга. Первое — это зашифрованный протокол, а второе — это политика безопасности.во вторых для магазина SSL это не просто рекомендация а уже как бы строгое правило
letsgo, давайте еще пост — перейти.
Конечно, такой возможностью пользуются не только злоумышленники — есть и вполне «белые» плагины и расширения браузера, которые с помощью такого яваскрипта делают полезные вещи. Например, советник яндекса, или плагин от Evernote. Но в большинстве случаев это именно малвари. И, к сожалению, SSL тут не спасет — половина этой малвари грузится через https, а внедрение происходит на уровне браузера.
И еще, ссылка на статью от гугла, про CSP и SSL — и пример прописывания CSP на SSL сайте
#15
11 сентября 2017 в 18:54
Да откуда ж у вас такие сказки? — ну правда… какая треть, почему не четверть или половина. Можно ругать и не соглашаться, но про "треть" это же просто ерунда… Давайте пруфлинк что-ли.
Себя цитировать? Надеюсь отзыв найдёте.
Вот и отзыв с Хабра о этой защите. Спойлер
Хотелось бы и ваш пруфлинк, что весь мир ставит это)
согласен, и не согласен. Зависит от того, что собой представляет интернет-магазин. Если там есть регистрация-авторизация и прием платежей, то ДА — SSL надо.
Наивно однако. Вопрос в том, что поисковики видят "интернет-магазин" а не "интернет магазин без оплаты".
давайте еще пост — перейти.
Так вот может с этого и стоит начать?) Чтобы понять масштаб проблемы. Читаем статью на спруте и смотрим в Ли статистике "Переходы на другие сайты". И результаты у кого какие, есть ли проблема и стоит ли это того для вас.
Евгений, во всём есть плюсы и минусы, но тем не менее стоит сначала каждому глянуть — есть ли проблема то. Ведь она решается не только вами, разработчики браузеров, антивирусы итд активно борятся с этим. Вот для примера глянул два сайта у себя с посещаемостью и близкие к развлекательным (так как всегда много всего) — за август сентябрь 1 переход на другой сайт. Не стоит также забывать, что зачастую ряд решений двигает маркетинг, особенно он интересен в сфере безопасности. Решений много, но каждый новый вирус все равно охватывает многих.