액세스 제어 계층 전에 유효성 검사 계층을 갖는 것이 괜찮습니까?

API 구조화 된 웹 응용 프로그램을 만들고 있으며이 응용 프로그램에는 자체 작업을 수행하는 다른 계층이 있습니다.

첫 번째 계층은 사용자 입력의 유효성을 검사하는 유효성 검사 계층이며, 유효성 검사를 통과하면 두 번째 계층 ( 액세스 제어 계층)으로 이동하고 그렇지 않으면 오류 메시지를 반환합니다.

두 번째 계층은 사용자가 수행하려는 작업을 수행 할 수있는 권한이 있는지 확인하는 액세스 제어 입니다. 사용자가 권한이 있으면 요청을 다음 계층으로 이동하고 그렇지 않으면 오류 메시지를 반환합니다.

세 번째 계층은 응용 프로그램의 논리가있는 컨트롤러 계층입니다.

내 질문은 액세스 제어 전에 유효성 검사 계층을 갖는 것이 괜찮습니까? 사용자가 권한이없는 작업을 수행하려고하고 유효성 검사 오류 메시지를 다시 보내면 어떻게됩니까? 사용자는 엔드 포인트로 요청을 보내고 유효성 검사 계층과 대화하고 유효성 검사를 통과 한 후에 메시지를 보게됩니다.You can't access this!

나에게 이상하게 느껴지므로 이것처럼 괜찮거나 인프라에서 다른 옵션이 될 수 있습니까?

허용되지 않은 작업에 대한 일부 입력의 유효성을 아는 것이 보안 누출인지 여부에 따라 다릅니다. 그렇다면 실제로 다른 방법으로 수행해야합니다.

권한이없는 사용자에 대한 유일한 안전한 응답은 "액세스 거부"입니다. 때때로 응답이 "잘못된 요청"이고 다른 경우 "액세스 거부"인 경우, 권한이없는 사용자에게 정보를 전송하는 것입니다.

예를 들어 명명 된 문서가 존재하는 "문서 삭제"작업의 유효성을 검사 할 수 있습니다. 권한이없는 사람은 삭제하려고 시도하고 수신 한 오류를 비교하여 존재 여부를 식별 할 수 있습니다. 특별히 결정된 공격자는 어떤 문서가 존재하는지 확인하기 위해 모든 문서 이름을 특정 길이로 열거 할 수 있습니다.

여러 가지 유형의 유효성 검사가 있습니다.

1. 저렴한 기본 위생 검사-요청이 명백하게 잘못되었는지 확인합니다.

   헛된 왕복을 피하기 위해 일반적으로 클라이언트 측에서 최소한 부분적으로 복제됩니다.

   어쨌든 정보 유출 위험이 없으므로 액세스 제어를 수행하기 전에 오류가 발생하기 쉬운 작업을 수행해야합니다.

2. 보호 된 응용 프로그램 데이터에 여전히 의존하지 않는 더 비싼 유효성 검사

   이러한 추가 유효성 검사가있는 경우 액세스 제어 후 데이터 유출을 피하지 않고 DOS 공격을 방해 할 수 있습니다.
   때로는 단순히 요청을 실행하면 일부 유효성 검사가 암시 적으로 감소되거나 비용없이 수행되므로 여기서 생략 될 수 있습니다.

   첫 번째 단계의 모든 유효성 검사가 복제되면이 클라이언트 측의 일부도 복제하는 것이 좋습니다.

3. 보호 된 응용 프로그램 데이터에 따른 추가 검증

   액세스 제어 전에이를 수행하면 정보 유출 위험이 커집니다. 따라서 먼저 액세스 제어를 수행하십시오.

액세스 제어 전에 일부 유효성 검사 가 있어야합니다 . SO의 API에 엔드 포인트 "답변 편집"이 있고 사용자가 특정 응답을 편집 할 수 있는지 여부는 응답에 따라 달라질 수 있습니다 (특정 평판 아래에서는 사용자가 자신의 답변 만 편집 할 수 있음). 따라서 액세스 제어 계층이 작동하기 전에 올바른 형식의 "응답 ID"매개 변수를 확인해야합니다. 아마도 대답이 존재할 수도 있습니다.

Caleth와 Greg가 언급했듯이 OTOH는 액세스 제어 전에보다 광범위한 검증을하는 것이 잠재적 인 보안 위험입니다.

어려운 규칙은

1. 사용자가 달리 알 수없는 것으로 확인 된 유효성 검사를 통해 정보를 공개해서는 안됩니다.
2. 액세스 제어가 필요로하는 범위까지 액세스 제어가 데이터를 사용하려면 먼저 데이터의 유효성을 검사해야합니다.

이 두 규칙을 모두 따르면 액세스 제어 전과 후에 일부 유효성 검사가 필요하다는 것을 의미 할 수 있습니다.

입력을 확인한 후 '액세스 거부'를받는 데 따르는 좌절과 더불어 ; 또한 유효성 검사 계층은 매우 간단한 것이 아니라면 항상 Controller의 정보가 필요할 수 있습니다 . 이것을 염두에두고, 액세스 제어 뒤에 유효성 검사를 배치하는 것이 컨트롤러에 더 가깝다고 생각 합니다.

이는 유효성 검사 계층이 의미하는 바에 따라 다릅니다. 요청 구문을 확인하는 것이 안전하다면 어쨌든 안전해야합니다. '유효성 검사'는 권한이없는 사용자가 액세스 할 수없는 정보를 사용 하는 경우 더 이상 안전하지 않습니다.

액세스 제어를 시도하기 전에 완전성 검사기가 있어야하지만,이 부분이 권한있는 정보를 사용 해서는 안된다는 모든 관리자 (현재와 미래)에게 매우 명확하게 통신하도록주의 해야합니다 . 이러한 검사는 인증 후 별도의 유효성 검사 단계에서 수행해야 합니다.

온 전성 검사기의 온 전성 검사는 실제로 코드의 어느 부분에 대해서도 코드 종속성이 없어야하며 파이프 라인을 낮추고 문제없이 공개적으로 게시 할 수있는 자체 패키지로 분리 할 수 ​​있어야합니다 (법적 문제는 제외) . 그렇게 할 수 없다면 '유효성 검사 계층'이 너무 많은 일을하고 있거나 코드베이스가 엉망입니다.

아뇨 괜찮아요

유효성 검사 계층에 버그가 있으면 보안 계층을 무시할 수 있습니다.

비즈니스 요구 사항의 일부로 보안을 고려하는 것은 흔한 실수입니다. "판매 역할을 가진 사용자 만 분기 별 수치를 볼 수 있어야합니다"는 비즈니스 규칙처럼 보입니다.

그러나 보안을 유지하려면 "판매 역할의 사용자 만이 엔드 포인트에서 코드를 실행할 수 있어야합니다"와 같은 규칙을 읽어야합니다. 서버가 도착하기 전에 항상 "액세스 거부"를 반환해야합니다. 서버에서 작성한 모든 종류의 코드 또는 파일.