Ruby on Rails 내에서 안전한 REST API를 구축하기위한 제안을 찾고 있습니다.

Ruby on Rails 내에서 안전한 REST API를 구축하기위한 제안을 찾고 있습니다.

---

현재 작업중인 프로젝트를위한 REST API 빌드를 시작하고 있으며 RoR을 사용하여 API를 빌드하는 가장 좋은 방법에 대해 약간의 조사를하게되었습니다. 기본적으로 모델은 세계에 공개되어 있으며 URL 끝에 ".xml"을 입력하고 적절한 매개 변수를 전달하여 URL을 통해 호출 할 수 있다는 것을 금방 알게되었습니다.

그래서 다음 질문이 왔습니다. 무단 변경을 방지하기 위해 앱을 보호하려면 어떻게해야합니까? 몇 가지 연구를하고 나는 몇 기사에 대해 이야기 발견 attr_accessible하고 attr_protected그들이 어떻게 사용할 수 있습니다. 내가 찾은 특정 URL은 '07 년 5 월에 다시 게시되었습니다 ( 여기 ).

루비의 모든 것들이 그렇듯이 그 이후로도 진화했다고 확신합니다. 제 질문은 이것이 RoR 내에서 REST API를 보호하는 가장 좋은 방법입니까?

"새 프로젝트"또는 "기존 프로젝트"시나리오에서 무엇을 제안합니까?

---

API 요청을 인증하는 방법에는 여러 가지가 있으며 restful_authentication 또는 acts_as_authenticated와 같은 플러그인에서 제공하는 일반 인증과 다릅니다. 가장 중요한 것은 클라이언트가 세션을 유지하지 않기 때문에 로그인 개념이 없다는 것입니다.

HTTP 인증

기본 HTTP 인증을 사용할 수 있습니다. 이를 위해 API 클라이언트는 일반 사용자 이름과 비밀번호를 사용하고 다음과 같이 URL에 입력합니다.

http://myusername:mypass@www.someapp.com/

나는 restful_authentication이 이것을 즉시 지원한다고 믿으므로 누군가가 API를 통해 또는 브라우저를 통해 앱을 사용하는지 여부를 무시할 수 있습니다.

여기서 한 가지 단점은 사용자에게 모든 요청에서 사용자 이름과 비밀번호를 명확하게 입력하도록 요청한다는 것입니다. SSL을 통해 수행하면이를 안전하게 만들 수 있습니다.

나는 이것을 사용하는 API를 실제로 본 적이 없다고 생각합니다. 특히 현재 인증 체계에 의해 즉시 지원되므로 문제가 무엇인지 모르겠습니다.

API 키

API 인증을 활성화하는 또 다른 쉬운 방법은 API 키를 사용하는 것입니다. 본질적으로 원격 서비스의 사용자 이름입니다. 누군가가 귀하의 API를 사용하기 위해 등록 할 때 귀하는 그들에게 API 키를 제공합니다. 이것은 각 요청과 함께 전달되어야합니다.

한 가지 단점은 누군가 다른 사람의 API 키를 받으면 해당 사용자로 요청할 수 있다는 것입니다. 모든 API 요청에 HTTPS (SSL)를 사용하면이 위험을 어느 정도 상쇄 할 수 있다고 생각합니다.

또 다른 단점은 사용자가 어디를 가든 동일한 인증 자격 증명 (API 키)을 사용한다는 것입니다. API 클라이언트에 대한 액세스를 취소하려는 경우 유일한 옵션은 API 키를 변경하는 것입니다. 그러면 다른 모든 클라이언트도 비활성화됩니다. 이는 사용자가 여러 API 키를 생성 할 수 있도록 허용하여 완화 할 수 있습니다.

API 키 + 비밀 키 서명

사용되지 않음 (일종)-아래 OAuth 참조

훨씬 더 복잡한 것은 비밀 키로 요청에 서명하는 것입니다. 이것이 Amazon Web Services (S3, EC2 등)입니다. 기본적으로 사용자에게 API 키 (예 : 사용자 이름)와 비밀 키 (예 : 비밀번호)의 두 가지 키를 제공합니다. API 키는 각 요청과 함께 전송되지만 비밀 키는 전송되지 않습니다. 대신 일반적으로 다른 매개 변수를 추가하여 각 요청에 서명하는 데 사용됩니다.

