REST 인증 체계의 보안

REST 인증 체계의 보안

---

배경:

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

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

• RESTful 인증
• REST API / 웹 서비스 보안을위한 우수 사례
• 최고의 SOAP / REST / RPC 웹 API의 예는 무엇입니까? 그리고 왜 그들을 좋아합니까? 그리고 무엇이 잘못 되었나요?

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

질문을하려면 :

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

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

---

이전 답변은 데이터 전송의 맥락에서 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 질문을 확장했습니다 .

---

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

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

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

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

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

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

---

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

---

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

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

---

실제로 원래 S3 인증 은 약한 MD5 서명을 사용하더라도 내용에 서명을 허용합니다. HMAC (서명 할 문자열)에 Content-MD5 헤더를 포함하는 선택적 방법을 간단히 시행 할 수 있습니다.

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

새로운 v4 인증 체계가 더 안전합니다.

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

---

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

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

XML 암호화 (W3C 표준)

XML 보안

참고 URL : https://stackoverflow.com/questions/454355/security-of-rest-authentication-schemes