[12장] 기본 인증

[eunbc]

No description provided.

[annahxxl]

인증

인증 프로토콜과 헤더

보안 영역

• 보안 영역(realm)은 저마다 다른 사용자 권한을 요구한다

  HTTP/1.0 401 Unauthorized
  WWW-Authenticate: Basic realm="어쩌고"

기본 인증

Base-64 사용자 이름/비밀번호 인코딩

• HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론으로 이어서 합치고, base-64 인코딩 메서드를 사용해 인코딩 한다
• base-64 인코딩은 8비트 바이트로 이루어져 있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다
• 대부분 문자와 숫자로 이루어진 특별한 64개의 문자 중에서 선택된다
• 뜻하지 않게 사용자 이름과 비밀번호가 노출되는 문제를 예방

프락시 인증

• 프락시 서버에서 접근 정책을 중앙 관리 할 수 있기 때문에, 회사 리소스 전체에 대한 통합적인 접근 제어를 하기 위해서 프락시 서버를 사용하면 좋다

기본 인증의 보안 결함

• base-64로 인코딩된 사용자 이름과 비밀번호는 어렵지 않게 디코딩할 수 있다
• 더 복잡한 방식으로 인코딩되어 있다고 하더라도, 가로채서 인증에 성공할 수 있다
• 사용자는 모든 사이트에 같은 아이디와 비밀번호를 사용하는데, 다른 중요한 사이트에 접근할 수도 있다
• 프락시나 중개자가 중간에 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다
• 사용자가 가짜 서버에 연결되어 있는데도, 기본 인증을 수행할 수 있다

결론

• 기본 인증은 다른 사람들이 보지 않기를 원하지만, 보더라도 치명적이지 않은 경우 유용
• SSL과 함께 연계해서 사용 가능

[byulcode]

12.1 인증

인증(Authentication) : 보호된 리소스에 접근하는 것을 허용하기 이전에 등록된 유저의 신원을 입증하는 과정(ex 로그인)

HTTP의 인증요구/응답 프레임워크

웹 에플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대신에 현재 사용자가 누구인지를 알 수 있게 비밀번호 같이 개인 정보를 요구하는 '인증 요구'로 응답할 수 있다.

사용자가 다시 요청을 보낼 때는 인증 정보를 첨부해야한다. 인증정보가 맞지 않으면 서버는 클라이언트에 다시 인증요구를 보내거나 에러를 낼 수 있다.

인증 프로토콜과 헤더

HTTP는 커스텀이 가능한 제어 헤더를 통해 다양한 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다.

인증 단계

1. 사용자가 인증 요구를 보내면, 서버는 401 Unauthorized 응답과 함께 WWW-Authenticate 헤더를 기술해서 어디서 어떻게 인증할지 설명한다
2. 클라이언트가 서버로 인증하려면, 인코딩된 비밀번호와 그 외 인증 파라미터들을 Authorization 헤더에 담아서 요청을 다시 보낸다
3. 인증이 성공하면 서버는 200 OK를 반환하며, 추가적인 정보를 Authentication-Info헤더에 기술할 수 있다

보안 영역

웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나눈다. 보안 영역은 저마다 다른 사용자 권한을 요구한다.

12.2 기본 인증

웹 서버는 클라이언트의 요청을 거부하고 ID/PW를 요구할 수 있다.

• 401 상태코드, 접근하고자 했던 realm을 WWW-Authenticate에 기술해서 인증 요구를 시작한다

  WWW-Authenticate: Basic realm=”문서 집합 정보”

• 브라우저는 사용자 ID/PW를 입력 받아 Authorization 요청 헤더 안에 암호화해서 서버로 전송한다.

  Authorization: Basic base-64로 인코딩한 ID/PW

Base-64로 사용자 이름/PW 인코딩

Base-64 인코딩은 HTTP 헤더에서 사용할 수 없는 문자를 포함한 ID/PW를 전송하는데 유용하다

절차	예
1. 사용자 이름과 비밀번호를 입력받는다	ID: brian-totty / PW: Ow!
2. 사용자 이름, 비밀번호를 콜론으로 이어붙인다	brian-totty:Ow!
3. Base 64 인코딩	BASE64ENC(brian-totty:Ow!) -> YnJpYW4tdG90dHk6T3ch
4. 인가 요청을 보낸다	GET /family/jeff.jpg HTTP/1.0 Authorization: Basic YnJpYW4tdG90dHk6T3ch

프락시 인증

프락시 서버를 사용하면 접근 정책을 중앙 관리할 수 있어 프락시를 통한 사용자 인증을 사용하는 경우도 있다

12.3 기본 인증의 보안 결함

• 탈취당할 경우 누구나 쉽게 디코딩할 수 있다
• 디코딩 할 수 없더라도 서버로 그대로 전송해서 인증에 성공할 수 있다
• 프락시와 같은 중개자가 개입하는 경우 기본 인증은 정상적인 동작을 보증하지 않는다
• 가짜 서버의 위장에 취약하다

