2023年4月3日月曜日

2023年4月においてクリックジャッキング未対策のサイトはどの条件で被害を受けるか

サマリ

CookieやlocalStorage等でセッション管理しているウェブサイトがクリックジャッキング対策していない場合、どの条件で被害を受けるかを説明する。SameSite属性のないCookieでセッション管理しているウェブサイトは、主要ブラウザのデフォルト設定ではクリックジャッキングの影響を受けない。一方、loaclStorageにトークン類を格納するウェブサイトでは、Google Chrome等のブラウザでクリックジャッキングの影響がある。また、ブラウザの設定を変更した場合の影響についても説明する。

クリックジャッキングとは

クリックジャッキングとは、一言で説明すると「ウェブサイト利用者に意図しないクリック(タップ)をさせる」攻撃です。ウェブサイト上で意図しないクリックを勝手にさせられると、重大な結果になる場合があります。例えば、このURLを閲覧すると、以下のようにTwitterにて「犯行予告を投稿する」画面になり、「ツイートする」を押すと、押した人のアカウントで犯行予告をツイートする結果になります。Twitterのこの機能はウェブインテントと呼ばれます。

このような拙い「攻撃」だと、被害者は画面内容を見た結果ツイートボタンは押さないわけですが、これにiframeを用いた仕掛けを組み合わせて「知らない間にボタンを押させる攻撃」がクリックジャッキングです。具体的には、iframeを用いて、下図のようにボタンを押させるための罠と、Twitter等の掲示板の画面を重ねます。

この際、掲示板を手前に配置してCSS設定により透明にします。一方罠サイトは奥側に配置します。すると、見た目上は罠サイトだけが見えますが、ボタンをクリックすると手前側の掲示板のボタンを押したことになり、ログイン中の利用者のアカウントで意図しない投稿がされます。これがクリックジャッキングです。現実のTwitterはクリックジャッキング対策がされているので、この攻撃は成立しません。

この例では「意図しない投稿」でしたが、これ以外に、設定変更や退会など「クリックだけでできる操作」全てで影響がありえます。

クリックジャッキング対策には、以下のようなレスポンスヘッダを出力することで行われます。

Content-Security-Policy: frame-ancestors 'none';

上図はCSPを用いた対策ですが、伝統的なX-Frame-Optionsヘッダを用いた対策も有効です。

しかしながら、上記対策をしていない場合でも、モダンブラウザでは、iframe内のコンテンツからCookieおよびlocalStorageへのアクセスが制御されていて、クリックジャッキング攻撃ができないケースが多くなっています。
本稿では、モダンなブラウザの利用者がクリックジャッキング被害を受ける条件について説明します。

検証方法

今回は、クリックジャッキングの影響の有無を、iframe内のウェブページがCookieやlocalStorageの値を受け取れるかどうかで判断することにしました。もしもiframe内のページがCookieやlocalStorageにアクセスできない場合、ページはログイン状態にはならず、被害者のアカウントでの投稿や設定変更などはできないからです。
下図は検証環境の模式図です。サイトAがクリックジャッキング脆弱なサイト、サイトBは罠サイトです。

サイトAのログインを模して、CookieやlocalStorage、sessionStorageをセットします(図の左側)。この後サイトBに遷移しますが、サイトB内にiframeがあり、その中にサイトAのページがあります(図の右側)。このiframe内のサイトAのページでCookie、localStorage、sessionStorageの値を表示して、これらの値を受け取れているかを確認します。

CookieのSameSite属性は以下の3種類のものを用意しました。SameSite属性の意味についてはこちらの記事を参照ください。

  • SameSite属性なし
  • SameSite=None
  • SameSite=Lax

SameSite属性なしは伝統的なセッション管理を想定しています。SameSite=Laxの場合、iframe内のコンテンツにCookieは送信されないはずですが、比較のためテスト条件に加えました。

検証結果

検証結果を下表に示します。

結果の要約は下記の通りです。

  • SameSite属性のないCookieでセッション管理しているサイトは全てのブラウザにてクリックジャッキングの被害を受けない
  • localStorageでセッション管理しているサイトは、Google Chrome、Edge、Opera(デスクトップ、Android)のユーザが被害を受ける
  • Brave、Firefox、Safariの利用者はいずれのケースでもクリックジャッキングの被害を受けない

このように、ブラウザのセキュリティ機能の差により、クリックジャッキング被害の条件が変わっています。


各ブラウザのセキュリティ機能

