アクセシビリティ vs セキュリティ ～こんな対策はいらない！～

Transcript

1. 1. アクセシビリティ vs セキュリティ ～こんな対策はいらない！～ 株式会社ビジネス･アーキテクツ 太田 良典
2. 2.  アクセシビリティとセキュリティ  CAPTCHAの問題  バリデーションの問題  セッションタイムアウトの問題 2 今日のお話
3. 3. アクセシビリティと セキュリティ 3
4. 4. 4 デザイニングWebアクセシビリティ
5. 5. セキュリティにからむ内容 5
6. 6. 6 3-1 CAPTCHAの導入でアクセス不能になる ※画面は開発中のものです
7. 7. 7 6-4 入力が困難なフォーム ※画面は開発中のものです
8. 8. 8 6-9 時間切れで作業が継続できなくなるフォーム ※画面は開発中のものです
9. 9. CAPTCHAの問題 3-1 CAPTCHAの導入でアクセス不能になる 9
10. 10. Completely Automated Public Turing test to tell Computers and Humans Apart コンピュータと人間とを判別する 完全自動化された チューリングテスト 10 CAPTCHAとは?
11. 11. ロボットによる自動アクセスの排除 特に、フリーメールサービスの 自動アカウント登録を防ぐため 画像を見せて、書かれている内容を 入力させる手法が主流 11 CAPTCHAの目的
12. 12. 12 CAPTCHAの例 (reCAPTCHA)
13. 13. スクリーンリーダーの場合、画像が あっても内容を理解できることがある 「代替テキスト」が指定されていれば それを読んでくれる 13 画像が見えない人は?
14. 14. <img alt="reCAPTCHA 確認用画像" > 画像の内容とは異なっている これを入力してもパスできない 14 reCAPTCHAの代替テキスト
15. 15. 15 画像が見えても……?
16. 16. 無理ゲー 16
17. 17. 見えないと全くアクセスできない 適切な代替テキストも指定できない アクセスできるようにすることは とても難しい 17 CAPTCHAの問題点
18. 18. セキュリティ上の意義 18
19. 19.  機械によるアカウント登録を防ぐ ► 機械的にアカウントを作成されると スパムメールを大量送信される ► 手動の登録は防がない  アカウント登録の初回に一度だけ CAPTCHAを突破する必要がある 19 フリーメールサービスの場合
20. 20.  機械によるあらしを防ぐ ► 手動のあらしは防がない  コメントを入力するたびに毎回 CAPTCHAを突破する必要がある 20 ブログのコメント欄
21. 21.  機械によるログイン試行を防ぐ ► 手動の試行は防がない  ログインするたびに毎回 CAPTCHAを突破する必要がある ► 2回目からCAPTCHAを出すケースも。 この場合1回は機械試行できる 21 ログインフォーム
22. 22. 本当に必要なのか? 22
23. 23.  CAPTCHAは機械によるアクセスを 妨げるためのもの  認証の機能は持っていない ► 悪意ある攻撃者による 手動のアクセスは防げない ► 「画像認証」と呼ぶのは語弊がある 23 判断のポイント
24. 24. まとめ 24
25. 25.  CAPTCHAはアクセシビリティも ユーザビリティも低下させる  実は必要ないことも多い ► 必要なケースもあるが、多くはない ► 必ずしも安全性は高まらない  採用するときはちゃんと考える 25 CAPTCHAのまとめ
26. 26. バリデーションの問題 6-4 入力が困難なフォーム 26
27. 27. 値が正当(valid)なものであるかを 確かめる処理 27 バリデーションとは?
28. 28. 28 バリデーションの例
29. 29.  そもそも「全角」とは何か  どうやって入力するのか ► 特にスマートフォン 29 全角で入力してください?
30. 30. 30 半角と全角の入力方法を教えてください。
31. 31. 31 全角の入力方法
32. 32. セキュリティ上の意義 32
33. 33. 33 入力バリデーションはセキュリティ対策
34. 34.  ユーザーの入力には「危険な文字」 が含まれることがある ► 例: “ ‘ < など  危険な文字を入力させなければいい ► 全角はだいたいあんしん 34 バリデーションによる対策の発想
35. 35. 本当に必要なのか? 35
36. 36. コメント欄とか どうするの? 36 素朴な疑問
37. 37.  お問い合わせやコメントなどの 入力欄では、自由な入力が必要 ► “ や ‘ が入力できる必要がある ► O‘Reillyの話題を禁止するのか? 37 自由な入力が必要な場合
38. 38.  入力バリデーションは セキュリティ対策になる 「こともある」  しかし本質ではなく、 対策にならないことも多いので、 他の手法で安全性を担保すべき 38 入力バリデーションはセキュリティ対策?
39. 39. 39 再掲
40. 40. まとめ 40
41. 41.  バリデーションは必要だが、 必要以上の制限をすると入力困難に  必ずしも安全性は高まらない ► バリデーションは セキュリティとはまた別の話 ► たまたま重なることはある 41 バリデーションのまとめ
42. 42. セッションタイムアウトの問題 6-9 時間切れで作業が継続できなくなるフォーム 42
43. 43. 43 セッションタイムアウトとは
44. 44.  ログイン後、一定時間経つと 自動的にログアウトする  入力に時間がかかるユーザーは、 入力を終えるまでに ログアウトしてしまうことがある 44 セッションタイムアウトの問題
45. 45. 45
46. 46. 46
47. 47. セキュリティ上の意義 47
48. 48. 48 旧セキュアプログラミング講座 http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a05_03_main.html
49. 49. もし，本人がWWWブラウザを終了さ せずに席を離れた隙に他人が操作をし て当該ASPアプリケーションのページ を呼び出すことができれば，生きてい るセッションに再接続することができ， 各種の情報が漏れてしまうことになる。 49 離席対策 http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a05_03_main.html
50. 50. 本当に必要なのか? 50
51. 51. どのくらい 短くすれば 安全と言えるのか? 51 素朴な疑問
52. 52. セッションの継続が必要で，ユーザに閲覧させる情報・入 力させる項目があまり多くないページでは， Session.Timeoutプロパティに小さな値を設定し，無理の ない範囲でタイムアウトの時間を短くする。 Session.Timeoutプロパティには１分刻みでタイムアウト 時間を設定できる。その最小値は１分である。次の代入文 は，セッション・タイムアウトを３分に設定する例である。 Session.Timeout = 3 52 3分!? http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a05_03_main.html
53. 53.  「ユーザに閲覧させる情報・入力さ せる項目があまり多くないページ」 をどう判断するのか? ► 入力したり読んだりする速度は ユーザーによってまちまち  3分に根拠はあるのか? ► 離席直後に使われたらアウトでは? 53 さらなる疑問
54. 54. 最近の文書では? セッション関連の 注意事項は多数あるが、 セッションの長さには 言及なし 54
55. 55. まとめ 55
56. 56.  セッションが短ければ安全、 という話にはあまり根拠がない (ように思える)  古い文書を信じ続けないこと 56 セッションタイムアウトのまとめ
57. 57. おわりに ～アクセシビリティ vs セキュリティ～ 57
58. 58.  アクセスしやすくする施策は セキュリティのための施策と対立?  高度なセキュリティと アクセシビリティは両立できない? 58 vs セキュリティ?
59. 59.  機密性 (Confidentiality) ► 漏れない  完全性 (Integrity) ► 改ざんされない  可用性 (Availability) ► ちゃんと使える、止まらない 59 セキュリティの三大要素
60. 60.  機密性を保持する最も簡単な方法は サービスを公開しないこと ► 存在しなければ何も漏れない  しかし、それでは意味がない ► きちんと使えることが重要 ► 現実的でない「対策」は セキュリティ研究者も批判 60 使えなければ意味がない!
61. 61. 61 何のためにやるのか?
62. 62. ありがとうございました 62