문제

당사 사이트에서는 개인 정보 (양식을 통해 제공)를 기반으로 시뮬레이션을 사용자에게 제공합니다. 나중에 시뮬레이션 결과를 다시 얻을 수 있지만 로그인/비밀번호 계정을 만들도록 강요하지 않습니다.

우리는 링크와 함께 이메일을 보내서 결과를 되 찾을 수 있다고 생각했습니다. 그러나 개인 데이터가 위험에 처하기 때문에 당연히이 URL을 보호해야합니다.

따라서 URL에서 토큰 (문자와 숫자의 40 자 조합 또는 MD5 해시)을 전달하고 SSL을 사용하려고합니다.

마지막으로 그들은 다음과 같은 이메일을받습니다.

안녕,
결과를 되 찾으십시오 https://www.example.com/load_simulation?token=uzvtlbcwcw33rihvnbxtkxtxm2rkj7yjrwyuxhxn

당신이 그것에 대해 어떻게 생각하십니까? 충분히 안전합니까? 토큰 세대에 대해 무엇을 조언 하시겠습니까? HTTPS 요청에서 URL 매개 변수를 전달하는 것은 어떻습니까?

도움이 되었습니까?

해결책

SSL은 운송 중 쿼리 매개 변수를 보호합니다. 그러나 전자 메일 자체는 안전하지 않으며 대상으로 이동하기 전에 이메일이 여러 서버를 따라 튀어 나올 수 있습니다.

또한 웹 서버에 따라 전체 URL이 로그 파일에 로그인 될 수 있습니다. 데이터가 얼마나 민감한 지에 따라 IT 사람들이 모든 토큰에 액세스하는 것을 원하지 않을 수 있습니다.

또한 쿼리 문자열이있는 URL은 사용자 이력에 저장되어 동일한 컴퓨터의 다른 사용자가 URL에 액세스 할 수 있습니다.

마지막으로,이를 매우 불안하게 만드는 것은 URL이 모든 리소스, 심지어 타사 리소스에 대한 모든 요청의 참조 헤더로 전송됩니다. 예를 들어 Google Analytics를 사용하는 경우 Google에 URL 토큰을 보내고 모든 것을 보내드립니다.

제 생각에는 이것은 나쁜 생각입니다.

다른 팁

나는 그것을 위해 쿠키를 사용할 것입니다. 워크 플로는 다음과 같아야합니다.

  1. 사용자는 처음으로 사이트에 온다.
  2. 사이트는 쿠키를 설정합니다
  3. 사용자는 데이터를 입력합니다. 데이터는 쿠키에 저장된 일부 키를 사용하여 DB에 저장됩니다.
  4. 사용자가 떠날 때 https : 링크와 함께 이메일을 보냅니다.
  5. 사용자가 돌아 오면 사이트는 쿠키를 발견하고 사용자에게 이전 데이터를 제시 할 수 있습니다.

이제 사용자는 다른 컴퓨터에서 다른 브라우저를 사용하려고합니다. 이 경우 "전송"버튼을 제공하십시오. 사용자 가이 버튼을 클릭하면 "토큰"을받습니다. 그녀는 다른 컴퓨터 에서이 토큰을 사용하여 쿠키를 재설정 할 수 있습니다. 이런 식으로 사용자는 토큰을 양도하려는 안전을 결정합니다.

SSL은 운송중인 데이터의 내용을 보호하지만 URL에 대해서는 잘 모르겠습니다.

어쨌든, URL 토큰을 재사용하는 공격자를 완화하는 한 가지 방법은 각 토큰을 한 번만 사용할 수 있는지 확인하는 것입니다. 합법적 인 사용자가 링크를 계속 사용할 수 있도록 쿠키를 설정할 수도 있지만 첫 번째 액세스 후에는 쿠키가있는 사람에게만 작동합니다.

사용자의 이메일이 손상되고 공격자가 먼저 링크를 얻는다면, 당신은 당신이 hoSed입니다. 그러나 사용자는 또한 더 큰 문제가 있습니다.

이메일은 본질적으로 불안합니다. 누구든지 해당 링크를 클릭하고 데이터를 얻을 수 있다면 실제로 보호하지 않습니다.

SSL을 통과 할 때 토큰은 안전합니다. 당신이 가질 문제는 URL을 볼 수있게함으로써 사람들 (의도하지 않은 사람들)에게 불가능하다는 것입니다.

