REST API / 웹 서비스 보안을위한 모범 사례 [닫기]

REST API 또는 서비스를 설계 할 때 보안 (인증, 권한 부여, 아이디 관리)을 다루는 모범 사례가 있습니까?

SOAP API를 빌드 할 때 WS-Security를 ​​안내서로 사용하며이 주제에 관한 많은 문헌이 있습니다. REST 엔드 포인트 보안에 대한 정보가 적었습니다.

REST에 의도적으로 WS- *와 유사한 사양이 없다는 것을 이해하지만 모범 사례 또는 권장 패턴이 나오기를 바랍니다.

관련 문서에 대한 토론이나 링크는 대단히 감사하겠습니다. 중요한 경우 .NET Framework v3.5를 사용하여 빌드 된 REST API / 서비스에 대해 POX / JSON 직렬화 된 메시지와 함께 WCF를 사용합니다.

tweakt가 말했듯이 Amazon S3는 작업하기에 좋은 모델입니다. 요청 서명에는 우발적이거나 악의적 인 요청 재생을 방지하는 데 도움이되는 몇 가지 기능 (예 : 타임 스탬프 통합)이 있습니다.

HTTP Basic의 좋은 점은 거의 모든 HTTP 라이브러리가이를 지원한다는 것입니다. 물론이 경우에는 일반 텍스트 암호를 인터넷을 통해 보내는 것이 거의 보편적으로 좋지 않기 때문에 SSL이 필요합니다. 발신자가 자격 증명이 필요하다는 것을 이미 알고 있더라도 Digest는 nonce 값을 교환하기 위해 추가 왕복이 필요하기 때문에 SSL을 사용할 때는 기본이 Digest보다 선호됩니다. 기본 기능을 사용하면 발신자는 처음으로 자격 증명을 보냅니다.

클라이언트의 신원이 설정되면 권한 부여는 실제로 구현 문제 일뿐입니다. 그러나 기존 권한 부여 모델을 사용하여 다른 구성 요소에 권한을 위임 할 수 있습니다. 여기서 Basic의 좋은 점은 서버가 클라이언트 비밀번호의 일반 텍스트 사본으로 끝나서 필요에 따라 인프라 내의 다른 구성 요소로 간단히 전달할 수 있다는 것입니다.

HTTP 이외의 REST 표준은 없습니다. REST 서비스가 확립되어 있습니다. 나는 당신이 그들을 들여다보고 그들이 어떻게 작동하는지 느낌을 얻는 것이 좋습니다.

예를 들어, 자체 개발할 때 Amazon S3 REST 서비스에서 많은 아이디어를 빌 렸습니다. 그러나 요청 서명을 기반으로 한 고급 보안 모델을 사용하지 않기로 결정했습니다. 가장 간단한 방법은 SSL을 통한 HTTP 기본 인증입니다. 상황에 가장 적합한 것을 결정해야합니다.

또한 O'reilly의 RESTful Web Services 책을 강력히 추천합니다 . 핵심 개념을 설명하고 모범 사례를 제공합니다. 일반적으로 제공하는 모델을 가져 와서 자신의 응용 프로그램에 매핑 할 수 있습니다.

또한 http api를 대상으로하는 토큰 기반 인증을위한 새로운 개방형 프로토콜 인 OAuth를 살펴볼 수도 있습니다 .

이 접근 방식에 의해 촬영과 매우 유사하다 플리커 와 우유 기억 "나머지"API를 (편안한 API를 반드시 좋은 예,하지만 토큰 기반 접근 방식의 좋은 예).

Github 에는 훌륭한 점검 목록이 있습니다 .

입증

• 인증, 토큰 생성, 암호 저장에서 바퀴를 재발 명하지 마십시오. 표준을 사용하십시오.

• Max Retry로그인에서 사용 및 탈옥 기능.

• 모든 중요한 데이터에 암호화를 사용하십시오.

JWT (JSON 웹 토큰)

• 임의의 복잡한 키 (JWT Secret)를 사용하여 토큰을 매우 단단하게 강제하십시오.

• 페이로드에서 알고리즘을 추출하지 마십시오. 백엔드에서 알고리즘을 강제 실행하십시오 (HS256 또는 RS256).

• 토큰 만료 ( TTL, RTTL)를 가능한 짧게 만드십시오 .

• JWT페이로드에 민감한 데이터를 저장하지 않고 쉽게 해독 할 수 있습니다.

