セキュキャン2015講義メモまとめ

AndroidとiOSのアプリサンドボックス

守る技術
モバイル端末の様々なセキュリティ機構がどのような仕組みなのか知ってほしい
日本の端末独自の取り組み
今後のモバイルセキュリティの向上のための提案をできたらいいね

攻める技術
jailbreakやアプリの脆弱性がどのようなものか知ってほしい
ブラックボックスとなっている危機のセキュリティ機構をry

Jailbreakとは
セキュリティ機構をすべて突破すること
端末の機能を完全にコントロールできる状態
端末のbootloaderやkernelも書き換えられる
やろうと思えばOSをまるごと入れ替えることも可能

Jailbreakのメリットや目的
端末自由にカスタマイズ
いらないアプリの削除 無効化
広告の排除など
端末やアプリのより詳しい調査
技術的な挑戦

Jailbreakの注意点
利用規約違反 
電波法違反(ファームウェアの書き換え，モデル側の操作)
偽ソフトウェアの存在
Jailbreakによるリスク(sshなどのサービスのパスワードをデフォルトのまま運用 Jailbreak用ソフトにマルウェアが混入 Jailbreakの失敗による故障など)

Jailbreakの脆弱性を見つけるには?
高度なスキル
Exploitコード作成スキル
1から解析するリバース・エンジニアリングスキル
kernelExploitを含めて複数見つける必要がある

特にiOSは難しい
実行ファイルは全部バイナリ(逆コンパイルできない)
ブラックボックスなシステム

Androidなら
AOSPのリポジトリをおっかける
こっそりバグシュウセイされている場合もある
過去の脆弱性を理解する
Linux自身の脆弱性も使える
Chipsetベンダーのドライバの脆弱性もリポジトリで追う

Jailbreakの脆弱性を見つけるには?
あやしい動作を見つけておく
クラッシュ野菜起動する→その時のクラッシュログを取得しておくなど

Jailbreakの難しいところ
Sandboxの回避など

Jailbreak用の脆弱性は2種類ある
・一般アプリから利用できる脆弱性
     ・一般的な脆弱性としての評価は高い ブラウザの脆弱性など
・端末の所持者自身にしか利用できない脆弱性
・ユーザの操作が必要
     ・アックアップ用の処理
     ・端末のロックを解除しないと使えない
     ・Androidのshellからなど
他人が悪用することは難しい

ASLRとDEP
バッファオーバーフローなどから防御できる技術
Android
     ASLRとDEPどちらも有効
     ただしアプリは全部同じアドレスを使う(アプリは実質ASLR無効)

Sandbox
想定された動作のみ許可
他のアプリやOSのデータの干渉を防ぎ保護する
systemを乗っ取られてもrootは守る
rootを取られてもkernelは守る

Sandboxで制限されること
アプリ管理外のリソースへのアクセス
システムデータの書き換え
デバイスドライバにアクセスできず，kernelExploitにry

Capability
特権を分割し，個別に設定できる
Linuxのセキュリティ機構
rootから特権を剥奪 一般ユーザ継承させるに特権を選べる

SELinux ユーザに機能を制限させる!?
一般アプリは制限が厳しい
Shellユーザへの制限もある?
jailbreakの際にはこれらの抜け道を探す必要がある


iOSのサンドボックス
一般のアプリはサンドボックスが有効になる
プリインストール済のアプリは異なる制限で動作する

基本的にアプリは以下以外にはアクセスできない

uidはmobileとrootのみ
通常のプログラムはmobileで動作

コード署名がないとプログラムが動かない
Appleが認めたアプリしか動作しない

端末の脆弱性の問題点 
脆弱性が見つかっても脆弱性修正までの期間が長い
古い端末だとパッチが提供されていない場合もある
端末の管理者権限がないため自分で修正も出来ない(修正するにはjailbreakが必要)

アプリの脆弱性の起こりやすい所
アプリの脆弱性はアプリ間連携で起こる事がおおい
(カスタムURLスキームetc)

カスタムURLスキーム:ブラウザで開くとアプリが起動する
アプリでバリデーションが不足していると脆弱性になる
iOS,Android両方の機能

SSL証明書の検証不備
かなりよくある脆弱性
検証を行うのは2点
     証明書チェーンの検証
     ホスト名の検証


開発者側としてセキュリティに考慮しながら書く場合，
この機能をつけることでどういう理由で何が有効になるのか
というのを明確にしたほうがよい
また，どういうセキュリティモデルであるか，ということを自分自身で明確化する必要がある．

HTTP2,QUIC入門

