Безопасность Вашего сайта - залог успеха. Защита сайта.

[webds]

Добрый день уважаемые пользователи OpenCart.

Открываю эту тему с целью собрать и предоставить максимальную информацию о том как обеспечить свой сайт.

 

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

 

 

 

[rb2]

Честно говоря, я вообще не понимаю зачем эти права нужны и зачем с ними работать. [...] Но как показал опыт, все скрипты работают под Админ правами сервера. [...] Честно пока мало эффекта видел от этого назначения прав, хотя элементарная защита как бы есть , и я все же рекомендую выставлять права по максимуму правильно.

Чувствуется профессионал.

[Baco]

Здравствуйте, подскажите пожалуйста, как можно взломать сайт имея доступ только к БД ? [#INTO OUTFILE]

[webds]

Добрый ночи rb. Спасибо Вам за то, что следите за перепиской на форуме.

 

Мои высказывания и рекомендации - это всего лишь мои мысли в слух и они могут иногда быть ошибочными. 

Что делать и как поступать - решать каждому админу сайта на свое усмотрение.  

 

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

 

 

CHMOD или права доступа.

 

Для начала нам нужно задать себе вопрос, что это такое? 

 

CHMOD - название программы, которая работает на серверах под ОС Linux и дает возможность нам назначать права доступа различным объектам : каталогам , файлам.

 

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

 

Сами привилегии подразделяются на три категории и записываются одной строкой сразу для трёх типов пользователей:

 

владелец — u (непосредственно владелец файлов)

 

группа — g (других пользователей, входящих в группу владельца)

 

остальные —  о (всех прочих пользователей);

 

 

 

Обычно Chmod задают в цифровом виде. Стандартно можно увидеть и это рекомендовано делать такие комбинации: 

 

600

только владелец файла может читать/записывать

 

644

владелец файла, может читать/записывать, члены группы и остальные только читать

 

666

любой пользователь может читать/записывать

 

700

только владелец файла, может читать/записывать и запускать на исполнение

 

711

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

 

755

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

 

777

любой пользователь может читать/записывать и запускать на исполнение

 

Для каталогов:

 

700 

только владелец может входить в этот каталог, читать и записывать в него файлы

 

 

755

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

На этом теорию заканчиваем.  Ее и так много в интернете.  

 

 

Перейдем к практике:

 

Взлом Вашего Веб ресурса можно разделить на несколько этапов:  

 

Этап 1. Подготовка.

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

 

Этап 2.  Получить доступ.

Вариантов как это сделать - много.  

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

Что же делает эта "дыра"?

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

 

Этап 3. Управление.  

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

Результатом может быть  как просто повредить Ваш ресурс так и использовать его для размещения рекламы и т.д.

 

Этап 4. Маскирование.

Злоумышленник попытается максимально спрятать свой код  между всеми остальными файлами Вашего сайта.  Чтоб в будущем сразу обратится к шелл скрипту и опять проделать все что ему необходимо.  

 

Этап 5. Контроль и сканирование.

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

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

 

Теперь настало время вернутся к правам доступа.  

Дело в том, что при наличие уязвимости, права доступа иногда  честно говоря мало в чем могут помочь.  

 

К примеру:  если у нас появилась возможность залить шел скрипт, то теперь злоумышленник может выполнять разные действия над Вашими файлами.   

 

Знаю, после этих слов будет много  вопросов...  как так? стоят же права к примеру только читать? 

Ответ очень простой: шелл скрипты могут изменять права других файлов.  А если не могут то с помощью простой функции RENAME()  могут заменить свой полученный файл на любой файл вашей системы. 

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

 

Суть эксперимента 1 (названия файлов выдуманные): 

 

1. Вам необходимо создать файл config.php  с любым содержанием  и назначить ему любые логичные права доступа Вашей системы.

2. Создать скрипт rename.php и использовать функцию RENAME() (функция PHP, переименовывает файл или директорию)

3. Создать скрипт newconfig.php  с любым содержанием.

4.  Запустить rename.php , после откроем  файл config.php  и увидим в нем содержимое newconfig.php

 

Суть эксперимента 2  (названия файлов выдуманные): 

 

1. Вам необходимо создать файл config.php  с любым содержанием  и назначить ему любые логичные права доступа Вашей системы к примеру 400.

 

2. Создать скрипт сhmod.php  и использовать в нем функцию php  сhmod(), в которой прописать путь к файлу config.php и переопределить права на 777

3. Запустить скрипт сhmod.php

 

После чего мы видим что права на наш скрипт были сменены

 

Вопрос, почему же так? Почему же можно менять тогда так легко  права доступа с помощью Shell Скриптов , которые используют сhmod() функцию?

 

Ответ прост: Apache и скрипты работают с одними и теми же правами.  

Мало того, есть большая угроза заражению всех Ваших веб сайтов на Вашем хостинге, если хоть один с сайтов уже заражен.  

Распространение вирус -  скрипта можно остановить использую разные правовые группы для разного своего веб проекта на одном хостинге. Но для этого необходимо как минимум установить и настроить nginx+apache2-mpm-itk 

[webds]

Здравствуйте, подскажите пожалуйста, как можно взломать сайт имея доступ только к БД ? [#INTO OUTFILE]

Добрый день.  

 

Ну, учить что то ломать не стоит я думаю, это будет не правильно.  

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

 

Не забывайте, что  база - это очень важная часть  Вашего сайта, в которой  хранится много информации о пользователях Вашего же сайта.  

[Zeppelin]

Не забывайте, что  база - это очень важная часть  Вашего сайта, в которой  хранится много информации о пользователях Вашего же сайта.  

 

если я правильно помню, то в релизах после OCStore 1.5.4.* пароли пользователей шифруются по алгоритму md5 salt+hash что доставляет немало хлопот при подборе пароля администратора. Поэтому наличие базы пользователей вполне может отказаться бесполезной информацией.

почитать

 

Ответ прост: Apache и скрипты работают с одними и теми же правами

 

 

спорное утверждение, зависит от хостера. У меня, наоборот через CPanel нельзя было очистить кэш, не хватало прав как раз из-за того, что Апач жил как user\group = nobody, а у меня были юзерские права.

Змінено 19 січня 2015 користувачем Zeppelin

[Blondi]

 

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

 

А что, "дыры" имеют только бесплатные, взломанные, и только из сомнительных источников модули?

 

 

В зависимости от функций заложенных в файлах -  скриптах, через такую вот "дыру" злоумышленник проделав определенный запрос

 

Не путайте пожалуйста "дыры", "шеллы" и "бэкдоры".

 

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

 

А вот шелл или модуль с бэкдором можно получить "в комплекте" со взломанным модулем, и вот в них то злоумышленник и вкладывает определенный функционал, который ему нужен. Уязвимость же можно только эксплуатировать, заранее "запрограммировать" её нельзя.

 

 

Здравствуйте, подскажите пожалуйста, как можно взломать сайт имея доступ только к БД ? [#INTO OUTFILE]

Я правильно поняла что база только в виде дампа в файле? Тогда перебирать пароль админа, и надеяться что он не очень длинный. Тогда можно попасть в админку, а с админки можно сделать с сайтом все что угодно.

 

 

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

 

Не забывайте, что  база - это очень важная часть  Вашего сайта, в которой  хранится много информации о пользователях Вашего же сайта.  

 

В базе хранится ВСЯ информация о сайте, кроме той что гвоздями прибита в файлах, сверстана или прописана скриптами. Если есть доступ на запись в базу, то при ЛЮБЫХ (ну ладно, в 80% случаев, если у Вас свое железо и правильные руки, и в 100% на шаред-хостингах) условиях с сайтом можно сделать все что угодно.

 

Данные пользователей интернет магазина - да кому они нужны? Там что, есть данные о кредитных картах? Нет, если это секс-шоп какой то то да, есть эл-почта, можно по-шантажировать. Помните уязвимость у яндекса, когда он умудрился проиндексировать адреса доставок магазинов сексатрибутики и доставки цветов?

 

А вот например в ЧПУ прописать свой редирект, или в карточку товара прописать свой шелл?... Скопировать сайт можно и парсером! Доступ в админку через базу можно получить минимум двумя способами. А есть доступ в админку - сайт весь Ваш!

[Baco]

Вы уж извините, но в данной теме актуальности ровным счетом столько, сколько и по этой ссылке. 

[freelancer]

в этой теме воды, что хоть выжимай )

[webds]

если я правильно помню, то в релизах после OCStore 1.5.4.* пароли пользователей шифруются по алгоритму md5 salt+hash что доставляет немало хлопот при подборе пароля администратора. Поэтому наличие базы пользователей вполне может отказаться бесполезной информацией.

почитать

 

 

спорное утверждение, зависит от хостера. У меня, наоборот через CPanel нельзя было очистить кэш, не хватало прав как раз из-за того, что Апач жил как user\group = nobody, а у меня были юзерские права.

 

Добрый день всем!

 

 

И так Соль или Salt.

 

Это строка случайных данных, которая подается на вход хеш-функции вместе с исходными данными (википедия).

 

Другими словами, это генерированное значение, которое присутствует в алгоритме создания паролей.

 

 

Если смотреть OpenCart  то хлопот вообще нету создать новый пароль администратора, заменить его в базе данных и зайти под админ правами в админ панель Вашего магазина.  

 

Теперь от теории к практике: 

$this->db->query("UPDATE " . DB_PREFIX . "customer SET salt = '" . $this->db->escape($salt = substr(md5(uniqid(rand(), true)), 0, 9)) . "', password = '" . $this->db->escape(sha1($salt . sha1($salt . sha1($data['password'])))) . "' WHERE customer_id = '" . (int)$customer_id . "'");

С этого кода мы видим как генерируется наш пароль.

 

Сначала необходимо генерировать соль: 

$salt = substr(md5(uniqid(rand(), true)

1. Генерируется путем получения уникального идентификатора  c функции PHP uniqid()

2. Потом необходимо получить  ХЕШ (нашего уникального идентификатора) с помощью функции PHP MD5()

3. И на по следок - обрезать полученный ХЕШ  до длинны в 9 символов  с помощью функции PHP substr()

 

И так соль готова.

 

Дальше  генерация пароля:

sha1($salt . sha1($salt . sha1($data['password'])))

1. $data['password']  - это наше значение, выдуманное нами.  

 

2. sha1 (Secure Hash Algorithm 1) - функция PHP, которая вернет нам ХЕШ нашего выдуманного нового пароля

 

3. Ну и $salt - эта наша соль, которую генерировали раньше.

 

В общем, если выполнить в php скрипте такую строку кода, подставив вместо слов СОЛЬ и ВЫДУМАННЫЙ ПАРОЛЬ  - свои ХЕШ значения то в результате получим наш ХЕШ нового выдуманного нами пароля:

<?php echo  sha1('СОЛЬ' . sha1('СОЛЬ' . sha1('ВЫДУМАННЫЕ ПАРОЛЬ'))); ?>

Хранением информации (логин, пароль и соль ) о пользователе хранится  в базе, в таблице ПРЕФИКС_user

 

Спасибо за внимание!

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

[webds]

в этой теме воды, что хоть выжимай )

Если Вы так считаете зачем же Вы ее доливаете? )))))))   Если каждый на этом форуме напишет по слову в тему - получится флуд)))

 

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

 

