Step 6 (S-44893)

From Stepik Wiki
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14833/step/6

Step 6 (S-44893) 1.png

[00:00 - 00:18] рассмотрели как сделать так скажем на коленке а самостоятельную систему авторизации на основе гук мы ее обязательно следует упомянуть что на самом деле


[00:18 - 00:36] джанго уже есть встроенная система авторизации а и встроенная система сессии мы рассматривали как я сделать что бы понять как это устроено внутри а встроенная система авторизации они работают более сложным образом там больше нюансов


[00:36 - 00:55] и вот что следует пронизать во 1 а система авторизации система управления сессиями выполнена в виде отдельных приложений то есть это джанго приложение которое вы можете подключить к вашему проекту или не подключать


Step 6 (S-44893) 2.png

[00:55 - 01:10] а в зависимости от того хотите достаточно вам их функционал или недостаточно для управления сессиями в django используются вот такое приложение


[01:10 - 01:28] в чем его особенности а здесь все сделано не зависимыми от пользователя то есть а мы рассматривали что сессия всегда связан с пользователем а на самом деле это не обязательно то есть ключ сессии может генерироваться для любого пользователя в том числе


[01:28 - 01:44] для неавторизованного достаточно чтобы он был в длинном и уникально а если сессия не связано с пользователем и называется то есть чем не связано с авторизованным почте


[01:44 - 01:59] а контриб слышен в поддерживаться на зимней сессии то есть фактически для каждого пользователя авторизованным он или нет создается сессия и в объект цессии а можно складывать произвольные да то есть у нас цессии хранился только идентификатор


[01:59 - 02:16] пользователя а то есть их можно хранить произвольные данные например там список покупок то есть в корзину в магазине там наиболее в интернет магазине наиболее распространенный пример использования смеси


[02:16 - 02:34] а также это приложение позволяет хранить сессии не в базе данных о каком нибудь более быстром хранилище например в redis либо кэшем а дело в том что с проверка соси происходит на каждый запрос и


[02:34 - 02:52] очень желательно чтоб доступ к сессии по ключу был быстро поэтому сейчас хранят подземных хранилищ а как и как используется с данное приложение ну во 1 вы должны включить в список инсталл ups


[02:52 - 03:11] ваших настройках после того как вы подключили проложение сесси у вас появляется свойства request точка section но мы его называли также отличие в том что оно существует всегда нас request session иногда был пустым то есть нам


[03:11 - 03:29] стандартные с этим джанге существуют всегда а ведет себя как словарь то есть вы можете из сессий прочитать какое то значение можете


[03:29 - 03:46] записать какое то значение и это значение оно сохранится между запросами том что на самом деле оно будет храниться в хранилище в базе данных вы бы уволились у пользователя будет только ключ сессия и вы можете очистить


[03:46 - 04:02] вы можете вызвать метод это очистит содержимое сессии но это было аналогично нашему то есть в принципе включает содержимое 6 а


[04:02 - 04:17] сессии поскольку они сделаны с анонимными их можно использовать без а без использования авторизации то есть это просто стандартный с этим django то некоторые словарь который привязывается


[04:17 - 04:36] к пользователю и существует сохраняется между запросами а поверх система сессия в django организована система пользователей джанго contract пауз она предоставляет готовую модель юзер


Step 6 (S-44893) 3.png

[04:36 - 04:52] то есть а есть модель пользователя у которого есть наиболее используемые поля то есть имя и email и тому подобное и представляет а вместе с моделью пользователя системы разделения прав то есть есть встроенная а модель дервишем


[04:52 - 05:07] который позволяет раздавать права пользователя на доступ к разным объектам это может пригодится а что важнее есть стандартные view для входа выхода а из


[05:07 - 05:23] для регистрации написания обработчиков регистрации и входа выхода довольно трудоемко и чревато проблемами с безопасностью


[05:23 - 05:40] а вот country пауз есть встроенные обработчики уже все решили а content uploads в систему пользователей она использует с другими приложениями например django admin


[05:40 - 05:55] то есть если вы для своего проекта хотите использовать готовую админку вам потребуется включить систему авторизации django а каким образом используется


[05:55 - 06:13] авторизация по стольку ее включили это приложение он стал tops у вас у объекта request во вьюшках появляется свойства юзер это текущий пользователь в отличие от нашей реализации в стандартном


[06:13 - 06:29] стандартной системе пользователей request user определен всегда а если пользователь авторизован то есть если авторизованный пользователь из аутентификации этот возвращает true


[06:29 - 06:48] а для всех остальных вернет false в этом случае у нас объект пользователь соответствует анонимному пользователю то есть записи в базе нету но объект пользователя а есть это позволяет писать меньше if но все таки вы должны понимать что наличие просто переменной request юзер


[06:48 - 07:07] во вьюшках не означает что вы работаете с каким то конкретным авторизованным пользователям системы в системе жаль что еще можно сказать про сессии из строя на авторизацию и в замке а важное отличие в том что


[07:07 - 07:22] эти системы эти приложения сделано ленивыми то есть а вот с вами lazy а что это значит то есть мы делали так что он срабатывает на каждую


[07:22 - 07:38] естественно это слишком мало слишком накладно то есть на самом деле не на каждую ее нужно проверять авторизацию пользователя а поэтому вот эти переменные которые


[07:38 - 07:56] предоставляется request юзер и request session они сделаны ленивыми а объект существует но непосредственно проверка произойдет только при 1 доступе к этому объекту то есть когда вы попробуете


