[TIL] HTTP : The Definitive Guide "p283 ~ p284"

시윤·2025년 3월 23일

TIL http

[TIL] Two Pages Per Day

목록 보기

116/146

Chapter 12. Basic Authentication

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

✏️ 원문 번역

Proxy Authentication

Authentication also can be done by intermediary proxy servers. Some organizations use proxy servers to authenticate users before letting them access servers, LANs, or wireless networks. Proxy servers can be a convenient way to provide unified access control across an organization’s resources, because access policies can be centrally administered on the proxy server. The first step in this process is to establish the identity via proxy authentication.

인증은 중간에 위치한 프록시 서버에 의해 수행될 수도 있습니다.
일부 기업은 프록시 서버를 사용하여 서버나 LAN, 무선 네트워크에 접근하기 전 우선적으로 사용자를 인증합니다.
프록시 서버는 기업의 리소스에 대해 통합된 접근 제어 방식을 제공할 수 있는 편리한 수단입니다.
중앙에 위치한 프록시 서버에서 접근 정책을 관리할 수 있기 때문입니다.
프록시 인증의 첫 번째 절차는 신원을 확인하는 것입니다.

The steps involved in proxy authentication are identical to that of web server identification. However, the headers and status codes are different. Table 12-3 contrasts the status codes and headers used in web server and proxy authentication.

프록시 인증의 과정은 웹 서버에서 이루어지는 것과 동일합니다.
하지만 헤더와 상태 코드가 다릅니다.
Table 12-3은 웹 서버와 프록시 인증의 상태 코드 및 헤더 차이점을 나타냅니다.

The Security Flaws of Basic Authentication

Basic authentication is simple and convenient, but it is not secure. It should only be used to prevent unintentional access from nonmalicious parties or used in combination with an encryption technology such as SSL.

Basic Authentication은 간단하고 편리하지만 안전하지 않습니다.
악의적이지 않은 그룹이 의도치 않게 리소스에 접근하는 것을 막거나 SSL과 같은 암호화 기술을 결합하였을 때만 사용하는 것이 좋습니다.

Consider the following security flaws:

다음의 보안상 결함을 고려해봅시다.

Basic authentication sends the username and password across the network in a form that can trivially be decoded. In effect, the secret password is sent in the clear, for anyone to read and capture. Base-64 encoding obscures the username and password, making it less likely that friendly parties will glean passwords by accidental network observation. However, given a base 64–encoded username and password, the decoding can be performed trivially by reversing the encoding process. Decoding can even be done in seconds, by hand, with pencil and paper! Base 64–encoded passwords are effectively sent “in the clear.” Assume that motivated third parties will intercept usernames and passwords sent by basic authentication. If this is a concern, send all your HTTP transactions over SSL encrypted channels, or use a more secure authentication protocol, such as digest authentication.

Basic Authentication은 네트워크를 통해 username과 password를 전송합니다. username과 password는 쉽게 디코딩될 수 있는 형태입니다.
사실상 비밀이 유지되어야 하는 password가 누구나 읽고 캡처할 수 있을 만큼 공개적으로 전송됩니다.
Base-64 인코딩은 username과 password를 모호하게 만들어 우호적인 구성원들이 네트워크 관찰에 의해 우연히 비밀번호를 보게 될 가능성을 줄입니다.
하지만 Base-64로 인코딩된 username과 password는 인코딩의 역과정을 통해 쉽게 디코딩할 수 있습니다.
연필과 종이를 사용하면 손으로도 몇 초 안에 디코딩을 수행할 수 있습니다.
Base-64 인코딩된 비밀번호는 효율적으로 "투명하게" 전송됩니다.
Basic Authentication을 통해 전송되는 username과 password를 탈취하려는 제삼의 구성원이 있다고 가정해봅시다.
이러한 상황이 우려된다면 SSL로 암호화된 채널에서 모든 HTTP 트랜잭션을 전송하거나 Digest Authentication과 같은 보다 안전한 인증 프로토콜을 사용하는 것이 좋습니다.

Even if the secret password were encoded in a scheme that was more complicated to decode, a third party could still capture the garbled username and password and replay the garbled information to origin servers over and over again to gain access. No effort is made to prevent these replay attacks.

비밀번호가 디코딩이 복잡한 방식으로 암호화되었더라도 제삼자가 여전히 암호화된 username과 password를 캡처한 후 계속해서 암호화된 정보를 원본 서버에 그대로 전달하여 접근 권한을 획득할 수 있습니다.
이러한 Replay 공격에 대해서는 막을 도리가 없습니다.

Even if basic authentication is used for noncritical applications, such as corporate intranet access control or personalized content, social behavior makes this dangerous. Many users, overwhelmed by a multitude of password-protected services, share usernames and passwords. A clever, malicious party may capture a username and password in the clear from a free Internet email site, for example, and find that the same username and password allow access to critical online banking sites!

