Absolute134

Всем привет!

Перестал работать сайт, при открытии ошибка User already has more than 'max_user_connections' active connections

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

show full processlist

Что показывает?

Manticore Search, форк Sphinx Search. Или остановиться на Sphinx, который даже иногда стоит по умолчанию на некоторых VPS. Это достаточно надежно и просто. Это быстро. ИМХО, если поиск прям так страшно необходим определенного качества, то лучше использовать подобные системы. 

Ну, понятно, что на крестах оно работает быстро) Просто такого огромного кол-ва записей в таблицах пока нет, думал на PHP обойтись. Тем более TNTSearch поддерживается в Laravel. В любом случае, спасибо. Пока немного покопаюсь с TNTSearch, если уж не судьба, то буду на эти движки смотреть. А Вы тестили и Sphinx и Manticore Search? В чем отличие?   

Первый блин комом (хотя, любой опыт полезен, считаю)) Три дня барахталась ТП хостера с моим поддоменом. В итоге — мягкий самоотвод, по сути, в последнем ответе:

«Изучил тему безопасности на форуме. Насколько я понял, вас заинтересовал момент с возможность загрузки php скриптов в директорию upload с дальнейшей возможностью их запуска из браузера. Но в этом же посте было сказано, чтобы закрыть уязвимость, нужно отключить выполнение php скриптов для новой директории (поддомена), однако без .htaccess это получится реализовать, только разместив поддомен (добавив отдельным сайтов) на отдельном веб-сервере с другим интерпретатором.

 Исходя из вышесказанного, не уверен, что реализация изменения отдачи статики окупит потраченное время и действительно обезопасит сайт. К тому же в upload уже есть .htaccess с запрещающей директивой php_flag engine 0, которая закрывает уязвимость.» 

Поскольку я некомпетентен в вопросах веб-безопасности настолько, чтобы давать им советы как и что надо сделать, да и терпением не отличаюсь (увы), решил не испытывать больше ни свое, ни их. Может быть, позже, когда-нибудь… )

Видимо, издержки виртуального хостинга)

В том же ISPmanager и других панелях — PHP для домена отключается довольно элементарно.
Ну хотя бы вот: docs.ispsystem.ru/ispmanager-lite/php/reyoimy-raboty-php
Или FastPanel: fastpanel.direct/wiki/ru/site-settings#php-settings   

Может кто за WAF  с icms работал и поделится опытом? Нет таких?)

На Sprinthost можно так сделать, спросил сейчас… И, видимо, так и сделаю. А как потом обновляться?

Так вы принципиально ничего не меняете в движке. Прописали в config.php значения ключам upload_root, upload_host, затестили и забыли.

Тут наверное стоит дополнить, что в случае использования виртуального хостинга — некоторые хостеры изолируют сайты друг от друга в рамках одного юзера. Beget, IHC и ряд других. В таких случаях, надо смотреть по ситуации.

А что касается, ICMS — upload на др.домене — всё чётко работает — я тестил) Видимо, изначально задумывалось под мультисайт) В любом случае, очень хорошо что это есть и проработано.   

Что даст перенос /upload на другую директрою (поддомен)? Скажите пожалуйста)

 

Подобное реализовано на PrestaShop. Это возможность отдавать статику, правда частично, в случае ICMS т.к. css, js и прочее из папки templates всё равно грузится с основного домена.
Вкратце:
1. Когда браузер обращается на сервер за какой-нибудь картиночкой — он отправляет cookie в запросе. Если домен отличается, cookie — не отправляются, что несколько уменьшает объем переданного трафика.
2. Домен для отдачи статики можно настроить без выполнения PHP. Тогда даже если вам в upload кому-то удастся загрузить web-shell — он всё равно не будет выполнен при попытки его запуска из адресной строки, впрочем, он всё равно не будет выполнен т.к. .htaccess запрещает, но я бы на один лишь .htaccess не рассчитывал)) Это если мы говорим об Apache.

Кстати, система нормально работает выше корня — на одном уровне с корневой папкой.
По-быстрому затестил — всё вроде работает ничуть не хуже.

index.php

// Подключаем файл первоначальной инициализации окружения InstantCMS
require_once '../bootstrap.php';

nginx

    location /templates {
        alias /var/www/my_user/data/www/templates/;
    }
    location /upload {
        alias /var/www/my_user/data/www/upload/;
    }

аяксы правда не затестил

Поэтому был создан этот топик. 

