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

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