HASIGOLOG
Webアプリのセキュリティ 〜サイバー空間で生きるために〜
こんにちは!
インターンの大坪です。
今回はWebアプリケーションのセキュリティについて学んだ事を書いてみます。
なぜセキュリティ?
まず、何故セキュリティについて考える必要があるのか挙げてみました!
学生視点
・楽しい
→サイバー空間で戦える!SECCONを始めとするハッカー大会を始め、セキュリティをテーマとしたイベントが沢山!
・就職に有利である
→セキュリティ人材は不足している!
企業視点
・経済的損失
→利用者が受ける金銭的損失の補償、Webサイト停止による信用失墜などが考えられる。
・法的に対策を行う義務
→個人情報を5000件以上保持している業者はセキュリティ対策を要求されている。
これは…勉強するしかない!
そこで、今回はインジェクション系の脆弱性というものを中心に勉強したことをまとめていきます。
インジェクション系の脆弱性には
・XSS(クロスサイトスクリプティング)
・SQLインジェクション
・OSコマンドインジェクション
・メールヘッダインジェクション
などがあります。まずはイメージを掴むためにSQLインジェクションを例に取って考えてみます。
以下の様なSQL構文があります。
Webアプリケーションに脆弱性があり「$id」へ次のような文字列が与えられました。
すると、データを流し込んだあとのSQL文は以下のようになります。
セミコロン「;」によりSELECT文が終了させられてDELETE FROMというSQL文が追加されてしまいました。
これをSQLインジェクションと呼ぶそうです。
SQLはもちろん、HTML、HTTPなどWebアプリケーションの多くは決められた文法により構成され、その中に命令や、演算子、データなどが混在した構造のテキストで表されてます。
多くの場合、データは引用符(例:ダブルクォート「”」)や記号文字(例:カンマ「,」、改行)で区切ることで識別しますので、実装に問題があると、上記SQLインジェクション攻撃の例のように問題がおきてしまいます。
そしてこの原理による脆弱性を、「インジェクション系脆弱性」と呼ぶそうです。
「インジェクション系脆弱性」のそれぞれの概要と対策方法をざっくり挙げてみます。
1) SQL インジェクション
概要:
データベースの不正利用をまねく可能性がある。
対策:
・Webアプリに渡されるパラメータにSQL文を直接指定しない。
・SQL文の組み立てを文字列連結により行う場合はエスケープ処理などを正しく行い、SQL文のリテラルを正しく構成する必要がある。
・SQL文の組み立てはプレースホルダ(実際の内容を後から挿入するために、とりあえず仮に確保した場所)で実装する。
2)XSS(Cross Site Scripting)
概要:
利用者のブラウザ上で不正なスクリプトが実行されてしまう可能性がある。
具体例と対策:
・セッションIDをURLパラメータに格納しない。
・HTTPS通信で利用するCookieにはsecure属性を加える。
・ログイン後に、新しいセッションIDを発行するようにする。
・ログイン成功時に秘密情報を作成してCookieにセットし、この秘密情報とCookieの値が一致することを全てのページで確認する。
3) OS コマンド・インジェクション
概要:
悪意あるリクエストにより、ウェブサーバ上で意図しないOSコマンドが実行させられ、重要情報が盗まれたり、攻撃の踏み台に悪用される可能性がある。
対策:
・シェルを起動できる言語機能の利用を避ける。
例えば、perlのopen関数など、OSコマンドを実行できる言語機能(関数)を使用しないようにする。
・シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。
4)メールヘッダ・インジェクション
概要:
管理者が設定した本来固定のメールアドレスではない宛先にメールが送信され、迷惑メールの送信に悪用される可能性がある。
対策:
・HTML(hiddenパラメータ等)で宛先を指定しない。
・メールヘッダを固定値にして、外部からの入力は全てメール本文に出力する。
・メールヘッダを固定値にできない場合、ウェブアプリの実行環境や言語に用意されているメール送信用APIを使用する。
5)ディレクトリ・トラバーサル
概要:
公開を想定していないファイルを参照されてしまう可能性がある。
対策:
・外部からパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
・ファイルを開く際は、固定ディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。
インジェクション系脆弱性ではありませんが次のような手法もあります。
6)CSRF(Cross Site Request Forgeries)
概要:
ログイン後の利用者が予期しない処理を実行させられてしまう可能性がある。
対策:
・処理を実行するページをPOSTメソッドでアクセスするようにし、その「hidden」パラメータに秘密情報を挿入するようにする。実行ページではその値が正しい場合のみ処理を実行する。
・処理を実行する直前のページで再度パスワードの入力を求める。
・Refere(リンク元のページ)が正しいリンク元かを確認し、正しい場合のみ処理を実行する。
今回勉強したことをきっかけとしてセキュリティマスターへの道を進みたいと思います!最後までありがとうございました。
参考:
お問合せはCONTACTよりお寄せください
RECRUIT
採用情報
私たちと一緒に
働いてみませんか?
CONTACT
お問い合わせ
ご相談など
お気軽にご連絡ください