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/)

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

2015/3/7 に[MSakamaki](https://github.com/MSakamaki)氏に声を掛けられれて一緒に AngularJS ES6 リファクタソンを開催しました。

内容は参加者が 2〜3 人のチームに分かれて ES5 で書かれた Angular1.3 ベースの Web アプリを、ES6 でリファクタするという企画です。
ES5 のコードの中にクソコードを仕込んでおいて、ついでにリファクタしてくれるかなーなんて思いながら主催側ですが、一緒にリファクタして結構楽しかったです。

Angular1.3 を ES6 でリファクタするポイントや、書き換えてみての所感とかまとめようと思います。  
(注 今回のコードは実験的な試みです。プロダクションコードに適用するかは自己責任でお願いします。)

[AngularJS ES6 リファクタソン - AngularJs Japan User Group | Doorkeeper](https://angularjs-jp.doorkeeper.jp/events/21008)



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

## Angular1.X 系は ES6 と相性が悪い？？

始めにやってみた感じの所感を先に紹介すると、**ES6 の新機能は非常に魅力的だけど、Angular1.X 系の DI との組み合わせ(特に Modules)が、非常に相性が悪い** と思いました。
残念な部分も含めて ES6 へのリファクタのポイント紹介します。

## 環境周り

ES6 にはまだブラウザ上で動作しない仕様もあるため、Babel を使って ES6 で書いたコードを ES5 へコンパイルしました。また、最近 Babel とセットで使われることが多い jspm を利用ました。

- [Babel · The transpiler for writing next generation JavaScript](https://babeljs.io/)
- [jspm.io - Frictionless Browser Package Management](http://jspm.io/)

リファクタソンの課題はこちらです。

- [MSakamaki/AngularEs6Son](https://github.com/MSakamaki/AngularEs6Son)

こちらがリファクタ  ソンの内容を持ち帰って、私が書き直してみたコードです。今回紹介するコードはこちらのリポジトリにあります。全体を見たい場合はこちらを見てください。

- [mitsuruog/angular-es6](https://github.com/mitsuruog/angular-es6)

## controller

contorller は ES6 の class を使って置き換えます。

(client/app/list/list.controller.js)

```js
export default class ListController {
  constructor(BeanService, RegionsService) {
    this.beans = [];
    this.regions = [];
    this.beanService = BeanService;
    this.regionsService = RegionsService;
    // APIアクセス部分
    // Arrow Functionはthisを固定してくれるので、
    // promiseの中がthisと書けて非常に嬉しい
    this.beanService.query().$promise.then((data) => (this.beans = data));
    this.regionsService.query().$promise.then((data) => (this.regions = data));
  }
  // template側で利用する機能
  delete(id) {
    this.beanService
      .delete({
        id: id,
      })
      .$promise.then(() => {
        this.beanService.query().$promise.then((data) => (this.beans = data));
      });
  }
}
// Strict DI
ListController.$inject = ["BeanService", "RegionsService"];
```

class 内で再利用する Object は一旦`this`に格納します。
`this`の利用頻度が多いですが、普段`controllerAs`で contorller を利用している人にとっては、あまり違和感なのではないでしょうか。
module への登録は次のように行います。

(client/app/app.js)

```js
import ListController from "./list/list.controller";

export var app = angular.module("Es6App", ["ui.router"]);

// controllers
app.controller(ListController.name, ListController);
```

このあたりまでは ES6 の Arrow Functions・Classes・Modules などの新機能を使って Angular1.X 系でもいけるんじゃないかと思います。わたしにもそんなこと思っていた時期がありました。

ES6 の Class と Arrow Functions は本当にいいですね。

## factory

factory も contoller と同様に class を使って置き換えます。

(client/dataservices/beans/beans.service.js)

```js
export default class BeanService {
  constructor($resource) {
    return $resource(
      "http://localhost:8000/api/beans/:id",
      {
        id: "@id",
      },
      {
        update: {
          method: "PUT",
        },
      }
    );
  }
}
// Strict DI
BeanService.activate.$inject = ["$resource"];
```

module への登録は次のように行います。

(client/dataservices/index.js)

```js
import BeanService from "./beans/beans.service";

export var app = angular.module("Es6AppDataServices", ["ngResource"]);

app.factory("BeanService", ($resource) => new BeanService($resource));
```

module 登録の際に factory Class をインスタンス化する必要があります。さらに DI の注入がある場合は、依存関係のモジュールを渡さなければなりせん。
Angular1.X 系の DI の仕組みは、ES6 の Modules とは相性が悪いようです。そこで、Class のインスタンスを返す static な function を追加して次のように改善してみました。

(client/dataservices/beans/beans.service.js)

```js
export default class BeanService {

  constructor($resource) {
    ...
  }

  static activate($resource){
    BeanService.instance = new BeanService($resource);
    return BeanService.instance;
  }

}
// Strict DI
BeanService.activate.$inject = ['$resource'];
```

これで module への登録は少しスッキリします。

(client/dataservices/index.js)

```js
...

app.factory('BeanService', BeanService.activate);
```

## filter

filter も同様に class で置き換えます。

(client/filters/regionName/regionName.filter.js)

```js
export default class regionName {
  constructor() {
    return (input, regions) => {
      let regionName = "";
      angular.forEach(regions, function (region) {
        if (region.id === input) regionName = region.name;
      });
      return regionName;
    };
  }

  static activate() {
    regionName.instance = new regionName();
    return regionName.instance;
  }
}
```

module の登録は factory と一緒なので省略します。

## directive

directive も同じです。

(client/components/amountLabel/amountLabel.directive.js)

```js
export default class amountLabel {
  constructor() {
    // directiveの設定系
    this.templateUrl = "components/amountLabel/amountLabel.html";
    this.restrict = "EA";
    this.scope = {
      amount: "=",
    };
  }

  link(scope, element, attrs) {
    if (scope.amount > 1000) {
      scope.styleClass = "text-info";
    } else if (scope.amount <= 1000 && scope.amount > 500) {
      scope.styleClass = "text-success";
    } else if (scope.amount <= 500) {
      scope.styleClass = "text-danger";
    }
  }

  static activate() {
    amountLabel.instance = new amountLabel();
    return amountLabel.instance;
  }
}
```

module の登録は factory と一緒なので省略します。

## config

Config や router も ES6 の Class で置き換えてみます。

(client/app/app.config.js)

```js
export default class AppConfig {
  constructor($locationProvider) {
    // アプリ共通の設定系
    $locationProvider.html5Mode(true);
  }

  static activate($locationProvider) {
    AppConfig.instance = new AppConfig($locationProvider);
    return AppConfig.instance;
  }
}
// Strict DI
AppConfig.$inject = ["$locationProvider"];
```

(client/app/app.route.js)

```js
export default class AppRouter {

  constructor($stateProvider, $urlRouterProvider) {

    $urlRouterProvider.otherwise('/list');
    $stateProvider.state('app', {
      abstract: true,
      url: '/#',
      template: `<div ui-view="header"></div>
        <div ui-view="contents" class="main"></div>
        <div ui-view="footer"></div>`
    })

	...

  }

  static activate($stateProvider, $urlRouterProvider) {
    AppRouter.instance = new AppRouter($stateProvider, $urlRouterProvider);
    return AppRouter.instance;
  }

}
// Strict DI
AppRouter.$inject = ['$stateProvider', '$urlRouterProvider'];
```

アプリのトップレベルの module への最終的な登録はつぎのとおりです。

(client/app/app.js)

```js
import angular from "angular";
import "angular-ui-router";

import "../components/index";
import "../dataservices/index";
import "../filters/index";
import AppConfig from "./app.config";
import AppRouter from "./app.route";
import ListController from "./list/list.controller";

export var app = angular.module("Es6App", [
  "ui.router",
  "Es6AppFilters",
  "Es6AppDataServices",
  "Es6AppComponents",
]);
// 設定系
app.config(AppConfig.activate);
app.config(AppRouter.activate);
// controllers
app.controller(ListController.name, ListController);
```

## 課題

とりあえず ES6 に置き換えることはできそうですが、テスト周りについての変更点については、まだ検証できてません。
個人的にはテストの spec が ES6 で書けるだけでも嬉しいです！！

- Angular1.X 系で良かった、テスタビリティがどれくらい犠牲にされているか。
  - ngMock
  - カバレッジ測定
  - E2E(protoractor)
- そもそもこの書き方でいいのか・・・

## さいごに

今や最も優れている(？)Angular1.X 系。
2 年後くらいに ES6 が主流になったとき、今の Backbone を見る時に感じるものと同じ感覚を覚えるのではないかと思いました。
また、来年には Angular2 が来ると言われているのですが、1.X 系とは全く別物なんですよねー(白目)。

にしても、いつになったらフロントエンド開発のデファクトが定まるのか、まだまだ JS フレームワークの長い旅は続きそうです。

### 参考

- [Using ES6 with Angular today](http://blog.thoughtram.io/angularjs/es6/2015/01/23/exploring-angular-1.3-using-es6.html)
- [Exploring ES6 Classes In AngularJS 1.x](http://www.michaelbromley.co.uk/blog/350/exploring-es6-classes-in-angularjs-1-x)
- [Writing AngularJS Apps Using ES6](http://www.sitepoint.com/writing-angularjs-apps-using-es6/)
- [Using ES6 Modules with AngularJS 1.3 — GoCardless Blog](https://gocardless.com/blog/es6-angular/)
- [gocardless/es6-angularjs](https://github.com/gocardless/es6-angularjs)
- [lukehoban/es6features](https://github.com/lukehoban/es6features)
- [yoheiMune/es6features(上の日本語  訳)](https://github.com/yoheiMune/es6features)

March, 2015

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

Angular1.X系をES6で書いてみたらちょっと残念だった話〜AngularJS ES6リファクタソンを終えて〜

March, 2015

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

Angular1.X系をES6で書いてみたらちょっと残念だった話〜AngularJS ES6リファクタソンを終えて〜

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