あしのあしあと

2017-10-01

2017 OWASP World Tour Tokyo

| 22:31 |  2017 OWASP World Tour Tokyo - あしのあしあと を含むブックマーク

久しぶりの Web。周回遅れになっているので、情報収集のために参加した。思っていたのとは、ちょっと違った*1が、参加してよかった。充実した 1 日になった。

後日、参照できるよう、最低限のメモを残しておく。


Opening "OWASP Project Overview for Developers"

紹介していただいたプロジェクトは、いずれも FLAGSHIP であったが、ほとんどが知らないプロジェクトだった。

https://speakerdeck.com/owaspjapan/owt2017jp-owasp-project-overview-for-developers


Training 1 "OWASP TOP 10 を用いた脆弱性対応"

恥ずかしいことに、「Proactive Controls」すら知らなかった。話の流れからして、「TOP 10」とのマッピングは、誰もやっていなかったのだろう。

印象に残ったのは、「ソースコード静的解析では、アクセス制御、認可制御など、機能仕様に関係する脆弱性は検出できない」旨。これは、以前から言われていることであるし、静的解析ツールの原理を考えても、できなさそうだ。だが、今回は説得力があった。資料 35 ページ目の右下にしれっと書かれているのだが、静的解析ツールが「コベリティ」だったからだ(最近では、オージス総研さんのソリューションにも加わっている)。一流の開発者であっても、似たような悩みをかかえているのかも。

https://speakerdeck.com/owaspjapan/owt2017jp-owasp-top10


Training 2 "最小権限の具体的な実現方法"

「具体的な実現方法」についてのプレゼンを初めて聞いた。「最小権限は、セキュリティの原理原則である」という一方で、「最小権限の設計や実装は、業務要件次第」と言って、具体的なやり方を一切語らない。そんなコンサルタントなら、自分にだってできる。このセッションは、そこを一歩踏み出し、「Web アプリケーションにおける最小権限の設計のガイドライン」となっている。

前のセッションでも話があったように、権限設計や、アクセス制御の問題は、業務要件次第であるため、コレといった決定的な解決策を提示しにくい。

悪いことに、アクセス制御の設計を、画面中心で行っている案件は少なくないだろう。それは、画面設計書(あるいは、UI 部分のみを実装したモック)が、プロダクトオーナーとの最良のコミュニケーションツールだからではないか(特に、業務要件を整理するときは、確かに便利)。最も頻繁に更新され、最も信頼できるドキュメントなどになるため、どうしても画面が中心になってしまうのではないかと。こういう人たちに、「ローカルプロキシ」を使ってもらいたい。一発で目が覚めるから。

セッションでも、画面はただの UI で、リスクアセスメントと同様、情報やデータを起点に設計してほしい旨が述べられていた。その通りだと思う。

こんな状態で、ペネトレーションテストを実施すると、やはり、アクセス制御の問題が挙がってくるようだ。一般には、危険度が高いと評価されるため、脆弱なアプリケーションだとお墨付きをいただける。これは恥ずかしい。

残念ながら、アクセス制御の問題は、後付けが困難である。全ての処理をインターセプトし、権限表に従って、権限の有無をチェックするようにしなければならないからだ。そんな仕組みが全くないところに?

となると、プログラム中にハードコーディングする対策がとられたりして、収拾がつかなくなる。

こうであっても、「たまたま権限設計がシンプルだった」という奇跡に救われることもある。そうすると、同じ設計の仕方を横展開されてしまうのではないかと、夜も眠れなくなる。ウソ。ぐっすり。

と、いくらでも書けてしまうので、そろそろやめよう。

正直、自分の中では、インジェクション系は、どうでもいい。はっきり言って、インジェクション系の脆弱性は、作り込みにくい。SQLi とか、見たことない。たとえあったとしても、比較的簡単につぶせる(対、アクセス制御)。

https://speakerdeck.com/owaspjapan/owt2017jp-least-privilege


Training 3 "開発者・運用担当者に向けた、OWASP ZAP を用いた脆弱性診断手法"

開発者、受け入れ担当者、運用担当者などに向けた発表というところが、本当に素晴らしいと思う。何年も、モノをつくっている人たちにアプローチする姿勢には、頭が下がる。

