HTTPS가있는 경우 REST 서비스 보안이 필요한 이유


13

나는 웹 서비스의 보안과 같은 아마존에 대해 이야기 하는이 훌륭한 기사 http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ 을 참조합니다 . 그러나 팀에서 이미 HTTPS를 사용하는 경우 왜 필요한지에 대한 질문을 받았습니다. 나는 그것이 장에게 다르게 말하고 있지만 그들이 옳을지도 모르기 때문에 나는 대답 할 수 없었다.

HTTPS가 작동하지 않을 수있는 REST 서비스를 제공 할 때도 있습니까? 타사 웹 사이트처럼?

공개 웹을 통한 웹 서비스 보안 경험이있는 사람은 경험에 대해 알려주십시오.

미리 감사드립니다.

편집 : 명확히하기 위해 사용자 인증에 대해 말하고 있지만 클라이언트 인증에 대해 더 많이 말하고 있습니다. 사용자 인증은 HTTPS + REST를 통한 일반 텍스트 인 것으로 가정 할 수 있습니다.

내 걱정은 HTTPS를 통해 클라이언트 엔드 포인트가 여전히 클라이언트 응용 프로그램없이 내 웹 서비스를 사용할 수 있지만 모든 것이 평범한 텍스트이므로 클라이언트가없이 웹 서비스를 사용하여 누구나 웹 서비스에 액세스 할 수 있다는 것입니다.


3
security.stackexchange.com에 가장 적합 합니까?
jweyrich

1
어쩌면 당신은 옳지 만 내 질문은 mor deve 관련입니다.

답변:


13

이미 HTTPS를 사용중인 경우 Gmail 또는 사용자 계정이있는 다른 사이트에 사용자 이름과 비밀번호를 제공해야하는 이유는 무엇입니까? 답변은 귀하의 질문에 대한 답변과 동일합니다.

HTTPS 는 무엇보다도 서버와 클라이언트 간의 암호화 된 연결을 제공합니다.

HTTPS 고유의 트러스트는 브라우저 소프트웨어에 사전 설치된 주요 인증 기관을 기반으로합니다 ( "내가 누구를 신뢰해야하는지 인증 기관 (예 : VeriSign / Microsoft / etc.) 등을 신뢰 함").

서버 가 각 사용자에게 인증서를 제공 하지 않으면 서버 다른 인증 방법없이 클라이언트를 신뢰할 수 없습니다.


당신이 오해 미안하거나 명확하지 않았다. Amazon APi 문서에는 HTTPS를 사용해야한다고 명시되어 있지만 그렇지 않은 경우 요청에 서명합니다. 이 시점에서 사용자 이름 비밀번호는 관련이 없습니다.

3
높은 수준에서 서버가 사용자의 명령을 수락하려면 서버에 대한 신원을 증명해야합니다. 클라이언트 인증 HTTPS를 통해 수행 할 수 있으며 메시지 서명을 사용하여 수행 할 수도 있습니다.
매트 볼

1
클라이언트 인증에 HTTPS를 사용하려면 내 답변의 마지막 링크에 설명 된대로 각 사용자에게 공개 키 인증서를 발급해야합니다. 이 인증서를 전자 버전의 여권으로 생각하십시오.
매트 볼

1
내 질문에 대한 답변을 "각 사용자에게 인증서 제공"링크를 제공합니다. 서버의 SSL로는 충분하지 않으므로 웹 서비스의 양쪽 끝을 올바르게 보호하려면 전체 개인 공개 키와 서명이 여전히 필요합니다. 당신의 대답은 지금까지 가장 가깝습니다. 대단히 감사합니다.
Abhishek Dujari 2016 년

1
+1 클라이언트 인증서를 언급하는 것이 좋지만 서버가 인증서를 발급 할 필요는 없습니다. 신뢰할 수있는 CA가 서명하면됩니다. 기본적으로 서버 인증서 작동 방식과 동일합니다.
JimmyJames

3

HTTPS는 도청 및 "중간자 공격"을 방지하는 데 매우 적합합니다. 세션의 모든 트래픽을 암호화합니다.

그러나 대부분의 사람들은 브라우저와 함께 제공되는 기본 인증서를 사용하고 있으므로 자신의 개인 인증서를 작성하거나 브라우저가이를 사용하도록 구성하는 방법을 모릅니다.

이것은 도청 등으로부터 인증 대화 상자를 보호하는 것 외에는 사용자 인증에 HTTPS를 꽤 쓸모 없게 만듭니다.


나는 당신이 내가 요구하는 것에 매우 가깝다고 생각합니다. 따라서 HTTPS를 사용하더라도 클라이언트 측에서 여전히 요청에 서명해야한다고 제안하십니까?

2

HTTPS는 채널의 보안에 관한 것으로, 발신자가 누구인지 또는 고려해야 할 다른 많은 것을 입증하지는 않습니다. 인증, 권한 부여 및 전송 계층 암호화는 고려해야 할 부분에 불과합니다. 웹 애플리케이션과 관련하여 알려진 많은 취약점이 REST API에 매우 많이 적용됩니다. 입력 유효성 검사, 세션 크래킹, 부적절한 오류 메시지, 내부 직원 취약성 등을 고려해야합니다. 큰 주제입니다.

로버트


0

클라이언트 SSL 인증서에 접근하여 보안을 API와 분리 할 수 ​​있습니다. 이 방법의 큰 단점은 점점 더 많은 클라이언트가 API를 소비함에 따라 비용이 많이 드는 작업 오버 헤드입니다.

어쨌든 HTTP 기본 인증은 대다수의 공개적으로 소비되는 서비스에 적합합니다.

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