Проблема с безопасным входом в систему. Почему меня перенаправляют на небезопасный вход в систему?

У меня возникли некоторые проблемы с получением веб-сайта на моем рабочем месте. Проблема возникла, когда произошел "двойной вход" с сайта безопасного входа. Второй логин фактически запрашивался доменом HTTP, а не HTTPS.

По сути, ситуация такова:

  • Пользователь переходит на https://mysite.com/something
  • Появится приглашение для входа
  • Введите имя пользователя и пароль
  • Пользователю предоставляется ДРУГОЕ приглашение для входа в систему (IE скажет, что оно небезопасно, и адресная строка отражает это)
    • Если пользователь вводит свой пароль небезопасный, он будет входить на небезопасный сайт.
    • если они нажмут "отменить", они получат 401 страницу
  • Если вы вернетесь обратно на https://somesite.com/something вы пропустите приглашение и автоматически войдете на защищенный сайт (возможно, cookie)

Я немного озадачен тем, почему пользователь не вошел в систему должным образом в первый раз (перенаправлен на не-ssl), но любой последовательный вход будет в порядке? Я пытался использовать fiddler, чтобы увидеть, что происходит после того, как пользователь вводит свой пароль в первый раз, и пытаюсь заставить fiddler автоматически войти на сайт (без удачи)

Я полагаю, что рассматриваемый веб-сайт использует Basic Digest аутентификацию.

Спасибо за любую помощь

Источник

2 ответа

Похоже, сервер передает заголовок Location на другую страницу во время (или сразу после) аутентификации.

В зависимости от того, как сконфигурированы / настроены сервер (ы) (для портов 80 и 443), эта страница также может быть просто закодирована для перехода на страницу http:// (порт 80), на которой вы еще не были бы аутентифицируется (опять же, в зависимости от структуры).

Можете ли вы проверить HTTP-заголовок и сообщить, есть ли заголовок Location или если код проверки подлинности установлен на "перенаправление на страницу в случае успеха".

Источник

Обычная и дайджест-аутентификация заставляют браузер добавлять заголовок с именем Authorization, Сервер может свободно читать или игнорировать его. Скорее всего, он проигнорирует его, если будет установлен файл cookie аутентификации. Этот файл cookie является файлом cookie сеанса. Он будет называться ASPSESSIONID, JSESSIONID, PHPSESSIONID или что-то подобное.

Вот что происходит:

  1. Первый вход в систему завершается с ошибкой через HTTPS. Трудно сказать, почему, я использую экстрасенсорную отладку.
  2. Вы будете перенаправлены на страницу http. Сервер настроен на запрос базовой / дайджест-аутентификации, что делает.
  3. Вы вводите свои учетные данные, которые принимаются на этот раз. Сервер дает вам сессионный cookie
  4. Возвращаясь к HTTPS, сервер игнорирует Authorization заголовок (который, скорее всего, потерпит неудачу), поскольку существует файл cookie сеанса.

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

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

Источник
Другие вопросы по тегам