メインのブラウザとして使っていたKinzaの開発が終了したらしい。Google APIにアクセスできなくなってGoogleアカウントと同期できなくなったためということだ。ウチではGoogleアカウントの同期とか使っていなかったので、使えなくても構わないのだが。いずれにしても開発終了してしまったなら、セキュリティの問題もあるので別のブラウザに乗り換えざるを得ない。
普通はChromeということになるのだろうが、ブックマークを新規タブで開けないのがめんどくさい。右クリックメニューや真ん中ボタンを使えばいいのだが、頻繁に使う機能なので、余計な1アクション増えてしまうのは抵抗がある。

Chromeを試してみたらローカル環境でもひっかかった。Xamppを使ったローカル環境でhttpsアクセスすると、やたらセキュリティ警告が出るのだ。Kinzaでも時々は出ていたのだが、一度「リスクを承知でアクセス」するとしばらくは出なかった。Chromeだとしつこいほどに出る。
ローカルサーバーではhttpしか使わないことにしてもいいのだが、できれば.htaccessファイルなども含めてWebサーバーと同じ環境でテストしたいので、httpsでアクセスできるようにしておきたい。
どうもXamppでインストールされる証明書が2019年で期限が切れているのが原因らしい。Chromeの警告は正常に動作しているだけなのかもしれないが、うるさいことには違いない。有効な証明書をインストールしてやればいいらしいのだが、まともにやると結構手間がかかりそうだ。
調べてみると、mkcertというソフトを使えば、ローカルサーバー用の証明書を簡単に作れるらしい。試してみると確かに簡単に作れた。C:\xampp\apache\conf\ssl.crt、C:\xampp\apache\conf\ssl.keyディレクトリ内にあるserver.crtファイルとserver.keyファイルをmkcertで作成したファイルで上書きすると、警告が出なくなった。

Firefoxも試してみた。
Firefoxを触るのは久しぶりだが、ブラウザによる見た目の違いは昔ほどはないようだ。しかしCSSの解釈が微妙に違うところがあるようで、たとえばこのサイト構成に使っているterm.phpはFirefoxではリンクが効かなくなるケースがあることに初めて気づいた。フォームの入力フィールドのサイズもChrome系とかなり違う。メインブラウザとして使わないとしても、たまにはFirefoxでの表示もチェックしたほうがいいかもしれない。Firefoxもブックマークを新規タブで開く設定はないが、隠し機能でブックマークから新規タブで開くことができる。

ブックマークを新規タブで開くなんて普通にメニューで設定できてもよさそうなものだが、これができるブラウザは少ないようだ。なんでなんだろう。セキュリティの問題かなんかあるのだろうか。target=”_blank”で別ページを開く場合は親ページが改竄される危険があるらしいが、ブックマークは親ページとか関係ないと思うのだが。

逆にChrome系にしかないと思っていたレスポンシブ対応確認のための表示は、ほとんどのブラウザでできるようだ。できるに越したことはないのだが、これはWeb開発しているユーザーでないと必要ない機能だ。

で結局Vivaldiにした。Kinza同様タブ、ブックマーク関連のメニューが豊富で、標準機能でブックマークを新規タブで開けるからだ。

掲示板の迷惑投稿を防ぐ方法としては、ロボットではなく人が投稿していることを確かめるため、ロボットには読めないはずの画像による文字を読ませて入力させたり、複数の画像から質問に該当するものを選択させたり、掲示板に投稿する利用者に一手間かけさせるものが多い。
ここでは、なるべくユーザーに余計な手間をかけさせず、スパムを防止する有効な方法がないものか考えていきたいと思う。

投稿ID方式

フォームに隠しパラメータを仕込んでおいて、その値を送ってこない投稿は不正投稿としてブロックするという対策法は昔からある。しかしフォームのhtmlを解析しているのか、正しい隠しパラメータを送信してブロックを回避するスパム投稿は多いので、これだけではあまり効果のある対策とはいえない。フォーム表示のたびにランダムな値に変更しても同様だ。
しかし、最近これに投稿までの時間を計測して、あまりに早いものはスパムとして判断してブロックするという対策がどこかで紹介されていた。

