Я недавно начал работать над Django, и теперь мое приложение приближается к завершению, и я начал задаваться вопросом о безопасности и лучших практиках.
У меня есть представление, которое генерирует страницу, и различные функции на странице отправляют запросы Ajax на отдельные представления. Например, у меня есть представление, названное show_employees, и я могу удалить и обновить сотрудников путем передачи запроса сообщения представлениям delete_employee и update_employee.
Я поместил @login_required декораторов перед каждым из этих представлений, так как я не хочу никого получающего доступ к ним без того, чтобы быть аутентифицируемым. Это хорошо?
В delete_employee и представлениях update_employee, я только отвечаю на запрос, если это - Ajax запрос POST (использующий is_ajax ()). Это хорошо?
Я возвращаю 'успех', когда представление преуспевает в том, чтобы делать то, что необходимо и ошибка, когда существует ошибка Проверки в моей форме, но я все еще не обрабатываю другие исключения. Как я должен сделать это? Я должен возвратиться, стандартные 500 пролистывают ответ Ajax как это путем обертывания представления с попыткой - кроме блока для обрабатывания всех исключений?
Есть ли что-либо еще, что я могу сделать безопасный мое представление?
Вот демонстрационное мое представление:
@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')
Спасибо.
Что ж, вместо того, чтобы использовать только @login_required, я предлагаю вам взглянуть на структуру разрешений и связанный декоратор требуемых разрешений . Таким образом, вы можете точно настроить ограничения доступа для пользователей или групп. Также проще и безопаснее впоследствии изменить поведение пользователя с разрешениями, чем с помощью декоратора login_required. Предположим, что теперь у вас есть только администраторы, но позже вы захотите добавить другие типы пользователей, тогда легко пропустить декоратор login_required и предоставить этим пользователям доступ к представлениям администратора. У вас не будет этой проблемы с правильно определенными разрешениями.
Затем is_ajax просто проверяет заголовок HTTP_X_REQUESTED_WITH. На самом деле это имеет отношение не к безопасности, а к удобному для пользователя поведению. Таким образом вы предотвратите случайное открытие этой страницы в браузере обычным пользователем и получение странных данных. В безопасности ничего не помогает, каждый порядочный хакер может установить дополнительный HTTP-заголовок :).
Отказ от обработки исключений может быть потенциально опасным, если вы случайно оставите DEBUG = True
, и в этом случае django предоставит фрагменты кода и трассировки, потенциально выдавая слабые места. Но если эта опция отключена, django покажет свою страницу с ошибкой 500. Мое предложение: найдите все ожидаемые исключения django (их не так много) и убедитесь, что вы их правильно поймаете. Далее я бы сказал, пусть другое исключение будет обработано django, django по-прежнему будет предоставлять возможности для генерации обратных трассировок и другой отладочной информации и отправки их администраторам вместо отображения их на сайте. Если вы обнаружите все неожиданные ошибки, это поведение не будет напрямую доступно, возможно, вы не будете знать о сбое кода.
Наконец, когда вы работаете с данными, вводимыми пользователем, я бы посоветовал вам взглянуть на главу о безопасности в книге django, где объясняются наиболее важные угрозы и способы их устранения в фреймворк django.