Безопасность вашего сайта в ваших руках

1. Правильно выставите права доступа на файлы и папки.
2. Если есть необходимость привлечения стороннего разработчика
3. Всегда перед тем как проводить любые действия над сайтом делайте резервную копию(база+файлы)
4. Пользуйтесь антивирусной программой
5. Не используйте ломанные компоненты для instantcms
6. При выборе исполнителя проверьте портфолио.
7. С осторожностью относитесь к разработкам размещенных не на официальном сайте.
8. Будьте внимательны к бесплатным шаблонам
Уважаемые коллеги, если есть что добавить, то напишите в данном посте ниже.
Если вы увидели, что ваш совет добавлен не поленитесь затрите ваше сообщение. Спасибо.

Работайте с теми, у кого есть портфолио (или блог тут), у кого есть репутация, карма, так как риск потерять ее гораздо выше мимолетной прибыли от вреда вам.

Не упомянута основная причина взлома многих сайтов, которая и на офф. сайте проскакивала много раз )
Не сохраняйте пароли в фтп менеджерах!
Вне зависимости от того, стоит антивирусник на локальном компе или нет.
И второе, так как многие держат свои сайты на дедиках или VPS, то безопасность ваших сайтов в очень большой степени зависит от настроек вашего сервера. Я не спец по безопасности, но вкратце могу сказать следующее:
1.Для каждого сайта нужно заводить отдельного юзера unix, состоящего в отдельной группе; Файлы сайта должны принадлежать этому юзеру и должны лежать в его доамашней директории.
2. Демоны апача, пхп не должны запускаться от пользователя root. Лучше, завести под каждого отдельного юзера и отдельную группу. Чтобы скрипты работали корректно, достаточно добавить владельца демона в группу владельца файлов сайта. И тогда для того, чтобы разрешить запись в нужный файл или папку, достаточно установить права 775. Что конечно же безопаснее 777. Возможно про это говорил stealthdebuger. Если я ошибаюсь, интересно было бы послушать специалиста, как нужно )
3. Настройки chroot для юзера unix. Доступ не выше домашней директории.
4. Директива open_basedir — запирать скрипты в домашней директории.
Ну и наверно еще что-то. Я ведь не спец )))

Закрыть дополнительным паролем папку admin

а. Выставите на все папки права 755 (кроме тех, в которые должны быть разрешена запись) б. Выставите на (/cache, /images,/upload) и вложенные в них папки права 777 в. На все остальные файлы выставите права 644

Прежде чем это утверждение, принимать это основное решение — надо БУКВАЛЬНО ЗНАТЬ УСЛОВИЯ ПРЕДОСТАВЛЕНИЯ ПРАВ ХОСТЕРА.
Что може явиться неправильным — в этом случае?
Большинство в целях безопастности уже изначально — ПРИНУДИТЕЛЬНО устанавливают права 755 на директории. И 644 на файлы. И изменение одной директории с прав 755 на 777 повлечет полную неработоспособность скрипта.Это также касается любого изменения прав на файл-644 (ПРАВИЛА касаются -ТОЛЬКО ВИРТУАЛЬНЫХ ХОСТИНГОВ).
Надо четко обозначить и принять определенное правило касающееся ПРАВИЛ ПРАВ НА ДИРЕКТОРИИ И ФАЙЛЫ.

Если хостер обозначил права НЕ ИНАЧЕ 755 на директории и 644 на файлы- не надо ничего менять.
Приемлемо как — только исключительные решения, в зависимости о ПРОФЕССИОЛТИЗМА услуг виртуального хостинра.

Не упомянута основная причина взлома многих сайтов, которая и на офф. сайте проскакивала много раз )
Не сохраняйте пароли в фтп менеджерах!

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

stealthdebuger, пост поправили — не смогли повторить при правильных правах или всё же смогли и поэтому?

stealthdebuger, пост поправили — не смогли повторить при правильных правах или всё же смогли и поэтому?

Хм… Если вы успели увидать мое сообщение, то заметили, видимо, и оговорку, что требуются еще и другие условия для того, чтобы вариант сработал.
Кроме того да, при правильных правах и владельцах (тот же файл .htaccess от рута) сделает всякие попытки тщетными.

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

Кроме того да, при правильных правах и владельцах (тот же файл .htaccess от рута) сделает всякие попытки тщетными.

