「セキュア・プログラミング講座」にいってきた！

セキュア・プログラミング講座（Webアプリケーション編)ブートアップセミナー
（ＮＩＩで開催）にいってきた！
その内容をメモメモ

---

・ＩＰＡのセキュア公開資料
　　脆弱性を前倒しで論点を挙げている
　　やさしい論点が後になる

■導入：ＨＴＴＰプロトコル
・Ｗｅｂアプリケーション
　　まあ、せつめいしなくてもいい

・使われるプログラミング言語の例
　サーバー
　　ＲｏＲに刺激されＣａｋｅ，Ｄｊａｎｇｏ・・・
　クライアント
　　Ｄａｒｔ，ＴｙｐｅＳｃｒｉｐｔ
　　JQuery
　大きなことが抜けている

・攻撃は通信から入ってくる
　ＨＴＴＰプロトコル

・ＨＴＴＰの通信を観察する
　　ローカルプロキシ：リクエストの監視、改変
　　　ＤＷＡＳＰ・ＺＡＰ・Ｆｉｄｄｌｅｒなど

・ＨＴＴＰ通信の観察
　ＭＩＭＥメッセージの一種

・ＰＯＳＴメソッド

・舞台裏は単純なテキストのやり取り
　→いくらでも捏造、改変できる

---

■ＳＱＬインジェクション：シンプルな攻撃
・攻撃の流れ
　　入力パラメータにＳＱＬ文字列を使い、データを破壊する
・被害
　　ＤＢの中身を読み出される
　　定義も
　　ＲＤＢＳの種類、バージョンがわかる
　　情報の改ざん→データ破壊
　　サーバーのっとり

・やりかた
　　パスワードを' or 'a'='a とする

・悪さをする特殊企業
　　'
　　;
スペース　　ＳＱＬサーバー
-- コメント
\ 特殊記号：エスケープを乗り越える

・対策
　ＳＱＬ文の発行を半自動化してくれる道具を使う
　　　よい道具
　　　　　Ｏ／Ｒマッパ
　　　　　言語に統合されたクエリ（ＬＩＮＱ、ＰＬ／ＳＱＬ）
　　　　　プリペアド・ステートメント

　　　次善の策
　　　　　特殊記号をエスケープする

・Ｏ／Ｒマッパー
　　　ＲｏＲ　ＡｃｔｉｖｅＲｅｃｏｒｄ
　　　Ｇｒａｉｌｓ　ＧＯＲＭ
　　　Ｃａｋｅ　Ｍｏｄｅｌ
　　　Ｓｐｒｉｎｇ　Ｓ２ＪＤＢＣ，Ｈｉｂｅｒｎｅｔａ
　
・ＳＱＬ注入のポイント
　　ＳＱＬ文を発行してデータベースへアクセス
　　ＳＱＬの構文を攻撃者にいじられない

---

■スクリプト注入
　ブラウザ側を攻撃
・典型的にはＸＳＳ
　　ＨＴＭＬの文字列を貼り付けられると、
・偽ページ：
　セッションのっとり

・攻撃方法

・攻撃パターン
　　スタイルタグなどもあぶない：いろいろな手口

・対策１：scriptタグを抑止
　対策２：ＵＲＬ属性の無害化

・バリエーション
　　蓄積されたデータ内
　　ＤＯＭ型（ＡＪＡＸ）

---

■セッションメカニズムとユーザー認証について
・ＨＴＴＰはステートレス
　セッションで
　セッションＩＤ運び方３種類
　　　ＵＲＬリライティング
　　　ＰＯＳＴデータ
　　　クッキー

---

■セッションハイジャック
・ＳＳＬで暗号化していても、セッションハイジャックは
　起こる可能性はある
　　→証明書を使わない限り、なりすましはできる

・被害
　　なんでもできる
　　　金銭被害
　　　情報漏えい
　　　業務妨害

・悪い例
　　ある種のフレームワーク
　　　ログイン前とログイン後で同じセッションＩＤを使っている場合
　　「推測」への対応
　　　　→処理系が作ってくれるので、それを使う
　　　　　ログイン、ユーザー認証成功のたびに異なる値を使う
　　「奪取」の対応
　　　　ＳＳＬなどを使う
　　　　Ｃｏｏｋｉｅにセキュア属性
　　　　Ｃｏｏｋｉｅの寿命を短くする
　　　　ログイン成功時のＣｏｏｋｉｅを発行しなおす

