Джанго рассматривает безопасность и лучшие практики - PullRequest
5 голосов
/ 20 апреля 2010

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

У меня есть представление, которое генерирует страницу и различные функции на странице, публикуемой AJAX-запросами к отдельным представлениям. Например, у меня есть представление под названием show_employees, и я могу удалять и обновлять сотрудников, передавая запрос на публикацию представлениям delete_employee и update_employee.

  1. Я поставил декораторы @login_required перед каждым из этих представлений, так как я не хочу, чтобы кто-то обращался к ним без аутентификации. Это нормально?

  2. В представлениях delete_employee и update_employee я отвечаю только на запрос, если это запрос AJAX POST (uisng is_ajax ()). Это нормально?

  3. Я возвращаю «успех», когда представление успешно выполняет то, что необходимо, и ошибку, когда в моей форме есть ошибка проверки, но я все еще не обрабатываю другие исключения. Как мне это сделать? Должен ли я возвращать стандартную страницу 500 через ответ AJAX, такой как this , обернув представление блоком try-Кроме, чтобы обработать все исключения?

  4. Могу ли я сделать что-нибудь еще для защиты своего зрения?

Вот пример моего вида:

    @login_required
    def add_site(request):
        data = {}
        if request.method == 'POST':
            if request.is_ajax():
                form = AddSiteForm(request.user, request.POST)
                if form.is_valid():
                    site = form.save(commit=False)
                    site.user = request.user
                    site.save()
                    data['status'] = 'success'
                    data['html'] = render_to_string('site.html', locals(), context_instance=RequestContext(request))
                    return HttpResponse(simplejson.dumps(data), mimetype='application/json')
                else:
                    data['status'] = 'error'
                    data['errors'] = {}
                    for field, error in form.errors.iteritems():
                        data['errors']['id_'+field] = strip_tags(unicode(error))
                    return HttpResponse(simplejson.dumps(data), mimetype='application/json')

Спасибо.

1 Ответ

11 голосов
/ 20 апреля 2010

Ну, вместо того, чтобы использовать только @login_required, я предлагаю вам взглянуть на структуру разрешений и связанный с ней требуемый уровень разрешения декоратора . Таким образом, вы можете точно настроить ограничения доступа для пользователей или групп. Также проще и безопаснее изменить поведение пользователя впоследствии с разрешениями, чем с помощью декоратора login_required. Предположим, что теперь у вас есть только администраторы, но позже вы захотите добавить других типов пользователей, тогда легко пропустить декоратор login_required и предоставить этим пользователям доступ к представлениям администратора. У вас не будет этой проблемы с правильно определенными разрешениями.

Затем is_ajax просто проверяет заголовок HTTP_X_REQUESTED_WITH. Это на самом деле не связано с безопасностью, но с дружественным поведением. Таким образом, вы предотвращаете случайное открытие этой страницы в браузере обычным пользователем и получение некоторых странных данных. В безопасности это не поможет, каждый порядочный хакер может установить дополнительный HTTP-заголовок:).

Необработка исключений может быть потенциально опасной, если вы случайно уйдете на DEBUG=True, и в этом случае django предоставит фрагменты кода и обратные трассировки, потенциально выявляя слабые места. Но если эта опция отключена, django покажет свою собственную страницу с ошибкой 500. Мое предложение таково: ищите все ожидаемые исключения django (их не так много) и убедитесь, что вы правильно их уловили. Кроме того, я бы сказал, что django будет обрабатывать другое исключение, django будет по-прежнему предоставлять возможность генерировать трассировки и другую отладочную информацию и отправлять их администраторам вместо отображения их на месте. Если вы обнаружите все непредвиденные ошибки, это поведение не будет доступно напрямую, возможно, вы не узнаете о сбое кода.

Наконец, когда вы работаете с пользовательскими входными данными, я бы посоветовал вам взглянуть на главу о безопасности в книге django, в которой объясняются наиболее важные угрозы и способы их устранения в рамки Джанго.

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