□技術メモ - セキュリティを考慮したプログラム ※管理人の個人的な技術メモです。このページはセキュリティ対策について 記載していますが、必ずしも正確であることを保証していません。 このページの内容の実行結果について、管理人はいかなる責任も負いかねますので ご自身の責任でご参照ください。 ----------------------------------------------------------- (2015/02/04記) ・このページはセキュリティを考慮したプログラムと、セキュリティ対策に 関することを記しています。 ○SQLインジェクション、クロスサイトスクリプティング(XSS) ・いずれもWebページの入力値を適切にエスケープしないまま展開することにより、 アプリケーションの本来の意図とは違う動作をさせるという手法。 SQL中に展開されるのがSQLインジェクション。入力中に存在するタグなどが HTML中に展開されるのがクロスサイトスクリプティング。 ※対策 ・エスケープする必要のある文字を文字参照に置き換える。 文字参照には文字番号で指定する方法(数値文字参照)と キーワードで指定する方法(文字実体参照)がある。以下は例。 = (なし) = 等号(文字実体参照が定義されていないものもある) < < < 小なり > > > 大なり ' ' ' アポストロフィー（シングルクォート） " " " ダブルクォート ・SQLのPrepare文とバインド機構を使用する。 本来これはSQLの内部コードへの変換回数を減らすことでサーバの負担を減らすことが目的であることに注意。 SQLを内部コードへ変換してからバインド変数を適用するならSQLインジェクションにも有効。 Prepare文を単なるテンプレートとしてSQLが完成してから内部コードを作成しているなら SQLインジェクション対策にはならないので注意。 ・タグの使用を認めている掲示板なども存在するが、その場合は使用許可するタグの ホワイトリストに存在しないタグの実行は認めないとする。 ・入力可能な桁数を適切に設定する。 ○第二攻撃（Second-order XSS） ・XSSを引き起こす入力がWebシステムに登録され、これを別の閲覧者が参照した場合も 上記と同様にタグが展開される。 ○バッファオーバーラン ・Cで開発されたシステムでは十分に長いバッファを設定してあることを理由に、文字長の判定をしていない システムも存在する。その場合、変数の格納領域以外のアドレスの値を書き換えることが可能であり、 任意のコードが書かれたアドレスからの処理に誘導する可能性が生じる。 ※対策 ・開発時の対策としては、データを書き込む際に領域を超えて書き込まないことを確認する必要がある。 ・プラットフォーム側でバッファオーバーフローの発生を抑制することも考えられる。 Solaris 2.6以降のSPARC版ではカーネルのオプションを変更することである程度抑制できるらしい。 libsafeやStackGuardなどのバッファオーバーラン対策のツールでは、オーバーフローを検知した際に プログラムを停止させることができる。しかしこれも一時しのぎの対策と考えるべき。 ・セキュリティホールが発見された場合は速やかにコードを修正して、メーカー等から提供されるパッチは 速やかに適用することが必要になる。 ○クロスサイトリクエストフォージョリ(CSRF, XSRF) ・クロスサイトからニセのリクエストを送信する。 ・2012年のパソコン遠隔操作事件で使われた手法の一つがCSRFと言われている。 ※対策 ・リクエストの遷移元を確認していないことが原因で発生するので、これを確認することが対策となる。 ・以下のようなCSRF以前の問題がある場合は対策が成り立たないので、ここではこれらが存在しないことを前提として考察する。 XSS脆弱性が存在する。 攻撃者がトラフィックを盗聴可能状態にある。 スパイウェアが存在する。 ・対策1:hiddenフィールドにワンタイムトークンを格納する方法 リクエストを受信したらサーバ側で乱数やハッシュ値などでワンタイムトークンを生成する。 これをセッションと組み合わせてサーバ側のセッションオブジェクトに保持する。 リクエストに対する応答を返す。その際、キャッシュが残らないようにヘッダを設定する。 次にクライアントはトークンを含んだ値をPOSTで送信する。 サーバ側はトークンとセッションが一致していたら正しいと判断して次へ進む。 ・対策2:CAPTCHA(画像認証) サーバ側で乱数を発生させ、これに該当する読みにくい数字や記号の画像を表示する。 これを読んだ正規ユーザが正しい値を返信してきたら次の処理へ進む。 ・対策3:パスワードを再入力する ユーザIDに対応するパスワードを入力する。この値が正しければ次の処理へ進む。 キャッシュが残らないように正しくヘッダを設定すること。 ・対策4:セッションIDやトークンなどの照会情報が他者に傍受されることを防ぐ必要がある。 したがって特にCSRF対策が必要なサイトではTLS(Transport Layer Security)による暗号化が必要になる。 注意： ・セッションIDのハッシュ値をトークンにする(つまりセッションIDから算出できる値になる)のは避けるべき。 推測困難な値が２つある方が望ましい。 ・HTTPリファラーにサイトの遷移情報が存在するのでこれを参照する方法もあるが、リファラーを出力しない ブラウザがある、リファラーが偽造される可能性がある、など推奨されないとする意見もある。 ○ソーシャル・エンジニアリング ・ファイアウォールやセキュリティの技術的な壁が高い場合、攻撃者はアナログな方法 (ごみ箱をあさる、フロアに侵入する、人をだます等)でこれを解決することがある。 これらの手法はソーシャル・エンジニアリングと呼ばれている。 ・人間系の脆弱性に対する攻撃なので「ヒューマン・ハッキング」「だましのテクニック」 等と呼ばれることもある。 ・一般的に攻撃者はシステムの脆弱性に対する攻撃で30分程度で侵入できなかった場合はこれを行うと言われている。 ・攻撃者がソーシャル・エンジニアリングを行う理由は「簡単だから」 ・攻撃者が攻撃対象企業の担当者とメールのやり取りをしながら、情報を流出させたくなる雰囲気を作ったり、 悪用する機能が埋め込まれたツールをインストールするように誘導する行為もソーシャル・エンジニアリングと言える。 ・サイバー攻撃対策は高度化しているが、最も困難とされるポイントが「人間」だと言われている。 ○リバース・エンジニアリング ・ソフトウェアを逆アセンブルなどして、仕様や技術情報を明らかにする技術。 ・非営利目的で逆アセンブルやリバース・エンジニアリングを行うことは セキュリティホールやバグの発見・原因究明につながるとされているが、 脆弱性が悪用される可能性やリスクも存在する。