Предотвращение мошеннических пауков из каталога индексации - PullRequest
Новая
       17

Предотвращение мошеннических пауков из каталога индексации

0 голосов
/ 01 февраля 2011

У нас есть защищенный веб-сайт (разработанный на .NET 2.0 / C #, работающий на сервере Windows и IIS 5), на который участники должны войти, а затем они могут просматривать некоторые файлы PDF, хранящиеся в виртуальном каталоге. Чтобы запретить паукам сканировать этот веб-сайт, у нас есть файл robots.txt, который запрещает вход всех пользовательских агентов. Однако это НЕ помешает паукам-мошенникам индексировать PDF-файлы, поскольку они игнорируют команды robots.txt. Поскольку документы должны быть в безопасности, я не хочу, чтобы в этот виртуальный каталог попадали ЛЮБЫЕ пауки (даже самые хорошие).

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

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

  1. Создание Honeypot / tarpit, который позволит проникнуть негодяям-паукам, а затем перечислит их IP-адрес. Минусы: это также может блокировать действительных пользователей, приходящих с одного и того же IP-адреса, необходимо вручную поддерживать этот список или иметь какой-то способ для участников удалить себя из списка. У нас нет диапазона IP-адресов, которые будут использовать действительные участники, так как веб-сайт находится в Интернете.

  2. Анализ заголовка запроса: Однако, пауки-изгои используют имена реальных агентов, так что это бессмысленно.

  3. Тэг мета-роботов: Минусы: подчиняются только Google и другим действительным паукам.

Был разговор об использовании .htaccess, который, как предполагается, хорош, но это будет только Apache, а не IIS.

Любые предложения очень приветствуются.

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

Ответы [ 3 ]

3 голосов
/ 01 февраля 2011

Я вижу противоречие между

. Членам необходимо войти в систему, а затем они могут просматривать некоторые файлы PDF, хранящиеся в виртуальном каталоге

и

* 1008.*

это НЕ помешает мошенническим паукам проиндексировать PDF-файлы

Почему любой неавторизованный HTTP-запрос к этому каталогу когда-либо обрабатывается чем-то еще, кроме кода 401?Пауки-румяна, конечно, не могут предоставить авторизационный cookie.И если каталог для них доступен, что такое «вход в систему»?

Возможно, вам нужно обслуживать PDF-файлы через скрипт, который проверяет авторизацию.Я думаю, что IIS также может требовать авторизацию только для доступа к каталогу (но я действительно не знаю).

1 голос
/ 03 февраля 2011

Вот что я сделал (расширив код Ли).

  1. Создал HTTPHandler для файлов PDF, создал web.config в защищенном каталоге и настроил обработчик для обработки PDF-файлов.

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

  3. Если у пользователя есть переменная сеанса, я создаю объект fileInfo и отправляю его в ответе. Примечание: не делайте context.Response.End (), также «Content-Disposition» устарел.

Так что теперь, когда даже есть запрос на PDF в защищенном каталоге, обработчик HTTP получает запрос и проверяет, вошел ли пользователь в систему. Если нет, отобразите сообщение об ошибке, иначе отобразите файл.

Не уверен, что производительность снижается, поскольку я создаю объекты fileInfo и отправляю их, а не отправляю файл, который уже существует. Дело в том, что вы не можете Server.Transfer или Response.Redirect к файлу * .pdf, поскольку вы создаете бесконечный цикл и ответ никогда не будет возвращен пользователю.

1 голос
/ 02 февраля 2011

Я предполагаю, что ваши ссылки на PDF-файлы приходят из известного местоположения. Вы можете проверить Request.UrlReferrer, чтобы убедиться, что пользователи переходят с этой внутренней / известной страницы для доступа к PDF-файлам.

Я бы определенно заставил загрузки проходить через скрипт, где вы можете проверить, действительно ли пользователь зашел на сайт, прежде чем разрешить загрузку. 

protected void getFile(string fileName) {

/* 
    CHECK AUTH / REFERER HERE
*/

    string filePath = Request.PhysicalApplicationPath + "hidden_PDF_directory/" + fileName;

    System.IO.FileInfo fileInfo = new System.IO.FileInfo(filePath);

    if (fileInfo.Exists) {
        Response.Clear();
        Response.AddHeader("Content-Disposition", "attachment; filename=" + fileInfo.Name);
        Response.AddHeader("Content-Length", fileInfo.Length.ToString());
        Response.ContentType = "application/pdf";
        Response.WriteFile(fileInfo.FullName);
        Response.End();
    } else {

/*
    ERROR
*/

    }
}

Не проверено, но это должно дать вам хотя бы представление.

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

...