自分も、開発をしている人に(保守・運用の要員までは考えていなかった)、どんな形でもよいから、広く 「ローカルプロキシ」 を使ってもらおうとしている。なぜか。HTTP のリクエストは、「いつでも何でも送れる」 ということをわかってほしいから。好きなタイミングで送信できるし、好きな内容で送信できるということを、体で理解してほしいから。そうなれば、変な設計しないでしょ。上記の最小権限とかアクセス制御とか、まじめに考えるでしょ。こと設計においては、ガイドや規約が、なかなか役に立たない。体に叩き込むのが早そうでしょ。

で、ローカルプロキシは、シンプルなツールだし、うったえる内容も 「いつでも何でも」 だけだし。簡単に浸透していくと思っていた。のだが、これが意外に進まない。

ローカルプロキシを、本当に使ってほしい人、例えば、設計のレビューする人だったり、テストの計画を作る人だったりするのだが、こういうエライ人たちは、構築した Web アプリケーションを実際に動かすことが、ほとんどなかったりする。なぜか。自分の経験的には、そういうエライ人は、だいたいまわっていない。てんてこ舞いしている。調整。

ドキュメント作っても、読んでもらえない。トレーニング立ち上げても、受講してもらえない。完全に、読みが甘かった。

もちろん、色々なチャネルでアプローチをしていて、一部の若手には、使ってもらい出している。草の根的な活動も大事だと思っているので、これはこれで続けていこうと思う。

とはいっても、やはり、前述した人たちにアプローチするのが手っ取り早いし、そうできないのがもどかしい。もう少し、頭を使いマス。

で、OWASP ZAP の話。OWASP ZAP のスキャナも、ゴリゴリ開発している人に使ってもらいたい。ということで、組織内に展開するために、OWASP ZAP を色々動かしていたときのこと。あるプラグインAlpha)を追加したら、ウイルス対策ソフトが吠えた。これが、変な跳ね方をして、しばらく、おとなしくすることになってしまった。これも、完全に想定外。

改めて、何年も、モノをつくっている人たちにアプローチする姿勢には、頭が下がる。

https://speakerdeck.com/owaspjapan/owt2017jp-owaspzap


Training 4 "OWASP BWA を用いた学生および職員向けトレーニング"

自分も、組織内で、Web アプリケーションセキュリティに関するトレーニングを立ち上げ、実施している。立ち上がったのは、10 年くらい前だが。

そういえば、トレーニングを立ち上げた話って、初めて聞いた。確かに、民間の人では、語りにくい。

他の仕事をかかえていて、2 週間程度で演習を作り上げたという話があったが、えっと、5 時間/日 × 14 日 = 70 時間。うん。とうていムリ。

自分の場合、企画した当初は、定時後にしか作業できなかったし、やられサイトも自作したということもあったが、たった 2 日間のコンテンツをつくるのに、半年近くかかった。満足いくクォリティになったが、やりすぎなのかもしれない。

XSS を 「分解して」 教えるところは、「なるほど」 と思った。自分のアプローチとは違ったが、前提知識を小出しにして積み上げていくという点は、一致していた。確かに、トレーニングを作成すると、こういうノウハウは蓄積する。ここらあたりの話は、心の中で、ウンウンと頷きながら聞いていた。

最後に、職員向けに、1.5 時間/週 でゆっくりやったという話だったが、コンテンツをどうやって分割したのか、受講者が前回の学習内容を覚えているものなのか、あたりも知りたかった。

https://speakerdeck.com/owaspjapan/owt2017jp-owasp-bwa


"開発プロジェクトの現状を把握する OWASP SAMM の活用"

TODO: 後で書く → 2017/10/10 ようやく書いた。途中までだが。

最後にキタ。

悲しいかな、「OWASP SAMM」を知らなかった。そんな自分には、最も有益な情報となった。

セッションの前半では、OWASP SAMM の骨子を、丁寧に解説いただいた。4 つのビジネス機能、ビジネス機能ごとに 3 つのセキュリティ対策、初めて聞く整理に驚いた。と同時に、コレは使えると思った(たとえ、教科書通りに使えないとしても)。また、各対策で活用できる OWASP の成果物が取り上げられていた。ほとんど知らない成果物であったため、たくさんの情報がいただけた。

セッションの後半では、具体的な活用事例が語られた。さすがに時間が短く(+ 大部分が社外秘の情報だろうから)、あまり細かいことはわからなかった。しかし、「アドバイス集の作成」や「タイムリーな情報提供」からスモールスタートするとよいなど、ノウハウも語られた。