По поводу безопасности, все имеет целесообразность. Вот вы пишите, что вас будет ломать. Кто? Я могу дать вам гарантию, что вас сломают, например, люди с hackerone. Например, Майл.ru им на этом сайте только выплатил более $2,420,775. hackerone.com/mailru?type=team
То, что сделано людьми, ими и ломается. Вопрос, кто это будет делать и зачем. Если у вас есть бюджет, вы можете создать заявку на hackerone, там собственно все известные сайты есть, и результат не заставит себя ждать. А для школьников, да и не только, эта CMS безопасна, достаточно безопасна.

Обычно безопасность проверяют с учетом окружения. Не только CMS, но и ПО. phpmyadmin бедный щелкают, как орехи. Почему и спросил. Можно организовать атаку не уровня любителя, некоторые могут обеспечить достаточно мощности уровня прав. структур. Вопрос только зачем? Лучше деньги зарабатывать на  hackerone, кто знает и может. Хорошо платят, многие живут этим. Целесообразность ключевое слово.

Майл.ру платит в рамках Bug Bounty. Это не результат шантажа или хакерского вымогательства.

Целесообразность? Ну, вот здесь многие билингом пользуются на своих проектах. Целый компонент под биллинг заточен. То есть ICMS — это сайты с персональными данными, финансовыми операциями. Найдутся добрые люди, поверьте)) У меня лет 5 назад интернет-магазин на PrestaShop китайцы взломали, чтобы просто мой почтовый сервер юзать для рассылок, а вы говорите))

hackerone — это люди и их возможности небезграничны, также как и компетенция. Ну, нашли уязвимости на майл.ру и что? Я на мамбе их находил. Не критичные, но всё же. Не надо идеализировать майл.ру))

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

...

Не проверял, попробуйте. Но я бы лучше просто вынес директорию загрузок файлов на поддомен, тем более что такой функционал — штатный.

Ок, благодарю, попробую таки выше корня — легче отслеживать будет внедрение. в корне только index.php c 444 правами. А статику алиасом nginx и т.д.  Насчёт — не палить уязвимости — услышал)

В таких случаях указывайте название софта чем проводили тестирование

 

Во-первых, ещё не до конца провел тестирование т.к. несколько инструментов для пентестинга  в арсенале имеется, в том числе очень дорогих-лицензионных. Во-вторых, кто занимается разработкой/пентестами итак понимают какой инструментарий/софт был задействован в первом посте. В-третьих, я ещё только осваиваю это нелегкое дело. 

Сейчас меня интересует безопасность  ICMS, а конкретные инструменты для анализа — дело десятое. Интересует т.к. в планах проект, который 100% придут ломать. Поэтому был создан этот топик. 

ICMS — потому что здесь много уже написано того, что требуется, а писать самому на каком-нибудь Ларавеле мне лень/долго, да и есть некоторые пробелы в знании php.

Но честно так и не внял, как повлиять на заголовки, хотя пытался долго

Через перенос строки. Однако функция header всё равно не даст двойной заголовок отправить, но при этом нотис будет.

В остальном, всё поправим, в любом случае спасибо.

Вам спасибо, что работаете над продуктом и его развитием. Сколько уже CMS протестировал — пришел к выводу, что больше всего ошибок допускают разработчики дополнений. 

А может быть есть у Вас набор каких-то рекомендации по максимально безопасной эксплуатации ICMS? Пусть даже это будут какие-то параноидальные советы типа, как в разработках для банковского сектора))

Встанет CMS выше корневой папки с соответствующей правкой путей инклудов в index.php, который один останется в корне?

А должна?

Думаю, да… Ведь новички в мире веба в том числе пользуются продуктом. Да и рядовому веб-мастеру, давайте будем честны, — по барабану — работает и ладно.

Какая там должна быть фильтрация?

Переведите свой результат словами, если вы понимаете суть вашего скриншота, а не просто воспользовались инструментом автоматической проверки.

open_basedir is not set

allow_url_fopen enabled

Если что, не относится к CMS, это настройки PHP на вашем сервере.

Я понимаю. Ставил по дефолту CMSка ведь не требует от юзера отключения опасного параметра allow_url_fopen ?

В общем господа, вроде бы работает. На мобилках отключается.

if($device_type != 'desktop'){
		$(function(){		
            $("#etaj_filter163 option[value='']").remove();		
			$("#sroc_filter163 option[value='']").remove();
			$("#orientir_filter163 option[value='']").remove();
			$("#rion_filter163 option[value='']").remove();
			$("#metro_filter163 option[value='']").remove();
			$("#teh_filter163 option[value='']").remove();
		});
		};

Ну и собственно поместить в шаблон виджета труда не составит))

Можно в одну строчку выбрать эти элементы.

$('select[id$="_filter163"] option:first-child').remove();