Comments 27
Если спрятать простыню кода под спойлер(что и нужно делать), то от статьи останется немного негодования и реклама, что сказать-то хотели в итоге? (да, я прочитал про сумбурность)
Так вот каким образом я оказался подписан на левые группы в VK.
Это исходник скрипта в оригинале? У нас недавно были подобные случаи с готовыми скриптами, но SEO-шники утверждали, что это результат взлома (последние события показали, что так, скорее всего, оно и было).
Я таки не понял, а кто главный злодей-то? uLogin? Кого ногами бить, и самое главное что делать чтобы не попасть в аналогичную ситуацию?
Включаю КО :)
Чтобы не попасть в аналогичную ситуацию подключайте скрипты только со своего сервера. Тут и jquery кстати отметился недавно, т.ч. вообще все у себя надо держать.
Чтобы не попасть в аналогичную ситуацию подключайте скрипты только со своего сервера. Тут и jquery кстати отметился недавно, т.ч. вообще все у себя надо держать.
jquery? можно посмотреть, где именно и как отметился?
А вот как раз новость сегодня была.
Свои иногда тоже ломают. Нарывались уже — встречали хакерские вставки в PHP- и JavaScript-коды yui и некоторых других типовых скриптов и движков на нашем сервере. Но тут уже зависит от того, кто и как эксплуатирует.
Кстати говоря, написал по случаю на коленке за пару часов на Delphi программку для поиска отличий в файлах и структуре каталогов. Использовал при взломе нашего сервера для поиска изменённых скриптов в проекте на несколько гигов (сравнивались два распакованных бэкапа до и после заражения — структура каталогов, размер и md5-хэши файлов). Думаю, не выложить ли её себе на сайт с исходниками, только не знаю, насколько она тут будет интересна сообществу.
Боюсь вас разочаровать, но для такого дела очень легко использовать git.
Правильно я понял, что система управления версиями (та же git) позволит в данном случае найти изменения, сделанные в обход оной, и выдать инфу об отличиях для поиска несанкционированных изменений?
Поможет для поиска изменений между бэкапами: распаковываем бэкап А, создаем репозиторий, добавляем все, делаем коммит, заменяем данные бэкапом Б, смотрим diff — как-то так.
Как-то действий многовато получается. У меня после программки было просто: распаковал бэкапы в разные каталоги, запустил программку, указал в её окне пути к бэкапам, щёлкнул кнопку и минут через 20 получил список изменений в grid-е и XML-файле. Осталось только отсмотреть отличия в конкретных файлах с помощью fc. Изменений было мало, так что бяки нашлись быстро.
Да не надо столько много всего делать.
Схема такая: git в отдельном каталоге, собственно проект – в отдельном. Всякого рода картинки, кэши и там прочее, что не исполняемое из git-а исключено, то есть он держит в себе только скрипты (мы же про веб-проект говорим), исполняемые файлы то есть. И вряд ли их будет несколько гигов (да и это не сказать, чтоб проблема для современного-то железа).
Один раз добавили всё, что нужно, закоммитили и коммит назвали там как-нибудь «состояние на 25.09.14», и всё. Если ничего не меняется, git status будет показывать clear, если что-то поменяли самостоятельно – коммитим снова (вообще через git и разворачивать удобно новые версии), если что-то поменялось – по git status мы видим конкретный файл, а по git diff – конкретные строки и изменения в них.
Схема такая: git в отдельном каталоге, собственно проект – в отдельном. Всякого рода картинки, кэши и там прочее, что не исполняемое из git-а исключено, то есть он держит в себе только скрипты (мы же про веб-проект говорим), исполняемые файлы то есть. И вряд ли их будет несколько гигов (да и это не сказать, чтоб проблема для современного-то железа).
Один раз добавили всё, что нужно, закоммитили и коммит назвали там как-нибудь «состояние на 25.09.14», и всё. Если ничего не меняется, git status будет показывать clear, если что-то поменяли самостоятельно – коммитим снова (вообще через git и разворачивать удобно новые версии), если что-то поменялось – по git status мы видим конкретный файл, а по git diff – конкретные строки и изменения в них.
ИМХО годится такой подход, разве что, для огромных проектов с кучей серверов, ибо там деваться особо некуда. Для остальных случаев не считаю его правильным. Подменить эксплоитом могут не только скрипт, но и, например, картинку, PDF-файл, ещё что-нибудь, что может быть открыто дырявым приложением. Да и потереть, к слову, тоже могут. Искать потерю потом не всегда приятно.
Для нескольких гигабайт — вряд ли:) С другой стороны существует PlasticSCM, которую рекомендуют для гигантских игровых проектов (сам не пробовал).
UFO just landed and posted this here
Никаких uLogin, Loginza и подобных «полезных» сервисов!
Только HybridAuth и локальные библиотеки. Лучше один раз помучаться, и освоить, чем сидеть на пороховой бочке и зависеть от не пойми кого.
Только HybridAuth и локальные библиотеки. Лучше один раз помучаться, и освоить, чем сидеть на пороховой бочке и зависеть от не пойми кого.
Sign up to leave a comment.
uLogin, как средство накрутки лайков клиентов