웹 응용 프로그램의 HTML 코드에서 데이터베이스 ID를 직접 사용해서는 안된다는 말을 듣고 있습니다.사용자로부터 데이터베이스 ID를 난독 처리해야합니까?
현재 테이블 행 ID (tableRow-454는 DB의 행 ID입니다), 숨김 또는 양식 또는 URL의 필드를 선택하는 것과 같은 것에 ID를 사용합니다. (저는 사람들이 페이지에 사람들이 ####이라는 것을 시각적으로 말하는 것을 언급하지 않습니다.)
내가 제안한 권고는 사용자로부터 ID를 난독 화하기 위해 몇 가지 수학을 사용하는 것이 었습니다. 나는 이것이 단지 복잡한 일을 만들고 불필요한 복잡성을 추가 할 것이라고 생각하고 있습니다. 그러나 HTML에서 데이터베이스 ID를 판별하기가 더 어려워지는 몇 가지 좋은 이유가 있습니다.
사용자의 ID를 혼란스럽게합니까? 아니면 신경 안쓰니?
아니요, 스스로 추가 작업을하고 계십니다.
여기에서 ID를 변경하면 사용자가 무언가에 액세스 할 수 없다는 충분한 테스트를하고있는 한 ID를 표시하는 것이 좋습니다.
일부 상황에서는 숨기거나 비 연속 숫자가 있거나 0부터 세지 않을 수도 있습니다. 예를 들어 누군가 3 번 주문 번호를 얻은 경우 질문을 시작할 수 있습니다 ...
네, 그래야합니다.
사용자가 이러한 ID를 악의적으로 변경하는 경우 요청한 데이터가 여전히 볼 수있는 데이터인지 확인합니다.
ID를 숨기려면 수동으로 유효성 검사를 수동으로 수행하는 것보다 쉽습니다. 이 시간 선명하게
편집 : 당신이 화면에 목록을 표시하는 경우
ID의 1에-20는 응답이 1과 20 사이임을 확인하는 것은 매우 쉽습니다. 실제 ID를 화면에 표시하는 경우 ID 캐싱 메모리를 사용해야하거나 잘못된 데이터를 제공하지 않도록 다른 데이터베이스 호출/긴 쿼리를 만들어야합니다.
대리 ID를 사용하면이 작업이 쉬워집니다.
앱을 안전하게 만들기 위해 "장소 전체에서"인증 할 필요가 없습니다. 서버의 데이터를 먼저 확인하는 경우 사용자가 ID를 변경하더라도 문제가되지 않습니다. – David
"예"동의하지만 서버가 이미 맹목적으로 ID를 받으면 이미 손상되었습니다. 고 말했다. –
사용자가 아무 것도 변경하지 못하게하려면 브라우저를 사용하지 마십시오. 다른 말로하면 ** 클라이언트를 신뢰하지 않는 ** ** ID를 난처하게하면 아무 것도 변경되지 않습니다. –
데이터 내부에 대해 이야기하는 내용은 사용자에게 공개하지 않지만 대개의 경우 항상 발생합니다. 데이터 소스를 기반으로 드롭 다운을 만드는 방법에 대해 설명합니다. 내 솔루션은 증분 공격을 제거하고 가능한 경우 쿼리 문자열 값을 암호화하기 위해 테이블에 다른 ID 사양을 지정하는 것입니다. NET에서 매우 인기있는 MVC URL 패턴이 주어 지므로 항상 가능한 것은 아닙니다. 따라서 고유 한 열 이름을 사용하여 URL에 대해 정규화하는 경향이 있습니다. 그런 다음 데이터베이스에서 해당 값을 조회합니다. 그러나 그것을 완전히 해결하는 쉬운 방법은 없습니다.
ID가 사용자에게 의미가 있고 데이터 민감한 응용 프로그램을 다루는 경우 ID 값을 숨겨야한다고 말하고 싶습니다. 더 중요한 것은 현재 사용자가 URL을 통해 요청하는 데이터에 액세스 할 수 있는지 확인하는 것입니다. 예를 들어 mysite.com/account/view/12와 같은 URL이있는 경우 현재 사용자는 해당 계정 ID (예 : 12)에 액세스 할 수 있습니다.
정보가 공개이고 민감하지 않은 경우 ID 값을 숨길 필요가 없다고 말합니다.
당신은 사용자
왜에서 데이터베이스 ID를 숨길해야합니까? 사용자 (사용자)가 염려 할 필요가없는 구현 세부 사항입니다. ID 123311122입니까? 누가 신경 써! (단, ICQ를 사용하지 않는 한). 예를 들어 SO가 노출을 최소화하는 방법을 보여줍니다 (그러나 제거하지는 않습니다).
2 차 메모에서 예측 가능한 ID를 사용하는 것은 공격의 또 다른 공격 벡터 인 반면 모호함에 의한 보안이지만 다른 유용한 도구입니다. 나는 이것이 비록 걱정거리 인 소프트웨어에서 일한 적이 없다.
당신의 프레임 워크가 "숨겨진 ID"를 처리하거나 깨끗한 매핑을 제공하는 수단을 제공하지 않는다면 전환 할 가치가 없을 수도 있습니다.
나는 일반적으로는 OK라고 말할 것입니다,하지만 일부 망 가지고있다 :
당신의 번호가 순차적 경우에 '추측 게임'(예를 들어, 사용자가 세부 사항을 변경 ID = 4511 열은? 세부 사항까지? 누군가 다른 사람의 세부 사항을보기 위하여 id = 4512). 이것을 막으려면 적절한 보안이 필요합니다. 정보가 존재한다는 사실 자체가 문제가 될 수 있기 때문에 어떤 경우에는 이것이 충분하지 않을 수도 있습니다. 예를 들어 Youtube를 사용하면 로봇 화면 긁힘을 방지하기 위해 더 많은 ID를 사용합니다.
id의 본질에 대해 가정하면 : 문제가 생길 수 있습니다 (예 : id : s를 GUI에서 직접 조작하거나 id를 기반으로 항목을 정렬하는 경우). DB를로드 밸런싱하고 개별 ID 범위로 끝내야하는 경우 이것은 놀랄 일이 아닙니다.
ID 재사용. 예를 들어, MySql : InnoDB 엔진은 재시작시 시퀀스를 리셋합니다 (최신 최대 값까지). 삭제를하면 열심히 물지 수 있습니다.
그러나 이러한 모든 문제는 맞춤 ID에도 적용되지만,이 사람들이 어디에서 왔는지는 알 수 있습니다. 내 눈에서 볼 수있는 가장 융통성있는 솔루션은 GUID : s입니다. 왜냐하면 여러분은 어디에서나 생성 할 수 있고 위에서 언급 한 문제 중 하나에 부딪치지 않기 때문입니다. 그들은 인간을 위해 읽기가 더 어렵 기 때문에 절충점입니다.
친숙한 이름을 사용하는 것이 좋습니다. 그것은 현대적이고 의미 론적입니다. 또한 링크를 만들 때 모양이 더 좋아 보입니다.
예를 들어 mysite/products.aspx? id = 25와 mysite/products/ferrari를 비교해보십시오. 후자는 더 깨끗하고 기억하기 쉽습니다 (사용자 용).
현재 숨겨진 필드에 ID를 사용하는 경우 세션을 사용하여 해당 값을 저장하십시오. 언급 한 테이블 행 ID에서만 사용하는 경우에는 숨길 가치가 있다고 생각하지 않습니다.
2 가지 : 깔끔한 URL을 사용하면 대용량의 제품 (예 :)이있을 때 실패합니다. 질문 제목이 고유하지 않으므로 SO와 같은 것이 비참하게 실패하게됩니다. 따라서 질문 제목과 함께 ID가 포함되었습니다. 세션에서 ID를 저장하는 것과 관련된 문제는 다음과 같습니다. 탭 :( –
그래, 그 점에 대해 동의해야합니다. 작은 사이트의 경우 제목이 고유 한 것이므로 매우 효과적 일 수 있습니다. 잘. – Venemo
IMO : 아니요, ID를 난처하게해서는 안됩니다. 보안이 응용 프로그램의 관심사 인 경우 어쨌든 다른 보안 조치가 필요합니다. 모호함으로 인한 보안만으로는 충분하지 않으며 보안에 대한 잘못된 인식을 제공합니다.
아직 작은 수학 만 수행하면 다른 ID (흐릿하게 보임)가 여전히 예측 가능하다는 가능성이 있습니다. 대부분의 경우 악의적 인 사용자는 사용자가 길을 걸을 수있게하려는 경우 자신이 아닌 한 자신이 속한 계정을 신경 쓰지 않습니다 .-)
ID:s in URI:s are a part of a good UI어쨌든 모든 URI는 공개적입니다. 요청을 처리하고 일종의 인증에 기반하여 렌더링하는 것은 응답 페이지에 달려 있습니다.
거래 및 다른 민감한 물질은 쉽게 소금 + 해시 문자열로 숨겨 당신이 원한다면 데이터베이스에 다른 열 저장,하지만 여전히 있다면 사용자 입력을 (검증 할 수 없습니다 할 수있는 명확하게 웹 프로그래밍 URI를 통해 탐색 할 수 있음) 당신은 요점을 놓치고 있습니다.
Greg answered으로, 주문 번호는 아마 저 안하지만, 정보 처리의 종류의 책임은 웹 페이지 내에서하지만 조직의/당신 명시된 값 내에 있지해야한다 (즉, 당신은 여전히 밖으로 인쇄 할 것이다 서면 영수증의 주문 번호는 무엇입니까?)
웹이 오늘날과 같이 투명 함으로 인해 익숙하지 않은 다른 용도로 사용할 수 있습니다. URI : s, 즉 Youtube의 비디오 페이지와 수많은 URI 단축 서비스가 있습니다.
공개 ID를 "게시"하는 예로이 게시물의 URL을보십시오.
나는 https://stackoverflow.com/questions/1을 시도했지만 삭제 된 것처럼 보입니다. "첫 번째"서수 문제를 찾으려면 While applying opacity to a form should we use a decimal or double value?으로 가야합니다.)
... 아무런 해를 입지 않고 다른 게시물을 참조하기 만하면됩니다.
"웹 응용 프로그램의 HTML 코드에서 직접 데이터베이스 ID를 사용하지 않아야한다고 들었습니다. ... 사용자의 ID를 혼란스럽게합니까?"
사용자는 자신이 작업하고있는 현실 세계에 연결할 수있는 데이터에 직면 할 것으로 예상됩니다.
"데이터베이스 ID"는 해당 ID가 실제 작업 환경의 일부이기도 한 경우에만 사용자 인터페이스의 일부 여야합니다. 그렇지 않으면 응용 프로그램이 실제로 해당 필드에서 사용자를 보호해야합니다.
실딩은 실제로 "더 많은 작업"에 해당하지만, 이는 완전히 부적절합니다. 차폐를하지 않으면 사용자에게 처리하기가 더 어려워지는 응용 프로그램을 제공하게되어 최종적으로 사용자가 매일 더 많은 작업을 수행하게됩니다.
숨겨진 필드에서 행 ID를 변조하지 않기로 결정한 경우 Steve Sanderson의 asp.net mvc 책 415 페이지를 참조하여 HMAC (해싱 메시지 인증 코드) 유틸리티 클래스를 제공 할 수 있습니다. .NET은 물론이지만 아이디어를 얻을 수 있습니다. Google 도서에서 볼 수 있습니다 (Sanderson은 내가 읽은 최고의 프로그래밍 책에 대해 작성했습니다).
html로 행 ID를 넣을 때 사업 모델에 따르면 사용자가 삽입 한 행과 같은 특정 행 집합에 대한 액세스 권한이 있어야한다고 가정하면 사용자 ID 열을 포함하도록 db 테이블을 설계 할 수 있습니다 그리고 임의의 db 조작 (의사 코드 : @rowID = table.rowID 및 @userID = table.userID)에 포함 시키십시오. 이렇게하면 다른 사용자가 숨겨진 필드에서 rowID를 해킹하면 사용자 ID가 일치하지 않기 때문에 db 작업에서 다른 사용자의 데이터를 볼 수 없게됩니다. 물론이 접근법은 사용자가 일종의 인증을 사용하고 있으며 해킹 당하지 않았다고 가정합니다.
나는 두 가지 응답 중 어느 것이 더 많은 견인력을 얻는 지 궁금하다. –
그래, 재미있을거야 – Greg
+1. 또한 순차적 ID에 대해 걱정할 경우 항상 GUID를 대신 사용할 수 있습니다. – David