すごく感じたのは、自分が所属している組織と比べて、「現場との連携が強い」ということ。一定のガバナンスが機能しているということ。

プロジェクトの開始から終了まで、一定の粒度で状況を把握することは、簡単にできることではない。プロジェクトの開始を確実にフックすることも大変だし、プロジェクトの途中経過を適宜知ることも、また大変*2

もとい。JPCERT/CC が、1.0 版を翻訳してくれているとのことで、さっそくダウンロードしてみた。

https://www.jpcert.or.jp/research/2010/SAMM_20100407.pdf

TODO: もう、ぐだぐだだ。もう少しだけ書きたい。

https://speakerdeck.com/owaspjapan/owt2017jp-owasp-samm


Closing "The shift left path"

SHIFT LEFT。言葉は違えど、昔から、そう言われていたような気がする。まだまだ実現できていない、ということなのだろう。

TODO: 後で書く

https://speakerdeck.com/owaspjapan/owt2017jp-the-shift-left-path


「被害者を産むようなアプリケーションを、システムを、世にリリースしてはならない」と思っている(だろう)人がたくさんいて、勝手に励まされた。


最後に。

今回、これだけのイベントを開催していただいたのだが、なんと参加費用は 0 円。無償だった。> 主催者のみなさま、講師のみなさま、ありがとうございました。

また、非常によい環境で、気持ちよく受講できた。> サテライト TOKYO-C 会場のスタッフのみなさま、ありがとうございました。

*1:「BOOTCAMP」 でも、「トレーニング」 でもないような気がした。

*2:こういう取り組みは開発現場の理解が不可欠だと思う。しかし、それを取りつけるのは、なかなかハードルが高い。トップダウンで降ろしてもらうには、まだ、体力が足りない。ボトムアップで、できるだけ現場の負担にならないように、「打ち合わせ時間を短くする」や「現場で対応しなければならない箇所を減らす」など、工夫をしてはいる。が、まだうまく機能はしていない(ボスのおかげで、少しずつは成果が出ている)。

2017-04-08

FP 法のイメージをつかむ

| 09:05 |  FP 法のイメージをつかむ - あしのあしあと を含むブックマーク

ファンクションポイント(以下、FP)法について、なんとなく頭に残っていることをメモしておく。もう、ほっとんど忘れてしまったので、少し復習しながら。

「FP 法」については、聞いたことしかなかった*1し、もはや過去の手法だと思っていた。どんなイメージをもっていたかというと、要件定義 〜 外部設計で洗い出された「機能一覧」,「画面一覧」,「帳票一覧」,「外部 I/F 一覧」,「テーブル一覧」の行数を数えて、お終いだと。まぁせいぜい「組織ごとに機能の粒度をなるべく統一する」や「重みづけをして足し合わせる」くらいの工夫がある程度だと。


1 年前くらいに、ほんの少しだけ仕事でからんだのをきっかけに、もっと「きちんと」計測のルールがあることを知った。イメージとはかなり違っていて「データの項目数を細かく計測し、そこから規模を算出する方法」だった。確かに、いわゆる「機能一覧」にある機能なんて、粒度がてんでバラバラで、それの数を数えることに、ほとんど意味はないだろう。項目数をベースにすれば、ぶれは小さくなりそうだ。

そして、この時お世話になったのが、次の書籍。ただ、残念ながら、業務で計測できるレベルまでは到達しなかった。相も変わらず、自分の理解力のなさには辟易する。

もとい。この本では、今、最も普及している IFPUG 法が解説されている。そもそも、複数の方法があったことすら知らなかったのだが。

まずは、AP 境界(以下、境界)を設定するところからスタート。内外で分けてデータを数える、境界をまたぐデータを数える。ちなみに、データを数える際は、だいたい、次のように考える。

  • ユーザが認識できないデータは、カウントしない。例えば、データベースの各テーブルにある、システム管理に用いるカラム(例えば、更新日時)など
  • 実質的に「同じ」データは、カウントしない。例えば、入力したデータが、次画面で出力されている場合は、あわせて 1 つとカウントする

これは、システムの規模が、過大に評価されないようにするためだろう。少し、具体的な計測の流れをみてみる。


ファンクションの抽出と識別

