JavaScript, вводимый на моих Страницах PHP

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

5
задан Sam 17 August 2014 в 20:58
поделиться

6 ответов

Теперь вам нужно знать следующее:

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

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

Выполните повторное развертывание сейчас, обновляйте свои приложения, прекратите писать уязвимые PHP и заблокируйте свои учетные записи пользователей надежными паролями или SSH-ключи. Не пытаюсь прокачать мою компанию или что-то в этом роде, но это такое обычное явление на плохо управляемом веб-боксе, что мы ' Мы написали статью о , как полностью переделать с нуля . Я предлагаю это несколько раз в день.

РЕДАКТИРОВАТЬ: Если вы голосуете против меня, скажите, пожалуйста, почему - я отсортировал три случая с этим точным кодом, поэтому я не придумываю.

РЕДАКТИРОВАТЬ 2: Есть одно обстоятельство, в котором я могу переоценить ситуацию, и это только потому, что я являюсь сотрудником компании VPS (и я часто это вижу). Я сделал ошибку, предположив, что «веб-хостинг» этого пользователя был сервером под его контролем, а не общим хостингом. Это было ошибкой, но все же есть шанс, что я прав.

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

Я честно устал от тикетов, которые мы открываем, когда ящик поражает другой в Интернете. с SSH-зондами, данными DoS, внедрением URL-адресов или чем-то еще в этом отношении - и разработчик Rails или PHP, администрирующий ящик, не знает, почему это произошло и что он может с этим поделать. Все это указывает на компрометацию системы, а не на XSS. Поэтому мое предположение, что это был сервер под контролем OP, было неуместным, но это простительно (я надеюсь), потому что я сейчас на работе, обрабатываю эти билеты.

14
ответ дан 18 December 2019 в 07:55
поделиться

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

1
ответ дан 18 December 2019 в 07:55
поделиться

Обфусцированная часть переходит в "t.cn/vid"

0
ответ дан 18 December 2019 в 07:55
поделиться

Как я вижу, ваши страницы были внедрены в код, так что это было сделано из-за дыры в безопасности на вашем сервере или в любом приложении, работающем на нем. У хакера есть возможность писать ваши скрипты, и решение может быть таким простым, как изменение пароля FTP, или таким сложным, как поиск дыры в любом приложении, установленном на вашем сервере.

Но сначала попробуйте изменить свой пароль FTP. Измените его на очень сложный, длиной не менее 12 символов с любым специальным символом. Я слышал, что была атака методом перебора со стороны российских хакеров, которые встраивали скрипты в заголовки страниц для перенаправления пользователей на любые другие сайты с какой-либо неясной целью.

0
ответ дан 18 December 2019 в 07:55
поделиться

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

Я столкнулся с чем-то похожим несколько дней назад, оказалось, что это старый WordPress (v2.0 I think), через который они могут получить доступ.

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

0
ответ дан 18 December 2019 в 07:55
поделиться

Поскольку вы упомянули PHP, я пробегу список возможные способы, которыми это могло произойти. Этот список не исчерпывающий; но это позволит вам провести серьезное расследование того, что произошло.

  1. Возможно, ваш веб-хост был взломан, и он был размещен на вашей странице из-за слабой безопасности с их стороны. Однако не предполагают, что это так . Это должно быть ваше последнее средство .
  2. Вероятно, это твоя вина. Я говорю это не для того, чтобы обвинить; но чем раньше мы, разработчики, осознаем, что являемся причиной наших проблем, тем лучше нам всем будет. Единственный разработчик, которому я не доверяю, - это тот, который говорит, что не делает ошибок.

  3. Ваш сайт, вероятно, подвергся XSS-атаке .

    • Есть ли у вас какой-либо способ для пользователя ввести информацию на вашем веб-сайте? Используете ли вы какие-либо текстовые поля или что-нибудь, что позволяет вводить данные от пользователя?

Если да, то ваш сайт уязвим для XSS и других атак. Вот «шпаргалка» , которая расскажет вам общие вещи, которые вы можете сделать, чтобы смягчить это.

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

  2. Если вы собираетесь разрешить пользователю вставлять HTML, вам нужно очистить его .

  3. Не используйте магические кавычки .

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

Шаги:

  1. Переведите приложение в автономный режим.
  2. Запросите свою базу данных, чтобы узнать, сколько страниц / записей это было введено.
  3. Проверьте свой код на предмет того, что я упоминаю.
  4. Исправьте это.
  5. Просмотрите свою базу данных и устраните всех подозреваемых. строк (проще всего использовать сценарий SQL).
  6. Повторно разверните приложение.
  7. Убедитесь, что вы следите за журналами своего веб-сервера. Они являются находкой для определения источника атаки.
5
ответ дан 18 December 2019 в 07:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: