it-swarm-korea.com

MVC3의 AntiForgeryToken 또는 유사한 토큰 유효성 검사를 통한 JSON 하이재킹 방지 문제

제안 된 JSON 도용 방지 솔루션을 구현하는 것을 주저합니다.

  1. JSON 하이재킹을 완화하기 위해 권장되는 솔루션에는 REST가 아닌 전체 JSON POST를 통해 데이터를 가져옵니다.

  2. 대체 솔루션 (개체 래핑)은 소스 코드 액세스 권한이없는 타사 컨트롤에 문제를 일으 킵니다.

  3. 보안 토큰을 구성하거나 웹 페이지 내에서 안전하게 전달하는 방법에 대한 대체 솔루션 (아래 나열)을 구현하는 커뮤니티 검증 구현을 찾을 수 없습니다. 나는 또한 내 자신의 구현을 수행하기에 충분한 전문가라고 주장하지 않을 것입니다.

  4. 리퍼러 헤더는 신뢰할 수 없습니다.

배경

이 블로그 는 JSON 하이재킹과 관련된 CSRF 문제를 설명하고 JSON POST를 사용하여 데이터를 가져올 것을 권장합니다. HTTP POST를 사용하여 데이터를 가져 오는 것이 REST-full이 아니기 때문에 세션 당 작업 REST 작업, 또는 페이지 당.

또 다른 완화 기술은 JSON 데이터를 객체 여기에 설명 된대로 로 래핑하는 것입니다. 다른 기술이 발견 될 때까지 문제가 지연 될 수 있습니다.

대체 구현

나에게 JSON에 대한 jQuery HTTP GET을 사용하여 ASP.NET MVC의 AntiForgeryToken 사용을 확장하는 것이 자연스러워 보입니다.

예를 들어 위의 Haacked 링크에 따르면 민감한 데이터를 가져 오면 다음 코드가 취약합니다.

$.getJSON('[url]', { [parameters] }, function(json) {
    // callback function code
});

권장되는 POST 해결 방법을 사용하여 데이터를 가져 오는 것이 RESTfull이 아님에 동의합니다. 제 생각은 URL에 유효성 검사 토큰을 보내는 것입니다. 이렇게하면 CSRF 스타일의 공격자가 완전한 URL입니다. 캐시되거나 캐시되지 않은 경우 데이터를 가져올 수 없습니다.

다음은 JSON GET 쿼리를 수행하는 방법에 대한 두 가지 예입니다. 어떤 구현이 가장 효과적인지 확실하지 않지만 첫 번째 구현이이 데이터를 캐시하는 잘못된 프록시로부터 더 안전하다고 생각할 수 있으므로 공격자에게 취약합니다.

http : // localhost : 54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE

또는

http : // localhost : 54607/Home/AdminBalances? ENCODEDTOKEN-TOKEN-HERE

... MVC3의 AntiForgeryToken 또는 그 변형 ( swt 참조 ) 일 수도 있습니다. 이 토큰은 위에서 선택한 URL 형식에 대해 인라인 값으로 설정됩니다.

내 자신의 솔루션을 롤링하지 못하게하는 샘플 질문

  1. JSON GET (슬래시, 물음표 등)의 유효성을 검사하는 데 사용할 URL 형식 (위)은 무엇입니까? 프록시가 http : // localhost : 54607/Home/AdminBalanceshttp : // localhost : 54607/Home/AdminBalances? ENCODEDTOKEN-TOKEN-HERE 데이터?

  2. 인코딩 된 토큰을 웹 페이지에 어떻게 전달 하시겠습니까? 인라인 또는 페이지 변수로?

  3. 토큰을 어떻게 구성 하시겠습니까? AntiforgeryToken에 내장되어 있습니까, 아니면 다른 방법으로 구축 되었습니까?

  4. AntiForgeryToken은 쿠키를 사용합니다. 이 경우 백업 쿠키가 사용/필요합니까? HTTP 만? HTTP 전용과 함께 SSL은 어떻습니까?

  5. 캐시 헤더를 어떻게 설정 하시겠습니까? Google Web Accelerator를위한 특별한 것 (예 :)

  6. JSON 요청 SSL을 만드는 것의 의미는 무엇입니까?

  7. 반환 된 JSON 배열은 안전을 위해 여전히 객체에 래핑되어야합니까?

  8. 이 솔루션은 Microsoft에서 제안한 템플릿 및 데이터 바인딩 기능과 어떻게 상호 작용합니까?

위의 질문은 내가 앞서 나가지 않고 직접 수행하지 않는 이유입니다. 내가 생각하지 못했던 질문이 더 많을 가능성은 말할 것도 없지만 아직 위험합니다.

5

이 논문 다양한 합리적인 방어책을 요약합니다.

URL에 예측할 수없는 토큰을 포함하는 것은 실제로 위협을 방어하는 합리적인 방법입니다. (이에 대한 언급은 문서의 섹션 3을 참조하십시오.) 서버로 전달하는 합리적인 방법 중 하나는 매개 변수로 사용하는 것입니다. 토큰은 세션 쿠키의 복사본이거나 서버에 알려지고 공격자가 예측할 수없는 비밀 값일 수 있습니다. 이를 구현하는 기술은 CSRF를 방어하는 기술과 매우 유사합니다.

HTTP 대 HTTPS는 직교적인 문제라고 생각합니다. 여기서 관련성이 보이지 않습니다.

2
D.W.