[Ionic](http://ionicframework.com/)で Android アプリを初めて作って公開してみました。

ionic で開発自体は AngularJS ベースということもあり、結構スムーズだったのですが、開発以外の部分で意外とハマったので、その辺り紹介しようと思います。



作ったアプリはこちらです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/hello-ionic-1-1.png)

~~ダウンロードはこちら(現在は配布しておりません)~~

はい、千葉のローカルバスのアプリです。

では、早速本題へ。

## ionic でアプリ scaffold の作成

まず、ionic の概要についてご存知ない方はこちらを参照してください。

[キミは ionic を知っているか？AngularJS+PhoneGap+美麗コンポーネント群！ | HTML5Experts.jp](https://html5experts.jp/canidoweb/7359/)

最初に ionic を使ってアプリ scaffold を作成します。こちらは公式サイトの手順通りに行えばいいと思います。

[Getting Started with Ionic - Ionic Framework](http://ionicframework.com/getting-started/)

```sh
$ npm install -g cordova ionic
$ ionic start <アプリ名> tabs
$ cd <アプリ名>
$ ionic platform add android
$ ionic serve
```

最後の`ionic serve`すると、アプリの webview 部分がブラウザ上で表示されますので、比較的単純なデバックはこちらで行いながら開発していきます。

### パッケージ名の変更

ionic コマンドでアプリ scaffold の作成した場合は、必ず`config.xml`の`<widget id="">`のパッケージ名を変更してください。  
デフォルトでは`com.ionicframework.<アプリ名+乱数>`のような形式になっています。
これは後でストア公開するときのアプリの公開 ID になります。ストア公開後は変更できませんので必ず変更するようにしてください。

```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<widget id="com.mitsuruog.transitbus"
  version="0.0.1" xmlns="http://www.w3.org/ns/widgets"
  xmlns:cdv="http://cordova.apache.org/ns/1.0">
  <name>アプリ名</name>

  ...(省略)

```

## ionic でのアプリ開発

ionic は AngularJS ベースですので、UI 部分の開発は比較的 AngularJS の知識が流用できます。  
今回は、Cordova で利用頻度の高い plugin を AngularJS のモジュールでラップして使いやすくした、`ngCordova`を利用しました。

[ngCordova - Simple extensions for common Cordova Plugins - by the Ionic Framework Team - by the Ionic Framework Team](http://ngcordova.com/)

導入は、ngCordova の bower モジュールをインストールして、トップレベルの AngularJS モジュールで宣言すると利用できます。

```sh
$ bower install ngCordova --save
```

**app.js**

```js
angular.module("yourApp", ["ionic", "ngCordova"]);
```

ngCordova のそれぞれの plugin を利用するためには、別途 Cordova コマンドにて plugin をインストールする必要があります。詳しくは公式サイトを参照してください。

[ngCordova - Document and Examples - by the Ionic Framework Team](http://ngcordova.com/docs/plugins/)

### 実機での実行、デバック(webview)

実機での実行とデバックは、USB ケーブルで Android 端末の実機と PC を接続してから下のコマンドを実行すると、実機上にアプリがビルドされて実行されます。

```sh
$ ionic run android
```

webview デバックについては、Chrome を立ち上げて`chrome://inspect`することで、実機上の WebView を直接インスペクトすることができます。

手前味噌ですが、以前こんな記事を書いてます。

[Android やってる人で ChromeDevtools の Remote Debugging と Screencasting 知らない人は使ってみた方がいいよ！ - I am mitsuruog](http://blog.mitsuruog.info/2013/12/androidchromedevtoolsremote.html)

### ionic テーマのカスタム

ionic のスタイルは`Sass`で出来ていて、テーマ部分は`_variables.scss`に入っています。上書き用の`.scss`を書いてコマンドを実行すると上書きすることができます。

[Writing a Sass Theme | Formulas | Learn Ionic](http://learn.ionicframework.com/formulas/working-with-sass/)

通常は、`./scss/ionic.app.scss`にカスタム用の scss ファイルがあるので、こちらにカスタムする内容を書いていきます。Sass の環境構築についてはこちらを参照してください。

[Ionic CLI - Using Sass | Ionic Framework](http://ionicframework.com/docs/cli/sass.html)

[Sass: Syntactically Awesome Style Sheets](http://sass-lang.com/assets/img/illustrations/glasses-2087d741.svg)

コマンドの例はこちらです。

```sh
$ sass --watch scss/ionic.app.scss:www/css/ionic.app.css
```

これをプロジェクトのトップレベルで実行すると、`scss/ionic.app.scss`を参照して、`www/css/ionic.app.css`に上書き用の CSS を生成してくれます。  
`index.html`で、この CSS を読み込むとテーマをカスタムすることができます。

**index.html**

```html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width"
    />
    <title></title>

    <link href="lib/ionic/css/ionic.css" rel="stylesheet" />
    
    <link href="css/ionic.app.css" rel="stylesheet" />

    ...(省略)
  </head>
</html>
```

あとは、ガツガツ開発していきます。

PC のブラウザ上では正しく表示されているけど、実機だと表示できない・・・  
といった事がよくありますが、気にせず頑張ってください。

その辺りの微妙な不安感を楽しめるかどうかが、ionic と仲良くなるコツです。(うーん、アプリ開発全般で言えることか・・・)

ちなみに、プラットフォームで表示に差異が生じた場合は、CSS を上書きするようなパッチを当てます。  
ionic ではプラットフォームごとに、`platform-android`のような CSS クラスを付与しているので、以下のように追加で CSS を書きます。

```css
.platform-android .hoge {
  color: red;
}
```

### アイコン&スプラッシュイメージ

ionic には、プラットフォームでサイズがまちまちで作成が面倒なアイコンやスプラッシュイメージを、ベースのイメージから自動生成する仕組みが備わっています。

[Automating Icons and Splash Screens | The Official Ionic Blog](http://blog.ionic.io/automating-icons-and-splash-screens/)

`resources/android`フォルダの直下にアイコンであれば`icon.png`、スプラッシュイメージであれば`splash.png`を作成して置いてください。
(ios であれば`resources/ios`に置いてください)

以下のコマンドを実行すると、各プラットフォームごとに画像を生成してくれて、`config.xml`まで書き換えてくれます。超便利。

```sh
$ ionic resources
```

ちなみに、アイコンはこちらから探してきました。

[Clipart - High Quality, Easy to Use, Free Support](https://openclipart.org/)

### google analytics の導入

Web サイト同様にアプリでもユーザーの行動を分析したいので、google analytics を導入します。
ngCordova には GoogleAnalytics 用の plugin がありますが、今回は Android Native SDK v4 対応の別のものを使いました。

[cmackay/google-analytics-plugin](https://github.com/cmackay/google-analytics-plugin)

```sh
$ cordova plugin add com.cmackay.plugins.googleanalytics
```

初期化には少し注意する必要があるので、こちらを参照してください。(使ってるライブラリ微妙に違うけど、雰囲気わかってくれるはず。)

[Using Google Analytics With IonicFramework](https://blog.nraboy.com/2014/06/using-google-analytics-ionicframework/)

View の切り替え時などは、ionic の`ion-view `のライフサイクルイベントをハンドルしてトラッキングします。

**controller.js**

```js
$scope.$on("$ionicView.beforeEnter", function () {
  navigator.analytics.sendAppView("view名");
});
```

どのバス停が人気があるかとか、こっそりトラッキングしてニヤニヤしてます。  
ちゃんと真面目にエラーのスタックトレースも取得してます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/hello-ionic-2-2.png)

> モバイルアプリのトラッキングは Google Analytics 上のアナリティクス設定で新しいプロパティを作成する際に、トラッキングの対象を「モバイルアプリ」にしてください。(普段、Web ページのトラッキングをやっているので、最初うっかりハマってしまいました。)

## 公開準備

アプリの作成が完了しましたので、公開するための準備を行います。

### アプリのビルド

アプリが出来上がったので、リリース用にビルドします。手順は公式サイトを参照してください。

[Publishing your app - Ionic Framework](http://ionicframework.com/docs/guide/publishing.html)

まず、アプリをリリースビルドします。

```sh
$ cordova build --release android
```

これで、`platforms/android/ant-build/MainActivity-release-unsigned.apk`というファイルが生成されます。  
これは unsigned APK(署名なし APK)と呼ばれるもので、このままだと Play store に公開できません。

次に署名を作成します。`keytool`コマンドで private key を生成します。  
この手順は初回 1 回のみです。生成された private key はズッ友なので無くさないように。。。

```sh
$ keytool -genkey -v -keystore <あなたのKeyの名前>.keystore
  -alias <エイリアス名> -keyalg RSA -keysize 2048 -validity 10000

姓名は何ですか。
  [Unknown]:
組織単位名は何ですか。
  [Unknown]:
組織名は何ですか。
  [Unknown]:
都市名または地域名は何ですか。
  [Unknown]:
都道府県名または州名は何ですか。
  [Unknown]:
この単位に該当する2文字の国コードは何ですか。
  [Unknown]:
CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknownでよろしいですか。
  [いいえ]:  y
```

この例だと、10,000 日間有効な 2,048 ビットの RSA の鍵ペアと自己署名型証明書(SHA256withRSA)を生成するらしい。

次に、`jarsigner`コマンドを使って、APK を署名します。

```sh
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1
  -keystore <あなたのKeyの名前>.keystore platforms/android/ant-build/MainActivity-release-unsigned.apk <エイリアス名>

キーストアのパスワードを入力してください:
   追加中: META-INF/MANIFEST.MF
   追加中: META-INF/TRANSITB.SF
   追加中: META-INF/TRANSITB.RSA
  署名中: AndroidManifest.xml
  署名中: assets/_where-is-www.txt
  署名中: assets/www/app/animation.css
  署名中: assets/www/app/app.constant.js

...

  署名中: res/xml/config.xml
  署名中: resources.arsc
  署名中: classes.dex
jarは署名されました。

警告:
-tsaまたは-tsacertが指定されていないため、このjarにはタイムスタンプが付加されていません。タイムスタンプがないと、署名者証明書の有効期限(2042-09-01)後または将来の失効日後に、ユーザーはこのjarを検証できない可能性があります。
```

最後に`zipplugin`コマンドで APK を zip 化します。

```sh
$ zipalign -vf 4 platforms/android/ant-build/MainActivity-release-unsigned.apk <アプリ名>.apk

Verifying alignment of transitbus.apk (4)...
      50 META-INF/MANIFEST.MF (OK - compressed)
    7366 META-INF/TRANSITB.SF (OK - compressed)
   14812 META-INF/TRANSITB.RSA (OK - compressed)
   15959 AndroidManifest.xml (OK - compressed)
...

 2413084 resources.arsc (OK)
 2415741 classes.dex (OK - compressed)
Verification succesful
```

コマンドを実行した直下に apk ファイルができているので、これを play ストアにう p すればいい。

[Android においてなぜ zipalign をやる必要があるのか - Qiita](http://qiita.com/kazuqqfp/items/8eae69e309c6ed75d661)

### ストア公開用アイコン&宣伝画像

まず、ストア公開用アイコンと宣伝画像ですね。正直、デザインセンスや画像編集ツール慣れてない身としては、ここが一番コストがかかったとこです。

画像編集ツールはいろいろ試して悩んだ結果。。。

[Keynote](https://www.apple.com/jp/mac/keynote/)が最も使いやすかったので使っています w。
プレゼンテーション用のソフトなんですが、画像編集も便利
です。

アプリのデバイス枠はめ込み画像はこちらで作成できます。

[Device Art Generator | Android Developers](http://developer.android.com/distribute/tools/promote/device-art.html)

### ストア公開用スクリーンショット

続いてはスクリーンショットですが、個人だと手持ちの端末が 1 機種しかないので、タブレットとかの画像がエミュレータで実行したものを利用します。

エミュレータは Genymotion を使っています。

[Genymotion](https://www.genymotion.com/#!/)

導入はこちら。スクリーンショット撮るときに Android Studio の「Android Device Monitor」を使いますので、一緒にセットアップしておきます。

[Genymotion + Android Studio on Mac - Qiita](http://qiita.com/Sam/items/8d551f575b617fa0be7e)

Genymotion 上に作成した apk ファイルをどうインストールするか、少し悩んだのですが、起動した Genymotion のエミュレータに対して apk ファイルをドラッグするとインストールできます。

エミュレータでのスクリーンショットですが、Genymotion から取得する場合は有料プランの機能のようです。  
そこで、下の記事のように Android Device Monitor から実行中のエミュレータをアタッチすることで、スクリーンショットを取得することにしました。

[android emulator - Capture screenshot in GenyMotion - Stack Overflow](http://stackoverflow.com/questions/21771416/capture-screenshot-in-genymotion)

エミュレータが実行されている状態で Android Device Monitor を起動します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/hello-ionic-3-1.png)

実行中のデバイスが表示されるので、「Screen capture」ボタンをクリックします。キャプチャ用の別画面が立ち上がります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/hello-ionic-3-2.png)

> 他に良い方法あれば教えてください。。。

## 公開

で、いろいろ揃えてストア公開しよう！と思ったら。。。

[Google Play デベロッパー コンソール - 基本事項 - Google Play デベロッパー ヘルプ](https://support.google.com/googleplay/android-developer/answer/6112435?hl=ja)

1 回登録すれば OK です。$25 です。あ、はい。

というわけで無事公開できましたー。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/hello-ionic-3.jpg)

## 最後に

作るのに 4 日。そこから公開まで 3 日くらいかかりました。  
1 日フルで使えた日はないので、実質はもう少し少ないと思いますが、予想より公開準備の部分のコストが掛かったと思います。  
初期の学習コストだと思うので次回以降は半分くらいになると思いますが。。。

普段やっている Web と違って、アプリの世界は結構大変ですね。

いつもエンジニアとしてアプリの機能を開発していますが、このように 1 から自身の手でやってみると、世の中に出ている素晴らしいアプリを作成する裏側でどれくらいの労力が掛かっているか、実感できてよかったです。

特にデザイン周りでは苦労しましたし、デザインスキルを持っている人は本当に素晴らしい。貴重な才能だなと思います。  
また機会があったら作ってみたいと思います。

ではではー。

Androidアプリ開発初心者がionicでアプリを作って公開するまでの7日間の道のり

3/21 に[Web セキュリティ・ハンズオン 〜攻撃して学ぶ、HTML5 のセキュリティ〜](https://firefox-os.doorkeeper.jp/events/21218)に参加してきました。

セキュリティ業界のガチ勢を目の前に、最近の Web のセキュリティについて自分はまだまだ素人だと思い知りました。
いろいろ収穫のあったので忘れないうちにまとめておきたいと思います。

企画・運営していただいた方々、本当にありがとうございました。



## 発見した脆弱性

まず、今回の課題は架空の SNS サービスを題材としたもので、フロント側とサーバー側の両方に脆弱性があるものでした。
私が参加したチームは猛者しかいなかったので、たくさんの脆弱性を見つけることができました。  
(私ではなく、チームのメンバーが発見したものがほとんどです。)

主にフロント側の脆弱性を中心に、思い出せる範囲だけ紹介したいと思います。

### 管理画面への侵入、及び管理者への昇格

> これができた時点で、今回の自分の仕事は終了でした。(by Mala さん)

これは、管理画面に認証がかかっていなかったことがまず悪いのですが、そもそも`test.html`や`admin.html`など容易に推測できる URL になっていることも問題でした。

あまり Web に詳しくない方が、Wordpress に代表されるようなテンプレートを利用する機会も多いと思いますが、そのまま利用した場合、わかる人には管理画面の URL ばれているので危険ですね。
最近は、yeoman のテンプレートで管理側の機能も生成するものは気をつけた方がいいと思います。

管理者への昇格ですが、今回はブラウザの IndexedDB にログイン後のアカウント情報を持つ仕様でした。即 Devtools で書き換えました w。  
こういうセキュアな情報はフロント側では持ってはいけない典型的な例ですね。

### XSS

これは、SNS にコメント入力欄に XSS 脆弱性があるというよくあるパターンなのですが、普通に`<script>alert(1)<script/>`と書いても実行されません。ではどうするかというと、次のように書きます。

```
<img src='#' onerror=alert(1) />
```

[security - XSS attack with javascript in img src attribute - Stack Overflow](http://stackoverflow.com/questions/1798633/xss-attack-with-javascript-in-img-src-attribute)

わざとタグの中でエラーが起きるような記述をして`onerror`を発火させます。同様に`mousemove`とかでもできます。

もう一つ XSS できる方法があって、SNS に投稿する画像の exif に攻撃コードを注入する方法です。

[EXIF Cross Site Scripting, PHP Fun | Barry Shteiman](http://www.sectorix.com/2013/12/02/exif-cross-site-scripting-php-fun/)

この SNS は画像に付加されている撮影カメラの機種(？)を表示する仕様でした。そこに XSS 脆弱性があった訳です。

基本的には`innerHTML`を`textContent`に置き換えるのがいいと思いますが、サービス仕様によっては`<a>`タグは許容したいとかありそうで、なかなか悩ましいですね。

### WebAPI の認証不備

これは、WebAPI 側でトークンなどのチェックを一切行っていないことに起因するもので、API アクセスすると誰でも SNS の内容が盗聴できる状態でした。

また、コメント投稿など API 操作の際に、ユーザー ID をパラメータに含める謎仕様だったので、ローカルプロキシでリクエストを改ざんしたり、
広告用の iframe に CSRF 用のコードを含めることで、容易になりすまし投稿や削除などができる状態でした。

これは、WebAPI の認証はしっかりやることと、フロント側にセキュアな情報は持たせないの 2 点につきます。

手前味噌で恐縮ですが、以前こんな記事書きました。

[JWT(Json Web Token)を利用した WebAPI での Credential の受け渡しについて](http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html)

### ログインに関するもの

ログインに関するものは、まず何回でも失敗できるので、総当たり攻撃ができるということでした。数回失敗すると captcha を表示して相手が機械かどうか確認するのがいいそうです。

それからパスワード忘れ機能で、「好きな色はなに？」と聞いてくるのですが、デフォルトの仕様が「黒」だったので、ユーザー名を知っていればなりすましログインできる状態でした w。

過去には「好きなディズニーキャラクターは？」とういう仕様のサービスが実際にあったとか。。。なかったとか。。。

パスワード忘れの場合は、直接ログインさせるのではなく、メールなどでリセット用のアドレスを送付して 1 つクッションするのが一般的だと思います。  
それから、設問がイケてないと設計側の責任になるケースがあるので、設問自体をユーザーに決めさせるという方法もあるようです。

国によっては聞いてはいけない設問もあるようですので、こちらでチェックされるのがいいそうです。

[Choosing and Using Security Questions Cheat Sheet - OWASP](https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet)

最近は、パスワードや個人情報を持つこと自体がリスクな場合は、認証自体を SNS 認証(OAuth など)に置き換えるのもありだと思いました。

### 連番

今回の SNS はユーザー ID、メッセージなどほとんどが連番で予測可能でした。  
もう、連番のような推測可能な情報を Web で公開すること自体が脆弱性のような気もします。予測しにくいランダムな文字列を設定するように心がけたいですね。

たまに見過ごされがちなのが、投稿画像(動画)などの静的ファイルが連番になっている件で、他人に見られたくない画像が URL を予想して表示できる状態でした。

それと、削除された画像の扱いについてで、サービスによっては一定期間保管する(努力義務？)のようなものがあるそうで、そうした場合、Web からアクセスできない削除用フォルダのようなところに移動させたほうが良いそうです。

### iframe の postMessage

今回、認証用のログインダイアログが別ドメインの iframe になっていて、結果を postMessage で親画面に送っていたのですが、
postMessage の targetOrigin が指定されていないため、悪意のあるページにこの認証ダイアログが iframe が組み込まれると、認証後の情報をすべて抜き取られてしまいます。

ユーザーをあたかも正規サイトのような罠サイトに誘導して、ログインを促してセキュアな情報を抜き取る例の手口ですね。おー怖っ。

このことは、MDN 読めば書いてあるのですが普段から脅威に気づいていないと読み飛ばしてしまいそうです。  
新しい機能を利用する場合は、セキュリティに関する留意点を確認すること。

[window.postMessage セキュリティに関すること- Web API インターフェイス | MDN](https://developer.mozilla.org/ja/docs/Web/API/Window/postMessage#Security_concerns)

### Cordova(WebView の XSS)

こ、これは、恐ろしかった w。

XSS の続きなんですが、XSS の攻撃コードに Cordova のプラグインをコールするコードを設定すると、ネイティブの機能が呼び出されるという類のものです。

例）バイブを動作させるコード

```
<img src="a" onerror="navigator.vibrate(100)">
```

特に、最近はハイブリッド開発プラットホームが増えてきて、JS からネイティブの機能を操作ようになっているのですが、
そうなると今までの XSS がネイティブコードに対する脅威に昇格するので、今まで以上に XSS について注意する必要があると思いました。

XSS をさせないのが一番だと思いますが、開発中にちょっと試してインストールしたような、不要なプラグインは気付いたら削除するべきですね。
あと、万が一何かあった場合は、Webview から外にデータは流れないようにするべきだとおもいました。

[Crosswalk - xwalk_hosts](https://crosswalk-project.org/documentation/manifest/xwalk_hosts.html)

[Crosswalk - Content security policy](https://crosswalk-project.org/documentation/manifest/content_security_policy.html)

ふうふう。。。

## 大事なこと

まず、今回の課題は架空の SNS サービスを題材としたもので、フロント側とサーバー側の両方に脆弱性があるものでした。  
それぞれ脅威に対する対策については少し異なる部分もあると思うのですが、自分なりに感じた脅威に対する対策(心構え？)としては共通するものがあったかなと思います。

- 意図しないコード(人)を侵入させないこと。
- 意図しないコードを実行させないこと。
- もし、意図しないコードが実行されたとしても、外部に情報が漏れないこと。

フロント側の対策としては XSS を中心に昔からよく言われている対策を進めていけばいいと思うのですが、次々と新しいクロスプラットフォームが発表され、HTML の新しいタグや API が追加されるような変化が激しい状況下で、日々脅威となるポイントは増えているんだなと思いました。

## 最後に

昔から利便性とセキュリティは相反するものだとよく言われてきますが、
Web をより使いやすくするために追加された新機能や手法が新たな脅威を生む構図があり、なかなか考えさせられるものがありました。

いくつか攻撃コードの中には知っている手法もあったのですが、やはり知っているのと実際に攻撃してみたでは全く感じ方が異なりますね。  
このように実際に攻撃の実習と通して、Web セキュリティについて実践的に学べる場は本当に貴重だと思いました。

多くの企業システムに関わることが多いエンジニアとして、このような脅威があること実際の開発現場にて啓蒙していき、
より安全な Web システムを作るために努力していきます的な優等生コメントで締めたいと思います。

企画・運営していただいた方々、本当にありがとうございました。  
思いは確かに伝わりました。

### 参考資料

- [安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構](http://www.ipa.go.jp/security/vuln/websecurity.html)
- [HTML5 を利用した Web アプリケーションのセキュリティ問題に関する調査報告書](https://www.jpcert.or.jp/research/html5.html)
- [Android セキュリティ勉強会～ WebView の脆弱性編～(PDF)](https://ierae.co.jp/uploads/webview.pdf)
- [HTML5 Security Cheatsheet(mala さんに教えていただいた、xss の例がいっぱいのってるサイト)](https://html5sec.org/)

Tag: cordova

Androidアプリ開発初心者がionicでアプリを作って公開するまでの7日間の道のり

Webセキュリティ・ハンズオン〜攻撃して学ぶ、HTML5のセキュリティ〜に参加してみた話

Tag: cordova

Androidアプリ開発初心者がionicでアプリを作って公開するまでの7日間の道のり

Webセキュリティ・ハンズオン 〜攻撃して学ぶ、HTML5のセキュリティ〜に参加してみた話

Webセキュリティ・ハンズオン〜攻撃して学ぶ、HTML5のセキュリティ〜に参加してみた話