Безопасный пользовательский контроль входа в ASP.NET

Question

Проблема: Я хочу создать пользовательский элемент управления для входа в систему, который будет безопасно публиковать HTTPS, не затрагивая другие кнопки отправки на странице.

Если бы я писал это в ASP.NET MVC или любом другом языке по этому вопросу, я бы просто создал новый тег формы с формой action = "https: // ...". Теперь я застрял на сайте веб-форм ASP.NET. Это означает, что у меня может быть только один тег формы на всей странице, что лишает меня этого простого решения.

Что я пробовал?

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

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

3. Композитный подход. Я мог бы использовать AJAX для загрузки страницы, содержащей элемент управления, который использует JavaScript для изменения сообщения. Таким образом, элемент управления даже не будет отображаться, если у пользователя нет JavaScript, а вместо этого отображается кнопка, которая отправляет пользователя на страницу входа.

Последний вариант - лучший выбор в моей ситуации, но он усложняется, не вдаваясь в детали.

Итак, мой вопрос: есть ли другой способ обеспечить безопасный контроль входа в систему в ASP.NET без использования JavaScript?

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

Answer 1

Разве вы не можете просто переместить свой элемент управления с его собственной формой за пределы раздела <form runat="server">?

<form method="post" action="https://www.example.com/securepage.aspx">
    <ui:securelogincontrol id="SecureLogin" runat="server" />
</form>

<form runat="server">
    <!-- all the stuff that requires a webform -->
</form>

Answer 2

Обычный подход состоит в том, чтобы иметь выделенную страницу входа в систему только с элементом управления <asp:Login>, содержащимся на ней, для отправки формы. У вас есть другие настройки?

Если у вас есть выделенная страница входа в систему, вы можете настроить страницу для запроса SSL в web.config

<authentication mode="Forms">
    <forms loginUrl="~/login.aspx" slidingExpiration="false" timeout="500" requireSSL="true"/>
</authentication>

Вы также можете выполнить аутентификацию на стороне клиента, используя службы аутентификации ASP.NET AJAX

Answer 3

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

Второй подход, который вы описали, является наиболее простым - если вы готовы разрешить пользователям без JavaScript вход в систему через HTTP. У вас может быть ссылка под вашим логином с надписью «Безопасный вход в систему», которая скрыта JavaScript, чтобы дать им возможность.

Answer 4

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

Требования, которые у нас были, где они:

1. Логин должен быть защищен, SSL
2. Он должен поддерживать не Javascript Senarios
3. Контроль входа должен быть в состоянии разместить в любом месте потока сайтов.
4. Только страницы, для которых требовался Https, должны использовать https (таким образом, перемещаясь назад и вперед между протоколами)

То есть с тем фактом, что у нас уже был веб-сайт, основанный на модели веб-форм с одним тегом формы, и тем фактом, что владельцы содержимого используют тег формы с runat = "server", а наш сайт полностью построен с использованием MasterPage и ContentPlaceholder единственное, что поддержало это, было использование решения I-Frame.

Это создает некоторые другие проблемы, связанные с перезагрузкой страницы, javascript (поскольку в любом случае почти все используют javascript), http в https и https в http сообщения.

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

Чтобы решить проблему Javascript, вызывая различные протоколы и обращаясь к ним (это воспринимается как эксплойт XSS для вызова javascript в разных доменах), мы делаем двойные обратные вызовы на страницу с некоторыми добавленными параметры в строке запроса.

Надеюсь, эти советы тоже могут вам помочь.