Критичное устранение уязвимостей магазинов

[Yoda]

В последнее время, многие авторы шаблонов, начали поголовно практиковать пагубную технику встраивания целых кусков чужого кода в свои шаблоны, без разбора полетов. В связи с этим, по моим данным, около 10-15% популярных шаблонов и содержат в себе потенциальные уязвимости. 

С теми, у кого у меня есть прямая связь, в частном порядке мы закрываем эти дыры с уведомлением покупателей. 
Но со многими я просто физически не могу связаться, так как они отказываются идти на контакт.

 

Поэтому давайте сделаем наши магазины безопаснее вместе.

 

Вот очень полезная статья с большим набором заплаток от разного рода попыток взлома сайтов. Она правда для WP, но по сути техники взлома не сильно отличаются.

 

https://perishablepress.com/6g/

Для продвинутых пользователей, там все достаточно ясно-понятно. Для новичков, я бы рекомендовал добавить в .htaccess  хотя бы это:

<IfModule mod_rewrite.c>
    RewriteCond %{QUERY_STRING} (eval\() [NC,OR]
    RewriteCond %{QUERY_STRING} (javascript:)(.*)(;) [NC,OR]
    RewriteCond %{QUERY_STRING} (base64_encode)(.*)(\() [NC,OR]
    RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|%3C)(.*)script(.*)(>|%3) [NC,OR]
    RewriteCond %{QUERY_STRING} (\\|\.\.\.|\.\./|~|`|<|>|\|) [NC,OR]
    RewriteCond %{QUERY_STRING} (boot\.ini|etc/passwd|self/environ) [NC,OR]
    RewriteCond %{QUERY_STRING} (\'|\")(.*)(drop|insert|md5|select|union) [NC]
    RewriteRule .* - [F]
</IfModule>

Встраивать эту конструкцию необходимо после строки  

RewriteEngine On

После добавления, рекомендую запустить Xenu's

И проверить доступность всех ссылок вашего магазина.

Если появятся страницы с кодом 404 или 500, проведите анализ и удалите исключения из списка, которые мешают нормальному отображению страниц.

Змінено 5 листопада 2016 користувачем Yoda

[vasilev86]

Дыры, Дыры, сегодня кто то продавал мою базу :-D

https://xxx.ru/?utm_source=xxx.ru-%D0%9F%D0%A0%D0%9E%D0%94%D0%90%D0%96%D0%90-%D0%91%D0%90%D0%97%D0%AB-%D0%A1%D0%90%D0%99%D0%A2%D0%90&utm_term=xxx.ru-%D0%9F%D0%A0%D0%9E%D0%94%D0%90%D0%96%D0%90-%D0%91%D0%90%D0%97%D0%AB-%D0%A1%D0%90%D0%99%D0%A2%D0%90 

 

 

 

http://www.google.ru/search?q=

 

ПРОДАМ-БАЗУ-САЙТ
А-xxxx.ru

 

приплыли, это ппц господа. 8-)

Змінено 5 листопада 2016 користувачем vasilev86

[Baco]

Ещё один "безопасник", меньше говнокода писать и кубить... и модерировать что в магазин ставить, а не шаблоны проверять, нынче бизнес какой ?

с3.14здил - заионкубил - продавай... а что внутри ? а какая разница, работает )

 

p.s. вспомнилось из прошлой жЫзни, когда уважаемый человек вопрос задал:

 

а можно ли сделать SQL inject сквозь real_escape_string ?

взломать можно всё, вопрос резона )

[vasilev86]

 

с3.14здил - заионкубил - продавай... а что внутри ? а какая разница, работает )

 

:-D

[ArtemPitov]

а уязвимость то какая была в шаблонах ? 

Пошла тенденция брать забугорное и пихать в шаблон без просмотра что там внутри 

[Yoda]

а уязвимость то какая была в шаблонах ? 

Пошла тенденция брать забугорное и пихать в шаблон без просмотра что там внутри 

 

Уязвимости и дополнения, я не озвучиваю, потому что могут полететь головы, и подобная информация не нужна в открытом доступе. 

Вроде бы актив форума я собрал для выработки решения по вопросу. А вот что с этим делать - так никто и не понимает.

Поэтому единственным возможным вариантом развития событий на сегодня, пока что является защита своими силами.

[chamaerops]

Вопрос такой - есть ли эти дыры в дефолтном шаблоне?

Относится ли данная проблема только к шаблонам или к модулям тоже?

Змінено 6 листопада 2016 користувачем chamaerops

[Yoda]

Вопрос такой - есть ли эти дыры в дефолтном шаблоне?

Относится ли данная проблема только к шаблонам или к модулям тоже?

1 - нет

2 - нет информации.

[ArtemPitov]

Вроде бы актив форума я собрал для выработки решения по вопросу. А вот что с этим делать - так никто и не понимает.

 

Ну тут все просто, писать авторам, если не будут приняты меры - тогда брать "дробовик и срывать бошки"

[markimax]

:) Это не только в безопасности проблемы

Там в SEO вообще полный 3.14, 3.14, 3.14

А все от того что авторы тем по тупому копируют код "бесплатных" модулей где ошибок просто немеряно

К примеру "быстрый просмотр" товаров...

Открываем любую тему (да, да ребята - у всех (99%) там одна большая проблема) и что видим... дубли контента продуктов по разным URL, причем у "быстрого просмотра" без canonical понятное дело.

Как итог - выпадание страниц из индексов ПС, пессимизация контента  и все связанное с этим.

Это я только по "быстрому просмотру" прошелся сейчас. А если детально - все гораздо хуже.

Вообще авторы тем... что за глупость фаршировать темы "бесплатными" модулями, которые в 90% не нужны а в 99% вредны?

 

Вы не можете сделать, отдельно платную тему (с ценой ниже) и отдельно к ней service pack платный (с набором адаптированных под тему модулей)? Кому надо пусть берут sp, кому не надо чистую тему без говнокода "бесплатных" говноподелок

Мухи отдельно, котлеты отдельно

Да и вам легче будет темы обновлять! Да и заработаете больше :?
И не будет проблем ни с SEO ни с безопасностью

Зачем пользователей "принуждать" к проблемам ?

 

Сейчас авторов тем делю на три группы

1. Когда им сообщаешь о проблемах и они со словами благодарности исправляют код (им респект)

2. Когда тебя почти "посылают", как будто ты им в борщ плюнул. (без комментариев)

3. Это когда говорят "спасибо" и ничего не исправляют, а когда напоминаешь - они мотивируют тем, что "тот модуль" не они делали и пиши автору (бред полный :roll: )..

[markimax]

Провел эксперимент... правда не на форуме, пожалел авторов. Тем у кого на форуме я обнаруживаю пробои безопасности  я отписываюсь авторам.

А вот в официальном каталоге дополнений...

... на opencart.com взял самые популярные модули отзывов (с кучей продаж) с загрузкой изображений и ВСЕМ влил php бомбу, без всяких проблем. Ну что еще сказать..

О результатах отписался Yoda

Все ссылки на "бомбы" отправил ему

[sitecreator]

Вопрос по безопасности, напрямую не связанный с Опенкарт. Скорее это вопрос по безопасности сервера как такового.

 

Нередко видел (на проектах, доставшихся для доработки), что  все папки/файлы имеют права 777.  Ну работает ведь магазин.

 

На мой взгляд, при возможности, папок/файлов с правами 777 быть вообще не должно. Достаточно 755 в случае апаче, работающего от имени пользователя.

 

Если вы решили использовать VPS/VDS,  то смысла в использовании прав 777 нет.  максимум 755. Правильно настроенный новый сервер (VPS/VDS) не требует для работы Опенкарт прав 777. Про общий хостинг речь не идет.

 

Даже если "из коробки" сервер VPS/VDS требует прав 777 для работы Опенкарт, то стоит настроить сервер таким образом чтобы это требование не было актуальным.

 

Но кто придерживается этого правила?

И есть ли смысл делать акцент на этом правиле?

При общих равных условиях максимальные права 755 всегда делают сервер более безопасным чем использование 777.

 

разве я не прав?

насколько существенен данный фактор по вашему мнению?

 

в общем, это должно хорошо работать в совокупности с правилами вида:

 

"отключить вывод всех ошибок",

"отключить phpinfo",

"отключить eval"

и т. п.

Змінено 8 листопада 2016 користувачем sitecreator

[markimax]

....

 

разве я не прав?

насколько существенен данный фактор по вашему мнению?

 

в общем, это должно хорошо работать в совокупности с правилами вида:

 

"отключить вывод всех ошибок",

"отключить phpinfo",

"отключить eval"

и т. п.

 

Это вопрос с проблемами безопасности гМОДУЛЕЙ и гТЕМ.

С opencart все в порядке :)

 

В последнее время, многие авторы шаблонов, начали поголовно практиковать пагубную технику встраивания целых кусков чужого кода в свои шаблоны, без разбора полетов.

 

[markimax]

"отключить eval"

 

 

И у всех перестанет работать их любимый Mega Filter PRO PLUS :ugeek: :-D

И другие "любимые" тоже

И вы "ведьме" не докажите что eval это плохо

[jvz]

ashap тоже eval использует

[markimax]

...тоже eval использует

Ну, он то может изменить код быстро. Не думаю что это проблема. А вот "ведьме" не докажешь. Она упрямая :ugeek:

[sitecreator]

не, ну это пипец какой то.... то заионкубируют лажу полную. то eval без всякой на то необходимости...

 

вообще паранойя по защите своих модулей часто зашкаливает.   Порой складывается впечатление, что главная задача модуля - это не дать себя прочитать.  А безопасность и совместимость идет на последнем месте.

 

Недавно столкнулся с презабавнейшей ситуацией с двумя закодированными модулями.  Автор каждого модуля выдвигал условия его использования прямопротивоположные и взаимоисключающие.  Т. е. одновременная их работа на локальной машине вообще была невозможна.

 

eval - это ведь дыра немеряных размеров.  Вот зачем намеренно ухудшать безопасность?  Чтобы защитить свой модуль, но при этом понизить защищенность сайта, читай - бизнеса заказчика?

 

А вот "ведьме" не докажешь.

 

А это кто?

[jvz]

А это кто?

Авторша Mega Filter Pro

[HyperLabTeam]

короч народ
запасаемся вазелином
ведрами

авторша?
я думал это оно...

[sitecreator]

интересно то, что на 2.*  безопасность оказывается ниже чем на 1.5 благодаря "защищенным" модулям?

 

Если раньше авторы модулей для 1.5 не использовали ни eval, ни ioncube, то эти же самые авторы для 2.* используют эту самую гадость, причем ухитряются еще и, нередко, комбинировано (eval + ioncube) это делать....

Змінено 8 листопада 2016 користувачем sitecreator

[RespectS]

Поэтому давайте сделаем наши магазины безопаснее вместе.

...

... Для новичков, я бы рекомендовал добавить в .htaccess  хотя бы это:

<IfModule mod_rewrite.c>
    RewriteCond %{QUERY_STRING} (eval\() [NC,OR]
    RewriteCond %{QUERY_STRING} (javascript:)(.*)(;) [NC,OR]
    RewriteCond %{QUERY_STRING} (base64_encode)(.*)(\() [NC,OR]
    RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|%3C)(.*)script(.*)(>|%3) [NC,OR]
    RewriteCond %{QUERY_STRING} (\\|\.\.\.|\.\./|~|`|<|>|\|) [NC,OR]
    RewriteCond %{QUERY_STRING} (boot\.ini|etc/passwd|self/environ) [NC,OR]
    RewriteCond %{QUERY_STRING} (\'|\")(.*)(drop|insert|md5|select|union) [NC]
    RewriteRule .* - [F]
</IfModule>

Встраивать эту конструкцию необходимо после строки  

RewriteEngine On

После добавления, рекомендую запустить Xenu's

И проверить доступность всех ссылок вашего магазина.

Если появятся страницы с кодом 404 или 500, проведите анализ и удалите исключения из списка, которые мешают нормальному отображению страниц.

Спасибо!