OAuth

• redirect_uri허용 된 URL 만 허용하도록 항상 서버 측의 유효성을 검사하십시오 .

• 토큰이 아닌 코드를 항상 교환하십시오 (허용 안 함 response_type=token).

• 방지하기 위해 임의의 해시 상태 매개 변수를 사용하여 CSRF온 OAuth인증 프로세스.

• 기본 범위를 정의하고 각 애플리케이션에 대한 범위 매개 변수의 유효성을 검증하십시오.

접속하다

• DDoS / 무차별 대입 공격을 피하기 위해 요청을 제한 (스로틀 링)합니다.

• MITM (Man In The Middle Attack)을 피하려면 서버 측에서 HTTPS를 사용하십시오.

• HSTSSSL Strip 공격을 피하려면 SSL과 함께 헤더를 사용하십시오 .

입력

• GET(읽기), POST(만들기), PUT/PATCH(바꾸기 / 업데이트) 및 DELETE(레코드 삭제 ) 작업에 따라 적절한 HTTP 방법을 사용하고 405 Method Not Allowed요청 된 방법이 요청 된 리소스에 적합하지 않은 경우 응답 합니다.

• 요청에 대한 유효성 검사 콘텐츠 형식 Accept헤더 (콘텐츠 협상) 만 지원되는 형식 (예를 들면 수 있도록 application/xml, application/json과 등) 및 응답을 406 Not Acceptable일치하지 않는 경우 응답.

• 검증 content-type수락으로의 (예를 들어 데이터를 게시 application/x-www-form-urlencoded, multipart/form-data, application/json, 등).

• 일반적인 취약점 (예 : XSS, SQL-Injection, 원격 코드 실행 등)을 피하기 위해 사용자 입력의 유효성을 검사하십시오.

• URL에 민감한 데이터 (자격 증명, 비밀번호, 보안 토큰 또는 API 키)를 사용하지 말고 표준 Authorization헤더를 사용하십시오 .

• API Gateway 서비스를 사용하여 캐싱, Rate Limit정책 (예 : 할당량, 스파이크 체포, 동시 속도 제한) 을 활성화 하고 API 리소스를 동적으로 배포하십시오.

가공

• 인증 프로세스가 중단되지 않도록 모든 엔드 포인트가 인증으로 보호되는지 확인하십시오.

• 사용자 자신의 리소스 ID는 피해야합니다. / user / 654321 / orders 대신 / me / orders를 사용하십시오.

• ID를 자동 증가시키지 마십시오. 대신 UUID를 사용하십시오.

• XML 파일을 구문 분석하는 경우 XXE (XML 외부 엔티티 공격)를 피하기 위해 엔티티 구문 분석을 사용하지 않아야합니다.

• XML 파일을 구문 분석하는 경우 지수 엔티티 확장 공격을 통한 10 억 웃음 / XML 폭탄을 피하기 위해 엔티티 확장을 사용하지 않도록 설정하십시오.

• 파일 업로드에는 CDN을 사용하십시오.

• 방대한 양의 데이터를 처리하는 경우 Workers and Queues를 사용하여 가능한 한 많은 백그라운드에서 처리하고 응답을 빠르게 반환하여 HTTP 차단을 피하십시오.

• DEBUG 모드 를 끄는 것을 잊지 마십시오 .

산출

• X-Content-Type-Options: nosniff헤더를 보냅니다 .

• X-Frame-Options: deny헤더를 보냅니다 .

• Content-Security-Policy: default-src 'none'헤더를 보냅니다 .

• 헤더를 지문 제거 - X-Powered-By, Server, X-AspNet-Version등

• content-type응답을 강제 로 반환 application/json하면 응답 내용 유형은 application/json입니다.

• 자격 증명, 비밀번호, 보안 토큰과 같은 민감한 데이터는 반환하지 마십시오.

• 완료된 작업에 따라 올바른 상태 코드를 반환하십시오. (예를 들어 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, 등).

클라이언트 인증서가있는 SSL이 아직 언급되지 않은 것에 놀랐습니다. 물론이 방법은 인증서로 식별되는 사용자 커뮤니티를 신뢰할 수있는 경우에만 매우 유용합니다. 그러나 많은 정부 / 기업이 사용자에게이를 발행합니다. 사용자는 또 다른 사용자 이름 / 암호 조합을 생성 할 필요가 없으며 각 연결마다 ID가 설정되므로 서버와의 통신은 완전히 상태 비 저장이 가능하므로 사용자 세션이 필요하지 않습니다. (상기 언급 된 다른 솔루션 중 일부 또는 전부가 세션을 필요로한다는 것을 암시하지 않습니다)

