peliculas - django wikipedia

SuspiciousOperation de Django, encabezado HTTP_HOST no válido

Question

Después de actualizar a Django 1.5, comencé a recibir errores como este:

Traceback (most recent call last):

File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 92, in get_response
response = middleware_method(request)

File "/usr/local/lib/python2.7/dist-packages/django/middleware/common.py", line 57, in process_request
host = request.get_host()

File "/usr/local/lib/python2.7/dist-packages/django/http/request.py", line 72, in get_host
"Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS): %s" % host)

SuspiciousOperation: Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS): www.google.com

<WSGIRequest
path:/,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{''CONTENT_LENGTH'': '''',
''CONTENT_TYPE'': '''',
''DOCUMENT_ROOT'': ''/etc/nginx/html'',
''HTTP_ACCEPT'': ''text/html'',
''HTTP_HOST'': ''www.google.com'',
''HTTP_PROXY_CONNECTION'': ''close'',
''HTTP_USER_AGENT'': ''Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)'',
''PATH_INFO'': u''/'',
''QUERY_STRING'': '''',
''REMOTE_ADDR'': ''210.245.91.104'',
''REMOTE_PORT'': ''49347'',
''REQUEST_METHOD'': ''GET'',
''REQUEST_URI'': ''/'',
u''SCRIPT_NAME'': u'''',
''SERVER_NAME'': ''www.derekkwok.net'',
''SERVER_PORT'': ''80'',
''SERVER_PROTOCOL'': ''HTTP/1.0'',
''uwsgi.node'': ''derekkwok'',
''uwsgi.version'': ''1.4.4'',
''wsgi.errors'': <open file ''wsgi_errors'', mode ''w'' at 0xb6d99c28>,
''wsgi.file_wrapper'': <built-in function uwsgi_sendfile>,
''wsgi.input'': <uwsgi._Input object at 0x953e698>,
''wsgi.multiprocess'': True,
''wsgi.multithread'': False,
''wsgi.run_once'': False,
''wsgi.url_scheme'': ''http'',
''wsgi.version'': (1, 0)}>

Establecí ALLOWED_HOSTS = [''.derekkwok.net''] en mi archivo settings.py.

¿Que esta pasando aqui? ¿Alguien que pretende ser Google y acceder a mi sitio? ¿O es un caso benigno de que alguien configure su encabezado HTTP_HOST incorrectamente?

Answer 1

Al usar Nginx, en primer lugar, podría configurar sus servidores de una manera que solo solicite a los hosts que desea obtener a Django. Eso ya no debería darte errores de Operación Sospechosa.

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
}

Answer 2

Esto se soluciona en las versiones más nuevas de Django, pero si está utilizando una versión afectada (por ejemplo, 1.5) puede agregar un filtro a su manejador de registros para deshacerse de estos, como se describe en tiwoc.de/blog/2013/03/… publicación de blog.

Spoiler:

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,
        },
    }
}

Answer 3

Si está utilizando Nginx para reenviar solicitudes a Django que se ejecuta en Gunicorn / Apache / uWSGI, puede usar lo siguiente para bloquear las solicitudes incorrectas. Gracias a @PaulM por la sugerencia y a esta publicación en el blog como ejemplo.

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;
        ...
    }

}

Answer 4

Si su ALLOWED_HOSTS está configurado correctamente, entonces es posible que alguien esté investigando su sitio para detectar la vulnerabilidad falsificando el encabezado.

Los desarrolladores de Django ahora están discutiendo para cambiar esto de un error de servidor interno de 500 a una respuesta de 400. Vea este boleto .