링크에 접근 제어가 없는 것이 기본적인 문제로, 공개적인 인덱스가 없기 때문에 사적이라고 가정된다. AWS 계정 ID를 버킷을 통해 발견하는 것과 관련된 이야기가 해커뉴스에서 인기를 끌었는데, 댓글에서 도출된 합의는 계정 식별자의 비공개성을 보안의 일부로 의존하는 것이 잘못된 접근이라는 것이다. 이는 단순히 또 다른 'dorking' 방법일 뿐이다.
링크의 비공개성: 링크가 공개적으로 인덱싱되지 않는다는 이유로 사적이라고 가정하는 것은 문제가 있음. AWS 계정 ID의 비공개성에 의존하는 것은 보안상 올바르지 않은 접근이며, 이는 새로운 보안 이슈가 아니라 'dorking'의 한 형태임.
개인적으로 공유 가능한 링크를 생성하려면 URL의 해시 부분에 비밀 정보를 저장해야 한다. 해시는 DNS 쿼리나 HTTP 요청에 포함되지 않는다. 예를 들어, links.com#<secret> 형식의 링크는 브라우저를 벗어나지 않는다. 해시 부분의 데이터를 URL 안전 Base64 문자열로 인코딩하는 것이 좋다.
링크의 안전한 공유: URL의 해시 부분에 비밀 정보를 저장하여 링크를 안전하게 공유할 수 있음. 이 방법은 해시가 DNS 쿼리나 HTTP 요청에 포함되지 않기 때문에 더 안전함.
무한 사용이 가능한 "사적인" 링크에 대해 항상 의심스러웠다. 이것은 단지 오브스큐리티를 통한 보안이다. 구글 문서와 같이 "URL을 가진 사람이라면 누구나 접근할 수 있다"는 명시적인 옵션이 있는 경우가 더 낫다. 필자가 구축한 시스템에서는 짧은 수명을 가진 서명된 URL을 사용하며, 이 URL은 사용자에게 직접 보여지지 않는다.
사적인 링크에 대한 의구심: "사적인" 링크가 실제로는 오브스큐리티를 통한 보안에 불과하며, 짧은 수명을 가진 서명된 URL을 사용하는 것이 더 안전한 방법임.
빠른 리다이렉트 루프의 일부가 아닌 링크는 복사되어 공유될 것이다. URL은 보편적이며, 프로토콜 상의 자원에 접근을 용이하게 한다. 짧지 않은 수명을 가진 모든 것에 대한 접근 제어는 URL 외부에서 이루어져야 한다. e2ee가 아닌 채널에서 링크를 공유할 때, URL에 처음 접근하는 주체는 전송 대상자가 아니라 채널의 서비스일 수 있다. 이러한 스캐너 도구는 사용자에게 스캔이 공개적임을 명시하면 UX가 개선되지 않을 것이다.
URL을 통한 접근 제어: URL은 자원에 대한 접근을 용이하게 하기 위해 공유되며, 접근 제어는 URL이 아닌 다른 방법으로 이루어져야 함. 스캐너와 같은 도구는 사용자에게 공개적인 스캔을 알리면 사용자가 서비스 사용을 망설일 수 있으므로 UX 개선에 도움이 되지 않음.
"이메일 기반 인증" 문제에 대한 해결책은 계정과 비밀번호를 만드는 단계 없이, URL이 실수로 공유되더라도 문제가 되지 않는 일회용 코드를 사용하는 것이다. 사용자가 "사적인" 링크를 방문하면, 사이트는 시간 제한이 있는 일회용 코드를 이메일로 다시 보내고, 사용자는 이메일 소유를 확인하기 위해 임시 코드를 입력한다.
이메일 인증과 일회용 코드: 이메일 기반 인증 문제를 해결하기 위해 일회용 코드를 사용하며, 이는 URL이 실수로 공유되어도 문제가 되지 않음.
인터넷에서 URL에 무작위 문자열 이상의 보호가 없다면 그것들은 사실상 사적이지 않다. 인터넷에 연결된 웹캠을 찾는 것과 같은 이야기다. 우리는 이미 이를 알고 있어야 한다. "누가 책임져야 하는가" 섹션에서 이를 언급하지 않는 이유는 무엇인가?
URL의 사적인 성격: URL에 무작위 문자열 이상의 보호가 없으면 사적이지 않으며, 이는 이미 알려진 사실임.
주제에서 벗어난 이야기이지만, Cloudflare Radar가 1.1.1.1에서 데이터를 채굴한다는 링크가 있다. 1.1.1.1이 사용자 데이터를 어떠한 목적으로도 사용하지 않는다고 생각했는데?
Cloudflare Radar와 1.1.1.1: Cloudflare Radar가 1.1.1.1에서 데이터를 채굴한다는 주장이 있으며, 이는 1.1.1.1이 사용자 데이터를 사용하지 않는다는 기존의 인상과 상충함.
Zoom 회의 링크는 종종 쿼리 매개변수로 비밀번호를 추가한다. 이 링크가 "사적이고 안전한" 링크인가? 비밀번호 없이는 "사적이고 안전한" 링크인가?
Zoom 회의 링크의 안전성: Zoom 회의 링크에 비밀번호가 포함되어 있을 때와 없을 때의 안전성에 대한 질문.
다음 두 가지 사례 중 어느 것이 더 안전한지 설명해 줄 수 있는가?
domain.com/login 사용자: John 비밀번호: 5자리 무작위 비밀번호
domain.com/12자리 무작위 URL
두 경우 모두 같은 무작위/속도 제한 보호를 가정하거나 전혀 없다고 할 때, 왜 1번이 2번보다 더 안전한가?
로그인 안전성 비교: 두 가지 다른 로그인 방식의 안전성 비교에 대한 질문.
private airtable.com 앱에 업로드된 모든 미디어/사진은 공개 링크로, URL을 알고 있으면 인증 없이 접근할 수 있다.
Airtable.com의 공개 링크: Airtable.com에 업로드된 미디어/사진은 공개 링크로, URL만 알면 누구나 접근할 수 있음.
Hacker News 의견
링크에 접근 제어가 없는 것이 기본적인 문제로, 공개적인 인덱스가 없기 때문에 사적이라고 가정된다. AWS 계정 ID를 버킷을 통해 발견하는 것과 관련된 이야기가 해커뉴스에서 인기를 끌었는데, 댓글에서 도출된 합의는 계정 식별자의 비공개성을 보안의 일부로 의존하는 것이 잘못된 접근이라는 것이다. 이는 단순히 또 다른 'dorking' 방법일 뿐이다.
개인적으로 공유 가능한 링크를 생성하려면 URL의 해시 부분에 비밀 정보를 저장해야 한다. 해시는 DNS 쿼리나 HTTP 요청에 포함되지 않는다. 예를 들어, links.com#<secret> 형식의 링크는 브라우저를 벗어나지 않는다. 해시 부분의 데이터를 URL 안전 Base64 문자열로 인코딩하는 것이 좋다.
무한 사용이 가능한 "사적인" 링크에 대해 항상 의심스러웠다. 이것은 단지 오브스큐리티를 통한 보안이다. 구글 문서와 같이 "URL을 가진 사람이라면 누구나 접근할 수 있다"는 명시적인 옵션이 있는 경우가 더 낫다. 필자가 구축한 시스템에서는 짧은 수명을 가진 서명된 URL을 사용하며, 이 URL은 사용자에게 직접 보여지지 않는다.
빠른 리다이렉트 루프의 일부가 아닌 링크는 복사되어 공유될 것이다. URL은 보편적이며, 프로토콜 상의 자원에 접근을 용이하게 한다. 짧지 않은 수명을 가진 모든 것에 대한 접근 제어는 URL 외부에서 이루어져야 한다. e2ee가 아닌 채널에서 링크를 공유할 때, URL에 처음 접근하는 주체는 전송 대상자가 아니라 채널의 서비스일 수 있다. 이러한 스캐너 도구는 사용자에게 스캔이 공개적임을 명시하면 UX가 개선되지 않을 것이다.
"이메일 기반 인증" 문제에 대한 해결책은 계정과 비밀번호를 만드는 단계 없이, URL이 실수로 공유되더라도 문제가 되지 않는 일회용 코드를 사용하는 것이다. 사용자가 "사적인" 링크를 방문하면, 사이트는 시간 제한이 있는 일회용 코드를 이메일로 다시 보내고, 사용자는 이메일 소유를 확인하기 위해 임시 코드를 입력한다.
인터넷에서 URL에 무작위 문자열 이상의 보호가 없다면 그것들은 사실상 사적이지 않다. 인터넷에 연결된 웹캠을 찾는 것과 같은 이야기다. 우리는 이미 이를 알고 있어야 한다. "누가 책임져야 하는가" 섹션에서 이를 언급하지 않는 이유는 무엇인가?
주제에서 벗어난 이야기이지만, Cloudflare Radar가 1.1.1.1에서 데이터를 채굴한다는 링크가 있다. 1.1.1.1이 사용자 데이터를 어떠한 목적으로도 사용하지 않는다고 생각했는데?
Zoom 회의 링크는 종종 쿼리 매개변수로 비밀번호를 추가한다. 이 링크가 "사적이고 안전한" 링크인가? 비밀번호 없이는 "사적이고 안전한" 링크인가?
다음 두 가지 사례 중 어느 것이 더 안전한지 설명해 줄 수 있는가?
private airtable.com 앱에 업로드된 모든 미디어/사진은 공개 링크로, URL을 알고 있으면 인증 없이 접근할 수 있다.