URL 리다이렉션

URL redirection
Wikipedia의 URL 리다이렉션은 Wikipedia:리다이렉트.

URL 리다이렉션(URL Forwarding이라고도 함)은 웹 페이지를 여러 URL 주소로 사용할 수 있도록 하기 위한 World Wide Web 기술입니다.웹 브라우저가 리디렉션된 URL을 열려고 하면 다른 URL을 가진 페이지가 열립니다.마찬가지로 도메인 리다이렉션 또는 도메인 포워딩은 URL 도메인 내의 모든 페이지가 다른 도메인으로 리다이렉트되는 경우(wikipedia.com 및 wikipedia 등)입니다.net은 자동으로 wikipedia.org으로 리다이렉트 됩니다.

URL 리다이렉션은 다양한 이유로 실행됩니다.

  • URL 단축의 경우
  • 웹 페이지 이동 시 링크가 끊어지지 않도록 합니다.
  • 동일한 소유자에게 속한 여러 도메인 이름이 단일 웹 사이트를 참조할 수 있도록 합니다.
  • 웹 사이트를 출입할 수 있도록 안내한다.
  • 프라이버시 보호를 위해
  • 피싱 공격이나 악성 프로그램 배포와 같은 악의적인 목적으로 사용됩니다.

목적들

URL 리다이렉션을 사용하는 이유는 다음과 같습니다.

HTTPS 강제 실행