Попрошу Вас в следующий раз не создавать флуд а задать и написать реально интересный вопрос, для того чтоб было над чем подумать, подумать над решением его.  

 

Если же у Вас есть свой опыт в каких то вопросах -  конечно было бы  хорошо увидеть его.  

[Blondi]

 

Теперь от теории к практике:

1. Генерируем хэш нового пароля на http://www.md5.cz/

2. Вставляем в базу в нужное поле

3. Profit!

 

1. меняем в базе мыло админа на свое.

2. восстанавливаем пароль штатными средствами опенкарта на свое мыло

3. Profit!

 

webds - Будьте проще, и к вам потянутся люди...

[Baco]

Сайты на опенкарте подлежат взлому только в таких случаях:

1. Если взломан соседний сайт, размещённый на том же хостинге но на другом движке (joomla, drupal, wordpress... etc)

2. Админ, или владелец сайта - редкостный склеротик, который генерирует все пароли (и к FTP и к SQL и в админку) по типу qwerty123

3. Недобросовестные фрилансеры, которые оставляют за собой "бекдоры"

___

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

[Blondi]

Сайты на опенкарте подлежат взлому только в таких случаях:

1. Если взломан соседний сайт, размещённый на том же хостинге но на другом движке (joomla, drupal, wordpress... etc)

