Tudo bem ter uma camada de validação antes da camada de controle de acesso

24

Estou criando um aplicativo da Web com API cortada e nesse aplicativo temos camadas diferentes que estão fazendo seu próprio trabalho.

A primeira camada é a camada de validação que valida a entrada do usuário e, se passar na validação, a moveremos para a segunda camada (que é a camada de controle de acesso ). Caso contrário, retorne a mensagem de erro

A segunda camada é o Controle de acesso, que verifica se o usuário tem permissão para executar a tarefa que deseja executar. Se o usuário tiver permissão, move a solicitação para a próxima camada, caso contrário, retorne a mensagem de erro

Terceira camada é a camada do controlador, onde temos a lógica da aplicação

Minha pergunta é que é bom ter uma camada de validação antes do controle de acesso? E se o usuário estiver tentando executar uma tarefa à qual ele não tem permissão e estamos enviando uma mensagem de erro de validação? O usuário estaria enviando solicitações para um ponto de extremidade e conversando com a camada de validação e, uma vez aprovada na validação, ele veria a mensagemYou can't access this!

Parece estranho para mim, então está bem assim ou quais poderiam ser minhas outras opções em infraestrutura?

validation web-api access-control

— Muhammad
fonte

10

Também vale a pena mencionar que as validações geralmente precisam chegar ao banco de dados para realizar seu trabalho ou a um armazenamento de arquivos. Se você fizer isso antes de verificar se há violações no controle de acesso, essencialmente permitirá que os invasores façam DDoS em seu banco de dados ou sistema de arquivos, lançando grandes quantidades de tráfego nesse URL específico.

— Greg Burghardt

No meu caso o mesmo vale para Access Control Middleware, ele verifica um recurso e ver se o tipo de recurso é acessível por usuário, se é acessível I permitir o acesso de outra forma não

— Muhammad

Isso é verdade. Durante um DDoS, essa camada ainda atingirá seu armazenamento de dados. Com a execução dessa camada, você não acessará seu armazenamento de dados para validações E controle de acesso - apenas acessará o controle de acesso. Reduz o tamanho do tsunami, mas não o impede de atingir a praia. Isso oferece a você ou a sua equipe de servidores uma chance de responder a um ataque antes que todo o sistema fique atolado.

— Greg Burghardt

5

Do ponto de vista prático, o controle de acesso deve vir antes da validação de qualquer maneira - como você validará a correção da solicitação de um usuário se ele não puder acessá-la?

— Zibbobz

Validação @Zibbobz é simples como verificar se o usuário está enviando esquema correto, como o parâmetro que deve ser inteiro é inteiro ou qualquer outra coisa

— Muhammad

57

Depende se o conhecimento da validade de alguma entrada para uma tarefa que você não tem permissão para realizar é um vazamento de segurança. Se for, você realmente deve fazer o contrário.

A única resposta segura para um usuário não autorizado é "acesso negado". Se às vezes a resposta for "solicitação incorreta" e outras vezes "acesso negado", você estará enviando informações a um usuário não autorizado.

Como exemplo, você pode verificar na validação da tarefa "excluir documento" que o documento nomeado existe. Alguém sem permissões seria capaz de discernir se existe algo tentando excluí-lo e comparando qual erro eles recebem de volta. Um invasor particularmente determinado pode enumerar todos os nomes de documentos (com um determinado comprimento), para ver quais existem.

— Caleth
fonte

7

+1, absolutamente. Se seus dados forem pessoalmente identificáveis ou sensíveis de qualquer outra forma, as implicações de segurança serão muito, muito mais sérias que as implicações de usabilidade.

— Kilian Foth

4

@ caleth, na verdade, não informaria se um determinado documento está no sistema ou não; esse tipo de informação só é fornecido quando você atinge a camada do controlador. A validação apenas verifica o esquema, ele não acessa o banco de dados - apenas controle de acesso e camadas mais profundas acessam o banco de dados. Além disso, a camada de controle de acesso mostra apenas as mesmas coisas enquanto um recurso existe ou não. A única coisa comprometer é o esquema que eu estou pensando se é ok ou não

— Muhammad

@Caleth Você poderia elaborar seu último comentário? Não vejo como é esse o caso, dado o comentário dos OPs. De qualquer forma, parece que as únicas informações que estão sendo enviadas de volta são informações não privilegiadas se o esquema estiver documentado publicamente.

— Rotem

11

@Rotem É essencialmente impossível determinar antecipadamente de quais informações um invasor poderia se beneficiar. Só porque você não encontrou uma maneira de aprender algo que não deveria, não significa que não existe. Como um exemplo extremo, pode não haver qualquer vulnerabilidade agora , mas no futuro alguém pode adicionar um cheque para a camada de validação que faz informações vazamento porque não sei que não foi protegido.

— Kamil Drakari

4

@KamilDrakari não é um exemplo extremo, é um exemplo perfeitamente razoável. Em outras palavras, se você faz a validação antes do controle de acesso, sempre que um desenvolvedor deseja adicionar uma etapa de validação, ele precisa decidir se essa validação expõe algo sensível. A chance de todos os desenvolvedores receberem a chamada corretamente parece pequena.

— Mfrankli 4/18

24

Bem, existem vários tipos de validação:

Verificação básica barata de sanidade, que verifica se a solicitação não está obviamente incorreta.

Normalmente, isso é pelo menos parcialmente duplicado, no lado do cliente, para evitar viagens de ida e volta fúteis.

