Недопустимый заголовок HTTP_HOST Django SuspiciousOperation

Ответ 1

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

В настоящее время разработчики Django обсуждают возможность изменить это с 500 внутренних ошибок сервера до ответа 400. См. этот билет.

Ответ 2

Если вы используете Nginx для пересылки запросов на Django, запущенных на Gunicorn/Apache/uWSGI, вы можете использовать следующее для блокировки плохих запросов. Спасибо @PaulM за предложение и этот пост в блоге для примера.

upstream app_server {
    server unix:/tmp/gunicorn_mydomain.com.sock fail_timeout=0;
}

server {

    ...

    ## Deny illegal Host headers
    if ($host !~* ^(mydomain.com|www.mydomain.com)$ ) {
        return 444;
    }

    location  / {
        proxy_pass               http://app_server;
        ...
    }

}

Ответ 3

При использовании Nginx вы можете настроить серверы таким образом, чтобы только запросы к хостам, которые вы хотите получить в Django, в первую очередь. Это не должно давать вам никаких ошибок SuspiciousOperation.

server {
    # default server

    listen 80;
    server_name _ default;

    return 444;
}
server {
    # redirects

    listen 80;
    server_name example.com old.stuff.example.com;

    return 301 http://www.example.com$request_uri;
}
server {
    # app

    listen 80;
    server_name www.example.com; # only hosts in ALLOWED_HOSTS here

    location  / {
        # ...
    }
    # ... your config/proxy stuff
}

Ответ 4

Это исправлено в новых версиях Django, но если вы используете уязвимую версию (например, 1.5), вы можете добавить фильтр к вашему обработчику журнала, чтобы избавиться от них, как указано в this в блоге.

Спойлер:

from django.core.exceptions import SuspiciousOperation

def skip_suspicious_operations(record):
  if record.exc_info:
    exc_value = record.exc_info[1]
    if isinstance(exc_value, SuspiciousOperation):
      return False
  return True

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse',
        },
        # Define filter
        'skip_suspicious_operations': {
            '()': 'django.utils.log.CallbackFilter',
            'callback': skip_suspicious_operations,
        },
    },
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            # Add filter to list of filters
            'filters': ['require_debug_false', 'skip_suspicious_operations'],
            'class': 'django.utils.log.AdminEmailHandler'
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
    }
}

Ответ 5

Я проверил ответы как webjunkie, так и Brent, но безуспешно. Ошибка все еще была "400 Bad Request" с электронной почтой при доступе к общедоступному IP. Изменение конфигурации nginx, которое сработало для меня, было ответом Solarissmoke на аналогичный вопрос.

В файле .conf удалите "default_server" с вашего основного сервера.

-    listen 443 default_server;
+    listen 443 ;

Добавьте прослушивание порта 443 следующим образом:

 server {
     listen 443 ssl default_server;
     server_name _;
     return 444;
 }