REST 인증 체계의 보안

228

배경:

REST 웹 서비스에 대한 인증 체계를 설계하고 있습니다. 이것은 "실제로"안전 할 필요는 없지만 (개인 프로젝트에 가깝습니다) 가능한 한 운동 / 학습 경험처럼 최대한 안전하게 만들고 싶습니다. 번거롭지 않고 SSL 설정 비용이 들기 때문에 SSL을 사용하고 싶지 않습니다.

이 SO 질문은 나를 시작하는 데 특히 유용했습니다.

Amazon S3 인증의 단순화 된 버전을 사용하려고 합니다 ( OAuth는 좋아 하지만 내 요구에 너무 복잡해 보입니다). 재생 공격을 방지하기 위해 서버에서 제공 하는 임의로 생성 된 nonce 를 요청에 추가하고 있습니다.

질문을하려면 :

S3와 OAuth는 모두 선택된 몇 가지 헤더와 함께 요청 URL에 서명합니다. 둘 다 POST 또는 PUT 요청에 대한 요청 본문 에 서명하지 않습니다 . URL과 헤더를 유지하고 요청 본문을 공격자가 원하는 데이터로 바꾸는 중간자 공격에 취약하지 않습니까?

서명 된 문자열에 요청 본문의 해시를 포함 시켜서 이것을 막을 수있는 것처럼 보입니다. 안전한가요?

