mysql uuid() 얼마나 활용 하시나요? 정보
mysql uuid() 얼마나 활용 하시나요?
본문
안녕하세요 즐거운 월요일 입니다.
보통 아래와 같이
mb_no = 1
데이터베이스 레코드를 수정 편집 할때에
auto increment 값을 활용 하는데
아주 편한 부분이면서 최적화 까지 되어 있지만
대부분의 보안 리포트에서 열심히 까이는 부분이 이 부분인데요
두가지를 병행해서 사용하면서
URL에 표출되는 부분만 uuid 같은 값으로 사용하려고 합니다.
PK를 전부 대체하기에는
비효율적인 부분이 너무 많아서 특정 부분만 사용하는게 효율적인데요
꼭 mysql에 uuid() 가 아니더라도
php의 uniqid() 함수도 있습니다.
추천
1
1
댓글 8개
그렇죠 오래전부터 거론되어왔는데...
저는 레코드가 많을때 검색속도가 빠를지 모르겠습니다.
여기에는 별로 추천하지 않는 글도 있네요.
https://stackoverflow.com/questions/2365132/uuid-performance-in-mysql/7578500#7578500
저는 레코드가 많을때 검색속도가 빠를지 모르겠습니다.
여기에는 별로 추천하지 않는 글도 있네요.
https://stackoverflow.com/questions/2365132/uuid-performance-in-mysql/7578500#7578500
@xpem 당연히 속도도 어마어마 하게 느려지면서 디스크 단편화 까지 불러올수 있습니다.
uuid를 활용하는것은 보안상 이점 이외에는 크게 이점이 없는것 같아요..ㅎㅎ
그래서 no 값은 기본으로 사용하고
보안레벨이 낮은 곳은 13자리 uniqid를 추가로 만들어서 사용하고
보안레벨이 높아야 할곳은 36자리 uuid를 만들어서 사용하는 방향으로 기획중입니다.
uuid를 활용하는것은 보안상 이점 이외에는 크게 이점이 없는것 같아요..ㅎㅎ
그래서 no 값은 기본으로 사용하고
보안레벨이 낮은 곳은 13자리 uniqid를 추가로 만들어서 사용하고
보안레벨이 높아야 할곳은 36자리 uuid를 만들어서 사용하는 방향으로 기획중입니다.
auto_increment를 안쓰고 uuid를 쓰면 보안상 얻는 이점은 뭔가요?
쓰면 왜 보안상 좋다는 건지 도무지 이해가 되지 않네요.
쓰면 왜 보안상 좋다는 건지 도무지 이해가 되지 않네요.
@gshn
예를 들어 회원번호로 데이터를 수정하는 인터페이스가 있는데
파라미터로 mb_no=1 을 키로 두면
공격자가 2,3,4,5,6 이렇게 시도를 해 볼수 있습니다.
물론 모든 부분에서 권한 검사를 하게 되겠지만
사람이 프로그래밍을 하는 이상 실수로 보안 검사등을 빼먹는 경우가 많이 생기죠
이런 오픈 보드에서는 항상 권한 검사를 하도록 업그레이드 되어 왔지만
새로운 솔루션이나 시스템을 만들때에는
프로그래머가 실수로 빼먹는 경우가 많다고 합니다.
이렇게 다음 파라미터 값을 쉽게 유추할 수 있는 부분은 보안상 취약 하다고 하네요^^
예를 들어 회원번호로 데이터를 수정하는 인터페이스가 있는데
파라미터로 mb_no=1 을 키로 두면
공격자가 2,3,4,5,6 이렇게 시도를 해 볼수 있습니다.
물론 모든 부분에서 권한 검사를 하게 되겠지만
사람이 프로그래밍을 하는 이상 실수로 보안 검사등을 빼먹는 경우가 많이 생기죠
이런 오픈 보드에서는 항상 권한 검사를 하도록 업그레이드 되어 왔지만
새로운 솔루션이나 시스템을 만들때에는
프로그래머가 실수로 빼먹는 경우가 많다고 합니다.
이렇게 다음 파라미터 값을 쉽게 유추할 수 있는 부분은 보안상 취약 하다고 하네요^^
@gshn 아주 예전에 진기한 현상을 목격 했었는데
SKT 휴대폰 요금 고지서의 GET 방식의 파라미터 키 값이 숫자로 되어 있길래
주소를 복사해서 숫자를 1증가시켜 보니 다른사람의 고지서가 딱 하니 나타나더라구요..
이런 보안상의 실수를 미연에 방지하기 위해서 사용합니다.
SKT 휴대폰 요금 고지서의 GET 방식의 파라미터 키 값이 숫자로 되어 있길래
주소를 복사해서 숫자를 1증가시켜 보니 다른사람의 고지서가 딱 하니 나타나더라구요..
이런 보안상의 실수를 미연에 방지하기 위해서 사용합니다.
아하 무슨 말씀인진 알겠습니다.
사실상 그건 어떤 취약점이나 보안을 떠나서 똥멍청이개발자의 실수 영역같은데 ㅋㅋ
그것 때문에 보안에 취약하다고 생각하는건 더욱 납득이 되지 않네요^^;;
세션 취득 없이 중요한 정보가 담긴 페이지를 GET으로 보여줘야 한다면 token 값을 어딘가에 저장해 놓고 token의 hash가 담긴 URL를 메일 등으로 전달해야하는 사람에게 전달 한 후 hash가 오면 저장해 둔 token의 hash와 verify해서 true이면 볼 수 있도록 하는 방법을 사용할거 같은데욥...
PK랑은 전혀 관계 없도록 말이죠.
믈론 똥싼너구리님의 의견이 아니라 한국인터넷진흥원 따위가 기계적으로 말하는 보안이겠지만요.
사실상 그건 어떤 취약점이나 보안을 떠나서 똥멍청이개발자의 실수 영역같은데 ㅋㅋ
그것 때문에 보안에 취약하다고 생각하는건 더욱 납득이 되지 않네요^^;;
세션 취득 없이 중요한 정보가 담긴 페이지를 GET으로 보여줘야 한다면 token 값을 어딘가에 저장해 놓고 token의 hash가 담긴 URL를 메일 등으로 전달해야하는 사람에게 전달 한 후 hash가 오면 저장해 둔 token의 hash와 verify해서 true이면 볼 수 있도록 하는 방법을 사용할거 같은데욥...
PK랑은 전혀 관계 없도록 말이죠.
믈론 똥싼너구리님의 의견이 아니라 한국인터넷진흥원 따위가 기계적으로 말하는 보안이겠지만요.
@gshn 모든 보안 가이드는 그런 "똥멍청이개발자"를 위한 가이드 라고 보시면 될거에요 ㅎㅎ
혼자서 모든 시스템을 개발하는것이 아니고 이런저런 개발자 손을 거치는 프로젝트의 경우는 특히 그런 문제를 항상 안고 있다고 생각이 드네요.. ㅋㅋ
혼자서 모든 시스템을 개발하는것이 아니고 이런저런 개발자 손을 거치는 프로젝트의 경우는 특히 그런 문제를 항상 안고 있다고 생각이 드네요.. ㅋㅋ
그러게요. wr_id로 다른 게시물을 url 로 접근해볼 수 있듯이 get으로 함부로 다른 사람의 것을 볼 수 없도록 하기 위해서 괜찮은 것 같습니다. 이메일로 검증을 위해 잠깐 유효한 URL링크를 보낼 때도 이런 긴 param 값을 넘기잖아요. pk로는 조금 피해야겠지만, 필요에 따라 잘쓰면 참 좋을 것 같아요 : )