stealthdebuger -это ВАШ КАРТ ВЛАНШ.Пожалуйста, разьясните принципиально основную теорию защиты сайтов от определенного фактора уязвимостей.
Я предлагаю ВАМ как профессионалу, создать блог в котором Вы сможете поделиться своими многолетними знаниями в плане безопастности исполняемых скриптов.В Вашем варианте достаточно преподнести тему как Общая.В итоге Вы имеете неоспоримое преимущество и интерес к теме:
1-эта тема ОЧЕНЬ НУЖНА сторонним разработчикам дополнений в виде модулей, плагиной, компонентов.
2-именно малый процент разработчиков являются профессионалами.В ЛЮБИТЕЛЬСКОМ итоге мы имеем ВСЕ взломы по совершенно правильным (классическим) понятиям.Разработчик дополнений в ICMS в большей степени, это саморазвивающийся програмист, и не более.Уровень соотношения качества кода к знаниям, иногда имеет противоречия.
Кто как не ВЫ в данной ситуации сможете обозначить прямые условия правильного кодирования.
Сверх задача? Просто делитесь опытом, если жаба не жмет.Это называеться прогрессом личности- учите! И МЫ — ученики, ВАМ только благое будем вешать.

Присоединяюсь к пожеланиям Oll, тоже интересно было бы почитать )
Кроме того, интересно было бы услышать рекомендации аудита безопасности, проведенные для icms. Что-то сами заметили — csrf-токены, модификаторы escape, удаление коннекторов в fck-едиторе… Наверняка же, ещё есть много чего…
Понятно, что не все используют, но кому то же поможет сделать свой код более безопасным.
Согласен с Олей, профессионалов-кодеров(именно программистов по образованию или близких по професии) среди разработчиков расширений очень мало. R2, Максисофт(отошел от icms) — я больше и не знаю
Почти все мы самоучки, да и опыт то небольшой — всего то пару лет, и то без отрыва от производства.
В целом, если бы была какая-то тема на форуме или может блог, где можно было бы обсуждать, послушать, учиться — как нужно писать и как не нужно- это было бы очень даже полезно в целом для сообщества, ну и для нас тоже ) Возможно даже обсуждение в закрытом режиме.
Интересно не только про безопасность, но и про произодительность, быстродействие… И вообще качество кода.
Честно, во многом учусь у Fuze, его код легко читается. Что ни говори, хотя он и говорит, что не профессионал, есть талант у человека. Как то, умеет он просто и красиво писать.
Писать то всё равно будем . Сколько раз не пытался переключиться на другое, тянет на php и всё. Засядет в голове какая идея, и пока не реализуешь, тараканы в голове не дают покоя.
Ну и, хотелось бы и красиво кодить.

Димитриус,

Честно, во многом учусь у Fuze, его код легко читается. Что ни говори, хотя он и говорит, что не профессионал, есть талант у человека. Как то, умеет он просто и красиво писать.

Это ТАЛАНТ, и я oll с него беру пример.

Марат, oll, спасибо.

По мануалам безопасности: дело в том, что подобные публикации имеют обратную сторону. Где вероятность, что человек, читающий разбор безопасности InstantCMS будет использовать данную информацию для своего развития, а не для руководств к действию.
Поэтому в данном случае думаю максимум что возможно — это попросить написать некий пост, охватывающий в целом безопасное написание php кода, не в контексте бывших уязвимостей InstantCMS. Далеко не все исходя из патчей смогут сделать PoC.

В целом, если бы была какая-то тема на форуме или может блог, где можно было бы обсуждать

Одну сторону озвучил Fuze постом выше, вторую сторону я могу продемонстрировать наглядно instantcms.ru/blogs/nash-instantcms/komponent-rasylki-dlja-instantcms-instantmailer-v0-0-7.html#comment_57766
Это весьма неблагодарное дело. Тратится тьма личного времени на анализ кода, тестирование, описание найденной проблемы и рекомендации по устранению, а в ответ чаще всего слышишь ругань, упреки и фразы по-типу "сам дурак".

P.S. Если озвученный вопрос будет действительно интересен многим, я могу выложить несколько своих рассуждений, но предпочту это сделать на специализированом форуме, в отведенной для ICMS ветке.

вторую сторону я могу продемонстрировать наглядно

Я почему то уверен, что такая проблема практически у всех разработок. Но вот механизма, для контроля нет.

предпочту это сделать на специализированом форуме

поделитесь, где этот форум?