先のエントリーAJAX で、動的にテーブルを作る方法（初級）では、感じをつかむために、ベタにテーブルを作成していたため、重複するロジック／コードが多かった。ここではそれをフレームワークっぽくした。こういう軽量なコードを理解した上で、ひな型として自分で持っておくと見通しがよくてよいと思う。 この JavaScript ではできるだけ Java のアプレットにならった構造やメソッド名に近づけた。つまり、先のエントリーAJAX で、動的にテーブルを作る方法（初級）では、感じをつかむために、ベタにテーブルを作成していたため、重複するロジック／コードが多かった。ここではそれをフレームワークっぽくした。こういう軽量なコードを理解した上で、ひな型として自分で持っておくと見通しがよくてよいと思う。 この JavaScript ではできるだけ Java のアプレットにならった構造やメソッド名に近づけた。つまり、

IPA（独立行政法人情報処理推進機構）の「安全なウェブサイトの作り方」というドキュメントは、なかなかまとまっていて、良い。すべてのウェブアプリ開発者は目を通しておくべきだ。ここではこのドキュメントから注意点をピックアップしてまとめてみた。

1. SQL インジェクション
2. OS コマンド・インジェクション
3. パス名パラメータの未チェック／ディレクトリ・トラバーサル
4. セッション・ハイジャック
5. クロスサイト・スクリプティング
6. クロスサイト・リクエスト・フォージェリ (CSRF)
7. HTTP ヘッダ・インジェクション
8. メールの第三者中継

IPA（独立行政法人情報処理推進機構）の「安全なウェブサイトの作り方」というドキュメントは、なかなかまとまっていて、良い。すべてのウェブアプリ開発者は目を通しておくべきだ。ここではこのドキュメントから注意点をピックアップしてまとめてみた。

1. SQL インジェクション
2. OS コマンド・インジェクション
3. パス名パラメータの未チェック／ディレクトリ・トラバーサル
4. セッション・ハイジャック
5. クロスサイト・スクリプティング
6. クロスサイト・リクエスト・フォージェリ (CSRF)
7. HTTP ヘッダ・インジェクション
8. メールの第三者中継

Perl で、スクリプトをデーモン化するのはそんなに難しくない。Proc::Daemon というモジュールを使えば簡単にできるのだが、それには小さなフレームワークに沿ってスクリプトを書かねばならない。次のサンプルに空のフレームワークを示したので、既存のスクリプトがある場合にはこれに沿って自分のスクリプトを少々改造すればよい。基本的には action サブルーチンにロジックを書けばいいようになっている。 使用するモジュール

use Proc::Daemon;

Perl で、スクリプトをデーモン化するのはそんなに難しくない。Proc::Daemon というモジュールを使えば簡単にできるのだが、それには小さなフレームワークに沿ってスクリプトを書かねばならない。次のサンプルに空のフレームワークを示したので、既存のスクリプトがある場合にはこれに沿って自分のスクリプトを少々改造すればよい。基本的には action サブルーチンにロジックを書けばいいようになっている。 使用するモジュール

use Proc::Daemon;

いわゆるログイン処理において、ユーザーがウェブページのフォームから入力してきたユーザー名とパスワードをデータベースに保存されているものと照合し、認証するという仕組みはメンバー制サイトにはもはや欠かせないものとなっている。ここで、ユーザー名とパスワードは SSL で暗号化された通信路（チャネル）を通じてサーバに送るのは当然として、データベースにユーザー名とパスワードを生のまま入れていた場合は、もしデータベースが何者かにハッキングされたらパスワードがそのまま漏洩してしまうことになる。パスワードというものはある個人であればどのサイトでも共通にしていることも多いのではないだろうか? あなたはまさにこのエントリを読んでいるくらいなのだからそんなことはないかも知れないが、一般ユーザーのセキュリティに対するリテラシーはどうだろう？そのようなことを前提にすると、仮に（あってはならないことだが）自サイトからパスワードが漏れた場合、そのパスワードを使って悪意のあるものが次々に他のサイトへの認証を試みるシナリオもあると思う。また、データベースがハッキングされないまでも、管理者がデータベースを覗けばユーザーが設定したパスワードを簡単に見ることができるシステムは、やはりセキュリティ上問題であろう。 このような事態を避けるためにも、セキュリティの基本ではあるが、データベース中のパスワードはハッシュ文字列で保存しておくべきである。たとえデータベースの管理者がデータベースに保存されているハッシュ値を覗けたとしても、そのハッシュ値からのパスワード自体の復元はほぼ不可能だからだ。このような仕組みにすると、ユーザーがパスワードを忘れた場合はパスワードで照合できなくなるので、再設定の仕組みが必要である。このポイントを頭に入れて注意深く世のサイトがどのように作られているか、普段からアンテナをはって参考にして欲しい。 この方法は特に Perl だけにできるということではなく、もちろん言語を問わず、ハッシュ関数が用意されている Java や PHP にも使える。 いわゆるログイン処理において、ユーザーがウェブページのフォームから入力してきたユーザー名とパスワードをデータベースに保存されているものと照合し、認証するという仕組みはメンバー制サイトにはもはや欠かせないものとなっている。ここで、ユーザー名とパスワードは SSL で暗号化された通信路（チャネル）を通じてサーバに送るのは当然として、データベースにユーザー名とパスワードを生のまま入れていた場合は、もしデータベースが何者かにハッキングされたらパスワードがそのまま漏洩してしまうことになる。パスワードというものはある個人であればどのサイトでも共通にしていることも多いのではないだろうか? あなたはまさにこのエントリを読んでいるくらいなのだからそんなことはないかも知れないが、一般ユーザーのセキュリティに対するリテラシーはどうだろう？そのようなことを前提にすると、仮に（あってはならないことだが）自サイトからパスワードが漏れた場合、そのパスワードを使って悪意のあるものが次々に他のサイトへの認証を試みるシナリオもあると思う。また、データベースがハッキングされないまでも、管理者がデータベースを覗けばユーザーが設定したパスワードを簡単に見ることができるシステムは、やはりセキュリティ上問題であろう。 このような事態を避けるためにも、セキュリティの基本ではあるが、データベース中のパスワードはハッシュ文字列で保存しておくべきである。たとえデータベースの管理者がデータベースに保存されているハッシュ値を覗けたとしても、そのハッシュ値からのパスワード自体の復元はほぼ不可能だからだ。このような仕組みにすると、ユーザーがパスワードを忘れた場合はパスワードで照合できなくなるので、再設定の仕組みが必要である。このポイントを頭に入れて注意深く世のサイトがどのように作られているか、普段からアンテナをはって参考にして欲しい。 この方法は特に Perl だけにできるということではなく、もちろん言語を問わず、ハッシュ関数が用意されている Java や PHP にも使える。