web-dev-qa-db-ja.com

htaccessが作成者のクエリ文字列を WP サブフォルダーにあります

/author/username/または?author={#id}クエリ文字列を問わず、あらゆる種類の著者ページへのアクセスを禁止しました。

私はこれを私のhtaccessファイルの始めに加えてこれをしました：

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_URI} ^/author/
    RewriteRule .* - [F]
    RewriteCond %{QUERY_STRING} ^author=([0-9]*)
    RewriteRule .* - [F]
</IfModule>

しかし、ワードプレスが物理的にサブディレクトリにあるときも同じことはできません。

最初の部分はうまくいきます：

RewriteCond %{REQUEST_URI} ^/subdir/author/
RewriteRule .* - [F]

しかし、2番目の部分をどのように編集しようとしても、/subdir/?author=1は/subdir/usernumber1/に私を連れて行き、それは大丈夫ですが、これはこの全体の目的を破ります。

何か案は？

編集：

はい、ユーザー名が表示されないようにしていました。

昨日の最後の瞬間、私は解決策を思いつくことができました。

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_URI} ^/subdir/author/
    RewriteRule .* - [F]
    RewriteCond %{REQUEST_URI} ^/subdir/
    RewriteCond %{QUERY_STRING} ^author=([0-9]*)
    RewriteRule .* - [F]
</IfModule>

私は以下の答えに基づいてそれを短くすることができるかもしれません（私はとても感謝しています）。

そしてはい、これはsubdirに置かれます。

最初のスニペットは、ルートディレクトリに置かれていましたが、うまくいきませんでした（あるいは実際にはうまくいく途中で試したソリューションの中に、すでに著者ページへのリダイレクトがキャッシュされているものもあります）.

htaccessauthormod-rewrite
2
D. Dan

問題は.htaccessでこれを行うことですが、代わりにWordPress内から作成者ページを無効にしないのはなぜですか？

これはサブディレクトリの問題を全く無関係にしながら同じ結果を達成します（そしてパーマリンク構造の設定に関係なく動作します）。

作成者ページへのすべてのURLを404エラーに設定するサンプルコード：

add_action( 'template_redirect',
        function() {
                if ( isset( $_GET['author'] ) || is_author() ) {
                        global $wp_query;
                        $wp_query->set_404();
                        status_header( 404 );
                        nocache_headers();
                }
        }, 1 );
add_filter( 'author_link', function() { return '#'; }, 99 );
add_filter( 'the_author_posts_link', '__return_empty_string', 99 );

（このプラグインから取られたコード： 著者のアーカイブを無効にする ）

1
Iceable

スキャナーがサイトのユーザー名を取得するのを防ごうとしていると思います。そして、セキュリティのために、可能な限り最初の境界ゲートでブロックすること、つまりPHPではなく.htaccessでブロックすると信じています。

サブディレクトリが問題を引き起こす理由はわかりません。ルートとWPサブディレクトリの両方のhtaccessファイルに条件を追加してみても、まったく問題はありません。私はあなたのものとかなり似た書き換え条件を使用し、サブディレクトリにWPがあるかどうかに関係なくサイトで動作します：

RewriteCond %{QUERY_STRING} author=
# redirect away from site
RewriteRule (.*) https://www.fbi.gov/investigate/cyber/%1 [R=302,L]

また、 Jeff Starrの6G "firewall" の修正バージョンを使用して、WPScanユーザーエージェントをさらに確認します。このスキャナーはハッカーに人気があり、管理者ユーザー、脆弱なプラグインの使用などを特定するためにオンラインの「URLを入力する」セキュリティスキャナーによっても使用されます。 ：

<IfModule mod_setenvif.c>
  # numerous 6G UA Checks (OMITTED)
  #check for WPScan
  SetEnvIfNoCase User-Agent "WPScan" bad_bot
  # Apache >= 2.3
  <IfModule mod_authz_core.c>
    <RequireAll>
    Require all Granted
    Require not env bad_bot
    </RequireAll>
  </IfModule>
</IfModule>

OPに関するM Kaplunのコメント：

Markのプラグイン ;を知りませんでしたPHPに対する私のコメントにもかかわらず、それは明らかにすぐに使えるワンストップソリューションです。私は別のアプローチを取ります（これは、Markが言及したテーマによるユーザー名漏洩の問題を「解決」します）。

表示名を変更（WPダッシュボード経由）およびスラッグを作成（usersテーブルで「user_nicename」を編集、または Author Slugプラグインの編集 を使用）してユーザー名と完全に異なるようにします。

そう：

  1. 著者のクエリ文字列（ハッカー）を含むリクエストはリダイレクトされます（上記の2行のhtaccess）。

  2. テーマ別の投稿に追加された著者のリンクは、まだ友好的で働きます。関連する「作成者のページ」に移動しますが、作成者スラッグはユーザー名を識別しなくなります。例えば私のサイトでは、（有効な）著者リンク（表示名「AW」）でhttps://wptest.means.us.com/author/not-for-scanners/に移動し、私の投稿のリストを確認できます。

これは、多くの著者がいるサイトでは実用的ではありません。たぶん（@Mark Kaplun @ mark-kaplun）のプラグインを拡張して、スラッグの変更を自動化することができます（DB内のすべてのuser_nicenameをハッシュしますか？）

公開されているユーザー名は危険ですか？

Wordpress.orgのコンセンサスは、ユーザー名 "leakage"は セキュリティリスクではない であるということです。しかし、潜在的な可能性を提供します一部のユーザーが最初の試行でハッキングされる（ブルートフォースは不要）。

フレンドリーなURLスラッグ/author/hclintongmailcomは、電子メールと（大文字と小文字を区別しない）ユーザー名[email protected]を持つ著者であることを理解するために天才である必要はありません。

ハッカーのパスワードリストには、10億以上の（思い出す？からの）メールアドレスがあります（小さなサブセット https://haveibeenpwned.com/ ）。多くのユーザーがサイト間で同じパスワードを使用し、パスワードを変更しません。 したがって、別のサイトで侵害されたメールユーザー名とパスワードを持つ作成者は、サイトでの最初の試行で「ハッキング」される可能性があります。

1
scytale

@Iceableが示唆しているように、これはおそらく.htaccessを使用してあなたの特定の質問に答えるのではなく、「WordPressの方法」で処理するのが最善です。

しかし、2番目の部分をどのように編集しようとしても...

「第二部」を編集する必要はありません。 「2番目の部分」は、URL-pathではなくクエリ文字列をチェックするだけです。これは、WordPressがサブディレクトリにインストールされているときには変わりません。

また、.htaccessファイルがWordPressがインストールされているサブディレクトリの中にあると仮定すると、あなたのディレクティブは単純化できます。サブディレクトリを参照する必要はありません。

RewriteRule ^author/ - [F]
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F]

.htaccessファイルがWP installのルートにある場合、これらのディレクティブはWPのインストール場所に関係なく機能します。

REQUEST_URIサーバー変数に対してチェックするよりも、（可能な場合）RewriteRule pattern を使用してURLパスをチェックする方が効率的です。また、RewriteRule pattern はURLパスからdirectory-prefixを引いたものと一致します（したがって、これは追加の作業なしにあらゆるサブディレクトリに対して自然に機能します）。 REQUEST_URIサーバー変数にはURLパス全体が含まれているのに対して、サブディレクトリはすべて明示的に考慮する必要があります。

また、これらのディレクティブがオプションであることを意図していない限り、<IfModule mod_rewrite.c>コンテナは必要ありません。

1
MrWhite