데이터베이스 ID 노출-보안 위험?

URL 등의 데이터베이스 ID를 노출하는 것이 보안 위험이라고 들었지만 그 이유를 이해하는 데 어려움을 겪고 있습니다.

왜 위험하거나 왜 그렇지 않은지에 대한 의견이나 링크가 있습니까?

편집 : 물론 액세스 범위가 지정됩니다. 예를 들어 리소스 foo?id=123를 볼 수 없으면 오류 페이지가 표시됩니다. 그렇지 않으면 URL 자체가 비밀이어야합니다.

편집 : URL이 비밀 인 경우 수명이 제한되어 생성 된 토큰 (예 : 1 시간 동안 유효하며 한 번만 사용할 수 있음)이 포함됩니다.

편집 (몇 달 후) : 현재 선호되는 방법은 ID에 UUIDS를 사용하여 노출시키는 것입니다. 일련 번호 (일반적으로 일부 DB의 성능을 위해)를 ID로 사용하는 경우 각 항목에 대해 UUID 토큰을 대체 키로 생성하고 공개하는 것이 좋습니다.

적절한 조건이 주어지면 식별자를 노출하는 것이 보안 위험이 아닙니다. 그리고 실제로는 식별자를 노출시키지 않고 웹 응용 프로그램을 설계하는 것은 매우 부담이됩니다.

준수해야 할 몇 가지 규칙은 다음과 같습니다.

1. 역할 기반 보안을 사용하여 작업에 대한 액세스를 제어하십시오. 이 작업을 수행하는 방법은 선택한 플랫폼 및 프레임 워크에 따라 다르지만, 대부분의 경우 작업에 일부 권한이 필요한 경우 브라우저를 인증 단계로 자동 리디렉션하는 선언적 보안 모델을 지원합니다.
2. 프로그래밍 방식의 보안을 사용하여 개체에 대한 액세스를 제어하십시오. 프레임 워크 수준에서 수행하기가 더 어렵습니다. 더 자주, 그것은 당신이 당신의 코드에 작성 해야하는 것이므로 오류가 발생하기 쉽습니다. 이 검사는 사용자에게 작업에 대한 권한이있을뿐 아니라 수정중인 특정 개체에 대한 필요한 권한이 있는지 확인함으로써 역할 기반 검사를 넘어서게됩니다. 역할 기반 시스템에서는 관리자 만 인상을 줄 수 있는지 쉽게 확인할 수 있지만 그 이상으로 직원이 특정 관리자 부서에 속해 있는지 확인해야합니다.
3. 대부분의 데이터베이스 레코드에는 조건 1과 2로 충분합니다. 그러나 예측할 수없는 ID를 추가하는 것은 약간의 추가 보험 또는 "심층 보안"으로 생각할 수 있습니다. 그러나 예측할 수없는 식별자가 필요한 한 곳은 세션 ID 또는 다른 인증 토큰으로, ID 자체는 요청을 인증합니다. 이들은 암호화 RNG에 의해 생성되어야합니다.

데이터 보안 위험은 아니지만 데이터 크기와 속도를 모두 노출하므로 비즈니스 인텔리전스 보안 위험입니다. 나는 비즈니스가 이것에 의해 피해를 입는 것을 보았고이 반 패턴에 대해 깊이 글을 썼습니다. 실험이 아닌 사업이 아니라면 개인 신분을 공개하지 않는 것이 좋습니다. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

ID의 의미에 따라 다릅니다.

경쟁상의 이유로 회원 수를 공개하고 싶지 않지만 순차적 ID를 사용하면 URL에 http://some.domain.name/user?id=3933이 표시됩니다.

반면에 사용자의 로그인 이름을 대신 사용하는 경우 : http://some.domain.name/user?id=some 사용자가 아직 모르는 내용을 공개하지 않은 것입니다.

일반적인 생각은 다음과 같습니다. "앱의 내부 작동에 대한 정보를 다른 사람에게 공개하지 마십시오."

데이터베이스 ID를 노출하면 일부 정보를 공개하는 것으로 간주됩니다.

그 이유는 해커가 앱 내부 작업에 대한 정보를 사용하여 공격하거나 사용자가 보지 않을 데이터베이스에 들어가도록 URL을 변경할 수 있기 때문입니다.

데이터베이스 ID에는 GUID를 사용합니다. 그것들을 새기는 것은 훨씬 덜 위험합니다.

db에서 정수 ID를 사용하는 경우 qs 변수를 변경하여 사용자가 원하지 않는 데이터를 쉽게 볼 수 있습니다.

예를 들어 사용자는이 qs에서 id 매개 변수를 쉽게 변경하고 http : // someurl? id = 1 해서는 안되는 데이터를 보거나 수정할 수 있습니다

데이터베이스 ID를 클라이언트에 보내면 강제로 두 경우 모두 보안을 확인 합니다. 웹 세션에서 ID를 유지하는 경우 원하는 것을 원할 것인지 선택할 수 있습니다. 이는 잠재적으로 처리량이 적다는 것을 의미합니다.

이는), 당신은 지속적으로 액세스 제어에 일을 위임하려고 할 수 있습니다 응용 프로그램의 경우가하지만 내 전체 경력에 같은 일관된 백엔드 시스템을 본 적이 없다. 대부분은 웹 이외의 용도로 설계된 보안 모델을 가지고 있으며 일부는 사후에 추가 역할을 추가했으며 일부는 핵심 보안 모델 외부에 볼트로 고정되어 있습니다 (역할이 다른 운영 컨텍스트에 추가 되었기 때문에). 웹 전에).

따라서 우리는 합성 세션 로컬 ID를 사용합니다.

정수가 아닌 키 필드의 문제도 있으며, 이는 열거 된 값과 유사한 경우 일 수 있습니다. 해당 데이터를 삭제하려고 시도 할 수 있지만 작은 바비 드롭 테이블 처럼 될 가능성이 있습니다 .