상태 비 저장 (세션없는) 및 쿠키없는 인증을 수행하는 방법은 무엇입니까?

Bob은 무언가를 달성하기 위해 웹 애플리케이션을 사용합니다. 과:

• 그의 브라우저는 다이어트 중이므로 쿠키를 지원하지 않습니다 .
• 웹 애플리케이션은 인기있는 애플리케이션으로, 주어진 순간에 많은 사용자를 처리합니다 . 확장 성 이 있어야 합니다. 세션을 유지 하면 동시 연결 수에 제한이 적용되고 물론 무시할 수없는 성능 저하 가 발생하는 한 세션이없는 시스템을 사용하는 것이 좋습니다. :)

몇 가지 중요한 참고 사항 :

• 우리는 전송 보안을 가지고 있습니다 ( HTTPS 와 가장 친한 친구).
• 커튼 뒤에서 웹 애플리케이션 은 현재 사용자를 대신하여 외부 서비스에 많은 작업을 위임합니다 (이러한 시스템은 Bob을 사용자 중 하나로 인식 함). 즉, 사용자 에게 Bob의 자격 증명을 전달해야합니다 .

이제 Bob을 어떻게 인증합니까 (각 요청마다)? 그런 것을 구현하는 합리적인 방법은 무엇입니까?

• 재생 테니스를 통해 자격 증명을 사용하여 HTML 양식 숨겨진 필드 ... 볼 자격 증명 (포함 사용자 이름 및 암호 )와 두 라켓은 브라우저와 각각의 웹 응용 프로그램입니다. 즉, 쿠키 대신 양식 필드를 통해 데이터를주고받을 수 있습니다. 각 웹 요청에서 브라우저는 자격 증명을 게시합니다. 그래도의 경우 단일 페이지 응용 프로그램 이 재생처럼 보일 수 스쿼시 고무 벽에 대신 재생 테니스 는 AS, 웹 양식 의 자격 증명을 포함는 전체 수명 살아 유지 될 수있는 웹 페이지를 (그리고 서버는 자격 증명을 다시 제공하지 않도록 구성됩니다).
• 페이지 컨텍스트에 사용자 이름 및 비밀번호 저장-JavaScript 변수 등. 여기에는 단일 페이지가 필요합니다. IMHO.
• 암호화 된 토큰 기반 인증. 이 경우 로그인 조치로 인해 암호화 된 보안 토큰 (사용자 이름 + 비밀번호 + 기타)이 생성됩니다. 이 토큰은 클라이언트에게 다시 제공되며 다가오는 요청에는 토큰이 수반됩니다. 이게 말이 돼? 이미 HTTPS가 있습니다 ...
• 기타 ...
• 마지막 수단 :이 작업을 수행하지 말고 세션에 자격 증명을 저장하십시오! 세션이 좋습니다. 쿠키 유무.

이전에 설명한 아이디어와 관련하여 웹 / 보안 문제가 떠오 릅니까? 예를 들면

• 타임 아웃 - 자격 증명과 함께 타임 스탬프를 유지할 수 있습니다 (타임 스탬프 = Bob이 자격 증명을 입력 한 시간). 예를 들어 NOW-timestamp> threshold 이면 요청을 거부 할 수 있습니다.
• 교차 사이트 스크립팅 보호-어떤 식 으로든 다르면 안됩니까?

이 글을 읽어 주셔서 감사합니다 :)

아, 저는 세션없이 세션을 유지하는이 질문을 좋아합니다.

응용 프로그램 평가 중에이 작업을 수행하는 여러 방법을 보았습니다. 인기있는 방법 중 하나는 인 플레이 테니스 사용자를 인증하는 모든 요청에 사용자 이름과 암호를 전송 - 당신이 언급 한 방법입니다. 내 생각에 이것은 특히 응용 프로그램이 단일 페이지가 아닌 경우 안전하지 않습니다. 또한 확장 가능하지 않습니다. 특히 나중에 인증 외에 앱에 인증을 추가하려는 경우에도 마찬가지입니다 (로그인을 기반으로 무언가를 빌드 할 수도 있지만).

