Лучший способ разработать защищенное приложение. С .net

Question

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

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

Каков наилучший способ разработки защищенного приложения, если по какой-либо причине форма входа в систему будет пропущена, другие вызовы функций не будут выполняться?

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

спасибо!

Answer 1

(неправильно прочитал ваш пост и изначально думал, что вы говорите о веб-формах, поэтому вычеркните оригинальный ответ)

Если все работает через ваше приложение, вы контролируете, проходят ли они через форму входа или нет, если только вы не запускаете отдельный .exe. Если это не требует особых мер безопасности, вы должны быть в безопасности, зная, что пользователь вошел в систему.

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

Answer 2

Если это приложение, которое запускается на ПК пользователя, то на самом деле нет способа его обезопасить. Его можно разобрать, разобрать и собрать по желанию пользователя.

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

Однако существуют способы аутентификации и защиты внешних ресурсов, таких как база данных или веб-служба.

Answer 3

если вы используете ASP.NET, зачем хранить билет в куки? Просто поместите это в переменную сеанса, позвольте ASP обрабатывать куки. Таким образом, никакая жизненно важная информация не сохраняется в куки, только в памяти сервера.

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

Кто-то может найти дыру в петле на первом уровне, поэтому второй уровень должен ВСЕГДА проверять все запросы, прежде чем перенаправлять запрос на третий уровень. Третий уровень - это только ваши данные, и он должен иметь логические ограничения, чтобы гарантировать, что данные остаются чистыми, но не в плане безопасности.

Единственный способ убедиться, что ваш 2-й и 3-й уровни "безопасны", - это разместить их на разных серверах. Каждый раз, когда вы не доверяете клиенту или безопасность является приоритетной, 2-й и 3-й уровни НЕ должны быть в клиентском приложении.

Как правило, 1-й уровень можно взломать, поэтому вы также проверяете 2-й уровень. Если 2-й и 3-й уровни находятся на стороне клиента, они также могут быть взломаны.

Answer 4

Все ваши разрешения должны быть повторно проверены на 2-м и, возможно, 3-м уровне. Ваше приложение только 1-го уровня.

Если вы объединяете все 3 уровня в само приложение, то вам DO нужен способ отслеживать разрешения.

Answer 5

Я согласен с Шоном. Но если вы хотите сделать это вручную (при условии, что вы используете asp.net), тогда я использовал это: 1) когда пользователь проходит проверку подлинности, я выдаю билет проверки подлинности, в котором имя пользователя, отметка времени и его привилегии зашифрованы и сохранены. Я храню этот билет в печенье. 2) На каждой странице я включаю функцию аутентификации в обработчик событий page_preload. Эта функция читает билет из куки, расшифровывает его и проверяет имя пользователя, метку времени и привилегии. Таким образом, я могу убедиться, что 1) пользователь прошел через страницу входа в систему, 2) у него не истекло время ожидания 3) он использует страницу с необходимыми привилегиями. Если какая-либо информация окажется недействительной, то он будет перенаправлен на страницу входа.

Таким образом, вам потребуется доступ к базе данных только один раз для аутентификации, т.е. на странице входа. Для последующих запросов вам просто нужно расшифровать билет аутентификации и проверить, содержит ли он действительные данные.

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

Надеюсь, это поможет, vamyip