備忘録 〜セキュリティ〜

こんばんは、うさです。 本日は、セキュリティについての書籍を読んでまとめていきます。 今回参考にさせて頂いた書籍はこちら。

第1章 Webアプリケーションの脆弱性とは

アプリケーションのバグにおいて悪用ができてしまうものを脆弱性(セキュリティバグ)と呼ぶ。 →この脆弱性があってはいけない理由
  1. 経済的損失
    • 利用者が受けた金銭的損失の補填、補償
    • 迷惑料として配る金券等の費用、配送料
    • Webサイト停止による機会損失
    • 信用失墜による売上の減少
  2. 法的な要求: Webサイトの安全対策を要求している法律として、「個人情報の保護に関する法律」があり、 5000件を越える個人情報を保持する事業者は個人情報取扱事業者として安全管理措置を講じる義務がある
  3. 利用者が回復不可能なダメージを受ける場合がある: 利用者の個人情報が漏洩した場合、元の状態に戻すことは不可能である。金銭的に解決は出来ても精神面の解決はできない。
  4. Webサイト利用者に嘘をつくことになる: 多くのWebサイトは安全性をうたっている。ここで脆弱性があると安全性に大きく影響をする。
  5. ポットネットワーク構築に荷担する: サイトを閲覧した利用者のPCがボットに感染し、それにより攻撃者の指令を受けて操作されてしまう可能性がある。 ボットネットワークに組み込まれたPCは迷惑メール送信やDDoS攻撃に荷担する。 また、ボットからサーバーに対して攻撃されることもある。
では、脆弱性が生まれる理由とは・・・
  1. バグによるもの→ セキュリティに無関係なところで発生し、アプリケーション全体に影響が及ぶ (例)SQLインジェクション、クロスサイト・スクリプティング等
  2. チェック機能の不足によるもの→ セキュリティ上のチェックが甘いことにより発生し、アプリケーション全体に影響が及ぶ (例)ディレクトリ・トラバーサル脆弱性等

第2章 自習環境のセットアップ

この章では仮想的にLinuxサーバーが動作する環境を作り、Webサーバーに見立てての実習のための環境設定を行っているので、割愛する。

第3章 Webセキュリティの基礎 〜HTTP、セッション管理、同一生成元ポリシー〜

3-1 HPPTとセッション管理

HTTPを学ぶ理由:Webアプリケーションの脆弱性には、Web固有の特性に由来するものがあるため ブラウザは、サーバーへ要求としてHTTPリクエスト(リクエストメッセージ)を送信し、サーバーはブラウザへの返信としてHTTPレスポンス(レスポンスメッセージ)を返す。 リクエストメッセージには「Referer」というヘッダが付く場合がある。 これが役立つ場合は、セキュリティ確保を目的として積極的にチェックする場合であり、 反対に問題になる場合は、URLが秘密情報を含んでいる場合。 <GETとPOSTの使い分け> リクエストメッセージの1行目はリクエストラインと呼ばれ、「GET」と「POST」が存在する。 使い分け方としては、
  • GETメソッドは参照(リソースの取得)のみ用いる
  • GETメソッドは副作用がないことが期待される
  • 秘密情報の送信にはPOSTメソッドを用いること
また、POSTで送信すべき理由としては、
  • URL上に指定されたパラメータがReferer経由で外部に漏洩する
  • URL上に指定されたパラメータがアクセスログに残る
上記をまとめると以下の中で1つでも当てはまる時はPOSTで、1つも当てはまらない時はGETを利用すべき
  • データ更新など副作用を伴うリクエストの場合
  • 秘密情報を送信する場合
  • 送信するデータの送料が多い場合
<hiddenパラメータ> 利用者の入力した値はhiddenパラメータとしてHTMLソース上に記述される そして、このhiddenパラメータは書き換え可能である。 メリットとしては、書き換え可能であると記述したが、情報漏洩や第三者からの書き換えに対しては堅牢である。 <クッキーとセッション管理>
  • セッション管理:アプリケーションにおいてログインした状態をサーバー側で覚えておくこと
  • クッキー:サーバー側からブラウザに対して「名前=変数」の組を覚えておくように指示するもの
クッキーはアプリケーションデータを保持する目的でクッキーに値を入れることはあまり行われない。 その理由は、
  • クッキーが保持できる値の個数や文字列長には制限がある
  • クッキーの値は利用者本人には参照・変更できるので、秘密保持の格納には向かない

3-2 受動的攻撃と同一生成元ポリシー

Webアプリケーションに対する攻撃は、能動的性攻撃と受動的攻撃に分類される。
  • 能動的攻撃:攻撃者がWebサーバーに対して直接攻撃すること。
  • 受動的攻撃:攻撃者がサーバーを直接攻撃するのではなく、Webサイトの利用者に罠を仕掛けることにより、罠を閲覧したユーザを通してアプリケーションを攻撃する手法。
『正規サイトを悪用する受動的攻撃』 以下の順で攻撃される
  1. 攻撃者が正規サイトを攻撃してコンテンツに仕掛けを仕込む
  2. 仕掛けられた正規サイトを利用者が閲覧する
  3. マルウェア感染などがおこる
この手法の攻撃者のメリットは、
  • 罠サイトに誘導する手間がいらない
  • 正規サイトは利用者が多いので被害が拡大する可能性が高い
  • 正規サイトの機能を不正利用することにより攻撃者にメリットが得られる
  • 利用者の個人情報を盗むことにより攻撃者にメリットが得られる
この手法は以下の4つがよく用いられる
  • FTPなどのパスワードを不正入手してコンテンツを書き換える
  • Webサーバーの脆弱性をついた攻撃によりコンテンツを書き換える
  • SQLインジェクション攻撃によりコンテンツを書き換える
  • SNSなどの利用者が投稿できるサイト機能をクロスサイト・スクリプティング脆弱性を悪用する
『サイトをまたがった受動的攻撃』 以下の順で攻撃される
  1. 利用者が罠サイトを閲覧する
  2. 罠サイトから、仕掛けを含むHTMLをダウンロードする
  3. HTMLの仕掛けが発動して正規サイトに攻撃のリクエストを送信する
  4. 正規サイトからJavaScriptなどの仕掛けを含むレスポンスが返る
では、ブラウザはどのように受動的攻撃を防ぐのか サンドボックス:プログラムができることに制限があり、悪意のあるプログラムを作ろうとしても利用者に被害が及ばないように配慮されている 一般的に、以下の機能が制限される
  • ローカルファイルへのアクセスの禁止
  • プリンタなどの資源の利用禁止
  • ネットワークアクセスの制限(同一生成元ポリシー)
上記に記載した「同一生成元ポリシー」とは、JavaScriptによるサイトをまたがったアクセスを禁止するセキュリティ上の制限である。 同一生成元である条件として、
  • URLのホストが一致している
  • スキーム(プロトコル)が一致している
  • ポート番号が一致している
ブラウザは同一生成元ポリシーにより受動的攻撃を防止しているが、アプリケーションに脆弱性があると受動的攻撃を受ける場合がある。

第4章 Webアプリケーションの機能別に見るセキュリティバグ

4-1 Webアプリケーションの機能と脆弱性の対応

まずは、以下にWebアプリケーションでよく用いられる処理と混入しやすい脆弱性を示す。
  • HTMLへの出力→クロスサイト・スクリプティング
  • HTTPヘッダの出力→HTTPヘッダ・インジェクション
  • SQLの呼び出し(発行)→SQLインジェクション
  • シェルコマンドの呼び出し→OSコマンド・インジェクション
  • メールヘッダ及び本文の出力→メールヘッダ・インジェクション

4-2 入力処理とセキュリティ

Webアプリケーションの入力では何をするのか →HTTPリクエストとして渡されるパラメータの値の受付時の処理(以後、入力処理とする) 入力処理では以下の処理を行う
  • 文字エンコーディングの妥当性検証
  • 文字エンコーディングの変換
  • パラメータ文字列の妥当性検証
文字エンコーディング関連の処理が終わった後、入力値の検証を行う。 入力値検証の目的は
  • 入力値の間違いを早期に発見して再入力を促すことにより、ユーザビリティ(使いやすさ)を向上する
  • 間違った処理を継続することによるデータの不整合などを防ぎ、システムの信頼性を向上させる
入力値検証の主目的はセキュリティのためではないが、以下のようなケースにおいてセキュリティの役に立つ。
  • SQLインジェクション対策が漏れていたパラメータがあるが、英数字のみ許可していたので実害には至らない
  • PHPのバイナリセーフでない関数を使っているが、入力段階で制御文字をチェックしているので実害には至らない
  • 表示処理の関数に文字エンコーディングの指定を怠っているが、入力段階で不正な文字エンコーディングをチェックしているので実害には至らない
上記に出てきたバイナリセーフとは・・入力値がどんなバイト列であっても正しく扱えること →値ゼロのバイト(ヌルバイト)が現れても正しく処理できる このヌルバイトを利用した攻撃もある その為、アプリケーションの入り口でバイナリセーフの関数を用いて入力値のヌルバイトをチェックし、ヌルバイトがあればエラーにすることにより対応が可能 しかし、入力値検証だけでは対策にならない。 なぜなら、「すべての文字を許容する」というアプリケーションの仕様の場合は入力時点では何も防げない。 その対策としては、
  • 制限文字のチェック
  • 文字数のチェック
を行う。

4-3 表示処理に伴う問題

表示処理が原因で発生するセキュリティ上の問題は以下がある。
  • クロスサイト・スクリプティング
  • エラーメッセージからの情報漏洩
<クロスサイト・スクリプティング> 『概要』 Webアプリケーションには外部からの入力などに応じて表示が変化する箇所があり、この部分のHTML生成の実装に問題があるとクロスサイト・スクリプティング(以下、XSSと省略する)が生じる その場合の影響としては以下が挙げられる。
  • サイト利用者のブラウザ上で、攻撃者の用意したスクリプトの実行によりクッキー値を盗まれ、利用者に成りすましの被害にあう
  • 同じくブラウザ上でスクリプトを実行させられ、サイト利用者の権限でWebアプリケーションの機能を悪用される
  • Webサイト上に偽の入力フォームが表示され、フィッシングにより利用者が個人情報を盗まれる
『攻撃手法』
  • クッキーの盗み出し
  • JavaScriptによる攻撃
  • 画面の書き換え
それぞれの攻撃について。 まずは、「クッキーの盗み出し」
  1. 攻撃者は脆弱なサイトの正規利用者を罠サイトに誘導する
  2. 正規利用者が罠サイトを閲覧すると、XSS攻撃により、クッキー値をクエリー文字列につけて、情報収集ページに遷移する。
  3. 情報収集ページは受け取ったクッキー値をメールで攻撃者に送信する。
続いては、「JavaScriptによる攻撃」 現在は、Ajaxの流行により、アプリケーションの様々な機能を呼び出すためのAPIが用意されているWebサイトが増加している。 APIは攻撃に悪用することも可能なので、XSSとJavaScriptの組み合わせによる攻撃がしやすくなっている。 最後に、「画面の書き換え」 攻撃者はリンクに見せかけたボタンを用意し、それをクリックすると、 もとのformを隠し、新たなformを追加することにより改変された画面へと誘導される。 そこに個人情報などを入力させて盗む。 『脆弱性の生まれる原因』 HTML生成の際に、HTMLの文法上特別な意味を持つ特殊記号を正しく使っていないことであり、それにより、HTMLやJavaSriptを注入・変形される現象がXSSである。 『基本的対策』
  • 要素内容については「<」と「&」をエスケープする
  • 属性値については、ダブルクォートで囲って、「<」と「”」と「&」をエスケープする
『保険的対策』
  • 入力値検証を行い、条件に一致しない入力の場合にはエラーを表示して再入力を促す
  • クッキーにHttpOnly属性を付与して、JavaScriptからのクッキーの読み出しを禁止する
  • TRACEメソッドの無効化にすることで、クロスサイト・トレーシングというJavaScriptによりHTTPのTRACEメソッドを送信することにより、クッキー値やBasic認証のパスワードを盗み出す攻撃に対処できる
<エラーメッセージからの情報漏洩> エラーメッセージからの情報漏洩については以下の2種類がある。
  • エラーメッセージに攻撃者にとって有益なアプリケーションの内部情報が含まれる
  • 意図的な攻撃として、エラーメッセージに秘密情報を表示させられる

4-4 SQL呼び出しに伴う脆弱性

<SQLインジェクション> 『概要』 SQLインジェクションはSQLの呼び出し方に不備がある場合に発生する脆弱性。 以下の影響を受ける場合がある。
  • データベース内のすべての情報が外部から盗まれる
  • データベースの内容が書き換えられる
  • 認証を回避される(ID、パスワードを用いずにログイン)
  • その他、データベースサーバ上のファイルを読み出し、書き込み、プログラムの実行などが行われる
『攻撃手法と影響』
  • エラーメッセージ経由の情報漏洩:あるURLを表示するとエラーメッセージが表示され、そこにユーザIDやパスワードが表示され、情報漏洩となる
  • UNION SELECTを用いた情報漏洩:UNION SELECTは2つのSQL文の結果の和集合を求める演算で、これにより、意図しない情報が表示されてしまう
  • SQLインジェクションによる認証回避:SQLインジェクション脆弱性があると、パスワードを知らなくてもログインできてしまう場合がある
  • SQLインジェクション攻撃によるデータ改ざん::iframe要素やscript要素を埋め込み、Webサイトの利用者のPCにマルウェアを感染させるように誘導する攻撃
『脆弱性が生まれる原因』
  • 文字列リテラルの問題:SQLの標準規格では、文字列リテラルはシングルクォートで囲む。 しかし、シングルクォートを重ねることを忘れてしまうと脆弱性が生まれる
  • 数字項目に対するSQLmインジェクション:数字リテラルはシングルクォートで囲まれないため、数値でない文字が現れた時点で数値リテラルは終了する。その後の文がSQL文として解釈されてしまう。
『対策』
  1. プレースホルダによりSQL文を組み立てる
  2. アプリケーション側でSQL文を組み立てる際に、リテラルを正しく構成するなど、SQL文が変更されないようにする
上記2つのうち2は対策が難しいため、1による対策が良い <プレースホルダによるSQL文組み立て> SQL文中のクエッションマークがプレースホルダであり、変数や式などの可変パラメータの場所に埋め込んでおくもの。 プレースホルダには「静的プレースホルダ」と「動的プレースホルダ」がある。
  • 静的プレースホルダ:値のバインドをデータベースエンジン側で行う。
    1. プレースホルダのついたSQL文はデータベースエンジンに送られ、コンパイルなどの実行準備が行われ、SQL文が確定
    2. バインド値がデータベースエンジンに送られ、エンジン側で値を当てはめたSQL文が実行
    →プレースホルダの状態でSQL文がコンパイルされるため、後からSQL文が変更される可能性は原理的にあり得ない。
  • 動的プレースホルダ:SQLを呼び出すアプリケーション側のライブラリ内で、パラメータ内をバインドしてからデータベースエンジンに送る方式。 バインドに当たりリテラルは適切に構成されるため、処理系にバグがなければSQLインジェクションは発生しない。
『保険的対策』
  • 詳細なエラーメッセージの抑止:先ほど記載した通り、エラーメッセージにより情報を得られてしまうため、詳細なエラーメッセージを抑止することで被害に遭いにくくする
  • 入力値の妥当性検証:4-2節のようにアプリケーション要件に従った入力値検証を行うと、脆弱性対策になる可能性がある
  • データベースの権限設定:アプリケーションを利用するデータベースユーザに対しては、アプリケーションを実現するために必要最低限な権限のみ与えることで被害を最小限に抑えられる

4-5 「重要な処理」の際に混入する脆弱性

「重要な処理」→ログインした利用者のアカウントにより、取り消しできない重要な処理が実行できるもの <クロスサイト・リクエストフォージェリ> 『概要』 「重要な処理」の受付に際し、利用者を意図したリクエストであることを確認する必要がある。 しかし、この確認処理が抜けていると、罠サイトを閲覧しただけで、利用者のブラウザから勝手に「重要な処理」を実行させられてしまう。 以下、クロスサイト・リクエストフォージェリ(以下CSRFと略す)の影響を示す。
  • 利用者のアカウントによる物品の購入
  • 利用者の退会処理
  • 利用者のアカウントによる掲示板への書き込み
  • 利用者のパスワードやメールアドレスの変更
『攻撃方法と影響』
  • 入力-実行パターンのCSRF攻撃:例としてパスワード変更画面を示す
    1. 利用者があるホームページにログインしている
    2. 攻撃者が罠を用意する
    3. 被害者が罠を閲覧する
    4. 罠のJavaScriptにより、被害者のブラウザ上で攻撃対象サイトに対し、新しいパスワードがPOSTメソッドにより送信される
    5. パスワードが変更される
  • 確認画面がある場合のCSRF攻撃:例としてメールアドレス変更時を示す
    1. hiddenパラメータでパラメータ受け渡ししている場合 このパターンは確認画面がない場合と同じで「入力-実行パターンのCSRF攻撃」と同じ攻撃を受ける
    2. セッション変数によりパラメータ受け渡ししている場合 このパターンでは、次の2段階の攻撃が必要になってくる
      1. 確認画面に対してメールアドレスをPOSTしてセッション変数にメールアドレスをセットする
      2. タイミングを見計らって実行画面を呼び出す
『脆弱性が生まれる原因』
  • form要素のaction属性にはどのドメインのURLでも指定できる →罠などのサイトからでも、攻撃対象サイトにリクエストを送信できるということ
  • クッキーに保管されたセッションIDは、対象サイトに自動的に送信される →罠経由のリクエストに対しても、セッションIDのクッキー値が送信されるので、認証された状態で攻撃リクエストが送信されるということ
『対策』
  • CSRF対策の必要なページを区別する
  • 正規利用者の意図したリクエストであることを確認する
  • 具体的な方法としては以下の3つがある
    1. 秘密情報(トークン)の埋め込み
    2. パスワードの再入力
    3. Refererのチェック
『CSRF攻撃への保険的対策』 重要な処理の実行後に、対象利用者の登録済みメールアドレスに対して、処理内容の通知メールを送信する →攻撃を受けた際に利用者が早期発見をし、被害を最小限にとどめることが出来る。

4−6 セッション管理の不備

第三者がセッションIDを知るための手段は次の3つ
  1. セッションIDの推測
  2. セッションIDの盗み出し 方法としては、
    • クッキー生成の際の属性の不備により漏洩する
    • ネットワーク的にセッションIDが盗聴される
    • クロスサイト・スクリプティングなどアプリケーションの脆弱性により漏洩
    • PHPやブラウザ等プラットフォームの脆弱性により漏洩
    • セッションIDをURLに保持している場合は、Refererヘッダから漏洩
  3. セッションIDの強制
推測可能なセッションID 攻撃は以下の順で行われる。
  1. 対象アプリケーションからセッションIDを集める
  2. セッションIDの規則性の仮説を立てる
  3. 推測したセッションIDを対象アプリケーションで試す
対策としては、 Webアプリケーション開発ツールが備えるセッション管理機構を利用する。 URL埋め込みのセッションID セッションIDをクッキーに保存せず、URLに埋め込ませる場合がある。 →Refererヘッダを経由して、セッションIDが外部に漏洩し、成りすまし原因になる場合がある。 漏洩する条件
  • URL埋め込みのセッションIDを使える
  • 外部サイトへのリンクがある。あるいはリンクを利用者が作成できる。
対策としては、 URL埋め込みのセッションIDを使わないためには、クッキーにセッションIDを保存するように設定する。 セッションIDの固定化 セッションIDの固定化攻撃は以下の順で行われる。
  1. セッションIDを入手する
  2. 被害者に対して、入手したセッションIDを強制する
  3. 被害者は標的アプリケーションにログインする
  4. 攻撃者は、被害者に強制したセッションIDを使って標的アプリケーションにアクセスする
対策として、
  • セッションIDをURL埋め込みにしない
  • クッキーモンスター問題のあるブラウザを使わない
  • クッキーモンスター問題の発生しやすい地域型ドメインを使わない
  • クロスサイト・スクリプティング脆弱性をなくす
  • HTTPヘッダ・インジェクション脆弱性をなくす
  • その他、クッキーを書き換えられる脆弱性をなくす
があります。 しかし、これらを満たすことは困難である。 このため、セッションIDが外部から強制されることは許容し、セッションIDの固定化攻撃が行われても、セッションハイジャックは防ぐようにすることが一般的。

4-7 リダイレクト処理にまつわる脆弱性

オープンリダイレクタ脆弱性 『概要』 リダイレクトの中で、任意のドメインにリダイレクトできるものをオープンリダイレクタ。 →フィッシングという詐欺に悪用される可能性がある 『脆弱性が生まれる原因』
  • リダイレクト先のURLを外部から指定できる
  • リダイレクト先のドメインのチェックがない
どちらか一方の条件に当てはまらないようにすれば脆弱性はなくなる。 『対策』
  • リダイレクト先のURLを固定する
  • リダイレクト先のURLを直接指定せず番号指定する
  • リダイレクト先のドメインをチェックする
HTTPヘッダ・インジェクション 『概要』 リダイレクトやクッキー発行など、外部からのパラメータを元にHTTPレスポンスヘッダを出力する際に発生する。 『脆弱性が生まれる原因』 リダイレクト先URLやクッキー値として設定されるパラメータ中に改行を挿入した場合に、改行がそのままレスポンスとして出力されることが原因 『対策』
  1. 外部からのパラメータをHTTPレスポンスヘッダとして出力しない: 以下の方針に従うべきである。
    • リダイレクト先をURLとして直接指定するのではなく、固定にするが番号などで指定する
    • Webアプリケーション開発ツールの提供するセッション変数を使ってURLを受け渡す
  2. 次の2つを実施する。
    • リダイレクトやクッキー生成を専用APIにまかせる
    • ヘッダ生成するパラメータの改行文字をチェックする

4-8 クッキー出力にまつわる脆弱性

一般的に、セッション管理機構ではセッションIDのみをクッキーに保存し、 データ自体は、Webサーバのメモリやファイル、データベースなどに保存する。 一方、クッキーに保存すべきでないデータをクッキーに保存することにより脆弱性が生まれる。 このデータとは、書き換えられると困る情報で、ユーザIDや権限情報などが挙げられる。 クッキーのセキュア属性不備 クッキーにはSecureという属性(以下、セキュア属性と記述)があり、これを指定したクッキーはHTTPSの場合のみブラウザからサーバに送信される。 『攻撃手法と影響』 セキュア属性のないクッキーを盗聴する方法は以下の手順である。
  1. Fiddlerを起動しておく
  2. 上記ページを閲覧して、ブラウザにクッキーをセットする
  3. 罠ページをアクセスする
  4. 罠ページからのリクエストにクッキーがついていることをFiddlerで確認する
『脆弱性が生まれる原因』 原因はセキュア属性をつけていないことであるが、 セキュア属性をつけない主な原因は以下が挙げられる。
  • 開発者がセキュア属性について知らない
  • セキュア属性をつけるとアプリケーションが動かなくなる →そのアプリケーションはショッピングサイトのようなHTTPとHTTPSが混在するWebアプリケーション
セキュア属性がついていないセッションIDが盗聴された場合でも、トークンにセキュア属性を付けることで確実に暗号化されていればHTTPSのページはセッションハイジャックされることはない。

4-9 メール送信の問題

メールヘッダ・インジェクション脆弱性 メールヘッダ・インジェクションは宛先や件名などのメールヘッダを外部から指定する際に、改行文字を使ってメールヘッダや本文を追加・変更する手法。 メールヘッダ・インジェクション脆弱性は以下の通り。
  • 件名や送信元、本文を改変される
  • 迷惑メールの送信に悪用される
  • ウイルスメールの送信に悪用される
脆弱性の生まれる原因以下の通り。 ヘッダの各フィールドは改行で区切られているので、外部から指定するパラメータに改行を挿入できれば、新たなヘッダを追加できる。 この改行をアプリケーションがチェックしていない場合には、ヘッダや本文を追加・変更できることになる。 →つまり、これが脆弱性の生まれる原因 『対策』 メール送信にsendmailコマンドではなく、専用のライブラリを使用すべき。 その上で、以下のいずれかを実施する。
  • 外部からのパラメータメールヘッダに含ませないようにする
  • 外部からのパラメータには改行を含ませないようにメール送信時にチェックする

4-10 ファイルアクセスにまつわる問題

ディレクトリ・トラバーサル脆弱性 外部からパラメータの形でサーバ上のファイルを指定できるWebアプリケーションでは、ファイル名に対するチェックが不十分であると、アプリケーションの意図しないファイルに対して閲覧や改ざん、削除が出来る場合がある。 この脆弱性をディレクトリ・トラバーサルという。 影響は以下の通り。
  • Webサーバ内のファイルの閲覧→重要情報の漏洩
  • Webサーバ内のファイルの改ざんの削除 →Webコンテンツ改ざんによるデマ、誹謗中傷の書き込み →マルウェアのサイトに誘導する仕組みの書き込み →スクリプトファイルや設定ファイル削除によるサーバ機能停止 →スクリプトファイル改ざんによる任意のサーバスクリプト実行
脆弱性が生まれる原因は、
  • ファイル名を外部から指定することができる
  • ファイル名として、絶対パスや相対パスで異なるディレクトリを指定できる
  • 組み立てたファイル名に対するアクセスの可否をチェックしていない
対策は、
  • 外部からファイル名を指定してできる仕様を避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する
意図しないファイル公開 外部から閲覧されると困るファイルをWebサーバの公開ディレクトリに配置している場合がある。 この場合、ファイルに対するURLがわかると、秘密ファイルの閲覧が可能になる。 意図しないファイルの公開により重要情報の漏洩が発生する。 脆弱性が生まれる原因は、
  • ファイルが公開ディレクトリに置かれている
  • ファイルに対するURLを知る手段がある
  • ファイルに対するアクセス制限がかかっていない
根本的な対策としては、非公開ファイルを公開ディレクトリに置かないことである。 そのためには、
  • アプリケーションの設計時に、ファイルの安全な格納場所を決める
  • レンタルサーバを契約する場合は非公開ディレクトリが利用できることを確認する

4-11 OSコマンド呼び出しの際に発生する脆弱性

OSコマンド・インジェクション Webアプリケーションの開発に用いる言語の多くはシェル経由でOSコマンドを呼び出す機能を提供しており、シェルを呼び出せる機能の使い方に問題があると、意図しないOSコマンドが実行可能になる場合がある。 これがOSコマンド・インジェクションである。 典型的には以下のような攻撃を受ける。
  1. 攻撃用ツールを外部からダウンロードする
  2. ダウンロードしたツールに実行権限を与える
  3. OSの脆弱性を内部から攻撃して管理者権限を得る
  4. Webサーバは攻撃者の思い通りのままになる
上記を行うと以下の悪用が可能になる。
  • Webサーバ内のファイルの閲覧・改ざん・削除
  • 外部へのメールの送信
  • 別のサーバへの攻撃
この脆弱性が生まれる原因は、
  • シェル経由でOSコマンドを呼び出す際に、シェルのメタ文字がエスケープされていない場合
  • シェル機能を呼び出せる関数を仕様している場合
対策としてはいずれかを行うべきである。(優先すべき順に並べる)
  1. OSコマンド呼び出しを使わない実装方法を選択する
  2. シェル呼び出し機能のある関数の利用を避ける
  3. 外部から入力された文字列をコマンドラインのパラメータに渡さない
  4. OSコマンドに渡すパラメータを安全な関数によりエスケープ
万一対策に漏れがあった場合の影響が大きいため、攻撃の被害を軽減する保険対策を実施すべきである。
  • パラメータの検証
  • アプリケーションの稼働する権限を最小限する
  • WebサーバのOSやミドルウェアのバッチ適用

4-12 ファイルアップロードにまつわる問題

アップロード機能に対するDoS攻撃 Webアプリケーションのアップロード機能に対して、巨大なファイルを連続して送信することにより、Webサイトに過大な負荷を掛けるDoS攻撃を仕掛けられる可能性がある。 影響として、
  • 応答速度の低下
  • 最悪の場合、サーバの停止
対策としては、アップロードファイルの容量制限が有効である。 アップロードファイルによるサーバ側スクリプト実行 影響として、
  • Webサーバ内のファイルの閲覧・改ざん・削除
  • 外部へのメールの送信
  • 別サーバへの攻撃
アップロードファイルによるサーバ側スクリプト実行を防止するには以下を実施する。
  • 利用者にアップロードされたファイルは公開ディレクトリに置かず、スクリプト経由で閲覧させる
  • ファイルの拡張子をスクリプト実行の可能性のないものに制限する
脆弱性が生まれる原因は、
  • アップロードしたファイルが公開ディレクトリに保存される
  • アップロード後のファイル名として、「.php」、「.asp」などスクリプトを示す拡張子が指定できる
対策としては、上記の原因を潰せば良いわけですが、 拡張子の制限だけでは対策抜けが生じる可能性があるため、 ファイルを公開ディレクトリに保存しない方法が望ましい。 ファイルダウンロードによるクロスサイト・スクリプティング 攻撃者がアプリケーションに罠を仕掛けて、アップロードしたファイルがHTMLとして認識されるような仕向ける。 利用者のブラウザがこのファイルをHTMLとして認識するとXSS攻撃が成立する。 脆弱性の生まれる原因は、Internet Explorer特有の仕様が影響する。 ファイルダウンロードによるXSS脆弱性対策はファイルのアップロード時とダウンロード時の対策それぞれを示す。
  1. ファイルアップロード時の対策 以下を実施する。
    • 拡張子が許可されたものかをチェックする
    • 画像の場合は、マジックバイトも確認する
  2. ファイルダウンロード時の対策 以下を実施する。
    • Content-Typeを正しく設定する
    • 画像を場合は、マジックバイトを確認する
    • 必要に応じてContent-Dispositionヘッダを設定する
  3. その他の対策
    • ファイルサイズ以外の縦横サイズ、色数などのチェック
    • 画像として読み込めるかどうかのチェック
    • ウイルス・スキャン
    • コンテンツの内容チェック →アダルトコンテンツ →著作権を侵害するコンテンツ →法令、公序良俗に反するコンテンツ

4-13 インクルードにまつわる問題

ファイルインクルード攻撃 includeなどに指定するファイル名を外部から指定できる場合、アプリケーションが意図しないファイルを指定することにより脆弱となる場合がある。 →ファイルインクルード脆弱性 影響は以下の通り。
  • Webサーバ内のファイルの閲覧による情報漏洩
  • 任意のスクリプトの実行による影響 →サイト改ざん →不正な機能実行 →他サイトへの攻撃
脆弱性が生まれる原因は、
  • インクルードファイル名を外部から指定することが出来る
  • インクルードすべきファイル名かどうかの妥当性をチェックしていない
である。 対策は以下のいずれかを実施する。
  • 外部からファイル名を指定することを避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する

4-14 evalにまつわる問題

evalインジェクション eval関数の利用法に問題がある場合、外部から送り込んだスクリプトを実行される場合がある。 →このような攻撃をevalインジェクション攻撃 この攻撃による影響は、
  • 情報漏洩
  • サイト改ざん
  • 不正な機能実行
  • 他サイトへの攻撃
がある。 脆弱性が生まれる原因は、
  • evalを用いることがそもそも危険である
  • evalに与えるパラメータのチェックがされていない
である。 対策としては、上記の原因からもわかる通り、
  • evalを使わない
  • evalの引数に外部からのパラメータを指定しない
  • evalの与える外部からのパラメータを英数字に制限する

4-15 共有資源に関数問題

競合状態の脆弱性 共有資源とは、複数のプロセスやスレッドから同時に利用している変数、共有メモリ、ファイル、データベースなどのこと。 共有資源に対する排他制御が不十分な場合、競合状態の脆弱性の原因となる場合がある。 代表例としては、
  • 別人の個人情報などが画面に表示される
  • データベースの不整合
  • ファイルの内容の破壊
が挙げられる。 脆弱性の生まれる原因は、
  • 変数nameは共有変数である
  • 共有変数nameの排他制御をしていない
対策は以下のうちいずれかの実施である。
  • 可能であれば共有資源を使用しない
  • 共有資源に対して排他制御を行う
まとめ だいぶだらだらと長く記述していきましたが、 それぞれの脆弱性の発生原因とそれへの対策をしっかりと抑えていく必要があると感じた。 現状、覚えられていない。とりあえず、このような脆弱性があるのだなという把握は必要。

第5章 代表的なセキュリティ機能

5−1 認証

認証:利用者が確かに本人であることをなんらかの手段で確認すること。 Webアプリケーションで用いられる認証手段は、「HTTP認証」、「HTMLフォームでのIDとパスワードを入力させるフォーム認証」、「SSLクライアント証明書を用いるクライアント認証」がある。 それでは、認証処理を要素分解していく。
  1. ログイン機能:認証処理の中心となるのが本人確認の機能=ユーザIDとパスワードをデータベースとの照合
    • ログイン機能に対する攻撃
      • SQLインジェクション攻撃による認証機能のバイパス・パスワードの入手
      • ログイン画面に対するパスワード試行
      • ソーシャルハッキングによるパスワード入手
      • フィッシングによるパスワード入手
    • ログイン機能が破られた場合の影響:Webアプリケーションが不正ログインされると、攻撃者は利用者の持つ権限を全て利用できるようになる。
    • 不正ログインを防ぐためには →SQLインジェクションなどのセキュリティバグをなくす →パスワードを予測困難なものにする
  2. 総当たり攻撃への対策:アカウントロックが有効である。 →暗証番号やパスワードを規定回数以上間違えるとアカウントをロックする
  3. パスワードの保存方法
    • パスワードの保護の必要性:パスワードの漏洩→他の秘密情報の漏洩→悪用により情報漏洩以外の被害
    • 暗号化によるパスワードと課題:暗号を使う場合の課題は以下の通り
      1. 安全な暗号のアルゴリズムの選定
      2. 鍵の生成
      3. 鍵の保管
      4. 暗号アルゴリズムが危殆化した場合の再暗号化
    • メッセージダイジェストによるパスワード保護と課題 メッセージダイジェスト・・・任意の長さのデータを固定長のデータ(メッセージダイジェスト)に圧縮する関数をハッシュ関数といい、セキュリティ上の要件を満たすハッシュ関数を暗号学的ハッシュ関数という。 それでは、メッセージダイジェストを用いてパスワードを保護する。 まず、ハッシュ関数の特性は、
      • ハッシュ値から元データを得ることが困難(一方向性)
      • 異なる入力から得られるハッシュ値が一致する確率が極めて低い(衝突耐性)
      であり、これによりパスワードが安全に保存できる。 しかし、ハッシュ値から元のパスワードを解析するための手法がしられている。 3種類取り上げる。
      1. オフライン総当たり攻撃:パスワードは短い文字列で文字種も限られていることから総当たり的にデータを探索できる
      2. レインボー・クラック:レインボーテーブルというものを用いて文字種と文字数の制限毎に作成される →文字数を多くすることで防ぐことができる
      3. ユーザDB内にパスワード辞書が作られる:攻撃者がダミーのユーザを多数登録して、ユーザDB上に「パスワード辞書」を作ってしまう
    • ハッシュ解読の対策として2つ示す。
      1. ソルト:ハッシュの元のデータに追加する文字列のこと。 →見かけのパスワードを長くするとともに、ソルトをユーザ毎に異なるものにすることで、パスワードが同じでも異なるハッシュ値が生成される
      2. ストレッチング:ハッシュの計算を繰り返し行うことによって計算時間をのばすことが出来る
  4. 自動ログイン
    • 自動ログインの安全な実装方式:
      • セッション寿命を延ばす
      • トークンを使う
      • チケットを使う
      • 3方式の比較を行うと、 この中ではトークン方式が一番好ましい。 メリットとして、
        • 自動ログインを選択しない利用者に影響を与えない
        • 複数端末からログインしている場合に一斉ログアウトできる
        • 管理者が、特定利用者のログイン状態をキャンセルできる
        • クライアント側に秘密情報がわたらないので解析されるリスクがない
    • 自動ログインのリスクを低減するには:重要な処理の前にはパスワード入力を要求する
  5. ログインフォーム:一般的なガイドラインは以下の通り
    • パスワード入力欄はマスク表示する
    • HTTPSを利用する場合は、ログインフォームからHTTPSにする
  6. エラーメッセージの要件:エラーメッセージは攻撃者のヒントとなる情報は含むべきでない
  7. ログアウト機能:ログアウト処理の要件は以下の通り
    • ログアウト処理は副作用があるのでPOSTメソッドでリクエストする
    • ログアウト処理ではセッションを破棄する
    • 必要な場合、CSRF対策の対象とする

5-2 アカウント管理

アカウント管理における6つの機能についてセキュリティ上の注意点を記述する
  1. ユーザ登録:ユーザ登録については4つのセキュリティ上の注意点がある。
    1. メールアドレスの受信確認:メールアドレスを登録・変更する際には、登録されたメールアドレスに送信されるメールを利用者自身が受信できることを確認すべき そのために→
      • メールにトークンつきURLを添付して、そのURLから処理を継続する
      • メールアドレスを入力した後、トークン入力画面に遷移する。 トークンは、指定したメールアドレスにメール送信される
    2. ユーザIDの重複防止:ユーザIDは一意でなければならない為、排他的制御に細心の注意を払う必要がある
    3. ユーザの自動登録への対処:インターネット経由で自由にユーザ登録できるWebサイトの場合、外部からの自動操作により大量にユーザを作成される場合がある。 →CAPTCHAという仕組みを用いて、わざと文字をゆがめた画像を表示させ、利用者に文字を入力させ人間であることを確認する方法がある。
    4. パスワードに関する注意
  2. パスワードの変更:パスワード変更機能に対するセキュリティ上の注意点は以下の4点
    1. 現在のパスワードを確認する:現在のパスワードを入力してもらい照合 →セッションハイジャックされた状態で第三者がパスワードを変更することを防止できる
    2. パスワード変更時にはメールでその旨を通知する:第三者が不正にパスワードを変更した場合でも早期発見に繋がる
    3. SQLインジェクション脆弱性:
    4. CSRF脆弱性
  3. メールアドレスの変更:メールアドレス変更に必要な機能対策は以下の3つ
    • 新規メールアドレスに対する受信確認
    • 再認証
    • メール通知
  4. パスワードリマインダ:パスワードを忘れた際に何らかのかたちでパスワードを知らせる仕組みを用意する場合がある。 これには、管理者向けパスワードリマインダと利用者向けパスワードリマインダがある。 利用者向けパスワードリマインダの方法は以下の4つ
    • 現在のパスワードをメールで通知する
    • パスワード変更画面のURLをメールで通知
    • 仮パスワードを発行してメールで通知
    • パスワード変更画面に直接遷移
    この中で推奨すべきは下の2つである。
  5. アカウントの停止:特定のアカウントに対してセキュリティ上の問題が生じた場合は当該のアカウントを一時的に停止する場合がある。
  6. アカウントの削除:アカウントの削除は通常取り消し出来ない処理なので、本人の意思確認とCSRF脆弱性対策を目的として、パスワードの確認を要求すべき

5-3 許可

許可とは、認証された利用者に対して権限を与えること。 権限の例を以下に示す。
  • 認証された利用者のみ許可された機能 →退会処理、送金、新規ユーザ作成等
  • 認証された利用者のみに許可された情報の閲覧 →非公開の利用者自身の個人情報、非公開の掲示板、Webメール等
  • 認証された利用者のみに許可された編集操作 →利用者本人の設定変更、Webメールからのメール送信等

5-4 ログ出力

ログ出力の目的
  • 攻撃や事故の予兆をログから把握し、早期に対処する
  • 攻撃や事故の事後調査
  • アプリケーションの運用監査
アプリケーションログは以下の3種類である。
  • エラーログ:エラーを記録するもの →攻撃の検出に役立つ場合がある
  • アクセスログ:Webアプリケーションの情報閲覧や機能の利用記録をしてのログ →正常・異常共にログを残し、個人情報漏洩事件・事故への対応に役立つ
  • デバッグログ:デバッグ用のログ →開発環境やテスト環境で取得するもので、本番環境では取得すべきでない

第6章 文字コードとセキュリティ

6-1 文字コードとセキュリティの概要

文字コードとは以下の2つの概念を合わせたものである。
  • 文字集合
  • 文字エンコーディング

6-2 文字集合

文字集合とは、その名の通り文字を集めたもの。 文字集合の扱いが原因でおこる脆弱性は、文字変換の際のエスケープ処理で脆弱性が生まれる。

6-3 文字エンコーディング

文字エンコーディングとは、文字集合をコンピュータ上で扱う為の符号化。 文字エンコーディングは以下のようなものがある。
  • Shift_JIS
  • ISO-2022-JP
  • UTF-16
  • UTF-8

6-4 文字コードによる脆弱性の発生要因まとめ

文字コードによる脆弱性については以下の3つのタイプに分類される。
  • 文字エンコーディングとしては不正なバイト列による脆弱性
  • 文字エンコーディングの扱いの不備による脆弱性
  • 文字集合の変更に起因する脆弱性

6-5 文字コードを正しく扱うために

文字コードを正しくあつかうためには、以下の4つのポイントがある。
  1. アプリケーション全体を通して文字集合体を統一する
  2. 入力時に不正な文字エンコーディングをエラーにする
  3. 処理の中で文字エンコーディングを正しく扱う
  4. 出力時に文字エンコーディングを正しく扱う

第7章 携帯電話向けWebアプリケーションの脆弱性対策

7-1 携帯電話向けWebアプリケーションの技術的特徴

携帯電話のブラウザでWebアクセスする際は、キャリアのゲートウェイからインターネットに説ゾオクされる形態となる。 ゲートウェイの役割は以下の通り。
  • 携帯電話網からインターネットへの橋渡し(プロキシ)
  • 携帯IDの付与
  • クッキー保持
  • 絵文字の変換
  • SSL処理
  • 言語変換
ブラウザの機能的特徴
  • クッキーが使えない端末の存在:セッション管理にクッキーを用いず、URLにセッションIDを埋め込む方式が定着
  • JavaScriptが使えない端末が大半
  • Refererなどのリクエストヘッダの制限
  • HTTPレスポンスの容量制限

7-2 携帯ブラウザの技術仕様

JavaScriptのサポートにより脆弱性が¥が存在する場合のリスくが高まるとともに、新たな脆弱性パターンが生まれる可能性もある。 クッキーの仕様を以下に示す
  • HTTPの状態でSet-Cookieされたクッキーは事業者のゲートウェイが保持する
  • HTTPSの状態でSet-Cookieされたクッキーは端末が保持する

7-3 かんたんログインの問題

かんたんログインとは、IDとパスワードの代わりに端末IDのみを用いた認証方法。 かんたんログインに対する攻撃手法を以下に示す。
  • 携帯電話をモデムとしてゲートウェイを経由する方法
  • リクエストヘッダを書き換える
  • DNSリバインディング攻撃(受動的攻撃)
上記に攻撃手法を示したが、安全なかんたんログインの実装方法はあるのか 以下が必須条件となる
  • 携帯電話事業者のゲートウェイからのアクセスのみを受け付ける
  • リモートIPアドレスを元に事業者判定する
  • 携帯IDとしてはiモードID、EZ番号、ユーザIDのみ用いる
  • HTTPSではかんたんログインを受け付けない
  • Hostヘッダのチェックまたは名前ベースのバーチャルホストの設定を行う
  • ソフトバンクの非公式JavaScript対応端末へのなんらかの対処を行う

7-4 URL埋め込みのセッションIDによる問題

Refererヘッダにより外部にセッションIDが漏洩するという問題がありますが、それ以外にも以下の問題がある。 ・セッションIDの固定化がおこりやすい 対策としては、
  • クッキーが使え得る場合はクッキーを使う
  • 外部ドメインに極力リンクしない
  • 外部リンクにはクッションページをはさむ
  • ログイン後にセッションを開始する
  • 検索エンジン対策:認証前はセッションに有効にしないこと。

第8章 Webサイトの安全性を高めるために

Webサーバへの攻撃経路と対策

Webサーバへの攻撃はソフトウェアの脆弱性をついた攻撃や、Webサーバの管理に用いるパスワード攻撃がある。 対策としては、
  • サービス提供に不要なソフトウェアは稼働させない:不要なソフトウェアについては削除か停止をすることが安上がりで安全
  • 脆弱性の対処をタイムリーに行う
  • 一般公開する必要のないポートやサービスはアクセス制御する
  • 認証強度を高める:管理者のソフトウェアの認証の強度を高める →以下を推奨
    • TelnetサーバとFTPサーバを削除あるいは停止し、SSH系サービスのみを稼働させる
    • SSHサーバの設定によりパスワード認証を停止し、公開鍵認証のみとする

8-2 成りすまし対策

成りすましの手口はネットワーク的な成りすましと、Webサイトのデザインだけを似せたフィッシングの手法がある。
  1. ネットワーク的な成りすまし
    • DNSに対する攻撃:
      • DNSサーバに対する攻撃によりDNSの設定内容を書き換える
      • DNSキャッシュボイズニング攻撃
      • 執行したドメインを第三者がく購入して悪用する
    • ARPスプーフィング:ARPの偽応答を返すことで、IPアドレスを偽装する手法
  2. フィッシング:正規サイトにそっくりな入力画面を用意してメールなどで利用者を誘導し、IDとパスワードや個人情報などを入力させて盗み取る手法
Webサイトの成りすまし対策として以下が有効である。
  • ネットワーク的な対策:
    • 同一セグメント内に脆弱なサーバは置かない
    • DNS運用の強化:DNSSECの導入
  • SSL/TLSの導入
  • 確認しやすいドメインの採用

8-3 盗聴・改ざん対策

盗聴・改ざんの経路を以下に示す。
  • 無線LANの盗聴・改ざん:無線LANを流れるパケットは適切に暗号化されていないと盗聴される可能性がある
  • ミラーポートの悪用
  • プロキシサーバの悪用:もともとあるプロキシサーバを操作できる場合や、通信路上にプロキシサーバを設置出来る場合、プロキシサーバを流れるHTTPメッセージを盗聴できる
  • 偽のDHCPサーバ:偽のDHCPサーバにより、DNSやデフォルトゲートウェイのIPアドレスを偽装できる場合がある
中間者攻撃:盗聴用の機器により通信を中継させるタイプのものがある。 通信の盗聴・改ざんの対策として、以下の注意点がある。 SSL利用時の注意点
  • 入力画面からHTTPSにする
  • クッキーのセキュア属性に注意
  • 画像やCSS、JavaScriptなどもHTTPSで指定
  • frame、iframeを使わない
  • ブラウザのデフォルト設定でエラー表示されないようにする
  • アドレスバー・ステータスバーを隠さない
  • コンテキストメニューを無効化しない

8-4 マルウェア対策

Webサイトのマルウェア対策とは、以下の2つの意味がある
  • Webサーバがマルウェアに感染しないこと→マルウェアがWebサーバ上で活動してる状態
  • Webサイトを通じてマルウェアを公開しないこと→Webコンテンツとしてマルウェアがダウンロード出来る状態
マルウェアの感染経路は、インターネット接続・外部媒体、持ち込みクライアント・電子メールが多い。 Webサーバのマルウェア対策は以下が重要
  • サーバの脆弱性をタイムリーに行う
  • 出所不明なプログラムをサーバに持ち込まない
  • サーバ上では運営に直接関係ない操作をしない
  • サーバにUSBメモリなどの外部メディアを装着しない
  • Webサーバのネットワークを執務スペースのLANと切り離す
  • サーバに接続するクライアントPCにウイルス対策ソフトを導入してパターンファイルを最新に保つ
  • クライアントPCに最新のセキュリティパッチを導入する

第9章 安全なWebアプリケーションのための開発マネジメント

安全なアプリケーションのための開発プロセスについて説明する
  • 企画段階の留意点 安全なアプリケーション開発に必要な予算の見積もり、確保することが重要
  • 発注時の留意点 RFPに記載するセキュリティ要件が重要になってくる →セキュリティバグに対する要求は漠然としてしまうと実効性に乏しくなってしまう。
  • 要件定義時の留意点 セキュリティバグ対策については受注者の開発基準をベースとすべきである。
  • 基本設計の進め方 実施すべき重要項目は以下の通り
    1. セキュリティ機能に対する具体化
    2. 方式設計として開発標準の詳細化、テスト方式の決定
    3. 画面設計時のセキュリティ機能の確認
  • 詳細設計・プログラミング時の留意点 基本設計に従って開発
  • セキュリティテストの重要性と方法 自力で診断する場合は「ウェブ健康診断仕様」という脆弱性診断を用いて判断する。
  • 受注者側テスト 以下の手法を行う
    • ソースコード検査
    • ツールによるブラックボックス検査
    • 手動によるブラックボックス検査
  • 発注者側テスト 予算に余裕がなければ先ほど出てきた「ウェブ健康診断仕様」を用いて行う。
  • 運用フェーズの留意点 このフェーズで重要なことは以下の2点
    • ログの監視
    • 脆弱性対処
以上で備忘録を終了する。

iOS まとめ

こんにちは、うさです。 本日で一応iOSについての勉強を終えて、 次回からもう一度サーバーサイドの勉強をしたいと思います。 そして、本日学んだことは昨日と同じくObjective-Cを用いての家計簿のアプリ作りです。 昨日はひたすら書籍に書いてあることを真似して書くというもので 頭にはなかなか入らなかったので、 本日はひたすらノートにコードを書き、わからないクラスやメソッドを調べながら頭に叩き込んでいきました。 このようにやっていくとある程度形式的にコードが書かれていることが多いのだなと思いました。 例えば、メソッドで長くて絶対理解できないと思っていた ですが、 これはデータベースにおいて必要な挿入・削除・更新・入れ替えの4パターンそれぞれ対して、 この後の それぞれの処理に対応しています。 また、サンプルで使用されているメソッドを調べてみると 使用をおすすめしてないようなものもあった。 例えば、 [NSCalendar currentCalendar]はカレンダーを使うクラスになるのですが、 iPhoneの設定で「設定」-> 「一般」->「言語環境」->「カレンダー」から和暦の設定にすると 4000年4月1日(土) ←2012年4月1日は日曜日 こんな感じに表示がおかしくなることがある。 (平成2012年として表示しているため) 今回は、おかしくならなかったが、 上みたいになったら、 dateFormatter.calendar = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; で記載することで、西暦に統一することができる。 まだまだ、iOSやObjective-Cについてはわからないことだらけだが、 徐々に学んでいこうと思う。 以上うさでした。
スクリーンショット 2015-02-19 15.17.42

iOS学習 家計簿を作る

こんにちは、うさです。 昨日と今日でiOSの家計簿アプリを作りました。 ページの構成としてはこんな感じ スクリーンショット 2015-02-19 15.17.42 ページ数が多くてなんだかややこしいですね そしてデータベースはCoreDataのSQLiteを用いてデータの保存を行います。 では、CoreDataで使用するクラスを確認していきます。
  • NSManagedObject:CoreDataで永続化されるデータの全てをこのクラスをインスタンス化して使用。 SQLiteの場合は、1つのモデルが1つのテーブルに対応してインスタンスがそのテーブルの各レコードに対応
  • NSManagedObjectContext:CoreDataを扱う際に中心となるクラス。 データの保存・削除・移動などを管理
  • NSEntityDescription:エンティティの定義を管理するクラス。 データを新規作成する時に使用
  • NSManagedObjectModel:各エンティティの情報やエンティティ同士の関連を管理するクラス。 Xcode上のGUIのエディタで編集したものを読み込んで初期化
  • NSPersistentStoreCoordinator:NSManagedObjectModelとSQLiteなどのファイルを関連づけして永続化を行う
  • NSFetchRequest:データの検索に使用するクラス。 検索条件やソート、取得件数などを指定
  • NSFetchedResultsController:NSFetchRequestを元にデータを取得しUITableViewで扱いやすいようなAPIを提供。 delegateを指定した場合には、NSManagedObjectContextを監視して指定のNSFetchRequestに関連のある変更が合った場合にdelegateに処理を委譲する
といった感じでクラスを利用していきます。 ソースコードは全部書くと膨大な量になってしまうため、ある1ページのソースコードを書いてどんな処理を行っているのか見ていきます。   このソースコードは下の画像のページにおける処理を行います。 スクリーンショット 2015-02-19 15.45.57 家計簿における項目の入力を行うページになります。 今回、このアプリをつくってみて感じたことは、
  • ページ数が多いとどのページとどのページか関連し合っているのかがわからなくなる
  • エラーが出ている時は基本的にはスペルミス(笑) →本格的に開発を始めたら、予測変換を最大限の活用!!
  • とにかくクラスやメソッドを覚えないことには開発は難しい
です。 とりあえず、このアプリを何度も作ってみたりしてObjective-Cの記述方式に慣れていきます。 以上うさでした。

備忘録 〜ソフトウェアテスト〜

こんばんは、うさです。 本日は、「ソフトウェアテスト」について備忘録として 一冊の書籍から重要なことを書いていく。 今回参考にさせて頂いた書籍はこちら!!

第1章はじめに

第1章ではソフトウェアテストをするうえでの心得が書かれており、 ソフトウェアの「バグを全部見つけるのは無理だと心得ろ」と『Cem kaner』という方は言っている。 それは今完全なテスト手法がないからである。 では、テストエンジニアは何を心得てテストを行っていくべきなのか!! それは 「どの部分にバグが出やすいか、 そこにどのようなテスト手法を用いれば 十分な品質が得られるか」 を考えてやっていくことである。 なぜなら、バグの47%はプログラムの4%の部分に偏在しているという例もあるくらいに バグは一カ所に固まっているからである。

第2章ソフトウェアの基本

第2章ではホワイトボックステストについて書かれている。 業務では殆ど使う事はなくなったそうですが、 知っておくべきではある。 ホワイトボックステストとは 一言で言うと、 「プログラムの論理構造がを解析するテスト」である。 では、どんなことをするのかというと、 制御パステスト法を用いる。 これはカバレッジ率の値を取る為に用います。 カバレッジ率とは、ステートメントカバレッジ・ブランチカバレッジ・コンディションカバレッジの3つをどれだけ網羅出来たかを表す値である。
    • ステートメントカバレッジ:コード内の命令文を少なくとも一回実行する事 例を挙げると con1 = 0 とcon2 = 2 でそれぞれ一回命令文を実行します。 これがステートメントカバレッジである。
 
    • ブランチカバレッジ:ステートメントカバレッジでは対処できなかったもう一方の分岐も行う事
 
  • コンディションカバレッジ:書籍には説明が出てきませんでしたが、 コード内の条件式について「true/false」それぞれ一回ずつ出力させる事
ここまでだいぶ用語の説明になってしまいましたが、 ホワイトボックステストを用いてどうすればよいのか。 上記のカバレッジ率を上げる為にコード内の条件を一つ一つ確認していきます。 しかし、量は膨大であるため、カバレッジ率には基準が存在し、 一般商用ソフトウェアでは60〜90%あればよい。 しかし、そこの数値はソフトウェアの利用目的に大きく関わってくるため一概には言えないよう。 そして、意識しなければならないのは、
  • カバレッジテストはテストを行うのに時間がかかる
  • ソフトウェアの仕様が間違っていてもバグは発見できない
といったことです。 時間がかかると書きましたが、 テスト用フレームワークを用いて単体テストのコード書いてテストすることで飛躍的に時間は短縮されカバレッジ率も上がる。

第3章エンジニアが最も使う手法

ということで、続いてはブラックボックステストについて。 ソフトウェアテストの約8割がブラックボックステストを行う会社もあるので重要なテストである。 ソフトウェアとはデータを『入力・出力・計算・保存』という仕事で成り立っている。 まずは、その中の「入力・出力」についてのテストを見ていく
  • 同値分割法:入力領域を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす作業
  • 境界値分析法;同値分割で得た同値クラスの境目の値のバグを見つける作業 境界値分析法でのバグは4つに分けられる
    1. 「>」と「>=」の間違い
    2. 数字の書き間違い
    3. 境界がない(elseの書き忘れ等)
    4. 余分な境界
    これらのバグを発見するにはOn-Offポイント法を用いる これは異なる処理が行われる最も近い二点を選択してテストすること
  • ディシジョンテーブルテスト:表に、状態・状態の組み合わせ・アクションを書き、 この表の通りに「状態」をテストし、期待通りの「アクション」を起こすかを確認する作業
  • 状態遷移テスト:ある状態からイベント処理(入力が多い)を行い期待通りの遷移が行われるを確認する作業 このテストで、
      1. 期待通りでない状態に遷移
      2. 遷移自体を行わない
    という二つが検出される。
では、これらのテスト手法をどのように使っていくのか!! 例として、 もし、ダイアログボックスが一つだけあれば境界値テスト 複数のダイアログボックスがあればディシジョンテーブルテスト ダイアログボックスの遷移があれば状態遷移テストを行う これらを行いまだバグが見つかるようなら以下の理由が考えられる
  • ブラックボックステストのアプローチの仕方が間違っている
  • ホワイトボックステストでしか見つからないバグが存在した

第4章探索的テスト

探索的テストとは、ソフトウェア機能を学習しながらテスト設計とテスト実行を同時に行う事 どういんことか。 テストケースを書いて実際にテストを行ってバグが見つかるのは50%以下。 ならば、テストケースを書くのではなくてソフトウェアをテストしながら考えて実行してしまうということ。 どのように探索的テストを行っていくのか!!
  1. ターゲットソフトウェアを決める
  2. 機能をリストアップ
  3. バグが見つかりそうなエリアを見つける
  4. 各機能のテスト及びバグの記録
  5. 継続的にテストの実行
といった具合に行ってバグを見つけていく。 探索的テストの網羅率はプログラムの構造を理解していることによって、 テストケースベースののテストコード網羅率を上回る。 つまり、プログラミングエンジニアはこのテストを行う方がよいということである。

第5章非機能要求のテスト

今まで書いてきたテストは全て機能要求に対するテストのアプローチであり、 この章では非機能要求のテストを説明する。 非機能要求では品質特性の向上を図る。 まずは、期待通りの性能を引き出す為に、 パフォーマンステストについて行う。 パフォーマンステストとはソフトウェア設計・企画時の段階で設定された性能が期待通り出ているかをチェックするもので、 平均的なWebアプリケーションでは72%しか出ないといった結果となっている。 設計時のパフォーマンスの定義の例として、 要求:20Mバイトのデータを10秒で処理したい 結果:21Mバイトになったとたん30秒かかる(バグ)    1Mバイトに10秒かかる(バグ) といった具合に定量的に明確化して定義する。 パフォーマンステストは次の手順で行う。
  1. アーキテクチャバリデーション:机上でのチェック
  2. パフォーマンスベンチマーク:パフォーマンステストが出来る状態のソフトウェアが出来た時点でテストを行う
  3. パフォーマンス回帰テスト:プログラム開発途上で変更時に行う
  4. パフォーマンスチューニング、アクセプタンステスト:最終製品が要求定義に定められたパフォーマンスを出しているかのチェック
  5. 24×7パフォーマンスモニター:ERPアプリの際、顧客の使用するデータに近いダミーデータでのテスト

第6章ソフトウェアテスト運用の基本

テストを行う際重要になってくるのが、どれだけの時間を割くのかということである。 そして、テストに割く時間は開発のスピードによって左右されるという事。 そうなった場合の選択肢は以下の3通り
  • ソフトウェアの品質を下げる
  • 出荷を遅らせる
  • 機能を削る
もちろん、このような事態にならないように開発での期限は守らなければならないが、 対応策は考えなくてはならない。

第7章ソフトウェアテスト品質管理の基本

品質は目に見えないものである。 しかし、何らかの形に数値として表さなくてはならない。 それは「バグの数」である。 バグの数を数値化してグラフに表すと スクリーンショット 2015-02-12 2.21.01 こういった形でバグの数は徐々に減っていく。 また、重要度の高いバグもどんどん減っていく。 しかし、GUIアプリケーションではオンラインヘルプの文章や文字が欠けているといったUIの問題が継続的に出てくる場合もある。 もちろん、バグの数が減っていくとバグ修正にかかる時間も減っていく事になる。 もし、後の方でバグが見つかると致命的な場合がある。 例えば、設計上からくるバグは一個のバグ修正の為に何カ所もコードを変えなければならなくなる。 最後に、この書籍から学んだ事は、 バグは完全になくなりはしないという事。 重要の高いバグは徹底的に修正をして、 後は市場に出した後に少しずつ修正していく。 テストの種類は色々あり最初はどれを使えばいいのかわからなかったり、 どの程度までテストを行えばいいのかわからないと思われる。 ある程度コードを書いたら探索的テストやブラックボックステストを行うといった方法を使っていけばよいのかなと感じた。 テストの自動化もあるそうだが、それはテストに慣れてきてからだろう。 一番大切な事は、いかに完璧に近い設計書を書けるかだと感じた。 プログラミングでも同じ事が言えるが、 ソフトウェア完成間近で設計ミスによる変更等は時間(コスト)の大幅なロスである。 のちのち設計の仕方についても勉強をしていきたい。 以上、ソフトウェアテストについての備忘録??でした。

iOS 画像でスライドパズル

こんにちは、うさです。 本日からiOSの勉強を新しい参考書で行っていきました。 前回使っていた参考書が基本的なUI部品等の使い方だったのに対し、 本日から使いだした参考書はいきなり、画像を使ってのスライドパズルのアプリを作らされて 何を行っているのか理解する事が難しいです。 それでは、そのアプリのコードを載せます。 コメントを含めて書いていきましたが やっぱり難しい。 とりあえず、書いて見返してまた書くの繰り返しを行っていきます。 また、iOS8とiOS7ではだいぶライブラリが変更になっており、 iOS8では使えないものがたくさんあるので、 その辺も調べて、iOS8でも同じように表示できるようにしていきます。 因に今回利用させていただいた参考書はこちらです。 以上うさでした。

iOS 〜Mapの利用〜

こんにちは、本日はiOS8で「Map」の利用を行いました。 ここで問題が起きまして、 普通にマップ自体は表示できるのですが、 マップである地点をフォローボタンで現在地として設定したところ、 そのボタンを押すとエラーが出て、 その場所を表示できないのです。 このようなエラーメッセージが出てしまいました。 今利用している書籍はiOS7に対応しているもので、 iOS8から位置情報の取得の仕方が変わったらしいのです。 iOS7までがこの2パターンだったのに対し
  • 常に許可
  • 許可しない
iOS8では
  • 使用中のみ許可
  • 常に許可
  • 許可しない
の3パターンになってしまいました。 ということで、どうやれば位置情報を取得して 許可できるのかというと スクリーンショット 2015-02-04 16.03.12 画像の左にあるプロジェクトナビゲータのinfo.plistを開いて スクリーンショット 2015-02-04 16.04.01 赤く囲んである2つ追加します。 これらは、位置情報を常に許可するものとアプリを使用中のみ許可するものになります。 これを入れる事で、 デバイスの「プライバシー」>「位置情報」で取得できるようになります。 しかし、この状態だと、 わざわざ、設定の変更をしなければならないので、 Objective-Cのコード入力で位置情報が許可されているかどうかを確認して 許可されていなければ、常に許可や使用中のみ許可にすることが出来るようなのです。 しかし、色々試してみたのですが、どうもうまくいかなかったので、 今回は諦めてObjective-Cの知識がもっと付いた時にしっかりと理解しながら そのコードを書いて設定していきたいと思います。 因に今回書いたコードはこちらです。 左下に設定した位置情報のポイントに移動して、 右下は経度、緯度をブックマークした地点に移動します。 スクリーンショット 2015-02-04 16.20.33スクリーンショット 2015-02-04 16.21.30スクリーンショット 2015-02-04 16.21.40 (左:起動後のページ、中央:「Follow」でフォローした場所、右:ブックマークした場所) また今回の事については調べていきたいと思います。 以上うさでした。
スクリーンショット 2015-02-03 15.31.58

iOS 〜テキストフィールドのデリゲート〜

こんにちはうさです。 今回はデリゲートについて書いていきます。 デリゲート??初めて聞く用語ですね。 デリゲートとは こちらにも記述されている通り、 イベント等の処理の受付だけを行い、 処理は他のクラスに任せる事のようです。 処理を行う方法としては
  • デリゲートしたいクラスのデリゲートプロトコルの採用を宣言する。
  • デリゲートしたいインスタンスのdelegateプロパティにselfを設定する
  • デリゲートメソッドを実装して処理を定義する
といった事を行います。 デリゲートの大枠を掴めたところで 実際に例としてテキストフィールドを使っていきます。 まずは、Objectライブラリの中から「TextField」をドラッグ&ドロップします。 そのとき、Attributesインスペクタでテキストフィールドが空の時の文言や使用するキーボード等の設定を行います。 そして、先ほどのテキストフィールドをエディタへドロップしプロパティ宣言しました。 ここから、デリゲートプロトコルを宣言していきます。 「ViewControllerクラスのヘッダファイル」の@omterface ViewController:UIViewControllerの後ろにプロトコル宣言をします。 それがこちら 書き方は「<プロトコル>」となります。 続いてViewControllerクラスの実装ファイルに記述していきます。 コードがこちら デリゲートしたいインスタンスのdelegateプロパティにselfを設定するに当たるのがこちらの一行 self.myTextField.delegate = self; これでテキストフィールドのデリゲートになりました。 最後にデリゲートメソッドを記述します。 最初の行がそれに当たります。 以降がそのreturnキーの入力イベントを受け止める処理になります。 [self.view endEditing:YES]; はキーボードを下げる(引っ込める)ことを意味し NSLog(@”入力された文字&gt; %@” , self.myTextField.text); はテキストフィールドに入力された文字を出力します。 return NO; これはテキストフィールドに改行コードを入力しないことを表します。 アプリを起動してテキストフィールドをタップすると キーボードが出現します。 そして、returnキーを押すとキーボードが下がります。 スクリーンショット 2015-02-03 15.31.58 今回で書籍の半分以上終わりましたが、 まだまだわからないことが多いので、より多くのコードに触れて理解を深めていきます。 こちらはその書籍 以上うさでした。
スクリーンショット 2015-02-03 14.46.03

iOS 〜アニメーション〜

こんにちは、うさです。 本日もiOSアプリとObjective-Cの勉強をしていきましたので、 サンプルアプリを通して復習していきます。 アニメーションという事でイメージ画像を4つ用意して その画像を変化させる事で動いているようにみせるアプリを作りました。 今回のアプリを通して思った事は コードを書く作業よりも 画像やUI部品等の配置作業が多いなということです。 手順として、 1.4つのイメージ画像をプロジェクト内に用意して、 「Mediaライブラリ」から最初のイメージをドロップする。 2.イメージ画像に「Tap Gesture Recognizer」(タップするとアクションを起こす)をドロップ 3.イメージ画像をエディタへcontrolキー+ドラッグでプロパティの挿入 4.「Tap Gesture Recognizer」をエディタへcontrolキー+ドラッグでアクション接続 後は、コードを書くのですが、 恐らく10数行しか書いていないと思います。 こちらがそのコード それでは、僕が書いたコードがどんなことをしたのか確認していきます。 まずは、 アニメーションのイメージを入れる為の配列を用意します。 これは実際の値ではないので、ポインタ(*)が付いていますね。 続いてアニメーションを作るコードを書き込みます。 最初に、先ほど用意した配列に4つのイメージ画像を入れています。 次に self.frog.animationImages = animationSeq; はカエルのイメージビューにアニメーションの配列を設定しています。 animationDurationでアニメーションの長さ animationRepeatCountはアニメーションの繰り返しの回数を設定しています。 最後に アニメーションの再生と停止を切り替えています。 isAnimatingはアニメーションが再生中かどうかを判断します。 それをif文で再生したり、停止させたりしています。 以上が書き足したコードでした。 すると、 動きとしては スクリーンショット 2015-02-03 14.46.03スクリーンショット 2015-02-03 14.46.34スクリーンショット 2015-02-03 14.46.09スクリーンショット 2015-02-03 14.46.23 を3回繰り返すアプリとなります。 これをうまく使ってゲーム等を作っているのでしょうか!! 以上うさでした。
スクリーンショット 2015-02-02 15.12.33

iOS 〜初めてのObjective-C〜

こんにちは、うさです。 本日からiOSアプリの勉強を開始しました。 言語は「Objective-C」で開発していきます。 Objective-Cはもとより、 C言語すら勉強していない僕は記述方法から大苦戦です。 基本的なところからどんな意味を持つのかを勉強していきましたので、 僕の頭に叩き込む為に、書いていきます。 (書籍等を見ながら書いていきますが解釈の違いがあるかもしれません。) ということで、一つのアプリを例にとってみます。 そのアプリは「デートピッカーを使っての日数計算」するものです。 まずは、下記のようにウィジェットの配置をしていきます。 X-codeはドラッグ&ドロップで簡単に配置できて便利ですね!!(以前やったAndroidStudioもそうでしたが) スクリーンショット 2015-02-02 15.12.33 そして、アシスタントエディタへ接続してプロパティ宣言等を行い、 完成したコードがこちら!! 今まで勉強してきたJavaなどと違った記載のされ方なので、 インスタンスやメソッドが何をさしているのかわからないですねー!! 基本的なところを確認していくとは言ったものの、 X-codeをインストールした時点で記載が合あった箇所は省いて記述の仕方と意味を理解していきます。 それではまず、ラベルの初期表示するコード NSDateFormatterは日付の書式のクラスでObjective-CではクラスにNSが最初に付くみたいですね。 *formatterは変数なのですが「*」が前についているので何じゃこりゃ!!って感じです。 「*」はint型のように1や2等の実際の値が入るのではなく、 値が記録されているアドレス(参照先)を入れるらしいのです。 「=」の後を見ていって確認します。 [NSDateFormatter alloc]はNSDateFormatterインスタンスを作成し、 initメソッドで初期化を行っています。 これは、実際の値ではなく初期化されたインスタンスを変数formatterとするということですね。 なかなか使いどころが難しいですが、慣れるしかないですね。 で、やっと次の行ですが、 こちらは、formatterの書式を設定しています。 続いて self.toDay.textはJavaでも同じような記述をしていましたが、 「self(自分自身のインスタンス)」の「toDay(プロバティ)」が指している「text(テキスト)」に代入という事ですね。 何を代入するのかというと、 NSDateクラスのdateメソッドで本日の日付をstringFromDateでdate型からstring型へと変更しています 次の も先ほどと同じ値をselectedDataプロパティへ設定しています。 最後の日数の隣のラベルは 「@」は後ろの型を自動的に検知して表示します。 書式間違え等がなくなり、入力を短縮出来るわけですね。 これで、ラベルの初期値がすべて設定されました。 それでは、デートピッカーで設定した日付を検知して選んだ日付と日数に表示していきます。 アクション接続でのメソッドt定義として – (IBAction)changedDate:(UIDatePicker *)sender { と記載されます。 最初に付いている「-」はインスタンスに対して実行するインスタンスメソッドとのこと。 「+」もあり、それはクラスに対して実行するクラスメソッドだそう。 (これは後々理解していきます) IBActionはこのメソッドをUI部品と接続して使う事を示しています。 changedDateというメソッド名とし、 (UIDatePicker *)はデートペッカーという部品のクラスである事を示し、 senderはこのアクションの値になります。 それでは、このアクションについて。 最初の2行は全く同じ処理を行い、 日付の初期設定をしています。 3行目は self.selectedDate.text = [formatter stringFromDate:sender.date]; 「sender」つまりデートペッカーで選んだ日付をselectedDateに表示します。 4行目は toDay(現在の日付)をstring型からdate型へと変換しています。 そして デートピッカーの日付と現在の日付間の秒数を「timeIntervalSinceDate」で求めて秒数を示すインスタンスに代入しています。 その値を secs/(60 * 60 * 24)で”日”へ変更してroundで四捨五入し、numDaysへ代入 最後に days(日数)へnumDaysを代入しています。 すると、デバイスへの表示が以下のようになります。 スクリーンショット 2015-02-02 16.38.47 今回はいろんな♪記号等の意味を確認しながら一つの例を見ていきました。 明日以降もObjective-Cを勉強しながら、 iOSでアプリを作っていきます。 以上、うさでした。
スクリーンショット 2015-01-30 16.28.45

Android アクティビティ(アプリを実行)

こんにちは、うさです。 本日で今まで使っていた参考書が一通り終了しまして、 その最後のコンテンツが「アクティビティ」となります。 まず1つ目は、テキストデータの受け渡しのアクティビティです。 これはいくかの「XMLファイル(レイアウト)」を用意して、 それぞれの画面に移動するというものです。 まずは、メインページのコードです。 ボタンを3つ用意してそれぞれ違うページへ移動できるようにJavaで処理を行います。 スクリーンショット 2015-01-30 16.28.45 そして下記のコードがメインページに置けるjavaコードです。 こちらのコードで重要なのは です。 インテントを生成して、Intent()の第1引数でContextクラスのインスタンス、第2引数で対象のアクティビティが定義されています。 ここでは、「Activity1.class」を呼んでいます。 そして、その「Activity1」がこちらです。 finish()により、アクティビティが終了(停止状態)となり、元の画面へと移動する事になる。 その画面がこちら スクリーンショット 2015-01-30 16.36.06 ページは3つ作ったのですが、全て同じ画面表示と処理なので1つだけの記載とします。 続いては他のアプリケーションを呼んでアクティビティに表示します。 「http://」から始まる文字列を記入すると、Webブラウザを起動します。 また、「検索実行ボタン」の上に文字列を記入してボタンを押すと、ブラウザでそのキーワードを検索します。 そのレイアウトの「XMLファイル」がこちら スクリーンショット 2015-01-30 17.10.30 そして、ボタンクリックによりアプリを呼び出す為のコードを以下に示します。 それぞれの処理を見ていきます。 「ACTION_VIEW」でデータ表示というアクションを 「Uri.parse()」でテキストへ入力された文字列をURI形式に変更しています。 「検索実行ボタン」の処理はこちらで Web検索を指定するアクションの「ACTION_WEB_SEARCH」、 「putExtra()」でインテントに格納しています。 その第1引数の「SearchManager.QUERY」は検索文字列を示しており、第2引数で啓作文字列を設定しています。 本日で一通り終えたので、よりJavaの知識を身につける事とiOSの勉強に入っていきます。 以上うさでした。