Аутентификация и защита фасада
От: Stalker. Австралия  
Дата: 08.10.17 05:33
Оценка:
Имеется система (ASP.NET MVC), состоящая из вебформы, которая из своих контроллеров стучится в фасад WebAPI для обработки бизнес логики (т.е. WebAPI находится внутри сети). Требуется обеспечить защиту. Достаточно-ли такого подхода:

1) Сертификат, т.е. WebAPI позволяет подключится контроллеру вебформы только если тот имеет сертификат (дополнительно можно проставить ip адрес)
2) Контроллеры вместе с запросом посылают фасаду токены с клеймами, которые содержат id подключившегося пользователя и его роль. Теперь в фильтре метода WebAPI я смогу проконтролировать что пользователь принадлежит к нужной роли, а далее информация которую будем брать из базы будет отфильтровываться по его id. Например если пользователь с ролью "Владелец Кредитной Карты" хочет получить список транзакций по своей карте, то во-первых будет проконтролировано что он принадлежит этой роли, а транзакции отфильтруются по его id.

Достаточно-ли этого, или требуется что-то еще согласно OWASP top 10?
Re: Аутентификация и защита фасада
От: Qulac Россия  
Дата: 08.10.17 10:45
Оценка:
Здравствуйте, Stalker., Вы писали:

S>Имеется система (ASP.NET MVC), состоящая из вебформы, которая из своих контроллеров стучится в фасад WebAPI для обработки бизнес логики (т.е. WebAPI находится внутри сети). Требуется обеспечить защиту. Достаточно-ли такого подхода:



S>1) Сертификат, т.е. WebAPI позволяет подключится контроллеру вебформы только если тот имеет сертификат (дополнительно можно проставить ip адрес)


Сертификат достаточно передать один раз при новом подключении, а дальше передается только токен аутентификации.

S>2) Контроллеры вместе с запросом посылают фасаду токены с клеймами, которые содержат id подключившегося пользователя и его роль. Теперь в фильтре метода WebAPI я смогу проконтролировать что пользователь принадлежит к нужной роли, а далее информация которую будем брать из базы будет отфильтровываться по его id. Например если пользователь с ролью "Владелец Кредитной Карты" хочет получить список транзакций по своей карте, то во-первых будет проконтролировано что он принадлежит этой роли, а транзакции отфильтруются по его id.


Предоставлять доступ только на основании входных данных — смертный грех программиста. Если вы передаете на сервис id пользователя(что уже плохо), то вы должны обязательно проверить, прошел ли этот пользователь процедуру аутентификации так как id может быть перехвачен, угадан(что не сложно они как правило идут по порядку и можно найти id который принадлежит какому ни будь пользователю) Поэтому в общем случае данные пользователя не должны использоваться для его распознавания, нужно использовать токен сгенерированный системой.
Программа – это мысли спрессованные в код
Re[2]: Аутентификация и защита фасада
От: Stalker. Австралия  
Дата: 08.10.17 21:53
Оценка:
Здравствуйте, Qulac, Вы писали:

Q>Сертификат достаточно передать один раз при новом подключении, а дальше передается только токен аутентификации.


сертификат который требует IIS вроде каждый раз передается про каждом вызове?

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


имелся ввиду следующий процесс — юзер авторизуется в системе, его данные (ID, роль итп) хранятся в сессии на основе куки между браузером и контроллером, а когда контроллер делает вызов бизнес логики WebAPI — то он генерирует токен на основании того, что есть в кукисах.
ID пользователя вообще скорее всего его email будет, хотя можно и внутренний id использовать. Вообще я правильно понимаю, что при использовании https такая информация может спокойно передаваться по сети? Или-же ее все равно желательно еще дополнительно шифровать? Вообще если токен украден, то теоретически наверно неважно зашифрован он или нет.
Re[3]: Аутентификация и защита фасада
От: Qulac Россия  
Дата: 08.10.17 22:25
Оценка:
Здравствуйте, Stalker., Вы писали:

S>Здравствуйте, Qulac, Вы писали:


Q>>Сертификат достаточно передать один раз при новом подключении, а дальше передается только токен аутентификации.


S>сертификат который требует IIS вроде каждый раз передается про каждом вызове?


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


S>имелся ввиду следующий процесс — юзер авторизуется в системе, его данные (ID, роль итп) хранятся в сессии на основе куки между браузером и контроллером, а когда контроллер делает вызов бизнес логики WebAPI — то он генерирует токен на основании того, что есть в кукисах.

S>ID пользователя вообще скорее всего его email будет, хотя можно и внутренний id использовать. Вообще я правильно понимаю, что при использовании https такая информация может спокойно передаваться по сети? Или-же ее все равно желательно еще дополнительно шифровать? Вообще если токен украден, то теоретически наверно неважно зашифрован он или нет.

При https можно многое что передавать, только я не понимаю зачем. Упрощать это не сильно всё упрощает, а использование отдельного токена архитектурно позволяет полностью отвязать логику управления доступом от всего остального и при необходимости использовать часть отлаженного кода повторно.
Программа – это мысли спрессованные в код
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.