30. Принятие основных решений по видам обеспечений системы

31. Принятие основных решений по безопасности и отказоустойчивости системы

Безопасность системы основывается на средствах, имеющихся во фреймоврке Django. В п.п. 2.5.1 - 2.5.5 будут рассмотрены основные моменты по обеспечению безопасности разработанного web-приложения.

Защиту базы данных от несанкционированного локального доступа предполагается осуществлять с использванием средств серверной ОС (БД хранится в одном файле, права доступа к которому можно контролировать стандартными средствами ОС).

Так же отметим решения, принятые по другим вопросам безопасности, а именно:

38. Код web-приложения находится вне корня web-сервера. Это не позволит злоумышленнику отобразить его в виде текста, или запустить его на выполнение.

39. Ограничение попыток аутентификации пользователя в единицу времени. Таким образом, система будет защищена от brute-force атак по подбору пароля.

40. Ограничение на размер принимаемых файлов. Таким образом, система будет защищена от некоторых атака класса DOS.

Так же, настоятельно рекомендуется использование фаервола для ограничения несанкионированного доступа к системе.

32. Защита от межсайтового скриптинга (xss)

XSS атаки позволяют пользователю вставить собственные JS скрипты в браузеры других пользователей. Это достигается с помощью сохранения вредоносных скриптов в базе данных, которые затем запрашиваются и отображаются браузерами других пользователей, или принуждением пользователя нажать на ссылку, которая позволит вредоносному скрипту выполниться в браузере пользователя. Однако, XSS атаки могут происходить из любого недоверенного источника данных, такого как куки или веб сервисы, в случае когда данные были недостаточно очищены перед их размещением на странице.

Шаблоны Django экранируют специальные символы, которые обычно создают проблемы для HTML. В частности, экранирование специальных символов осуществляются следующие автоматические замены:

11. < заменяется на <

21. > заменяется на >

22. ' (одинарная кавычка) заменяется на '

23. " (двойная кавычка) заменяется на "

24. & заменяется на &amp.

33. Защита от подделки межсайтового запроса (csrf)

CSRF атаки позволяют недобросовестному пользователю выполнять действия от имени другого пользователя, без ведома последнего или его согласия.

CSRF защита работает, проверяя метку с текущим временем в каждом POST запросе. Она не позволяет злоумышленнику просто сформировать POST запрос и создать возможность другому авторизованному пользователю неумешленно отправить эту форму. Злоумышленнику потребуется знать содержимое метки, которое сильно зависит от пользователя (используются cookie).

Django обладает встроенной защитой против большинства типов CSRF атак.

Для реализации данного метода защити, в каждом POST запросе используется CSRF-token.

34. Защита от внедрения sql (sql-injection)

Внедрение SQL — это тип атаки, когда недобросовестный пользователь имеет возможность выполнить в базе данных определённый SQL запрос. Результатом выполнения такого запроса может быть удаление или даже утечка данных.

При использовании Django ORM созданный SQL запрос будет правильно экранирован соответствующим драйвером базы данных.

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

35. SSL/HTTPS

Применение этой защиты хорошо отражается на безопасности, хотя и не всегда уместно с практической точки зрения. При отсутствии HTTPS злоумышленник имеет возможность перехватывать аутентификационные данные или любую другую информацию, передаваемую между клиентом и сервером. А в случае активной атаки — может даже изменять данные, передаваемые в любом направлении.

Для реализации данной защиты были предприняты следующие действия:

1. Настроено перенаправление HTTP запросов на HTTPS. Перенаправление осуществляется с помощью функционального слоя Django.

41. Использованы "безопасные" cookie. Если браузер изначально подключается через HTTP, что характерно для большинства браузеров, то существует возможность утечки пользовательских cookie. По этой причине в настройках проекта использованы параметры SESSION_COOKIE_SECURE и CSRF_COOKIE_SECURE. Таким оразом, браузер будет отправлять данные cookie только через HTTPS соединения.