⇒ 기본 인증은 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는데 사용하거나, SSL 같은 암호 기술과 혼용해서 사용한다

[park0jae]

인증

• HTTP는 사용자 인증을 하는데 사용하는 자체 인증요구/응답 프레임워크를 제공
• 웹 애플리케이션이 HTTP 요청 메세지를 수신
  • 서버는 요청을 처리하는 대신 현재 사용자를 식별할 수 있는 ‘인증 요구’로 응답
  • ‘인증 요구 응답’을 받은 사용자는 다시 요청을 보낼 때 인증 정보(사용자 이름 & 패스워드)를 첨부해야 함

기본 인증 프로토콜과 헤더

단계	헤더	설명	메서드/상태
요청		첫 번째 요청에는 인증정보 X	GET
인증 요구	WWW-authenticate	서버의 ‘인증 요구’ 응답	401 Unauthorized
인증	Authorization	클라이언트의 인증정보를 통한 재요청	GET
성공	Authentication-Info	인증정보 정확 → 서버는 문서와 함께 응답	200 OK

보안 영역

WWW-Authenticate: Basic realm="Family"

• 웹 서버는 기밀 문서를 보안 영역(realm) 그룹으로 나눈다
• 보안 영역은 저마다 다른 사용자 권한을 요구한다.

기본 인증

• 기본 인증은 가장 잘 알려진 HTTP 인증 규약
• 기본 인증에서 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있음
• 서버는 200 대신 401 상태 코드와 함께 보안 영역을 WWW-authenticate에 기술해 응답하여 인증 요구를 시작
• 인증 정보를 포함하여 요청하라는 응답을 받은 클라이언트는 사용자 계정과 비밀번호를 입력하는 대화상자를 연다.

ex) 인증 예시

• 사용자가 자신의 가족사진인 /family/jeff.jpg 요청
• 서버가 WWW-Authenticate 헤더와 함께 개인 가족사진에 접근하는데 필요한 비밀번호를 요구하는 401 Unauthorization Required 응답을 반환
• 브라우저가 401 응답을 받고, Family 영역에 관한 사용자 이름과 비밀번호를 요구하는 대화상자를 띄움
• 사용자가 사용자 이름과 비밀번호를 입력하면 브라우저는 그것을 콜론으로 이어 붙여 base-64 방식으로 인코딩한 후 Authorization 헤더에 그 값을 담아 다시 서버로 요청
• 서버가 사용자 이름과 비밀번호를 디코딩하고, 그 값이 정확한지 검사한 후 문제가 없으면 HTTP 200 OK 메세지와 함께 요청 받았던 문서를 응답한다.

인증요구/응답	헤더 문법 & 설명
인증 요구 (서버 → 클라이언트)	WWW-Authenticate: Basic realm=따옴표로 감싼 문서 집합 정보
인증 요구 응답 (클라이언트 → 서버)	Authorization: Basic base-64로 인코딩한 사용자 이름과 비밀번호

기본 인증의 보안 결함…

• 누군가 패킷을 가로채어 Base64 Decoding을 실시하면 ? 바로 개인정보 유출
• 여러 사이트에서 동일한 비밀번호를 사용하는 사용자들에게는 치명적인 결함이 될 수 있음
• 메시지의 인증헤더를 건드리지는 않지만, 다른 부분을 수정하여 트랜잭션의 본래 의도를 바꿔버리는 프락시나 중개자가 개입하면 → 정상 동작 보장 Xx
• 따라서..
  • HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나, 보안이 더 강화된 다이제스트 인증 프로토콜을 사용
  • 기본 인증은 재전송 공격을 예방하기 위한 어떤일도 하지 않음
  • 만일, 기본 인증을 요구하는 서버가 가짜 서버면 ?… 정말 큰일남 (가짜 서버의 위장에 취약)

다이제스트 인증 ?

• 기본 인증과 호환되며 기본 인증보다 안전한 인증 방법
• Improvements
  • 비밀번호를 네트워크를 통해 통신할 때 평문 전송 X
    • 그대로 보내는 대신, 요약/압축(Digest) 상태로 보냄
    • 서버는 비밀번호를 알고 있어, 요약만으로 대응하는지 검사하여 인증 가능
    • 공격자는 모든 가능성이 있는 PW를 하나씩 대입해보지 않는 이상 알 수 없어 보안성 증가
  • 무결성 침해 방지 구현 가능

[eunbc]

인증

1. 웹사이트의 개인정보나 사내 문서는 인증이나 권한 없는 사용자가 볼 수 없어야 한다. 당신이 누구인지 증명하는 ‘인증’을 해야한다.
2. HTTP에는 기본 인증과 다이제스트 인증이라는 두 가지 공식 인증 프로토콜이 있음

기본 인증

1. 클라이언트 측에서 정보 요청 - 헤더 없음, GET
2. 서버 측에서 인증 요구 - WWW-Authenticate 헤더, 401 Unauthorized
   1. WWW-Authenticate : Basic realm=”Corporate Financials” 처럼 영역을 그룹으로 나누어 사용하기도 함
