Если спрятать простыню кода под спойлер(что и нужно делать), то от статьи останется немного негодования и реклама, что сказать-то хотели в итоге? (да, я прочитал про сумбурность)
Блин прочитал два раза не ясно, кого рекламируют ?:) uLogin или uptolike? В итоге судя по посту и улогина и аптулайка руки по локоть в фекашках.
или это такой черный пиар?
Бить наверное меня, т.к. мне случайно попался скрипт, который явно не постоянно подключается при загрузке, а так, изредка и выборочно. Короче «поймал за руку случай» — повезло
Это исходник скрипта в оригинале? У нас недавно были подобные случаи с готовыми скриптами, но SEO-шники утверждали, что это результат взлома (последние события показали, что так, скорее всего, оно и было).
Включаю КО :)
Чтобы не попасть в аналогичную ситуацию подключайте скрипты только со своего сервера. Тут и jquery кстати отметился недавно, т.ч. вообще все у себя надо держать.
Свои иногда тоже ломают. Нарывались уже — встречали хакерские вставки в PHP- и JavaScript-коды yui и некоторых других типовых скриптов и движков на нашем сервере. Но тут уже зависит от того, кто и как эксплуатирует.
Кстати говоря, написал по случаю на коленке за пару часов на Delphi программку для поиска отличий в файлах и структуре каталогов. Использовал при взломе нашего сервера для поиска изменённых скриптов в проекте на несколько гигов (сравнивались два распакованных бэкапа до и после заражения — структура каталогов, размер и md5-хэши файлов). Думаю, не выложить ли её себе на сайт с исходниками, только не знаю, насколько она тут будет интересна сообществу.
Правильно я понял, что система управления версиями (та же git) позволит в данном случае найти изменения, сделанные в обход оной, и выдать инфу об отличиях для поиска несанкционированных изменений?
Поможет для поиска изменений между бэкапами: распаковываем бэкап А, создаем репозиторий, добавляем все, делаем коммит, заменяем данные бэкапом Б, смотрим diff — как-то так.
Как-то действий многовато получается. У меня после программки было просто: распаковал бэкапы в разные каталоги, запустил программку, указал в её окне пути к бэкапам, щёлкнул кнопку и минут через 20 получил список изменений в grid-е и XML-файле. Осталось только отсмотреть отличия в конкретных файлах с помощью fc. Изменений было мало, так что бяки нашлись быстро.
Да не надо столько много всего делать.
Схема такая: git в отдельном каталоге, собственно проект – в отдельном. Всякого рода картинки, кэши и там прочее, что не исполняемое из git-а исключено, то есть он держит в себе только скрипты (мы же про веб-проект говорим), исполняемые файлы то есть. И вряд ли их будет несколько гигов (да и это не сказать, чтоб проблема для современного-то железа).
Один раз добавили всё, что нужно, закоммитили и коммит назвали там как-нибудь «состояние на 25.09.14», и всё. Если ничего не меняется, git status будет показывать clear, если что-то поменяли самостоятельно – коммитим снова (вообще через git и разворачивать удобно новые версии), если что-то поменялось – по git status мы видим конкретный файл, а по git diff – конкретные строки и изменения в них.
ИМХО годится такой подход, разве что, для огромных проектов с кучей серверов, ибо там деваться особо некуда. Для остальных случаев не считаю его правильным. Подменить эксплоитом могут не только скрипт, но и, например, картинку, PDF-файл, ещё что-нибудь, что может быть открыто дырявым приложением. Да и потереть, к слову, тоже могут. Искать потерю потом не всегда приятно.
Не слышал про такую. Хорошая штука, спасибо. Правда, меня терзают смутные сомнения насчёт того, что хакер, взломавший сервер, не сможет подкорректировать базу так, чтобы изменения не были видны. Я сравнивал бэкапы, слитые автоматически на чистую машину.
uLogin, как средство накрутки лайков клиентов