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

Здравствуйте, voviandr, Вы писали:

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

Зачем такой огород? Все что нужно — проверить, чьи это данные и не давать смотреть чужие.

Здравствуйте, voviandr, Вы писали:

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

Это стандартный пример как пытаются изобретать велосипед с точки зрения безопасности.
СУБД это такая штука, у которой очень развиты механизмы разграничения доступа. Конечно, если приложение общается с базой только через одно соединение с максимальными правами, то этот механизм сводится на нет, но если использовать соединения именные или использовать механизмы проксирования (имперсонации), то такой вопрос попросту не возникнет — перехвативший ключ не получит доступ к данным, поскольку его учетке этот доступ не назначен.

Здравствуйте, voviandr, Вы писали:

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

Ну и что страшного будет, если какой-нить злоумышленник узнает ID пользователя в БД.
Авторизация-то происходит по: Login, Password

Злоумышленник узнает ID (номер строки таблицы БД), где хранятся личные данные пользователя.
Но без физического доступа к этой БД, инфы то он никак не получит ...

MSO>Злоумышленник узнает ID (номер строки таблицы БД), где хранятся личные данные пользователя.
MSO>Но без физического доступа к этой БД, инфы то он никак не получит ...

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

Здравствуйте, voviandr, Вы писали:

MSO>>Злоумышленник узнает ID (номер строки таблицы БД), где хранятся личные данные пользователя.
MSO>>Но без физического доступа к этой БД, инфы то он никак не получит ...

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

Это заведомо неверно: архитектура веб-приложения должна позволять любому юзеру смотреть общие (то бишь PUBLIC/COMMON) поля других уч. записей.
И в зависимости от группы уч. записи (вдруг это Admin) позволять менять или контролировать реквизиты записей таблицы Accounts ...
Да что тут огород городить или велосипед изобретать, достаточно посмотреть как сделано в многопользовательских CMS,
например, та же DLE (Data Life Engine)

MSO>Это заведомо неверно: архитектура веб-приложения должна позволять любому юзеру смотреть общие (то бишь PUBLIC/COMMON) поля других уч. записей.

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

Здравствуйте, DOOM, Вы писали:

DOO>Это стандартный пример как пытаются изобретать велосипед с точки зрения безопасности.
DOO>СУБД это такая штука, у которой очень развиты механизмы разграничения доступа. Конечно, если приложение общается с базой только через одно соединение с максимальными правами, то этот механизм сводится на нет, но если использовать соединения именные или использовать механизмы проксирования (имперсонации), то такой вопрос попросту не возникнет — перехвативший ключ не получит доступ к данным, поскольку его учетке этот доступ не назначен.

Я бы не рекомендовал использовать именные соединения в веб-проекте. Как и любой другой контекст на стороне БД.

Здравствуйте, Ziaw, Вы писали:

Z>Я бы не рекомендовал использовать именные соединения в веб-проекте. Как и любой другой контекст на стороне БД.
По какой причине?

Здравствуйте, Аноним, Вы писали:

MSO>>Это заведомо неверно: архитектура веб-приложения должна позволять любому юзеру смотреть общие (то бишь PUBLIC/COMMON) поля других уч. записей.

А>говоря проще, конечный результат который я хочу получить —
А>если я скопирую ссылку из одноклассников, и передам эту ссылку другому юзеру, то он её открыть ведь не сможет, так ?
А>его просто выбросит на его же главную страницу. вот как добиться аналогичного поведения в моём веб-приложении ?

Зависит от ссылки, в одноклассниках в некоторых урлах зашита сессия пользователя, в некоторых нет.

Ты не туда копаешь, простых (якобы) средств будет недостаточно. Любая модификация урла будет защитой на основе незнания алгоритма, первый злоумышленник который догадается о нем — вытащит данные.

Нужно везде проверять может ли пользователь иметь доступ к конкретным данным. Если может — показываем, если нет — нет. Например, если тебе нужно сделать какие-то приватные строки в таблице, сделай там поле OwnerID и ко всем запросам добавляй and (OwnerID = @CurrentUserId).

Здравствуйте, Ziaw, Вы писали:

Z>Нужно везде проверять может ли пользователь иметь доступ к конкретным данным. Если может — показываем, если нет — нет. Например, если тебе нужно сделать какие-то приватные строки в таблице, сделай там поле OwnerID и ко всем запросам добавляй and (OwnerID = @CurrentUserId).
Ну дак ты все-таки объяснишь, почему надо обязательно изобретать свой велосипед, собирая по дороге все шишки до этого набитые производителями ОС и СУБД?

Здравствуйте, DOOM, Вы писали:

