Настройка фильтра «RequireHttpsAttribute» для учета X-Forwarded-Proto - PullRequest
Новая
       17

Настройка фильтра «RequireHttpsAttribute» для учета X-Forwarded-Proto

0 голосов
/ 26 февраля 2019

Я размещаю приложение ASP.NET Framework на эластичном компоненте AWS и использую балансировщик нагрузки.

Использование моей текущей конфигурации для запроса https приводит к бесконечным циклам, поскольку балансировщики нагрузки используют http дляобщаться с сервером.Для того, чтобы иметь функцию фильтра, мне нужно учесть заголовок X-Forwarded-Proto, который, насколько я понимаю, содержит исходный протокол запросов.Я понимаю, что не так, но я не понимаю, как использовать этот атрибут для обеспечения безопасного соединения.

Это моя текущая конфигурация: 

public class RequireHttpsAttribute : AuthorizationFilterAttribute {

    public int Port { get; set; }

    public RequireHttpsAttribute()
    {
        Port = 443;
    }

        public override void OnAuthorization(HttpActionContext actionContext)
        {
            var request = actionContext.Request;

            if (request.RequestUri.Scheme != Uri.UriSchemeHttps)
            {
                var response = new HttpResponseMessage();

                if (request.Method == HttpMethod.Get || request.Method == HttpMethod.Head)
                {
                    var uri = new UriBuilder(request.RequestUri);
                    uri.Scheme = Uri.UriSchemeHttps;
                    uri.Port = this.Port;

                    response.StatusCode = HttpStatusCode.Found;
                    response.Headers.Location = uri.Uri;
                }
                else
                {
                    response.StatusCode = HttpStatusCode.Forbidden;
                }

                actionContext.Response = response;
            }
            else
            {
                base.OnAuthorization(actionContext);
            }
        }
}

Эта конфигурация фильтрадобавлен в мой WebApiConfig.

Мой вопрос: как проверить наличие X-Forwarded-Proto в этом фильтре?

1 Ответ

0 голосов
/ 26 февраля 2019

Если ваши балансировщики нагрузки обрабатывают SSL для вас, вы бы уступили это ограничение (только для SSL) для них - как вы заметили, ваше приложение всегда обнаружит http:80 (не https:443)).

Не используйте RequireHttpsAttribute в веб-API, которые получают конфиденциальную информацию.RequireHttpsAttribute использует коды состояния HTTP для перенаправления браузеров с HTTP на HTTPS. Клиенты API могут не понимать перенаправления с HTTP на HTTPS или подчиняться им. Такие клиенты могут отправлять информацию по HTTP.Веб-API должны:

  • Не прослушивать HTTP.
  • Закройте соединение с кодом состояния 400 (Bad> Request) и не обслуживайте запрос.

В примечании в документе указано, что API клиенты могут / не могут следовать вашему ответу на перенаправление, поэтому рекомендуется, чтобы вы ответили с какой-то ошибкой (или не совсем) - и именно здесь вам следует проверить заголовки http.В вашем случае вы не можете сделать первое, потому что ваше приложение всегда будет получать HTTP: 80 (отсюда только проверка заголовка http / фильтр).

На сайте MVC вы можете выполнять перенаправления маршрутизации (UrlПереписать и т. Д.), Но это работает, потому что клиенты являются браузерами (и знают, что делать с redirect).Однако клиент API может быть любым (не только браузером).

Обновление / уточнение:

Конечно, важно, чтобы вы должны по-прежнему фильтрует http header, пересылаемые вашими балансировщиком нагрузки, которые указывают, был ли исходный запрос через https или нет, и следуют рекомендациям в doc - ответьте соответствующим кодом ошибки http (примечаниепредлагает 400 Bad Request).

То, что вы не можете сделать, это проверить фактическую схему / протокол запроса источника, потому что ваши балансировщики нагрузки будут всегда перенаправлять http:80 в ваше приложение.

TLDR: вы ограничиваете информацию на основе заголовка http, передаваемого вашими балансировщиком нагрузки.

...