В Google Chrome появится новая функция безопасности при переходе по ссылкам, которые открывают URL-адреса в новом окне или вкладке. Она будет блокировать попытки использовать JavaScript для перенаправления пользователя на вредоносную страницу.

Старый браузер Microsoft, Internet Explorer, перестал отображать большинство популярных веб-сайтов, в том числе YouTube, StackOverFlow, Instagram, Twitter и другие. Вместо этого IE принудительно редиректит пользователей в Edge: так компания предполагает «пересадить» пользователей устаревшего браузера, который она пытается «убить» уже несколько лет, на свой актуальный продукт. Принудительный редирект начался с окончанием поддержки IE — 13 ноября.



Подобное поведение софта Microsoft связано с официальной политикой компании по ликвидации Internet Explorer и обеспечению полной миграции пользователей в Edge. В общей сложности IE редиректит в Edge уже не менее тысячи веб-сайтов.

Эксперты из MessageLabs предупреждают о новом хитроумном приёме, который включили в свой арсенал спамеры. Они размещают вредоносные файлы SWF на известных хостингах вроде ImageShack, где разрешено размещение флэш-анимации. Опыт показывает, что жертву значительно проще заманить на сайт, который она считает безопасным.

Средствами флэша пользователя можно перенаправить с этой страницы на другой сайт, где и происходит непосредственно заражение его компьютера. Например, при загрузке страницы можно показать пользователю окошко с сообщение о необходимости скачать кодек для просмотра этого «медиафайла». Юзер нажимает “OK” — и дело сделано.

Такой вид атак появился совсем недавно, но эксперты прогнозируют, что он может широко распространиться в ближайшее время. У антиспамерских компаний пока нет эффективного способа блокировать такие ссылки в почтовом трафике. Та же MessageLabs ежедневно выявляет около 3000 вредоносных сайтов и блокирует ссылки на них, но они не могут отфильтровать ссылки на ImageShack и тому подобные сервисы.

В наборе инструментов для веб-мастера Webmaster Tools появилось очень полезное дополнение. Теперь система не просто выдаёт статистику по количеству входящих ссылок в поисковом индексе, на которые с вашего сайта возвращается «ошибка 404», но и показывает, с каких сайтов идут эти ссылки. В табличке указана и дата, когда поисковый робот обнаружил битую ссылку.



Обладая всей этой информацией, можно быстро исправить ошибку: поставить или редирект, или страницу с контентом по этому адресу. Фактически, Google предоставляет инструмент для бесплатного получения новых ссылок на ваш сайт.

via Official Google Webmaster Central Blog

Зачем был написан топик?

Испытав в очередной раз необходимость воспользоваться TinyUrl, я наткнулся на угрожающее сообщение, что либо сайт находится в блэк-листе, либо мой IP забанен. Попробовав ввести другой адрес и добившись результата, я пришёл к неутешительному выводу, что такую фигню выдаёт ссылка на файл, лежащий на яндексовом хостинге. Пара минут поиска — и вот ссылка уже благополучно обрезана в MooURL. Откуда я взял MooURL? А вот наобум выбрал. В своём блоге, в записи от 29.06.2008, Артём Беляйкин опубликовал список из 68 сервисов, которые предложил для уменьшения размера длинных ссылок. Правда, с упором на маскировку партнёрских ссылок, а я упираюсь в пользователя :)

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

Зачем это хабрасообществу?

Для пользы. И чтобы не копаться в этом самим, когда понадобится. Использовано может быть по разному поводу, например: записывать на бумажку такой адрес удобнее; по смс скидывать удобнее; в социальных сетях (когда стоит запрет на публикацию адреса) публиковать удобнее. Это если не брать в расчёт использование в целях редиректа и прочие варианты.

Представляю простой до безобразия микро-сервис Обматерю.
Это простейший редирект, но я подобного не видел:
— пишешь obmate.ru/ya.ru и попадаешь на сайт ya.ru
Спрашивается, а зачем он нужен? — Я его использую, когда прямую ссылку на давать не хочется. Адрес виден, но тИЦ и PR сайту не повышается.
Скрипт просто редиректит на строку после "/".

Может кому пригодится?
obmate.ru

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

Оттиск этой печати выглядит так:

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

Но речь не о деньгах, а о правильном редиректе…

Навеяно этой темой.

Собственно, речь о том, как я в своих проектах делаю проверку на повторное попадание POST или GET параметров в скрипт. А именно: при генерации формы я добавляю в hidden input определенный уникальный ключ, который записываю в некоторой лог таблице. При отправке запросов в скрипт, он выполняет нужные действия и ставит полученному ключу статус выполненности. Ну и собственно дальше просто — сделать проверку в скрипте, принимающем данные, не использован ли случайно ключ.

Очень странно, что подобных готовых плагинов не существует. Такое ощущение, что все обожают SMO, спамеров и целыми днями модерируют свой форум до потери пульса.
А решение совсем несложное:
Устанавливаем плагин Prime Links
После чего необходимо внести небольшие изменения в код плагина:
Открываем includes/prime_links.php, находим строку:
define('EXTERNAL_LINK_PREFIX', ''); // Example: 'http://anonym.to?'
заменяем на:
define('EXTERNAL_LINK_PREFIX', 'http://ваш_домен/папка_форума/go.php?'); // Example: 'http://anonym.to?'

В папке форума создаем файл go.php следующего содержания:
<?php
if (isset($_SERVER['QUERY_STRING'])) Header('Location: '.$_SERVER['QUERY_STRING']);
?>

