잘못된 권한 부여

인증은 사용자가 누구인지 증명합니다. 권한 부여는 사용자가 무엇을 할 수 있는지 결정합니다.

권한 부여가 제대로 작동하지 않으면 시스템이 사용자가 해서는 안 되는 작업을 하거나 보아서는 안 되는 내용을 볼 수 있게 합니다.

BOLA는 객체 수준 권한 부여 오류를 의미합니다.

이는 가장 중요한 API 위험입니다. API가 사용자가 로그인했는지는 확인하지만, 사용자가 요청한 특정 객체가 실제로 해당 사용자에게 속하는지는 확인하지 않는 경우입니다.

사용자의 계정이 100번이라고 가정해 보십시오.

ID를 변경했는데도 서버가 응답한다면 다른 사람의 주문을 읽은 것입니다. 이것이 BOLA입니다.

개발자는 요청에 포함된 ID를 신뢰하는 경우가 많습니다.

로그인한 사용자가 해당 객체를 실제로 소유하는지 확인하는 것을 잊는 것입니다. 해결 방법은 모든 요청에서 소유권을 확인하는 것입니다.

또 다른 결함은 BFLA인 기능 수준 권한 부여 오류입니다.

일반 사용자가 관리자 전용 작업을 호출했는데 작동하는 경우입니다. 엔드포인트가 사용자의 역할을 확인하지 않기 때문입니다.

관리자용 경로를 생각해 보십시오.

일반 사용자가 이 경로를 성공적으로 호출할 수 있다면 API가 역할 기반 접근을 적용하지 못한 것입니다.

일부 API는 요청 필드를 레코드에 무조건 매핑합니다.

사용자가 프로필 업데이트에 role=admin과 같은 필드를 추가하여 자신에게 부여된 권한을 조용히 높일 수 있습니다.

버튼이나 필드를 숨기는 일을 클라이언트에 절대 의존하지 마십시오.

공격자는 UI를 완전히 우회하여 요청을 직접 전송하므로, 모든 권한 부여 결정은 서버에서 적용해야 합니다.

순차적인 ID를 사용하면 BOLA를 쉽게 악용할 수 있습니다.

UUID와 같은 무작위 식별자를 사용해도 권한 부여 확인을 대신할 수는 없지만, 다음 숫자를 추측하는 단순한 공격은 막을 수 있습니다.

안전한 API는 기본적으로 거부합니다.

명시적인 규칙이 권한을 부여하는 경우에만 접근을 허용합니다. 이렇게 하면 확인을 빠뜨리더라도 데이터가 유출되지 않고 접근이 차단됩니다.

권한 부여 버그는 쉽게 숨겨지므로 의도적으로 테스트해야 합니다.

자신의 토큰으로 다른 사용자의 데이터에 접근해 보십시오. 접근이 된다면 즉시 수정해야 할 심각한 결함을 발견한 것입니다.

API가 사용자의 로그인 여부는 확인하지만 ID를 변경하면 다른 사용자의 레코드를 반환합니다. 이 결함은 무엇입니까?

권한 부여가 제대로 작동하지 않으면 사용자가 접근해서는 안 되는 대상에 접근할 수 있습니다. BOLA, BFLA, 대량 할당을 주의하십시오.

서버에서 소유권과 역할을 확인하고, 기본적으로 거부하며, 권한 부여를 의도적으로 테스트하십시오.