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

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

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

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

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

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

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

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

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

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

13.10.2009 11:42:12
Не знаю, сработает ли это, но как насчет разделения элемента управления входом и представления его в iframe на странице? Это позволит вам иметь вторую форму без раздражающего ASP.NET?
Lazarus 13.10.2009 11:46:26
Проверьте «Управление несколькими формами» на msdn.microsoft.com/en-us/magazine/cc163736.aspx
Viktor Jevdokimov 13.10.2009 11:51:59
Спасибо Виктор, я это проверю. Но проблема в том, что мы используем мастер-страницы. Если бы я выбрал решение для нескольких форм, мне бы пришлось сменить место отверстия, а это просто невозможно. Я рассматриваю iframe, попробую тот. Я думаю, что дизайнеры на этот раз должны будут согнуть разработчиков.
Gargamel 13.10.2009 12:50:53
4 ОТВЕТА

Разве вы не можете просто переместить свой контроль, с его собственной формой, за пределы <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>
3
13.10.2009 11:46:00
Создайте простой HTML-код в первой форме и управляйте им как старым ASP (без серверных элементов управления).
Viktor Jevdokimov 13.10.2009 11:54:16
@Victor: Почти хорошо? Хорошо иметь собственные пользовательские элементы управления в простой HTML-форме, как в моем примере, если эти пользовательские элементы управления не требуют какой-либо функциональности веб-форм.
LukeH 13.10.2009 11:58:30
@Luke: Я дал +1, но проблема с такими формами в том, что вам нужно получить доступ к значению элемента управления, используя Request.Form ["ключевое слово"], где "ключевое слово" - это имя поля ввода формы. Пойди разберись, что это будет, когда генерируется динамически.
Viktor Jevdokimov 13.10.2009 12:13:29
@Victor: Вам не нужно выяснять какие-либо автоматически сгенерированные имена, вы просто должны иметь простые элементы HTML-формы внутри своего пользовательского элемента управления. Так что у вас есть и <input type="text" name="username" />т. Д. securelogincontrol, А затем забрать его с Request.Form["username"]т securepage.aspx. Д. В.
LukeH 13.10.2009 12:28:30
То, что я хочу, чтобы иметь возможность войти в систему пользователя, не покидая страницу. Это для удобства использования. Я мог бы перенаправить на securepage.aspx и сразу же перенаправить обратно, но это не так хорошо, как иметь один или нет обратной передачи. Подход с двумя формами не работает, потому что контроль входа должен находиться внутри основной формы. Другой альтернативой может быть использование iFrames, но я не знаю об этом.
Gargamel 13.10.2009 12:38:04

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

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

1
13.10.2009 11:48:59
Да, это тот недостаток, что те, у кого нет JS, не получат подключения к серверу
Gargamel 13.10.2009 12:32:01

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

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

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

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

2
13.10.2009 11:59:46
Интересно, есть ли у вас опыт работы с ASP.NET AJAX auth. Сервисы? или вы знаете, поддерживает ли он HTTPS и как он обрабатывает сценарий отката, когда у пользователя не включен JS? Я не мог найти никакой информации об этом.
Gargamel 13.10.2009 13:02:45

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

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

  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 в разных доменах), мы делаем двойные обратные вызовы на страницу с некоторыми добавленными параметрами в строке запроса.

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

0
25.02.2010 11:36:57