완전히 상태 비 저장 메커니즘은 아니지만 (자바 스크립트 실행이 있다고 가정 할 때) 널리 사용되는 메커니즘은 JavaScript에 세션 쿠키를 포함하는 것입니다. 내 안의 보안 담당자가 소리를 지르고 있지만 실제로 작동 할 수 있습니다. 모든 요청에는X-Authentication-Token헤더 또는 그와 비슷한 것으로 데이터베이스, 메모리의 파일 저장소 등에 매핑하여 사용자의 유효성을 검사합니다. 이 토큰은 지정한 시간의 시간 초과를 가질 수 있으며 시간이 초과되면 사용자는 다시 로그인해야합니다. 상당히 확장 가능합니다. 데이터베이스에 저장하고 하나의 SQL 문이 실행되고 올바른 인덱스를 사용하면 여러 명의 동시 사용자가 있더라도 실행하는 데 시간이 거의 걸리지 않습니다. 여기서 부하 테스트는 확실히 도움이 될 것입니다. 질문을 올바르게 읽으면 이것이 암호화 된 토큰 메커니즘이 될 것입니다. 그러나 사용자 이름 + 암호 + 다른 조합을 사용하는 대신 32 자의 암호화 된 임의 토큰을 사용하는 것이 좋습니다.이 방법은 그대로 유지됩니다. 예측할 수 없지만 여전히 사용자 ID 또는 이와 같은 것과 연관시킬 수 있습니다.

어떤 것을 사용하든 안전하게 전송되었는지 확인하십시오. HTTPS는 유선을 통해 사용자를 보호하지만 URL을 통해 세션 토큰을 유출하는 경우 (또는 URL을 통한 자격 증명) 사용자를 보호하지 않습니다. 헤더를 사용하거나 가능하지 않은 경우 매번 POST 요청을 통해 토큰을 보내는 것이 좋습니다 (사용자 브라우저의 숨겨진 양식 필드를 의미 함). POST 요청을 사용하는 후자의 접근 방식은 CSRF 방어를 사용해야합니다. 경우에 따라 토큰 자체를 사용하는 것이 일종의 CSRF 방어 일 수 있습니다.

마지막으로, 만료 된 토큰을 제거 할 수있는 메커니즘이 백엔드에 있는지 확인하십시오. 이것은 과거에 많은 응용 프로그램의 골칫거리였습니다. 빠르게 성장하는 인증 토큰 데이터베이스는 결코 사라지지 않는 것 같습니다. 여러 사용자 로그인을 지원해야하는 경우 수를 제한하거나 각 토큰에 대해 더 짧은 시간 제한이 있는지 확인하십시오. 앞서 말했듯이 부하 테스트가 이에 대한 답이 될 수 있습니다.

제가 생각할 수있는 몇 가지 다른 보안 문제가 있지만이 단계에서 해결하기에는 너무 광범위합니다. 모든 사용 (및 남용) 사례를 염두에두면 다음을 상당히 잘 구현할 수있을 것입니다. 이 시스템.

로그인 옵션에 대해-평소 손님을위한 세션도 지원하고 싶다고 생각합니다.

따라서 로그인을 시행하려는 경우 암호화 된 토큰 옵션이 좋을 수 있습니다. 왠지 게스트 세션에도 좋을지도 모릅니다. 다른 방향으로, URL에 토큰을 추가하는 것과 테니스 옵션을 결합합니다.

URL로만 자격 증명을 보내는 것은 위험 할 수 있습니다. 예를 들어 HTTP 참조 헤더를 통해 또는 트래픽을 검사하거나 컴퓨터를 감시하는 사람이 토큰을 유출 할 수 있습니다.

쿠키를 사용할 수 있더라도 CSRF (Cross Site Request Forgery) 공격으로부터 자신을 보호하기 위해 임의의 토큰 또는 임의의 검증자를 추가하는 것이 좋습니다.