2. Админ, или владелец сайта - редкостный склеротик, который генерирует все пароли (и к FTP и к SQL и в админку) по типу qwerty123

3. Недобросовестные фрилансеры, которые оставляют за собой "бекдоры"

___

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

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

5. 0day уязвимости.

 

Это касается не только опенкарта, но и любого другого движка.

 

И да, в остальном это все индивидуальные подходы, которые не зависят от движка.

[webds]

Видео обзор о модуле DS Firewall Opencart

[halfhope]

95% взломов opencart происходят по причине недобросовестных исполнителей. Остальные - модули с вареза и дыры в модулях. Файерволл будет полезен в тех случаях ,если у Вас пароль 123 и есть дыры в модулях. Еще смотря что за файлерволл. Мне одному кажется, что я зря калории тратил расставляя запятые?

[Baco]

95% взломов opencart происходят по причине недобросовестных исполнителей. Остальные - модули с вареза и дыры в модулях. Файерволл будет полезен в тех случаях ,если у Вас пароль 123 и есть дыры в модулях. Еще смотря что за файлерволл. Мне одному кажется, что я зря калории тратил расставляя запятые?

Нет, не одному... потратив время на просмотр видео, автору риспект, что всё же потратил время, создал видео, описание... Но зачем ? 

 

+ где же хвалебный "плохой модуль" который отзывы создает ? можно хоть на него ссылку, а то подозреваю, что сам написал дырявый код, сам взломал свой сайт через свой дырявый код а потом сам "поправил " дыру через мега-супер фаервол... Ход маркетинга понятен, тут и похитрей есть индивидуумы маркетинга.

