티스토리 뷰
OpenID와 관련해서 지난번 글 말미에 환상을 품을 만한 실험에 대해 얘기했습니다. 사실, 낚시성 멘트였구요. 환상 정도는 아니지만, 재밌는 실험입니다.
1.
스패머들이 자신의 주소를 숨기기 위해 야후를 사용했던 방식을 이용한 방식으로 신뢰하는 도메인을 야후로 만들어 보겠습니다.
2.
지난 글에서 단일 사용자 로그인을 수행하는 OpenID의 질문중에 세번째로 인증 정보를 전달할 도메인을 확인하는 과정이 있다고 하였습니다. 인증정보를 확인하기 위한 질문까지 가기위해서 로그인사이트(이하 RP; Relying Party;Consumer site)에서는 OpenID를 접수 받고서, OpenID의 발급자(이하 IdP; ID Provider)에게 페이지를 리다이렉트합니다. 대개 사용하시는 분들은, 아이디는 로그인사이트에 넣지만, 비밀번호는 항상 발급자 홈페이지에 넣기 때문에 안심(?)스러운 광경을 연출되는 것을 보게 됩니다.
물론, 연출만이 아니라 모든 인증이 끝난 뒤에도, 실제로 비밀번호는 RP 사이트에 전달되지 않기 때문에 안심이죠.
3.
이렇게 비밀번호를 확인하고 마지막 단계로, RP 사이트에 대한 "신뢰하는 root url"을 보여주게 되고, 이 사이트가 정말 당신이 로그인하고 있는 사이트가 맞는지 확인하는 작업을 수행합니다. 사이트를 1회만 승인하던, 계속 승인하던간에 IdP에서는 RP로 다시 리다이렉트를 하게 됩니다. 이것은 처음 IdP로 건너 올 때, 되돌아갈 위치를 return_to라는 변수에 실어왔기 때문에 가능한 것입니다.
만약, 많은 사람들이 현재 사용하는 me2day나 스프링노트를 항상 승인하도록 설정해둔다면, 사이트에서 오픈아이디를 도입하고자 하는 개발자가 신뢰하는 root url을 me2day 로 해 놓고, 승인 시도를 하게된다면, 마지막 단계없이 로그인 할 수 있지 않겠습니까? 그러나, 이 경우에는 return_to의 url과 신뢰하는 root가 다른 hostname을 갖게 됩니다. 이에 대한 간단한 내용이 사양서의 노트에 기록되어 있지요.
4.
서문이 너무 길었군요. 다시 처음에 언급한 야후를 이용하여 송신지를 숨기는 스패머들 얘기를 꺼내 보겠습니다. 야후에서 검색을 하고 난 결과 목록에서 원하는 링크를 누르면, 항상 다시 야후로 간다음 목적지로 리다이렉트 됩니다. 편의상 이것을 YR-Hack(Yahoo redirection hack) 이라고 합시다. 아마도, 이 YR핵은 통계를 내거나 클릭 기반의 데이터를 쌓아서 다음 결과에 반영하려고 그런것인지는 잘 모르겠습니다만, 다음과 같은 테스트를 해볼 수 있습니다.
5.
그럼 신뢰하는 root url을 rds.yahoo.com 혹은 *.yahoo.com 으로 한다면, 야후로 승인받고, 제 홈에 올 수 있다는 얘기 아닙니까. 예를 들면,
자,자, 무슨 얘기인지 차근차근 따져봅시다. YR 핵의 핵심은 rds.yahoo.com 서버가 하는 일은 단지 "*-" 뒤에 있는 페이지로 redirection한다는 것이고, 이 서비스를 이용하면, trust 경로를 yahoo로 할 수 있다는 것인데. 일반적으로 사이트에서 오픈아이디를 지원하려면, 굳이 야후로 할 이유가 없습니다. 그러나, 악의적으로 사이트를 개설하고, 오픈아이디를 로그인 하도록 만들어 놓았는데, 신뢰하는 사이트가 야후로 보인다면? 자신의 신상 정보를 쉽사리 줄 수가 있겠지요. 보안에 취약해지는 부분입니다. 물론, 이런 YR 핵을 이용하여 만든 것들이 얼마나 퍼질지는 모르겠습니다.
6.
자, 환상은 무엇이고 재미는 무엇이란 말입니까?
환상은 분산환경에서 단일 사용자 로그인(SSO)을 구현해 봄직한 구멍이 보인다는 것입니다.지난 글과 서두에 언급한 세번째 질문을 처음가는 사이트라 할 지라도 비슷한 사이트에서 승인처리를 해놓았다면 야후라는 이름으로 승인될 수 있다는 것입니다.
재미는 무엇입니까? 야후 기록만 살펴봐도 어디에 누가 깔려 얼마나 많은 사용자가 로그인하고 있는지 알 수 있다는 것입니다. 분산환경에서 집중화된 로그인 기록!
자, 우리 대화를 YR 핵 대신 서비스를 만드는 사람이 중앙에서 리다이렉션해주는, 이런 비슷한 처리하는 서버를 두는 것으로 바꾸고 생각해봅시다.
환상과 재미가 취약한 보안(?)과 함께 느껴지시나요?
기회가 되면 적용할만한 꺼리와 보안을 고려하여 좀 익은다음 뒷 얘기를 더 해보겠습니다.
1.
스패머들이 자신의 주소를 숨기기 위해 야후를 사용했던 방식을 이용한 방식으로 신뢰하는 도메인을 야후로 만들어 보겠습니다.
2.
지난 글에서 단일 사용자 로그인을 수행하는 OpenID의 질문중에 세번째로 인증 정보를 전달할 도메인을 확인하는 과정이 있다고 하였습니다. 인증정보를 확인하기 위한 질문까지 가기위해서 로그인사이트(이하 RP; Relying Party;Consumer site)에서는 OpenID를 접수 받고서, OpenID의 발급자(이하 IdP; ID Provider)에게 페이지를 리다이렉트합니다. 대개 사용하시는 분들은, 아이디는 로그인사이트에 넣지만, 비밀번호는 항상 발급자 홈페이지에 넣기 때문에 안심(?)스러운 광경을 연출되는 것을 보게 됩니다.
물론, 연출만이 아니라 모든 인증이 끝난 뒤에도, 실제로 비밀번호는 RP 사이트에 전달되지 않기 때문에 안심이죠.
3.
이렇게 비밀번호를 확인하고 마지막 단계로, RP 사이트에 대한 "신뢰하는 root url"을 보여주게 되고, 이 사이트가 정말 당신이 로그인하고 있는 사이트가 맞는지 확인하는 작업을 수행합니다. 사이트를 1회만 승인하던, 계속 승인하던간에 IdP에서는 RP로 다시 리다이렉트를 하게 됩니다. 이것은 처음 IdP로 건너 올 때, 되돌아갈 위치를 return_to라는 변수에 실어왔기 때문에 가능한 것입니다.
만약, 많은 사람들이 현재 사용하는 me2day나 스프링노트를 항상 승인하도록 설정해둔다면, 사이트에서 오픈아이디를 도입하고자 하는 개발자가 신뢰하는 root url을 me2day 로 해 놓고, 승인 시도를 하게된다면, 마지막 단계없이 로그인 할 수 있지 않겠습니까? 그러나, 이 경우에는 return_to의 url과 신뢰하는 root가 다른 hostname을 갖게 됩니다. 이에 대한 간단한 내용이 사양서의 노트에 기록되어 있지요.
The openid.return_to URL MUST descend from the openid.trust_root, or the Identity Provider SHOULD return an error. Namely, the URL scheme and port MUST match.즉, 최종적으로 신뢰한 사이트를 돌려 받을 주소(return_to)는 반드시 trust_root로 부터 만들어져야하는 것입니다. 예를 들어,
trust_root=http://www.me2day.net&return_to=http://myservice.org/openid/finish와 같은 방법으로 앞뒤를 다르게 서비스를 개설할 수 없다는 것입니다.
4.
서문이 너무 길었군요. 다시 처음에 언급한 야후를 이용하여 송신지를 숨기는 스패머들 얘기를 꺼내 보겠습니다. 야후에서 검색을 하고 난 결과 목록에서 원하는 링크를 누르면, 항상 다시 야후로 간다음 목적지로 리다이렉트 됩니다. 편의상 이것을 YR-Hack(Yahoo redirection hack) 이라고 합시다. 아마도, 이 YR핵은 통계를 내거나 클릭 기반의 데이터를 쌓아서 다음 결과에 반영하려고 그런것인지는 잘 모르겠습니다만, 다음과 같은 테스트를 해볼 수 있습니다.
http://rds.yahoo.com/*-http://coolengineer.com/위와 같이 야후를 이용하여 제 홈에 오는 방법이 가능합니다. 아차!
5.
그럼 신뢰하는 root url을 rds.yahoo.com 혹은 *.yahoo.com 으로 한다면, 야후로 승인받고, 제 홈에 올 수 있다는 얘기 아닙니까. 예를 들면,
trust_root=http://*.yahoo.com/&return_to=http://rds.yahoo.com/*-http://myservice.org/openid/finish와 같은 형식으로 하면, trust domain을 yahoo로 하고 return_to 에 씌여지는 url이 정상적으로 동작하는 것이라면, 그 앞에 http://rds.yahoo.com/*- 을 붙여주면, myservice.org 서비스에 로그인이 가능하게 됩니다.
자,자, 무슨 얘기인지 차근차근 따져봅시다. YR 핵의 핵심은 rds.yahoo.com 서버가 하는 일은 단지 "*-" 뒤에 있는 페이지로 redirection한다는 것이고, 이 서비스를 이용하면, trust 경로를 yahoo로 할 수 있다는 것인데. 일반적으로 사이트에서 오픈아이디를 지원하려면, 굳이 야후로 할 이유가 없습니다. 그러나, 악의적으로 사이트를 개설하고, 오픈아이디를 로그인 하도록 만들어 놓았는데, 신뢰하는 사이트가 야후로 보인다면? 자신의 신상 정보를 쉽사리 줄 수가 있겠지요. 보안에 취약해지는 부분입니다. 물론, 이런 YR 핵을 이용하여 만든 것들이 얼마나 퍼질지는 모르겠습니다.
6.
자, 환상은 무엇이고 재미는 무엇이란 말입니까?
환상은 분산환경에서 단일 사용자 로그인(SSO)을 구현해 봄직한 구멍이 보인다는 것입니다.지난 글과 서두에 언급한 세번째 질문을 처음가는 사이트라 할 지라도 비슷한 사이트에서 승인처리를 해놓았다면 야후라는 이름으로 승인될 수 있다는 것입니다.
재미는 무엇입니까? 야후 기록만 살펴봐도 어디에 누가 깔려 얼마나 많은 사용자가 로그인하고 있는지 알 수 있다는 것입니다. 분산환경에서 집중화된 로그인 기록!
자, 우리 대화를 YR 핵 대신 서비스를 만드는 사람이 중앙에서 리다이렉션해주는, 이런 비슷한 처리하는 서버를 두는 것으로 바꾸고 생각해봅시다.
환상과 재미가 취약한 보안(?)과 함께 느껴지시나요?
기회가 되면 적용할만한 꺼리와 보안을 고려하여 좀 익은다음 뒷 얘기를 더 해보겠습니다.
반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- TCP/IP
- OpenID
- url
- 킹벤자민
- SSO
- 구근
- VIM
- Subversion
- 대화
- BlogAPI
- nodejs
- ssh
- writely
- 덴드롱
- tattertools
- Tattertools plugin
- 오픈소스
- SVN
- JavaScript
- 수선화
- 디버깅
- perl
- 클레로덴드럼
- MySQL
- Linux
- 커피
- 벤자민
- 식물
- macosx
- 퀴즈
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
글 보관함