2009-04-15 4 views
2

Если пользователь нажимает кнопку, которая делает сообщение (скажем, имеет имя пользователя и пароль в сообщении), и эти учетные данные успешно проходят проверку подлинности. Если я сделал перенаправление на совершенно другое приложение (поэтому я не могу переносить сеанс и т. Д.), И я использую GET с именем пользователя и паролем в querystring (я мог бы даже использовать базовое шифрование, если это помогает, но независимо), а затем, когда он попадает на страницу, я проверяю, чтобы убедиться, что она появилась на странице, которую я ожидал от нее, вытащить значения из строки запроса, поместить их в переменную сеанса и затем перенаправить обратно на ту же страницу (удаление строки запроса так что они не могут быть просмотрены пользователем). Все это происходит через SSL на том же сервере.URL-адрес вопроса о безопасности Querystring (ASP.NET)

Может ли кто-нибудь указать на дыры в безопасности кого-то, перехватывающего имя пользователя и пароль в этом сценарии?

ответ

4

Если вы используете SSL, никто не может перехватить запрос. Проблема на самом деле с самим клиентом. Не стоит добавлять логин и пароли в запрос GET (даже в зашифрованном виде), потому что:

  1. URL-адрес может быть легко скопирован и вставлен кому-то еще.
  2. Если пользователь нажимает внешнюю ссылку, URL-адрес будет отправлен как реферер.
  3. Атаки XSS могут быть использованы для захвата URL-адреса.
+0

Спасибо за ответ. Я знаю, что это вообще не рекомендуется, но я хотел знать, где * дыра в безопасности. Клиент никогда не должен действительно видеть запрос, потому что перенаправления происходят на сервере, и я очищаю URL-адрес до того, как он попадет на клиент, верно? – EdenMachine

+0

Браузер увидит URL-адрес и может даже кэшировать его. По крайней мере, я предлагаю вам установить cookie (с доменом = другой веб-сайт) вместо передачи значений в querystring. –

+0

«потому что перенаправления происходят на сервере», это неверно. Сервер в основном отправляет HTTP-ответ, который сообщает клиенту перейти на другую страницу. –

3

Mehrdad уже дает некоторые проблемы, здесь некоторые другие:

  • При использовании в запросе получить имя пользователя и пароль будут явно видны в пользовательском браузере истории/кэше.
  • Комбинация имени пользователя и пароля, вероятно, будет отображаться в ваших журналах сервера.

Также: подумайте о том, чтобы использовать «соленые» хеши для паролей, а не просто хранить его в виде открытого текста (если это уже не так). Добавлено: Как правильно Mehrdad комментарии: ... даже в случае подсоленной хэша, она по-прежнему уязвимы от атак ...

Edit:

@EdenMachine: Я думаю, вы должны Google для " Cross Site Authentication "и тому подобное - это будет« несколько »сложнее реализовать, но будет (если сделано правильно) сделать более безопасным (а также без проблем). Пример ссылки: http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer.all

+0

И даже в случае соленого хэша он по-прежнему уязвим для повторных атак. –

+0

Действительно, хороший момент! – ChristopheD

+0

Я добавлю это к своему ответу ... – ChristopheD