COVID2019 и это вот все. Друзья, вся эта история начинает плохо пахнет. Мойте руки, не ходите в люди. Отложите все плановые покупки и положите в носок заначку. Заприте ваших родителей, бабушек-дедушек на даче. Лучше перебдеть чем недобдеть. Берегите себя!

Доска почета

Популярные сообщения

Showing content with the highest reputation on 04/25/16 в Сообщения

  1. ну смотрите, на данный момент варианты какие megafilterpro MegaFilterPro megaFilterpro ну и так далее
    2 points
  2. WarStyle

    Приколы ))

    Вот бы додумались по аналогии с "экстрасенсами" выпустить шоу "битва программистов", где десять бородатых мужиков, с танцами и бубном пытаются угадать, что же случилось с "сайтом" человека по его абсурдным репликам в стиле: "Все было хорошо и тут х*ракс..."
    1 point
  3. Само по себе оно не могло появится, вспоминайте что до этого делали.
    1 point
  4. savage4pro

    Третья категория

    ControllerCatalogCategory->autocomplete() меняете 'limit' => 5 на нужное кол-во
    1 point
  5. savage4pro

    Безопасность Opencart

    вопрос касался версий 1.5.х поэтому и путь system/logs, хотя дыра присутствует и в более поздних версиях переименование файла смысла имеет действительно немного, т.к. инъекция позволяет переопределить назначение записи ошибок в "хоть-что.php", даже за пределами папки logs типа "../inc.php" а тут, на свой страх и риск, можете воспользоваться конструкцией, которая запретит прямой вызов .php, в обход index.php и admin/index.php в верхнем .htaccess <FilesMatch .*\.php$> RewriteCond %{REQUEST_URI} !(^/(admin\/)?index*\.php|^/$) RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] </FilesMatch> и это не панацея, конечно - никто не мешает дописать свою хрень в уже имеющийся файл, например, startup.php и переименовать файл ошибок обратно, дабы не сломать весь сайт сразу, никто же не хочет ломать сайт, а всего лишь какое-то время пользоваться частью его ресурсов, большой частью, пока его не закроют отключить показ ошибок в .htaccess php_flag display_errors off где-нибудь в config.php или в Log::__construct() error_reporting(0); насчет прав и прочего тут в теории все относительно просто 1. на продакшене 1 сайт = 1 пользователь от которого работает веб-сервер для обслуживания данного сайта, права - папки 0700, файлы - 0600 2. ftp не должен иметь прямого доступа ко всем файлам сайта, только через mount к папкам картинок ну и прайсов каких-нибудь в своей домашней папке на dev, на продакшене ftp нет в принципе 3. ssh для пользователя с доступом по ключам, никаких паролей вообще, и он должен быть один такой, который имеет право пушить в мастер продакшена с мерджа веток опять-таки на dev-сервере 4. к dev-серверу нет доступа из мира, кроме нескольких vpn-серверов, через которые осуществляется доступ персонала, и наоборот - в мир, кроме как на прод через систему контроля версий 5. группа разработчиков всегда работает только с ветками на dev каждый под своим пользователем 6. доступ к админке на продакшене запретить совсем, и работать с данными только через api, что подразумевает его расширение если пункты 1 и полвторого реализовать не сильно затратно, достаточно чуть поднастроить vps, то начиная с п.3 и далее цена реализации инфраструктуры начинает зашкаливать для среднего владельца магазина и ему дешевле будет плюнуть на зараженный сайт, а в худшем случае выбросить его в помойку, сделать ребрендинг и построить все заново объяснение простое - первые пункты защитят от широкого гребня ботнетов, а далее начинается защита от злых на вас людей при деньгах и дабы не иметь потенциальных дыр, никаких модулей с ионкубами, да и вообще никаких сторонних модулей, только свое, с одним исключением - обкатанные тысячами покупателей и вылизанные авторами модули от людей с репутацией полубогов, уровень которой вы сами для себя установите
    1 point