이 답변의 모든 사람은 진정한 액세스 제어 / 권한을 간과했습니다.

예를 들어 REST API / 웹 서비스가 의료 기록 게시 / 접근에 관한 것이라면 누가 데이터에 액세스 할 수 있고 어떤 환경에서 액세스 제어 정책을 정의 할 수 있습니다. 예를 들어 :

• 의사는 치료 관계가있는 환자의 의료 기록을받을 수 있습니다
• 아무도 연습 시간 외에는 의료 데이터를 게시 할 수 없습니다 (예 : 9-5)
• 최종 사용자는 자신이 소유 한 의료 기록 또는 보호자가되는 환자의 의료 기록을받을 수 있습니다
• 간호사는 간호사와 동일한 장치에 속하는 환자의 의료 기록을 업데이트 할 수 있습니다.

이러한 세분화 된 권한을 정의하고 구현하려면 XACML이라는 속성 기반 액세스 제어 언어 인 eXtensible Access Control Markup Language를 사용해야합니다.

다른 표준은 다음과 같습니다.

• OAuth : 아이디 페더레이션 및 권한 위임 (예 : 다른 서비스를 대신하여 서비스를 수행하도록 허용 (Facebook에서 내 Twitter에 게시 할 수 있음)
• SAML : 자격 증명 연동 / 웹 SSO. SAML은 사용자가 누구인지에 관한 것입니다.
• WS-Security / WS- * 표준 : SOAP 서비스 간의 통신에 중점을 둡니다. 이들은 애플리케이션 레벨 메시징 형식 (SOAP)에 고유하며 메시징, 신뢰성, 보안, 기밀성, 무결성, 원 자성, 이벤트 등 메시징 측면을 처리합니다. 액세스 제어는 없으며 SOAP에만 해당됩니다.

XACML은 기술에 구애받지 않습니다. Java 앱, .NET, Python, Ruby ... 웹 서비스, REST API 등에 적용 할 수 있습니다.

다음은 흥미로운 자료입니다.

• OASIS XACML 웹 사이트
• NIST ABAC 표준

OAuth를 몇 번 사용했으며 다른 방법 (BASIC / DIGEST)도 사용했습니다. OAuth를 진심으로 제안합니다. 다음 링크는 OAuth 사용에 대해 본 최고의 자습서입니다.

http://hueniverse.com/oauth/guide/

REST와 관련하여 보안과 관련하여 내가 만난 최고의 게시물 중 하나는 1 RainDrop 이상 입니다. MySpace API는 보안을 위해 OAuth를 사용하며 RestChess 코드에서 사용자 정의 채널에 완전히 액세스 할 수 있습니다. 이것은 Mix에서 시연되었으며 여기 에서 게시물을 찾을 수 있습니다 .

훌륭한 조언에 감사드립니다. 우리는 RESTful API를 Microsoft의 곧 출시 될 Zermatt Identity 프레임 워크와 통합하기 위해 사용자 정의 HTTP 헤더를 사용하여 클라이언트에서 서비스로 ID 토큰을 전달했습니다. 나는 여기 에 문제 와 여기 에 우리의 해결책을 설명 했다 . 나도 조정했다 의 조언을 받아 RESTful Web Services를 구입했습니다 .

OWASP (Open Web Application Security Project)에는 웹 응용 프로그램 개발의 모든 측면을 다루는 치트 시트가 있습니다. 이 프로젝트는 매우 귀중하고 신뢰할 수있는 정보원입니다. REST 서비스와 관련하여 다음을 확인할 수 있습니다. https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

OAuth 2/3을 추천합니다. 자세한 정보는 http://oauth.net/2/ 에서 찾을 수 있습니다.

나는 편안한 ws 보안에 대해 많은 것을 검색했고, 클라이언트에서 서버로 쿠키를 통해 토큰을 사용하여 요청을 인증했습니다. 이미 DB에 있었던 지정된 보안 정책을 기반으로 각 요청을 인증하고 권한을 부여해야했기 때문에 서비스 요청의 승인을 위해 스프링 보안을 사용했습니다.

SOAP 세계가 보안 표준에 잘 적용된다고해서 기본적으로 안전하다는 의미는 아닙니다. 우선, 표준은 매우 복잡합니다. 복잡성은 보안의 좋은 친구가 아니며 XML 서명 줄 바꿈 공격 과 같은 구현 취약점 은 여기에서 고유합니다.

.NET 환경에 대해서는별로 도움이되지 않지만 "Java를 사용한 웹 서비스 구축" (제작자가 10 명 이하인 브릭)은 WS- * 보안 아키텍처와 특히 단점을 이해하는 데 많은 도움 이 되었습니다.

REST 자체는 보안 표준을 제공하지 않지만 OAuth 및 SAML과 같은 것이이 분야의 표준이되고 있습니다. 그러나 인증 및 권한 부여는 고려해야 할 사항의 일부일뿐입니다. 웹 애플리케이션과 관련하여 알려진 많은 취약점이 REST API에 매우 많이 적용됩니다. 입력 유효성 검사, 세션 크래킹, 부적절한 오류 메시지, 내부 직원 취약성 등을 고려해야합니다. 큰 주제입니다.

(stinkeymatt에 따라) 추가하고 싶습니다. 가장 간단한 해결책은 사이트에 SSL 인증서를 추가하는 것입니다. 즉, URL이 HTTPS : //인지 확인하십시오. 그것은 운송 보안을 책임질 것입니다. RESTful URL을 사용하면 WS * 보안 / SAML과 달리 단순하게 유지하는 것이 좋습니다. oAuth2 / openID 연결 또는 기본 인증 (간단한 경우)을 사용할 수 있습니다. 그러나 여전히 SSL / HTTPS가 필요합니다. 여기에서 ASP.NET Web API 2 보안을 확인하십시오 : http://www.asp.net/web-api/overview/security (기사 및 비디오)

@Nathan은 결국 간단한 HTTP 헤더이며, 일부는 OAuth2와 클라이언트 측 SSL 인증서를 언급했습니다. 요점은 이것입니다 ... REST API는 실제로 API 범위를 벗어나야하므로 보안을 처리 할 필요가 없습니다.

대신 웹 프록시 뒤의 HTTP 헤더 (SiteMinder, Zermatt 또는 Apache HTTPd와 같은 일반적인 접근 방식)이든 OAuth 2와 같이 보안 계층이든 그 위에 보안 계층을 배치해야합니다.

핵심은 요청이 최종 사용자 상호 작용없이 작동해야한다는 것입니다. 필요한 것은 REST API에 대한 연결이 인증되도록하는 것입니다. Java EE에서는 userPrincipal다음에서 얻을 수있는 개념 이 있습니다.HttpServletRequest . URL 패턴을 보호 할 수 있도록 배치 디스크립터에서 관리되므로 REST API 코드를 더 이상 확인할 필요가 없습니다.

WCF 세계에서는 ServiceSecurityContext.Current현재 보안 컨텍스트를 얻는 데 사용 합니다. 인증이 필요하도록 응용 프로그램을 구성해야합니다.

위에서 언급 한 진술에는 예외가 있으며 이는 재생을 방지하기 위해 nonce를 사용하는 것입니다 (공격 또는 누군가가 동일한 데이터를 두 번 제출할 수 있음). 해당 부분은 응용 프로그램 계층에서만 처리 할 수 ​​있습니다.

웹 응용 프로그램 보안의 경우 다양한 보안 공격에 대한 치트 시트를 제공하는 OWASP ( https://www.owasp.org/index.php/Main_Page )를 살펴보십시오 . 애플리케이션을 보호하기 위해 가능한 한 많은 조치를 통합 할 수 있습니다. API 보안 (권한 부여, 인증, ID 관리)과 관련하여 이미 언급 한 여러 가지 방법 (기본, 요약 및 OAuth)이 있습니다. OAuth1.0에는 루프 홀이 있으므로 OAuth1.0a를 사용할 수 있습니다 (사양과 관련하여 OAuth2.0이 널리 채택되지 않음)

시간이 지났지 만 질문은 여전히 ​​관련이 있지만 대답은 약간 변경되었을 수 있습니다.

API Gateway는 유연하고 구성 가능한 솔루션입니다. 나는 KONG을 약간 테스트하고 사용 했으며 실제로 본 것을 좋아했습니다. KONG은 사용자 관리에 사용할 수있는 자체 관리 REST API를 제공합니다.

Express-gateway.io 는 최신 버전이며 API 게이트웨이이기도합니다.