[07:56 - 08:13] прочитать его свойства обратиться к этому объекту а django а произведен посредством проверку сессия и вернет вам уже конкретного пользователя либо авторизовывал либо не авторизован если вы в коде вашей вьюшки не обращаясь к рекламе


[08:13 - 08:29] авторизация проверяться и не будет а это что касается встроенной встроенных систем авторизации 6 а


[08:29 - 08:48] в общем то а в завершении темы авторизации нужно обсудить аспекты безопасности простейший аспекта а когда мы говорим про безопасность а по сути дела есть распространенное атаке от окна пароли и на сессии


Step 6 (S-44893) 4.png

[08:48 - 09:03] а что может сказать про безопасность пароли в этом случае злоумышленники пытаются похитить а сам пароль пользователя 1 либо всех сразу а


Step 6 (S-44893) 5.png

[09:03 - 09:20] в какой момент это может происходить например в момент когда пользователь вводит отправляет пароль а форму логина как мы говорили форма методом post значит он продается в открытом виде чтобы злоумышленник не смог его


[09:20 - 09:38] прихватить с помощью прослушивания сниффинга сети все формы в которых есть пароль должны отправляться ps вообще без это крайне рекомендуемый стандарт для современных сайтов а


[09:38 - 09:55] 2 момент злоумышленник может попытаться написать робота который перебирает логина и пароля потому что на самом деле у пользователя пароль и не такие разнообразные не довольно просты и у многих пользователей совпадают поэтому злоумышленник может перебирать


[09:55 - 10:14] логина и пароля в вашей форме форма входа то есть фактически р по словарю перебирать для этого в форме входа часто добавляют каптчу если не при 1 запросе то стоит какой то детектор брутфорса перебора


[10:14 - 10:31] и если мы видим то множества повторяющихся запросов на вход мы добавляем каптчу и без каптчи вообще не проверяют форма входа логин и 3 момент это хранения паролей в базе


[10:31 - 10:47] а периодически происходят утечки базы данных связанных с ним то там атаками на сетевую инфраструктуру проникновения в сеть там а компании и тому подобное ну тем или иным образом хакеры получают


[10:47 - 11:05] база данных пользователей а здесь очень важно чтобы пароли не хранились в открытом виде если пароли хранятся в открытом виде фактически вы потеряете пароль все пользователи сразу поэтому на практике пароли хранятся в зашифрованном виде но


[11:05 - 11:20] хранить закэшированы виде а это не достаточно потому что есть так называемый радужные таблицы но фактически это набор


[11:20 - 11:39] переведенный в хэш таблице которая позволяет расшифровать примитивных и широкие а поэтому во 1 к пароль добавляя соль чтобы перестал быть словарным словом соль соль это какой то произвольное строчка которой фиксируется для проекта


[11:39 - 11:58] а а а например в джанге делают еще более хитрым образом для каждого пользователя соль уникальна то есть каждый пользователь собственной солью и пароли хэшируется не 1 раз а несколько раз подряд что делает невозможным


[11:58 - 12:15] обратное преобразование сша а то есть главное не хранит не хранит пароли в открытом виде можно хранить многократно зафиксированными с добавлением соли что собственно реализован в стандартном приложении


[12:15 - 12:33] так это что касается паролей ну соответственно утраты пароля означает что злоумышленник сможет войти от лица пользователя осуществить какие то действия в приложении тем не менее можно сделать и без а кража пароля ему достаточно


Step 6 (S-44893) 6.png

[12:33 - 12:49] а здесь вариантов намного больше дело в том что все на куклу можно получить с помощью javascript если вам удастся разместить на странице


[12:49 - 13:08] сайты которые пользуются некоторые пользователи свой джаваскрипта вы получите доступ а у через все это означает что у злоумышленника будет права будет авторизации пользователя по крайней мере на время жизни этой смеси


[13:08 - 13:25] какие меры безопасности можно предпринять ну во 1 ключ сессии нужно делать как мы говорили в уникальном и генерировать его с хорошим генератором случайных чисел чтобы его невозможно было


[13:25 - 13:40] подобрать чтобы невозможно было подобрать будут брутфорсом во 2 рекомендуется ставить чтобы а эти куки не видны были из java скрипта


[13:40 - 13:55] помимо этого cookie могут быть привязаны к ip адреса если злоумышленник украл он не сможет и пользу с поскольку находится в другом опят


[13:55 - 14:13] куки хранятся ограниченное по времени то есть если ограничение по времени жизни чтобы нельзя было пользоваться бесконечно то есть даже своя кухня была утеряна она перестанет быть актив это слабая защита и важный пункт


[14:13 - 14:30] при критических действиях требуют именно пароль то есть например если злоумышленник получил кукол и а с этой куклой он не сможет сменить пароль то есть обычно заходит на страницу смены или бы восстановления пароля и меняет пароль


[14:30 - 14:48] после этого злоумышленник получает постоянный доступ на все критических действиях а требуется запрос пароля особо важно связанных с деньгами сейчас принято делать в фотору на авторизацию то есть нужно будет вводить во 1 пароль а во 2


[14:48 - 15:06] 2 способ подтверждения по смс приходит код то есть вот какой на безопасности основано на авторизацию чисто по селам и куки можно рассчитывать только а в некритичных


[15:06 - 15:22] а не критично действиях на сайте в критичных действия то критичных обработчиках нужно использовать авторизацию по паролю либо вот например двухфакторную авторизацию а общем то


[15:22 - 15:38] на этом тема авторизации может быть закрыта в 1 приближении рассмотрели и теперь мы можем перейти к рассмотрению дополнительных тем а вот по разработке