Security Specializationは2022/5に追加された試験で、ReactiveのProfessional認定の条件の1つ。名前通り、OutSystemsで開発する際のセキュリティ関係の話題に関係する出題がある試験。
試験情報のPDFと一緒にダウンロードできるサンプル問題を解説する。
全部で8問で、この記事では5問目-8問目が対象。
Security Specializationのサンプル問題について解説 1/2(#1-#4)
サンプル問題は、
https://www.outsystems.com/learn/certifications/
の、「Security Specialist」項目のリンク「Exam Details」でダウンロードできる資料から。「Sample Exam」がついている方のファイルが該当する。
5 SQL Injection
ログイン画面に攻撃があり、ログイン情報の代わりに「'1' = '1.」のような入力があった。
という設定で、攻撃の説明として妥当なものはどれか？
明らかにSQL Injection。ユーザー入力をそのままSQLの条件等に使うと、攻撃者に条件を操作したり、別のクエリを実行されたりするもの。よって選択肢Cが正解。
他の選択肢を見ておくと、
A. Distributed denial-of-service：コンピュータやネットワークを使えなくするようなDoS攻撃の一種で、複数のマシンから行われるもの
B. Cross-site request forgery：ログインセッションを持っているユーザーに攻撃をして、攻撃用のリクエストをシステムに行わせる
D. Obfuscation：私が知らないだけで実はそういう攻撃があるのかもしれないが、攻撃ではなくソースコードや実行コードを読みづらくする技術のことだと思う
6 Active Directory認証
エンドユーザーのログインフローについては、認証フローに記載がある。
- SAML2.0, Okta, Azure ADについては、外部の認証ページにリダイレクトされる（外部でログイン後、OutSystemsに戻ってきて、ログインする）
- 統合Windows認証の場合は、ブラウザに統合認証のユーザー認証情報が含まれていれば、それを自動で送信。含まれていなければ、Azure ADの認証ダイアログで認証
- それ以外（デフォルトのOutSystems認証、Active Directory、LDAP認証の場合）は、OutSystemsのログインページでログインする
この問題は3.のケースについてのもの。
このケースではユーザーが認証情報を入力すると、まずOutSystemsのDB（User Entity）に対してアカウント＋パスワードで認証しに行く。デフォルトの認証を構成している場合は、この段階でログインされる。これが失敗した場合は、Active DicretoryかLDAP認証が構成されていれば、そちらに認証に行く、という仕組み。このあたりは、UsersアプリケーションのUser_Login Actionで行われている。
選択肢を順番に見ていく。（カッコ内の訳は適当訳）
A. 「ユーザーの入力した認証情報を暗号ハッシュにかけ、OutSystemsのデータベースに保存された情報と比較する」これは、3.に示した方法の内デフォルトのOutSystems認証の場合を指すので×
B. 「ユーザーは外部のWebページにリダイレクトされてそこで認証。その後OutSystemsのアプリケーションにリダイレクトで戻ってくる」明らかに1のパターン。×
C. 「ユーザーの認証情報は、まずOutSystemsのデータベースに対して検証する。該当するユーザー情報がなければ、構成されたドメインサーバーに対して認証を行う」これが統合Windows認証無しの場合のActive Directory認証の動作。○
D. 「まずブラウザに認証済み情報がないかチェック。あればその情報を自動でサーバーに送る。無ければユーザーは（Active Directoryが表示させるダイアログで）認証情報を入力する。従ってアプリケーションにカスタムログインページがあってもユーザーに表示されない」これは2の統合Windows認証を構成した場合のフロー。×
よって選択肢Cが正解。
7 アクセス制御/権限
アクセス制御/権限の脆弱性からOutSystemsアプリを保護するからの出題。
アクセス制御/権限の脆弱性からアプリケーションを守るのに貢献し「ない」選択肢はどれか。
A. 「特定のユーザーに実行させたくないActionがWidgetに紐づいており、かつそのWidgetを非表示にした場合」。これは妥当ではない。なぜなら、攻撃者がリクエストを無理やり発行させることにより、UI上非表示であってもそのActionを実行させ得るため
B. 「画面を、その画面にアクセスを許可されたRoleの持ち主が利用できる機能だけに限定する」。正しい
C. 「Server Actionを実行する前にRoleのCheck Actionでログインユーザーに必要な権限があることを確認する」。これも正しい。Screen Actionから呼ばれた場合は、そのScreenで許可されたRoleを持つユーザー以外はServer Actionを実行できない。しかし、他の経路で実行された場合は、それだけでは足りないので、明示的なチェックロジックを入れる
D. 「推測できないID (GUID)を使う」。これも正しい。推測できるIDであれば、連続番号を機械的に作って、もしくはあるIDから推測して、攻撃用のIDを用意できてしまう。
というわけで選択肢Aが正解
8 Security Misconfigurationの脆弱性
Security SpecializationではOWASPが公開しているセキュリティ脆弱性とOutSystemsでの対策が試験範囲に含まれている。
この問題は、その中から、（恐らく）Security Misconfigurationを起こしうるものを聞いている。
OutSystemsのサイトに載っているOWASPの記述は2017年のものだが、2021年のものについてのドキュメント：A05:2021 – Security Misconfiguration
この脆弱性は古いソフトウェアを放置したり、デフォルトの設定のまま運用したり、セキュリティに関わる設定を間違ったりすることによって起こる。
以下で順に選択肢を見ていくが、正解の根拠がちょっと不明。
A. 「環境間（開発・QA・本番など）でadminアカウントには違う認証情報を使う」。環境間で同じものを使っていると1環境の情報が漏れると全環境の情報が漏れることになる。よって環境ごとに違う情報を使うとするのは正しい
B. 「システムのドキュメントやAPIのサンプルリクエストをアプリケーションのリソースとして保持しない」。これは問題ないと思うが、サンプル問題についているAnswersでは正解（つまり脆弱性がある）とされている (2022/6/7時点）。余計な情報を持っていると、攻撃者にシステムの仕組みを推測する情報を与えてしまう。上のリンクでもHow to Preventの1つとして『A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.』が挙げられている
C. 「不要なコンポーネント、サンドボックス、テストアプリケーションを削除する」。Bの説明と同じ理由で危険性を下げる
D. 「エラーのスタックトレースをエンドユーザーに表示しない」。スタックトレースの公開はSecurity Misconfigurationの例として挙げられている。使っているソフトウェアの名前とバージョンが漏れればそのソフトウェアの脆弱性も知られてしまう。またスタックトレースから呼出のフローも察知されてしまう。というわけで表示しないのは正しい行動
というわけで、全て脆弱性を下げる選択肢に見える。
現時点では、サンプル問題に付属の回答で正解とされるBが、Security Misconfigurationの脆弱性を作りうるものである理由が不明。後で気づいたら補足する予定。