次に、各ブラウザのセキュリティ機能がどのようにクリックジャッキングを防いでいるかを説明します。

Chromium系ブラウザの防御はデフォルトSameSite=Lax

CookieのSameSite属性にてLaxあるいはStrictを指定した場合、iframe内に置かれたページに対してはCookieは送信されません。これはすべてのブラウザに共通の仕様ですが、Chromium系のブラウザ(Google Chrome、Edge、Brave、Opera…)では、SameSite属性のないCookieはSameSite=Laxとして扱われます(参考)。
このため、SameSite=Noneを明示的に設定していないCookieは、iframe内のページには送信されないことになります。SameSite属性は、もともとはCSRF対策を意図した機能と思われますが、クリックジャッキング対策にも効果があります。
デフォルトSameSite=Laxの効果はCookieのみであるため、sessionStorageとlocalStorageには効果が及びません。

※注
SameSite属性のないCookieは、Cookieが生成されてから2分以内であれば、クロスサイトのPOSTリクエストに付与されます(参考)が、iframeの場合はこの2分間の猶予期間はなく、ただちにSameSite=Laxとして扱われます。

Firefoxは2022年1月11日にデフォルトSameSite=Laxを導入しましたが、非互換を理由に直後にキャンセルされました(参考)。現在でも、SameSiteのデフォルトは、SameSite=None相当です。
一方、Firefoxは2022年6月14日に包括的 Cookie 保護(Total Cookie Protection:TCP)と呼ばれる機能を投入しました。TCPはセキュリティ目的というよりはプライバシー保護を目的としたものですが、クリックジャッキング防御にも効果があります。

下図は包括的Cookie保護(TCP)のイメージ図です(引用元)。

従来は一つのCookieの入れ物(cookie jar)をすべてのサイトで共有していました(上図左)が、TCPが有効になるとサイト毎にcookie jarが独立するようになります(上図右)。これだけだと抽象的でわかりにくいので、サイトAがサイトB、サイトCのiframeにて表示されている様子を用いて説明します(下図)。

上図のように、サイトAのCookieは、単独で表示されている場合(左)、サイトBのiframe内で表示されている場合(中央)、サイトCのiframeで表示されている場合(右)で、それぞれ別の値となります。この機能はサードパーティCookieによるトラッキングを防ぐ目的で導入されたものですが、セッション管理のCookieもiframe内では分離・保護されるため、結果としてクリックジャッキングに対する防御として作用します。また、Cookieだけでなく、sessionStorageやlocalStorageもサイト毎に分離されます。

なお、実験による検証の結果、Braveブラウザにも包括的Cookie保護と同様の機能が実装されているようです(sessionStorageの挙動はFirefoxともSafariとも異なりますが、詳細は省略します)。BraveはChromiumベースのブラウザなので、デフォルトSameSite=Laxも実装されています。

Safariの防御機能はITP(Intelligent Tracking Prevention)

Safari(WebKit)にはITP(Intelligent Tracking Prevention)というトラッキング防止機能があります。これにより、結果としてクリックジャッキングも防御されています。
下図は、ITPによりiframe内のページのCookieがどうなるかを模式的に示しています。

サイトAでセットされたCookieは、サイトBにiframeで埋め込まれてもCookieは送信されず、またレスポンスのSet-Cookieも無視されます。すなわち、iframe内ではCookieの送信も受信もされないということになります。

一方、sessionStorageとlocalStorageについては、FirefoxのTCPのような挙動になります。すなわち、サイト毎に分離された形になります。この挙動はWebKitのドキュメントに記載されています。

Partitioned Third-Party Storage
Third-party LocalStorage and IndexedDB are partitioned per first-party website and also made ephemeral.
試訳: サードパーティのlocalStorageとindexedDBはファーストパーティのウェブサイト毎に分離され、またエフェメラル(一時的)なものになります。

すなわち、localStorage等については、iframe等に埋め込まれていた場合、ファーストパーティのウェブサイト毎に別の名前空間になります。
しかし、実験の結果はsessionStorageも上記の分離がなされていました。Safari 16.0まではsessionStorageは分離されておらず、Safari 16.1以降においてsessionStorageもlocalStorage同様のサイト毎の分離がされているようです。私はこの件についてのドキュメントを発見できていませんので、ドキュメントをご存知の方はぜひ教えてください。また、エフェメラルいうのは、ブラウザを終了すると削除されるという意味です。通常localStorageはブラウザを終了しても保持されますが、iframe等のサードパーティで保存されたlocalStorageはブラウザの終了と共に削除されます。一方、FirefoxのlocalStorageはサイト毎に分離されていますが、ブラウザを終了しても、localStorageの値は保持されます。


