5

JSR 303 Bean 検証用のHibernate Validator impl や、 ESAPIバリデーター インターフェイスとそのDefaultValidator実装など、入力検証用のさまざまなフレームワークを見てきました。

ESAPI 入力検証は、ESAPI.properties ファイルによる正規表現パターン マッチングを中心に展開します。

ESAPI ルート:

ESAPI プロパティ:

Validator.SafeString=[A-Za-z0-9]{0,1024}$

Java クラス:

ESAPI.validator().isValidInput("Name","darthvader", "SafeString", 255, false)

Hibernate Validator/Spring MVC ルート

Hibernate には、さまざまな制約アノテーション (@NotNull、@Size、@Min、@Pattern、@Valid など) を使用して Bean にアノテーションを付けることが含まれます。また、Spring MVC を検証ルールに統合します。

@RequestMapping(value = "/appointments", method = RequestMethod.POST)
public String add(@Valid User user, BindingResult result) {
    ....
}

Hibernate Validator/Spring MVC を使用すると、正規表現マッチングなどで同様の機能が提供されるようです。Hibernate Validator API よりも ESAPI ライブラリを使用する利点はありますか? 多分SQLインジェクション/ XSSまたはその性質のものですか？XSS/SQL インジェクションに対するセキュリティは、ESAPI 入力検証フレームワークにすぐに提供されますか? どちらか一方を使用するよりも実際の利点があります。前もって感謝します。

私自身の質問への回答: 私は投稿の独自の解決策にたどり着いたと思います。Hibernate/Spring MVC を使用すると、かなり堅牢な Bean 検証機能が可能になります。また、Hibernate は @SafeHtml、@Pattern などのセキュアなアノテーションを提供します。基本的に、Bean 検証を提供するアノテーションの複合セットを設定できます。http://docs.jboss.org/hibernate/validator/5.0/reference/en-US/html_single/

4

2 に答える 2

6

Hibernate バリデータ API よりも ESAPI ライブラリを使用する利点はありますか?

私はセキュリティ担当者なので、最初に言いたいのは、入力の検証について心配する前に、セキュリティ レベルについて心配する前に、バックエンドの科学にコンテキスト エスケープがあることを確認してくださいということです。入力の検証。データがデータベースに送信される場合は、クエリ (または準備されたステートメントまたはストアド プロシージャ) のためにエスケープしていることを確認し、そのデータを処理するときに、ダウンストリームの Web サービス/コマンド ライン/などに送信されるように適切にエスケープします。そのデータをユーザーに再提示するとき (html/javascript/actionscript/etc)

必須の部分を片付けたので、両方のライブラリは非常に異なる目的で使用されます。ESAPI の主な設計目標は、最初からセキュリティ メカニズムなしで設計された不運なアプリケーションを保護するのに役立つように設計することです。たとえば、SQL インジェクション用にデータをエンコードする手法が事前にパッケージ化されていますが、複雑さ/時間の制約などのために、パラメーター化されたクエリやストアド プロシージャとしてすぐに書き直すことはできません。ただし、Hibernate は JPA 実装として設計されており (ご指摘のとおり)、JSR 仕様への参照は Hibernate の実装に光を当てます。

データの検証は、プレゼンテーション層から永続化層まで、アプリケーション全体で発生する一般的なタスクです。多くの場合、同じ検証ロジックが各レイヤーに実装されているため、時間がかかり、エラーが発生しやすくなっています。各レイヤーでのこれらの検証の重複を避けるために、開発者は多くの場合、検証ロジックをドメイン モデルに直接バンドルし、実際にはクラス自体に関するメタデータである検証コードでドメイン クラスを混乱させます。

これは明らかにドメイン層の検証を処理するためのものであり、Hibernate が実際にはアプリケーションの間違った層でいくつかの便利なメソッドを提供しているという卑劣な疑いを持っています。プレゼンテーション層に。ドメイン モデルで可能な HTML をクリーンアップまたはパントするべきではありません。最初に HttpRequest オブジェクトからデータをプルするコントローラー/サービスレイヤーでパントする必要があります。データが検証されたら、データを Domain オブジェクトに変換して、バックエンドに渡します。また、Hibernate を使用しても、@SafeHtmlそのデータが正当な JavaScript であるが正当な HTML ではない場合、JavaScript 攻撃から保護されません。 これこれが、出力エスケープが入力フィルタリングよりも 100 倍重要である理由です。

最初の質問に答える:

Hibernate バリデータ API よりも ESAPI ライブラリを使用する利点はありますか?

  1. 何よりもまず、Hibernate の「@SafeHtml」は JSR 303 仕様の一部ではないため、これを使用することで、JPA 実装を Hibernate に直接関連付けることになります。これはメンテナンスに悪影響を及ぼします。
  2. ESAPI のバリデータは、バリデーションを変更する機能を提供しますvalidator.properties。つまり、アノテーション駆動型モデルで現在行われているように、開発に行ってまったく新しいビルドを作成する必要がなく、本番環境でビジネス上の問題を処理できます。
  3. ESAPI のバリデータは、セキュリティの専門家によって設計、作成、およびテストされました。
  4. これは最も重要なことです。ESAPI は ESAPI.encoder().canonicalize()、ESAPI の呼び出しのいずれかで暗黙的に使用されるメソッドを提供しますValidator.getValidHtml(args...)。この方法だけで、誰かがアプリケーションに対して複数のエンコード攻撃を試みているかどうかを判断できます。同様の呼び出しは、私が知っている他の Java セキュリティ ライブラリには存在しません。間違いなく、Hibernate のバリデータ実装にも存在しません。ドメイン ライブラリであるため、Hibernate がその呼び出しを行うことは決してありません。

4 の重要性はいくら強調してもしすぎることはありません。これは、ほとんどの XSS が実際にアプリケーションに挿入される方法として、複数のエンコード攻撃が使用されるためです。これにより、すべての入力が 1 つずつ URL エンコードされるように強制され、そのような入力をアプリケーションに入力しようとしているユーザーをすぐに識別することができます。

ESAPIには大きな欠点があります。2014 年秋の時点で、コミュニティの開発が停滞したため、OWASP で旗艦の地位を失いました。ESAPI 3.0 でボールが転がり始めるかどうかは、時間が経てばわかります。

于 2015-01-22T14:30:10.067 に答える
0

参考までに、Hibernate Validator に基づいて、入力検証専用の一連の注釈を作成しました。

https://github.com/righettod/hibernate-validator-security-contribs

これが役立つことを願っています:)

于 2014-02-23T10:09:29.810 に答える