ポストインクルードでは通常「ACMS_POST_2GET」モジュールを利用します。

<form action="" method="post" class="js-post_include-ready">
  <input type="text" name="keyword" value="" size="15" />
  <input type="hidden" name="bid" value="%{BID}" />
  <input type="hidden" name="cid" value="%{CID}" />
  <input type="hidden" name="tpl" value="include/search.html" />
  <input type="submit" name="ACMS_POST_2GET" />
</form>

ACMS_POST_2GETモジュールは、POSTする情報（ブログ情報、エントリ情報、テンプレート、キーワードなど）から、URLに変換してリダイレクトします。ポストインクルードではこのリダイレクトされたURLのHTMLを取得して表示します。

POST_2GET_Ajax

Ver. 3.1.17 から新しいモジュール「ACMS_POST_2GET_Ajax」が利用できるようになりました。

ACMS_POST_2GETモジュールとの違い

tpl指定した場合の挙動が異なります。「ACMS_POST_2GET」モジュールの場合、tpl指定されていても、URLにtplコンテキストが入らない場合があります。

以下のポストインクルードを例に実際に取得するHTMLのURLの違いを見てみます。ここで「%{CID}」は「news」カテゴリーを指定しているものとします。

<form action="" method="post" class="js-post_include-ready">
  <input type="text" name="keyword" value="" size="15" />
  <input type="hidden" name="bid" value="%{BID}" />
  <input type="hidden" name="cid" value="%{CID}" />
  <input type="hidden" name="tpl" value="search.html" />
  <input type="submit" name="ACMS_POST_2GET" />
</form>

ACMS_POST_2GETの場合

https://example.com/news/search.html?keyword=xxxxxx

ACMS_POST_2GET_Ajaxの場合

https://example.com/news/tpl/search.html?keyword=xxxxxx

この場合「ACMS_POST_2GET」の場合は「themes/ご利用テーマ/news/search.html」テンプレートがないと404になりますが、「ACMS_POST_2GET_Ajax」の場合は、tpl指定されているので「themes/ご利用テーマ/search.html」があれば取得できることになります。

「ACMS_POST_2GET」の場合でも、テンプレートをカテゴリディレクトリに設置すれば解決しますが、多くのカテゴリがある場合は同じテンプレートをカテゴリー毎に設置しないといけなくなります。

「ACMS_POST_2GET_Ajax」であれば、必ずURLに「tplコンテキスト」が入るので、1つのテンプレートで済みます。

Ver. 3.1.17 以降のバージョンの場合、ポストインクルードで指定するモジュールは「ACMS_POST_2GET_Ajax」をご利用ください。

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）は、ユーザーが意図しないリクエストを第三者が送信する攻撃手法です。攻撃者は、認証されたユーザーを利用してそのユーザーの権限で悪意ある操作を行わせることを狙います。

a-blog cms を利用すればCSRF攻撃からサイトを簡単に保護できます。

CSRF攻撃の防止

a-blog cms では、CSRFトークンを使用してCSRF攻撃に対応しています。

システムによって管理されているユーザーセッションごとにCSRF「トークン」を自動的に生成します。 このトークンはユーザーのセッションに保存され、CMSが生成するHTMLにも自動的に埋め込まれるようになっております。

ユーザーが何かリクエストする際には、テンプレートに埋め込まれたCSRFトークンも一緒に送信することで、ユーザーセッションに保存されているトークンと比較し、悪意あるリクエストを排除することが出来るようになります。

以下では、CSRFトークンが使用されるリクエストや、CSRFトークンの生成方法について解説します。

CSRFトークンが必要な操作

a-blog cms で CSRFトークンが必要な操作について列挙します。

POST操作

POSTモジュールは基本的にCSRFのチェックを行いますが、例外として以下のPOSTモジュールはCSRFトークンをチェックしません。

• ACMS_POST_2GET
• ACMS_POST_2GET_Ajax
• ACMS_POST_Download
• ACMS_POST_Login_Check
• ACMS_POST_Member_SigninRedirect

Ajax（ポストインクルード）によるGETリクエスト

通常GETリクエストは、CSRFトークンをチェックしませんが、Ajaxリクエストの場合、CSRFトークンによる認証をする場合があります。

