3

Google App Engine で実行する GWT アプリを開発していますが、クロスサイト リクエスト フォージェリについて心配する必要があるのか​​、それとも自動的に処理されるのでしょうか?

認証を必要とするすべての RPC リクエストに対して、次のコードを用意しました。

public class BookServiceImpl extends RemoteServiceServlet implements
BookService {
    public void deleteInventory(Key<Inventory> inventoryKey) throws NotLoggedInException,  InvalidStateException, NotFoundException {
        DAO dao = new DAO();
            // This will throw NotLoggedInException if user is not logged in
        User user = dao.getCurrentUser();
            // Do deletion here
    }
}

public final class DAO extends DAOBase {
    public User getCurrentUser() throws NotLoggedInException {
            currentUser = UserServiceFactory.getUserService().getCurrentUser();
            if(currentUser == null) {
                throw new NotLoggedInException();
            }
        return currentUser;
    }

UserServiceが認証をチェックする方法に関するドキュメントが見つかりませんでした。上記のコードに頼るだけで十分ですか、それとももっと頼る必要がありますか? 私はこれの初心者ですが、CSRF攻撃を回避するために私が理解していることから、いくつかの戦略は次のとおりです。

  1. Cookie をチェックするだけでなく、リクエスト ペイロードに認証トークンを追加する
  2. HTTP Referer ヘッダーの確認

SID 値のように見える Google からの Cookie が設定されていることはわかりますが、ペイロード内のシリアル化された Java オブジェクトからは、トークンが渡されているかどうかを判断できません。また、Referer ヘッダーが使用されているかどうかもわかりません。

それで、私は問題がないことを心配していますか？そうでない場合、ここでの最善の戦略は何ですか? これは十分に一般的な問題であり、標準的な解決策が存在する必要があります...

4

1 に答える 1

6

同じコードを通常のサーブレットに入れると、XSRF に対して確実に脆弱になります。しかし、RemoteServiceServletGWT を使用しているため、答えは使用している GWT のバージョンによって異なります。

まだリリースされていない GWT 2.1 以降、RPC メカニズムはリクエスト ヘッダーを追加し、これらのヘッダーが RemoteServiceServlet に存在することを検証します。これには制限があります。特に、Flash の古いバージョンでは別のドメインからリクエスト ヘッダーを送信できますが、潜在的な攻撃者にとってはより困難になります。

XSRF から適切に保護したい場合は、Lombardi の開発ブログを参照してください。このブログでは、2 つの手法について説明しています。1 つ目は、2.1 の変更を古いバージョンの GWT に移植する単純な変更です。2 番目のアプローチでは、セッション ID を要求パラメーターとして複製する必要があり、XSRF から保護するために推奨される方法です。

参考文献

  1. GWT RPC - CSRF から保護するのに十分ですか?
  2. GWT RPC と XSRF に関する Lombardi 開発ブログ
  3. GWT アプリケーションのセキュリティ
于 2010-06-05T17:01:46.210 に答える