HTTP/2はTLSと異なり必要となる要素技術の数は少ない．
ヘッダ圧縮仕様HPACKを完全に理解しないと概要以上のレベルの技術は身につかない．
HTTP2はTLSの上に乗っかっている

HPACK:ビットをどう扱うか 記号の遊び データの遊びのような…

QUICはTCP/TLSの技術要素の集まり きちんと理解するには相当の努力が必要
HTTP/2とQUICの技術的概要を知ることを目的とする．
HTTP/2データの解析ができるところまで目指します．

HTTP/1.1からHTTP/2へ
TCP ハンドシェイク 
HTTP通信:平文でも暗号文でもOK
HTTP/1.1 semantics(ヘッダの中で遣り取りをする それはある意味セマンティックス?)文法は変わらない
HTTP/2 Frame Layer
従来のHTTP/1.1とTLSの間にクッションが入ったもの

プリミティブ

HTTP転送サイズ3年で96%増加
リクエストも20%増加

回線帯域を増やしても，ある一定から表示時間が変わらなくなる
Round Trip Timeを小さくしていくとちゃんと下がる
WEBページの表示速度を早くするためには回線速度増強よりRTTの影響を小さくするかが重要

HTTP/1.1の問題
HTTP Head of Line Blocking(先頭のHTTPリクエストが終わらないとレスポンスが帰ってこない)
ネットワーク通信の利用が非効率
曖昧でテキスト処理が煩雑

TCPの問題点 
TCP Head of Line Blocking 
3方向ハンドシェイクのコスト
initcwnd(初期輻輳ウィンドウ)が小さくスロースタート
パケットロスによる大きなバックオフ
カーネルのソケットバッファの増大
NATのタイムアウトとIPのローミング
経路途中のTCP Nuffer Bloat
解決策は提示されているが，OSや中継器の機能追加が必要 これは非常に時間がかかる．

QUIC(Quic UDP Internet Connections)
Googleが独自に開発しているプロトコル
UDP上でTCP*TLS相当+αの機能を実装

Javascript難読化読経

Closure Compiler:Googleのjs圧縮コンパイラ

Web Assembly :
ブラウザ上でのjsパース時間が高速化のボトルネックなので事前パース済のバイナリjsを配信
ブラウザ = WebAssembly実行環境
バイナリが読めないと今後上位レイヤーでも死ぬらしい

難読化する理由:
アンチウィルスやIDSの回避
(パターンマッチの回避が目的 機械的に大量に生成 Gumblar,Gumblar.Xなど 最近は少ない，解析は容易)
アンチデバッグ
(解読しにくくする事が目的:攻撃者による悪意のあるコードまたは正規のアプリケーションによるロジックの隠蔽など)

難読化のテクニック
長く読めない変数名(minify, 文字列を無駄に長くする)
文字列の隠蔽(ゴミの埋め込み(ゴミを入れてreplaseでゴミ取り出す機構作ってたりとか)，8進数16進数にするとか)
(文字列を位置文字ずつ組み立て ブラウザのエスケープ関数やエンコード関数)
(n進数化するとか 部分文字列の切り出しや連結)
プロパティへのアクセス
文字列を実行


難読化jsの読み方

圧縮，js自動生成されたもの
変数名や関数名が1文字になっている
ロジックの隠蔽は基本的にない
DOM操作は隠れていないのでDOM操作を手がかりに処理の意図を推測

攻撃者による改竄
基本的には「文字列の生成→文字列をコードとして実行」の形態
evalやFunctionなどのコード実行部分をフック
改竄の場合は結局はiframeやscriptの注入がほとんど
基本的に根性で読む

"setTimeout(function(){var key1=document.getElementById("key0").value;var r="",n,c;n=key1.length;for(var i=0;i<n;i++){c=key1.substr(n-1-i,1);if(/[a-z]/.test(c)){c=c.toUpperCase()}else if(/[A-Z]/.test(c)){c=c.toLowerCase()}else if(/[\d]/.test(c)){c=9-parseInt(c,10)}r+=c}var e=document.createElement("img");var f="\x66\x6c\x61\x67\x7b"+r+"\x7d";n=r.length;for(var i=0;i<n;i++){c=r.substr(n-1-i,1);if(/[a-z]/.test(c)){c=c.toUpperCase()}else if(/[A-Z]/.test(c)){c=c.toLowerCase()}else if(/[\d]/.test(c)){c=9-parseInt(c,10)}r+=c}r+=f.length;f=r+Math.random();e.setAttribute("src","r");document.body.appendChild(e)},1000);"

