2016-09-20 4 views
5

先週のセキュリティパッチは理解できません:https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2016-022/。私は古いTYPO3 6.2のインストールがあります。すべてのcf_ *テーブルを切り捨て、UID 2-6のページを開いた。いいえ、ハッシュ。結果として、13のcf_cache_hash-entriesが表示されます。 フロントページのリスティングページから詳細ページを開きました。私は、アクション、コントローラ、現在表示されているレコードのUID、および原因のcHashのようなURLのいくつかのパラメータを参照します。 次に、私のページ2-6のURLにこれらのパラメータ(id = xを除く)をコピーしました。 cf_cache_hashにはまだ13のレコードがあります。したがって、キャッシュフラッディングはありません。13.09.2016からTYPO3セキュリティアップデートを実行した後の対応は?

またはどのように私はこの引用interpreteする必要があります:新しく生成されたページのキャッシュ エントリに有効なCHASH引数リードと

リンク。 cHashは特定のページにバインドされていないため、攻撃者 は有効なcHash引数を複数のページに使用して、 の無駄なページキャッシュエントリを追加する可能性があります。

次の問題は:

は、あなたがどのテーブルを教えてくださいすることができRealURLはのような拡張機能が使用されている場合は

、彼らの キャッシュをフラッシュするために必要とされる(とTYPO3は、同様にキャッシュします)私/私たちはクリアする必要がありますか?

  • tx_realurl_urldecodecache
  • tx_realurl_urlencodecache

は多分OKです。しかし、tx_realurl_pathcacheはどうでしょうか?原因を明確にすることはできますが、それ以前のリアルタイム設定の古いエントリはどうですか?私がそのテーブルを切り捨てると、これらの古いエントリはもはや有効ではなく、再びビルドされませんでした。そのため、古い検索エンジンの結果は無効です。

お客様からの質問:バックエンドでシステムキャッシュをクリアするだけで十分ですか、またはInstalltoolですべてのキャッシュをクリアするをクリックする必要がありますか?ニース。 IMO、それだけでは不十分で、テーブルをDB上で直接切り捨てる必要があります。右。

次の1:

これは、このようなURLが検索エンジンでインデックス化されている場合、この検索エンジン からの訪問者が正常に動作していないページに終わることを意味します。

Hey cool。そしていま?解決策は何ですか?それをそのままにしておきますか? IMOは、InstallToolの設定、pageNotFoundOnCHashErrorに依存します。右?

私たちに何をすべきか教えてください。それをどう対処するか詳細を追加してください。

ステファン

+0

これは一度に複数の質問です。 1. _ "cf_cache_hashにまだ13のレコードがあります" _ 'cache_hash'キャッシュは、URL内の' cHash'と全く関係ありません。有効なcHashが 'cache_pages'の新しいキャッシュエントリをトリガします。以前は、 'index.php?id = 1&foo = bar&cHash = abc'のようなリンクを' index.php?id = 2&foo = bar&cHash = abc'に変更することができました。 cache_pages'キャッシュエントリが作成される – helhum

答えて

3

私にとって、それは(更新TYPO3のバージョンをインストールした後)に沸く:

あなたはRealURLはを使用しない場合:「

$GLOBALS['TYPO3_CONF_VARS']['FE']['cHashIncludePageId'] = true; 

&を有効にして、あなたはおそらくあります完了しました。もちろん、すべての古いGoogleのヒットが行われますが、「公開」サイトでは、リアルール(またはそれに近い)を実行していないとGoogleのことを気にしませんでした

realurl 1.Xを6.2

(おそらく適切なパッチがあることは決してないだろう)

つのオプション設定を有効にしないでください:1.1を使用DDOS

  • のリスクを取る

    1. をバージョンhttps://github.com/mogic-le/typo3-realurl キャッシュテーブルにヒットがない場合、正しく理解すると、TYPO3をno_cacheモードに設定します。それは、パフォーマンスの問題ですが、あなたがRealURLは2.1 7.6+とRealURLは2

      1. 待ちを実行します(とリスクを取る場合、それは

      を(副作用として)行われてキャッシュテーブルのエントリを防ぐことができます?)

    2. 変更memcachedのようなものに、キャッシング フレームワーク(それはやや線の間に を提案しています:あなたがDDOSのため を使用することはできませんキャッシュバックエンドを持っている場合は、あなたが本当に気にする必要はありません)
    3. f helhum(私はそれはあなたの古い リンクについて1ビットを助けないだろうと思いますが)
  • 2

    RealURLは> = 2.1.0からORKは、このコアのオプションをサポートしています。しかし、他のさまざまなcHashの問題が修正されているため、少なくとも2.1.4に更新することをお勧めします。

    関連する問題