防御機能を無効化するとどうなるか

ここまで、ブラウザの提供する保護機能により、クリックジャッキング攻撃から防御される仕組みをご紹介しました。しかし、これらの機能は利用者が無効にすることができます。以下、利用者が保護機能を無効にした場合の影響を調べるため、まずはブラウザ毎にセキュリティ機能を無効化する方法を説明します。以下は、セキュリティを低下させる設定なので、検証以外では使用しないことをお勧めします。また試用した後は忘れずに戻しておいてください。

Google Chrome、Edgeの場合

Google Chrome等のChromium系ブラウザにて、デフォルトSameSite=Laxを無効化するには、Windowsの場合レジストリのLegacySameSiteCookieBehaviorEnabledForDomainListにて、無効化するドメインのリストを指定します。参考記事によると、この設定は暫定的なもので将来変更される見込みです。設定例を下図に示します。この設定では、すべてのドメインにてデフォルトSameSite=Laxを無効化しています。危険な設定なので、検証用途以外には使わないでください。


同じ方法でEdgeでも設定可能です。

Firefoxの場合

FirefoxのTCPを無効化するためには、設定|プライバシーとセキュリティから、強化型トラッキング防止機能から、カスタムを選択して、Cookieのチェックを外すか、その右のセレクトボックスで「クロスサイトトラッキングCookie(一番上)」を選択します。


Safari

SafariのITPを無効化するには、Safariの設定からプライバシーを選び、「サイト超えトラッキングを防ぐ」のチェックを外します。


結果

上記の設定変更をした結果を下表に示します。赤字で(*)付きで示した項は設定変更により条件が変わっていることを示します。


考察

前述の設定変更により、以下の状態となりました。

  • ブラウザ側の変更により、ほぼ全ての条件でクリックジャッキングの影響を受けるようになる
  • FirefoxのTCP、およびSafariのITPはプライバシー強化のための機能だが、セキュリティの効果もある
  • SameSite=Lax設定はクリックジャッキング対策としても効果が高い

各ブラウザの設定変更の中で、もっとも現実にありそうなものがSafariのITPの無効化です。「サイト超えトラッキングを防ぐ」でGoogle検索するとトップに表示されるのが、以下のYahoo! JAPANの記事です。

iOS 11以降では、「サイト越えトラッキングを防ぐ」がオン(有効)になっている場合があります。
「サイト越えトラッキングを防ぐ」がオンになっている場合、Cookie(クッキー)がSafari上に残らなくなります。
Yahoo! JAPANでは、複数のサービスでCookieを使用しているため、「サイト越えトラッキングを防ぐ」をオンにしていると、サービス内の機能が限定されるなど、一部のサービスを利用できません。
以下の手順を参考に、「サイト越えトラッキングを防ぐ」機能をオフにしてからYahoo! JAPANのサービスをご利用ください。
iPhone向けSafariで「サイト越えトラッキングを防ぐ」機能をオフにするより引用

しかし、当該の設定変更を行うと、Yahoo!以外のサイトでもセキュリティを弱くする結果になります。このページには以下のような記載もありますが、

注意
「サイト越えトラッキングを防ぐ」機能の設定変更は、お客様ご自身の責任において変更してください。

「お客様ご自身の責任において変更」と書いてありますが、変更による影響は何も説明されていないため、この書き方はいかがなものかという感想を持ちました。


まとめ

  • SameSite属性のないCookieによるセッション管理という伝統的なサイトはモダンなブラウザのデフォルト設定ではクリックジャッキング攻撃の影響はない
  • localStorageにトークン類を保存する実装の場合、Chromium系のブラウザ(Chrome、Edge、Opera)ではクリックジャッキング攻撃の影響がある
  • ブラウザのトラッキング機能を解除するとクリックジャッキング攻撃の影響を受けやすくなる
  • アプリケーション提供者は、ブラウザの設定によらずクリックジャッキングを防御するために、CSPやX-Frame-Optionsによりクリックジャッキング対策を実施すること
  • サイト運営者は、ブラウザの設定変更を促さないこと
  • サイト利用者は、ブラウザの設定を安易に変更しないこと

2023年3月27日月曜日