Basic Authentication이 기업의 인트라넷 접근 제어나 개인적인 콘텐츠 등 중요하지 않은 응용 프로그램에서 사용되고 있더라도 소셜 활동에 의해 위험에 처할 수 있습니다.
비밀번호를 사용하는 수많은 서비스에서 많은 사용자가 username과 password를 공유하고 있습니다.
현명하지만 악의적인 제삼자는 무료 인터넷 이메일 사이트를 통해 username과 password를 투명하게 캡처한 후, 동일한 username과 password를 사용하여 치명적인 온라인 뱅킹 사이트에 접근할 수도 있습니다.

Basic authentication offers no protection against proxies or intermediaries that act as middle men, leaving authentication headers intact but modifying the rest of the message to dramatically change the nature of the transaction.

Basic Authentication은 중개자로서의 역할을 수행하는 프록시에 대한 보호를 제공하고 있지 않습니다.
인증 헤더는 그대로 유지하면서 트랜잭션의 성격을 극단적으로 변화시키도록 메시지의 나머지 부분을 수정합니다.

Basic authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a valid host protected by basic authentication when, in fact, he is connecting to a hostile server or gateway, the attacker can request a password, store it for later use, and feign an error.

Basic Authentication은 위조 서버의 스푸핑에 취약합니다.
사용자는 자신이 Basic Authentication에 의해 보호되는 유효한 호스트에 접속하고 있다고 믿지만 실제로는 적대적인 서버나 게이트웨이에 연결중일 수 있습니다.
공격자는 추후에 사용하기 위해 비밀번호를 요청 및 저장한 후 오류인 척 가장하기도 합니다.

This all said, basic authentication still is useful for providing convenient personalization or access control to documents in a friendly environment, or where privacy is desired but not absolutely necessary. In this way, basic authentication is used to prevent accidental or casual access by curious users.

친숙한 환경 혹은 보안이 권장되지만 필수적이지는 않은 환경 내에서 문서를 편리하게 개인화하고 접근 제어를 제공한다는 점에서 Basic Authentication은 여전히 유용합니다.
호기심 많은 사용자에 의한 우발적인 접근을 방지하기 위해 사용할 수 있다는 의의가 있습니다.

For example, inside a corporation, product management may password-protect future product plans to limit premature distribution. Basic authentication makes it sufficiently inconvenient for friendly parties to access this data.† Likewise, you might password-protect personal photos or private web sites that aren’t top-secret or don’t contain valuable information, but really aren’t anyone else’s business either.

예를 들어 기업 내에서 상품을 관리하는 데 비밀번호를 사용할 수 있습니다.
비밀번호는 미래의 상품 계획이 조기에 유출되는 것을 막습니다.
Basic Authentication은 우호적인 구성원들이 데이터에 접근하는 것을 불편하게 만들 수 있습니다.
마찬가지로 다른 이의 비즈니스에 관한 것이 아닌 개인적인 사진이나 웹 사이트를 비밀번호로 보호할 수도 있습니다.
이는 일급비밀이나 가치 있는 정보를 포함하지 않은 콘텐츠입니다.

Basic authentication can be made secure by combining it with encrypted data transmission(such as SSL) to conceal the username and password from malicious individuals. This is a common technique.

Basic Authentication은 암호화 데이터 전송 기법(SSL)과 결합하여 보안을 강화할 필요가 있습니다.
username과 password를 악의적인 사용자로부터 숨기는 것입니다.
아주 일반적으로 이루어지는 보안입니다.

We discuss secure encryption in Chapter 14. The next chapter explains a more sophisticated HTTP authentication protocol, digest authentication, that has stronger security properties than basic authentication.

Chapter 14에서 보안 암호화에 대해 논의합니다.
다음 챕터에서는 정교한 HTTP 인증 프로토콜인 Digest Authentication에 대해 설명합니다.
Digest Authentication은 Basic Authentication에 비해 더 강력한 보안 특성을 제공하고 있습니다.

✏️ 요약

Proxy Authentication Features

: 프록시 서버에 의해 인증이 수행될 때 나타나는 요청/응답 특성

통합된 접근 제어 제공 -> 서버나 LAN, 무선 네트워크에 접근하기 전 먼저 사용자를 인증하여 보안 확보
Proxy-Authenticate = WWW-Authenticate
Proxy-Authorization = Authorization
Proxy-Authentication-Info = Authentication-Info
Unauthorized Status Code로 407 사용

The Security Flaws of Basic Authentication

: Basic Authentication의 보안상 결함

