WEBアプリケーションセキュリティー株式会社　ミュートネット

竹原　広佑

１９：００　〜　１９：１０　自社・自己紹介など １９：１０　〜　１９：５０　WEBセキュリティ １９：５０　〜　２０：００　休憩 ２０：００　〜　２０：３０　WEBセキュリティ ２０：３０　〜　２０：４０　まとめ ２０：４０　〜　後片付け（終了）

本日の予定

・対象　１．Webアプリケーションを作ったことがない。　２．セキュリティについて何も知らない。　３．セキュリティについての基本は幾つか知ってはいるが、　　　意識したことは無い。

・非対象　４．セキュリティの基礎についてしっかりと把握し、意識して　　　コードを書いている。　５．セキュリティについての最新動向もしっかりと学習し　　　開発に生かしている。

本日の勉強会内容の対象者目安

WEBセキュリティー１

『WEBアプリケーションの数が近年急増』

【背景】

様々なデバイスの普及（スマホ、タブレット等）

クラウド関連の成長

はじめに

Webアプリケーション数と脆弱性報告数

出典元　 IPA（ http://www.ipa.go.jp/security/vuln/report/vuln2012q3.html）

ソフトウェアに対してウェブサイトの脆弱性報告が非常に多い！

２００８年後期に急増（ titterなどのWEB関連のサービスが流行り始める）

グラフ（１）

グラフはユーザからの報告を受けた把握できている数

実際にはwebサイトの約４割が脆弱性を抱えている

グラフ（２）

出典元　 IT pro（ http://itpro.nikkeibp.co.jp/article/NEWS/20120705/407596/）

IPA調べでは２０１２年３ Q度の１営業日に対する報告数はなんと。。

グラフ（３）

３．９６　件 /日 !!

脆弱性とは

Cross Site Scripting（クロスサイトスクリプティング）Parameter Manipulation（パラメータ改ざん）Backdoor & Debug Options（バックドアとデバッグオプション）Forceful Browsing（強制的ブラウズ）Path Traversal（パスの乗り越え）SQL Injection（ SQLの挿入）OS Command Injection（OSコマンドの挿入）Client Side Comment（クライアント側コメント） etc

脆弱性の種類（１）

ここで脆弱性として代表的な物をご紹介！

第三者が通常のサイト利用者に対して自由にスクリプトを実行させる事ができる。

これにより、ユーザしか知り得ない情報（ IDやパスなど）を不正に取得することが可能となる。

Cross Site Scripting（クロスサイトスクリプティング）

上記の３つに共通な部分はURLの文字列変更による攻撃

例）http://○○○.com/○○○.php?userid=２１９http://○○○.com/phpmyadminhttp://○○○.com/(インデックスページの表示 )

上記の様なURLの場合、 useridの部分を２２０や２２１に変える事で別ユーザとしてアクセスできそう

Parameter Manipulation（パラメータ改ざん）Path Traversal/Directory Traversal（パスの乗り越え）

Forceful Browsing（強制的ブラウズ）

上記の２つは主に開発中に開発者のミスで生まれる脆弱性。

開発中に仕込んでいた、本来踏むべき手順を無視し、実行できるルートを削除し忘れていたため、本来ならば起こり得ない事象を生む。

HTMLコメントは、攻撃者の格好のヒントになってしまう恐れも。。。

Backdoor & Debug Options（バックドアとデバッグオプション）

Client Side Comment（クライアント側コメント）

SQLやOSコマンドを入力欄に入力し、本来であればエスケープすべき SQL文をしていないそれらの文字列がサーバによってコマンドとして実行されてしまう現象。

SQL Injection / Second Order Injection（ SQLの挿入）

OS Command Injection（ OSコマンドの挿入）

例）ログイン画面、パスワード入力欄などにSQLを書きサーバに送信

脆弱性の割合

(http://www.ipa.go.jp/security/vuln/report/vuln2012q3.html)出典元　 IPA

脆弱性の中で特に代表的なものそれが

クロスサイトスクリプティング（ XSS）と

SQLインジェクションです！

脆弱性まとめ

XSSと SQLインジェクション詳細

XSS（クロスサイトスクリプティング）詳細（１）

一般ユーザ偽の関連サイト　等（悪意のある第三者）

正規のWEBページ

ここでスクリプトを送り込む

余談クロスサイトリクエストフォージェリ

一般ユーザ予めサーバに送信される情報を作成

（悪意のある第三者）

正規のWEBページ

リダイレクト

対策としてしっかりとサニタイジング（無害化）

しよう！

XSS詳細（２）

Web サイトの入力フォームへの入力デ ー タ か ら 、 HTML タグ、 JavaScript、 SQL文などを検出し、それらを他の文字列に置き換えること。

※エスケープなど無害化行為の総称

サニタイズとは？

出力時、htmlspecialchars関数で簡単に出来ます！

PHPでの対策

XSS（クロスサイトスクリプティング）詳細（１）より

一般ユーザ偽の関連サイト　等（悪意のある第三者）

正規のWEBページ

ここでスクリプトを無害化できる

SQLインジェクション例）

SQLインジェクション詳細（１）

ID

ここの値を$SQL = “Select * from user where id = ‘”.$id. ”’”;

なんて形でやっていると・・・・

SQLインジェクション詳細（２）

SQLインジェクション例）A‘ or ‘A’ = ‘A’ID

と入力されると展開後の文字列は

Select * from user where id = ‘A’ or ‘A’ = ‘A’;

となり入力情報がなんであっても通ってしまう

前述のような形なら

まだ幾らかマシです！！

SQLインジェクション詳細（３）

SQLインジェクション詳細（４）

SQLは；（セミコロン）で区切ることが出来るので‘ ； delete from userID

と入力されると

後ろに続く delete文が実行されます！！こんな事されたらもう・・・・

対策として（；や‘は）

　エスケープすること！

特殊文字として認識させないように

文字列として内部で扱う

また、入力時の禁止文字列としての

対応も対策のひとつ！

SQLインジェクション（５）

エスケープ処理もきちんとしたし、これで一安心！！

SQLインジェクション（６）

ではないんです！

大層な名前ですがSQLインジェクションと本

質は同じです！

セカンドオーダインジェクション（１）

例として例えば以下の様な形でユーザ登録できる

webアプリがあったとします。

セカンドオーダインジェクション（２）

ID : admin’--pass : password

もし、このWEBアプリがパスを変更できるとしたら流れるクエリはこんな形

セカンドオーダインジェクション（３）

Update user set pass = ‘pass’ where id = ‘admin’—’;

SQLは -をコメントとしているので、上記のSQLでは adminのアカウントのパスワードが変更されてしまう。

外部入力時のみではなく読み出しの値に対しても

エスケープ処理を忘れずに！（全てのクエリに対してエスケープは必須で

す）

セカンドオーダインジェクション（４）

現在では、これらのサニタイジングを自動で（意識せず）やってくれるフレームワークが多数存在して

います。

しかし、それらのものにも脆弱性が存在しうるため、日々の最新アップデートは常に確認しておくべき！

現在では・・

XSSは HTML出力時、サニタイジングを！SQLインジェクションは、 SQL生成時全ての場合に

おいてエスケープ処理を！

昨今の開発ではフレームワークを使用している為、脆弱性を生むような自体は避けられてはいる。が、バージョンアップなどの動向については常に

チェックするよう心がける。

セキュリティーまとめ