Короткие ссылки как способ разноса «заразы».

Не так уж давно, а точнее с момента регистрации своего аккаунта в Twitter, я начал пользоваться различными сервисами сокращения ссылок наподобие bit.ly, is.gd и прочих. Причин использования сервисов было несколько, но одна из основных — сокращение, иногда до 95% длины первоначальной ссылки, что немаловажно примаксимальной длине сообщения в твитере в 140 символов.
Несмотря на очевидные преимущества короткие ссылки имеют также и не менее очевидные недостатки и иногда могут нанести вред компьютеру. Рассмотрим некоторые из этих проблем.

Какова цена вопроса?

Представим себе такую ситуацию: у Вас медленное Интернет-соединение и Вы натыкаетесь на ссылку вида http://is.gd/cEudm с описанием, типа «Программа для сжатия ссылок«.
Откуда бы Вам знать что откроется при клике по ссылке? Страничка с описанием программы весом в 100 Кб или это ссылка на exe-шник весом в несколько мегабайт?
Возникает вопрос: ткнуть или не ткнуть в ссылку? Возникновение подобных вопросов — это, пожалуй, самый мелкий недостаток коротких ссылок.
Решение проблемы с помощью сервиса. Многие сервисы коротких ссылок предоставляют в наше распоряжение так называемый предпросмотр ссылки. Делается это с помощью добавления к короткому URL какого-либо символа — «=», «+» и т.д. В результате открывается не целевая страница, а страница сервиса с описанием того, куда вы будите перенаправлены.
Однако не все сервисы имеют подобные «фичи» и в таких случаях нам поможет Delphi.
Решение проблемы с помощью Delphi. Какой бы «навороченный» ни был сервис — работает он всегда и везде по одному очень простому алгоритму:

1. По длинной ссылке составляется хэш (в приведенном выше примере хэш = cEudm). Этот хэш вместе с длиным URL сохраняется в базе данных на сервере
2. При клике по короткой ссылке мы переходим на сервер сервиса и нам по хэшу возвращается редирект (301 или 304) на целевой URL
3. Мы отправляемся по URL, а сервис (если у него предусмотрено) сохраняет статистику, например, откуда мы пришли, когда и т.д.

Следовательно в самом простом случае от нас требуется не так много:

1. Отправить на короткий URL запрос HEAD и вытянуть из заголовков ответа сервера значение «Location:», получив тем самым URL назначения.
2. Отправить второй HEAD на полученный URL и получить заголовок «Content-Length: «.

Сделать это достаточно просто, используя тот же Synapse. Например так:
1. Получение значения заголовка «Location:»:

function GetTargetURL(const aHeaders: TStringList): string;
var i:integer;
begin
  Result:='';
  if aHeaders=nil then Exit;
  for i:=0 to aHeaders.Count - 1 do
    begin
      if pos('location:',LowerCase(aHeaders[i]))>0 then
       begin
         Result:=copy(aHeaders[i],11,length(aHeaders[i])-pos('location:',LowerCase(aHeaders[i])));
         break;
       end;
    end;
end;

Здесь в качестве входного параметра выступает StringList со всеми заголовками ответа сервера, который можно получить так:

 with THTTPSend.Create do
    begin
      if HTTPMethod('HEAD',ShortLink) then
        aHeaders:=Headers
      else
        ShowMessage('Ошибка отправки запроса')
    end;

Далее, отправляем точно такой же запрос на полученный с помощью функции GetTargetURL URL и читаем размер документа:

function GetContentLength(const aHeaders: TStringList): integer;
var i:integer;
begin
  Result:=0;
  if aHeaders=nil then Exit;
  for i:=0 to aHeaders.Count - 1 do
    begin
      if pos('content-length:',LowerCase(aHeaders[i]))>0 then
       begin
         Result:=StrToInt(copy(aHeaders[i],17,length(aHeaders[i])-pos('content-length:',LowerCase(aHeaders[i]))));
         break;
       end;
    end;
end;