WEBプラットフォームのセキュリティ

プラットフォーム化するweb
複雑化するweb
(6週間おきにメジャーバージョンアップ) 
(webアプリの大規模化:開発者の努力や脆弱性診断だけで安全性を保つことは困難に)

WEBをセキュアにする技術が登場
XSSを抑止するCSP
全ての通信をTLSで暗号化する技術HSTS
サーバ上のリソースの改竄を検知する技術(SRI)

しかしこれらが全ての問題を解決するわけではない
その技術を導入すると新たに生じる問題が…
仕様自体の考慮漏れが普通にある

HSTS:スーパークッキーズ
https->1 http ->0 ってやっていくと，ユーザのトラッキングが出来る

HSTSを基に問題点を考察
端末時刻の改竄にｙるHSTSの強制失効
HSTSを用いたユーザ追跡
実装を謝るとHTTPS非対応のサブドメインがアクセス不能になる
HSTSはwebsocketに適用されるのか? クロームではされていない脆弱性が報告された
HSTSはプライバシモードにも引き継ぐのか? (プライバシが無くなる可能性が)

FetchAPI : curlみたいな感じ リクエストを出して受け取る(メッチャ仕様がきついらしい どうして?)

Phishing
ニセのサイトに誘導し，そこでパスワードなどの貴重な情報を入力させる
利用者をだますために，本物のサイトと似た画面を用意
国際化ドメイン名によりリスクが増加する．
対策 
Unicodeの部分だけpunycodeで表示するとか
URLに含まれる言語がユーザのロケールと一致すること
混在が許されない複数の文字集合がURLに存在しないこと
Safariはホワイトリストで許可した文字集合のみIDNで表示

Pharming
DNS情報の改竄により，偽サイトへ誘導させる
DNSによる名前解決→ニセのIPアドレスを返す
hostsの改竄，DNSサーバやルータへの攻撃など
ドメイン名ハイジャック

SOP(同一オリジンポリシー)
異なるオリジンのオブジェクトは操作できない
(例外的に操作できるオブジェクトもある)

Fetch API
HTTPによる非同期通信を提供する低水準のAPI

WEBには様々な脅威があるブラウザベンダは個々に対策を講じてきた
現状を理解しそれぞれの立場で今やれることをやってwebを安全にしていくしかない
今ある技術を正しく理解して使う
今の技術では未解決の問題を解決するために提案をする

これからのWEBセキュリティ

セキュリティだけ 開発だけ ではなく
セキュリティの理解がある開発者が求められている
知識を技術的に還元できる人材が必要

ユーザが投稿したjsをシェアする(動かせる)ものがある
セキュリティの常識:ユーザにやらせるなんてとんでもない!
少し基準を緩めてユーザ投稿を許す
sandboxで使われているので被害は抑えられる
常識を一つ変える事で開発が進むのかもしれない

Railsを使っていればxss csrf sqliを入れ込みにくい
デフォルトで作りこまないような設計になっている

XSS
<h1><%= URL%></h1> ←on the rail

html special character 
なんでこの文字をエスケープしなきゃいけないのか よく分かっていない現実
分かっていないのなら，「かならずこう書け」と指導するしかない

ちなみにエスケープしないのなら
<%= raw URL %> ← out of rail
レールから外れているので身構えて欲しいという意味

開発者が意識しなくても守れるような仕組みを作る必要が多いにある
railsの場合，現在はサーバサイドが中心なので，クライアントサイドでもセキュアにしていく必要がありそう

アプリケーション自体がHTTPSを前提にすることはまだ進んでいない


「趣味と実益のスタック破壊」

これからのwebセキュリティ
開発技術とセキュリティ技術が近いところに来ている
開発技術抜きにセキュリティが語られなくなってきている

~2000
まだフロントエンドという言葉はなかった
ブラウザ自体を攻撃しユーザの端末を乗っ取る攻撃が主流
「セキュリティのためにjsはオフに」
iframeでのオリジンの詐称が既にあった

~2003
cssの発展と攻撃手法の開発 object要素なども攻撃対象に
ブラウザ機能を使っているメーラを経由したウイルスの流行
各サイトが「スクリプトによる貼り付け処理」を要求
ブラウザがネット上のバイナリを自動実行する問題
webサイトのディレクトリindexが公開される事例が多数
XSSが流行った
クライアントが直接攻撃される事が多かった

~2005
各サイトが攻撃されるようになる
SQLiが流行る
XSSが発展する
画像処理系に問題が見つかる (GDI+のバッファオーバーフローなど)