• スパム対策研究用掲示板
• 拒否したログ一覧 2025-11-17 16:18:23更新
• アクセスの解析 2025-11-17 16:24:45更新

リンク元　ユーザーエージェント

スパム投稿の動向を分析するためで環境変数でリンク元やユーザーエージェントをログに残してみたが、こうした情報もスパムかどうか判定するヒントになるかもしれない。
リンク元はPerlの場合、環境変数$ENV{'HTTP_REFERER'}で得られる。たとえばこのページのリンクから掲示板にアクセスしたら

http://shade-search.com/sts/term/term.php

がHTTP_REFERERになる。いったん掲示板を開いて掲示板の他のページから移動した場合は掲示板CGIのURL　たとえば

http://shade-search.com/sts/fsw/yybbs/yybbs.cgi?type=2

のようなものになるはずだ。

Clip Board改造版のサンプルとして設置している掲示板に、また新しいタイプのスパムが来ているようだ。こちらも調査したい。
まだ投稿キーも搭載されていない頃のバージョンをベースに改造したものだったが、改造版投稿キーに入れ替えていたので、そこそこスパムはブロックできていたようだ。オリジナルのClipboardの最新版に更新した上で、URLを引き継ぐためにディレクトリ名とcgiのファイル名は以前のclip/clip.cgiに戻した。改造版の方もとりあえずディレクトリ名を変更して残しておくことにする。

掲示板(YY-BOARD)と同様に、ひらがなチェック、投稿IDチェック、ダミーフィールド処理を追加し、どの処理が有効かログを残すことにする。

• 研究用掲示板2(Clipboard)
• 拒否したログ一覧
• アクセスの解析 2025-11-17 09:39:57更新

掲示板2の方はアクセスが少ないが、投稿IDを送ってこないというタイプのスパムがいるようだ。これは初めてのケースだ。投稿キーはクリアし、スタイル指定で隠したダミーフォールドの値は送ってきているのに、hiddenを指定したinputタグに気づかないのも不思議だが、単純にオリジナル掲示板CGIで送られるはずの値を送っているだけかもしれない。
いずれにしても、新しいタイプではなく、むしろ古いタイプのスパムのようだ。投稿IDを送ってこないので、時間を計測する必要も無く、その時点で拒否するだけで済むので対策は簡単だ。
と思っていたら、掲示板の設定ミスで投稿IDがフォームにセットされていなかったことが判明^^;
ひらがなチェックや投稿キー、ダミーフィールドにも引っかからず、投稿IDだけで拒否していたスパムもあるようなので、気になる。ダミーフィールドに引っかからないということは、HTMLを見ていないという可能性も残っているが。

それと、フォームにアクセスせず、いきなり投稿してくるタイプがあることも拒否ログを見てわかった。

こちらの掲示板はスパム投稿の頻度は低いが、たまに来るものの中に投稿ID、ダミーフィールドどちらも突破してくるスパムがある。やはりJavaScriptを使わざるを得ないか。

スパム投稿対策研究のために設置した掲示板を長いこと放置していたら、スパム投稿でひどいことになっていた。対策は継続してやらないとダメのようだ。
旧掲示板のURLから今回新たに公開したbbs.phpにリダイレクトするようにした。PHP/掲示板PHP

• ./yybbs/yybbs.cgi → ./yybbs/bbs/bbs.php
• ./clip/clip.cgi → ./clip/bbs/bbs.php

できればスパム投稿を続けてもらって、bbs.phpがどれだけスパム防止効果があるか調べてみようということだ。とはいってもフォームから投稿してくるスパムはほとんど無いと思うので、これまでのスパムがすべて新掲示板に流れるわけではないと思うが。
・・・と思っていたが掲示板2の方はさっそく前の掲示板と同じ傾向のスパム投稿が来ている。JavaScriptのスライドロックも効果が無いので、ひょっとしたら人が投稿している？

bbs.phpのスライドロックは、ロボットはJavaScriptは無視するらしいということに期待して、JavaScriptで表示するロックを外さないと投稿できないという仕組みだ。ボタンを横にスライドするだけなので、読みにくい文字を入力したり、写真を選ぶ必要はない。この記事のテーマであるユーザーの負担が少ないスパム投稿対策というわけだ。