rest  authentication  oauth  amazon-s3  rest-security 
— dF.
소스
6
Amazon S3는 설명하는 MITM 공격을 방지하기 위해 Content-MD5를 헤더 문자열의 일부로 포함 할 수 있습니다.
— laz
8
MD5는 매우 약한 해시 함수이며 현재 몇 년 동안 사용이 권장되지 않습니다 ( en.wikipedia.org/wiki/MD5) . 요즘 SHA2를 사용하십시오. MD5는 정체성 위기에 처한 돼지의 립스틱입니다.
— Henrik
6
Startcom 은 주요 브라우저에서 인증서 경고를 발생시키지 않는 무료 SSL 인증서를 제공합니다
— Plato
5
@SeanKAnderson (rant : 2008 년에 이미 많은 공격을 자동화 한 스파이 기관이 인터넷을 포위 공격 할 때 사람들이 99.99999 % 정도의 대화를하는 것은 터무니없는 일입니다. 실제 문제를 처리하는 이상한 방법입니다. "나아, 문제 없어요, 할머니가 해킹하지 못했을 것입니다"
— Henrik
2
@Plato 무료 SSL 인증서를 위해 요즘 LetsEncrypt를 추천합니다
— shuttle87

답변:

168

이전 답변은 데이터 전송의 맥락에서 SSL 만 언급했으며 실제로 인증은 다루지 않았습니다.

실제로 REST API 클라이언트를 안전하게 인증하는 방법을 요구하고 있습니다. TLS 클라이언트 인증을 사용하지 않는 한 SSL 만으로는 REST API를위한 실용적인 인증 메커니즘이 아닙니다. client authc가없는 SSL은 서버 만 인증하는데 , 이는 실제로 클라이언트 를 인증하려고하기 때문에 대부분의 REST API와 관련이 없습니다 .

TLS 클라이언트 인증을 사용하지 않는 경우 다이제스트 기반 인증 체계 (Amazon Web Service의 사용자 정의 체계와 같은) 또는 OAuth 1.0a 또는 HTTP 기본 인증 (SSL을 통해서만)과 같은 것을 사용해야합니다.

이 체계는 요청이 누군가가 보낸 것을 인증합니다. TLS (SSL) (클라이언트 인증없이)는 유선을 통해 전송 된 데이터가 변경되지 않은 상태로 유지되도록합니다. 그것들은 별개이지만 보완적인 문제입니다.

관심있는 사람들을 위해 HTTP 인증 체계와 작동 방식 에 대한 SO 질문을 확장했습니다 .

— 레 헤즐 우드
소스
16
바로 그거죠. API에 관한 한 SSL이 확인하는 유일한 것은 처리하는 호출이 도중에 엉망이 아니라는 것입니다. API는 여전히 누구와 대화하고 있는지 또는 전혀 액세스 권한이 있는지 여부를 모릅니다.
— Tim Gautier
1
좋은 대답입니다. 또한 이러한 우수한 자원을 살펴 .. 가지고 추천 할 것입니다 owasp.org/index.php/Web_Service_Security_Cheat_Sheet 및 owasp.org/index.php/REST_Security_Cheat_Sheet (초안)
— dodgy_coder
2
사소한 점이지만 SSL을 사용하면 중간 공격에서 도청과 사람을 예방할 수 있다는 추가 이점이 있습니다.
— dodgy_coder
@Les Hazlewood Https를 통한 HTTP 기본 인증이 서버와 대화하는 사람을 결정하는 데 어떻게 도움이 될 수 있습니까?
— Spring
@Les Hazlewood 여기서 질문을했습니다. tnx stackoverflow.com/questions/14043397/…
— Spring
60

REST는 웹 표준에 대한 작업을 의미하며 웹에서의 "보안"전송 표준은 SSL입니다. 다른 모든 것들은 펑키하고 클라이언트를 위해 추가 배포 노력이 필요하며 암호화 라이브러리를 사용할 수 있어야합니다.

SSL에 커밋하면 원칙적으로 인증에 필요한 멋진 것은 없습니다. 정교한 표준 서명 프로토콜보다 훨씬 간단하고 보안 연결 컨텍스트에서 여전히 효과적이므로 웹 표준을 사용하여 HTTP 기본 인증 (각 요청과 함께 전송되는 사용자 이름 및 비밀 토큰)을 사용할 수 있습니다. 비밀번호가 절대 일반 텍스트를 넘지 않도록해야합니다. 따라서 일반 텍스트 연결을 통해 비밀번호를 수신 한 경우 비밀번호를 비활성화하고 개발자에게 메일을 보낼 수도 있습니다. 또한 일반 비밀번호를 기록하지 않는 것처럼 자격 증명이 수신시 어디에도 기록되지 않도록해야합니다.

HTTP 다이제스트는 비밀 토큰이 전달되지 않도록하는보다 안전한 방법입니다. 대신 서버가 다른 쪽 끝에서 확인할 수있는 해시입니다. 위에서 언급 한 예방 조치를 취한 경우 덜 민감한 응용 프로그램에는 무리가있을 수 있습니다. 결국, 사용자의 암호는 로그인 할 때 (브라우저에서 멋진 JavaScript 암호화를 수행하지 않는 한) 이미 일반 텍스트로 전송되며 각 요청에서 쿠키도 마찬가지입니다.

API를 사용하면 개발자가 웹 사이트에 로그인하는 비밀번호 대신 클라이언트가 임의로 생성 된 문자열 인 토큰을 전달하는 것이 좋습니다. 따라서 개발자는 사이트에 로그인하여 API 확인에 사용할 수있는 새 토큰을 생성 할 수 있어야합니다.

토큰을 사용하는 주된 이유는 토큰이 손상된 경우 교체 할 수있는 반면 암호가 손상된 경우 소유자는 개발자 계정에 로그인하여 원하는 작업을 수행 할 수 있기 때문입니다. 토큰의 또 다른 장점은 동일한 개발자에게 여러 토큰을 발행 할 수 있다는 것입니다. 앱이 여러 개 있거나 액세스 수준이 다른 토큰을 원하기 때문일 수 있습니다.

(SSL 만 연결하는 의미를 포함하도록 업데이트되었습니다.)

— 마헤 모프
소스
3
내 생각에 연간 30 달러 정도의 GoDaddy SSL 인증서를받을 수 있습니다. 나는 Verisign SSL 인증서가 얼마나 많은 돈을들이는지 (1 년에 600 달러 또는 올바르게 기억한다면 무엇인가) 충격을 받았다. 그러나 GoDaddy 옵션은 완벽하게 실현 가능하다.
— Brian Armstrong
19
SSL / TLS 상호 인증을 사용하지 않고 사용자 / 클라이언트가 사용하는 인증서를 서버가 신뢰하지 않는 한 서버 / 응용 프로그램에 대해 사용자를 인증하지 않았습니다. 서버 / 응용 프로그램에 사용자를 인증하기 위해 더 많은 작업을 수행해야합니다.
— Pauld
5
라이언 : SSL 암호화 요즘은 장고 또는 레일 등과 같은 웹 응용 프로그램 프레임 워크와 응답 생성하기 위해 사용했던 것과 비교 처리 능력의 매우 작은 양의 소요
— 카메론 월시
4
startcom의 인증서는 무료이며 널리 인정됩니다. cacert.org는 인식이 적은 공개 대안입니다.
— Dima Tisnek
17
이것은 인증에 관한 질문을 다루지 않습니다.
— Sam Stainsby
8

또는이 문제에 대해 알려진 해결책을 사용하고 SSL을 사용할 수 있습니다. 자체 서명 된 인증서는 무료이며 개인 프로젝트에 적합합니까?

— 우서
소스
2
자체 서명 인증서는 무료이지만 AFAIK에는 여전히 고정 IP가 필요합니다.
— dF.
8
@dF 인증서에 대해 상업 유료의 특정 라이센스 요구 사항을 제외하고 고정 IP를 가질 필요는 없습니다.
— Chris Marisic 2016 년
양쪽 끝 (클라이언트 및 서버)에서 인증서 저장소를 제어 할 수있는 경우이 옵션을 사용할 수 있지만 인증서 관리 및 배포는 개발 환경보다 프로덕션에서 훨씬 더 복잡합니다. 커밋하기 전에이 대안의 복잡성을 이해해야합니다.
— 19:46에
5

URL의 매개 변수 중 하나로 본문의 해시가 필요하고 해당 URL이 개인 키를 통해 서명 된 경우 중간자 공격은 본문을 생성 할 콘텐츠로만 바꿀 수 있습니다. 같은 해시. 적어도 MD5 해시 값으로 쉽게 할 수 있으며 SHA-1이 손상되면 그림을 얻을 수 있습니다.

본문이 무단 변경되지 않도록하려면 본문의 서명이 필요합니다.이 서명은 서명을 생성하는 개인 키를 알지 못하므로 중간자 공격이 중단 될 가능성이 적습니다. .

— 자 다즈
소스
9
유효한 내용과 동일한 md5 해시를 생성하는 문자열을 찾는 것이 훨씬 쉬울 수 있지만, 같은 값으로 해시되는 유효한 버전의 악의적 인 버전을 만드는 것은 여전히 ​​매우 어렵습니다. 이것이 md5가 더 이상 비밀번호 해시에 사용되지 않지만 여전히 다운로드 확인에 사용되는 이유입니다.
— Tim Gautier
1

클라이언트가 서버와 통신하기가 어렵다는 제안이 있습니다. 그들은 혁신적인 솔루션을 이해하고 그에 따라 데이터를 암호화해야합니다.이 모델은 amazon \ yahoo \ google.이 아닌 한 공개 API에는 적합하지 않습니다.

어쨌든 본문 내용을 암호화 해야하는 경우 다음과 같은 기존 표준 및 솔루션을 확인하는 것이 좋습니다.

XML 암호화 (W3C 표준)

XML 보안

— LiorH
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.