HTTP 계 정 비밀번호 검증
7773 단어 Http
RFC 7235 HTTP 인증 프레임 워 크 를 정의 합 니 다.서버 는 클 라 이언 트 의 요청 에 따라 보 낼 수 있 습 니 다. challenge(질의 정보),클 라 이언 트 는 인증 증명 서 를 제공 할 수 있 습 니 다.질문 과 응답 작업 절 차 는 다음 과 같 습 니 다.서버 에서 클 라 이언 트 에 게 돌아 갑 니 다.
401(Unauthorized,권한 이 부여 되 지 않 은)상태 코드 와 WWW-Authenticate 첫 번 째 부분 은 어떻게 검증 하 는 지 에 대한 정 보 를 제공 하 는데,그 중 에는 적어도 하나의 질의 방식 이 포함 되 어 있다.이후 자신의 신분 을 증명 할 의향 이 있 는 클 라 이언 트 는 새로운 요청 에 추가 할 수 있 습 니 다. Authorization 첫 번 째 필드 를 검증 합 니 다.필드 값 은 인증 증빙 정보 입 니 다.보통 클 라 이언 트 는 사용자 가 작성 할 수 있 도록 암호 상 자 를 꺼 내 서 적당 한 것 을 보 냅 니 다. Authorization 수부의 요청.
위의 그림 에서 보 여 준 기본 인증 과정 에서 정보 교환 은 HTTPS(TLS)연결 을 통 해 안전 을 확보 해 야 한다.
대리 인증
상기 와 같은 질문 질의 와 응답 원 리 는 대리 인증 에 사용 된다.다음은 중간 대리 가 인증 해 야 할 예 를 소개 한다.자원 인증 과 대리 인증 은 병존 할 수 있 고 독립 된 헤드 정보 와 응답 상태 코드 와 구별 된다.대리 인증,질의 상태 코드 는?
407(프 록 시 인증 서 를 제공 해 야 합 니 다).응답 헤드Proxy-Authenticate는 최소한 하나의 사용 가능 한 품질 제 를 포함 하고 요청 헤드Proxy-Authorization는 프 록 시 서버 에 인증 서 를 제공 하 는 데 사 용 됩 니 다.접근 거부
(프 록 시)서버 가 합 법 적 인 인증 정 보 를 받 았 을 때 이 인증 이 요청 자원 의 권한 을 얻 지 못 하면(프 록 시)서버 는
403응답 상 태 를 되 돌려 주 고 사용자 인증서 권한 이 부족 하 다 는 것 을 설명 합 니 다. 401 인증 되 지 않 음 407 대리 인증 이 다 릅 니 다.크로스 필드 이미지 인증
브 라 우 저 에서 최근 에 복 구 된 잠재 적 인 보안 구멍 은 도 메 인 이미지 인증 입 니 다....에서 Firefox 59 시작,브 라 우 저 는 다른 필드 의 그림 자원 을 불 러 올 때 HTTP 인증 대화 상자(bug)를 다시 꺼 내지 않 습 니 다. 1423146）。공격 자가 임의의 그림 을 제3자 페이지 에 삽입 할 수 있다 면 HTTP 인증 대화 상 자 를 꺼 내 는 것 을 금지 하면 사용자 의 신분증 이 도 둑 맞 는 것 을 피 할 수 있 습 니 다.
HTTP 인증 문자 인 코딩
브 라 우 저 사용
utf-8 사용자 이름과 비밀 번 호 를 인 코딩 합 니 다.Firefox 사용 ISO-8859-1단,다른 브 라 우 저 와 일치 하도록 변경 utf-8 bug 1419658 에서 묘사 한 잠재 적 인 문제.WWW-Authenticate ...과 Proxy-Authenticate 제1 부WWW-Authenticate ...과 Proxy-Authenticate 응답 메시지 의 첫 번 째 부분 은 자원 접근 권한 을 얻 기 위해 인증 하 는 방법 을 지정 하 였 습 니 다.그들 은 인증 을 해 야 하 는 방안 을 명 확 히 해 야 한다.그러면 권한 을 수 여 받 기 를 원 하 는 클 라 이언 트 가 증빙 정 보 를 어떻게 제공 해 야 하 는 지 알 수 있다.이 두 첫 번 째 부분의 문법 형식 은 다음 과 같다.WWW-Authenticate: realm=
Proxy-Authenticate: realm=
여기 서 검 증 된 방안('기본 검증 방안'은 가장 흔히 볼 수 있 는 검증 방안 으로 아래 에서 소개 한다)을 말한다.realm 은 보호 구역 이나 보호 범 위 를 설명 합 니 다.'Access to the staging site'와 유사 한 메시지 일 수 있 습 니 다.사용 자 는 어느 공간 에 접근 하려 고 하 는 지 알 수 있 습 니 다.
Authorization ...과 Proxy-Authorization 제1 부Authorization ...과 Proxy-Authorization 요청 메시지 의 첫 번 째 부분 에는(프 록 시)서버 에 사용자 프 록 시 신분 을 증명 할 수 있 는 증빙 이 포함 되 어 있 습 니 다.여기 서도 검 증 된 유형 을 가리 키 고 그 다음 에 증빙 정보 가 있 으 며 이 증빙 정 보 는 인 코딩 되 거나 암호 화 될 수 있 으 며 어떤 검증 방안 을 사용 하 느 냐 에 달 려 있다.Authorization:
Proxy-Authorization:
검증 방안
유 니 버 설 HTTP 인증 프레임 워 크 는 여러 검증 방안 에서 사용 할 수 있 습 니 다.서로 다른 검증 방안 은 안전 강도 와 클 라 이언 트 나 서버 엔 드 소프트웨어 에서 얻 을 수 있 는 난이도 가 다르다.
가장 흔히 볼 수 있 는 검증 방안 은'기본 검증 방안'('Basic')으로 이 방안 은 아래 에서 상세히 논술 할 것 이다.IANA 는 일련의 검증 방안 을 유 지 했 습 니 다.그 밖 에 가상 호스트 서비스 에서 제공 하 는 다른 유형의 검증 방안 도 있 습 니 다.예 를 들 어 Amazon AWS 등 입 니 다.일반적인 검증 방안 은 다음 과 같 습 니 다.
Basic (see RFC 7617,base64b 인 코딩 증명서.자세 한 내용 은 다음 글 을 참조 하 시기 바 랍 니 다.),Bearer (see RFC 6750,beaer 영패 OAuth 2.0 을 통 해 자원 보호),Digest (see RFC 7616,Firefox 에서 md5 해시 만 지원,보기 bug 472823 SHA 암호 화 지원 에 사용),HOBA (살펴보다 RFC 7486 (초안), HTTP Origin-Bound 인증,디지털 서명 기반),Mutual (살펴보다 draft-ietf-httpauth-mutual),
AWS4-HMAC-SHA256 (살펴보다 AWS docs).
기본 검증 방안
"Basic"HTTP 검증 방안 은 RFC 7617 에 따 르 면 이 방안 에 서 는 사용자 의 ID/비밀 번 호 를 증빙 정보 로 사용 하고 base 64 알고리즘 을 사용 해 인 코딩 한다.
기본 검증 방안 의 안전성
사용자 ID 와 비밀 번 호 는 네트워크 에서 명문 으로 전송 되 기 때문에 기본 검증 방안 은 안전 하지 않 습 니 다.기본 검증 방안 은 HTTPS/TLS 프로 토 콜 과 함께 사용 해 야 합 니 다.이러한 안전 방면 의 강화 가 없다 면 기본 검증 방안 은 민감 하거나 가치 있 는 정 보 를 보호 하 는 데 사용 되 어 서 는 안 된다.
Apache 를 사용 하여 접근 제한 및 기본 인증
아파 치 서버 에 있 는 디 렉 터 리 를 비밀번호 로 보호 하려 면 하나 가 필요 합 니 다.
.htaccess a. .htpasswd 서류...해 야 한다
.htaccess 파일 형식 은 보통 이렇게 보 입 니 다:AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user...해 야 한다
.htaccess 파일 참조 .htpasswd 파일,줄 마다 콜론(":")으로 구 분 된 사용자 이름과 비밀번호 입 니 다.실제 비밀 번 호 는 볼 수 없습니다. encrypted (이 예 에서 MD5 를 사 용 했 습 니 다.이름 을 지 을 수 있 습 니 다.htpasswd 파일 이 마음 에 드 는 이름 이지 만 다른 사람 이 접근 하지 않도록 해 야 합 니 다.(Apache 는 보통 접근 을 막 도록 설정 합 니 다. .ht* 클래스 파일aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/nginx 접근 제한 및 기본 인증
nginx 설정 에서 보호 할 location 에 대해 다음 과 같은 설정 을 해 야 합 니 다.
auth_basic ；auth_basic_user_file （ apache ）nginx 에서 보호 구역 과 이 구역 을 지정 해 야 합 니 다. auth_basic 명령 이 제공 하 는 보호 구역 이름 입 니 다.그리고 이auth_basic_user_file 명령 이 하 나 를 가리 키 고 있다.htpasswd 암호 화 된 사용자 증 거 를 포함 하 는 파일 입 니 다.위의 apache 예 와 같 습 니 다.location /status {
auth_basic "Access to the staging site";
auth_basic_user_file /etc/apache2/.htpasswd;
}URL 에 있 는 신분증 으로 접근 하기(폐기 됨)
많은 클 라 이언 트 들 이 로그 인 상 자 를 팝 업 하지 않 고 사용자 이름과 비밀 번 호 를 포함 하 는 인 코딩 된 URL 을 사용 하 는 것 을 지원 합 니 다.다음 과 같 습 니 다.
https://username:[email protected]/이런 URL 은 사용 에 찬성 하지 않 는 다.Chrome 에 서 는 URL 의 username:password@부분 이 보안 상의 이유 로 제거 되 기도 합 니 다.Firefox 는 이 사이트 에 인증 이 필요 한 지 확인 합 니 다.그렇지 않 으 면 경고 창 이 나타 납 니 다.사용자 이름"username"으로 로그 인 할 것 입 니 다. ”www.example.com“ 사이트,하지만 이 사이트 에 서 는 인증 이 필요 없습니다.사 기 를 시도 한 것 으로 보인다.
좋은 웹페이지 즐겨찾기
