URL 리다이렉션
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
URL 리다이렉션은 사용자를 한 웹 페이지에서 다른 웹 페이지로 자동으로 이동시키는 기술이다. 이는 보안 프로토콜 사용, URL 오타 수정, 도메인 변경, 외부 링크 로깅, URL 축약, 장치 타겟팅 등 다양한 목적으로 활용된다. 리다이렉션은 HTTP 상태 코드를 통해 구현되며, 웹 서버 설정, 서버 측 스크립팅, JavaScript, 메타 리프레시 등을 사용하여 구현할 수 있다. URL 리다이렉션 서비스는 URL을 단축하거나 기억하기 쉽게 만들며, Referrer 정보 숨기기에도 사용된다. 그러나 오픈 리다이렉트, 코버트 리다이렉트, 사이트 간 누출 등의 보안 문제와 피싱 공격에 악용될 수 있는 위험이 존재한다.
URL 리다이렉션은 다음과 같은 다양한 목적으로 사용되며, 사용자와 웹사이트 운영자 모두에게 이점을 제공한다.
URL 리다이렉션은 다양한 방법으로 구현할 수 있다. 사용되는 기술은 구현하는 사람의 역할과 시스템 접근 권한에 따라 달라진다.
2. 목적
2. 1. HTTPS 강제
웹사이트는 보안 HTTPS 프로토콜과 일반 HTTP ("http://"로 시작하는 보안되지 않은 URI)를 통해 접속할 수 있다.
사용자가 보안되지 않은 버전으로 접속하거나 링크를 클릭하면, 웹사이트가 HSTS 프리로드 목록에 포함되어 있거나 이전에 해당 사이트를 방문한 적이 있다면 브라우저가 자동으로 보안 버전 (HTTPS)으로 리디렉션한다.[1]
그렇지 않은 경우에는 웹사이트에서 HTTP를 통해 연결된다. 웹사이트 운영자는 브라우저를 HTTPS 버전으로 리디렉션하고, 향후 접속을 위해 HSTS를 준비함으로써 이러한 요청에 응답하도록 설정할 수 있다.[1]
2. 2. 유사 도메인 이름
사용자는 URL을 잘못 입력할 수 있다. 기업들은 종종 이러한 오타 도메인을 등록하고 의도한 위치로 리디렉션한다. 이 기법은 종종 동일한 이름을 가진 다른 최상위 도메인(TLD)을 "예약"하거나 ".com"을 입력하는 사용자를 수용하기 위해 ".edu" 또는 ".net" 사이트를 더 쉽게 만들기 위해 사용된다.
2. 3. 페이지 이동 및 새 도메인
웹 페이지는 다음 세 가지 이유로 새 도메인으로 리디렉션될 수 있다.
URL 리디렉션을 사용하면, 오래된 URL로 연결되는 인바운드 링크를 올바른 위치로 보낼 수 있다. 이러한 링크는 변경 사항을 인지하지 못한 다른 사이트나 사용자가 브라우저에 저장한 북마크/즐겨찾기에서 올 수 있다. 이는 검색 엔진에도 적용된다. 검색 엔진은 종종 데이터베이스에 오래된 도메인 이름과 링크를 가지고 있으며, 검색 사용자를 이러한 오래된 URL로 보낸다. "영구적으로 이동" 리디렉션을 사용하여 새 URL로 리디렉션하면 방문자는 여전히 올바른 페이지에 도달하게 된다. 또한, 다음 검색 엔진 크롤링 시 검색 엔진은 새 URL을 감지하고 사용할 것이다.
2. 4. 외부 링크 로깅
대부분의 웹 서버 접근 로그는 방문자가 어디에서 왔고, 호스팅된 사이트를 어떻게 탐색했는지에 대한 자세한 정보를 기록한다. 하지만 방문자가 어떤 링크를 통해 사이트를 떠났는지는 기록하지 않는다. 이는 방문자가 외부 링크를 클릭할 때, 원래 서버와 통신할 필요가 없기 때문이다. 이 정보는 여러 가지 방법으로 수집할 수 있는데, 한 가지 방법은 URL 리다이렉션을 이용하는 것이다. 방문자를 다른 사이트로 직접 보내는 대신, 사이트의 링크를 원래 웹사이트 도메인의 URL로 연결하여 자동으로 실제 대상 사이트로 리다이렉션되도록 한다. 이 기술은 원래 웹사이트 서버에 대한 추가 요청으로 인해 발생하는 지연이라는 단점을 가지고 있다. 이 추가 요청은 서버 로그에 흔적을 남겨 어떤 링크가 클릭되었는지 정확히 드러내므로, 개인 정보 보호 문제도 야기할 수 있다. 동일한 기술은 일부 기업 웹사이트에서도 사용되는데, 이는 후속 콘텐츠가 다른 사이트에 있으며, 따라서 반드시 해당 기업과 관련이 없음을 명시하기 위한 것이다. 이러한 시나리오에서는 경고를 표시하는 것이 추가적인 지연을 발생시킨다.
2. 5. 긴 URL의 짧은 별칭
웹 애플리케이션은 데이터 계층 구조, 명령 구조, 트랜잭션 경로, 세션 정보 등을 나타내기 위해 긴 URL을 사용하는 경우가 많다. 이러한 URL은 보기 좋지 않고, 기억하기 어려우며, 마이크로블로그 사이트의 글자 수 제한에 맞지 않을 수 있다. URL 축약 서비스를 이용하면 짧은 URL을 생성하여 긴 URL로 리디렉션할 수 있어 이러한 문제를 해결할 수 있다.
2. 6. 길거나 변경되는 URL에 대한 의미 있고 영구적인 별칭
콘텐츠는 그대로 유지되지만 페이지의 URL이 변경되는 경우가 있다. 따라서 URL 리다이렉션은 북마크를 가진 사용자에게 도움이 될 수 있다. 이는 위키백과에서 페이지 이름을 변경할 때마다 일상적으로 수행된다.
2. 7. Post/Redirect/Get
Post/Redirect/Get (PRG)는 사용자가 양식을 제출한 후 새로 고침 버튼을 클릭할 경우 중복된 양식 제출을 방지하는 웹 개발 디자인 패턴으로, 사용자 에이전트를 위한 더 직관적인 인터페이스를 생성한다.
2. 8. 장치 타겟팅 및 지오타겟팅
리다이렉션은 지오타겟팅과 같은 타겟팅 목적으로 효과적으로 사용될 수 있다. 모바일 클라이언트의 증가와 함께, 장치 타겟팅은 점점 더 중요해졌다. 모바일 사용자를 제공하는 데는 두 가지 접근 방식이 있는데, 반응형 웹사이트를 만들거나 모바일 웹사이트 버전으로 리다이렉션하는 것이다. 모바일 웹사이트 버전이 제공되는 경우, 모바일 클라이언트를 사용하는 사용자는 해당 모바일 콘텐츠로 자동 전달된다. 장치 타겟팅의 경우, 클라이언트 측 리다이렉션 또는 캐시 불가능한 서버 측 리다이렉션이 사용된다. 지오타겟팅은 현지화된 콘텐츠를 제공하고 사용자를 요청된 URL의 현지화된 버전으로 자동으로 전달하는 접근 방식이다. 이는 둘 이상의 위치 및/또는 언어의 대상을 타겟팅하는 웹사이트에 유용하다. 일반적으로 지오타겟팅에는 서버 측 리다이렉션이 사용되지만, 요구 사항에 따라 클라이언트 측 리다이렉션도 옵션이 될 수 있다.
2. 9. 검색 엔진 조작 (주의)
리다이렉션은 URL 하이재킹과 같이 비윤리적인 목적으로 검색 엔진을 조작하는 데 사용되어 왔다. 기만적인 리다이렉션의 목표는 자체적으로 순위(랭킹) 파워가 충분하지 않거나 검색 대상과 거의 또는 전혀 관련이 없는 랜딩 페이지로 검색 트래픽을 유도하는 것이다. 이 방법은 검색어 범위에 대한 순위와 검색자를 대상 페이지로 리디렉션하기 위해 교활한 리디렉션을 활용하는 여러 개의 URL이 필요하다. 이러한 방법은 모바일 장치 및 장치 타겟팅의 부상과 함께 다시 부활했다. URL 하이재킹은 임시 리다이렉션에 대한 검색 엔진의 처리를 악용한 도메인 외부 리디렉션 기법이다. 임시 리다이렉션이 발생하면 검색 엔진은 순위(랭킹) 값을 리다이렉션을 초기화하는 URL에 할당할지, 아니면 리다이렉션 대상 URL에 할당할지 결정해야 한다. 리다이렉션이 임시적인 특성을 나타내므로, 리다이렉션을 시작하는 URL은 검색 결과에 표시되도록 유지될 수 있다. 특정 상황에서는 임시 리다이렉션을 순위가 높은 URL에 적용하여 이러한 동작을 악용할 수 있었는데, 이로 인해 검색 결과에서 원래 URL이 리다이렉션을 초기화하는 URL로 대체되어 순위를 "훔치는" 결과를 낳았다. 이 방법은 일반적으로 교활한 리다이렉션과 결합되어 검색 결과에서 사용자의 흐름을 대상 페이지로 다시 타겟팅했다. 검색 엔진은 이러한 종류의 조작적인 접근 방식을 탐지하기 위한 효율적인 기술을 개발했다. 주요 검색 엔진은 이러한 기술을 적용하다가 적발된 사이트에 대해 일반적으로 가혹한 순위 페널티를 적용한다.
2. 10. 방문자 조작 (주의)
URL 리다이렉션은 오픈 리다이렉트와 코버트 리다이렉트와 같은 피싱 공격을 하려는 공격자들이 오용할 수 있다.
오픈 리다이렉트(open redirect)는 매개변수를 취한 다음에 아무런 확인 절차 없이 사용자를 해당 매개변수 값으로 넘겨주는 응용 프로그램이다.[9]
코버트 리다이렉트(covert redirect)는 매개변수를 취한 다음 충분한 확인 절차 없이 사용자를 해당 매개변수 값으로 넘겨주는 응용 프로그램이다.[10] 2014년 5월, 싱가포르의 난양 이공대학의 수학 박사 과정에 있던 왕징이라는 학생이 밝혀냈다.[11]
URL 리다이렉션은 방문자가 어떤 웹사이트를 방문하고 있는지 혼란스럽게 만드는 피싱 공격의 일부로 사용되기도 한다. 최신 브라우저는 항상 주소 표시줄에 실제 URL을 표시하기 때문에 위협이 줄어들었다. 하지만 리다이렉션은 다른 방식으로 공격을 시도하는 사이트로 연결될 수도 있다. 예를 들어, 리다이렉션은 사용자를 속여 바이러스 백신 소프트웨어를 다운로드하게 하고, 대신 어떤 종류의 트로이 목마를 설치하도록 유도하는 사이트로 연결할 수 있다.
2. 11. `referrer` 정보 제거
링크를 클릭하면 브라우저는 리퍼러라는 필드를 보내는데, 여기에는 현재 웹 페이지의 URL이 포함된다. 민감한 URL의 경우, `referrer` 정보가 외부로 유출되는 것을 막기 위해 리다이렉션 페이지를 사용할 수 있다. 예를 들어 `https://externalsite.com/page`와 같은 외부 URL을 `https://redirect.company.com/https://externalsite.com/page`로 변환하는 것이다. 이렇게 하면 세션 ID와 같은 민감한 정보를 리퍼러 URL에서 제거하고, 사용자에게 다른 사이트로 이동했음을 명확히 알려 피싱 위험을 줄일 수 있다.
3. 구현 방법
```html
이 링크를 따라주세요.
```
자동 리다이렉션을 지원하지 않는 브라우저를 위한 대비책으로도 사용된다.
```html
```
위 코드는 3초 후 `http://www.example.com/`으로 이동한다. 검색 엔진 크롤러의 해석이 다를 수 있으므로 주의해야 한다. 야후! 재팬은 0초 리프레시를 301 리다이렉션으로 처리하지만,[6] 구글 검색은 서버 측 301 리다이렉션을 권장한다.[7]
```javascript
window.location='https://www.example.com/'
```
보안상 스크립트 실행을 허용하지 않는 웹 브라우저에서는 작동하지 않으며, 검색 엔진 크롤러에게 이전 사실이 전달되지 않을 수 있다.
3. 1. HTTP 상태 코드 3xx
HTTP 프로토콜은 리다이렉션을 위해 3으로 시작하는 상태 코드를 사용한다. 이 응답은 브라우저가 다른 페이지를 표시하도록 한다. 클라이언트는 리다이렉션을 처리하는 방법에 대한 여러 결정을 내려야 하며, 다른 상태 코드를 사용하여 리다이렉션의 목적, 캐싱 처리 방법, 후속 요청에 사용할 요청 메서드를 이해한다.
HTTP/1.1은 리다이렉션을 위해 다음과 같은 여러 상태 코드를 정의한다([https://tools.ietf.org/html/rfc7231 RFC 7231]):
304 수정되지 않음 및 305 프록시 사용은 리다이렉션이 아니다.
| 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:` 헤더에 기본 선택 사항을 표시한다.
HTTP 헤더에 있는 HTTP 상태 코드를 사용하여 리다이렉션의 종류를 알리고, `Location:` 헤더를 사용하여 이동 대상을 알린다. 종류에는 301 Moved Permanently (영구 이동)이나 302 Found (발견) 등이 있다. 웹 서버의 설정 파일 (아파치의 경우, httpd.conf 파일이나 .htaccess 파일) 또는 CGI 등으로 지정할 수 있다.
3. 1. 1. 301 리다이렉션 예시
httpHTTP/1.1 301 영구 이동
Location: https://www.example.org/
Content-Type: text/html
Content-Length: 174
=이동됨=
이 페이지는 https://www.example.org/로 이동되었습니다.
```
301 "영구 이동" 리다이렉션이 포함된 HTTP 응답 예시다. HTTP 헤더의 HTTP 상태 코드를 통해 리다이렉션 종류를 알리고, `Location:` 헤더를 통해 이동 대상을 알린다.
3. 1. 2. 서버 측 스크립팅
PHP와 같은 서버 측 스크립트 언어를 사용하여 리다이렉션을 구현할 수 있다. 웹 페이지 제작자는 일반적으로 HTML 콘텐츠를 제작할 때 HTTP 헤더를 사용하여 리다이렉션을 생성할 수 없다. HTTP 헤더는 HTML 파일을 제공할 때 웹 서버 프로그램에 의해 자동으로 생성되기 때문이다. CGI 스크립트를 작성하는 프로그래머의 경우에도 마찬가지이지만, 일부 서버에서는 스크립트가 사용자 지정 헤더를 추가할 수 있다(예: "비 구문 분석 헤더"를 활성화하여). 많은 웹 서버는 스크립트가 "Location:" 헤더 라인을 출력하면 3xx 상태 코드를 생성한다. 예를 들어, PHP에서는 "header" 함수를 사용할 수 있다.```php
header('HTTP/1.1 301 영구 이동');
header('Location: https://www.example.com/');
exit();
```
캐싱을 방지하려면 더 많은 헤더가 필요할 수 있다. 프로그래머는 헤더가 본문보다 먼저 출력되도록 해야 한다. 이는 코드의 자연스러운 제어 흐름에 쉽게 맞지 않을 수 있다. 이를 돕기 위해, 서버 측 콘텐츠 생성을 위한 일부 프레임워크는 본문 데이터를 버퍼링할 수 있다. ASP 스크립팅 언어에서는 `response.buffer=true`와 `response.redirect "https://www.example.com/"`를 사용하여 이를 수행할 수도 있다. HTTP/1.1은 상대 URI 참조 또는 절대 URI 참조를 허용한다. URI 참조가 상대적인 경우 클라이언트는 [https://tools.ietf.org/html/rfc3986 RFC 3986]에 정의된 규칙에 따라 필요한 절대 URI 참조를 계산한다.
HTTP 헤더에 있는 HTTP 상태 코드를 사용하여 리다이렉션의 종류를 알리고, Location: 헤더를 사용하여 이동 대상을 알린다. 종류에는 301 Moved Permanently (영구 이동)이나 302 Found (발견) 등이 있다. 웹 서버의 설정 파일 (아파치의 경우, httpd.conf 파일이나 .htaccess 파일) 또는 CGI 등으로 지정할 수 있다.
3. 1. 3. Apache HTTP Server mod_rewrite
아파치 HTTP 서버의 mod_rewrite 모듈을 사용하면 더 유연한 URL 재작성 및 리디렉션을 수행할 수 있다. 예를 들어, 요청을 정규화된 도메인 이름으로 리디렉션하려면 다음과 같이 할 수 있다.[1]```apache
RewriteEngine on
RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC]
RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L]
```
이러한 구성은 서버 구성 파일을 통해 서버의 하나 이상의 사이트에 적용하거나,
.htaccess 파일을 통해 단일 콘텐츠 디렉토리에 적용할 수 있다.[1]3. 1. 4. nginx rewrite
Nginx는 통합 http rewrite 모듈을 사용하여 고급 URL 처리 및 웹 페이지 생성을 지원한다. nginx 구성 언어만 사용하여 결정론적 URL 단축 서비스를 구현하는 mdoc.su가 이러한 rewrite 모듈의 고급 사용 예시이다.예를 들어, `[https://www.dragonflybsd.org/cgi/web-man?command=HAMMER§ion=5 /DragonFlyBSD/HAMMER.5]`에 대한 요청이 들어오면, 먼저 첫 번째 rewrite 지시어를 사용하여 내부적으로 `/d/HAMMER.5`로 리디렉션한다. (아직 클라이언트에게 HTTP 응답을 보내지 않고 내부 상태에만 영향을 미침) 그런 다음 두 번째 rewrite 지시어를 사용하여 클라이언트에게 외부 cgi 스크립트인 web-man 페이지로 실제로 리디렉션하도록 302 Found 상태 코드가 있는 HTTP 응답을 보낸다.
3. 2. Refresh Meta 태그 및 HTTP refresh 헤더
넷스케이프는 일정 시간 후에 페이지를 새로 고치는 메타 리프레시 기능을 도입했다. 이는 한 페이지를 다른 페이지로 대체하기 위해 새 URL을 지정할 수 있는 기능이다. 이 기능은 대부분의 웹 브라우저에서 지원된다. 0초의 시간 초과는 즉시 리디렉션을 발생시키며, 구글에서 301 영구 리디렉션으로 처리되어 페이지랭크를 대상 페이지로 전송할 수 있다.다음은 이 기술을 사용하는 간단한 HTML 문서의 예이다.
```html
Please follow this link.
```
이 기술은 웹 디자이너가 사용할 수 있는데, 그 이유는 메타 태그가 문서 자체 내에 포함되어 있기 때문이다. 메타 태그는 HTML 파일의 "head" 섹션에 배치해야 한다. 이 예제에서 숫자 "0"은 다른 숫자로 대체하여 해당 초만큼 지연시킬 수 있다. "body" 섹션의 앵커는 이 기능을 지원하지 않는 브라우저 사용자를 위한 것이다.
HTTP `refresh` 헤더를 사용하여 동일한 효과를 얻을 수도 있다.
```http
HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/
Content-Type: text/html
Content-Length: 78
Please follow this link.
```
이 응답은 CGI 프로그램으로 생성하기가 더 쉬운데, 그 이유는 기본 상태 코드를 변경할 필요가 없기 때문이다.
다음은 이 리디렉션을 실행하는 간단한 CGI 프로그램이다.
```perl
# !/usr/bin/perl
print "Refresh: 0; url=https://www.example.com/\r\n";
print "Content-Type: text/html\r\n";
print "\r\n";
print "Please follow this link!"
```
참고: 일반적으로 HTTP 서버는 상태 줄과 Content-Length 헤더를 자동으로 추가한다.
W3C는 메타 리프레시의 사용을 권장하지 않는데, 이는 브라우저 (또는 검색 엔진)에 원래 리소스나 새 리소스에 대한 정보를 전달하지 않기 때문이다. W3C의 웹 콘텐츠 접근성 지침(7.4)은 자동 새로 고침 페이지의 생성을 권장하지 않는데, 그 이유는 대부분의 웹 브라우저가 사용자가 새로 고침 빈도를 비활성화하거나 제어할 수 없기 때문이다. 이에 대한 W3C의 관련 문서로는 [https://www.w3.org/TR/WAI-WEBCONTENT/#gl-movement W3C 웹 콘텐츠 접근성 지침 (1.0): 시간 민감 콘텐츠 변경의 사용자 제어 보장], [https://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-avoid-auto-redirect 표준 리디렉션 사용: 뒤로 가기 버튼을 망가뜨리지 마세요!] 및 [https://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-no-periodic-update 웹 콘텐츠 접근성 지침 1.0의 핵심 기술 섹션 7.] 등이 있다.
HTML 문서의 head 요소 내에 meta 요소의 http-equiv 속성 값에 "refresh"를 기술한다. content 속성으로 문서를 읽어들인 후 몇 초 후에 전송할지를 지정한다. HTTP 상태 코드는 리다이렉션 없이 직접 액세스한 경우와 동일한 코드가 반환된다.
; meta 태그 기술 예
: ``로 설정하면, 3초 후에 `http://www.example.com/`로 자동 전송된다.
: content="3"의 3 부분은 전송까지의 시간을 의미한다.
; 크롤러의 해석
: 각종 검색 사이트의 크롤러의 해석은 각기 다르므로 주의가 필요하다. 0초의 경우, 야후! 재팬의 경우 301 리다이렉션(영구적인 리다이렉션)으로 처리된다[6] . 구글 검색의 경우 서버 측에서 301 리다이렉션 사용을 권장하고 있다[7] .
3. 3. JavaScript 리다이렉션
자바스크립트는 `window.location` 속성을 설정하여 리다이렉션을 발생시킬 수 있다. 다음은 그 예시이다.```javascript
window.location='https://www.example.com/'
```
일반적으로 자바스크립트는 리다이렉션 대상 사이트의 URL을 브라우저의 방문 기록에 추가하므로, 사용자가 뒤로 가기 버튼을 누를 때 리다이렉션 루프가 발생할 수 있다. 이러한 동작은 다음 명령을 사용하여 방지할 수 있다.
```javascript
window.location.replace('https://www.example.com/')
```
그러나 보안상의 이유와 일부 브라우저 및 많은 웹 크롤러에서 자바스크립트가 실행되지 않기 때문에, HTTP 헤더 또는 리프레시 메타 태그가 더 선호될 수 있다.
자바스크립트와 같은 클라이언트 스크립트를 사용하여 자동으로 페이지 전환 처리를 기술하여 전송할 수 있으며, `location` 또는 `location.href`에 대입하는 방법 등이 있다.[8]
보안 등의 이유로 스크립트 실행을 허용하지 않는 웹 브라우저에서는 페이지가 전송되지 않는다. HTTP 응답에서는 리다이렉션 없이 직접 접근한 경우와 동일한 상태 코드가 반환되므로, 검색 엔진 등의 크롤러에게 페이지가 이전되었다는 사실이 전달되지 않을 수도 있다.
3. 4. Frame 리다이렉션
프레임을 인라인으로 생성하여 약간 다른 효과를 얻을 수 있다. 프레임 리다이렉션의 경우 브라우저가 URL 표시줄에 대상 페이지의 URL이 아닌 프레임 문서의 URL을 표시한다는 것이 주요한 차이점이다. 이 '클로킹' 기법은 독자가 더 기억하기 쉬운 URL을 보거나 피싱 사이트를 웹사이트 스푸핑의 일부로 사기적으로 숨기기 위해 사용될 수 있다.HTML5 이전에는 대상 페이지를 포함하는 HTML 프레임으로 동일한 효과를 낼 수 있었다.
3. 5. 리다이렉션 체인
하나의 넘겨주기는 넘겨주기 체인에서 다른 넘겨주기로 연결될 수 있다. 넘겨주기가 다른 넘겨주기로 연결되는 경우, 이를 이중 넘겨주기라고도 한다.[1] 예를 들어, "https://wikipedia.com" (도메인으로 "*.com") URL은 먼저 .org 도메인 이름의 https://www.wikipedia.org/ 로 넘겨지며, 여기에서 https://en.wikipedia.org/ 언어별 사이트로 이동할 수 있다. 이는 체인의 서로 다른 링크가 서로 다른 서버에서 제공되는 경우 불가피하지만, 서버에서 브라우저에 넘겨주기로 반환하기 전에 URL을 최대한 ''다시 쓰기''를 통해 최소화해야 한다.3. 6. 리다이렉션 루프
페이지가 다른 페이지를 거쳐 다시 자기 자신에게 리다이렉션되면 무한 리다이렉션 시퀀스가 발생할 수 있다. 브라우저는 특정 횟수 이후 리다이렉션을 중단하고 오류 메시지를 표시한다. HTTP/1.1 표준에서는 클라이언트가 순환 리다이렉션을 감지하고 중단해야 한다고 명시하고 있다. 이전 버전의 표준에서는 최대 5번의 리다이렉션을 권장했지만, 콘텐츠 개발자는 일부 클라이언트가 이러한 고정 제한을 구현할 수 있다는 점을 인지해야 한다.4. 서비스
웹 서버에 대한 기술적인 작업이나 접근 없이 URL 리다이렉션을 수행하는 서비스가 있다.
4. 1. URL 리다이렉션 서비스
URL 리다이렉션 서비스는 사용자를 원하는 콘텐츠로 리디렉션하는 인터넷 링크를 제공하는 정보 관리 시스템이다. 사용자는 일반적으로 기억하기 쉬운 도메인 이름을 사용하고 URL 또는 웹 주소의 길이를 줄일 수 있다는 이점이 있다. 리디렉션 링크는 도메인 네임 시스템과 유사하게 호스트가 자주 변경되는 콘텐츠의 영구적인 주소로도 사용될 수 있다.URL 리다이렉션 서비스를 포함하는 하이퍼링크는 블로그 및 위키를 대상으로 하는 스팸 메시지에 자주 사용된다. 따라서 스팸을 줄이는 한 가지 방법은 알려진 URL 리다이렉션 서비스에 대한 하이퍼링크를 포함하는 모든 편집 및 댓글을 거부하는 것이다. 그러나 이는 합법적인 편집 및 댓글도 제거할 수 있으며 스팸을 줄이는 효과적인 방법이 아닐 수 있다.
최근, URL 리다이렉션 서비스는 단축된 URL을 생성하기 위한 효율적이고 사용자 친화적인 방법으로 AJAX를 사용하기 시작했다. 일부 URL 리다이렉션 서비스의 주요 단점은 수익을 창출하기 위해 지연 페이지 또는 프레임 기반 광고를 사용한다는 것이다.
4. 1. 1. 역사
최초의 리다이렉션 서비스는 최상위 도메인 (TLD)인 .to (통가), .at (오스트리아), .is (아이슬란드)를 활용했다. 이 서비스들의 목표는 기억하기 쉬운 URL을 만드는 것이었다. 최초의 주류 리다이렉션 서비스는 2000년에 최고 4백만 명의 사용자를 자랑했던 V3.com이었다. V3.com의 성공은 "r.im", "go.to", "i.am", "come.to", "start.at"을 포함한 다양하고 짧으며 기억하기 쉬운 도메인을 보유한 덕분이었다. V3.com은 1999년 초에 대규모 무료 웹 호스팅 회사인 FortuneCity.com에 인수되었다. 최상위 도메인의 판매 가격이 연간 50USD에서 10USD 미만으로 떨어지면서 리다이렉션 서비스의 사용은 감소했다. 2002년 TinyURL이 출시되면서 새로운 종류의 리다이렉션 서비스, 즉 URL 단축이 등장했다. 이 서비스의 목표는 긴 URL을 짧게 만들어 인터넷 포럼에 게시할 수 있도록 하는 것이었다. 2006년부터 매우 인기 있는 트위터 서비스의 140자 제한으로 인해 이러한 짧은 URL 서비스가 널리 사용되었다.4. 2. Referrer 마스킹
리다이렉션 서비스는 링크가 있는 페이지와 대상 페이지 사이에 중간 페이지를 배치하여 Referrer를 숨길 수 있다. 이는 다른 URL 리다이렉션 서비스와 개념적으로 유사하지만, 다른 목적을 수행하며, 대상 URL을 단축하거나 난독화하려는 시도는 거의 없다. (유일한 의도된 부작용은 리퍼러 정보를 숨기고 다른 웹사이트 간의 명확한 게이트웨이를 제공하는 것이다.) 이러한 유형의 리다이렉션은 잠재적으로 악의적인 링크가 리퍼러를 사용하여 정보를 얻는 것을 방지하기 위해 자주 사용된다. 예를 들어 쿼리 문자열의 세션 ID가 있다. 많은 대형 커뮤니티 웹사이트는 외부 링크에 링크 리다이렉션을 사용하여 계정 정보를 훔치는 데 사용될 수 있는 악용 가능성을 줄이고, 사용자가 서비스를 떠날 때 이를 명확히 하여 효과적인 피싱의 가능성을 줄인다.5. 보안 문제
URL 리다이렉션은 피싱 공격에 악용될 수 있다.[9]
URL 리다이렉션은 또한 사이트 간 누출 공격을 수행하는 메커니즘을 제공한다. 웹사이트가 특정 페이지를 반환하는 데 걸린 시간을 측정하거나, 한 대상 페이지를 다른 대상 페이지와 구별함으로써, 공격자는 다른 웹사이트의 상태에 대한 상당한 정보를 얻을 수 있다. 2021년, Knittel 등은 크롬의 성능 API 구현에서 교차 출처 리다이렉션을 안정적으로 감지할 수 있는 취약점을 발견했다.[5]
5. 1. 오픈 리다이렉트
웹 애플리케이션이 리다이렉션 대상을 충분히 검증하지 않으면, 공격자는 웹 애플리케이션을 임의의 웹사이트로 리다이렉션하도록 만들 수 있다.[9] 오픈 리다이렉트는 매개변수를 취한 뒤 아무런 확인 절차 없이 사용자를 해당 매개변수 값으로 넘겨주는 애플리케이션이다.[9]5. 2. 코버트 리다이렉트
인증 흐름의 일부로 오픈 리다이렉션이 발생하면, 공격자는 피해자 웹사이트로부터 인증 정보를 훔칠 수 있다.[10] 코버트 리다이렉트는 매개변수를 취한 다음 충분한 확인 절차 없이 사용자를 해당 매개변수 값으로 넘겨주는 응용 프로그램이다.[10] 2014년 5월, 싱가포르 난양 이공대학의 수학 박사 과정에 있던 왕징 학생이 이를 밝혀냈다.[11]참조
[1]
웹사이트
Double Redirects May Take Google More Time To Pick Up On
https://www.seroundt[...]
2024-01-28
[2]
서적
Annual Computer Security Applications Conference
Association for Computing Machinery
2023-12-04
[3]
웹사이트
What is an Open Redirect vulnerability, why is it dangerous and how can you stay safe?
https://www.techrada[...]
2024-04-08
[4]
웹사이트
CWE - CWE-601: URL Redirection to Untrusted Site ('Open Redirect') (4.14)
https://cwe.mitre.or[...]
2024-04-08
[5]
서적
Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security
Association for Computing Machinery
2021-11-13
[6]
웹사이트
リダイレクトとは？
https://info-search.[...]
ヤフー株式会社
2019-03
[7]
웹사이트
Google がサポートしているメタタグ
https://support.goog[...]
Google
2019-03
[8]
웹사이트
window.location - Web API インターフェイス
https://developer.mo[...]
MDN
2019-03
[9]
웹인용
Open Redirect
https://www.owasp.or[...]
OWASP
2014-12-21
[10]
웹인용
Covert Redirect
http://tetraph.com/c[...]
Tetraph
2014-12-21
[11]
웹인용
Serious security flaw in OAuth, OpenID discovered
http://www.cnet.com/[...]
CNET
2014-12-21
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com