ここではどのようにしてアクセスを制限するかについて述べます。（まだ書きかけ中です）

１．ページへのアクセス

２．権限種別

３．レコードへのアクセス

これは、アプリケーションサーバのセキュリティ設定で実現できます。ユーザのロールに応じて、アクセスできるページを規定します。また、ログインしていない場合にアクセスさせたくないページはすべて、WEB-INFの下に配置しておくのがいいです。

ユーザのロールに応じて、もしくは管理者の与えた権限に応じて、できることを変えます。権限には、参照・更新・追加・削除・一括削除・全削除・実行などがあります。権限がない場合は削除や更新のボタンを表示しないなどの対応をとります。

意外と盲点になりやすいのがこの部分です。パラメータにuserid=123などとついていると、その値を変えるだけで他のユーザのデータにアクセスできてしまう脆弱なアプリケーションもあります。

対応としては、パラメーターにはアクセス可能なキーを使わないことです。パラメーターは改ざん可能なので、そのようなキーはすべてセッションIDに紐付けたIDをサーバー側で持つようにします。例えば、各ユーザーは自分の所属するグループのデータは閲覧できる場合、グループIDをサーバー側で保持するようにします。そうすると自分の所属グループ以外は閲覧できないようにできます。

DBでは代理キーを使っているので当該テーブルのIDだけで検索できますが、検索時には必ずwhere句にグループIDを付加するようにします。そうすることによって、パラメータを改ざんして他グループのデータを参照することができなくなります。また操作の前に必ずユーザがその情報への参照や更新に権限があるかをチェックします。

ポイントはどのようにパラメータを改ざんしても他のデータへアクセスできないようにすることです。

あるいはパラメータを暗号化することです。キー値となるものには、すべてスクランブルをかけます。

パラメータを操作することで、自分の管轄のデータを不正に更新・削除できるが、これは防ぎようがありません。これは正規の使い方をしなかったユーザ側の責任ということになります。ユーザの操作ミスを極力防ぐことは必要ですが、ユーザが勝手なことをして自分のデータを壊したとしてもそれはユーザ側の責任です。ある程度のことはシステム側で誤動作を防止してあげる必要がありますが、それ以上は致し方ありません。守るべきは他のユーザのデータです。

・パラメータを表示させない

またパラメータがアドレスバーに表示されないようにするのもいい方法です。ログイン時に別の画面を開いて、バーを一切表示しないようにします。

また、GETの代わりにPOSTを使い、右クリックも禁止してソース表示をできないようにします。また、スニファーをされても内容を見れないように、httpsを使うのも手です。ただ所詮は程度問題に過ぎず、やろうと思えばいろいろ抜け道はあるでしょう。

なので、サーバ側でどんなパラメータが送られてきたとしても、データを破壊するようなことがないようにする、権限のないデータにはアクセスさせないようにすることが大切です。

セッションIDもCookieを調べれば盗むことができますが、そこまでは対応はできません。ただ、他人がソースを見たり、アドレスバーを見たりするぐらいはできるので対応します。またセッションタイムアウトは必ず入れるようにします。

様々なクラッキングがありますが、基本はサニタイジングをしっかり行なうことです。ユーザが入力した文字列に「<」「>」「&」がある場合、それらの文字をブラウザに再度表示する必要があるときは、きちんと「<」「>」「&」に変換しておくことです。

あと、SQLインジェクションに対しては、PreparedStatementを使うなどして、SQLを改ざんされないようにすることです。