Base-64의 손쉬운 디코딩 : 비밀번호 유출 위험이 있으므로 SSL을 사용하거나 Digest Authentication을 사용하는 것이 좋음
Replay 공격 : 암호화된 비밀번호를 캡처해서 그대로 서버에 전달한 후 접근 권한을 획득할 수 있음
여러 서비스에서 비밀번호를 공유하는 경우 : Basic Authentication을 사용하는 인트라넷 등에서 비밀번호를 탈취하여 온라인 뱅킹 사이트에서 사용하는 등의 공격이 가능함
프록시 보호 기능 부재 : 인증 헤더는 유지하면서 메시지의 나머지 부분을 수정하여 공격이 가능함
스푸핑 공격 : 중간에서 호스트를 바꿔치기 하여 비밀번호를 탈취할 수 있음

✏️ 감상

Spoofing

스푸핑 공격이라고 함은 공격자가 시스템을 속여 정보를 탈취하는 등의 악의적인 일체의 행위를 말한다. 시스템을 구체적으로 어떻게 속이는지에 따라서 스푸핑의 종류도 천차만별이다. 아마 가장 많이 알려진 스푸핑 기법은 IP 스푸핑일 것이다.

IP 스푸핑은 말 그대로 공격자가 자신의 IP를 속여서 시스템에 접근하는 공격 기법이다. 부당하게 탈취한(?) IP를 도용하여 시스템에 해를 끼치고 있다면 전부 IP 스푸핑에 해당한다. 예를 들어, 마치 자신이 원본 서버인 척 클라이언트와 통신하며 패킷을 가로채고 위조된 패킷을 전송하는 것은 IP 스푸핑이다. 탈취한 IP를 돌려가면서 타겟 서버에 지속적으로 요청을 전송하여 서비스를 중단시키는 DDoS 공격도 IP 스푸핑의 일종이다.

IP 스푸핑에 의한 피해를 방지하기 위해서는 SSO(Single Sign-On)를 사용하는 것이 좋다. SSO는 한 번 로그인하면 이후에 추가적인 로그인 없이 시스템에 접근할 수 있게 하는 기법이다. IP 주소 기반의 인증뿐만 아니라 토큰 기반 인증을 채택하고 있기 때문에 IP가 탈취당하더라도 토큰이 유효하지 않으면 시스템에 접근할 수 없다.

SSO와 대조되는 방식으로는 트러스트가 있다. 트러스트는 시스템에 접속하려는 사용자가 신뢰할 수 있는 IP 범위 내에 있을 때 접근을 허용하는 방식을 택한다. 예를 들어 사용자가 사설 IP로 사내 시스템에 접근하려 하는 경우 사내 시스템은 해당 사용자를 신뢰할 수 있는 사용자로 간주한다. 따라서 사용자가 특정 네트워크에서 별도의 인증 없이 빠르게 시스템에 접근할 수 있다는 장점이 있다. 문제는 IP가 스푸핑 당한 경우에도 시스템은 해당 사용자를 신뢰하여 동일하게 리소스를 전달할 수 있다는 점이다. 정말 스푸핑이 발생해서는 안 되는 시스템이라면 트러스트 대신 SSO를 사용하도록 하자.

그 밖에도 IP보다 더 낮은 레이어(MAC)에서 스푸핑을 수행하는 ARP 스푸핑 등이 있다. ARP 스푸핑을 대처하는 방법은... 다음에 더 알아보도록 하겠다.

Replay

보안 수업에서 들었던 악명 높은 그 이름...ㅎㅎ 바로 리플레이다. 암호화를 하거나 말거나 패킷을 그대로 가로채서 전달하기 때문에 정보를 노출시키지 않기 위한 모든 노력을 그야말로 무력화시킬 수 있다.

리플레이 공격이 금전적인 요소와 연결되면 상당히 골치가 아프다. 사용자가 은행에서 10만 원을 이체하려는 트랜잭션이 있었고, 공격자가 그것을 탈취해서 10번 실행했다고 해보자. 그럼 의도치않게 100만 원이 이체가 되는 것이다. ~~물론 실제 은행 시스템이 이렇게 단순하지는 않겠지만 예를 들자면 그렇다는 거다.~~

리플레이 공격에 대응하는 간단한 방법 중 하나는 각 메시지에 타임스탬프를 추가하는 것이다. 타임스탬프를 사용하면 요청이 유효한 시간 내에만 처리되도록 보장할 수 있다. 리플레이 공격의 경우 항상 원본 요청보다 늦게 전송된다. 서버측에서 타임스탬프를 확인한 후 일정 시간을 초과한 리플레이 요청이 오는 경우 응답하지 않을 수 있다. 하지만 공격 시점과 원본 요청 시점에 큰 차이가 없는 경우 리플레이 공격이 성공할 가능성이 있다. 때문에 리플레이 공격의 또다른 대응 방안으로 nonce(One-Time Token)를 사용하기도 한다. 서버는 요청에 담긴 nonce 값이 이전에 사용되었는지 확인하여 해당 요청이 원본인지 리플레이인지 구분할 수 있다.