最近、僕は良くAngularを触るのですが、今参画している案件ではセキュリティ診断なるものがあるらしいです。
となると、Angularに関してもセキュリティの知識は身に付けておくべきでしょう。
ということで今回は、Angularにおけるセキュリティについてまとめてみました。
Angularのセキュリティ
Angularはサーバサイドではなくフロントサイドなので、セキュリティを過剰に意識しすぎる必要はありません。
ただ、最近はセキュリティにうるさい世の中なので、エンジニアである以上意識してコーディングはするべきです。
Angularがデフォルトで対策しているものは以下の通りです。
- XSS(クロスサイトスクリプティング)
- CSRF(クロスサイトリクエストフォージェリ)
- XSSI(クロスサイトスクリプトインクルージョン)
XSS(クロスサイトスクリプティング)
フロントサイドにおいて、XSSは一番考慮しなくてはならない問題です。
XSS対策において大切なことは、悪意のあるDOMを挿入されないようにすることです。
クロスサイト・スクリプティング。 セキュリティの知識がある方なら一度は聞いたことがあるかもしれません。 ただ、こういったセキュリティ用語は体験できる機会が少ないので、なかなか知識として定着しにくいものです。 ということで今[…]
AngularにおけるXSS対策
Angularは、すべての入力を信頼できない値として処理します。
つまり、DOMへの値挿入はすべて信頼できない値として処理し、サニタイズされます。
<script>タグなど、特殊な文字列を無害化します。
サニタイズ例
|
1 2 3 4 5 |
<h3>Binding innerHTML</h3> <p>Bound value:</p> <p class="e2e-inner-html-interpolated">{{htmlSnippet}}</p> <p>Result of binding to innerHTML:</p> <p class="e2e-inner-html-bound" [innerHTML]="htmlSnippet"></p> |
|
1 2 3 4 |
export class InnerHtmlBindingComponent { // For example, a user/attacker-controlled value from a URL. htmlSnippet = 'Template <script>alert("0wned")</script> <b>Syntax</b>'; } |
テンプレート補完({{}})は自動的に「htmlSnippet」の値をエスケープします。
innerHTMLでは、<script>タグはサニタイズされますが、<b>タグなどはサニタイズされません。
CSRF(クロスサイトリクエストフォージェリ)
Angularは、デフォルトでCSRFの対策がなされています。
HttpClientXsrfModuleのソースコード
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 |
/** * @license * Copyright Google Inc. All Rights Reserved. * * Use of this source code is governed by an MIT-style license that can be * found in the LICENSE file at https://angular.io/license */ import { Injector, ModuleWithProviders } from '@angular/core'; import { Observable } from 'rxjs'; import { HttpBackend, HttpHandler } from './backend'; import { HttpInterceptor } from './interceptor'; import { HttpRequest } from './request'; import { HttpEvent } from './response'; /** * An injectable `HttpHandler` that applies multiple interceptors * to a request before passing it to the given `HttpBackend`. * * The interceptors are loaded lazily from the injector, to allow * interceptors to themselves inject classes depending indirectly * on `HttpInterceptingHandler` itself. * @see `HttpInterceptor` */ export declare class HttpInterceptingHandler implements HttpHandler { private backend; private injector; private chain; constructor(backend: HttpBackend, injector: Injector); handle(req: HttpRequest<any>): Observable<HttpEvent<any>>; } /** * Constructs an `HttpHandler` that applies interceptors * to a request before passing it to the given `HttpBackend`. * * Use as a factory function within `HttpClientModule`. * * */ export declare function interceptingHandler(backend: HttpBackend, interceptors?: HttpInterceptor[] | null): HttpHandler; /** * Factory function that determines where to store JSONP callbacks. * * Ordinarily JSONP callbacks are stored on the `window` object, but this may not exist * in test environments. In that case, callbacks are stored on an anonymous object instead. * * */ export declare function jsonpCallbackContext(): Object; /** * Configures XSRF protection support for outgoing requests. * * For a server that supports a cookie-based XSRF protection system, * use directly to configure XSRF protection with the correct * cookie and header names. * * If no names are supplied, the default cookie name is `XSRF-TOKEN` * and the default header name is `X-XSRF-TOKEN`. * * @publicApi */ export declare class HttpClientXsrfModule { /** * Disable the default XSRF protection. */ static disable(): ModuleWithProviders<HttpClientXsrfModule>; /** * Configure XSRF protection. * @param options An object that can specify either or both * cookie name or header name. * - Cookie name default is `XSRF-TOKEN`. * - Header name default is `X-XSRF-TOKEN`. * */ static withOptions(options?: { cookieName?: string; headerName?: string; }): ModuleWithProviders<HttpClientXsrfModule>; } /** * Configures the [dependency injector](guide/glossary#injector) for `HttpClient` * with supporting services for XSRF. Automatically imported by `HttpClientModule`. * * You can add interceptors to the chain behind `HttpClient` by binding them to the * multiprovider for built-in [DI token](guide/glossary#di-token) `HTTP_INTERCEPTORS`. * * @publicApi */ export declare class HttpClientModule { } /** * Configures the [dependency injector](guide/glossary#injector) for `HttpClient` * with supporting services for JSONP. * Without this module, Jsonp requests reach the backend * with method JSONP, where they are rejected. * * You can add interceptors to the chain behind `HttpClient` by binding them to the * multiprovider for built-in [DI token](guide/glossary#di-token) `HTTP_INTERCEPTORS`. * * @publicApi */ export declare class HttpClientJsonpModule { } |
XSRF-TOKEN.Header name default is
X-XSRF-TOKENXSSI(クロスサイトスクリプトインクルージョン)
Angularは、デフォルトでXSSIの対策がなされています。
Angularのセキュリティ対策で大切なこと
Angularでのセキュリティ対策として大切なことは以下の通りです。
- 最新状態に保つこと
- Angularテンプレートを利用すること
最新状態に保つこと
何でもそうですが、常に最新状態を保つことは大切です。
特に、Angularの場合はバージョンが約半年ほどで更新されるので、最新のバージョンにすることも大切になります。
Angularテンプレートを利用すること
サードパーティ製のものを利用するなど、脆弱性のあるものを利用するのは極力避けましょう。
Angularでできることは多種多様なので、わざわざ脆弱性のあるものを入れる必要はありません。
Angularのセキュリティ公式サイト
Angularのセキュリティ公式サイトはこちらです。
Googleのセキュリティ
AngularはGoogleが開発していることもあり、Googleにおけるセキュリティも確認しておくべきです。
Googleにおけるセキュリティはこちらを参照してください。
おすすめ本
Angularの勉強をするならこの2冊がおすすめです！
まとめ
Angularでコーディングをする際に気を付けるべきポイントは特にありません。
といってもAngularだけで完結するシステムは存在しないため、サーバ側ではセキュリティの考慮は必須です。
また、コーディングが悪ければそれだけセキュリティリスクも増していきます。
常に最新の情報を入手し、セキュリティを考慮したコーディングを心がけましょう。