HTTP 'Get' Security - PullRequest
       8

HTTP 'Get' Security

4 голосов
/ 18 мая 2009

Каковы некоторые рекомендации по безопасности HTTP 'Get'?

Когда следует скрывать значения HTTP Getstring?

Редактировать - Приложение, которое я унаследовал, имеет все параметры строки запроса XOR «зашифрованы». Это также передает вещи как AccountID в строке запроса. Поэтому мне интересно, если это хорошие практики и как бы я исправить эти вещи, если это не так.

Редактировать -

Одним из методов, который я мог бы использовать для решения этой проблемы, было бы создание базового класса (это просто псевдокод):


public mustinherit class QSBase

  public shared Unique as long = 0
  private m_ID as string

  public readonly property ID
    get
      return m_ID
    end get
  end property

  public sub new()
   m_ID = Unique 'somehow get a unique value for this querystring
   Unique += 1
  end sub

  public function IDQueryString() as string
    return "ID=" & m_ID
  end function

end class

Затем для каждой страницы в приложении я бы создал производный класс со свойствами для каждого значения строки запроса.


public class QSPage1
  inherits QSBase

  private m_AccountID as string

  public readonly property AccountID as string
    get
      return m_AccountID
    end get
  end property

  public sub new(byval _AccountID as string)
    m_AccountID = _AccountID
  end sub

end class

Затем, когда я передаю строку запроса всплывающим окнам или другим страницам, я создаю экземпляр соответствующего класса, сохраняю его в сеансе и передаю уникальный идентификатор в строке запроса


Dim qs as new QSPage1("123456")
Session(qs.ID) = qs
Server.Transfer("Page1.aspx?" & qs.IDQueryString())
'or
CreatePopup("Page1.aspx?" & qs.IDQueryString())

На странице я получаю доступ к значениям, извлекая уникальный идентификатор и ссылаясь на сохраненное значение сеанса:


AccountID = CType(Session(Request.QueryString("ID")), QSPage1).AccountID()

Конечно, это можно поместить в функцию или класс на странице.

Некоторые преимущества этого подхода:

  • Ни одна из строк запроса не видна, кроме несвязанного идентификатора.
  • Это довольно легко реализовать в уже существующем коде.

Некоторые недостатки:

  • Длинный сеанс может накапливать многие из этих объектов строки запроса
  • Уникальный идентификатор должен быть "действительно уникальным" для этого сеанса

Кто-нибудь может подумать о каких-либо других преимуществах / недостатках или о лучшем способе сделать это (кроме переписывания приложения)?

Редактировать -

Спасибо всем, кто говорит, использовать HTTPS и POST. К сожалению, я ищу ответы, которые связаны только с использованием GET. (Если вы не можете объяснить, как публиковать данные во всплывающих окнах без использования QueryString, Session или Javascript?)

Ответы [ 8 ]

7 голосов
/ 18 мая 2009

Если у вас есть что-то, что стоит заслонить, я бы предложил перейти к HTTPS и создать дамп HTTP.

Как правило, я бы не помещал в строку запроса ничего, связанного с идентификаторами клиента, поставщика или заказа. Но это я.

4 голосов
/ 18 мая 2009

Я думаю, вы никогда не должны скрывать параметры GET.

Если вам нужно скрыть параметры в строке запроса на панели навигации, вы должны использовать post.

Если вы хотите, чтобы снифферы перехватывали ваши данные GET, используйте HTTPS.

3 голосов
/ 18 мая 2009

Возможно, вы могли бы рассказать о том, что вы пытаетесь достичь? В общем, вы должны избегать размещения важных вещей (например, учетных данных для входа) в URL. URL имеют привычку «просачиваться».

Общие рекомендации: настройте файл robots.txt, чтобы Google не проиндексировал ни одну из этих страниц, и используйте токены для входа в систему (или что-либо еще) только один раз.

Редактировать: Я бы предложил не использовать слабое "шифрование" XOR. Если вы беспокоитесь о том, что люди могут изменить параметры URL, добавьте безопасный хеш. Если вам действительно нужно скрыть информацию, содержащуюся в запросе, а затем зашифровать ее по-настоящему, не используйте собственный слабый алгоритм.

2 голосов
/ 18 мая 2009

Никогда, но не защищайте информацию в запросе GET. Эти запросы регистрируются непосредственно веб-сервером. Таким образом, информация доступна в текстовом формате, которую могут просматривать и проверять сторонние организации.

Если вам нужно передать учетные данные, используйте cookie-файл для хранения информации о состоянии и наложите все на SSL.

0 голосов
/ 10 сентября 2009

Мой честный ответ заключается в том, что, если данные НЕ ДЕЙСТВИТЕЛЬНО чувствительны (например, пароль, номер кредитной карты и т. Д.), То тот, кто кодировал «шифрование», вероятно, пытался скрыть отсутствие надлежащей аутентификации / авторизации в приложении.

Если, например, вы обеспокоены тем, что если вы не зашифруете часть «accountId = 1» URL-адреса, то кто-то сможет изменить ее до «accountId = 2» и просмотреть чужую учетную запись, тогда настоящий недостаток в приложении то, что оно не проверяет владение аккаунтом перед доставкой товара!

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

0 голосов
/ 20 мая 2009

Использовать POST, если вы хотите больше безопасности?

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

0 голосов
/ 18 мая 2009

Вы можете использовать HttpModule в asp.net, который может шифровать значения HTTP Get глобально - HttpModule для шифрования строки запроса . Кроме того, используйте SessionId в качестве ключа для шифрования / описания, что делает строку запроса более безопасной для каждого сеанса. Однако он не на 100% безопасен, и я бы не рекомендовал его использовать для веб-сайтов с высоким уровнем безопасности.

Как и предполагал «JD», лучше использовать HTTPS для защиты связи между сервером и клиентом. Однако клиент может легко изменить значение параметра в браузере, например, /showinvoice.aspx?id=1000 to /showinvoice.aspx?id=1001

Я предлагаю проверять каждое значение каждого параметра на стороне сервера перед выполнением страницы. Это остановит выполнение запроса, который недопустим.

0 голосов
/ 18 мая 2009

Немногие приходят на ум ...

  • Может потребоваться аутентификация и авторизация, в зависимости от того, что запрашивается.

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

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

...