初めに、ファンクションを抽出、識別する。そもそも「ファンクション」とは、FP 法にもとづいて抽出された AP の『機能』のこと。全部で 5 種類ある。イメージ優先で、超コンパクトにメモしておく。

  • データファンクション(DF):ユーザが認識できる論理データ
    • ILF(内部論理ファイル)… 境界内で維持管理*2
    • EIF(外部 I/F ファイル)… 境界内から参照のみ
  • トランザクションファンクション(TF):ユーザにとって意味があるデータの入出力
    • EI(外部入力)… 境界外から ILF に維持管理
    • EO(外部出力)… 境界外に出力(加工あり)
    • EQ(外部照会)… 境界外に出力(加工なし)

これらが『機能』。

DF であれば「DFD」,「ER 図」などから抽出し、ILF と EIF を見つける。TF であれば「業務フロー図」,「画面設計書」,「帳票設計書」などから抽出し、EI, EO, EQ を見つける。


ILF, EIF および EI, EO, EQ を見つけたら、それぞれの複雑度を判定し、点数化していく。 複雑度は、Low(低), Average(中), High(高)の 3 段階で判定する。ざっくり 3 段階。どうせ一定のブレ幅があるのに、これ以上細かく基準を設けても、手間ばかりかかるからなのだろう。

具体的にどうやるのか、以下に、簡単にメモしておく。


DF の複雑度の判定と点数化

まずは、DF の複雑度の判定から。複雑度は、DET と RET の相関で決まる。間違いを恐れず、この 2 項目のイメージをメモする。

  • DET(データ項目数):ユーザが認識できる、データの項目数*3
  • RET(レコード種類数):データのサブグループの数

データの項目数と、サブグループの数を分けて数えるのは、なんとなく納得できる。いくらテーブルの項目数が少なくても、参照するテーブルのリストが多い場合には、処理が複雑になりやすい*4だろう。

それぞれ計測し終えたら、次の表*5に従って複雑度を判定し、点数化する。

f:id:higher_tomorrow:20170402174934p:image:w480


TF の複雑度の判定と点数化

次に TF の複雑度の判定。DF と同様、間違いを恐れずイメージだけをメモする。DF の DET の計測の粒度を考えると、画面や帳票だって、同様に数えると考えるのが自然だろう。

ここで、FTR の考え方が面白い。いくら画面の項目数が多くても、1 テーブルの内容を出力するだけの機能は、小さな機能だ。確かに、要件定義 〜 外部設計あたりのフェーズでは、こうやって複雑度を算出するしかない気がする。

  • FTR(関連ファイル数):処理を行うときに、参照・維持管理される DF*6
  • DET(データ項目数):境界をまたぐデータのうち、ユーザが認識できるデータの項目数*7

DF の場合同様、それぞれ計測し終えたら、次の表に従って、複雑度を判定し、点数化する。

ちなみに、EQ と EO の複雑度の判定は、全く同じ表を用いる。しかし、EQ よりも EO の方が高い点数がつくようになっている。

f:id:higher_tomorrow:20170402131836p:image:w480

f:id:higher_tomorrow:20170402131834p:image:w480

f:id:higher_tomorrow:20170402131831p:image:w480


複雑度の判定の具体例

例として、次の図のような、帳票を出力する処理における「発注情報の ILF」および「発注書を出力する EO」を考える。これで DET, RET および FTR, DET を計測するイメージがつかめるはず。


f:id:higher_tomorrow:20170402204903p:image:w480


ここで、「発注書を出力する」ファンクションが EO になっているのは、発注書に「合計」の欄があり、出力時に演算しているから。ただ、EO と EQ は、どこで線引きするのか、正直、よくわからない。

さて、前述したマトリクスを用いて、FP を計測しよう。「発注情報の ILF」は、DET = 8, RET = 2 なので、複雑度は L(低)。なので、7 FP。一方、「発注書を出力する EO」は、DET = 11, FTR = 3 なので、複雑度は A(中)。なので、5 FP。


せめて、これくらいは、頭に残しておきたい。

*1情報処理技術者試験で出題される程度の知識しかなかったし、興味もなかった。特に昔は、KKD(経験・勘・度胸)が好きだったからなぁ。

*2:登録、変更、削除などの処理をいう。

*3レコード数ではない。

*4:実装する場合には、SQL も大きくなるし、パフォーマンスもおちやすい。

*5:この表は、どうやって作ったのだろう?

*6:参照される ILF or EIF および、維持管理される ILF。

*7:やはり、繰り返しや重複を除く。

2016-01-03

Trac Lightning のテーブルの構造を探ってみた