~2008
IPA「安全なウェブサイトの作り方」公開
SQLi勃興期
wiki関係の脆弱性多数
Flash関係の問題が報告され始める
jsonの解析にevalを使う危険性が語られるようになる
クロスサイトリクエストフォージェリ黎明期

~2011
Adobe Readerの問題が増える
バグ報奨金精度登場

~2013
utf-7サポートが着られる
XHR2が一般化．jQuery関係でセキュリテイホールの報告が増える
webviewの発展とネイティブアプリXSS

~2014
FlashPlayer経由のXSS
文字コード
Android webview
パスワードリストアタック

2015
mXSS
virtualDOM
Fingerprint

~2015までずっと
javaのセキュリテイホールが問題になってる
webが複雑になりすぎていて，限界が来ているのではということを象徴しているのでは?


現在

安全性自体は上がっている
ターゲットを絞った攻撃が増えてきた
仕様レベルで安全性を確保する方向になってきた
常時暗号化前提の機能拡張:ネットワーク機器の互換性的な問題で，あらゆるものに暗号化がされる
HTTP/2をすべて対応するには不可能

ClosureToolsが流れを牽引している
Contextual Auto Escaping(最近ではyahoo/secure-handlebarsという選択肢も)
Strict Auto Escaping(サーバサイドでいうScalikeJDBCのSQL Interpolation的なもの)


未来

webのアプリ化とアプリのweb化が近いところに来ている()
CSPの普及と進化(コンテンツセキュリティポリシー)
機能追加とパーミッションモデル

「この方法なら安全」というセキュリティ側の意見だけでは，開発側は制約が厳しくて使いにくい
今後もそのアプローチは受け入れてもらえないのでは
セキュアなものに，魅力的な機能を付与していく方向で増えていく


新しいセキュリティモデル
     セキュリティモデルの遷移
     新しいセキュリティモデルの構築
     なぜ新しいセキュリティモデルが必要なのか

デバイスによってセキュリティモデル(機能をどう許可するか)が変わってくる可能性がある
携帯は前提として1ユーザしか扱わないだろう→なので機能の許容が大きいとか
これが時計なら？ ピアスなら？ デバイスによって機能の制約が変化する


セキュリティエンジニアの今後
     バグハンター(WEBサイトもバグハンターがいるからという前提で進む可能性はある ブラウザはすでにそうなっている):純粋なセキュリティ技術が求められる
     セキュリティアーキテクト:開発もするけどテストをベースにしている人が出現するのでは(両方の技術を持っている人が大事 開発現場では既に必要となっている)
     セキュリティマネージャ:バグハンターと連携して，報奨金制度を運用する 足りていない
バグに関してどのくらいの額を払ったほうが良いか，どう満足してもらうか どう惹き付けるか というマネジメントの分野の人間が必要


Webセキュリティの「フロントエンド」


報奨金制度
googleよりも金をかければ世界一セキュアになれる
まだマイナスのコストが大きいという認識があり，日本では普及していない → どうしたら良くなっていくと思いますか?
バグ報奨金制度期間を設けてプレリリースを行うなど?
サイボウズは総額を決めておいて，予算でコントロールしていく

クラウドセキュリティ基礎

インターネットの企業の屋台骨
1時間サービスが止まるとサイバーエージェントだと約250万の損益…

クラウド
1.作ったサーバに環境構築してすぐ本番投入したい

サーバの環境構築の手間がかかる
ミドルウェア入れて設定ファイルを変更
アプリの動作に必要なライブラリも入れる
最新のアプリをデプロイ
アプリ設定(DB認証情報)設置
アプリのプロセスを起動

2.本番投入中のサーバでもすぐに消したい

サーバ無いにデータを保存できない
データベース
セッション情報
アクセスログ エラーログ デバッグログ
システムログなどetc


statelessサーバとstatefulサーバ
statelessサーバ
アプリケーションを動かすサーバ
データを中に一切保存せず，コピーすれば動くレベル
いつでも追加/削除しやすい状態を保つ

statefulサーバ
データベース，ログ
追加削除がしづらいので死ぬ気で守る
スペックアップや分散DBのりようでスケーラビリティ確保


statelessサーバの指針
Twelve Factor App
今までに定期された最適解のまとめがある

satefulサーバは?
「銀の弾丸」は無いが，現実的な選択肢は増えている
1.スケールアップで対応
2.分散DB
3.すごいストレージサービスを使う

分散DBにおけるCAP定理
以下のどれかが犠牲になる
可用性
一貫性
ネットワーク分断体制


