302 리디렉션이 리퍼러 문자열을 유지합니까?


92

사용자를 한 페이지에서 다른 페이지로 리디렉션해야하지만 원래 참조 문자열을 유지해야합니다. 그들이에 밖으로 시작한다면, 예를 들어, http://www.othersite.com/pageA.jsp ,로 연결되는 링크를 클릭 http://www.example.com/pageB.jsp 다음 302을 실행, http://www.example.com/pageC.jsp로 리디렉션하면 포함 할 참조 문자열이 필요합니다.http://www.othersite.com/pageA.jsp

302 리디렉션의 정상적인 동작입니까? 아니면 내 원래 리퍼러가 삭제 http://www.example.com/pageB.jsp됩니까? 그것은 바람직하지 않습니다.

차이가 있는지는 모르겠지만 JSP에서 작업 중이며 response.sendRedirect()302 리디렉션을 실행하는 데 사용 하고 있습니다.

나는 이것으로 실험을했고 원래 참조 자 문자열 ( http://www.othersite.com/pageA.jsp) 을 유지 한 것 같지만 이것이 정상적인 기본 동작인지 확인하고 싶었습니다.


현재 302 리디렉션을 사용하고 있지만 대신 301 리디렉션을 사용할 수 있습니다. 301 리디렉션의 동작이 더 신뢰할 수 있는지 알고 있습니까?


3
나는 그 반대가 필요합니다. 리디렉션 에서 리퍼러를 변경 하는 서버 측 리디렉션 을 수행합니다 (따라서 원래 리퍼러 삭제). 누군가?
cprcrack

답변:


32

짧은 대답은 Referer 헤더 또는 302 상태 코드 에 대해 관련 RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36에 지정되어 있지 않습니다 .

가장 좋은 방법은 여러 브라우저로 테스트를 수행하고 합의 동작이 있는지 확인하는 것입니다.

전체 벨트 및 중괄호의 경우 원래 리퍼러를 리디렉션 URL에 인코딩하여 검색을 보장 할 수 있습니다.


19
관심을 가질만한 사람에게는 주요 브라우저에서 spme 테스트를 수행했습니다. stackoverflow.com/questions/2158283/…
Marco Demaio 2011 년

121

나는 302에 대해 모르지만 오늘 일부 브라우저에서 301을 테스트했습니다. 결과는 다음과 같습니다.

시나리오 : 사용자가 domainA를 가리키는 domainX의 링크를 클릭합니다. domainA는 domainB로 301 리디렉션을 수행합니다.

  • refererdomainB에 착륙 할 때 IE8 : domainX (InPrivate 브라우징을 사용하는 경우 및 사용자가 새 탭에서 링크를 열 때도)
  • refererdomainB에 착륙 할 때 Safari4 : domainX (사용자가 새 탭에서 링크를 열 때도 해당)
  • domainB referer에 착륙 할 때 FF3.6.10 : domainX (사용자가 새 탭에서 링크를 열 때도)
  • domainB referer에 방문 할 때 Chrome5는 domainX입니다 ( 사용자가 새 탭에서 링크를 열지 않는 경우 ).
  • domainB referer에 방문 할 때 Chrome26은 domainX입니다 (사용자가 새 탭에서 링크를 열 때도 해당).

27
참고 :이 테스트는 얼마 전에 수행되었으며 현재 Chrome 26은 새 탭에서 열었을 때도 동일한 방식으로 작동합니다 .
Benjamin

모든 브라우저에서 테스트되지는 않았지만 302의 동작은 동일한 것 같습니다.
Amir Ali Akbari

1
참고 : 리디렉션 페이지 (domainA)가 Referrer-Policy : no-referrer 헤더를 발행하는 경우 Chrome (및 Opera)은 요청 의 Referer 헤더를 대상 페이지 (domainB)로 설정하지 않습니다 . Firefox와 Edge는 여전히 전송합니다.
David Balažic

12

좋은 질문. 이 경우, 리퍼러의 전송은 전적으로 브라우저에 의존합니다 (브라우저가 새 리소스에 대해 다른 요청을하도록 지시 받기 때문입니다).

RFC 2616은이 문제에 대해 침묵합니다.

요청 된 리소스는 일시적으로 다른 URI에 있습니다. 리디렉션이 가끔 변경 될 수 있으므로 클라이언트는 향후 요청에 대해 Request-URI를 계속 사용해야합니다. 이 응답은 Cache-Control 또는 Expires 헤더 필드로 표시된 경우에만 캐시 할 수 있습니다.

나는 브라우저가 올바른 리퍼러를 보내는 것을 믿지 않을 것입니다. 나는 다른 사람들과 다른 것을 보내는 적어도 하나가있을 것입니다.

해결 방법

가능하다면 ?override_referer=<old_url>리디렉션하는 URL에 매개 변수를 추가하고 HTTP_REFERER 대신 해당 값을 구문 분석하십시오.

이렇게하면 항상 올바른 결과를 얻을 수 있으며 보안 상 어떤 것도 잃지 않습니다. 리퍼러는 어느 쪽이든 위조 될 수 있습니다.


4
URL에서 리퍼러를 재정의 할 수있게함으로써 실제로 보안상의 무언가를 잃고 있습니다. 대부분의 최신 브라우저에서 AJAX 요청에 대한 리퍼러는 JavaScript를 통해 변경할 수 없습니다. 그러나 URL은 분명히 가능합니다. 이는 XSS 공격이 발생하는 경우 리퍼러가 URL 매개 변수보다 더 신뢰할 수 있음을 의미합니다. 오해하지 마십시오. 참조자는 여전히 완전히 신뢰할 수없는 사용자 입력입니다. 그러나 URL을 변경하는 것보다 다른 사람을 위해 해당 데이터를 스푸핑하는 것이 훨씬 더 어렵습니다.
phylae

7

나는 반대의 문제가 있었다 : 나는 그 리퍼러가 "pageB"였으면했지만 현재의 어떤 브라우저도 이런 식으로 진행하지 않는다 ...

그래서 301 또는 302 리디렉션 대신 pageB에서 HTML 리디렉션을 시도했습니다.

<meta http-equiv="refresh" content="0; url=pageC.jsp" />

결과는 놀랍습니다.

  • Referer는 Chrome에서 pageB입니다.
  • Referer는 FireFox & IE에서 비어 있습니다!

이것이 도움이되기를 바랍니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.