Скрытие строки запроса в веб-приложении ASP.NET - PullRequest
1 голос
/ 19 сентября 2008

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

Поэтому я должен передать свой идентификатор пользователя (GUID) во второе приложение. В настоящее время это делается через URL, но я хотел бы скрыть этот идентификатор.

Кто-нибудь знает, как это сделать правильно?

[РЕДАКТИРОВАТЬ]: я не могу использовать сеанс из-за границ приложения (2 разных сервера)

Ответы [ 8 ]

2 голосов
/ 19 сентября 2008

Если вы не можете использовать куки, потому что это междоменный домен, то зашифруйте его с помощью одноразового номера.

Настройка общего секрета / ключа между двумя серверами; отправьте зашифрованную комбинацию GUID и одноразового номера на второй сервер. Дешифруйте, проверьте, что одноразовый номер еще не использовался (чтобы остановить ответные атаки), затем используйте незашифрованный GUID.

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

Даже с файлами cookie, так как они легко редактируются / подделываются, у вас должна быть некоторая форма проверки.

2 голосов
/ 28 сентября 2008

У вас есть два веб-приложения ASP.NET, и одно приложение выполняет только аутентификацию пользователя?

это звучит как работа для ....

Веб-сервисы!

Создайте новый веб-сервис в приложении аутентификации (это расширение .asmx), добавьте единственный метод, который принимает имя пользователя и пароль и т. Д., И возвращает информацию аутентификации.

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

Пример:

AuthenticateUserService.asmx запускается приложением аутентификации:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class AuthenticateUserService : System.Web.Services.WebService 
{   
    [WebMethod]
    public bool AuthenticateUser(string username, string passhash) 
    {
        // Fake authentication for the example
        return (username == "jon" && passhash == "SomeHashedValueOfFoobar");
    }

}

После настройки запустите главное приложение, щелкните правой кнопкой мыши проект и нажмите «Добавить веб-ссылку».

Введите URL-адрес asmx в приложении аутентификации, и Visual Studio обнаружит его и создаст прокси-класс.

Как только это будет сделано, мы можем вызвать этот метод, как если бы он был локальным методом в нашем основном приложении:

protected void Page_Load(object sender, EventArgs e)
{
    // Now we can easily authenticate user in our code
    AuthenticateUserService authenticationProxy = 
         new AuthenticateUserService();
    bool isUserAuthenticated = 
         authenticationProxy.AuthenticateUser("jon", SomeHashMethod("foobar"));
}

Итак, что это действительно делает?

Исключает клиента из процесса аутентификации.

Ваш текущий процесс:

  • Клиент вводит учетные данные для AppA
  • AppA перенаправляет клиента в AppB
  • AppB перенаправляет клиента обратно в AppA, если учетные данные совпадают.

Заменяется на SOAP-вызов на стороне сервера между AppA и AppB. Теперь это так:

  • Клиент вводит учетные данные в AppA
  • AppA спрашивает AppB, хороши ли они
  • AppA предоставляет клиенту правильный контент.
2 голосов
/ 19 сентября 2008

Звучит как хитрая ситуация. Однако есть несколько вариантов, которые вы можете использовать, но все зависит от того, что делает ваше приложение.

Давайте назовем WebApp1 вашим сайтом аутентификации, а WebApp2 - вашим удаленным сайтом после аутентификации.

Может ли WebApp2 не вызывать WebApp1 за кулисами? (Услуги)

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

Если вы не можете использовать WebApp2 для запроса WebApp1, вам следует рассмотреть возможность создания временного Guid WebApp1 с истекающим сроком действия. Это было бы намного безопаснее в долгосрочной перспективе, но, поскольку это чистый текст, все еще подвержен атаке. Для двух веб-приложений также потребуется доступ к одному и тому же хранилищу данных.

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

0 голосов
/ 24 ноября 2010

перейти к управлению сеансом или использовать HTTP-сообщение, как сказано в предыдущем сообщении.

0 голосов
/ 19 сентября 2008

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

0 голосов
/ 19 сентября 2008

Если серверы имеют общее доменное имя, вы можете использовать cookie.

РЕДАКТИРОВАТЬ: Cookies просто скрывают идентификатор визуально, он все еще доступен. То же самое со скрытыми полями или использованием POST, а не GET. Поэтому, если идентификатор является достоверным, и вы хотите избежать его передачи по сети в незашифрованном виде, вам нужен другой подход.

Решением может быть шифрование идентификатора на сервере авторизации ключом, который используется серверами совместно. Другое решение может состоять в том, чтобы генерировать случайный GUID на сервере аутентификации, а затем позволить серверу аутентификации напрямую сообщать другому серверу (через SSL), какому идентификатору соответствует GUID.

0 голосов
/ 19 сентября 2008

Используйте переменные сеанса или HTTP POST вместо HTTP GET.

0 голосов
/ 19 сентября 2008

Передайте GUID через сеанс , наилучшим образом.

http://www.w3schools.com/ASP/asp_sessions.asp

ИЛИ, поскольку это 2 разных сервера, передайте информацию методом POST:

http://www.w3schools.com/aspnet/aspnet_forms.asp

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

Имея это в виду, вы также можете выполнить всю аутентификацию удаленно. Удаленно подключитесь к локальной базе данных с удаленного сервера и проверьте учетные данные для входа оттуда ... таким образом вы сможете сохранить сеанс и / или cookie на удаленном сервере.

Я бы рекомендовал ПРОТИВ скрытого предложения поля , поскольку оно полностью противодействует тому, что вы пытаетесь сделать! Вы пытаетесь скрыть GUID в URL, но публикуете ту же информацию в своем HTML-коде! Это не способ сделать это.

Наилучшим выбором является опция базы данных, или, если это невозможно, используйте HTTP POST.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...