[書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法

サマリ

ハッキングAPI―Web APIを攻撃から守るためのテスト技法(2023年3月27日発売)を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃(テスト)を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。
本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。

重要事項説明

  • 本書の監修者の一人(洲崎俊氏)と評者は知人関係にある
  • 評者が読んだ書籍はご恵贈いただいたものである
  • この記事のリンクにはアフィリエイトが含まれる

APIセキュリティテストとは何か

まずは、本書の主題である「APIセキュリティテスト」を本書でどのように定義しているかを紹介しよう。以下は、本書p3からの引用である。

APIセキュリティテストは、一般的なペネトレーションテストともWebアプリケーション診断とも異なります。APIが持つ攻撃対象領域(Attack Surface)の幅広さと複雑さのため、多くのペンテスターはAPIセキュリティテストを独自サービスとして位置づけています。

通常のWebアプリケーション脆弱性診断でもAPIのテストは当然含まれるが、APIはウェブアプリケーションからだけ利用されるものではなく、IoT機器などからも呼び出される。この場合、IoTシステムとしてセキュリティテストあるいはAPI単体でのセキュリティテストが行われる。本書で説明されるAPIセキュリティテストは、脆弱性診断というよりはペネトレーションテストである。

APIのペネトレーションテストを業務で経験できるエンジニアは限られていると思うが、例えばバグバウンティプログラムに参加して、公開APIをテストするような機会は、意欲と技量さえあれば誰にでも与えらるし、本書はバグバウンティプログラムに参加するバグハンター向けの注意や心構えについても度々言及している。

本書の構成

ここで、本書の構成について紹介しよう。本書は4つの部、16の章で構成される。ここからも分かるように、本書は非常に広範囲のトピックについて扱っている。

第1部 API セキュリティの原理

「第1部 API セキュリティの原理」では、後述の章立てからもわかるように。Web APIの基礎知識と、0章としてAPIテストのスコープ(範囲)、顧客からテスト許可を取得することの必要性などを説明している。2章 Web APIの解剖学では、RESTful APIに加えてGraphQLについても簡単な説明をしている。JSON/XML/YAML等のデータ形式、APIの認証方式(BASIC認証、APIキー、JWT、HMAC、OAuth2.0…)について説明する。REST APIおよびGraphQLを前提とすることから、Cookieによるセッション管理は本書では取り扱われておらず、そのためかCSRF脆弱性やCookieのSameSite属性に関する説明は割愛されている。

  • 0章 セキュリティテストへの準備
  • 1章 Webアプリケーションの仕組み
  • 2章 Web APIの解剖学
  • 3章 一般的なAPI脆弱性

3章の「一般的なAPI脆弱性」としては以下が紹介されている。概ねOWASP API Security Top 10 2019と重なっているが、3.1 情報漏えいと3.11 ビジネスロジックの欠陥は独自に追加したものである。

  • 3.1 情報漏えい
  • 3.2 オブジェクトレベルの認可不備 (BOLA)
  • 3.3 ユーザ認証の不備
  • 3.4 過剰なデータ露出
  • 3.5 リソース不足とレート制限
  • 3.6 機能レベルの認可不備 (BFLA)
  • 3.7 マスアサインメント
  • 3.8 セキュリティ設定ミス
  • 3.9 インジェクション
  • 3.10 不適切な資産管理
  • 3.11 ビジネスロジックの欠陥

第2部 APIテストラボの構築

  • 4章 API ハッキングラボの構築
  • 5章 脆弱なAPIラボ環境の準備

第2部はAPIテストのための実習環境として、診断ツールと脆弱なAPI環境を準備する。診断ツールとしては、Burp Suite、Postman、Wfuzzが大活躍することになるが、これら以外にOWASP Amass、KiterunnerなどAPIを発見するためのツールも紹介されており興味深い。脆弱なAPI環境としてはcrAPIなど数種を紹介している。また、訳注の形で拙作のBad Todoも紹介頂いていた(APIではなく古典的なWebアプリケーションとして)。

第3部 APIへの攻撃

第3部は、いよいよAPIの実際のテスト(攻撃)を説明する。第3部の章立ては以下の通りである。

  • 6章 APIの検出
  • 7章 エンドポイント分析
  • 8章 認証への攻撃
  • 9章 ファジング
  • 10章 認可への攻撃
  • 11章 マスアサインメント
  • 12章 インジェクション攻撃

まず6章と7章でAPIの検出と分析を行うが、この2章は十分な紙面を使って詳しく説明されている。このあたりが、よくある「ハッカー入門」的な書籍とは異なり、本書が実務的な内容になっていることの表れのように思える。
6章 APIの検出では、OSINT的な手法を活用してAPIを検出する。通常の脆弱性診断ではAPIエンドポイントの情報は開示されるので、このステップは省略されるが、本書でいう「ブラックボックス型テスト」では、APIの検出から始まるのでこのステップが必要になる。

7章のエンドポイント分析は、APIの正常系の仕様を把握するステップであり、ウェブアプリケーション脆弱性診断のサイト巡回(クローリング)に相当する。APIの仕様はドキュメント化されている場合も多いが、そうでない場合、アプリケーション経由のAPI通信をキャプチャすることになる。このステップは本書ではリバースエンジニアリングと表現されている。通信のキャプチャはBurp Suite等の診断プロキシを用いることもできるが、本書では主にPostmanを使用する。Postmanのプロキシ機能(評者は本書を読むまで知らなかった)を用いて、API仕様を明確にする。7章の後半は情報漏洩や過剰なデータ露出等、ファジングを伴わない脆弱性検査を行う。

8章から12章はさまざまな攻撃によるセキュリティテストである。8章の前半はパスワード認証に対する辞書攻撃やパスワードスプレイなど古典的な攻撃だが、Hydraのようなパスワード解析専用ツールではなく、Burp Suite IntruderやWfuzz等のファジング用のツールを使っている。パスワードスプレイの場合、ユーザIDのリストが必要になるが、6章で解説した偵察や7章の過剰なデータ露出脆弱性を利用できるとする。8章の後半は、トークンやJWTに対する攻撃で、ブルートフォースを含む攻撃手法を解説している。

9章で説明されるファジングとは異常なデータをAPIに送信して意図しない結果を引き起こすことである。ファジングにはワイドファジング(広く浅く)とディープファジング(狭く深く)があり、前者にはPostmanのCollection Runnerを用い、後者にはBurp Suite IntruderやWfuzzを用いている。評者はPostmanを使ってはいたが、もっぱらAPIの機能的なテストの目的であり、ファジングに用いる発想がなかったので勉強になった。

10章は認可への攻撃である。認可脆弱性に関しては特に目新しいものではないが、テストの観点とツールの効果的な使い方は興味深い。ここでも、Postmanを効果的に使用している。

11章はマスアサインメントに対する攻撃である。マスアサインメント脆弱性とは、主に更新系のAPIで、「変更できてはいけない項目を変更できる」問題であり、過去のGithubの事例が有名である。例えば、利用者が自身のメールアドレスやパスワードを変更できるのは問題ないが、テーブル上のadmin列をtrueに勝手に変更できたら大問題である。API呼び出しにadmin=trueを追加するだけで意図しないadmin列の更新ができる場合がマスアサインメント脆弱性である。Ruby on Rails 4以降ではStrong Parametersと言う機能によりマスアサインメントに対策している。マスアサインメントのテスト自体は簡単なのだが、問題は「変更できてはいけないパラメータ(先の例ではadmin)」をどう発見するかである。本章では、マスアサインメント可能なパラメータの探索についていくつかの方法を説明している。

12章はインジェクションということで、クロスサイトスクリプティング(XSS)やSQLインジェクションなどが含まれる。有名な脆弱性であるからか、この章の説明は簡潔なものである。12.4.1項で説明されるSQLインジェクション攻撃文字列は、あまり凝ったものではないし、本番環境で試すには危険なものが含まれていて評者はぎょっとした(p304)。だが、直後に訳者による適切なコラム「SQLインジェクションのテストを実施する際の注意と補足(pp305-306)」があり、評者は安心した。もっとも、コラム内の文字列「’||’」や「’+’」もMySQLの場合は危険なので、SQLインジェクション検査は厳重な注意が必要である(参考:とある診断員とSQLインジェクション)。

第4部 実世界におけるAPI攻撃

第4部は、「実世界におけるAPI攻撃」というテーマで、13章はバイパス技術の応用とレート制限テストとして、バリデーションやWAF、APIの利用制限を回避する技術といういかにもハッカー的なテーマ、14章は皆さん大好きGraphQLへの応用、15章では、APIの脆弱性が情報漏洩やバグバウンティでどのように発見されたかを紹介している。

  • 13章 バイパス技術の応用とレート制限テスト
  • 14章 GraphQLへの攻撃
  • 15章 データ侵害とバグバウンティ

本書のすごいところ

本書の眼目は、APIセキュリティテストの方法論に徹底しているところである。それは、APIを検出するところから始まる。種々の検出手法は、APIそのものを探すだけではなく、マスアサインメント可能なパラメータを探す場合にも応用できるもので、この種の解説は非常に貴重なものだ。
また、テストに使うツールの説明も詳しい。筆者は主にBurp SuiteやPostmanなどの汎用的なツールを使い、Burp SuiteのIntruderやPostmanのCollection Runnerによりファジングだけでなく、パスワードに対する辞書攻撃やマスアサインメントのパラメータ探索にも用いる。その他にも多くのツールが紹介されているが、評者には、汎用ツールの使いこなしこそ勉強すべきだと思えた。
さらには、テストに対する心構えや、方針の立て方など、現役のペンテスターならではの知見が学べるところも、本書ならではの価値といえる。

本書で扱ってない内容

本書で扱っていない項目についても紹介しよう。
まず、現在APIの主流であるRESTfulAPIはステートレスだからCookieによるセッション管理は行わないという主張から、Cookie関連の記載は一切ない。これに関連して、以下の項目もない。

  • Cookieに関する説明(例えばSameSite属性を含め、Cookieの言及がない)
  • セッション管理(トークン類の保存場所はlocalStorageかCookieか等)
  • APIのCSRF(Content-Type、CORSとの関連を含むが、そもそもCSRFの言及がない)

また、Web APIの基礎としてJSONなどの説明はあるが、同一オリジンポリシーやCORSの説明はない。
XSSの話題は少し出ているが、Content-Typeの話題はない。例えば、以下のケースは、レスポンスボディの見かけ上はXSSだが、Content-Type: application/jsonなのでJavaScriptは実行されない。この種の話題は、他の本(例えば拙著)で学ぶ必要がある。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 43

{"message": "<img src=x onerror=alert(1)>"}

その他、触れられてないテーマの例として下記がある。

  • JSONP(RESTfulAPIだから関係ない)
  • CSP(API側だから無関係というのは分かる)
  • X-Content-Type-OptionsやHSTSなどのレスポンスヘッダ(侵入とは直接関係がないからか?)
  • 脆弱性の対策方法

注意点

筆者は根っからのペンテスター気質という感じで、例えば、以下のような記載がある(p301)。

プロバイダのAPIがコンテンツを追加したり、そのWebアプリケーションに変更を加える場合、脆弱性が存在しないか探すべきかもしれません。

これに対しては、下記の訳注がついている。

一般に、許可なくサードパーティAPIをテストすることは許されていないケースが多いため、注意が必要です。

また、以下のような記載もある(p115)。

筆者は、Webアプリケーションの存在を発見すると、すぐにNiktoでスキャンを行います。

おそらく文脈的には「セキュリティテストの過程でWebアプリケーションを発見すると…」ということであろうが、Niktoも脆弱性診断ツールの一つではあるので、許可なくNiktoスキャンを行うことは問題がある。

本書の眼目は訳者の知見にある

本書は、本格的なAPIセキュリティテストの書籍の和訳というだけで価値が高いものであるが、次の点において、価値が倍加していると考える。

  • 原書の出版後に利用サイトやツールのバージョンアップ、サイトの閉鎖等に伴う利用法の変更や代替手段の説明があること
  • 豊富な訳注と訳者コラムにより、原書の説明不足や、日本の読者になじみのない一般知識(例えばAcmeの意味)が補足されていること
  • 訳注での参考情報の記載がとても豊富であり、追加の勉強のために役立つこと

したがって、読者が英語に堪能であったとしても、それでもこの和訳を選択する価値は十分にある。また、参考リンクが豊富であることから、買うなら電子版(PDF)が圧倒的にお勧めである。評者はレビューを紙版で行ったが、電子版も購入した。
翻訳はこなれていて、問題となるような箇所はなかった。

本書の使い方

本書のお勧めの活用法は以下のようなものであろう。

  • 4章「APIハッキングラボの構築」と5章「脆弱なAPIラボ環境の準備」に従い実習環境を準備する
  • 各章を読む
  • 章末に示された実習を行う
  • 本書を読むだけでは分からない箇所を訳注の参考文献に従って勉強する

かなり時間がかかるはずだが、それだけの価値は必ずある。

まとめ

  • 本書はAPIセキュリティテストに関する実践的なガイドである
  • ツールの紹介が多いが、読者はツールを能動的に活用する必要があり、そのための情報が本書にはある
  • 訳注および訳者コラムは価値が非常に高く、それだけで訳書を選択する理由になる
  • 買うなら絶対に電子版(PDF)をお勧めする

フォロワー

ブログ アーカイブ