クラウド時代のサーバ設計
Statelessサーバ
アプリを動かす
台数でコントロール出来る状態を保つ

statefulサーバ
データを保存
気合入れて頑張る


クラウド時代の脆弱性対応
アプリケーションの脆弱性が圧倒的に多い
Blue Green Deployment
脆弱性があったらもう1セット作って古い方を捨てる!という考え方

万能じゃない
SSHとかStatefulサーバの脆弱性もある
共通脆弱性評価システム CVSS v2
基本評価基準
現状評価基準
環境評価基準
で判断する

AWS独自の高レイヤーなサービス
割り切ったサービスレベル
1つのサーバが死ぬくらいは障害ではない
冗長化の枠組みを用意しているから冗長化は利用者の責任
さくらのクラウドは1台ごとの稼働率で判断する

RESTAPIによるアクセス
ほぼ全ての作業をAPIで利用可能
APIのアクセスキーをあらかじめ取得
コントロールパネルと同様の操作が可能になる


最小権限の原則
情報セキュリティでもっとも重要な原則
必要最小限の権限だけを用意する
ex アクセスキーの権限を最低限にする
APIの接続元IPアドレス
サンパウロでサーバ作成する権限は本当に必要?

個人情報とかの保存:きちんとやれば大丈夫

安全なデータの保存
権限管理
     データベースやデータベースサーバへの接続権限の最小化
暗号化
     データベースの暗号化
通信路等の保護
     ネットワークレベルの分離
     物理サーバ単位の専有化


気密性完全性Integrity可用性Availability


リスク評価
ある程度以上のビジネス継続リスクは許容できない
対策コストが見合わない例は見過ごしていい?

リスクの可視化
金額に落とすと定量的に評価出来る
失うものが少ないほど受容できるリスクが増える
行き過ぎた結果が「サイバーノーガード戦法」

抑止・防止
攻撃の「機会」そのものを減らす
対外的なアピール
エンドポイントを気軽に見せない
攻撃の「被害」を減らす
関係者の権限を管理する
責務の分離
最小権限


セキュリティ施策がスピード感を損なわないことの確認を取る
リスク脆弱性の対応を取る

クラウド時代のWEBシステムについて
サーバ設計，構築，運用技術の基礎
     サービスの無停止とスケーラビリティを実現する設計
具体的なセキュリティ施策
ID管理と監査
機密情報の保存

スマートフォンゲームやソーシャルゲームにおける不正行為の問題点と対策

チート:本来と異なる動作をさせる
該当するかや不正行為となるかはゲームの仕様に深く関わっている

何のためにチート?
俺つえええええをするため ゲーム内，ゲーム外で自慢
課金・作業回避 
金銭目的(RMT，アカウント販売 チート作業の代行)

チートをされると…
ゲームバランスが崩壊→ゲームの寿命を著しく縮める
ユーザの不公平感を生む
非チートユーザへの直接的被害
課金によって発生するはずの利益の損失
特にオンラインゲームだと影響範囲や非チートユーザの関わり方が複雑になるため致命的になりやすい

チート対策の難しい部分
ゲーム全般を理解できない/しようとしない意見「所詮ただのデータだから価値がない」
バグを作った開発側が悪い(法律に違反しなければ何をしてもいいという考え方)
巧妙なチートユーザは発見BANが難しい(チートなのか単純に運がいい，上手いプレイなのか区別がつかない)

ブラウザアプリ:一般的な脆弱性対策の知識・経験も比較的所持しているケースが多い
スマホアプリ:ゲームUIが作れてサーバがつくれてセキュリティも分かる人材は稀である
見た目・ユーザ体験重視の開発になることもしばしばある
見た目が凄い綺麗だからといってセキュリティの対策までなされているとは限らない

企画時のセキュリティの認知度・経験の低さ，スマホアプリを取り巻く現状
セキュリティをいしきした計画を立てるのが困難
リリース時にヒットするか判断が困難なため基本的にスモールスタート
世の中に脆弱なゲームアプリがあふれている中で，コスト(お金や時間)をかけて対策をするのが難しい

セキュリティ専門外社に診断を依頼すると
膨大な費用がかかる
セキュリティだけで開発費用全体を超えることあり
ゲーム性に深く踏み込めない
時間がかかりすぎる
網羅的にやると診断期間だけで数時間ということも

Webアプリとかの脆弱性と違う所
一般的なセキュリティの範囲の話があまり重要ではない
XSS関係ない(ユーザの自由入力が無かったりとか)
SQLインジェクションも作りによってはさほど脅威ではない
ログイン情報以外非公開の重要情報がほとんどない