3. 클라이언트 측에서 인증 정보를 보냄 - Authorization 헤더, GET
   1. 사용자가 이름과 비밀번호를 입력하면, 콜론으로 붙여 base-64 방식으로 인코딩하여 헤더에 담음
   2. base-64 인코딩 : 8비트 바이트로 이루어져 있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다. 바이너리, 텍스트, 국제 문자 데이터 문자열을 전송 가능한 알파벳으로 변환하기 위해 발명됐다. 원본 문자열이 변질될 걱정없이 디코딩 가능함
   3. 예시 : user:user1234! → dXNlcjp1c2VyMTIzNCE=
4. 인증 정보를 디코딩 한후 값이 정확하면, 서버는 문서와 함께 응답 - 200 OK
   1. 기본 인증은 Authentication-Info 헤더 사용하지 않음

기본 인증의 보안 결함

1. 기본 인증은 단순하고 편리하지만 안심할 수는 없다
   1. base-64 인코딩은 사실상 누구나 디코딩이 가능하기 때문에 그대로 보내는 것과 다름이 없다.
   2. 많은 사용자들이 모든 사이트에 같은 아이디와 비밀번호를 사용하기 때문에, 보안이 약한 사이트에서 탈취한 아이디/비밀번호 정보를 온라인 은행 사이트에 접근할 수도 있음
   3. SSL 암호화 채널을 통해 보내거나, 다이제스트 인증을 사용하는 것이 좋다.

[KarmaPol]

인증

당신이 누구인지 증명
신분증, 비밀번호 입력 등

HTTP의 인증 요구/응답 프레임워크

1. 서버에 HTTP 요청
2. 서버는 클라이언트에 인증 요구
   서버는 401 응답코드, 헤더 WWW-Authenticate에 요구하는 영역을 설명
3. 클라이언트는 서버에 인증 정보 보냄
   Authorization 헤더에 사용자 이름, 비밀번호와 알고리즘 기술
4. 서버는 접근 권한 확인 후 해당 문서 응답
   서버는 Authentication-Info 헤더에 추가 정보를 기술해서 응답하기도 함

보안 영역

WWW-Authenticate: Basic realm="Corporate Financials"
리소스를 보안 영역(realm)으로 나누어 헤더에 첨부하면 사용자에 권한 범위 이해를 도울 수 있다

기본 인증

HTTP 인증 규약

Base-4 사용자 이름/비밀번호 인코딩

서버, 네트워크 중에 뜻하지 않게 사용자 이름, 비밀번호 노출을 방지

프락시 인증

프락시 서버에서 사용자 인증 -> 통합적인 접근 제어 가능

기본 인증의 보안 결함

• Base64로 인코딩하더라도 암호화 되지 않으므로 결국 개인정보 노출
• 인증 헤더를 건드리지 않지만 요청의 다른 부분을 수정해 악용하는 중개자나 프락시에 취약
• 인증을 요구하는 가짜 서버에 취약
  => SSL 인증을 통해 취약점 보완 가능

[kimday0326]

인증?

사용자가 누구인지 증명하는 것이며, 완벽한 인증은 존재하지 않지만 정보가 많을수록 식별 가능성이 높아진다.

HTTP 인증요구/응답 프레임워크

• HTTP는 자체 인증요구/응답 프레임워크를 제공한다.
• 서버는 인증을 요청하고, 클라이언트는 인증 정보를 첨부해 다시 요청을 보내게 된다.

인증 프로토콜과 헤더

• HTTP는 다양한 인증 프로토콜을 지원하도록 확장 가능한 제어 헤더를 제공한다.
• 기본 인증 스킴(Basic)에서는 ID와 비밀번호를 Base64 인코딩하여 전달한다.
• WWW-Authenticate 헤더를 통해 인증을 요구하고, 클라이언트는 Authorization 헤더에 인증 정보를 전송한다.

보안 영역 (realm)

• HTTP는 각 리소스마다 다른 접근 조건을 'realm'이라는 보안 영역을 통해 관리한다.
• Realm은 접근이 제한된 문서들을 그룹화하고, 각 그룹은 다른 사용자 권한을 요구한다.

기본 인증

• 웹 서버는 클라이언트의 요청을 거부하고 ID와 비밀번호를 요구할 수 있으며, 서버는 401 상태 코드와 WWW-Authenticate 헤더를 포함하여 응답합니다.

Base-64 사용자 이름/비밀번호 인코딩

• Base64 인코딩은 ASCII 호환성과 HTTP 헤더에서 사용할 수 없는 문자를 처리하기 위해 사용된다.

프락시 인증

• 프락시를 통한 사용자 인증을 사용하여 접근 정책을 중앙에서 관리할 수도 있다.

기본 인증의 보안 결함

• 기본 인증은 암호화되지 않아 쉽게 디코딩될 수 있으며, 재전송 공격에 취약하다.
• 보다 안전한 인증을 위해서는 TLS 같은 암호화 채널 또는 다이제스트 인증 같은 프로토콜을 사용하는 것이 좋다.