・セッションハイジャックのポイント
　　発行と運用にかかわる
　　他人が入ってくる
　　対策：「推測」されない「奪取」されない

■セッションフィクセーション
（セッションＩＤのお膳立て）

・攻撃の流れ
　攻撃者はＣｏｏｋｉｅを取得し、
　ユーザーにそのＣｏｏｋｉｅを送りつけると
　攻撃者が知っているＣｏｏｋｉｅでログインすることになる
　　　→付け替えないから

　あとは、セッションハイジャックと同じ

・対策
　ログインしたとき、新しいセッションＩＤにする

---

■アクセス認可の実装
・失敗パターン
　メニューにないページにアクセスできる
　　　ＵＲＬをたたくと画面が出てくる
　他者の所有データにアクセスできる
　　　ＩＤに連番のキーの場合
・対策
　　ページごとに、保護するロジック
　　オブジェクトのオーナーを確かめる

・より一般的：ＰＥＰ
　保護すべきもの：Ｗｅｂページ
　問い：今ログインしているユーザーは
　　　　その対象へアクセスする権限をもつか

---

■ほかの論点
・セキュア・プログラミング講座
　Ｗｅｂアプリケーション編
　に書いてある

　　要件定義で考えないといけないもの
　　設計でもいいもの
　　実装でも間に合うもの


クロスサイト　リクエスト　フォージェリー
正常
　サーバーが送りだす→ブラウザが操作→サーバ書き込み

問題
　悪さサイトが送り出す→ブラウザが操作（しなくてもいい）→サーバーＸ

ＸＳＳとの違い
　クロスサイト　リクエスト　フォージェリーはサーバーに入ったところで悪さ
　ＸＳＳは、サーバーに入った後、ブラウザで悪さする
　
Ｃｏｏｋｉｅを他者がみる
document.cookie
ここに代入されてしまうと、Cookieを入れられてしまう。
　ところが、HTTPレスポンスにsecureをつけると、だいにゅうできない。

ところがＰＨＰは(WebSphereも)、
ブラウザからセッションＩＤを使えた（セッションあだぷしょん）。
→悪いヒトが、セッションＩＤを送りつけると・・・

ユーザーストーリーと知識地図とUML

アジャイルで要求を抽出する場合を考える。
この場合、ユーザーストーリーなどが使われることが考えられる。
しかし、すべてのユーザー（ステークホルダー）のシナリオが挙げられているか、
また、そのシナリオ間の関係(順序や並行作業など）が、正しく考慮されているか
という点は、ユーザーストーリーだけをみていてはわからない。

インセプションデッキの中で、ステークホルダーは分析される。
そこで、それらの人々、それぞれのユーザーストーリーを作ることになる。

---

このステークホルダーの広がりを書いたものがマップであり、
各ステークホルダーのユーザーストーリーを書いたものがシナリオとすると、
これは、まさに、知識地図となる。

---

　そして、UMLの枠組みで考えると、
インセプションデッキでステークホルダーを出すところは、
ユースケース図に相当する
（ステークホルダー→アクター）

そして、ユーザーストーリーをシナリオとして書くには、
アクティビティ図を使うことになる。
ステークホルダー（アクター）ごとにスイムレーンをわけ、
それぞれのユーザーストーリーを書いていくことになる。

グーグル、アンドロイド搭載ゲーム機を開発―今秋発売か

グーグルは、ハードメーカーになろうとしているのか？


グーグル、アンドロイド搭載ゲーム機を開発―今秋発売か
http://headlines.yahoo.co.jp/hl?a=20130628-00000389-wsj-bus_all

6月27日(木)のつぶやき

　ウィリアムのいたずら　@xmldtp　13:42

「PMがうさみみ付けて円陣組む？－アジャイルの方法論のまぜまぜの仕方」 goo.gl/SXCC1

from gooBlog production

返信 リツイート お気に入り

---

　ウィリアムのいたずら　@xmldtp　16:33

税抜き合計に５％を掛けて消費税とし、それらを足して合計金額としたプログラムは、税率変更だけでは済まなくって、大幅修正が必要かも！ goo.gl/0Z99E

1 件 リツイートされました

from gooBlog production

返信 リツイート お気に入り

---

　ウィリアムのいたずら　@xmldtp　17:00

１番仲の良いランキング
1位@dagjmpd
2位@_mason_x
3位@dentomo

→　goo.gl/uakWi
あなたのランキングもチェック? pic.twitter.com/B2yXLAUr2E

from Friend Ranking

返信 リツイート お気に入り

---

Follow @xmldtp