利用者と本システム間におけるWebアプリケーション通信の暗号化 - ログイン状態にある利用者の意図に反した機能実行の防止機能

別紙 1. 脆弱性リストの脆弱性

4.4. ログイン状態にある利用者の意図に反した機能実行の防止機能

4.6.1. 利用者と本システム間におけるWebアプリケーション通信の暗号化

4.6.2. 内部の通信に関する補足 4.6.3. データベースの暗号化 4.6.4. ファイルの暗号化

https://www.j-lis.go.jp/lasdec-archive/cms/12,28369,84.htmlより引用 43

プロジェクトの開発標準を策定

44 3 分で分かるセキュアプログラミング

認証方法などのセキュリティ要件はユーザーと相談して定義し，そのあとに粛々と実装する SQLインジェクションなどのセキュリティ・バグへの

対処法を明確にする

方式設計において，開発標準やテスト方式を整備して

おく

コーディング規約をメンバーに学習

してもらう。

規約を破ると本当に危険だと認識

してもらう

コード・レビューの方針を決める。内部レビューを基本とし，誰がどの範囲（抜き取り検査など）をチェックするのかを明確にする。レビューできる担

当者のリソースを確保する

脆弱性テストの方針を決める。内部テストを基本にし，必要に応じて外部の専門ベンダーに依頼する。テストできる担当者の

リソースを確保する

ポイント① ポイント② セキュリティ・バグの撲滅

ポイント③

セキュリティ・バグの撲滅セキュリティ機能（要件）と

セキュリティ・バグは分けて考える開発標準の整備とメンバーの教育でチーム力をアップ

コスト要因となるレビューとテストを計画的に

要件定義基本設計詳細設計開発テスト運用

日経SYSTEMS2009年8月号「プロマネの技で守るWebセキュリティ」図1を改変

45

脆弱性診断とは

46 脆弱性診断の種類

• Web アプリケーション脆弱性診断

– Web

アプリケーションの脆弱性の有無を確認する

– Web

アプリケーションのセキュリティ機能の正当性を確認する

– Web

アプリケーションのテストの一環として実施する

• ネットワーク脆弱性診断 ^*1

–

プラットフォームに既知の脆弱性がないかを確認する

–

プラットフォームの設定のミスを確認する

•

オープンリレーメールなど

–

ポートの開き状況等を確認する（ポートスキャン）

• ペネトレーションテスト

–

侵入可能性の実証まで行う

*1

プラットフォーム脆弱性診断と呼んだ方が良いが、ここでは慣習に従う

47 Web アプリケーション脆弱性診断の方法

•

リモート（ブラックボックス）診断

–

攻撃者の立場でインターネット越しに擬似攻撃を行う

–

ツール診断と手動診断

–

ツール診断は、手動の

30%

程度しか見つからないという声も

… –

大規模なサイトではツールによる網羅性確保をする場合が多い

•

ソースコード（ホワイトボックス）診断

–

ソースコードを読むことで診断する

–

専用ツール（

Fortify

等）を用いる場合が多い

–

人手による目視診断もあるが、網羅性確保は難しい

•

グレーボックス診断

–

リモート診断とソースコード診断の合わせ技

–

最近注目されているが、実施例は少ないと予想

48 ブラックボックス検査の特徴

• ブラックボックス検査は、プログラムを動かしつつ、ソースコードは見ない（ブラックボックス）で検査する

• 概念的には通常のテストと同じ方法

• 脆弱性はバグの一種と捉えると、バグはつまるところ動かしてみないとわからない … 脆弱性も似た傾向あり

• クロスサイトスクリプティング (XSS) など、表示系の脆弱性はとくに有効

• SQL インジェクション、 OS コマンドインジェクション等、

サーバー内部で起こる脆弱性の発見は難易度が高い

• 攻撃者と同じことをするので、ハッカー的スキルが要求される

49 ホワイトボックス検査の特徴

• ソースコードから脆弱性を調べる。原則としてプログラムは動かさない

–

ブラックボックスと併用することを最近はグレーボックスと呼ぶ

• ソースコードが読め、脆弱性の知識があれば、検査は可能

–

攻撃者としてのスキルはあまり要らない

• 手動検査とツール検査がある

–

手動検査は網羅性に課題があるが、難しい脆弱性が見つけられる（検査者の力量次第）

–

ツール検査は網羅性は得やすいが、複雑な脆弱性に課題

• サーバー内部の脆弱性は相対的に得意

• XSS 等は動かしたほうが早い … 場合もある

50 ブラックボックス vs ホワイトボックス

51

カテゴリ診断項目ウェブ健康診断ソースコード解析

クロスサイト・スクリプティング ○ ○

