понедельник, 24 декабря 2007 г.

Защита от сервиса с непристойным названием

или Окапываемся в SAPE (часть 3)

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

Вкратце поясню, принцип работы сервиса для тех, кто в бронетранспортёре.

Как, в общем-то, и ожидалось, алгоритм оказался до безобразия простым. Получая на вход исследуемую ссылку, сервис подставлял к урлу мусор в виде дополнительных параметров, тем самым нагло изменяя ссылку, которую сравнивает саповский скрипт с находящейся в файле links.db.

Проще говоря, получая на вход такой линк http://site.ru/, сервис загружает сраницу, затем генерит примерно следующий урл http://site.ru/?vsyakiy_musor=!@#$^%&*() и по нему загружает вторую страницу. Сравнивает их, берет разность по ссылкам и считает ее продажной.

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

Расскажу что я сделал для того чтобы обмануть сервис. Для этого залез в sape.php

С помощью метода тыка и добрался до этого блока. 

...
// Убиваем PHPSESSID
if (strlen(session_id())) {
$session = session_name() . '=' . session_id();
$this->_request_uri = str_replace(array('?'.$session,'&'.$session), '', $this->_request_uri);
}
...

В данном блоке производится выкашивание из $this->_request_uri идентификатора сессии. И мне показалось данная операция является очень схожей с той которая нам нужна. Только в моем случае надо убивать не только сессию, но и все что приходит после символа '?'.

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

  $this->_request_uri = preg_replace('/\?\S*/',"",$this->_request_uri);

Сохранил изменения. Проверяю...

Еззз! После этих манипуляций чудо-сервис прекратил определять все автоговнолинки.

Ну что господа?! Кто ещё не в Sape?! Бегом регаться, пока ироды какой-нибудь другой бяки не придумали :)

А чуть не забыл. Хочу предупредить, данное решение работает только на урлах без параметров и/или поверх ЧПУ-ссылок. То есть если сравниваемые урлы будут с параметрами, то задача по противостоянию усложняется в разы. Как я вижу, нужно будет определять все допустимые параметры и с помощью тех же регулярных выражений, но более извращенных, производить их фильтрацию. Но это охрененное усложнение. Лучше и проще, на мой взгляд, юзать mod_rewrite, тем более в популярных движках поддержка ЧПУ-ссылок уже является стандартом де-факто.

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

9 Comments:

Анонимный said...

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

Анонимный said...

аноним, тебе лечиться пора.

Доброжелатель said...

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

Юзайте модрерайт и 404 ошибку для несуществующих страниц - и будет вам счастье.

bum said...

2 Доброжелатель:
...рождает сквозные ссылки вместо обычных...
Можно ли уточнить, что вы подразумеваете под сквозными ссылками?

Энергетик said...

Мдя, не совсем понятно что Доброжелатель хотел донести до народа, говоря о "ссылочном". Чего "ссылочном"?

samsonych said...

Ну c модрерайтом всё понятно.
А вот 404 ошибку юзать. Это как?
Может кто подскажет?

provocateur-b said...

А вы читали новости? Sape снова нас порадовал.

rEd said...

Доброжелатель советует настроить свой сайт так, чтобы запрос _любого_ несанкционированного УРЛа возвращал 404ю. Это решит не только проблему с определением проданых ссылок алгоритмом сервиса, но и проблему дублированного контента на самом сайте (т.е. страниц с разным адресом но одинаковым содержимым).

Евгений said...

Спасибо за эту публикацию! Не прошло и полгода, как я ее нашел :)

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