Z>>Я бы не рекомендовал использовать именные соединения в веб-проекте. Как и любой другой контекст на стороне БД.
DOO>По какой причине?

Причин полно, начнем с аутентификации, какую атуентификацию выбрать? Для windows нам придется заводить дополнительные аккаунты в системе, для парольной хранить где-то вне базы в относительно открытом виде пользователей и их пароли. Все это довольно неприятно администрировать.

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

Еще начинаются проблемы с кешами, как на стороне БД так и на стороне вебсервера.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, DOOM, Вы писали:

Z>>>Я бы не рекомендовал использовать именные соединения в веб-проекте. Как и любой другой контекст на стороне БД.
DOO>>По какой причине?

Z>Причин полно, начнем с аутентификации, какую атуентификацию выбрать?
Любую. Реализовать SSO в базу не так сложно. Источником данных о пользователе (если СУБД нормальная) может быть все, что угодно (как и для самого web приложения — в общем-то что выиграть-то ты пытаешься?).

Z>Для windows нам придется заводить дополнительные аккаунты в системе, для парольной хранить где-то вне базы в относительно открытом виде пользователей и их пароли. Все это довольно неприятно администрировать.
Где ты предлагаешь хранить учетки пользователей (это я к тому, что непонятно, где ты пытаешься сэкономить)?


Z>Запрос будет вынужден вначале узнать текущего пользователя и установить соединение от его имени. Тут мы приходим ко второй проблеме, стоимость создания соединения достаточно высока. На каждый запрос это слишком дорого, придется изобретать свой пулинг.
Это тоже уже придумано до нас. У того же оракла есть прокси-пользователь.

Z>Еще начинаются проблемы с кешами, как на стороне БД так и на стороне вебсервера.
Проблема с кэшем не начинается, а остается

Здравствуйте, DOOM, Вы писали:

Z>>>>Я бы не рекомендовал использовать именные соединения в веб-проекте. Как и любой другой контекст на стороне БД.
DOO>>>По какой причине?

Z>>Причин полно, начнем с аутентификации, какую атуентификацию выбрать?
DOO>Любую. Реализовать SSO в базу не так сложно. Источником данных о пользователе (если СУБД нормальная) может быть все, что угодно (как и для самого web приложения — в общем-то что выиграть-то ты пытаешься?).

Итак лишняя система номер 1 — SSO.

Z>>Для windows нам придется заводить дополнительные аккаунты в системе, для парольной хранить где-то вне базы в относительно открытом виде пользователей и их пароли. Все это довольно неприятно администрировать.
DOO>Где ты предлагаешь хранить учетки пользователей (это я к тому, что непонятно, где ты пытаешься сэкономить)?

Я констатирую простой факт, аутентификационные данные пользователей придется хранить вне основной БД. Лишняя система номер 2, лишние синхронизации, проблемы консистентного бэкапа.

Z>>Запрос будет вынужден вначале узнать текущего пользователя и установить соединение от его имени. Тут мы приходим ко второй проблеме, стоимость создания соединения достаточно высока. На каждый запрос это слишком дорого, придется изобретать свой пулинг.
DOO>Это тоже уже придумано до нас. У того же оракла есть прокси-пользователь.

Угу, ессно придумано, проблема то не надуманная, ее пришлось решать костылями. Только зачем нам этот огород?

Z>>Еще начинаются проблемы с кешами, как на стороне БД так и на стороне вебсервера.
DOO>Проблема с кэшем не начинается, а остается

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

База даст нам column level security и row level security. Нужен механизм управления ими в приложении, лишняя система номер 3.

Метаданные CLS придется тащить на клиента, GUI потребуются эти знания. Причем в зависимости от привилегий пользователя нам все равно придется строить еще запросы (иначе ), этот геморой нам зачем?

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

Теперь рассказывай ты, что ты сможешь сэкономить.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Ziaw, Вы писали:

Z>>Нужно везде проверять может ли пользователь иметь доступ к конкретным данным. Если может — показываем, если нет — нет. Например, если тебе нужно сделать какие-то приватные строки в таблице, сделай там поле OwnerID и ко всем запросам добавляй and (OwnerID = @CurrentUserId).
DOO>Ну дак ты все-таки объяснишь, почему надо обязательно изобретать свой велосипед, собирая по дороге все шишки до этого набитые производителями ОС и СУБД?


Если ты объяснишь мне зачем тут что-то изобретать.

База дает:

Table level crud security — приложение все равно должно знать все эти правила, чтобы UI мог дисаблить/скрывать ненужные кнопки, если приложение и так умеет делать такие проверки, зачем нам их тащить еще на уровень БД? Какой смысл поддерживать две одинаковые схемы безопасности и там и там и не допускать их рассогласовывания. Зачем удваивать вероятность ошибок определенного класса? При развитии/поддержке работающей системы хватает забот и без этого.

