最近、僕は良くAngularを触るのですが、今参画している案件ではセキュリティ診断なるものがあるらしいです。
となると、Angularに関してもセキュリティの知識は身に付けておくべきでしょう。
ということで今回は、Angularにおけるセキュリティについてまとめてみました。
Angularのセキュリティ
Angularはサーバサイドではなくフロントサイドなので、セキュリティを過剰に意識しすぎる必要はありません。
ただ、最近はセキュリティにうるさい世の中なので、エンジニアである以上意識してコーディングはするべきです。
Angularがデフォルトで対策しているものは以下の通りです。
・XSS(クロスサイトスクリプティング)
・CSLF(クロスサイトリクエストフォージェリ)
・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>タグなどはサニタイズされません。
CSLF(クロスサイトリクエストフォージェリ)
Angularは、デフォルトでCSLFの対策がなされています。
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 { } |
コメントには以下のような記載があります。参考までに。
Cookie name default is XSRF-TOKEN.
Header name default is X-XSRF-TOKEN
XSSI(クロスサイトスクリプトインクルージョン)
Angularは、デフォルトでXSSIの対策がなされています。
Angularのセキュリティ対策で大切なこと
Angularでのセキュリティ対策として大切なことは以下の通りです。
・最新状態に保つこと
・Angularテンプレートを利用すること
最新状態に保つこと
何でもそうですが、常に最新状態を保つことは大切です。
特に、Angularの場合はバージョンが約半年ほどで更新されるので、最新のバージョンにすることも大切になります。
※バージョンアップには脆弱性対策に関するパッチも含まれるため、更新は怠らないようにしましょう。
Angularテンプレートを利用すること
サードパーティ製のものを利用するなど、脆弱性のあるものを利用するのは極力避けましょう。
Angularでできることは多種多様なので、わざわざ脆弱性のあるものを入れる必要はありません。
Angularのセキュリティ公式サイト
Angularのセキュリティ公式サイトです。
■Angularセキュリティ
URL：「https://angular.jp/guide/security」
Googleのセキュリティ
AngularはGoogleが開発していることもあり、Googleにおけるセキュリティも確認しておくべきです。
Googleにおけるセキュリティは以下を参照してください。
■Google Application Security
URL：「https://www.google.com/about/appsecurity/」
おすすめ本
Angularの勉強をするならこの2冊がおすすめです！
まとめ
Angularでコーディングをする際に気を付けるべきポイントは特にありません。
といってもAngularだけで完結するシステムは存在しないため、サーバ側ではセキュリティの考慮は必須です。
また、コーディングが悪ければそれだけセキュリティリスクも増していきます。
常に最新の情報を入手し、セキュリティを考慮したコーディングを心がけましょう。
