Prawidłowe użycie modułu protect_from_forgery w aplikacjach sieciowych i interfejsie API Railsy

Question

Zajmuję się tworzeniem aplikacji Rails 4, która obsługuje aplikację mobilną za pośrednictwem interfejsu API i ma interfejs WWW dla administratorów do zarządzania aplikacją. Istnieje również kilka stron internetowych, które widzą użytkownicy (pomyślne potwierdzenie adresu e-mail i zresetowanie hasła).

Utworzono dwa zestawy kontrolerów: jeden zestaw dziedziczy z APIController, a drugi z AdminController. Oba te elementy dziedziczą po aplikacji ApplicationController. Pozostały kontroler odpowiedzialny za strony przeglądane przez użytkownika również dziedziczy z aplikacji ApplicationController.

Biorąc pod uwagę ten schemat, nie jestem pewien, jak prawidłowo wdrożyć ochronę CSRF za pomocą modułu protect_from_forgery. Obecnie mam następujące:

class ApplicationController < ActionController::Base 
    # ... 
end 

module API 
    class APIController < ApplicationController 
    protect_from_forgery with: :null_session, if: Proc.new { |c| c.request.format == 'application/json' } 
    # ... 
    end 
end 

module Admin 
    class AdminController < ApplicationController 
    protect_from_forgery with: :exception 
    # ... 
    end 
end 

class UsersController < ApplicationController 
    protect_from_forgery with: :exception 
    # ... 
end 

Moje pytanie brzmi: czy to prawda? Czy jest jakiś sposób, aby to poprawić? Czy kontrola w APIController jest bezcelowa, skoro wszystkie żądania API będą tylko JSON?

Brakeman skarżył się, że nie ma modułu protect_from_forgery w ApplicationController, ale może nie widzi wywołań w podklasach.

Z góry dziękuję!

Answer 1

Widać here, on their (brakeman) Github page że sprawdza obecność na ApplicationController tylko

Administrator i Użytkownicy kontrolery są w porządku z protect_from_forgery with: :exception

Domyślne zachowanie na szynach 4 na protect_from_forgery jest :null_session, można usunąć opcja with:, jeśli chcesz.

Ulepszając, wprowadziłbym sposób zapisywania tokena w użytkowniku i dopasowywania go do każdego żądania, w ten sposób użytkownik żądający API musiałby wysłać swój token za każdym razem. Dzięki temu unikniesz konieczności uzyskania tokena CSRF, a następnie wysłałeś żądanie z tym tokenem. Dla użytkowników mobilnych jest to na przykład dodatkowa prośba, którą można rozwiązać, zapisując odpowiedni token. Jeśli ktoś dostanie ten token, może przekazać go jako użytkownika i zmienić dane. Możesz jednak znaleźć więcej sposobów na zwiększenie bezpieczeństwa.

CSRF może się zdarzyć, jeśli zapiszesz token w sesjach lub ciasteczkach, musisz zająć się tym samodzielnie, na wypadek gdybyś zdecydował się zapisać w ten sposób.

Jeśli zamierzasz korzystać z interfejsu API dla telefonów komórkowych, zapisz token (w strategii, o której mówiłem wcześniej) na telefonie komórkowym (pamięć lub lokalna db) i będzie bezpieczniejszy.