Column level security — в моем случае перечисление в запросе только тех колонок которые доступны пользователю. Это придется делать и в твоем случае тоже.

Row level security — в моем случае обычный предикат к запросам, в твоем случае такой же предикат, только он настривается в БД. Только вот я у себя могу в любой момент отключить этот предикат из кода приложения, а у тебя нужны не очень простые приседания.

Итак, сухой остаток: единственный плюс авторизации БД — нельзя забыть подставить предикаты безопасности в RLS. Это реализуемо и в коде приложения, например через linq.

Здравствуйте, Ziaw, Вы писали:

DOO>>Любую. Реализовать SSO в базу не так сложно. Источником данных о пользователе (если СУБД нормальная) может быть все, что угодно (как и для самого web приложения — в общем-то что выиграть-то ты пытаешься?).
Z>Итак лишняя система номер 1 — SSO.
Это не система. Это грамотная архитектура.

Z>Я констатирую простой факт, аутентификационные данные пользователей придется хранить вне основной БД. Лишняя система номер 2, лишние синхронизации, проблемы консистентного бэкапа.
Бэкап оперирует файлами данных и журналами транзакций, а не базами данных — проблема высосана из пальца.
То, что учетные записи лежат в некоторой служебной таблице — это только в плюс.

Z>Угу, ессно придумано, проблема то не надуманная, ее пришлось решать костылями. Только зачем нам этот огород?
С чего это костыль? Это распространенная технология. Когда ты обращаешься к виндовой шаре, то SMB сервер имперсонирует поток и в результате не парится за твои разрешения на уровне файловой системы. Почему по-твоему? Потому что TCB должно быть как можно меньше — это поняли еще в 60-ые.

Z>>>Еще начинаются проблемы с кешами, как на стороне БД так и на стороне вебсервера.
DOO>>Проблема с кэшем не начинается, а остается
Z>Усугубляется тем, что становится менее очевидно, какие запросы зависят от текущего пользователя, а какие нет.
Давай поймем о каком кэше ты говоришь — если о выборках БД, то использовать надо кэш БД — там вопросы безопасности будут решены.
Если кэш страниц пользователя — то эта проблема одинакова и в том и в другом случае.

Z>База даст нам column level security и row level security. Нужен механизм управления ими в приложении, лишняя система номер 3.
Ну механизмов таки больше — и никакой лишней системы. Ты тут сам предлагал шлепать ID пользователя в каждой строке — это в чистом виде копирование функционала СУБД.

Z>Метаданные CLS придется тащить на клиента, GUI потребуются эти знания.
Это-то почему?
Z>Причем в зависимости от привилегий пользователя нам все равно придется строить еще запросы (иначе ), этот геморой нам зачем?
Тут не понял.

Z>RLS нам тоже даст лишний оверхед в некоторых запросах, при этом велика вероятность, что некоторые данные которые мы не можем прочитать прямо, вдруг понадобятся в каких-то агрегатах, которые *сюрприз* должен видеть пользователь. Придется лепить костыли из хранимок.
Интересно, почему хранимая процедура — это костыль? Ты с Oracle AS работал? Там почти все на хранимых процедурах... Или HAS есть, например — тоже вся логика в базе, на web-сервере только преобразование в UI.
А твои агрегированные данные — используй вьюхи и подобные механизмы.
В конце-концов, если в данных порядка нет, то не будет порядка в модели безопасности.

Z>Теперь рассказывай ты, что ты сможешь сэкономить.
Годы допиливания системы разграничения доступа до нормального уровня. Это не так банально сделать, как тебе кажется. Недаром web приложения дырявые как решето.

Здравствуйте, Аноним, Вы писали:

А>говоря проще, конечный результат который я хочу получить —
А>если я скопирую ссылку из одноклассников, и передам эту ссылку другому юзеру, то он её открыть ведь не сможет, так ?
А>его просто выбросит на его же главную страницу. вот как добиться аналогичного поведения в моём веб-приложении ?
1. Реализовать поддержку сессий. В вашей платформе это стопроцентно уже есть.
2. Реализовать поддержку авторизации. Типа — если приходит запрос вне сессии, то редиректим пользователя на логин страницу, а после логина и создания сессии редиректим обратно. В вашей платформе это стопроцентно уже есть.
3. Реализовать структуру ACL — Access Control List. Зависит от вашей фантазии и потребностей вашего приложения. Можете хранить в каждой "строке" ID её хозяина. Можете реализовать unix-style уровни доступа "все-группа-владелец", гуглить по chmod 666. Можете приклеить к каждой строке DACL в стиле винды. Можете приклеить RBAC в стиле Exchange 2010.
4. Теперь просто при обработке запроса первым делом смотрите в сессии ID текущего пользователя, и проверяете политику безопасности. Если не совпало — отдаётё 403 Unauthorized. Если совпало — 200 Ok.

