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

Question

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

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

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

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

спасибо!

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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