クライアント上で暗号化を行う際にクラックされにくい方法は
◯DES+独自ロジックで暗号化
× 3DES + 難読化 
because 3DESの鍵がわかれば難読化の程度にもよるがやられやすい
独自ロジックで暗号化されていると調べるのが面倒なのでされにくいらしい

パラメータも基本的に何が改竄されると困るのかが分からない
ある時ある時で持ちうるパラメータが違うので，やってても対応が大変らしい

攻撃されうるポイント
・サーバ側のデータを書き換える(不正な通信 リクエスト)
・クライアント側(通信レスポンス改竄 メモリ改竄 アプリ改竄 データ改ざん)

チートを防ぐ
サーバ側:不正な通信(リクエスト)
トランザクション管理(レコードロック)

改竄検知・通信保護
(データへの署名付与: クライアント側 チェック:サーバ側)
(データの暗号化: SSLとかではなく)
(証明書のpinningによるproxyツール等でのCapture禁止)
→第3者による盗聴，改竄を防ぐ目的ではない

自動化検知・ブロック
・APIへのアクセス感覚の監視
・ゲーム内パラメータの増加速度の監視
・改竄検知・通信保護による自動化スクリプト作成の困難化
(サーバへのアクセスの自動化 いわゆるbot)

その他よくあるアプリでダメなところ
・SNS連携でなりすましし放題
・BaaSで署名がないのでデータ書き換え放題

バグハント入門

脆弱性報酬制度
Webアプリケーションでもgoogle FB GIt DBoxなど
小切手は換金手数料は高い

善意の検査でも攻撃とみられることもある
ISPにインターネットを止められた人も居るらしい

サイボウズ:日本の企業で唯一報酬制度を実施
検証環境を申請で用意してくれる

LiveはHTTPS化 でもhttpのものは空のiframeが貼られてた
無関係のホストをiframeにロードできてしまう
フィッシング
オープンリダイレクトとして利用
クリックジャッキング

CSS expression()
CSSからjsを実行できる
CSS注入の危険度が大きく上がる
IEの古いドキュメントモードで動作
<p style=x:expression(alert(1))>

HTML security cheat sheet
HTTPLeaks:HTTPリクエストを発生させるようなものの一覧を表示

ハントの秘訣
細かいことをきにしよう
些細なバグや特徴的な挙動(いちいち悪用できないか考える)

脆弱性を引き出すコツ
とりあえず手を動かして試す 色んな文字を打つだけでも気付きは得られる
クラスタを列挙しておくと便利
HTMLタグ一覧
HTTPLeaks
例えばフォーマットのファイルのセット
ブラウザで利用可能な文字コードの列挙
パーツが沢山あればアイデアに幅が生まれる

日本語入力でUnicodeのコードポイントを入力
1f625 → F5 でドヤ顔がでるらしいw

XSSフィルター
遮断出来る文脈を見る
典型的なXSSがある状況を作って遮断できるか確認
反射型XSS
DOM based XSS
Stored XSS
結構色々通してしまうので機能の限界はある
全てのXSSを止めることは出来ない
誤検知はなくせない(意図的に起こすことも出来る)

IEのXSSフィルタに絞ってみる
どんな文字列が遮断対象なのか厳密に見る
バイナリを観察
URLにアレコレ入力して試す
通過できたら想定外の挙動がしていることになる

知らなきゃより知りたいで動く
忘れ去られたものにも，今の技術と組み合わせると思わぬ化学反応があるかも?
バグハントは根気で

[感想]
己の無知を痛感…
XSS gameは触ったのに演習のXSSは全然分からなかった．
そもそもGETでどう渡せばコード埋め込めるのかが理解出来てなかったので，そこから課題
しかし，任意コード実行も発想力と工夫でカバー出来そうなので，0歩目を踏み出せたら楽しく脆弱性を見つけられるのではと感じた．
また，企業で有志にお金を払って取り組んでもらうところが増えると良いなと感じた．
バグハントも公開していく方がOSSが活発な時代なので，自分自身のアピールポイントにもなるし，企業側もこういうバグが修正された，と報告するほうが利用者も安心できるのではないかと思った．

完全性を支える技術

完全性(Integrity)の基礎
:情報が破壊，改竄または消去されていない状態を確保する．
誰がやるのかが問題

破壊されてない証拠は? 改ざんされてない証拠は? 消去されていない証拠は? etc
完全性の検証によってこれらを証明する．

