запретить связывать css с других сайтов

#c# #asp.net #iis #cufon

#c# #asp.net #iis #cufon

Вопрос:

У меня есть comerce css на моем сайте. Я использую IIS, и поставщик говорит, что другие могут использовать мои css-шрифты, потому что они знают URL. Можно ли настроить сервер или что- то в этом роде, чтобы только мой сайт мог его использовать? Речь идет о cufon

Комментарии:

1. Используйте что-то вроде Typekit вместо Cufon.

Ответ №1:

То, что ты можешь сделать:

  1. Сдавайтесь. Если ваши пользователи могут это видеть, они могут это украсть. Точно так же не ожидайте, что ваш сайт будет защищен от пользователей, просматривающих его исходный код.
  2. Если шрифт является векторным, растрируйте шрифт для всех поддерживаемых вами размеров шрифта, но не для других. Это может оказать негативное влияние на работу ваших пользователей в Интернете. Это приводит к тому, что при краже вашего шрифта получаются менее полезные данные, но фактически не останавливает кражу.
  3. Полностью замените использование шрифта растровыми изображениями. В этом случае гораздо больше работы по краже, и пользователю предоставляется только растрированная версия шрифта (и не обязательно все буквы). Вы можете создать специальный текст UserControl , который прикрепляет растровое изображение, куда бы вы его ни поместили, так что на самом деле это не так уж много работы по выполнению или сопровождению. Однако это увеличивает требования к пропускной способности вашей страницы. Это также вынуждает вас выполнять часть верстки вручную, которая обычно обрабатывается браузером, что может привести к большим или минимальным затратам на обслуживание, в зависимости от того, как работает верстка вашего сайта. И, как и в случае с #2, это может оказать негативное влияние на работу ваших пользователей в Интернете. Это также ухудшает доступность, хотя и не абсурдно, поскольку ваш UserControl , по-видимому, будет использовать alt text для дублирования текста.

Я настоятельно рекомендую # 1.

Комментарии:

1. помните, что придание шрифтам фиксированного размера, например, растровым изображениям, является ПЛОХОЙ ИДЕЕЙ для обеспечения доступности

Ответ №2:

Если вы используете IIS7 или более позднюю версию, вы можете выполнить проверку Refererer без написания какого-либо пользовательского кода, просто используя IIS URL Rewrite в manor, обсуждаемом здесь. Однако, как простая проверка реферера, она имеет недостатки, обсуждаемые в других приведенных ответах.

(Для ознакомления с перезаписью URL-адреса IIS смотрите здесь.)

Выдержка из первой ссылки:

Позвольте мне теперь объяснить, что мы сделали на этой странице свойств:

  • Указано название правила как «Предотвращать пиявничество». Это должно быть уникальное правило.
  • Каждому запрошенному URL будет соответствовать шаблон «.*», который является регулярным выражением.
  • Добавлено два условия и указано, что оба условия должны выполняться (см. «Логическая группировка» — «Соответствовать всем»)
  • HTTP_REFERER не соответствует empty, поскольку это может быть прямая ссылка на изображение
  • HTTP_REFERER не соответствует моему собственному сайту http://www.contoso.com

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

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

Если у вас нет доступа к удаленному рабочему столу или вы просто редактируете web.config , ваше правило перезаписи, вероятно, будет выглядеть примерно так:

     <rule name="block font leaching" stopProcessing="true">
      <match url="myFontFile.woff" />
      <conditions logicalGrouping="MatchAny">
        <add input="{HTTP_REFERER}" pattern="^$" /><!-- no referrer -->
        <add input="{HTTP_REFERER}" pattern="yourdomain.com" negate="true" /><!-- or not your site -->
      </conditions>
      <action type="AbortRequest" /><!-- block the request -->
    </rule>
  

В этом примере я выбираю полностью блокировать запрос (через AbortRequest ), однако вы могли бы с таким же успехом перенаправить на страницу с дружественным уведомлением.

Ответ №3:

Ненадежно. Чтобы предоставлять встроенные шрифты, они должны быть общедоступными и ссылаться на ваш CSS.

Что вы могли бы сделать, так это создать asp.net страница или обработчик, который принимает параметр файла шрифта, считывает файл откуда-то с вашего веб-сайта (APP_DATA — хорошее место для их размещения — вы не можете перейти к APP_DATA) и выдает его. В скрипте вы могли бы проверить переменную на стороне сервера HTTP_REFERER, и если она либо пуста, либо поступает с вашего сайта, вы размещаете файл на сервере, если это не так, вы этого не делаете.

В MSDN есть пример того, как обслуживать двоичный файл на C #. Вам нужно убедиться, что вы правильно указали тип MIME, однако имейте в виду, что это, вероятно, нарушит любое кэширование, предоставляемое браузером или прокси. Это также не помешало бы людям загружать шрифты, вводя URL в свой браузер и сохраняя их локально, но если проблема в пропускной способности, это на самом деле не будет проблемой.

Если вы используете IIS7, вы могли бы написать Http-модуль, который выполнял бы проверку реферера для вас, Скотт Ханслман написал его для предотвращения утечки изображений довольно давно, вы могли бы отредактировать его в соответствии с вашими целями.

Комментарии:

1. 1, также важно отметить, что для OP ничто не помешает им скопировать вставить его и разместить самостоятельно. Я бы поставил под сомнение важность этого, даже если пропускная способность CSS уменьшается, вероятно, это очень мало.

2. Следует отметить, что даже если HTTP_REFERER проверено на стороне сервера, оно может быть довольно легко подделано кем угодно (просто нужно отправить заголовок с нужным значением); другими словами, обслуживание его из обработчика делает немного больше для защиты ресурса, чем его статическое обслуживание.

Ответ №4:

Вы могли бы создать http-обработчик для обслуживания файлов css. В вашем пользовательском http-обработчике убедитесь, что request.Url.Host равен request .UrlReferrer.Host. Если они не совпадают, задайте для ответа значение 404 или отправьте пустой файл css.

Это непроверено, но должно быть близко к тому, что вам нужно. Вы бы добавили ссылку на css, например:

 <link rel="Stylesheet" href="CustomCSSHandler.ashx?file=site.css" />


public class CustomCSSHandler : IHttpHandler 
{
    public void ProcessRequest(HttpContext ctx) 
    {
        HttpRequest req = ctx.Request;
        //Get the file from the query stirng
        string file = req.QueryString["file"];
        //Find the actual path
        string path = ctx.Server.MapPath(file); //Might need to modify location of css

        //Limit to only css files
        if(Path.GetExtension(path) != ".css")
            ctx.Response.End();

        if (req.UrlReferrer != null amp;amp; req.UrlReferrer.Host.Length > 0)
        {
            if (CultureInfo.InvariantCulture.CompareInfo.Compare(req.Url.Host, req.UrlReferrer.Host, CompareOptions.IgnoreCase) != 0)
            {
                path = ctx.Server.MapPath("~/thiswontexist.css");
            }
        }   

        //Make sure file exists
        if(!File.Exists(path))
        {
            ctx.Response.Status = "File not found";
            ctx.Response.StatusCode = 404;
            ctx.Response.End(); 
        }           

        ctx.Response.StatusCode = 200;
        ctx.Response.ContentType = "text/css";
        ctx.Response.WriteFile(path);
    }
}