| 22:02 | Trac Lightning のテーブルの構造を探ってみた - あしのあしあと を含むブックマーク

体調は、まずまず。なんだけど、法律の勉強をする気が起きなかったので、Trac Lightning 3.2.0(Trac のバージョンは 0.12.4)をインストールして、そのテーブルの構造を調べてみた。仕事で Trac の管理まがいのことをやっているから、一度くらいはのぞいてみておいた方がよいかと思って(仕事中にお勉強って、なかなかできないので)。いつものごとく、パワポでお絵かき。

PupSQLite を使ってデータベースの中をのぞきつつ、適当に Trac と SVN をいじくって遊んでみた。そして、なんとか、Trac Lightning インストール後に存在する全テーブルを、1枚の絵におさめることができた。

f:id:higher_tomorrow:20160103214050p:image:w480

中には、よくわからないテーブルもあって。例えば「cache」テーブルや「system」テーブルは、何に使っているのだろう?

と、ネットを検索していたら、、見つけてしまった(いとも簡単に)。

http://trac.edgewall.org/wiki/TracDev/DatabaseSchema


既に、絵はあったのね。とほほ。。よく調べてから、作業するんだった。

で、この「implicit object Users」って何?えー。

2015-08-29

(今さら)Trac+SVN

| 05:21 | (今さら)Trac+SVN - あしのあしあと を含むブックマーク

最近、面倒を見始めたシステムを1枚の絵であらわすと、こんな感じ。

f:id:higher_tomorrow:20150827164219p:image:w480

こ、これは、、Trac+SVNではないか。アーキテクチャがぜんぜんわからず、苦戦中でござる。

2015-06-18

Silk Test と戯れる日々

| 05:15 | Silk Test と戯れる日々 - あしのあしあと を含むブックマーク

6月に入ってから、Silk Test(画面操作が必要なテストを自動化するためのツール)をいじっている。ここ2〜3日、ようやく体調が戻ってきたので、けっこう楽しく戯れている。テストコード(以下、スクリプト)を書くのは、なぜか嫌いではない。

あ、Silk Test には、スクリプトではなくGUIでテストを作成する「ビジュアルテスト」という機能もついている。が、生産性や可読性の観点から、採用を見送った。この機能は、たぶん、ユーザ側の人たちが対象なのだろうと思う。ちなみに、ビジュアルテストとスクリプトの相互変換はできない。このあたり、QTP ほどは使い勝手がよくはない。ん?今は、UTF っていうのか。


で、Webアプリケーションのボタンなどのオブジェクトに、フォーカスが当たっているかどうか、自動で検証をしたいのだが、、これが、いい感じで苦戦している。

IFocusable インターフェイスを実装しているオブジェクトなら、IsFocused メソッドによりできるかもしれない。IMoveable インターフェイスを実装しているオブジェクトなら、GetFocus メソッドによりできるかもしれない。

でも、DomButton オブジェクトや、DomLink オブジェクトには、こういったメソッドが実装されてなさそうだ。ボタンなどのオブジェクトが保持するプロパティのうち、"focus"という文字列を含む全プロパティを試してみたが、ダメだった。。Help!!


スクリプトは、VB .NETで記述するのだが、自分はJavaとシェルスクリプトがメインだったので、これまた苦戦している。

なんかよくわからないが、色々とコツがいるっぽい。例えば、次のように、テキストエリア内の改行を確認するのに、改行コードとして「vbLf」を使わないと、うまくいかない。Windows上で実行しているのに、なぜ改行が「vbCrLf」ではないのか。。

  ' うまくいくケース
  With _desktop.BrowserApplication("BrowserApplication")
      With .BrowserWindow("BrowserWindow")

          .DomTextField("TextField").SetFocus()
          .DomTextField("TextField").TypeKeys("<Ctrl+a><Delete>")
          .DomTextField("TextField").PressKeys("いろは<Enter><Enter>にほへと<Enter>")
          Workbench.Verify(
              "いろは" & vbLf & "にほへと",
              .DomTextField("TextField").getProperty("value"),
              "入力した日本語が確定し、テキエリア内で改行されること")

          End With
  End With

ちなみに、Silk Testの機能を使ってWebアプリケーションに対する動作を記録したときに、自動生成されるスクリプトは、上記のような感じになる。なので、With 〜 End With を多用しているのだが、本格的に量産体制に入る前に修正するつもり。