静的セキュリティテスト ( 機能 3)

の持つセキュリティ要求と実装が明確に定義されることになる。例えば、こうし た作業が発生の例として、認証認可が不要なControllerの確定が挙げられる。認 証認可が不要な場合は、Controllerには該当するコマンドは記述されないが、そ れが意図したものか、記述ミスなのかはコードからは読み取れない。そこで、セ キュリティ要求の形で明示することで、実装コードの背景となる暗黙の仕様を文 書化する事ができる。

Algorithm 1 PEP check.

Require: ACL, S ▷Nav. model

Require: Q ▷Requirements

Require: W ←0 ▷Warning

1: procedureCheckPEP 2: for eachs∈SCdo

3: res1←hasAuthenticationCheck(s) 4: res2←hasAuthorizationCheck(s) 5: res3←hasP olicyDef inition(s) 6: if ¬res1&¬res2&¬∃s∈Qthen 7: W ←W∪N ewW arning(M T1) 8: else if ¬res1&∃s∈Qthen 9: W ←W∪N ewW arning(M T2) 10: else if ¬res1&res3&¬∃s∈Qthen 11: W ←W ∪N ewW arning(M T3) 12: end if

13: if res3&¬res2then

14: W ←W ∪N ewW arning(M Z1) 15: end if

16: end for 17: end procedure

次にNavigation errorの検出方法について述べる。これは遷移の前後でセキュ リティ要求が異なる場合に発生する。具体的には、複数のロールによって共有さ れているView でそのユーザーのロールによって異なる遷移先を指定する必要が ある場合に、その確認とロールに対応したページの生成を忘れている場合である。

RailsにはMVCコードの自動生成機能 (Scaffold) があり、広く利用されている が、セキュリティ要求への配慮がないコードが自動生成されるためにNavigation

errorは発生しやすい。アプリケーション的には脆弱性はないが、通常の使用で権

限エラーが出てしまうのはアプリケーションのバグである。セキュリティ検証モ デルは すべてのViewとController間の遷移と遷移条件、そのセキュリティ要求 を記録しており、前後のセキュリティ要求が異なる場合は、ロールの確認等の適 切な遷移条件が与えられているかチェックを行い、問題がある場合は警告を出す。

最後に、セキュリティ要求の定義が、セキュリティ検証モデル上で矛盾が無い かを検証する。これにはデータフローモデルl を用いる。

一般的には、MVCの構成する各状態は、共通のセキュリティ要求のもとにグルー プを構成している。ただし、異なるセキュリティ要求との間でデータの流れが存 在する場合、それが意図したものなのか、バグなのかを判別したい。ロール定義 だけでは確認が難しい。

図4.3に一例を示す。この場合、C1,V1,M1,S1はセキュリティ要求の高い管理者

Algorithm 2 Navigation check.

Require: R, ACL, S, T ▷Nav. model

Require: ss∈SV ▷Start state

Require: r∈R ▷Role

Require: W ▷Warning

1: procedureCheckNAV(ss, r)

2: for eachtinGetT ransF rom(TV C, ss)do 3: sd←GetDstState(t)

4: ifisV isited(sd, r)then ▷detect infinite loop

5: @ ▷escape

6: else

7: setV isited(sd, r) ▷set flag

8: end if

9: g←GetGuard(t) 10: o←GetOperation(sd) 11: a←GetAsset(sd)

12: res1←EvaluateGuard(g, r, o, a) ▷Trans

13: res2←EvaluateP EP(sd, r) ▷State

14: if res1 =denythen ▷guard: AC1

15: if res2 =denythen ▷end of transition

16: @

17: else ▷inconsistent V and C

18: W ←W ∪N ewW arning(IN)

19: end if

20: else if res1 =allowthen ▷guard: AC1

21: if res2̸=allowthen

22: W ←W ∪N ewW arning(M Z2)

23: end if

24: else if res1 =truethen ▷guard: AC2

25: if res2̸=allowthen ▷improper guard

26: W ←W ∪N ewW arning(IN)

27: end if

28: else if res1 =f alsethen ▷guard: AC2

29: if res2̸=denythen ▷improper guard

30: W ←W ∪N ewW arning(IN)

31: end if

32: else ▷no guard

33: if res2 =allowthen

34: W ←W ∪N ewW arning(IN) ▷FP?

35: else if res2 =denythen

36: W ←W ∪N ewW arning(M Z2)

37: end if

38: end if

39: @CheckNAV(sd, r) ▷recursive call

40: end for 41: end procedure

図4.3: Dataflow modelを使ったポリシー整合性のチェック

が管理しているデータに関する状態である。一方、C2,V2,M2,S2は一般ユーザー のデータに関する状態である。実際のデータフローはModelのAtttibuteレベル で起こる。ロール定義だけではデータのセキュリティレベルはわからないため、セ キュリティ要求で指定したレベルを用いて、データフローを解析する。この例で は、S1(level=5)からV2(level=1)へのデータフローは、 高いレベルから低いレ ベルへのデータフローのため警告となる。意図するものであるなら、Atttibute S1 のレベルを1に、セキュリティ要求のなかで定義することで意図した実装である ことを明示できる。意図しない場合は、該当するコードを削除する。