先週のセキュリティパッチは理解できません: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に依存します。右?
私たちに何をすべきか教えてください。それをどう対処するか詳細を追加してください。
ステファン
これは一度に複数の質問です。 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