[webds]

+ где же хвалебный "плохой модуль" который отзывы создает ? 

 

 

Вы его можете скачать на странице описания модуля.  

 

а то подозреваю, что сам написал дырявый код

 

 

В действительности так и есть.   Я создал модуль,  с дырявым кодом для примера и тестирования firewall модуля.  Я был в роли, как написал выше ув. halfhope, "недобросовестным исполнителем".      

 

Так вот, в этом "плохом модуле", я допустил две серьезных уязвимости. 

1. SQL уязвимость

2. php уязвимость, прописав просто код с функцией PHP  eval(), думаю со мной все программисты согласяться что это очень опасная функция, если она напрямую принимает переменную с запроса.  

 

В обоих случаях  модуль справился.  

 

 сам взломал свой сайт через свой дырявый код а потом сам "поправил " дыру через мега-супер фаервол..

 

 

Да действительно сам взломал, но так взломать может каждый - это первое.

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

ну и третье - по поводу "потом сам "поправил " дыру через мега-супер фаервол"   Еще раз, ув. Baco, жаль что Вы так и не поняли алгоритм моего модуля.   Мой модуль - это не антивирус, который что то поправляет или находит, мой модуль  - это firewall, фильтрует запросы и отклоняет, если видит потенциально опасные данные в передачи.   Таким образом, у Вас на сайте могут быть сотни веб шелов и уязвимых модулей - тока вот использовать уязвимость - не всегда можно будет, так как модуль будет отклонять запросы.

 

От написания модуля - антивирусного сканера я отказался...  так как есть на это причины и я о них уже писал.  

Это как минимум : 

1. Большая нагрузка на сервер

2. Сложные и большое количество сигнатур

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

и.т.д

[ksenizi]

Добрый день!

 

Подскажите пожалуйста, может кто сможет проконсультировать по такому вопросу:   При разработке модуля меню, обязательно ли давать доступ разработчику к базе данных, помимо доступа к сайту по sftp? Да и вообще,обязательно ли давать sftp?

[webds]

 

Добрый день!

 

Подскажите пожалуйста, может кто сможет проконсультировать по такому вопросу:   При разработке модуля меню, обязательно ли давать доступ разработчику к базе данных, помимо доступа к сайту по sftp? Да и вообще,обязательно ли давать sftp?

 

Я Вам.. так отвечу.

 

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

 

Но с другой стороны....

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

 

 sftp также можно не давать... Не так уж много файлов... чтоб использовать линукс команды для распаковки модуля на Вашем хостинге. 

 

И так ЭТАПЫ:

1. Идет разработка модуля.

2. Идет установка на тест платформу у разработчика

3. Тестируете. 

4. Установка к Вам. (или сами, или через ftp уже разработчик закачивает)

5. Установка в админ панели и настройка. (или сами по инструкции или  админ пользователь с правами на этот модуль и менеджер модулей)

 

 

В зависимости от сложности модуля, могут быть еще какие то пункты. НО они в основном только для удобства и быстроты разработки. 

К примеру:

Если это модуль меню, как у Вас. 

То желательно предоставить FTP для того чтоб быстро вести разработку,  сразу корректировать код, стили и.т.д

 

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

[Helloween]

если я правильно помню, то в релизах после OCStore 1.5.4.* пароли пользователей шифруются по алгоритму md5 salt+hash что доставляет немало хлопот при подборе пароля администратора. Поэтому наличие базы пользователей вполне может отказаться бесполезной информацией.

 

Тема - муть. Вообще не хочу ввязываться в обсуждение.

Но решил докопаться до приведенной цитаты.

У меня ocStore 1.5.5.1.2

Логин, пароль и другие данные доступа к базе данных не захэшированы. Как защитить базу данных от гостей?

Пока закрыл файл конфига через .htaccess

[Bross]

У кого возникали проблемы с недобросовестными GET-запросами на сайт? Периодически механизм поиска используют как средство для повышения нагрузки на сайт. Что поможет снизить такие проблемы, кроме как тупое закрытие доступа через htaccess? В какой-то момент хостер просто скажет "давай до свидания!"

Змінено 10 серпня 2015 користувачем Bross