Вот и все.
По желанию можно добавить в файл robots.txt
User-agent: *
Disallow: /папка_форума/go.php

плюс ко всему каждый обязан иметь правильный robots.txt для форума phpbb, в котором уже должны быть строки:
Disallow: /папка_форума/memberlist.php

P.S. и почему нет блога PHPBB, а wordpress есть?

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Сегодня столкнулся с проблемой — обнаружилось, что по ошибке старого системного администратора, в одном очень редком случае у нас происходил редирект с обычного 80 порта на порт 8080.

Из-за этого в индекс яндекса попала целая куча страниц, имеющих адрес example.com:8080, потому что проблема существовала уже 3 года, а заметили ее только сейчас.

Проблема усугублялась тем, что сервер конфигурировался автоматически с помощью ISP manager, что привело к тому, что сайты были доступны как по адресу example.com, так и по example.com:8080, и с учетом того, что к серверу было привязано 5 ip-адресов и на нем крутилось около 20 сайтов, переконфигурировать все вручную чтобы сконфигурировать правильным способом апач и nginx (сделать, чтобы апач слушал только 127.0.0.1 и чтобы они висели на одном порту с nginx, а внешние адреса слушал только nginx) не представлялось возможным. Проблеме потенциально подвержены все сайты, которые пользуются ISP manager, поэтому я считаю ее достаточно актуальной, и решил опубликовтаь свое решение, чтобы все тоже проверили и исправили, если надо.

Соответственно стояла задача — «малой кровью» сделать:
1. чтобы сайт example.com корректно работал, но не открывался по адресу example.com:8080
2. чтобы с порта 8080 для одного определенного сайта шел редирект на 80 порт, чтобы сохранить работоспособность страниц, попавших в выдачу яндекса.

Добрый день.
Хочу поделиться своим опытом по переводу сайта на новый домен с сохранением всех параметров старого.

Задача

Есть домен site.com с определенными показателями ТИЦ и PR, но мы хотим перенести проект (сайт) на новый адрес не теряя уже полученные кровью и потом результаты в поисковиках.

Решение

Сделать на старом домене site.com файл .htaccess, с содержанием:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} robots.txt$ [NC]
RewriteRule ^([^/]+) $1 [L]

RewriteCond %{HTTP_HOST} ^site\.com
RewriteRule ^(.*)$ http://site.org/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^www.site\.com
RewriteRule ^(.*)$ http://site.org/$1 [R=301,L]

Небольшая новость вдогонку к посту о некорректном поведении скрипта AddThis. Сотрудники техподдержки Yandex в ответах на многочисленные обращения владельцев «забаненных» ресурсов сообщают, что скрипт от Однакнопка.ру редиректит посетителей, использующих мобильные устройства, на вредоносные цели. Если используете на своих проектах скрипт от Однакнопка.ру, проверьте корректность работы ваших сайтов, дабы не потерять посетителей и не попасть под фильтры поисковых систем и браузеров.

Здравствуй, Хабр!

Год назад мы столкнулись с проблемой. Если в двух словах — нас взломали. Взломали творчески, так, что мы не сразу поняли, что вообще происходит. В процессе решения проблемы получилось овладеть полезными навыками: составлять abuse-обращения и результативно общаться с хостерами, в т.ч. — зарубежными, больше радеть о безопасности нашего ресурса, постоянно мониторить наличие нашего сайта в индексе Яндекс и Google, и внимательно относиться к мелочам. В описываемом случае обычный символ «-» (дефис, минус, тире, черточка, палочка, дефисоминус) сыграл с нами злую шутку.

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

Разработчик Робин Линус на своей странице на GitHub Pages (визит по следующей ссылке небезопасен и его не рекомендуется выполнять с рабочего места, так как кроме видимой части сервисов страница проверяет, залогинены ли вы на сайтах для взрослых, а это останется в логах файрволла как попытка перехода прим.) продемонстрировал, как сайты могут снимать с вас «медийный отпечаток», то есть вести учет того, в каких популярных сервисах залогинены посетители даже без какой-либо авторизации на посещаемой странице.

Для автора публикации «медийный отпечаток» выглядит следующим образом и является абсолютно верным:



И это весьма неприятно.

Geektimes присоединился к некой «партнерской программе», заменяющей прямые ссылки ссылками со скриптом перенаправления.

В код HTML добавился следующий внешний скрипт:

<script src="//js.mamydirect.com/js/?h=CqwpgTi7" type="text/javascript" async></script>

Скрипт, подключенный на страницы гиктаймза, заменяет ссылки, ведущие не на файлы .jpg, .bmp, .pdf, .png, .zip и .gif, находящихся не на доменах из черного списка, ссылкой с редиректом через скрипт http://js.mamydirect.com/redir/clickGate.php, вида:

http://js.mamydirect.com/redir/clickGate.php?u=RGm1L5B5&m=1&p=8d1pun3ZhJ&t=CqwpgTi7&st=&s=&splash=0&abp=1&url=https%3A%2F%2Fmeduza.io%2Fnews%2F2017%2F06%2F09%2Fdyru-v-reestre-roskomnadzora-ispolzovali-protiv-platezhnyh-serverov-rossiyskih-bankov&r=https%3A%2F%2Fgeektimes.ru%2Fpost%2F289947%2F

Он же, в свое время, добавляет куки PHPSESSID и совершает перенаправление на URL, указанный в ссылке.