Ajax/JSONの脆弱性 - ○

SQLインジェクション ○ ○

HTTPヘッダ・インジェクション ○ ○

メールヘッダ・インジェクション ○ ?

OSコマンド・インジェクション ○ ○

ディレクトリ・トラバーサル ○ ○

オープンリダイレクタ ○ ○

リファラからの情報漏洩 ○ ?

コンテンツディレクトリ・リスティング ○

-クロスサイト・リクエスト・フォージェリー ○ おそらく☓

クリックジャッキング ○ おそらく☓

SSL使用状況クッキーのセキュア属性不備 ○ ?

セッションID使用状況 ○ ?

Cookie使用状況 ○ ?

ログアウト機能 ○ ?

セッションIDの固定化 ○ △

アクセス制御不備 ○ ?

認可不備 ○ ?

アクセス制御・認可

パラメータ操作

ユーザの意思の反した機能実行

セッション管理

ブラックボックス検査では発見が難しい脆弱性の例

52 <?php

$name = $_POST['name'];

$mail = $_POST['mail'];

$address = $_POST['address'];

try {

$con = new

PDO("mysql:host=localhost;dbname=db;charset=utf8", …);

$con->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$sql = "INSERT INTO entries VALUES('$name', '$mail', '$address')";

$result = $con->exec($sql);

} catch (PDOException $e) { // do nothing

}

?><p>

登録しました

</p>

•

キャンペーン応募のように、登録後のデータを利用者は参照できない

•

「登録しました」以外の表示が一切ない

•

エラー処理をしていないので、エラー内容、エラーか否かすらわからない

時間差を用いた診断の例（ブラックボックス）

53 INSERT INTO entries VALUES('$name', '$mail', '$address')

•

まったく画面表示がなくても、副問い合わせ

(SELECT sleep(5))

により、

5

秒遅延するか否かで診断は可能

•

診断者の技量により、診断の可否が左右される

•

診断の副作用により、データが破壊される危険性（結構よく聞く）

•

本番環境では更新系画面の

SQL

インジェクション診断をしない場合もある

',(SELECT sleep(5)),null) #

INSERT INTO entries VALUES(' ',(SELECT sleep(5)),null) # ', '', '')

出来上がりのSQL文

条件付き sleep により情報を取り出す

54 INSERT INTO entries VALUES('$name', '$mail', '$address')

• mini_bbs.members

テーブルの

email

列、第

1

行

1

文字目が

‘a’

の場合のみ

5

秒待つ

SQL

文

•

これを繰り返すことにより、

DB

内のすべての情報が漏洩する

',(select if(substr((select email from mini_bbs.members limit 0,1),1,1) =

'a',sleep(5),0)),null)#

INSERT INTO entries VALUES('',(select if(substr((select email from mini_bbs.members limit 0,1),1,1) = 'a',sleep(5),0)),

null)#', '', '')

出来上がりの

SQL

文

ソースコード診断なら検出は容易

55

•

ソースコード診断ツールならデータフローから脆弱性の検出が可能

•

画面表示の有無に関係なく診断可能

当該箇所のレポート

56 Web アプリケーション脆弱性診断の流れ

• 診断前準備

–

診断環境準備

–

診断用アカウントの準備

• アプリケーション仕様把握

• 画面構成の把握

• 診断箇所の決定（全画面・全項目の場合は省略）

• 画面一覧表の作成

• 診断作業

• 報告書作成

• 報告会

• 診断後の後始末

57 Web アプリケーション検査の課題

•

費用が高額である

–

検査に専門性を要すること、検査箇所や項目が多岐にわたることから、通常数百万円、場合によっては数千万円の費用が掛かる

–

ツールによる診断でコストを抑える場合が多いが、ツール診断には品質上の課題がある

•

安全性に対する課題

–

サイトに疑似攻撃をかけることからデータベース破壊などの危険性

–

稼働中サイトに対する安全な検査手法の要請

•

品質に関する課題

–

検査仕様のスタンダードがない

–

検査項目の規定

–

検査の深さに対する規定

–

抜き取り検査とする場合の抜き取り方法

→

ベンダーの手抜きやスキル不足による品質低下のリスク

58 診断の基準とは ?

•

なにを以て「正」とするか

?

–

脆弱性は、「ないこと」が正

–

セキュリティ機能は「機能自体があり正しく機能すること」が正

•

脆弱性が「ないこと」をどうやって検証するか

?

–

どの脆弱性を検査するか

? SQL

インジェクション、

XSS

、

CSRF…

–

どこまで調べたら、「ない」と言えるか

?

•

つまるところ、「色々やってみる」しかない

•

セキュリティ機能が「正しく機能」するとは