Здесь же можно определить и тип данных, который лежит «по ту сторону». Для этого нам необходимо получить значение заголовка Contet-type:

function GetContentType(const aHeaders: TStringList): string;
var i:integer;
begin
  Result:='';
  if aHeaders=nil then Exit;
  for i:=0 to aHeaders.Count - 1 do
    begin
      if pos('content-type:',LowerCase(aHeaders[i]))>0 then
       begin
         Result:=copy(aHeaders[i],15,length(aHeaders[i])-pos('content-type:',LowerCase(aHeaders[i])));
         break;
       end;
    end;
end;

В целом проблему можно считать решенной..но только в целом, так как есть ещё одно очень большое «НО» и именного его мы рассморим.

«Открыл ссылку и чё-то всё сначало замерло, а потом комп перезагрузился. Это не вирус?»

Довольно частые вопросы в Сети не правда ли? В плане распространения всяческой «заразы», начиная от спама и заканчивая вирусами, троянами и пр. вредоносным ПО короткие ссылки могут смело занимать первое место. И это довольно не шуточная проблема как для нас — конечных пользователей, так и для самих сервисов коротких ссылок.
Так буквально недавно узнал, что достаточно популярный сервис коротких ссылок tr.im полностью сворачивает свою деятельность именно по причине того, что на сервис было заявлено большое количество абуз по поводу распространения спама и вирусов.
Решение проблемы с помощью сервисов. Можно привести ещё пару подобных примеров, но суть не изменится. И владельцы крупных сервисов сокращения ссылок это прекрасно понимают и стараются с этим как-то бороться. Примером подобной борьбы со спамом может служить сервис is.gd. Этот сервис перед тем как сжать ссылку «пробивает» её по базе опасных сайтов и, если ссылка ведет на опасный сайт, отказывается её обрабатывать. Но далеко не все сервисы используют такие механизмы защиты, да и сам механизм не так уж и надежен. Приведу простой пример как обходится такая «защита».

Есть сайт A на котором лежит в полной боевой готовности троянский конь или другая хрень. Адрес этого сайта нада «впарить» незадачливому пользователю. Сервис не «дурак» и весть об опасном сайте А уже давно известна. Берем ещё парочку «белых и пушистых» доменов, скажем B и C и выставляем на них редиректы:
C —> B —> A
«Скармливаем» сервису ссылочку на домен C, получаем короткую ссылку и идем спокойно её распространять.

Пример абсолютно простой и в плане распространения вредоносного ПО практичски неработоспособный, но с «защитой» сервисов справляется. Как быть, если вдруг мы нарвемся на такую короткую ссылку? Превьюшка сервиса вернет нам адрс на домен C и не более.
Собственных решений может быть как минимум два.
1. Проверяем домен в Google. Для тех кто не в курсе — у Google уже давно и довольно плодотворно формируется большая база данных по сайтам замеченным в фишинге, спаме и т.д. И Google предоставляет нам эту базу для работы. Без залезаний в дебри API могу привести пример как воспользоваться базой. Для этого достаточно перейти по URL вида:

http://www.google.com/safebrowsing/diagnostic?site=домен

В результате мы получим страничку с таким содержанием:

Всё довольно информативно и понятно. На русском языке. Но Google тоже не всемогуч и всесилен. Поэтому можно объединить этот способ проверки с нашим «доморощенным», написанным на Delphi. Суть метода — отслеживание всех редиректов и дополнительная проверка по объединенной базе опасных сайтов каждого из доменов, обнаруженных при анализе ссылке.
Этот метод по технической реализации достаточно прост и одновременно эффективен и о нем мы поговорим (и рассмотрим реализацю) в следующий раз, т.к. решение будем рассматривать подробно.
В заключение можно сказать, что представленные две проблемы коротких ссылок не все — есть ещё ряд моментов, как-то — потеря всех своих ссылок при закрытии сервиса, наличие «межающих» ссылок на страницах сайта и т.д., но — то по своей сути, не такие уж важные проблемы, нежели распространение вирусов.