De qualquer forma, isso deve ser feito antes do controle de acesso para tornar as coisas mais fáceis e menos propensas a erros, pois não corre o risco de vazamento de informações.
Validação mais cara que ainda não depende de nenhum dado de aplicativo protegido.

Se houver essa validação extra, pode ser após o controle de acesso, não para evitar vazamento de dados, mas para impedir ataques do DOS.
Às vezes, a simples execução da solicitação faz parte dessa validação implicitamente, com custo reduzido ou sem custo; portanto, ela pode ser deixada de fora aqui.

Se toda a validação da primeira etapa for duplicada, pode fazer sentido duplicar partes desse lado do cliente também.
Validação adicional, dependendo dos dados do aplicativo protegido.

Fazê-lo antes do controle de acesso obviamente arrisca o vazamento de informações. Assim, primeiro faça o controle de acesso.

— Desduplicador
fonte

3

Seria ideal executar o controle de acesso em um ponto de aplicação da política na sua infraestrutura antes mesmo de chegar à sua API. Um conjunto estático básico de validação (Ex: OpenAPI) seria o primeiro, seguido por uma validação comercial mais profunda. Até alguma validação estática pode potencialmente ter impacto na disponibilidade dos ataques do ReDOS do seu aplicativo .

— Felickz #

@felickz: Sim, os ataques do DOS são um motivo válido para adiar a validação até depois da autorização. É um ato de equilíbrio. Enfim, eu dividi meu primeiro ponto para levar isso em conta corretamente.

— Deduplicator

Fazer validação cara antes do controle de acesso também corre o risco de vazar informações devido a ataques de tempo. Se o seu sistema demorar mais ou menos, dependendo do recurso, o invasor poderá inferir aspectos do recurso que está sendo solicitado.

— Lie Ryan

@LieRyan: Qual é o motivo de toda a validação potencialmente anterior ao controle de acesso não depender de dados de aplicativos protegidos.

— Deduplicator

13

Deve haver alguma validação antes do controle de acesso. Digamos que a API da SO tenha um nó de extremidade "editar resposta"; portanto, se o usuário pode editar uma resposta específica pode depender da resposta (abaixo de uma certa reputação, o usuário pode editar apenas suas próprias respostas). Portanto, o parâmetro "ID da resposta" que está sendo bem formado deve ser verificado antes que a camada de controle de acesso entre em jogo; possivelmente também que a resposta exista.

OTOH, como mencionam Caleth e Greg, colocar uma validação mais extensa antes do controle de acesso é um risco potencial à segurança.

Portanto, as regras rígidas são

Você não deve divulgar nenhuma informação através de validação que o usuário não possa descobrir de outra forma.
Você deve validar os dados antes que o controle de acesso possa usá-los na medida em que o controle de acesso precisar.

Seguir essas duas regras pode significar que você precisa ter alguma validação antes e depois do controle de acesso.

— Sebastian Redl
fonte

3

Esta é a resposta realista. Se for uma validação simples e direta da estrutura de dados de entrada, não haverá escrúpulos em colocá-la em primeiro lugar. Ele até protege a camada de controle de acesso de entradas / pacotes especialmente projetados. A validação que realmente envolve vazamento ou suposição de informações seguras deve ser feita após as verificações de acesso.

— SD

Isso pressupõe que as respostas sejam públicas. Ouso dizer que muitas APIs nem sequer mostram os dados sem autenticação.

— TomTom

6

Além da possível frustração de receber um 'acesso negado' após validar a entrada; Lembre-se também de que a camada de validação , a menos que seja muito simples, sempre pode precisar de informações do controlador . Tendo isso em mente, acredito que posicionar a Validação atrás do Controle de acesso , mais próximo do Controller, faz mais sentido.

— simurg
fonte

2

Isso depende do que você quer dizer com camada de validação - se com isso você quer apenas verificar a sintaxe da solicitação, isso é seguro e algo que você precisa fazer de qualquer maneira. Se a sua 'validação' usa qualquer informação que um usuário não privilegiado não tenha acesso, ela não é mais segura.

Você definitivamente deve ter um verificador de sanidade antes de tentar o controle de acesso, mas deve se comunicar muito claramente a todos os mantenedores (atuais e futuros) de que esta parte não deve usar informações privilegiadas; Essas verificações devem ser feitas em uma etapa de validação separada após a autenticação.

Como uma verificação de integridade para o verificador de integridade, ele não deve realmente ter nenhuma dependência de código em qualquer parte do código abaixo do pipeline e deve ser separável em seu próprio pacote que deve ser publicamente publicável sem problemas (exceto possíveis problemas legais) . Se você não pode fazer isso, sua 'camada de validação' está fazendo muito (ou sua base de código está uma bagunça).

— Cúbico
fonte

1

Não, não está bem.

Se você tiver um bug em sua camada de validação, ele pode ignorar a camada de segurança.

É um erro comum considerar a segurança como parte dos requisitos de negócios. "apenas usuários com o papel de vendas, deve ser capaz de ver os números trimestrais" parece ser uma regra de negócios.

Mas, se você quiser se proteger, precisará ler uma regra como "apenas usuários na função de vendas, devem poder executar o código neste nó de extremidade". Verifique se o servidor sempre retorna "acesso negado" antes de chegar ao qualquer tipo de código que você escreveu ou arquivos no servidor.

— Ewan
fonte