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

https://stackoverflow.com/questions/7551

08-06-2019
|

문제

REST API 또는 서비스를 설계할 때 보안(인증, 권한 부여, ID 관리)을 처리하기 위해 확립된 모범 사례가 있습니까?

SOAP API를 구축할 때 WS-Security를 가이드로 사용하고 해당 주제에 대한 많은 문헌이 있습니다.REST 엔드포인트 보안에 대한 정보를 덜 찾았습니다.

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

관련 문서에 대한 토론이나 링크를 주시면 매우 감사하겠습니다.중요한 경우 .NET Framework v3.5를 사용하여 구축된 REST API/서비스에 대해 POX/JSON 직렬화된 메시지와 함께 WCF를 사용하게 됩니다.

해결책

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

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

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

다른 팁

HTTP 외에 REST에 대한 표준은 없습니다.확립된 REST 서비스가 있습니다.나는 당신이 그것들을 들여다보고 그들이 어떻게 작동하는지 느껴볼 것을 제안합니다.

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

그리고, 책도 적극 추천드려요 RESTful 웹 서비스 오라일리에서.핵심 개념을 설명하고 몇 가지 모범 사례를 제공합니다.일반적으로 그들이 제공하는 모델을 가져와 자신의 애플리케이션에 매핑할 수 있습니다.

당신은 또한 살펴보고 싶을 수도 있습니다 OAuth, 특히 http API를 대상으로 하는 토큰 기반 인증을 위한 새로운 개방형 프로토콜입니다.

의 접근 방식과 매우 유사합니다. 플리커 그리고 우유를 기억해 "rest" API(반드시 편안한 API의 좋은 예는 아니지만 토큰 기반 접근 방식의 좋은 예).

훌륭한 체크리스트가 있습니다. Github:

입증

인증, 토큰 생성, 비밀번호 저장 등의 과정을 다시 개발하지 마세요.표준을 사용하십시오.
사용 Max Retry 로그인의 감옥 기능.
모든 민감한 데이터에 암호화를 사용하십시오.

JWT(JSON 웹 토큰)

임의의 복잡한 키(JWT 비밀)를 사용하여 토큰을 무차별 대입하는 것을 매우 어렵게 만듭니다.
페이로드에서 알고리즘을 추출하지 마세요.백엔드(HS256 또는 RS256)에서 알고리즘을 강제 적용합니다.
토큰 만료(TTL, RTTL) 최대한 짧게.
민감한 데이터를 저장하지 마세요. JWT 페이로드를 사용하면 쉽게 디코딩할 수 있습니다.

OAuth

항상 검증 redirect_uri 서버측에서는 허용된 URL만 허용합니다.
항상 토큰이 아닌 코드로 교환하도록 시도하십시오(허용하지 마십시오). response_type=token).
이를 방지하려면 무작위 해시와 함께 상태 매개변수를 사용하세요. CSRF 에 OAuth 인증 과정.
기본 범위를 정의하고 각 애플리케이션에 대한 범위 매개변수의 유효성을 검사합니다.

입장

DDoS/무차별 대입 공격을 방지하기 위해 요청(제한)을 제한합니다.
MITM(Man In The Middle Attack)을 방지하려면 서버 측에서 HTTPS를 사용하세요.
사용 HSTS SSL 스트립 공격을 방지하기 위해 SSL을 사용하는 헤더.

입력

작업에 따라 적절한 HTTP 메소드를 사용하십시오. GET (읽다), POST (만들다), PUT/PATCH (교체/업데이트) 및 DELETE (기록을 삭제하기 위해) 다음과 같이 응답합니다. 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 주입, 원격 코드 실행 등).
URL에는 민감한 데이터(자격 증명, 비밀번호, 보안 토큰 또는 API 키)를 사용하지 말고 표준 데이터를 사용하세요. Authorization 머리글.
API 게이트웨이 서비스를 사용하여 캐싱을 활성화합니다. Rate Limit 정책(예:할당량, 급증 저지, 동시 속도 제한) 및 API 리소스를 동적으로 배포합니다.

처리

