Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CA API Academy - Web API Security (Web APIセキュリティ)

1,533 views

Published on

Web APIのセキュリティリスクとその対策について説明しています。

Published in: Mobile
  • Celebrated pianist Scott Henderson says: "I am thoroughly impressed by the system's ability to multiply your investment! ♥♥♥ http://t.cn/A6zP2wH9
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes.........ACCESS WEBSITE Over for All Ebooks ..... (Unlimited) ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Download or read that Ebooks here ... ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Doc Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • DOWNLOAD THI5 BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Full EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download doc Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

CA API Academy - Web API Security (Web APIセキュリティ)

  1. 1. API Academy Web APIのセキュリティリスクとその対策とは? CA technologies APIM pre-sales team Tomohiro Kada Rev02.3
  2. 2. 2 アジェンダ Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. • これまでと違ったAPIのセキュリティ対策へのアプローチ • APIを外部へ公開する時のリスク • APIのセキュリティー対策を⾏うためのキーポイント
  3. 3. これまでと違ったAPIのセキュリティ対策への アプローチ
  4. 4. 4 APIを外部に公開する際のセキュリティー これまでのWebとの違い Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  5. 5. 5 APIを外部に公開する際のセキュリティー これまでのWebとの違い:これまでのWebアプリケーション Web/Applicati on Server 商品コード⼀覧 テーブル 商品コードと商品の価格 テーブル 商品コードと在庫情報 テーブル 商品コード⼀覧 Database Connection 指定の商品の商品 コード取得 商品コード 商品の価格 商品コード 在庫の状況と在庫数 Database Connection Database Connection ブラウザ 商品Aの価格と 在庫が知りたい。 HTML HTML Intern et 商品Aの価格は 1,000円で在庫 は5個あります。 境界 Webアプリケーションで必要なデータをバックエン ドのデータベースから取得してユーザがほしい情報 をレスポンスとして返していた。 • 必要なデータ取得時には⼊⼒ データのチェックが実⾏される。 • 認証/認可はWeb Applicationで実装されている。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  6. 6. 6 APIを外部に公開する際のセキュリティー これまでのWebとの違い:APIの場合 API Client 商品コード⼀覧を返すAPI 商品コードから商品の価格 を返すAPI 指定の商品コードの商品が 在庫にあるかどうかと在庫 数を返すAPI 商品コード⼀覧(JSON) API Request 指定の商品の商品 コード取得 /product/54112 商品コード 商品の価格(JSON) /product/54112/stock 商品コード 在庫の状況と在庫数 (JSON) 商品Aの価格は 1,000円で在庫 は5個あります。 商品Aの価格と 在庫が知りたい。 Internet ユーザ Internet 境界 /search/productid API Request API Request API Clientが必要とするバックエンドの コアな機能がAPIとして外部に公開され ることになり攻撃対象となりやすい。 モバイルアプリなどのAPI Client側にデータ⼊⼒のチェックなどの セキュリティーを実装するだけでなくAPIリクエストを受け付ける 側にも正しいセキュリティーの実装が必要。 サードベンダアプリ になる可能性もあり コントロールできな くなる。 APIへの認証/認可をAPIに実装す る必要がある。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  7. 7. APIを外部へ公開する時のリスク
  8. 8. 8 APIを外部へ公開する時のリスク Parameter Risk Identity Risk Man-In-The-Middle(MITM) Risk Brute Force Attack Risk Denial of Service(DoS) Attack Risk Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  9. 9. 9 ①Parameter Risks ⼊⼒されたデータを適切にチェックしないリスク • Webアプリケーションと同じようにAPI Requestで送信された値を適切にチェックしない場合、SQLインジェクション、 クロスサイトスクリプティングなどの攻撃に対して脆弱になります。 Application Server DatabaseHTTP Server API Client http://apitest.com/user_search/1234 SELECT * FROM users WHERE userID = ʻ1234ʼ SQL Injectionの典型例 http://apitest.com/user_search/ʼ%20or%20ʼ1ʼ=ʼ1 SELECT * FROM users WHERE userID = ʻʼ%20or%20ʼ1ʼ=ʼ1ʼ SELECT * FROM users WHERE userID = ʻʼ or ʼ1ʼ=ʼ1ʼ ※1=1は必ず合致するためすべてのユーザー名が返されてしまう。 API ※「%20」は半⾓スペース API Attacker Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  10. 10. 10 APIのパラメータとして不正なものを送る攻撃例 • SQL Injection • Shell Injection • Insecure Direct Object Reference(IDOR) ü URLクエリーなどで渡された値を使ってたとえばデータベースへのクエリーやファイルへのアクセスを⾏う場合、 アクセスしているユーザーの権限以外の情報が⾒えてしまう問題。 • ファジング(不正なパラメータの送信) ü エラーを起こす不正なリクエスト(データを空で投げてみたりStringのところを数字で送ったりするなど)を多く投 げてそのレスポンス(取得できたエラーメッセージ等)からターゲットのAPIが利⽤しているバックエンドシステム の種類やバージョンなどを特定し攻撃する際の材料として利⽤する。 ①Parameter Risks Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  11. 11. 11 ②Identity Risks “API Key”の間違った認識によるリスク • API Keyやアプリに埋め込んだ固有のキーなどをAPIリクエストの際の認証として利⽤するケースがありますがAPI Keyのみを 利⽤したAPIリクエストではAPI KeyがアプリケーションへのリバースエンジニアリングやMITMで不正に取得され、取得した API Keyを利⽤してあたかも正規のアプリケーションがアクセスするようにAPIをリクエストされるリスクがあります。 App API Keyはアプリケーションに対して発⾏されアプリケーションの識別のみに利⽤されることを理解する。 またAPI Keyは漏洩することを前提として考える必要がある。 App • アプリに埋め込まれたAPI Keyはリバースエン ジニアリングなどの⼿法で不正取得できる可能 性がある。 • 通信経路上が暗号化されていない場合やMan- In-The-Middle Attackでキーが不正取得され る可能性がある。 API Key API Key API Request API Request API Request API Keyの認証のみでは不正にAPIが 利⽤される可能性がある API API API Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  12. 12. 12 認証Tokenを利⽤するというアイデアが抜けている • APIリクエストの場合、リクエスト毎にクレデンシャル情報を付与して送信するケースがあり⼀旦、クレデンシャルが不 正取得されるとAPIが不正にリクエストされるリスクが⾼まります。 • 通信経路上でのクレデンシャルの不正取得 • アプリケーションからのクレデンシャルの不正取得 • 内部組織によるクレデンシャルの不正な取得 クレデンシャル (ID/Password) クレデンシャル (ID/Password) クレデンシャル (ID/Password) App クレデンシャルが漏えいした場合、 クレデンシャルを無効にもできるが ユーザがアプリを利⽤できなくなる API Request API Request ②Identity Risks API API API Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  13. 13. 13 パスワードがサードパーティアプリに知られる • APIリクエストのためのクレデンシャルがユーザーからサードパーティーのAPI Client経由で送信される場合、クレデンシャ ルがAPI Clientに不正利⽤される可能性がある。 • 「ユーザ」、「サードパーティーアプリ」、「APIで提供するデータ」の3者が別々に分かれている場合にAPIアクセスのた めのセキュアな権限付与の仕組みが実装できていないためにおこります。 App 不正なアプリケーションの場合、 ユーザークレデンシャル情報が 意図的に漏えいする可能性 外部連携先サービス ①連携先サービスのデータを 取得してアプリで利⽤したい のでパスワードを⼊⼒してく ださい。 ②IDとパスワードの⼊⼒ Attacker App User ②Identity Risks API ※これまではWebアプリのようにアプリとデータは同じ組織・システム で管理されていたがAPI連携でアプリは全く別の組織(サードベンダ、つま りデータの管理者ではない)のケースがあることを認識してAPIアクセスの 認証の仕組みを導⼊する必要がある。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  14. 14. 14 例:Nissan Leaf hacking ②Identity Risks Mobil eApp • ⾃動⾞の操作を⾏うモバイルアプリケーションからのAPIコールをキャプチャすると⾃動⾞オーナーの認証なしに (オーナーからの操作をおこなう権限を適切に付与されずに)、Vehicle Identification NumberのみでAPIをリクエ ストできてしまう状況であった。 • Vehicle Identification Numberと思われるものを無作為に作成してAPIリクエストすると成功するものがあり、さ らにレスポンスからユーザIDまで取得できてしまう状況であった。 API Server Attacker • MITMによりAPIリクエストを取得して解析するとVIN(Vehicle Identification Number)を認証のキーとしてAPIリクエストが成功してしまうことがわかる。 • VIN(Vehicle Identification Number)⾃体が⾃動⾞本体に張り付けられているので誰 でもわかってしまう。 • 推測したVINをランダムに⽣成してリクエストするとレスポンスが成功と返ってくるも のがあり、さらにユーザID情報までも返してしまっていることがわかる。 https://[API Server host]/operationURI?VIN=123456789XYZ ⾃動⾞を操作するモバイルアプリ Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  15. 15. 15 例:Nissan Leaf hacking ②Identity Risks 問題点 1. MITM対策がない • モバイルアプリケーションとAPI Serverの通信をMITMで調査されてしまっていることに問題がある。 Ø クライアント証明書認証と証明書のバリデーションの適切な導⼊ 2. APIリソースのオーナによる権限の付与という考え⽅がない • Vehicle Identification Number(VIN)のみでAPIがアクセスできるようになってしまっている。リモートで操 作される⾃動⾞のオーナ(リソースオーナ)からの権限をもらってアクセスを制御するといった考え⽅がない。 Keyによる認証はあくまでもアプリの識別・認証というレベルでとらえるべき。 Ø OAuthなどのAPIに適したアクセス認証の仕組みの導⼊ 3. 適切な権限コントロールがない • APIリクエストに対して適切なアクセス権限コントロール(認可)の考え⽅がなく⾃由に操作ができてしまう。 Ø OAuthのScopeなどAPIに適したアクセス認可の仕組みの導⼊ 4. ブルートフォースアタック対策がない • 正規のVINを取得するためにランダムに⽣成したVINをトライされても検知・ブロックしない。 Ø ⼀定時間内でリクエスト上限を超えた場合にアクセスをブロックする仕組みの導⼊ Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  16. 16. 16 例:Nissan Leaf hacking ②Identity Risks APIリクエスト時の適切なアクセス付与 App ⾃動⾞の オーナー リソースを持つユーザから適切な範囲でユーザーリソースにアクセスできる権限(トークン)をもらってアプリケーショ ンがAPIをコールするような考え⽅が必要 API Server (ユーザのリソース) 1.モバイルアプリケーションが私の ⾃動⾞を操作したいので権限を渡し てあげてください。 Token 2.⾃動⾞オーナーの認証と 権限の付与をもらって Tokenの⽣成 3.このトークンをつかって ください。 Token 4. API Call Token VIN 5.⾃動⾞オーナーからきちんとAPIコールのための権限 を付与されているか(権限確認)?アプリはこのAPIを コールしてよいか(アプリの認証)?のチェック App ID/secret オーナーの⾃動⾞ Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  17. 17. 17 ②Identity Risks 例: T-mobileの例(2017年10⽉) • 携帯電話ユーザーの契約情報を表⽰するWeb APIがあり、⾃分の契約している携帯電話番号でなく他⼈の番号を URLクエリーに⼊れてWeb APIをコールすると他⼈の契約情報が閲覧できてしまう問題がありました。 https://[API Server host]/XXXXXXX?access_token=ABC&msisdn=123456789 API Server Attacker 他⼈の携帯電話番号をURLクエリに指定 API Request API Response 他⼈の携帯電話番号の契約情報 他⼈の携帯電話番号を指定 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  18. 18. 18 ②Identity Risks 例: T-mobileの例(2017年10⽉) 問題点 • APIアクセスの認可処理ができていない ü Access Tokenを利⽤したトークンベース(OAuth ?)の”APIの認可処理”を実装していたと推測されます。 つまりどのAPIにアクセスできるか?をコントロールできるようになっていたと思われますが、単⼀のAPI 内で認可制御が必要であるにも関わらず実装されていなかった。 ü OAuth2による認可処理はScopeで実装することが可能ですが、アクセスできるAPIの範囲を絞るために scopeを利⽤しても、API内の処理では権限やロールによる処理はできないため、別途、実装する必要があ ります。 • この問題のケースではAccess Token発⾏時にユーザーの属性情報を付与して、実際にリクエストが あった際にAccess Tokenからユーザー属性を取得してアクセス制御するなどの実装⽅法が考えられ ます(URLクエリーで指定された電話番号がAccess Tokenに紐づいたユーザーであるかどうか チェックするなど)。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  19. 19. 19 ③Man-in-the-Middle(MITM) Risks 通信がすべて暗号化されていないリスク • Webアプリケーションと同じように機密性の⾼い通信のみSSLの暗号化を⾏う場合、認証トークン情報やAPIの情報(どん なURLにどんなリクエストがされているのか?)が取得され不正利⽤される可能性があります。 API Token API Request GET /userinfo/search API Response • OAuthなどのトークン情報が不正取得され再利⽤される。 • バックエンドのAPIのURLやリクエスト⽅法が把握され不正利 ⽤される。 ü 取得したトークンで不正リクエスト ü 認証がなければ不正にAPIを利⽤できる。 App SSLでない・暗号化されていない Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  20. 20. 20 SSL化が完全ではないケース1 • APIのすべての通信をSSLで暗号化したとしてもアプリケーション側でサーバ側が提⽰するSSLの公開鍵証明書のバリデー ションをチェックしていない場合、不正なプロキシなどを利⽤してSSLを終端することで通信内容を傍受される可能性があ ります。 App API API Request Proxyが⾃⼰署名の証明書を返しますが、Appが証明書のチェック(正規のCAから発⾏やホスト名 チェック)をしないため、SSLの通信をAppとProxyの間で正常にSSLの通信確⽴させてしまう。 proxy 実際にアプリをSSL Proxy経由でア クセスして通信(リクエスト&レスポ ンス)を傍受し解析。不正アクセス対 象となるAPIの解析で利⽤。 API Response SSLSSL SSLの終端 実際にキャプチャできたAPIリク エスト・レスポンスを確認して APIに脆弱性がないか解析 ⾃⼰署名 証明書 ③Man-in-the-Middle(MITM) Risks Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  21. 21. 21 SSL化が完全ではないケース2 • 提⽰されるサーバ側のSSL公開鍵証明書が信頼できる発⾏機関(CA or 中間CA)であることをきちんとチェックしても不正な プロキシが信頼された発⾏機関で署名されたSSL公開鍵証明書を提⽰する場合があります。 App API API Request 1.SSLを終端して信頼する証明書発⾏機関から取 得した証明書からサーバ側SSLのエミュレート SSL proxy 2.実際にアプリをSSL Proxy経由でア クセスして通信(リクエスト&レスポン ス)を傍受し解析。不正アクセス対象と なるAPIの解析で利⽤。 API Response SSLSSL SSLの終端 シーケンスを確認し てAPIに脆弱性がない か解析 証明書 信頼できる発⾏機 関が署名した証明 書なのでOK 証明書 エミュレートした偽の 証明書 ③Man-in-the-Middle(MITM) Risks Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  22. 22. 22 ④Brute force attack 試⾏テストへの対策が⼗分でないケース • 考えられる組み合わせのデータセットをAPIへバルクで送信して、IDとパスワードの取得を試みたり、バックエンドが持っ ているデータの取得を試みる可能性があります。 API API Request 試⾏する データセット attacker ランダムにデータセットを付与してAPI リクエストを投げつけるプログラム 正規のレスポンス 特定の組み合わせのデータセットで意味の ある正規のレスポンスを返す。 Data set Data set Data set Data set Data set 送信するインプットとして利⽤ TARGET API • クライアントの証明書認証を実装して証明 書をきちんとバリデーションできていない。 • 不正なAPIリクエスト試⾏を検知・ブロッ クしない。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  23. 23. 23 例: Snapchat find_friend exploit API API Request attacker ランダムに電話番号と名前を付与して APIリクエストを投げつけるプログラム 正規のレスポンス • リクエストしたデータセットで、たまたま サービスに登録している電話番号と名前が合 致すれば、その情報を返してしまう。 • レスポンスが返ればその名前と電話番号で登 録されているという1:1のリンクができあがり 個⼈情報の取得が可能になっていた。 Data set1 Data set2 Data set3 Data set4 Data set5 送信するインプットとして利⽤ Snapchatユー ザー検索API 電話番号 名前 090-1234-1234 Yamada Taro 090-1234-1235 Yamada Hanako エラー 試⾏するデータセット ④Brute force attack Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  24. 24. 24 ⑤Denial of Service(DoS) Attack Risk APIに特有のDoSアタックを検知できないケース1 API TARGET API • Attackerが意図的に⼤きくネストされたXML Documentや⼤きなJSONコンテナの深さ(Depth)を持つJSON Documentを 送信することでAPIのXMLやJSONのParserの処理リソース(メモリ)のキャパシティーを超えさせAPIの処理を停⽌させます。 とてつもなく⼤きなネストされたXML Documentや⼤きな JSONのコンテナの深さを持つJSON Documentを送信する attacker <items> <a>….. <b>….. <c>..... <d>.... ..... </items> ⼤きくNestされたXML Document ⼤きくNestされたXML Documentの処理 にリソースが多く利⽤されAPIの処理が遅 くなったり、処理が停⽌する。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  25. 25. APIのセキュリティー対策を⾏うための キーポイント
  26. 26. 26 •Validate Parameters1 •Apply Threat Detection2 •Turn on SSL everywhere with proper configuration3 •Separate Out Identity4 •Use Proven Solutions5 •Simplify API Call from App6 •Alter the incident7 APIのセキュリティー対策を⾏うためのキーポイント Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  27. 27. 27 • リクエストスキーマのチェック Ø 不正なデータの送信を検知するためにはAPIリクエストに対してスキーマのチェックを⾏うことが望ましい。 ü 例)送信されるクエリーや特定のエレメントの値に対してIntegerであるかどうかのチェックを⾏う。 • 正規表現の利⽤ Ø シンプルなHTTPクエリーデータとしてAPIにデータが送信される場合、意図したデータであるかどうかは正規表 現を利⽤して検知させることが効果的。 ü 例)URLクエリーで5桁の数字が送信されている場合、5桁の数字を正規表現で表すと「¥d{5}$」になり、 URLのクエリー部分がこの正規表現にマッチするかどうかをチェックすることで意図した⼊⼒データになっ ているか確認できます。 • エラーの処理 Ø 不正なデータが送信された際のエラー処理を適切に⾏う。Attackerにエラーから推測される情報をなるべく少な くする必要がある。 ••Validate Parameters1 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  28. 28. 28 • ⼤量なAPIリクエストをブロックする仕組み Ø リクエストレートの制限(request/sec)や上限を指定するクオータ(リクエスト上限数)などを利⽤して多量な APIリクエストを検知しブロックするようにする。 • XML/JSONのドキュメントストラクチャーチェック Ø XMLのネストの上限数やJSONのコンテナの深さ(Depth)の上限数などAPI Clientから送信されるXML,JSON Documentのストラクチャのチェックを⾏うことが望ましい。 • リクエストメッセージサイズのチェック Ø 送信されるメッセージサイズが指定サイズより⼤きくないかどうかチェックする。 ••Apply Threat Detection2 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  29. 29. 29 • APIに対して不正アクセスを試みる場合、まずAPIの通信を傍受して解析することから始めるためAPIリクエストを傍受され ない(Man-In-The-Middle Attackされない)ようにする必要があります。 • Man-In-The-Middle Attackを防ぐためSSLの利⽤には下記を注意します。 1. APIのリクエストにはすべてSSLを⽤いる。 2. サーバサイドとクライアントサイドの両⽅で適切なSSLクライアント証明書のバリデーションの実装を⾏う。 ü 相⼿側から提⽰されたSSLクライアント証明書が⾃分が信頼する証明書であるかどうか?をチェックする。 ••Turn on SSL everywhere with proper configuration3 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  30. 30. 30 1. APIでは「ユーザー」、「アプリケーション」、「APIのユーザーデータ」という3者が存在していることを認識して 「ユーザー」はアプリケーションから切りはなして取り扱うことを理解する必要があります。 2. 基本的にはスマートフォンアプリケーションに埋め込んであるキーの情報は外部に公開されるという認識を持つ(漏えい する可能性があるという認識を持つ)。 3. APIにアクセスさせてよいかの”認証”ではアプリのキー情報など”アプリケーションのIdentity”は信頼せず、キー情報に 加えて、ユーザーに認証をさせる必要がある。 4. APIコールにはトークンベースの認証⽅式を導⼊する(APIの認証に最適なOAuth 2.0の導⼊を検討する)。 5. キーの情報を保護する場合はアプリケーションのコーディング内に保存せず、Key chainなどセキュアな⽅法でデバイス にストアする。 6. キーとシークレットはデバイス毎・アプリケーション毎に⽣成するのが望ましい。すべてのアプリで同じキーとシーク レットが共通利⽤されるとそのキーを無効にしたい場合、すべてのデバイス上でアプリが利⽤できなくなる。 7. OAuth 2.0の導⼊に関しては仕組みが複雑であるため信頼できるプロダクトやライブラリなどを利⽤して実装し導⼊する 際には脆弱性を残さないようにする。またプロダクトメーカやライブラリ提供者からパッチの提供があることが望ましい。 ••Separate Out Identity4 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  31. 31. 31 「ユーザー」、「アプリケーション」、「APIのユーザーデータ」の3者の関係 ユーザー APIサーバー (ユーザーのデータ) アプリケーション ユーザーのクレデンシャル アプリケーションのクレデンシャル ⇒あくまでもアプリケーション or 開発者の識別で利⽤ ※これらの3者の関係を認識していないとユーザーのクレデンシャルが漏えいしたりする可能性がある。 ••Separate Out Identity4 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  32. 32. 32 Do not write your own solutions • セキュリティー対策の仕組みは、カスタムで作った仕組みではなくスタンダードなものとして利⽤できる”プロトコル” の利⽤が望ましいです。 • スタンダードなプロトコルを利⽤する場合、事前に利⽤するためのガイドラインや万が⼀、脆弱性が発⾒された際も対 応がしやすいです。カスタムで作ったソリューションではどこセキュリティーの脆弱性が存在しているのかの判断がし にくいです。 ü スタンダードなプロトコルを利⽤する場合も信頼されるところから提供されるライブラリや各社ベンダー製品を 利⽤する⽅が望ましい。万が⼀、プロトコル等に脆弱性が発⾒された場合、情報提供やパッチなどの適⽤がされ るためです。 ••Use Proven Solutions5 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  33. 33. 33 • 内部のAPIをそのまま機能としてモバイルアプリケーションへ公開するのではなく、APIアグリゲーション(APIマッシュアッ プ)を⾏ってモバイルアプリケーションからのAPIコール数を少なくしてあげることが重要です。 API Aggregationの動作イメージ ••Simplify API Call from App6 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  34. 34. 34 API Aggregationの導⼊メリット ü モバイルアプリケーション側でAPIのCALL数を少なくすることで、バックエンドでどういった情報を持っているAPI が存在しているのかを隠匿(隠す)ことができセキュリティーの強度が増します(APIの各機能をアプリからリクエスト させると万が⼀、トラフィックがMITM攻撃によりキャプチャされてしまうと各APIの提供機能が理解され攻撃対象に なりやすい。モバイルアプリに複雑な処理はさせないようにするのがベター)。 ü モバイルアプリケーションにAPIを提供する場合、モバイルアプリケーション側で必要なコーディングの量が減ること になります。 ü 遅延のあるネットワーク経由で複数のAPIをコールする場合、アプリケーションが必要とするデータの取得まで遅延の あるネットワーク経由でAPIをコールするため、アプリケーションの動作・レスポンスが悪化してしまいます。APIア グリゲーションで必要なデータを1回のAPIコールで返すことでアプリケーションの動作・レスポンスを改善すること ができます。 ••Simplify API Call from App6 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
  35. 35. 35 ••Alter the incident7 • APIへの不正なリクエストがあった場合、適切にログへの記録、管理者への通報ができる仕組みが必要です。 • ログや通報にはソースのIPアドレスや認証を⾏っている場合はユーザIDなど必要な情報をログや通報の内容に記録 しておくことが望ましい。 Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.

×