テストが週末に迫ってきて焦っています。
用語がまだ覚えきれておらず、色んな認証が混ざったりしていて不安です。

午前2は過去問道場でなんとかなると仮定して、
午後についてここは抑えておきたい用語や知識があれば教えていただきたいです。

いよいよ今週末支援士試験ですね！
混乱しやすい以下の項目を整理、理解するのはいかがでしょうか。

暗号
共通鍵暗号方式(AES、CTR暗号モード)
公開鍵暗号方式(RSA)
ハイブリッド暗号方式
ハッシュ関数(SHA-2、SHA-3、ソルト)

認証
シングルサインオン(よく出るところだけ)
ケルベロス認証(KDC、TGT、ST)
ID連携技術
 SASL(IdP、SP、アサーション、XML)
 OAuth 2.0(認可、アクセストークン、CSRF対策としてstateパラメタ、リプレイ攻撃対策としてノンス、認可コード横取り対策としてPKCE、登場人物含めたシーケンス図フローを確認、誰がパラメタを作ってどこで検証するか)
 OIDC(認証、IDトークン、OAuth 2.0を拡張して認証できるようにした)

PKI関連
メッセージ符号認証(MAC)
デジタル署名
デジタル証明書(サーバ証明書、クライアント証明書)
TLS/SSL通信シーケンス(アクセスしたいFQDNをSNIに記載)

XSS対策
タイプを理解する(反射型、格納型、DOMベース)
恒久対策はサニタイジング(エスケープ処理をする)
Httponly属性は恒久対策にならない
same-originとsame-siteの違いを理解する
same-origin-policyは異なるオリジンのリソースへのアクセスに制約をかける(穴をあけるのにCORSを使う)

CSRF対策
CookieにSameSite属性を指定する(Strict、Lax、Noneの違いを理解する)
Cookieとは別にトークン使用する
再認証(Web決済をするときなど再度パスワード入力をさせる)

ご参考になれば。

「IPAセキュア・プログラミング講座」の内容を読み返してみてください。
1. 脆弱性:ソフトウェアには既知の脆弱性（例えば、SQLインジェクションなど）と未知の脆弱性が存在します。既知の脆弱性には適切な対応を行い、未知の脆弱性には設計や防御策を講じる必要があります。
2. セキュリティ設計の原則:ソフトウェアのセキュリティを確保するために、いくつかの基本原則があります
・メカニズムの単純さ: 設計をシンプルにして、ミスを減らす。
・失敗時の安全性: デフォルトで安全な状態を保ち、明示的に許可された操作のみを許す。
 ・完全な媒介: すべてのオブジェクトアクセスを権限チェックする。
  ・最小権限の原則: 必要最低限の権限のみをユーザーやプログラムに与える。
3. 開発プロセス:
’安全なソフトウェアを作るためには、開発の初期段階からセキュリティを考慮する必要があります。脅威モデルの構築やセキュリティレビュー、テストを開発ライフサイクル全体にわたって実施することが重要です。
・脅威モデリングには「STRIDE」フレームワークが利用されます。これには、なりすまし、改ざん、情報漏洩、サービス拒否攻撃などのリスクが含まれます。
4. セキュリティ機能:ソフトウェア設計には、以下のセキュリティ機能が不可欠です：
・認証: ユーザーやシステムの身元を確認する。
・認可: 適切なアクセス権限があることを確認する。
・暗号化: データ保護のために暗号化を行い、適切な鍵管理と信頼できる暗号アルゴリズムを使用する。
・入力検証と出力エスケープ: すべての入力を検証し、出力をエスケープして、SQLインジェクションやクロスサイトスクリプティング（XSS）などを防ぐ。
・ロギング: モニタリングや監査のために、適切なログを記録する。
5. セキュリティテスト:実装されたセキュリティ対策が効果的であり、脆弱性がないかを確認するために、セキュリティテストが重要です。これには、外部からのブラックボックステストや内部のホワイトボックステストが含まれます。
6. エラーハンドリング:適切なエラーハンドリングにより、エラーメッセージに機密情報が含まれないようにし、システムが安全に停止するようにします。