URLコンテキストで「tpl」が指定されている場合

通常以下のようなURLコンテキストにtplが入ったURLは404になり取得できません。

https://example.com/news/tpl/search.html

ただAjaxの場合は、CSRFトークンを使用して取得することが可能です。

取得HTMLが部分HTMLだった場合

通常a-blog cmsは、部分的なHTMLの取得を許可しませんが、Ajaxの場合は、CSRFトークンを使用することで部分的なHTML取得が可能になります。

ajax_security_level: 2 # ajaxリクエストのセキュリティレベルを設定します。（0: チェックなし 1: RefererとHttpヘッダーを確認 2: CSRFトークン確認）

CSRFトークンの生成条件

以下の条件の場合にユーザーセッションをスタートさせ、CSRFトークンを生成します。

• ログインしている時
• POSTリクエストの時
• 「ACMS_POST_Form_」から始まる文字列がテンプレートにある時
• 「ACMS_POST_Comment_」から始まる文字列がテンプレートにある時
• 「ACMS_POST_Shop」から始まる文字列がテンプレートにある時
• 「ACMS_POST_2GET_Ajax」から始まる文字列がテンプレートにある時
• テンプレートに「check-csrf-token」文字列がある時
• シークレットブログ・カテゴリーだった時
• ログインページなど認証系の画面の時
• phpで「IS_OTHER_LOGIN」定数が定義されている時

CSRFトークンの埋め込み場所

生成されたCSRFトークンはレスポンスされるHTMLに埋め込まれます。

form要素

HTMLのform要素内の最後に、自動でinput要素が埋め込まれます。

<form method="post">
  ...
  <input type="hidden" name="formToken" value="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">
</form>

metaタグ

HTMLのメタタグとして、head要素内に自動で埋め込まれます。

<meta name="csrf-token" content="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">

標準機能外でCSRFトークンを利用する

標準機能は、特に何もしなくてもCSRF対策がされていますが、独自にJavaScriptでリクエストを送ってレスポンスを受け取る場合などは、自身でCSRFトークンをリクエストに含める必要があります。

POSTリクエストの場合

POSTデータに以下情報を含める必要があります。

formToken: xxxxxxxxxxxxxxx

独自に開発したPOSTモジュールにJavaScriptからリクエストする例

const csrfToken = document.querySelector('meta[name="csrf-token"]').content; // メタタグからCSRFトークンを取得
const formData = new FormData();
formData.append('ACMS_POST_CustomModule', 'exec');
formData.append('formToken', csrfToken);

const response = await fetch(url, {
  method: 'POST',
  body: formData,
});

GETリクエストの場合

HTTPヘッダーに以下情報を必要があります。

Referer: https://example.com/xxxxxxx
X-Requested-With: XMLHttpRequest
X-Csrf-Token: xxxxxxxxxxxxxxxxxxx

HTMXライブラリ にCSRFトークンをセットする例

document.addEventListener("htmx:configRequest", function(event) {
  const csrfToken = document.querySelector('meta[name="csrf-token"]').content; // メタタグからCSRFトークンを取得
  event.detail.headers['X-CSRF-Token'] = csrfToken;
});

a-blog cms では、ログインセッション時間を「.env」ファイルで設定できるようになっています。
デフォルトでは、72時間有効です。

# セッション
SESSION_COOKIE_LIFETIME=259200 # セッションのCookie有効期限

ただしサーバーの環境によっては、30分程度でログアウトしてしまう現象が発生することがあります。

原因

セッション管理にはPHPのセッションの仕組みを利用しています。 このセッション情報はデフォルトですとサーバー上のファイルとして管理しているのですが、このセッションファイルの有効期限が短い可能性がございます。

PHPデフォルトの設定だと、1/100の確率で、24分より古いセッションファイルが消えるので、これが影響している可能性が高いです。

session.gc_maxlifetime

サーバに保存されているセッションファイルを保護する有効期限。

session.gc_probability / session.gc_divisor

セッションファイルが消える確率。「session.gc_probability / session.gc_divisor」の確率で削除されます。

対策

php.ini で「session.gc_maxlifetime」の期限を伸ばしていただくか、config.user.php に以下コードを設定ください。

ini_set('session.gc_maxlifetime', 259200); // 72時間を設定