最も単純な検証 1bitずつ”あるべきデータ”と”検証対象のデータ”を比較し完全に一致していたらデータの完全性を保っている．

データの破壊を検知するアルゴリズム
誤り検出・誤り訂正
チェックサム CRC パリティ符号
→こっちは改竄検知には使えない

データの改竄を検知するアルゴリズム
Cryptographic hash function(ハッシュ関数)

代表的なハッシュ関数
MD5 よわい
SHA-0 よわい
SHA-1 ちょっと強い
SHA-256 つよい

暗号的ハッシュ関数は限りなく一方向の性質を持つものを用いる
暗号的ハッシュ関数は計算毛化から元のメッセージを計算することが難しければ難しいほどよい
ハッシュ関数にかけるメッセージ→出てきたものはダイジェスト(と呼ばれる)

ハッシュ関数の強さ
衝突攻撃と現像攻撃への体制があるものを選択する

衝突攻撃:データを改ざんして同じダイジェストを作れる
現在，MD5,SHA-0は結構簡単に衝突攻撃ができてしまうことがわかっている
SHA1も理論上衝突攻撃ができることがわかっている

"あるべきデータ"の完全性は誰が守る?
そもそも誰が作ったのか，誰が作ったものなら信頼するのか?
という単純にデータの同一性にとどまらない問題も完全性を保護するシステムには必要になる

認証を伴う完全性検証
公開鍵暗号をベースにした完全性検証を用いることで”誰が"という情報と"誰の身元の証明" を確認することができる

実用的なデータの完全性検証
OS上のデータは日々更新される
"あるべきデータ"を適切にアップデートする必要がある．
“あるべきデータ”を定義するのは基本的にユーザだが，OSにまかせても良い物もある
OSカーネルやシステムファイル，ブートローダなどは普通ユーザが編集したりしない

WEBアプリケーションの場合は?
ソースコードが同一であれば良い?
HTMLが同じであればよい?
色々あやふやである．

OS/VMレイヤでの改竄検知・保護の代表的な技術
TSSを用いた改竄検知:TMPデバイスを用いたブートストラップからアプリケーションまでの実行時検証，データ/メタデータの改竄検知
セキュアブート:UEFIがOSカーネルの改竄を検知
(アクセス盛業，サンドボックス):OSが提供するユーザ認証とデータのセキュリティ属性を使って意図しない書き込みを某氏

セキュアブート
ハッシュ値は使わず署名を確認しながらブートする技術
ファームウェアが署名を検証するための証明書を持っていなければならない

Win8 secure boot
厳密にいうとUEFIセキュアブートとは少し違う
アンチウイルスを先に起動するなど
ブートローダの署名をUEFIが持っている証明書で検証

アクセス制御・サンドボックスによる改竄検知
OSによるユーザ認証や権限設定がベースとなっているため，OSが信頼できるという前提がある
OSが改ざんされたり正規ユーザで遠隔操作されたりした場合は前提が成り立たない

実用システムにおける完全性検証は運用重点
実用的な改竄検知システムの勘所
1.完全性を検証すべきデータはどれか?
2.いつ"あるべきデータ"をアップデートするか?
3何で"あるべきデータ"であると判断するか?
:最近の流行りはハッシュ値(ダイジェスト)の検証を諦めて署名を検証する方向性で完全性を検証する


Web改竄
Web改竄と呼ばれるもの:webコンテンツが意図せずに書き換えられてしまうこと
インターネットで不正アクセスされたことがまるわかり(企業がこれをされると信用丸つぶれ)

ここ数年はマルウェア配信にも使われる
Drive by downloadと呼ばれる
Gumblar
クライアントアプリの脆弱性を着いてマルウェアを送り込む Explot kit としてパッケージ化されていたりもする

Web改竄の攻撃経路
Network :ドメインハイジャック(管理者情報を使った不正ログインによる書き換えやドメイン名更新忘れなどから起こる)
OS web server application content :管理ユーザの乗っ取り，脆弱性を着いたサーバの改竄

対策
ドメイン管理者ID/passの徹底管理

検知性能の指標
検知率(TP)
正しく改竄を検知した数，割合
誤検知率(FP)
正常な更新を改竄を検知してしまう割合
未検知率(FN)
改ざんされたのに検知できなかった数，割合
正常未検知率(TN)
改竄ではないので検知しなかった数，割合

とにかくちょっとでも変更があるようなら検知側に倒して，誤検知がどうかを別のロジックで判断するほうがよい