시큐어 HTTPS URI 스킴과 플레인 HTTP(「http://」로 시작하는 시큐어하지 않은 URI) 양쪽을 개입시켜 Web 사이트에 액세스 할 수 있는 경우가 있습니다.

사용자가 URI를 입력하거나 안전하지 않은 배리언트를 참조하는 링크를 클릭하면 웹 사이트가 애플리케이션과 함께 출하된HST 프리로드 목록에 포함되어 있거나 사용자가 이전에 오리진을 방문한 적이 있는 경우 브라우저는 자동으로 시큐어 버전으로 리다이렉트 됩니다.

그렇지 않으면 HTTP를 통해 웹사이트에 접속됩니다.웹 사이트 운영자는 브라우저를 HTTPS 변종으로 리다이렉트하고 향후 액세스를 위해 HSTS를 프라이밍함으로써 이러한 요구를 처리하기로 결정할 수 있습니다.

유사한 도메인 이름

사용자가 URL을 잘못 입력할 수 있습니다. 조직은 종종 이러한 "철자가 틀린" 도메인을 등록하고 "올바른" 위치로 리디렉션합니다.이 기술은 같은 이름의 다른 최상위 도메인(TLD)을 "예약"하거나 ".edu" 또는 ".net" 사이트가 ".com"을 입력하는 사용자를 쉽게 수용할 수 있도록 하기 위해 자주 사용됩니다.

새 도메인으로 페이지 이동

다음의 3가지 이유로, Web 페이지가 새로운 도메인으로 리다이렉트 되는 이유는 다음과 같습니다.

  • 사이트가 도메인 이름을 변경하기를 원하거나 변경해야 할 수 있습니다.
  • 작성자는 각각의 페이지를 새로운 도메인으로 이동할 수 있습니다.
  • 두 웹 사이트가 병합될 수 있습니다.

URL 리다이렉트를 사용하면, 낡은 URL 에의 착신 링크를 올바른 장소에 송신할 수 있습니다.이러한 링크는 사용자가 브라우저에 저장한 북마크/즐겨찾기 또는 변경사항이 있음을 깨닫지 못한 다른 사이트에서 온 것일 수 있습니다.검색 엔진도 마찬가지입니다.대부분의 경우 데이터베이스에 오래된/오래된 도메인 이름과 링크가 있으며 검색 사용자를 이러한 오래된 URL로 보냅니다."영구적으로 이동"된 리다이렉트를 새 URL로 사용해도 방문자는 올바른 페이지로 이동합니다.또, 다음의 검색 엔진 패스에서는, 검색 엔진이 새로운 URL 를 검출해 사용할 필요가 있습니다.

발신 링크 로깅

대부분의 웹 서버의 액세스 로그에는 방문자가 어디에서 왔고 어떻게 호스트 사이트를 탐색했는지에 대한 자세한 정보가 저장됩니다.그러나 방문자가 떠난 연결고리는 기록하지 않습니다.이는 방문자가 발신 링크를 클릭할 때 방문자의 브라우저가 원래 서버와 통신할 필요가 없기 때문입니다.이 정보는 여러 가지 방법으로 캡처할 수 있습니다.한 가지 방법은 URL 리다이렉션을 포함합니다.사이트상의 링크는, 방문자를 다른 사이트로 직접 송신하는 대신에, 원래의 Web 사이트의 도메인상의 URL 에 직접 송신해, 자동적으로 실제의 타겟으로 리다이렉트 할 수 있습니다.이 기술은 원래 웹 사이트의 서버에 대한 추가 요청으로 인해 발생하는 지연의 단점을 안고 있습니다.이 추가된 요청은 서버 로그에 트레이스를 남기며 어떤 링크가 팔로우되었는지 정확하게 표시되므로 사생활 문제가 [1]될 수도 있습니다.일부 기업 웹사이트에서는 후속 콘텐츠가 다른 사이트에 있으므로 반드시 회사와 관련되지 않는다는 진술을 구현하기 위해 동일한 기술을 사용합니다.이러한 시나리오에서는 경고를 표시하면 지연이 증가합니다.

긴 URL의 짧은 별칭

주요 기사 : URL 단축

웹 응용 프로그램의 URL에는 데이터 계층, 명령 구조, 트랜잭션 경로 및 세션 정보를 나타내는 긴 기술 속성이 포함되어 있는 경우가 많습니다.이로 인해 미적으로 불쾌하고 기억하기 어려운 URL이 생성되어 마이크로블로그 사이트의 크기 제한 내에 들어가지 않을 수 있습니다.URL 단축 서비스는 사용자를 짧은 [1]URL에서 긴 URL로 수정하여 이 문제를 해결합니다.

긴 URL 또는 변경 URL에 대한 의미 있는 영속적인 에일리어스

다음 항목도 참조하십시오.Permalink, PURL 및 링크 부패

내용이 그대로 유지되더라도 페이지의 URL이 변경될 수 있습니다.따라서 URL 리다이렉션은 북마크를 가진 사용자에게 도움이 됩니다.이 작업은 페이지 이름이 변경될 때마다 위키피디아에서 일상적으로 수행됩니다.

투고/리다이렉트/가져오기

주요 기사:투고/리다이렉트/가져오기

Post/Redirect/Get(PRG)는 웹 개발 설계 패턴으로, 사용자가 폼을 제출한 후 새로 고침 버튼을 클릭하면 폼이 중복되는 것을 방지하여 사용자 에이전트(사용자)에게 보다 직관적인 인터페이스를 제공합니다.

디바이스 타깃팅 및 지오타겟팅

리다이렉트는 지오타겟팅과 같은 타겟팅 목적으로 효과적으로 사용할 수 있습니다.모바일 클라이언트의 증가에 따라 디바이스 타깃팅의 중요성이 높아지고 있습니다.모바일 사용자에게 서비스를 제공하는 방법에는 두 가지가 있습니다. 즉, 웹 사이트를 응답형으로 만들거나 모바일 웹 사이트 버전으로 리디렉션합니다.모바일 웹사이트 버전이 제공되면 모바일 클라이언트를 가진 사용자는 자동으로 해당 모바일 콘텐츠로 전송됩니다.디바이스 타겟팅의 경우 클라이언트 측 리다이렉트 또는 캐시 불가능한 서버 측 리다이렉트가 사용됩니다.Geotargeting은 현지화된 콘텐츠를 제공하고 사용자를 요청된 URL의 현지화된 버전으로 자동으로 전송하는 방법입니다.이것은, 복수의 장소나 언어의 유저를 대상으로 하는 Web 사이트에 도움이 됩니다.일반적으로 서버 측 리다이렉트는 Geotargeting에 사용되지만 [2]요건에 따라서는 클라이언트 측 리다이렉트도 옵션일 수 있습니다.

검색 엔진 조작

URL 납치와 같은 비윤리적인 의도를 가지고 검색 엔진을 조작하는 데 리다이렉트가 사용되었습니다.잘못된 방향 수정의 목적은 검색 트래픽을 랜딩 페이지로 유도하는 것입니다. 랜딩 페이지 자체로는 충분한 순위 지정 능력이 없거나 검색 대상과 원격으로만 관련이 있거나 전혀 관련이 없는 페이지입니다.이 방법에서는 검색자를 대상 페이지로 전송하기 위해 교활한 리다이렉트를 사용하는 다수의 URL을 포함하는 검색어 범위의 순위가 필요합니다.이 방식은 모바일과 타깃팅의 부상과 함께 부활했다.URL 하이잭은 임시 리디렉션에 대한 검색 엔진 처리의 특성을 이용하는 도메인 외부 리디렉션[3] 기법입니다.일시적인 리다이렉트가 발생했을 경우 검색 엔진은 리다이렉트를 초기화하는 URL에 순위 값을 할당할지 또는 리다이렉트타깃 URL에 할당할지 결정해야 합니다.리다이렉트는 일시적인 성질을 나타내므로 리다이렉트를 시작하는 URL은 검색 결과에 표시되도록 유지될 수 있습니다.특정 상황에서는 순위의 URL에 일시적인 리다이렉트를 적용함으로써 이 동작을 부정 이용하는 경우가 있습니다.그 결과 검색 결과의 원래 URL이 리다이렉트를 초기화한 URL로 대체되어 랭킹을 「도용」할 수 있습니다.이 메서드는 보통 검색 결과에서 대상 페이지로 사용자 스트림을 재지정하기 위해 교활한 리다이렉트와 결합되었습니다.검색 엔진은 이러한 종류의 조작적 접근 방식을 탐지하는 효율적인 기술을 개발했습니다.주요 검색엔진들은 보통 [4]이런 기술을 적용하다 적발된 사이트에 대해 엄격한 순위 처벌을 가한다.

방문자 조작

URL 리다이렉션은 방문자가 방문하는 [5]웹 사이트를 혼동하는 피싱 공격의 일부로 사용될 수 있습니다.최신 브라우저는 항상 주소 표시줄에 실제 URL을 표시하므로 위협이 줄어듭니다.단, 리다이렉트를 사용하면 다른 방법으로 공격을 시도하는 사이트로 이동할 수도 있습니다.예를 들어 리다이렉트는 사용자를 사이트로 데려가 안티바이러스소프트웨어를 다운로드하여 트로이 목마를 설치하도록 속일 수 있습니다.

삭제 중referrer정보

링크를 클릭하면 브라우저는 HTTP 요청으로 링크의 소스를 나타내는 referer라는 필드를 전송합니다.이 필드에는 현재 웹 페이지의 URL이 입력되어 외부 링크를 서비스하는 서버의 로그에 기록됩니다.기밀 페이지에는 기밀 URL이 포함되어 있을 수 있습니다(예:https://company.com/plans-for-the-next-release-of-our-product） 에는 바람직하지 않습니다.referrer조직을 탈퇴하는 URL.레퍼러를 숨기는 리다이렉션페이지를 모든 외부 URL 에 포함할 수 있습니다.예를 들어, 다음과 같이 변환합니다.https://externalsite.com/page안으로https://redirect.company.com/https://externalsite.com/page이 기술은 세션 ID 등 잠재적으로 중요한 기타 정보를 레퍼러 URL에서 제거하여 최종 사용자에게 다른 사이트로의 클리어 게이트웨이를 통과했음을 표시함으로써 피싱 가능성을 줄일 수 있습니다.

실행

브라우저에 대한 몇 가지 다른 응답으로 인해 리다이렉트가 발생합니다.이것들은 HTTP 헤더 또는 HTML 컨텐츠에 영향을 주는지에 따라 다릅니다.일반적으로 사용되는 기술은 구현자의 역할과 시스템의 다른 부분에 대한 접근에 따라 달라집니다.예를 들어, 헤더를 제어할 수 없는 웹 작성자는 새로 고침 메타 태그를 사용하는 반면, 사이트의 모든 페이지를 리디렉션하는 웹 서버 관리자는 서버 구성을 사용할 가능성이 높습니다.

수동 리다이렉트

가장 간단한 방법은 방문자에게 새 페이지 링크를 팔로우하도록 요청하는 것입니다. 보통 다음과 같은 HTML 앵커를 사용합니다.

<a href="https://www.example.com/"> 이 링크를 따라 주세요.< / a >

이 방법은 자주 예비로 사용됩니다.브라우저가 자동 리다이렉트를 지원하지 않는 경우에도 방문자는 링크를 따라 대상 문서에 도달할 수 있습니다.

HTTP 상태 코드 3xx

World Wide Web에서 사용되는 HTTP 프로토콜에서 리다이렉트는 3으로 시작하는 상태 코드를 가진 응답으로 브라우저에 다른 페이지를 표시합니다.클라이언트가 리다이렉트를 검출했을 경우는, 리다이렉트 처리 방법을 몇번이나 결정할 필요가 있습니다.클라이언트는 리다이렉트의 목적, 캐싱 처리 방법 및 후속 요구에 사용할 요청 방식을 이해하기 위해 다양한 상태 코드를 사용합니다.

HTTP/1.1 에서는, 리다이렉션의 몇개의 상태 코드(RFC 7231)가 정의되고 있습니다.

  • 300개의 복수 선택 가능 (예를 들어 다양한 언어 제공)
  • 301이 영속적으로 이동(리다이렉트된 페이지에 링크 에퀴티를 전달하는 URL에서 다른 URL로 영속적으로 리다이렉트)
  • 302가 검출되었습니다(원래는 HTTP/1.0으로 "임시 리다이렉트"로 CGI 스크립트에 널리 사용되었습니다.HTTP/1.1에서는 303 및 307로 대체되었지만 하위 호환성을 위해 유지됩니다).
  • 303 기타 참조(원래 요구가 POST였던 경우에도 GET 요구를 새로운 URL로 강제)
  • 305 프록시 사용(클라이언트의 요청된 리소스는 프록시를 통해서만 사용 가능)
  • 307 일시 리다이렉트(브라우저가 GET 또는 POST 요구를 재발송신하기 위한 새로운 URL 제공)
  • 308 영속 리다이렉트(브라우저가 GET 또는 POST 요구를 재발송신하기 위한 새로운 URL 제공)

상태 코드 304는 수정되지 않고 프록시 사용 305는 수정되지 않습니다.

리다이렉트 상태 코드 및 특성[6]
HTTP 상태 코드 HTTP 버전 일시적/영구적 캐시 가능 요청 메서드 후속 요청
301 HTTP/1.0 영구적인 네. GET/POST가 변경될 수 있음
302 HTTP/1.0 임시의 디폴트 없음 GET/POST가 변경될 수 있음
303 HTTP/1.1 임시의 절대. 항상 GET
307 HTTP/1.1 임시의 디폴트 없음 변하지 않을 수도 있다
308 HTTP/1.1 영구적인 디폴트로는 변하지 않을 수도 있다

이러한 모든 상태 코드를 사용하려면 HTTP 응답의 Location: 헤더에 리다이렉트타깃의 URL을 지정해야 합니다.300개의 복수 선택 항목은 보통 메시지 본문에 있는 모든 선택 항목을 나열하고 Location: 헤더에 기본 선택 항목을 표시합니다.

301 리다이렉트의 HTTP 응답 예시

301 영속적으로 리다이렉트된HTTP 응답은 다음과 같습니다.

HTTP/1.1 301 영구 이동 위치: https://www.example.org/ Content-Type: text/text-Length: 174 <bead> <bead> <bead>이동했습니다.</title></head></body>=이 페이지는 <a href="https://www.example.org/">https://www.example.org/</a>로 이동했습니다.</p> </body> </body> </body>

리디렉션에 서버 측 스크립팅 사용

HTML 콘텐츠를 생성하는 웹 작성자는 일반적으로 HTTP 헤더를 사용하여 리디렉션할 수 없습니다. HTTP 헤더는 HTML 파일을 제공할 때 웹 서버 프로그램에 의해 자동으로 생성되기 때문입니다.CGI 스크립트를 작성하는 프로그래머도 마찬가지입니다만, 일부의 서버에서는 커스텀헤더를 추가할 수 있습니다(예를 들면, 「비파싱 헤더」를 유효하게 하는 것).스크립트가 "Location:" 헤더 행을 출력하면 많은 웹 서버가 3xx 상태 코드를 생성합니다.예를 들어 PHP에서는 "header" 함수를 사용할 수 있습니다.

머리글자('HTTP/1.1 301 영구 이동'); 머리글자('장소: https://www.example.com/'); 퇴장();

캐시를 [7]방지하려면 더 많은 헤더가 필요할 수 있습니다.프로그래머는 헤더가 본문보다 먼저 출력되도록 해야 합니다.이는 코드를 통한 자연스러운 제어 흐름과 쉽게 맞지 않을 수 있습니다.이를 위해 서버 측 내용 생성을 위한 일부 프레임워크는 본문 데이터를 버퍼링할 수 있습니다.ASP 스크립트 언어에서는, 다음의 방법으로도 실행할 수 있습니다.response.buffer=true그리고.response.redirect "https://www.example.com/"HTTP/1.1은 상대 URI 참조 또는 절대 URI [8]참조 중 하나를 허용합니다.URI 참조가 상대적인 경우 클라이언트는 RFC 3986에 [9]정의된 규칙에 따라 필요한 절대 URI 참조를 계산합니다.

Apache HTTP 서버 mod_rewrite

Apache HTTP 서버 mod_alias 확장을 사용하여 특정 요청을 리디렉션할 수 있습니다.일반적인 구성 지침은 다음과 같습니다.

permanent / oldpage.http:/https://www.example.com/newpage.html 리다이렉트 301 / oldpage.http:/https://www.example.com/newpage.html

보다 유연한 URL 개서 및 리다이렉션을 위해 Apache mod_rewrite를 사용할 수 있습니다.예를 들어 요청을 표준 도메인 이름으로 리디렉션하려면:

RewriteCond %{ RewriteEngineHTTP_HOST} ^([^:]+\.)* oldsite\.example\.com\?(:[0-9]*)?$ [NC ] RewriteRule ^ (.*) $ https://newsite.example.net/$1 [R=rewrite, L]

이러한 설정은 서버 컨피규레이션파일을 통해 서버상의 1개 또는 모든 사이트에 적용하거나 또는 를 통해 단일 콘텐츠디렉토리에 적용할 수 있습니다..htaccess파일.

nginx 개서

Nginx에는 통합 http rewrite [10]모듈이 있으며 고급 URL 처리 및 웹 페이지 생성(Web 페이지 생성)을 수행하기 위해 사용할 수 있습니다.return 지시)이러한 개서 모듈의 고도의 사용 예를 들면, mdoc.suible 2022년 4월 3일 Wayback Machine이 있습니다.Wayback Machine은 nginx 설정 언어만으로 [11][12]결정론적 URL 단축 서비스를 구현합니다.

예를 들어 다음과 같은 경우/DragonFlyBSD/HAMMER.5먼저 내부로 전송될 것입니다./d/HAMMER.5다음의 첫 번째 리라이트 디렉티브(HTTP 응답은 아직 클라이언트에 발행되지 않고 내부 스테이트에만 영향을 줍니다)를 사용하고, 그 후 두 번째 리라이트 디렉티브를 사용하면, 클라이언트에 대해서 302 Found 상태 코드의 HTTP 응답이 발행되어 실제로 web-man [13]의 외부 cgi 스크립트로 리다이렉트 됩니다. 

 location / Dragon Fly { rewrite ^ / Dragon Fly (BSD ) ? （ [ · · ） * ） 。$ /d$2 last; } location /d { set $db "https://leaf.dragonflybsd.org/cgi/web-man?command="; $ds "&section="; $ds "/"([^/]+)\.([1-9])$1$ds$2 redirect; }

메타 태그 및 HTTP 새로 고침 헤더

Netscape는 일정 시간 후 페이지를 새로 고치는 메타 새로 고침 기능을 도입했습니다.그러면 새 URL을 지정하여 한 페이지를 다른 페이지로 바꿀 수 있습니다.이것은 대부분의 [14][15]웹 브라우저에서 지원됩니다.타임아웃이 0초이면 즉시 리다이렉트에 영향을 줍니다.이것은 구글에 의해 301 영구 리다이렉트 처리되어 PageRank를 타겟 [16]페이지로 전송할 수 있습니다.

다음 예시는 이 기술을 사용하는 간단한 HTML 문서의 예입니다.

<http-equiv="Refresh" content="0;url=https://www.example.com/" /> </head> </head> <p> <a href="https://www.example.com/"> 이 링크를 따라 주세요.</a></p> </body> </body> </body>

메타 태그가 문서 내부에 포함되어 있기 때문에 웹 작성자가 이 기술을 사용할 수 있습니다.메타 태그는 HTML 파일의 "head" 섹션에 배치해야 합니다.이 예에서 숫자 "0"을 다른 숫자로 대체하면 이 정도의 지연 시간을 달성할 수 있습니다.본문 섹션의 앵커는 브라우저가 이 기능을 지원하지 않는 사용자를 위한 것입니다.

HTTP에서도 같은 효과를 얻을 수 있습니다.refresh헤더:

HTTP/1.1 200 OK Refresh: 0;url=https://www.example.com/ Content-Type: text/flash Content-Length: 78 이 링크를 따라주세요.< / a >

이 응답은 기본 상태 코드를 변경할 필요가 없기 때문에 CGI 프로그램에서 생성하기가 더 쉽습니다.

이 리다이렉트에 영향을 주는 간단한 CGI 프로그램을 다음에 나타냅니다.

!/usr/bin/module 인쇄물 "갱신: 0; url=https://www.example.com/\r\n"; 인쇄물 "Content-Type: text/html\r\n"; 인쇄물 "\r\n"; 인쇄물 "<a href=\"https://www.example.com/\"> 이 링크를 클릭해 주세요." </a>!"

주의: 보통 HTTP 서버는 상태 행과 Content-Length 헤더를 자동으로 추가합니다.

W3C는 원래 리소스 또는 새 리소스에 대한 정보를 브라우저(또는 검색 엔진)에 전달하지 않기 때문에 메타 새로고침 사용을 권장하지 않습니다.W3C의 Web Content Accessibility Guidelines(7.4)[17]에서는 대부분의 웹 브라우저에서는 새로 고침 속도를 비활성화하거나 제어할 수 없기 때문에 자동 새로 고침 페이지 작성을 권장하지 않습니다.이 문제에 관한 W3C Web Content Accessibility Guidelines (1.0) : 시간에 민감한 콘텐츠 변경에 대한 사용자의 제어 확인, 표준 리다이렉트 사용: 뒤로 버튼 [18]꺾지 말 것! 및 Web Content Accessibility Guidelines 1.0 섹션 [19]7의 핵심 기술 등이 있습니다.

JavaScript 리다이렉트

JavaScript는 다음을 설정하여 리다이렉트를 발생시킬 수 있습니다.window.location속성. 예: 

윈도.위치=https://www.example.com/'

보통 JavaScript는 리디렉터 사이트의 URL을 브라우저 이력으로 푸시합니다.사용자가 뒤로 버튼을 누르면 리다이렉트루프가 발생할 수 있습니다.다음 명령을 사용하면 이러한 유형의 [20]동작을 방지할 수 있습니다. 

윈도.위치.교체하다(https://www.example.com/')

단, 보안상의 이유로 일부 브라우저 및 많은 웹 크롤러에서 JavaScript가 실행되지 않기 때문에 HTTP 헤더 또는 새로 고침 메타 태그가 선호될 수 있습니다.

프레임 리다이렉트

인라인 프레임을 작성하면 약간 다른 효과를 얻을 수 있습니다.

<iframe height="100%" width="100%" src="https://www.example.com/"> 링크 </a>를 따라주세요.</iframe>

위의 리다이렉트 방식의 주요 차이점은 프레임 리다이렉트의 경우 브라우저는 URL 바에 대상 페이지의 URL이 아닌 프레임 문서의 URL을 표시한다는 것입니다.이 클로킹 기술을 사용하여 독자가 보다 기억에 남는 URL을 보거나 웹 [21]사이트 스푸핑의 일부로 피싱 사이트를 부정하게 숨길 수 있습니다.

HTML5 [22]이전에는 타깃페이지를 포함하는 HTML 프레임에서도 같은 효과를 얻을 수 있었습니다.

<frameset rows="100%"> <frame src="https://www.example.com/"> <noframes> <body><a href="https://www.example.com/"> 링크</a>를 참조해 주세요.</body> </noframes> </frameset>

리다이렉트 체인

하나의 리다이렉트가 다른 리다이렉트로 이어질 수 있습니다.예를 들어 URL "https://wikipedia.com" ("*com"을 도메인으로 사용)는 먼저 https://www.wikipedia.org/ (.domain name in.domain)으로 리다이렉트 됩니다.여기서 언어 고유의 사이트로 이동할 수 있습니다.이는 체인의 다른 링크가 다른 서버에 의해 처리되는 경우 피할 수 없는 일이지만 URL을 리다이렉트로 브라우저에 반환하기 전에 가능한 한 서버에 다시 쓰는 것으로 최소화할 필요가 있습니다.

리다이렉트 루프

실수로 인해 페이지가 다른 페이지를 통해 다시 자신에게 리다이렉트되어 무한 리다이렉트 시퀀스가 발생할 수 있습니다.브라우저는 일정 홉카운트 후에 리다이렉트를 정지하고 오류 메시지를 표시합니다.

HTTP/1.1 표준에는 다음과 같이 [23]기술되어 있습니다.

클라이언트는 주기적인 리다이렉션(즉, "무한" 리다이렉션 루프)을 검출하고 개입해야 합니다.

주의: 이 사양의 이전 버전에서는 최대 5개의 리다이렉션을 권장하고 있습니다([RFC 2068], 섹션 10.3).콘텐츠 개발자는 일부 클라이언트가 이러한 고정 제한을 구현할 수 있다는 것을 알아야 합니다.

시퀀스의 URL은 반복되지 않을 수 있습니다.다음은 예를 제시하겠습니다.https://www.example.com/1 -> [1] -> [2[permanent dead link]]...

서비스

온 디맨드로 URL 리다이렉션을 실행할 수 있는 서비스가 존재하기 때문에 기술 작업이나 사이트가 호스트되는 웹 서버에 대한 액세스가 필요하지 않습니다.

URL 리다이렉션서비스

리다이렉트 서비스는 정보 관리 시스템으로 사용자를 원하는 콘텐츠로 리다이렉트하는 인터넷 링크를 제공합니다.사용자에게 일반적인 이점은 기억에 남는 도메인 이름을 사용하고 URL 또는 웹 주소의 길이를 줄일 수 있다는 것입니다.리다이렉트 링크는 Domain Name System과 마찬가지로 호스트를 자주 변경하는 콘텐츠의 영구 주소로도 사용할 수 있습니다.URL 리다이렉션서비스와 관련된 하이퍼링크는 블로그 및 Wiki로 전송되는 스팸 메시지에서 자주 사용됩니다.따라서 스팸을 줄이는 한 가지 방법은 기존의 URL 리다이렉션서비스에 대한 하이퍼링크가 포함된 모든 편집 및 코멘트를 거부하는 것입니다.다만, 정당한 편집 및 코멘트가 삭제되어 스팸을 줄이는 효과적인 방법이 되지 않을 수도 있습니다.최근 URL 리다이렉션서비스는 단축 URL을 작성하기 위한 효율적이고 사용자 친화적인 방법으로 AJAX를 사용하고 있습니다.일부 URL 리다이렉션서비스의 큰 단점은 수익을 창출하기 위해 지연 페이지 또는 프레임 기반 애드버타이즈먼트를 사용하는 것입니다.

역사

최초의 리다이렉트 서비스는, 「.to」(Tonga), 「.at」(오스트리아), 「.is」(아이슬란드)등의 최상위 도메인(TLD)을 이용했습니다.그들의 목표는 기억에 남는 URL을 만드는 것이었다.최초의 주류 리다이렉트 서비스는 2000년에 400만 명의 사용자를 자랑했던 V3.com이었다.V3.com의 성공은 "r.im", "go.to", "i.am", "i.am" 및 "start.at"을 포함한 다양한 짧은 기억에 남는 도메인을 가지고 있었기 때문입니다.V3.com은 1999년 [24]초 대형 무료 웹 호스팅 회사인 FortuneCity.com에 인수되었습니다.최상위 도메인의 판매가격이 연간 70달러에서 10달러 미만으로 떨어지기 시작하면서 리다이렉션 서비스 이용이 줄었다.Tiny 출시와 함께2002년에 URL 단축이라는 새로운 종류의 리다이렉트 서비스가 탄생했습니다.그들의 목표는 긴 URL을 짧게 만들어 인터넷 포럼에 올릴 수 있도록 하는 것이었다.2006년 이후, 매우 인기 있는 트위터 서비스의 글자 수가 140자로 제한되면서, 이러한 짧은 URL 서비스는 많이 사용되고 있다.

레퍼러 마스킹

리다이렉션서비스는 링크가 접속되어 있는 페이지와 그 수신처 사이에 중간 페이지를 배치함으로써 레퍼러를 숨길 수 있습니다.이들은 개념적으로는 다른 URL 리다이렉션서비스와 비슷하지만 다른 목적을 가지고 있으며 수신처 URL을 단축하거나 난독화하려는 시도는 거의 없습니다(이러한 부작용은 레퍼러 정보를 숨기고 다른 웹 사이트 간에 명확한 게이트웨이를 제공하는 것뿐입니다).이러한 유형의 리다이렉션은 쿼리 문자열의 세션 ID 등 잠재적으로 악의적인 링크가 레퍼러를 사용하여 정보를 얻는 것을 방지하기 위해 자주 사용됩니다.많은 대형 커뮤니티 웹사이트는 효과적인 피싱의 가능성을 줄이기 위해 계정 정보를 훔치는 데 사용될 수 있는 악용 가능성을 줄이고 사용자가 언제 서비스를 떠날지 명확히 하기 위해 외부 링크의 링크 리다이렉션을 사용합니다.

다음은 PHP로 작성된 이러한 서비스의 간단한 예입니다. 

<?fls $url = htmlspecialchars($_GET['url']), 헤더('Refresh: 0;url=fl://'. $url); ?> 메타 리프레시를 사용한 폴백. --> <bitle> <tle> 리다이렉트 중...</filename> <http-equiv="filename" content="0;url=filename://<?=$url;>"></head><body><a href="http://<?=$url;"로 리다이렉트 하려고 합니다.> " > http:// <?= $url;?> </a></body> </body>

위의 예에서는 누가 그것을 호출했는지 확인하지 않습니다(예를 들어, 스푸핑할 수 있지만 레퍼러에 의한).또한 제공된 URL은 확인하지 않습니다.즉, 악의적인 사용자는 웹 서버의 리소스를 사용하는 임의의 페이지에서 자신이 선택한 URL 매개 변수를 사용하여 리디렉션 페이지에 연결할 수 있습니다.

보안 문제

URL 리다이렉션은 오픈리다이렉트 및 은닉리다이렉트 등의 피싱 공격에 대해 공격자가 악용할 수 있습니다.「오픈 리다이렉트란, 파라메타를 취득해,[25] 검증 없이 파라메타 값으로 유저를 리다이렉트 하는 애플리케이션입니다.」 「코버트 리다이렉트란, 파라메타를 취득해, 충분한 검증 [26]없이 유저를 파라메타 값으로 리다이렉트 하는 애플리케이션입니다.2014년 5월 싱가포르 [27]난양공대 수학 박사과정 학생인 왕징(王 it)에 의해 공개되었다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b "Google revives redirect snoopery". Blog.anta.net. 29 January 2009. ISSN 1797-1993. Archived from the original on 17 August 2011.
  2. ^ "Redirects & SEO - The Total Guide". Audisto. Retrieved 29 November 2015.
  3. ^ "SEO advice: discussing 302 redirects". Matt Cutts, former Head of Google Webspam Team. 4 January 2006.
  4. ^ "Sneaky Redirects". Google Inc. 3 December 2015.
  5. ^ "Unvalidated Redirects and Forwards Cheat Sheet". Open Web Application Security Project (OWASP). 21 August 2014.
  6. ^ "Redirects & SEO - The Complete Guide". Audisto. Retrieved 29 November 2015.
  7. ^ "PHP Redirects: 302 to 301 Rock Solid Robust Solution". WebSiteFactors.co.uk. Archived from the original on 12 October 2012.
  8. ^ Roy T. Fielding; Julian F. Reschke, eds. (2014). "Location". Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF. p. 68. sec. 7.1.2. doi:10.17487/RFC7231. RFC 7231.
  9. ^ Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry (2005). "Reference Resolution". Uniform Resource Identifier (URI): Generic Syntax. IETF. p. 28. sec. 5. doi:10.17487/RFC3986. RFC 3986.
  10. ^ "Module ngx_http_rewrite_module - rewrite". nginx.org. Retrieved 24 December 2014.
  11. ^ Murenin, Constantine A. (18 February 2013). "A dynamic web-site written wholly in nginx.conf? Introducing mdoc.su!". nginx@nginx.org (Mailing list). Retrieved 24 December 2014.
  12. ^ Murenin, Constantine A. (23 February 2013). "mdoc.su – Short manual page URLs for FreeBSD, OpenBSD, NetBSD and DragonFly BSD". Retrieved 25 December 2014.
  13. ^ Murenin, Constantine A. (23 February 2013). "mdoc.su.nginx.conf". Retrieved 25 December 2014.
  14. ^ "HTML meta tag". www.w3schools.com.
  15. ^ "An Exploration of Dynamic Documents". 2 August 2002. Archived from the original on 2 August 2002.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  16. ^ "Google과 Yahoo는 지연되지 않은 메타 업데이트를 301개의 리디렉션으로 받아들입니다."세바스찬의 팜플렛. 2007년 9월 3일.
  17. ^ "Web Content Accessibility Guidelines 1.0". www.w3.org.
  18. ^ Team, the QA. "Use standard redirects". www.w3.org.
  19. ^ "Core Techniques for Web Content Accessibility Guidelines 1.0". www.w3.org.
  20. ^ "Cross-browser client side URL redirect generator". Insider Zone.
  21. ^ Aaron Emigh(2005년 1월 19일).피싱 방지 테크놀로지 2007년 9월 27일 Wayback Machine에 아카이브(PDF).Radix Labs.
  22. ^ "HTML 5.2: 11. Obsolete features". www.w3.org.
  23. ^ Roy T. Fielding; Julian F. Reschke, eds. (2014). "Redirection 3xx". Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF. p. 54. sec. 6.4. doi:10.17487/RFC7231. RFC 7231.
  24. ^ "Net gains for tiny Pacific nation". BBC News. 14 September 2007. Archived from the original on 12 May 2014. Retrieved 27 May 2010.
  25. ^ "Open Redirect". OWASP. 16 March 2014. Retrieved 21 December 2014.
  26. ^ "Covert Redirect". Tetraph. 1 May 2014. Retrieved 21 December 2014.
  27. ^ "Serious security flaw in OAuth, OpenID discovered". CNET. 2 May 2014. Retrieved 21 December 2014.

외부 링크