改行コードってあまり気にしていなかったが、あまり無頓着だとトラブルになるようだ。
Linuxサーバー上での動作をチェックするために久しぶりにCGIファイルをWebサーバーにアップロードしてみたのだが、
500エラーで動作しないという問題が発生した。パーミッションをいじっても動くようにならず、なんでだと思っていたら
CGIファイルの改行コードがCRLFになっていたのが原因だった。

以前はCRLFでもエラーは出ていなかったはずと思ったが、どうも以前はFTPソフトでテキストモードでアップロードしていたので、自動的に改行コードがサーバーにあったものに変換されていたようだ。最近はテキストモードではなくバイナリモードでアップロードしているので、CRLFのファイルはCRLFのままアップされる。

整理しておくと改行コードはLF、CR、CRLFとあって、OSによって使う改行コードが違う。
LinuxなどUNIX系はLF、MacはCR、WindowsはCRLFを使う。プログラムでは、LFは"\n" CRは"\r" CRLFは"\r\n"と記述する。

でWeb上のサーバーはLinux系が多いので、そこで使用するCGIファイルはLFを使わなければならないということなのだろうが、不思議なことにPHPはCRLFのままでも問題なく動いている。
それとWindowsにインストールしたXamppでは、WindowsなのでCRLFで動くのは当然として、LFでも問題なく動く。

Webサーバー上のCGIファイルの改行コードは、OSで使用する改行コードを使うことが望ましいが、使わないと絶対ダメというほどではないということか。いずれにしても、WebプログラムのファイルはLFで統一しておくのが無難かもしれない。
ちなみにWindows標準のテキストエディタ「メモ帳」は、以前はLF改行コードでは改行されなかったが、最近のはちゃんと改行されるようだ。

長過ぎる文字列を切り詰めて短くしたいことがよくあるので、指定した文字数以上の文字は指定数に切り詰めて省略記号をつけるという処理のために以下のような関数を使っていましたが、思うように動かないことが多々ありました。

function jtruncate($str,$n) {
	if ($n < 2) { return ; }
	if (strlen($str) <= $n) { return $str ; }
	$substr = mb_substr($str,0,intval($n/2),"UTF-8") . '...';
	return $substr;
}

たとえばこの関数を使って

print jtruncate('PHPのコード',14);

を実行すると

PHPのコード...

と切り詰めていないはずなのに切り詰めた記号...が表示されてしまいます。

Web上で使用するパスワードはほとんど半角英数字と記号を使うので、全角の日本語は使えないと思っていたが、必ずしもそういうわけではないようだ。この用語集作成スクリプトterm.phpや掲示板スクリプトbbs.phpでも、管理者認証などのためパスワードを設定することになっているが、試しに日本語のパスワードを設定したところ、問題なく使えた。

しかし、一般的には日本語のパスワードは使えないということになっている。たぶんパスワードの入力に のようなpasswordフィールドを使っているからだと思う。このpasswordフィールドは、入力した文字が伏せ字になるだけでなくIMEが無効になっているので、日本語が入力できないのだ。直接入力するのではなくコピーアンドペーストすれば入力できないことはないが、半角文字が使われていないとかいわれて受け付けられない場合もあるだろう。
パスワードの入力にpasswordフィールドを使っているのは、入力画面を盗み見るショルダーハッキング対策だと思うが、入力した本人にも見えないので、正しく入力できているのか確認しにくいという問題もある。(特に新しいパスワードを登録する場合)

今更ですが、暗号化とハッシュ化をごっちゃにした記事がいくつかあったので、修正しておきます。
暗号化もハッシュ化も元のデータがわからないように変換することですが、暗号化は元のデータに戻す方法があり、ハッシュ化は元のデータに戻せないという大きな違いがあります。

ハッシュは元のデータに戻すことはできませんが、元のデータから生成されたものであるかどうかは判定することができるので、それを利用してパスワード認証によく利用されています。
ユーザーがパスワードを登録する際に、パスワードそのものではなくパスワードのハッシュを保存します。
ユーザーがパスワードを入力した際には、パスワードのハッシュが入力されたパスワードから生成されたものであるかどうか判定することによって、正しいパスワードかどうかを判断します。
生のパスワードを保存しないことによって、万一データが漏洩した際の安全性も上がります。