?

–

仕様や設計書が提示されることは、ほとんどない

–

アプリケーションの仕様を実物から把握して、「常識的に」診断員が判断している

–

おおまかなところは、診断会社毎に基準がある

…

はず

59 「ウェブ健康診断」の紹介

診断方式：遠隔地からインターネット経由による手動若しくは自動診断ツールを利用診断実施数：約３００団体

診断対象：地方公共団体が保有若しくは利用している、現在インターネットで稼動中の

Web

サーバ１サイト分（1 ドメインネーム）

https://www.j-lis.go.jp/lasdec-archive/cms/12,1284.html より引用

60

61 ウェブ健康診断仕様 (1)



12

項目の診断項目により危険度の高い脆弱性項目を網羅している

 実被害に至る可能性の高いものに限定

 「安全なウェブサイトの作りかた改定第

3

版」で解説されている

9

種類の脆弱性を包含

 診断仕様、判定基準、抜き取り基準が明確に定義・公開されている

 公開された無償ツールのみで診断できる

 本番稼働サイトの診断を前提とした安全性の高い診断仕様である

 当初、

LASDEC

により策定、現在は

IPA

に管理を移管された

https://www.j-lis.go.jp/lasdec-archive/cms/12,1284.html より引用

ドキュメント内 kccs (ページ 43-74)

利用者と本システム間におけるWebアプリ ケーション通信の暗号化

別紙 1. 脆弱性リストの脆弱性

4.4. ログイン状態にある利用者の意図に反した機 能実行の防止機能

4.6.1. 利用者と本システム間におけるWebアプリ ケーション通信の暗号化

4.6.2. 内部の通信に関する補足 4.6.3. データベースの暗号化 4.6.4. ファイルの暗号化

https://www.j-lis.go.jp/lasdec-archive/cms/12,28369,84.htmlより引用 43

プロジェクトの開発標準を策定

44

3 分で分かるセキュアプログラミング

45

脆弱性診断とは

46

脆弱性診断の種類

• Web アプリケーション脆弱性診断

– Web

– Web

– Web

• ネットワーク脆弱性診断 *1

–

–

•

–

• ペネトレーションテスト

–

*1

47

Web アプリケーション脆弱性診断の方法

•

–

–

–

30%

… –

•

–

–

Fortify

–

•

–

–

48

ブラックボックス検査の特徴

• ブラックボックス検査は、プログラムを動かしつつ、ソー スコードは見ない（ブラックボックス）で検査する

• 概念的には通常のテストと同じ方法

• 脆弱性はバグの一種と捉えると、バグはつまるところ動 かしてみないとわからない … 脆弱性も似た傾向あり

• クロスサイトスクリプティング (XSS) など、表示系の脆弱 性はとくに有効

• SQL インジェクション、 OS コマンドインジェクション等、

サーバー内部で起こる脆弱性の発見は難易度が高い

• 攻撃者と同じことをするので、ハッカー的スキルが要求 される

49

ホワイトボックス検査の特徴

• ソースコードから脆弱性を調べる。原則としてプログラ ムは動かさない

–

• ソースコードが読め、脆弱性の知識があれば、検査は 可能

–

• 手動検査とツール検査がある

–

–

• サーバー内部の脆弱性は相対的に得意

• XSS 等は動かしたほうが早い … 場合もある

50

ブラックボックス vs ホワイトボックス

51

ブラックボックス検査では発見が難しい脆弱性の例

52

<?php

$name = $_POST['name'];

$mail = $_POST['mail'];

$address = $_POST['address'];

try {

$con = new

PDO("mysql:host=localhost;dbname=db;charset=utf8", …);

$con->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$sql = "INSERT INTO entries VALUES('$name', '$mail', '$address')";

$result = $con->exec($sql);

} catch (PDOException $e) { // do nothing

}

?><p>

</p>

利用者と本システム間におけるWebアプリケーション通信の暗号化

4.4. ログイン状態にある利用者の意図に反した機能実行の防止機能

4.6.1. 利用者と本システム間におけるWebアプリケーション通信の暗号化

• ネットワーク脆弱性診断 ^*1

• ブラックボックス検査は、プログラムを動かしつつ、ソースコードは見ない（ブラックボックス）で検査する

• 脆弱性はバグの一種と捉えると、バグはつまるところ動かしてみないとわからない … 脆弱性も似た傾向あり

• クロスサイトスクリプティング (XSS) など、表示系の脆弱性はとくに有効

• 攻撃者と同じことをするので、ハッカー的スキルが要求される

• ソースコードから脆弱性を調べる。原則としてプログラムは動かさない

• ソースコードが読め、脆弱性の知識があれば、検査は可能