悪意を持ったWebPage改竄
予定にない更新
コンテンツを大幅に書き換える(基のコンテンツの跡形もなく消える : 基のコンテンツとの差分を比較してみる)
scriptやiframeなどの制御系のhtmlタグが挿入され，基のコンテンツに無かった外部リソースへのリンクやアクションが挿入される．(script要素に関する変更を検出してみよう)

情報セキュリティ基礎

出会い系サイトの情報漏洩面白すぎる 
議論:なぜ情報漏洩が起きるのか 

人材不足?
質?量? 
守れているのが当たり前 
無防備でも当たり前 
アンチパターンを纏めておくと良い 
これをしたらこうなるってのが分かると幸せ?


ミスが原因 
個人のモラルの問題?
大事なことが分からない 
お金になるから にも関わらず意識が低い 
セキュリティのモラル
ヒューマンエラー 
セキュリティリテラシを教育していこう 
人為的ミスはシステムが補助していくと良い 
企業は対策をしても，お金の面でプラスにはならない(でも流出するとマイナスしかない)

ピオログ 

10年前 あやしいファイルを開かない メールも注意 セキュリティソフト最新にする
でもそれでは完璧にならない
ファイル偽装 
メールを自然にする 
ウィルス対策ソフトは完璧ではない (未知のウィルスにはどうすれば)
偽装サイトからアクセス誘導など

今流行は標的型攻撃 
攻撃者は明確な目的を持って攻撃をしている
ウィルス感染は当たり前 

最近は，事故が起きる前提で，脅威ではなく被害を抑える方向に進んでいる 

議論:メールの添付ファイルのウイルスで被害が起きないようにするためには何をすべき?

そもそも添付ファイルを使わない 
怪しいの基準を学習する 
署名がされていないもの以外はリジェクトするとか 
HTTPSのノリで 

信頼した送信元しか送信しない 
訓練
多重防御 (フィルタリング)
防人(さきもり)@:標的型メール攻撃の無害化対策
メールサーバレベルで被害がありそうな場合は人でチェックする
OKボタンは無意識で押される事が多いので それの考えを詰めると良い 
マニュアルの作成 

解決方法
セキュリティ技術の研究開発 
セキュリティ人材の育成
セキュリティ啓発活動
セキュリテイ人材や製品・サービスを買ってくれること

攻撃検知と機械学習

機械学習とセキュリティ 
大量データとは無縁?

SVM

実習した(色んなパターンを工夫して取らないと結局辛いよね)
SVM:あるグループを2値分類する
次元一つ落としてその次元で分類する．
高次元では計算量が問題になる．
最大の弱点は再計算時の計算量(データを丸呑み出来る分，計算量が膨大になる)
適切なパラメータ設定が出来なければ精度がなまくらになってしまう．

DL使うにしても特徴量が分かってるものでないと辛い 
DLかけてそこそこいいものは出たらしい
パラメータ設定次第(しかも特徴量は自分たちで考えた方が良さげ) 

「‘ OR 1 = 1」
これを1文字ずつ16進数で表す．
更に頻度分析するとZipf’sの法則 

全部記号だけで見る
この頻度情報を順位にして，全部の値で割ると1~0に収まる(割合になる)
さらにこれをRBM(制約付きボルツマンマシン)で段々決める
入力値をどう作るかが問題になる.

例えば ‘ OR スペース = などがどういう頻度で出てくるかの相関を見たりする．
これで入力値をどうするかという話が出来る．

[感想]
めっちゃ有益だった．

特別講演

1.スポーツとテクノロジーをめぐる最近の動向から見えること

NFLウェアラブルセンターを利用して更なるデータスポーツへと進化
:情報用のトラッキングデバイスを選手のショルダーパッドの中に埋め込み，センサで速度・移動距離・移動の加速度などの情報が入手出来る．

プレイヤーのトラッキング
:複数のカメラで位置や高さを記録し，シュートやリバウンドなどのプレー内容と組み合わせてわかりやすく加工したデータを提供する．

近未来のサッカーボールはロボット化
キックスピード回転数方向インパクト可視化 飛行機どう データを取得

2020年に向けて何が変わるのか
スポーツの見せ方が変わる．エンターテイメントへ
(ゲームの原点に戻った見せ方の革新)
スポーツのトレーニングが変わる．(単なる根性論から合理性追求へ)
スポーツと関わりを持つ分野が変わる．(運動や大衆娯楽からより複合的な産業へ )

スポーツに関わる仕事が変わる．(スポーツアナリスト)
例えばスポーツアナリスト(アスリートのパフォーマンス向上に必要なデータや上表収集と分析を担う人材)

2020年大会において守るべき対象は?