인증 프로세스 중단을 방지하려면 모든 엔드포인트가 인증으로 보호되는지 확인하세요.
사용자 자신의 리소스 ID는 피해야 합니다./user/654321/orders 대신 /me/orders를 사용하세요.
ID를 자동으로 증가시키지 마세요.대신 UUID를 사용하세요.
XML 파일을 구문 분석하는 경우 XXE(XML 외부 엔터티 공격)를 방지하려면 엔터티 구문 분석이 활성화되어 있지 않은지 확인하세요.
XML 파일을 구문 분석하는 경우 지수 엔터티 확장 공격을 통한 Billion Laughs/XML 폭탄을 피하기 위해 엔터티 확장이 활성화되어 있지 않은지 확인하십시오.
파일 업로드에는 CDN을 사용하세요.
엄청난 양의 데이터를 처리하는 경우 작업자 및 대기열을 사용하여 백그라운드에서 최대한 많은 것을 처리하고 응답을 빠르게 반환하여 HTTP 차단을 방지하세요.
켜는 것을 잊지 마세요 디버그 모드 꺼짐.

산출

보내다 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/웹 서비스가 의료 기록 게시/GET에 관한 것이라면 누가 데이터에 액세스할 수 있고 어떤 상황에서 액세스할 수 있는지에 대한 액세스 제어 정책을 정의할 수 있습니다.예를 들어:

의사는 치료 관계에 있는 환자의 의료 기록을 얻을 수 있습니다.
누구도 진료 시간 외에는 의료 데이터를 게시할 수 없습니다(예:9~5)
최종 사용자는 자신이 소유한 의료 기록이나 자신이 보호자인 환자의 의료 기록을 얻을 수 있습니다.
간호사는 같은 부서에 속한 환자의 의무기록을 업데이트할 수 있습니다.

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

여기에 있는 다른 표준은 다음과 같습니다.

OAuth:ID.연맹 및 권한 위임.나를 대신하여 다른 서비스에서 서비스가 작동하도록 허용(Facebook이 내 Twitter에 게시할 수 있음)
SAML:ID 페더레이션/웹 SSO.SAML은 사용자가 누구인지에 관한 것입니다.
WS-보안/WS-* 표준:이는 SOAP 서비스 간의 통신에 중점을 둡니다.SOAP(애플리케이션 수준 메시징 형식)에만 해당되며 메시징 측면을 다룹니다.신뢰성, 보안, 기밀성, 무결성, 원자성, 이벤트...액세스 제어는 다루지 않으며 모두 SOAP에만 적용됩니다.

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

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

오아시스 XACML 웹사이트
그만큼 NIST ABAC 표준

나는 OAuth를 몇 번 사용했고 다른 방법(BASIC/DIGEST)도 사용했습니다.나는 진심으로 OAuth를 제안합니다.다음 링크는 OAuth 사용에 관해 본 최고의 튜토리얼입니다.

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

REST와 관련된 보안에 관해 내가 본 최고의 게시물 중 하나가 다음에서 끝났습니다. 1 빗방울.MySpace API는 보안을 위해 OAuth를 사용하며 RestChess 코드에서 사용자 정의 채널에 대한 전체 액세스 권한을 갖습니다. 이를 통해 저는 많은 탐색을 수행했습니다.이것은 Mix에서 데모되었으며 해당 게시물을 찾을 수 있습니다. 여기.

훌륭한 조언에 감사드립니다.우리는 RESTful API를 곧 출시될 Microsoft의 Zermatt Identity 프레임워크와 통합하기 위한 준비 과정에서 사용자 정의 HTTP 헤더를 사용하여 클라이언트에서 서비스로 ID 토큰을 전달했습니다.문제를 설명했습니다. 여기 그리고 우리의 솔루션 여기.나도 찍었다 트윅님의 조언을 듣고 구입했습니다. RESTful 웹 서비스 - 어떤 종류의 RESTful API를 구축하고 있다면 아주 좋은 책입니다.

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 보안에 대해 많이 검색했으며 요청을 인증하기 위해 클라이언트에서 서버로 쿠키를 통해 토큰을 사용하게 되었습니다.서비스 중인 요청에 대한 인증을 위해 Spring Security를 사용했는데, 이는 이미 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 게이트웨이는 유연하고 고도로 구성 가능한 솔루션입니다.테스트해보고 사용해봤는데 콩 꽤 마음에 들었고 내가 본 것을 정말 좋아했습니다.KONG은 사용자를 관리하는 데 사용할 수 있는 자체 관리 REST API를 제공합니다.

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

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow