Безопасно ли показывать индексы базы данных клиентам Silverlight?

Question

У меня есть приложение Silverlight, которое связывается с бэкэндом ASP.NET через WCF. У меня есть набор объектов DataContract, которые я определил и которые (по большей части) соответствуют типам, сгенерированным LINQ to SQL, с которыми работает мой сервер ASP.NET. Мой код WCF генерирует экземпляры моих объектов DataContract из типов генератора LINQ to SQL, когда мне нужно передать данные в мой клиент Silverlight.

У меня следующий вопрос: Каковы последствия для безопасности предоставления индекса (который используется в качестве первичного ключа в базе данных) через мои объекты DataContract?

Пример таблицы (позиция) в моей базе данных имеет следующие столбцы:

• PositionIndex: int (первичный ключ)
• PositionName: строка
• PositionType: int

И соответствующий объект (более или менее) это:

public class Position
{
    public int PositionIndex { get; set; }
    public string PositionName { get; set; }
    public int PositionTYpe { get; set; }
}

Я обеспокоен тем, что знаю, как легко перепроектировать DLL-библиотеки Silverlight с помощью Reflection - любой потенциальный злоумышленник узнает, что я даю клиенту индекс базы данных, и, поскольку они могут перепроектировать DLL-файлы Silverlight, они могут легко получить URL-адрес моих служб WCF и попытаться сломать их. Теперь я был хорош и воспользовался советом многих, кто пришел до меня, и я сделал много-много проверок на стороне ASP.NET, чтобы убедиться, что мои сервисы WCF получают легальный вклад, но я все еще обеспокоен что я делаю что-то плохое, давая потенциальным плохим парням немного, а не немного, понимание того, как устроен бэкэнд моей системы, и я достаточно долго знал, что этого более чем достаточно, чтобы решительный человек мог начать с.

Что вы, ребята, думаете? Если я делаю что-то плохое, используя индекс в моих DataContracts, можете ли вы предложить альтернативу? Мне трудно придумать дизайн, который не предоставляет этот индекс, поскольку мне нужно, чтобы клиент Silverlight обновлял строки, уже находящиеся в моей базе данных, и наличие индекса - лучший способ, который я могу помочь сторона ASP.NET определяет, какую строку в базе данных нужно обновить.

Answer 1

https://stackoverflow.com/questions/454771/is-it-safe-to-expose-database-indices-to-silverlight-clients

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

:)

Answer 2

Единственное, что могло бы помочь, - это иметь какую-то авторизацию, чтобы вы могли отслеживать, какие клиенты «владеют» какими ключами, чтобы они не могли изменять записи, которые они не должны изменять.

Answer 3

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

Основным преимуществом естественного ключа будет то, что вам нужно сохранить запись в средне- и долгосрочной перспективе отключенной от системы, или перенести запись между параллельными системами (где первичный ключ перестает быть полезным) - но это похоже, проблема не в этом.

Если безопасность относится к основной , вы могли бы выдать временные ключи (возможно, направляющие) для объектов, которые существуют только для сеанса клиента - переназначить их обратно на сервер. Однако на практике это было бы довольно болезненно.

Конечно, вы можете использовать Guids в качестве первичного ключа (uniqueidentifier): еще одно преимущество ключей на основе guid состоит в том, что (если они генерируются случайным образом) они не позволяют использовать ключ " +1, ключ + 2 "подход к запросу данных.

В любом случае, вы должны проверить, что клиенту разрешено [создавать / читать / обновлять / удалять соответствующим образом] запись, которой он пытается манипулировать.