SSN과 같은 개인 정보라면 이메일을 통해 URL을 보내지 않을 것이라고 생각합니다. 차라리 사이트의 사용자 이름과 비밀번호를 만들도록하겠습니다. 이런 종류의 정보가 당신과 그들을 위해 위험에 처한 이메일을 타협하는 것은 너무 쉽습니다. 누군가의 계정이 구성되면 그것은 실제로 그 결점이있는 quesion에 올 것입니다. 안전할수록 CYA 관점에서 더 나은 것입니다.

나는 진지한 개인 정보 보호 문제가있는 상황에 대해 충분히 안전하다고 생각하지 않을 것입니다. (아마도 ClearText) 이메일로 URL을 보내고 있다는 사실은 가장 약한 링크입니다. 그 후 토큰에 대한 무차별 인력 공격의 위험이 있는데, (실제 인증 메커니즘의 구조가 부족함) 잘 구성된 사용자 이름 및 비밀번호 설정보다 더 취약 할 수 있습니다.

HTTPS 요청의 매개 변수에는 우연히 문제가 없습니다.

그대로, 그것은 나쁜 생각 일 것입니다. 쉽게 사용하면 보안을 무시할 것입니다. 이전에 SSL은 서버와 클라이언트 브라우저 사이의 정보 전송 만 보호하며 중간 사람의 공격 만 방지합니다. 이메일은 매우 위험하고 안전하지 않습니다.

가장 좋은 것은 정보에 액세스하기위한 사용자 이름과 비밀번호 인증입니다.

나는 쿠키 아이디어를 어느 정도 좋아합니다. 쿠키 정보도 암호화해야합니다. 또한 공격 확률을 제한하기 위해 $ _server [ 'HTTP_USER_AGENT']를 소금과 핵심 문구와 함께 토큰을 생성해야합니다. 검증 사용을 위해 쿠키에 클라이언트에 대한 무의미한 정보를 저장하십시오.

핵심 문구는 쉽게 사용하기 위해 쿠키에 저장 될 수 있지만 쿠키도 도난할 수 있습니다 = (.

클라이언트가 자신이 제공 한 핵심 문구를 입력하는 것이 좋습니다. 데이터베이스에도 데이터와 함께 저장됩니다.

또는 개인이 $ _server [ 'http_user_agent'] 매개 변수에 다른 다른 기계를 사용하거나 단순히 쿠키를 놓친 경우 키를 사용할 수 있습니다. 따라서 쿠키를 전송하거나 설정할 수 있습니다.

또한 민감한 데이터가 데이터베이스에서 암호화되어 있는지 확인하십시오. 당신은 결코 알지 못합니다;)

해커가 데이터베이스에 액세스하면 많은 개인 정보를 자유롭게 제공 할 수 있다는 것을 알고 있습니까?

그 후 나는 이것이 아이디어로 나쁘지 않다고 말할 것이다. 해싱에 대해서는 안전하지 않기 때문에 MD5 또는 SHA1을 사용하지 않습니다. 그들은 "암호화"(암호화가 아니라는 것을 알고 있습니다)를 아주 쉽게 할 수 있습니다.

그렇지 않으면 이메일 종류의 비밀번호로 전송되지 않는 두 번째 정보를 사용할 수 있습니다. 그 이유는 누군가가 사용자의 이메일에 액세스 할 수있게되면 (세션을 죽이지 않으면 Hotmail을 사용하면 쉽게) 사용자가 보낸 모든 정보에 액세스 할 수 있습니다.

HTTPS는 귀하의 사이트에서 최종 사용자에게 데이터를 보안하고 암호화합니다. 다른 것은 없습니다. 안전한 터널로 가져 가십시오. 더 이상 아무것도 아닙니다.

내가 당신의 아이디어에 대해 이해 한 바에 따르면, 이론적으로 누군가는 무작위 40 문자열 또는 MD5 해시를 입력하고 누군가 엘스 세부 정보를 얻을 수 있습니다. 이것은 가능성이 거의 없지만 한 번만 발생하면됩니다.

더 나은 독창은 사용자에게 토큰을 보내고 이름, 우편 번호, SSN 또는 이들의 조합과 같은 세부 정보를 입력하도록 요청하는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top