IIRC, Amazon은 요청에 대한 모든 매개 변수를 가져와 매개 변수 이름별로 정렬하여이를 수행합니다. 그런 다음이 문자열은 사용자의 비밀 키를 해시 키로 사용하여 해시됩니다. 이 새 값은 전송되기 전에 요청에 새 매개 변수로 추가됩니다. 아마존 측에서도 똑같은 일을합니다. 모든 매개 변수 (서명 제외)를 가져 와서 순서를 지정하고 비밀 키를 사용하여 해시합니다. 이것이 서명과 일치하면 요청이 합법적이라는 것을 압니다.

여기서 단점은 복잡성입니다. 이 체계가 올바르게 작동하도록하는 것은 API 개발자와 클라이언트 모두에게 고통입니다. 작업을 수행 할 수없는 클라이언트 개발자의 많은 지원 전화와 성가신 이메일을 기대하십시오.

OAuth

키 + 비밀 서명의 복잡성 문제를 해결하기 위해 OAuth 라는 표준이 등장했습니다 . 핵심 OAuth는 키 + 비밀 서명의 특징이지만 대부분이 표준화되어 여러 언어의 라이브러리에 포함되어 있습니다 .

일반적으로 API 생산자와 소비자 모두 자신의 키 / 서명 시스템을 만드는 것보다 OAuth를 사용하는 것이 훨씬 쉽습니다.

또한 OAuth는 본질적으로 액세스를 세그먼트 화하여 각 API 소비자에게 서로 다른 액세스 자격 증명을 제공합니다. 이를 통해 사용자는 다른 소비 애플리케이션에 영향을주지 않고 선택적으로 액세스를 취소 할 수 있습니다.

특히 Ruby의 경우 OAuth의 생산자와 소비자 모두에게 즉시 지원을 제공 하는 OAuth gem 이 있습니다. 이 보석을 사용하여 API를 빌드하고 OAuth API를 사용했으며 매우 감동했습니다. 애플리케이션에 OAuth가 필요하다고 생각되면 (간단한 API 키 체계와 반대) OAuth gem을 사용하는 것이 좋습니다.

---

무단 변경을 방지하기 위해 앱을 보호하려면 어떻게해야합니까?

attr_accessible및 attr_protected액티브 모델에 대량 과제를 수행 할 수있는 능력을 제어하는 모두 유용합니다. 폼 주입 공격을 방지하기 위해 attr_protected를 사용하고 싶을 것입니다. attr_protected 사용을 참조 하십시오. 그렇지 않으면 우리가 해킹 할 것 입니다.

또한, 누구든지 Rails 앱의 컨트롤러에 액세스 할 수 없도록하려면 거의 확실하게 일종의 사용자 인증 시스템 before_filter이 필요하고 권한있는 사용자가 요청을 할 수 있도록 컨트롤러에를 삽입해야합니다. 요청 된 컨트롤러 작업을 실행하기 전에

더 많은 유용한 정보 는 Ruby on Rails 보안 가이드 (Rails 문서 프로젝트의 일부)를 참조하세요.

---

레일스 애플리케이션을위한 REST API도 구축 중이기 때문에 현재 여러분과 비슷한 질문에 직면하고 있습니다.

사용자가 편집 할 수있는 속성 만 attr_accessible로 표시되도록하는 것이 좋습니다. 그러면 update_attributes를 사용하여 할당 할 수있는 속성의 화이트리스트가 설정됩니다.

내가하는 일은 다음과 같습니다.

   class Model < ActiveRecord::Base  
       attr_accessible nil  
   end

내 모든 모델은 그로부터 상속 받으므로 대량 할당 가능하게 만들려는 모든 필드에 대해 attr_accessible을 정의해야합니다. 개인적으로이 동작을 기본적으로 활성화하는 방법이 있었으면합니다 (있을 수 있지만 그것에 대해 알지 못합니다).

누군가가 REST API뿐만 아니라 일반 양식 게시물을 사용하여 속성을 대량 할당 할 수 있다는 것을 알고 있습니다.

---

많은 것을 직접 구축하는 것을 절약하는 또 다른 접근 방식 은 개별 개발자를 위해 키, 토큰, 할당량 등을 처리하는 http://www.3scale.net/ 과 같은 것을 사용하는 것 입니다. 또한 분석을 수행하고 개발자 포털을 생성합니다.

There's a ruby/rails plugin ruby API plugin which will apply to policies to traffic as it arrives - you can use it in conjunction with the oAuth gem. You can also us it by dropping varnish in front of the app and using the varnish lib mod: Varnish API Module.

참고URL : https://stackoverflow.com/questions/247110/looking-for-suggestions-for-building-a-secure-rest-api-within-ruby-on-rails