Здравствуйте, DOOM, Вы писали:

Z>>Теперь рассказывай ты, что ты сможешь сэкономить.
DOO>Годы допиливания системы разграничения доступа до нормального уровня. Это не так банально сделать, как тебе кажется.

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

Размазывание логики между приложением и базой дает очень серьезные проблемы с рефакторингом. Это уже не годы допиливания, это годы переписывания.

DOO>Недаром web приложения дырявые как решето.

И основные дыры в них это sql injection, пресекается совсем не в БД и XSS с которым тоже средствами БД не справиться.

Здравствуйте, Ziaw, Вы писали:

Z>Ты на профильном форуме, будь добр аргументировать высказывания. Пока я увидел распухание схемы данных на дополнительные вьюхи и хранимые процедуры. Это то, что программисту придется дополнительно постоянно держать в голове, а она не резиновая. Больше сущностей — больше случаев ошибочного их использования.
Это тоже. Но и реализовать полностью концепцию Reference Monitor в рамках web приложения — очень непросто.
Те же SQL инъекции — типичный пример ошибки идентификации запроса пользователя (думал, что пользователь делает одну выборку, а реально там совсем другое).
Ни в одной современной СУБД такой дыры почему-то не найти — наверное, потому что они убили много времени на верификацию разборщика запросов.
Посмотри вот эту статью (достаточно только картинку): http://www.net-security.org/secworld.php?id=6501
Основная уязвимость — Information Leakage — т.е. это провалы самопальной системы разграничения доступа.

DOO>>Недаром web приложения дырявые как решето.
Z>И основные дыры в них это sql injection, пресекается совсем не в БД и XSS с которым тоже средствами БД не справиться.
Откуда у тебя такая информация — см. ссылку выше.
Кроме того, если пользователь ограничен в правах при соединении с базой, то проку от SQL инъекции нет вообще — он только свою информацию сможет получить/исказить.

Здравствуйте, DOOM, Вы писали:

Z>>Ты на профильном форуме, будь добр аргументировать высказывания. Пока я увидел распухание схемы данных на дополнительные вьюхи и хранимые процедуры. Это то, что программисту придется дополнительно постоянно держать в голове, а она не резиновая. Больше сущностей — больше случаев ошибочного их использования.
DOO>Это тоже. Но и реализовать полностью концепцию Reference Monitor в рамках web приложения — очень непросто.

Ответь на http://www.rsdn.ru/forum/web/4239569.1.aspx

Автор: Ziaw
Дата: 18.04.11

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

DOO>Те же SQL инъекции — типичный пример ошибки идентификации запроса пользователя (думал, что пользователь делает одну выборку, а реально там совсем другое).
DOO>Ни в одной современной СУБД такой дыры почему-то не найти — наверное, потому что они убили много времени на верификацию разборщика запросов.

Ни в одной современной системе разработки веб приложений этой дыры давно нет.

DOO>Посмотри вот эту статью (достаточно только картинку): http://www.net-security.org/secworld.php?id=6501
DOO>Основная уязвимость — Information Leakage — т.е. это провалы самопальной системы разграничения доступа.

К этому классу уязвимостей можно отнести все что угодно, вплоть до слабого пароля админа. Ты сам то писал такие системы? Все равно самопальная нужна, никуда ты не денешься. Как ты проверишь, может ли пользователь создать запись внутри слоя UI? Как ты разрешишь создание записей по сложному сценарию?

Дано ACL правило "пользователь DOOM может создавать документы определенных типов в папке исходящие, если копия документа отправляется начальнику его отдела", расскажи как ты его воткнешь в базу. ACL это часть бизнеслогики, вынос ее в БД означает огромное дублирование кода. Дублирование с кодом приложения и дублирование за счет беднейших средств декомпозиции кода в SQL.

DOO>>>Недаром web приложения дырявые как решето.
Z>>И основные дыры в них это sql injection, пресекается совсем не в БД и XSS с которым тоже средствами БД не справиться.
DOO>Откуда у тебя такая информация — см. ссылку выше.
DOO>Кроме того, если пользователь ограничен в правах при соединении с базой, то проку от SQL инъекции нет вообще — он только свою информацию сможет получить/исказить.

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

Вобщем плюс в твоей схеме только один, дополнительный "фаервол". Если нас сломали, у нас есть еще одна стенка. Но эта стенка совсем не бесплатно дается.