「セキュリティとUXの◯◯な関係」で使用したスライドです。 https://connpass.com/event/55559/

1. アクセシビリティvsセキュリティ
～こんな対策はいらない！～
株式会社ビジネス･アーキテクツ
太田良典

2. 自己紹介
2

3. BA
3

4. ウェブアクセシビリティ基盤委員会（WAIC）
4

5. 5

6. 今日のお話
アクセシビリティとセキュリティ
CAPTCHAの問題
バリデーションの問題
セッションタイムアウトの問題
6

7. アクセシビリティとセキュリティ
7

8. デザイニングWebアクセシビリティ
8

9. デザイニングWebアクセシビリティとは?
誰でもアクセスしやすいWebサイトの
制作プロセスについて語る本
 障害の有無や、状況にかかわらずアクセスできる
戦略や設計、ビジュアルデザインも重視
 ガイドラインの解説ではない
 BAが手がけた実例も豊富に収録
9

10. セキュリティにからむ内容
10

11. 3-1CAPTCHAの導入でアクセス不能になる
11
※画面は開発中のものです

12. 6-4入力が困難なフォーム
12
※画面は開発中のものです

13. 6-9時間切れで作業が継続できなくなるフォーム
13
※画面は開発中のものです

14. CAPTCHAの問題
14

15. CAPTCHAとは?
CompletelyAutomated Public Turing test
to tell Computers and Humans Apart
コンピュータと人間とを判別する
完全自動化されたチューリングテスト
15

16. CAPTCHAの目的
ロボットによる自動アクセスの排除
 特に、フリーメールサービスの
自動アカウント登録を防ぐため
 画像を見せて、書かれている内容を
入力させる手法が主流
16

17. CAPTCHAの例(reCAPTCHA)
17

18. 画像が見えない人は?
スクリーンリーダーの場合、画像があっても
内容を理解できることがある
「代替テキスト」が指定されていれば
それを読んでくれる
18

19. reCAPTCHAの代替テキスト
<img alt="reCAPTCHA 確認用画像" >
画像の内容とは異なっている
これを入力してもパスできない
19

20. 無理ゲー
20

21. CAPTCHAの問題点
見えないと全くアクセスできない
適切な代替テキストも指定できない
アクセスできるようにすることは
とても難しい
21

22. セキュリティ上の意義
22

23. フリーメールサービスの場合
機械によるアカウント登録を防ぐ
 機械的にアカウントを作成されると
スパムメールを大量送信される
 手動の登録は防がない
アカウント登録の初回に一度だけ
CAPTCHAを突破する必要がある
23

24. ブログのコメント欄
機械によるあらしを防ぐ
 手動のあらしは防がない
コメントを入力するたびに毎回
CAPTCHAを突破する必要がある
24

25. ログインフォーム
機械によるログイン試行を防ぐ
 手動の試行は防がない
ログインするたびに毎回
CAPTCHAを突破する必要がある
 2回目からCAPTCHAを出すケースも。
この場合、1回は機械試行できる
25

26. 本当に必要なのか?
26

27. 判断のポイント
CAPTCHAは機械によるアクセスを
妨げるためのもの
認証の機能は持っていない
 悪意ある攻撃者による
手動のアクセスは防げない
 「画像認証」と呼ぶのは語弊がある
27

28. まとめ
28

29. CAPTCHAのまとめ
CAPTCHAはアクセシビリティも
ユーザビリティも低下させる
必ずしも安全性は高まらない
 必要なケースもあるが、必要ないことも多い
採用するときはちゃんと考える
29

30. バリデーションの問題
30

31. バリデーションとは?
値が正当(valid)なものであるかを
確かめる処理
31

32. バリデーションの例
32

33. 全角で入力してください?
そもそも「全角」とは何か
どうやって入力するのか
 特にスマートフォン
33

34. 半角と全角の入力方法を教えてください。
34

35. セキュリティ上の意義
35

36. 入力バリデーションはセキュリティ対策
36

37. バリデーションによる対策の発想
ユーザーの入力には
「危険な文字」が含まれることがある
 例: “‘ <など
危険な文字を入力させなければいい
 全角はだいたいあんしん
37

38. 本当に必要なのか?
38

39. コメント欄とか
どうするの?
素朴な疑問
39

40. 自由な入力が必要な場合
お問い合わせやコメントなどの
入力欄では、自由な入力が必要
 “ や‘ が入力できる必要がある
 O‘Reillyの話題を禁止するのか?
40

41. 入力バリデーションはセキュリティ対策?
入力バリデーションは
セキュリティ対策になる
「こともある」
しかし本質ではなく、
対策にならないことも多いので、
他の手法で安全性を担保すべき
41

42. まとめ
42

43. バリデーションのまとめ
バリデーションは必要だが、
必要以上の制限をすると入力困難に
必ずしも安全性は高まらない
 バリデーションはセキュリティとはまた別の話
 たまたま重なることはある
43

44. セッションタイムアウトの問題
44

45. セッションタイムアウトとは
45

46. セッションタイムアウトの問題
ログイン後、一定時間経つと
自動的にログアウトする
入力に時間がかかるユーザーは、
入力を終えるまでに
ログアウトしてしまうことがある
46

47. 47

48. 48

49. セキュリティ上の意義
49

50. IPAセキュアプログラミング講座(2002年版)
50
http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a05_03_main.html

51. セッション盗用
もし，本人がWWWブラウザを終了させずに
席を離れた隙に他人が操作をして当該ASPア
プリケーションのページを呼び出すことがで
きれば，生きているセッションに再接続する
ことができ，各種の情報が漏れてしまうこと
になる。
51
IPA セキュアプログラミング講座 (2002年版) 「セッション盗用」より
http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a05_03_main.html

52. 本当に必要なのか?
52

53. どのくらい
短くすれば
安全と言えるの?
素朴な疑問
53

54. 明確に「こうすべき」とは書かれていないが……
セッションの継続が必要で，ユーザに閲覧させる情報・入力
させる項目があまり多くないページでは，Session.Timeoutプ
ロパティに小さな値を設定し，無理のない範囲でタイムアウ
トの時間を短くする。Session.Timeoutプロパティには１分刻
みでタイムアウト時間を設定できる。その最小値は１分であ
る。次の代入文は，セッション・タイムアウトを３分に設定
する例である。
Session.Timeout=3
54
IPA セキュアプログラミング講座 (2002年版) 「安全のためのセッション管理」より
http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a05_03_main.html

55. 55

56. さらなる疑問
「ユーザに閲覧させる情報・
入力させる項目があまり多くないページ」
をどう判断するのか?
 入力したり読んだりする速度は
ユーザーによってまちまち
3分なら安全なのか?
 離席直後に使われたらアウトでは?
56

57. 2016年の文書では?
57
セッション関連の
注意事項は多数あるが、
セッションの長さには
言及なし

58. まとめ
58

59. セッションタイムアウトのまとめ
セッションが短ければ安全、
という話にはあまり根拠がない
(ように思える)
古い文書を信じ続けないほうが良い
 一般に言われていることが古い話ということも多い
 パスワード定期変更のルールも見直されている
59

60. おわりに
～アクセシビリティvsセキュリティ～
60

61. vsセキュリティ?
アクセスしやすくする施策は
セキュリティのための施策と対立?
高度なセキュリティと
アクセシビリティは両立できない?
61

62. セキュリティの三大要素
機密性(Confidentiality)
 漏れない
完全性(Integrity)
 改ざんされない
可用性(Availability)
 ちゃんと使える、止まらない
62

63. 使えなければ意味がない!
機密性を保持する最も簡単な方法は
サービスを公開しないこと
 存在しなければ何も漏れない
しかし、それでは意味がない
 きちんと使えることが重要
 現実的でない「対策」はセキュリティ研究者も批判
63

64. 何のためにやるのか?
64

65. ありがとうございました
65

66. アンケートにご協力ください
https://goo.gl/JGpnHF