2016-10-26 3 views
1

오류 로그에 나타나는 위조 방지 쿠키 토큰 및 양식 필드 토큰이 일치하지 않습니다. Azure에서 호스팅되는 사이트. 정적 머신 키가 필요하다는 것을 알게 된 후에 validationKey 및 decryptionKey 속성을 사용하여 web.config에 추가했습니다. 그러나 우리는 여전히 임의 오류가 발생했습니다.임의 "Azure의 위조 방지 쿠키 토큰 및 양식 필드 토큰이 일치하지 않음"

여기 내 "임의"사용을 정의하기 위해 ~ 200 ~ 300 개의 양식 제출마다이 작업이 한 두 번 발생합니다. 그것은 단지 너무 많이 일어난 것처럼 느껴지고 그것은 우리의 서비스를 신뢰하는 고객에게 실질적인 방해입니다.

다른 생각은 쿠키가 활성화되지 않은 컴퓨터에서 이러한 일이 일어나고 있는지 여부입니다. 그 중 한 가지 또는 다른 방식으로 확인할 수 없었지만 ValidateAntiForgeryToken이 작동하려면 쿠키가 필요한지 여부를 알지 못했습니다. 쿠키가 필요한 경우 사용자에게 쿠키를 사용하여 쿠키를 올바르게 사용해야한다는 메시지를 표시해야합니까?

이 문제를 해결하는 방법이나 다른 방법을 진단하는 방법을 찾는 데 도움이 필요합니다.

미리 감사드립니다.

[업데이트]이 오류 팝업을 보았던 사용자로부터 방금 들었습니다. 그들은 페이지를로드하고 오류를 일으키는 동안 멀리 걸어 나간 것으로 밝혀졌습니다. 그것은 유효성 검사가 작업을 수행하고 미친 일이 없다는 것을 의미하는 좋은 소식입니다 ... 데이터 포인트가 나머지 사용자를 나타내는 지 확인해야합니다. 그래서, 토큰이 만료되는 상황을 어떻게 다룰 수 있습니까? 어떤 방법으로 사용자에게 알리십니까?

+0

악의적 인 양식 데이터를 제출하려는 사람이 있습니까? – Liam

+0

정말로, 누가 압니다. 레크리에이션 단계가 없다면 많은 이유가있을 수 있습니다. – Liam

+0

이들은 합법적으로 서비스를 사용하려고 시도하는 실제 사용자이므로 악성 폼 데이터를 제출하는 이유는 없습니다. 또한 HTML이나 스크립트 태그를 사용하는 것과 같은 다른 형태의 악의적 인 데이터가 있지만 다른 유형의 오류가 발생합니다. – lostdeveloper

답변

0

서버 팜이 있습니까? 즉, 자동 확장 기능을 사용하는 앱 서비스가 있습니까? 또는 여러 컴퓨터의 클라우드 서비스?

그렇다면 모든 machine.key가 모든 web.config 파일에서 동일한 값으로 정의되어 있는지 확인하십시오. machinekey는 AntiForgery 토큰을 생성하는 데 사용됩니다.

+0

흠 ... 죄송합니다. 이미 기계 키를 설정하셨습니다 ... –

+0

나는 우리가 Azure에 있기 때문에 우리는 자동으로 서버 팜에 있습니다. machineKey는 배포 된 단일 web.config에 정의되어 있으므로 충돌하는 web.config 파일을 볼 기회가 없습니다. – lostdeveloper

+0

확인. asp가 사용하는 기본 쿠키.net을 사용하여 AntiForgery 토큰을 관리 할 수 ​​있습니다 ** __ RequestVerificationToken ** –

0

실패한 요청의 헤더를 기록 할 수 있습니까? 다음과 같이 Application_Error의 global.asax에 일부 코드를 추가 할 수 있습니다.

foreach (string header in request.Headers) 
{ 
    // header <== header name 
    // request.Headers[header]) <== header value 
} 
+0

우선이 문제에 대해 다시 한 번 감사드립니다. 매우 감사. 헤더를 로깅하는 것과 관련해서는 무엇을 찾고 있습니까? 또한, 나는 방금 사용자로부터받은 피드백을 기반으로이 질문에 대한 업데이트를 게시하고 있습니다. – lostdeveloper

+0

위조 방지 토큰 쿠키가 있는지, 어쩌면 다른 재미있는 것들을 볼 수 있습니다. 크롤러 또는 해커의 히트 일 수있는 URL에이 쿠키가없는 POST입니다. –

+1

모든 헤더가 잘 맞으면 사용자를 사용할 수 있습니다. 다음 사용 사례를 고려해 봅시다. 1) 양식이 캐시 된 페이지 (클라이언트 측 캐시)에 있습니다. 위조 방지 토큰'A'가 생성됩니다 2) 사용자가 양식의 유효성을 검사 한 다음 3) 브라우저의 뒤로 버튼을 누릅니다 4) 사용자가 양식을 다시 확인합니다 (이전 'A'토큰 사용) 5) asp.net 위조 토큰'B'를 기다리고'A'를 얻는다. 그래서 그것은 예외를 던집니다. 이렇게하지 않으려면 위조 방지가 포함 된 양식의 URL에서 클라이언트 캐시를 사용 중지해야합니다. –