Можно ли иметь уровень проверки перед уровнем контроля доступа?

24

Я создаю веб-приложение API strcutured, и в этом приложении у нас есть разные уровни, которые выполняют свою работу.

Первый слой Validation слой , который пользовательский ввод Validate , и если она проходит проверку мы двигаемся , что второй слой (который является контроль доступа слоя) в противном случае возвращают сообщение об ошибке

Второй уровень - Контроль доступа, который проверяет, есть ли у пользователя разрешение на выполнение задачи, которую он хочет выполнить. Если у пользователя есть разрешение, он перемещает запрос на следующий уровень, в противном случае возвращает сообщение об ошибке.

Третий уровень - это слой контроллера, где у нас есть логика применения

Мой вопрос в том, что нормально иметь уровень проверки перед контролем доступа? Что если пользователь пытается выполнить задачу, на которую у него нет разрешения, и мы отправляем обратно сообщение об ошибке проверки? Пользователь будет отправлять запросы в конечную точку и разговаривать со слоем проверки, и как только он пройдет проверку только тогда, он увидит сообщениеYou can't access this!

Мне кажется странным, так ли это нормально, или что может быть моим другим выбором в инфраструктуре?

validation web-api access-control

— Мухаммед
источник

10

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

— Грег Бургхардт

В моем случае то же самое относится к промежуточному программному обеспечению контроля доступа, оно проверяет ресурс и проверяет, доступен ли тип ресурса пользователю, если он доступен, я разрешаю доступ, в противном случае - нет

— Мухаммед

Это правда. Во время DDoS этот слой все равно попадет в ваше хранилище данных. Запустив этот слой первым, вы не попадете в хранилище данных для проверок и контроля доступа - вы просто попадете в него для контроля доступа. Это уменьшает размер цунами, но не препятствует попаданию на пляж. Это дает вам или вашей серверной команде реальный шанс отреагировать на атаку до того, как вся система погрязнет.

— Грег Бургхардт

5

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

— Зиббобз

Проверка @Zibbobz проста, как проверка, отправляет ли пользователь правильную схему, например, параметр, который должен быть целым числом, является целым числом или чем-то еще

— Мухаммед

57

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

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

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

— Caleth
источник

7

+1, абсолютно. Если ваши данные каким-либо образом могут быть идентифицированы или конфиденциальны, то последствия для безопасности намного, гораздо серьезнее, чем последствия для удобства использования.

— Килиан Фот

4

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

— Мухаммед

@Caleth Не могли бы вы уточнить ваш последний комментарий? Я не понимаю, как это так, учитывая комментарии ОП. В любом случае кажется, что единственная информация, отправляемая обратно, является непривилегированной информацией, если схема публично документирована.

— Rotem

11

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

— Камил Дракари

4

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

— mfrankli

24

Ну, есть несколько типов проверки:

Дешевая базовая проверка работоспособности, которая проверяет, что запрос явно не искажен.

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

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

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

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

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

— Deduplicator
источник

3

Было бы идеально выполнять контроль доступа в точке реализации политики в вашей инфраструктуре даже до достижения вашего API. Первым должен быть базовый статический набор проверки (например, OpenAPI), а затем более глубокая проверка бизнеса. Даже некоторая статическая проверка может потенциально повлиять на доступность ваших приложений ReDOS- атак.

— Felickz

@felickz: Да, DOS-атаки являются веской причиной отложить проверку до окончания авторизации. Это баланс-акт. Во всяком случае, я разделил свою первую точку, чтобы правильно принять это во внимание.

— дедупликатор

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

— Ли Райан

@LieRyan: По этой причине вся проверка, которая возможна до контроля доступа, вообще не зависит от данных защищенного приложения.

— дедупликатор

13

Должна быть некоторая проверка перед контролем доступа. Скажем, API SO имеет конечную точку «редактировать ответ», и то, может ли пользователь редактировать конкретный ответ, может зависеть от ответа (ниже определенной репутации пользователь может редактировать только свои собственные ответы). Таким образом, корректно сформированный параметр «ID ответа» должен быть проверен до того, как уровень контроля доступа вступит в игру; возможно также, что ответ существует.

OTOH, как отмечают Калет и Грег, более тщательная проверка перед контролем доступа является потенциальной угрозой безопасности.

Таким образом, жесткие правила

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

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

— Себастьян Редл
источник

3

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

— SD

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

— TomTom

6

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

— Симург
источник

2

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

Вы обязательно должны иметь проверку работоспособности, прежде чем пытаться контролировать доступ, но вы должны очень четко сообщить всем сопровождающим (текущим и будущим), что эта часть не должна использовать привилегированную информацию; Любые такие проверки должны выполняться на отдельном этапе проверки после проверки подлинности.

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

— кубический
источник

1

Нет, это не хорошо.

Если у вас есть ошибка на вашем уровне проверки, она может обойти уровень безопасности.

Распространенной ошибкой считать безопасность частью бизнес-требований. «Только пользователи, имеющие роль продаж, должны иметь возможность видеть квартальные цифры», похоже на бизнес-правило.

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

— Ewan
источник