アプリケーション・プログラミング・インターフェース（API）は、アプリケーション同士が通信するための手段です。開発者がソフトウェア・アプリケーションを構築する際に、アクセスしやすい方法でデータの抽出と共有を可能にする手段を提供します。
APIを使用すると、 サイバー攻撃 APIは機密性の高い情報の変換に広く利用されています。認証の脆弱性、暗号化の欠如、論理的な欠陥、安全でないエンドポイントといった脆弱性により、APIは攻撃に対して脆弱になります。
API 実装時のセキュリティ対策不足により発生する主な攻撃には、次のようなものがあります。
中間者攻撃（MITM）
侵入者は機密情報を取得するために、API 交換を含む通信を中継および傍受することにより、通信当事者間のトラフィックを傍受します。
API インジェクション (XSS および SQLi)
コード インジェクション攻撃では、脆弱なソフトウェア プログラムに悪意のあるコードが挿入され、クロスサイト スクリプティング (XSS) や SQL インジェクション (SQLi) などの攻撃が実行されます。
攻撃者は、脆弱なAPI（適切なフィルタ入力とエスケープ出力（FIEO）を実行できないAPI）に悪意のあるスクリプトを挿入することで、エンドユーザーのブラウザを標的としたXSS攻撃を仕掛けることができます。また、APIメッセージに悪意のあるコード（データベースからオブジェクトやレコードを削除するコマンドなど）を挿入することも可能です。
分散型サービス拒否 (DDoS)
分散型サービス拒否（DDoS）攻撃では、複数のシステムが標的のシステム（通常はウェブサーバー）の帯域幅をフラッドさせます。APIに対するDDoS攻撃は、同時接続を大量に送信したり、各リクエストで大量の情報を送信・要求したりすることで、APIのメモリと容量を圧倒しようとします。2017年初頭にFCCウェブサイトに対して発生したDDoS攻撃では、商用クラウドサービスが利用され、コメントシステムに大量のAPIリクエストが送信されました。これにより利用可能なマシンリソースが消費され、人間のコメント投稿者が締め出され、最終的にウェブサイトがクラッシュしました。
DNSハイジャック
ドメイン ネーム サーバー (DNS) ハイジャック (DNS リダイレクトとも呼ばれます) は、DNS クエリが予期せず悪意のあるサイトにリダイレクトされるタイプの攻撃です。
DNSハイジャックの一例としては、インターネットに接続している際に、アクセスしたいウェブサイトから、不要なポップアップや広告が満載の悪質なウェブサイトにリダイレクトされるというケースが挙げられます。この主な目的は、収益を得ることです。
DNSハイジャックは、 フィッシング詐欺 フィッシングでは、攻撃者は被害者を標的にし、支払い認証情報などの機密情報を盗み出そうとします。フィッシングで最もよく見られるシナリオは、正規の支払い処理ウェブサイトを装ったウェブサイトにユーザーを誘導するメールを餌として送信し、そこから情報を盗み出すというものです。
Quick HealではAPIをどのように保護していますか？
HTTP 経由の HTTPS
トランスポート層セキュリティ（TLS）は、インターネット接続のプライバシーを維持し、2つのシステム間で送信されるデータが暗号化され、改ざんされていないことを確認する標準規格です。URLが「HTTPS」（HyperText Transfer Protocol Secure）で始まるウェブサイトは、TLSで保護されているとみなされます。
APIベースのインタラクションにはTLSが不可欠です。トランスポート層の暗号化は、APIのセキュリティを確保するために必須の要素の一つです。TLSがない場合、「中間者攻撃」のリスクは非常に高くなります。当社のAPIでは、特にAPIを公開する際には、TLSとHTTPSの両方を使用しています。HTTPSはHTTPよりも厳格に使用しています。
認証
APIにおけるエンドユーザー（呼び出し元）のIDを確認するには、TLSプロトコルを用いた基本認証を実装できます。ただし、OAuth 2とOpenID Connectはより安全な代替手段です。
URLに情報を公開しないでください
URLに機密情報や脆弱な情報を決して公開しないでください
入力パラメータの検証
リクエストパラメータは、実際のサービス処理ビジネスロジックに到達する前の最初のステップで検証されます。強力な検証チェックを実施し、検証に失敗した場合はリクエストを直ちに拒否します。
Encryption
API 経由で変換する際は、機密情報や個人情報に強力な暗号化を使用することを強くお勧めします。
強力かつ軽量な暗号化アルゴリズムを使用しています – AES256
AES256：
AES (Advanced Encryption Standard) は、米国国家安全保障局 (NSA) が極秘情報を保護するために承認した、初めてかつ唯一の公開暗号です。
これまで、256ビットAES実装に対する攻撃はごくわずかしか報告されていません。そのほとんどはサイドチャネル攻撃（システム上の暗号実装に対する攻撃であり、基盤となる暗号自体に対する攻撃ではありません）でした。AESアルゴリズムは、その設計と鍵長の強度によって保護されており、256ビットの鍵長は極秘情報に最適であると考えられています。データセキュリティに関しては、誰も妥協したくありません。AES-256は現在市場で入手可能な最も安全なデータ暗号化方式のXNUMXつです。
鍵交換アルゴリズム
強力な鍵交換アルゴリズム 認証鍵または暗号化鍵を交換する。ハードコードされた鍵や静的な鍵よりも、この方法を採用すべきです。
秘密鍵の交換には、Diffie Hellman Secured Key-exchange と呼ばれる最も強力な公開鍵交換方式を使用します。
Diffie Hellman セキュア鍵交換:
Diffie-Hellman鍵交換は複雑です。非常に大きな数値と多くの計算が用いられます。Diffie-Hellman鍵交換は、そのセキュリティの基盤として一方向性関数に依存しています。これらの計算は単純で一方向性ですが、逆算するのは非常に困難です。
Diffie-Hellman のいくつかの利点:
- 送信者と受信者はお互いについて事前に知る必要はありません。
- キーが交換されると、安全でないチャネルを介してデータの通信を安全に行うことができます。
- 秘密鍵の共有は安全です。
トークンベースの認証
トークンベースの認証の利点は、ログイン認証情報が脆弱になる可能性を排除できることです。トークンとは、二者間で機密情報をコンパクトかつ自己完結的な方法で送信するために使用される、高度にセキュリティ保護されたデータです。トークンは、ウェブサイトやアプリケーション内など、認証プロセスを強化するためによく使用されます。
私たちは、以下の要素で構成される JWT トークン ベースの通信を使用します。
- 使用されるトークンとアルゴリズムのタイプを定義するヘッダー。
- ユーザーに関する情報やその他のメタデータが含まれるペイロード。
- 送信者の身元とメッセージの信頼性を確認する署名。
URLは
クエリ パラメータの使用を避けているため、URL では機密情報が公開されることはありません。また、URL 経由では情報が公開されません。
入力パラメータの検証
当社では、ビジネス ロジックが実行される前の非常に初期の段階で強力な入力パラメータ検証を行っており、無効な可能性のあるリクエストはすべて拒否します。
セキュリティ vs パフォーマンス
パフォーマンスは機能であり、セキュリティは現代において不可欠な要素です。そのため、どちらか一方を犠牲にすることなく、両方を実現することが非常に重要です。パフォーマンスを犠牲にすることなくこのセキュリティ要件を満たすには、高度なセキュリティ対策を備えた軽量な実装戦略を選択することができます。
プラフラ・プラカシュ・ラナディブとの共著
