Movatterモバイル変換

セキュアコーディング方法論再構築の試みHASH コンサルティング株式会社徳丸浩

徳丸浩の自己紹介• 経歴– 1985年京セラ株式会社入社– 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍– 2008年 KCCS退職、HASHコンサルティング株式会社設立• 経験したこと– 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当– その後、企業向けパッケージソフトの企画・開発・事業化を担当– 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始– 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ• 現在– HASHコンサルティング株式会社代表 http://www.hash-c.co.jp/– 独立行政法人情報処理推進機構非常勤研究員 http://www.ipa.go.jp/security/– 著書「体系的に学ぶ安全なWebアプリケーションの作り方」(2011年3月)「徳丸浩のWebセキュリティ教室」(2015年10月)– 技術士（情報工学部門）Copyright © 2016 HASH Consulting Corp. 2

そもそもセキュアコーディングとは何だ?• 「脆弱性がない」を目指すだけでは、もはやセキュアコーディングとは言えない– セキュアコーディングでなくても、「脆弱性がないこと」は求められる• 「セキュアOS」と比べるとよい– 通常のOSも脆弱性がないことが求められる– セキュアOSは、脆弱性があっても攻撃を受けにくい、攻撃の影響が緩和されることを目指す• 以下の様なものではないか?– 脆弱性を解消する上で、もっとも確実な方法を採用する– 複数の対策を組み合わせて対策もれを防ぐ（多層防御）– 不測の事態により対策が回避されることを防ぐCopyright © 2016 HASH Consulting Corp. 4by @hebikuzure

Top 10 Secure Coding Practices (CERT)1. Validate input.2. Heed compiler warnings.3. Architect and design for security policies.4. Keep it simple.5. Default deny.6. Adhere to the principle of least privilege.7. Sanitize data sent to other systems.8. Practice defense in depth.9. Use effective quality assurance techniques.10. Adopt a secure coding standard.6https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

OWASP Top 10 Proactive Controls 20161. 早期に、繰り返しセキュリティを検証する2. クエリーのパラメータ化3. データのエンコーディング4. すべての入力値を検証する5. アイデンティティと認証管理の実装6. 適切なアクセス制御の実装7. データの保護8. ロギングと侵入検知の実装9. セキュリティフレームワークやライブラリの活用10. エラー処理と例外処理7OWASP Top 10 Proactive Controls 2016より引用

CERT C コーディングスタンダード• 00. はじめに• 01. プリプロセッサ (PRE)• 02. 宣言と初期化 (DCL)• 03. 式 (EXP)• 04. 整数 (INT)• 05. 浮動小数点 (FLP)• 06. 配列 (ARR)• 07. 文字と文字列 (STR)• 08. メモリ管理 (MEM)• 09. 入出力 (FIO)• 10. 環境 (ENV)• 11. シグナル (SIG)• 12. エラー処理 (ERR)• 13. Application ProgrammingInterface (API)• 14. 並行性 (CON)• 49. 雑則 (MSC)• 50. POSIX (POS)• AA. 参考情報• BB. Definitions• CC. 未定義の動作• DD. 未規定の動作8https://www.jpcert.or.jp/sc-rules/

Java セキュアコーディングスタンダード CERT/Oracle 版• はじめに• 00. 入力値検査とデータの無害化 (IDS)• 01. 宣言と初期化 (DCL)• 02. 式 (EXP)• 03. 数値型とその操作 (NUM)• 04. オブジェクト指向 (OBJ)• 05. メソッド (MET)• 06. 例外時の動作 (ERR)• 07. 可視性とアトミック性 (VNA)• 08. ロック (LCK)• 09. スレッド API (THI)• 10. スレッドプール (TPS)• 11. スレッドの安全性に関する雑則(TSM)• 12. 入出力 (FIO)• 13. シリアライズ (SER)• 14. プラットフォームのセキュリティ(SEC)• 15. 実行環境 (ENV)• 49. 雑則 (MSC)• AA. 参考情報• BB. Glossary9https://www.jpcert.or.jp/java-rules/

IDS00-J. 信頼境界を越えて渡される信頼できないデータは無害化する多くのプログラムは、認証済みでないユーザやネットワーク接続等、信頼できない情報源からデータを受け取り、それを（改変したり、あるいはそのまま）信頼境界（trust boundary）を越えて、信頼される側に渡す。多くの場合、データは、一定のシンタックスを持つ文字列であり、プログラム内部のサブシステムによって解析される。不正な形式の入力データには対応できないかもしれないし、インジェクション攻撃が含まれているかもしれないため、そのような入力データは無害化（sanitize）しなくてはならない。特にコマンドインタプリタやパーサに渡される文字列データはすべて、解析される文脈で無害な状態（innocuous）にしなければならない。コマンドインタプリタやパーサの多くは、独自の無害化メカニズムや検査機構を備えている。可能であれば、それらの無害化メカニズムを使用するほうが、独自に無害化メカニズムを実装するよりも好ましい。独自に実装した無害化メカニズムでは、特殊なケースやパーサの複雑な内部構造に配慮しない実装を行ってしまう可能性がある。それだけでなく、コマンドインタプリタやパーサに新しい機能が追加されたとき、無害化メカニズムが適切にメンテナンスされない恐れもある。10アーカイブ http://web.archive.org/web/20150515043831/ https://www.jpcert.or.jp/java-rules/ids00-j.html

11どのような場所で検証？ エントリーポイント ユーザによる入力 他システムとの連携ポイント 信頼境界 ここを超えるデータを検証信頼境界http://download.microsoft.com/download/3/e/e/3ee9501d-df73-41e9-baba-a1b4e41cb1ba/SecurityL100dataissue_6.ppt先程の現実世界の例と同様に、すべての入り口、つまりエントリポイントでデータを検証（チェック）すべきです。たとえば、SQLインジェクションは悪意のある、なしにかかわらず、ユーザが入力したデータを検証せずに、そのままSQL文の一部として利用してしまった場合に発生します。【中略】一方、すでに検証済みの信頼のおけるデータはそのまま利用することができます。先程の例では、高い塀の内側にある場合がそれです。この壁を信頼境界といいます。

14BOBBY TABLES IS WRONG. WHY?https://www.owasp.org/images/3/33/OWASP_Top_Ten_Proactive_Controls_v2.pptx

15'--@owasp.orghttps://www.owasp.org/images/3/33/OWASP_Top_Ten_Proactive_Controls_v2.pptx

16https://www.owasp.org/images/3/33/OWASP_Top_Ten_Proactive_Controls_v2.pptx1. update users set email='$NEW_EMAIL'where id=2904948282. $NEW_EMAIL = '--@owasp.org3. update users set email=''--@owasp.org'where id=290494828

IDS00-J. 信頼境界を越えて渡される信頼できないデータは無害化する多くのプログラムは、認証済みでないユーザやネットワーク接続等、信頼できない情報源からデータを受け取り、それを（改変したり、あるいはそのまま）信頼境界（trustboundary）を越えて、信頼される側に渡す。多くの場合、データは、一定のシンタックスを持つ文字列であり、プログラム内部のサブシステムによって解析される。不正な形式の入力データには対応できないかもしれないし、インジェクション攻撃が含まれているかもしれないため、そのような入力データは無害化（sanitize）しなくてはならない。特にコマンドインタプリタやパーサに渡される文字列データはすべて、解析される文脈で無害な状態（innocuous）にしなければならない。コマンドインタプリタやパーサの多くは、独自の無害化メカニズムや検査機構を備えている。可能であれば、それらの無害化メカニズムを使用するほうが、独自に無害化メカニズムを実装するよりも好ましい。独自に実装した無害化メカニズムでは、特殊なケースやパーサの複雑な内部構造に配慮しない実装を行ってしまう可能性がある。それだけでなく、コマンドインタプリタやパーサに新しい機能が追加されたとき、無害化メカニズムが適切にメンテナンスされない恐れもある。17アーカイブ http://web.archive.org/web/20150515043831/ https://www.jpcert.or.jp/java-rules/ids00-j.html

IDS00-J. 信頼境界を越えて渡される信頼できないデータは無害化する違反コード以下の違反コード例は、ユーザ認証を行うJDBCのコードを示している。パスワードはchar型配列として渡され、データベースへの接続が作成され、パスワードがハッシュ化されている。残念ながらこのコードはSQLインジェクション攻撃を許してしまう。SQL文 sqlString は無害化されていない入力値を受け付けており、前述の攻撃シナリオが成立してしまうだろう。適合コード (PreparedStatement)幸いJDBCライブラリはSQLコマンドを組み立てるAPIを提供しており、信頼できないデータを無害化してくれる。java.sql.PreparedStatementクラスは入力文字列を適切にエスケープ処理するため、適切に利用すればSQLインジェクション攻撃を防ぐことができる。これはコンポーネントベースで行う無害化の一例である。この適合コードでは java.sql.Statement の代わりに PreparedStatementを使用するようにdoPrivilegedAction() メソッドを変更している。また、引数 username の長さを検証しており、攻撃者が任意に長いユーザ名を送り込むことを防止している。18アーカイブ http://web.archive.org/web/20150515043831/ https://www.jpcert.or.jp/java-rules/ids00-j.html

22https://www.jpcert.or.jp/java-rules/ids00-j.htmlまさかの「SQLインジェクションを防ぐ」信頼境界も、信頼できないも、無害化もタイトルから消えた

「安全なウェブサイトの作り方」に出てくる信頼境界の例• SQLインジェクション– ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない。• OSコマンドインジェクション– Perlのopen関数は、引数として与えるファイルパスに「|」（パイプ）を使うことでOSコマンドを実行できるため、外部からの入力値を引数として利用する実装は危険です• ディレクトリトラバーサル– 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける– ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。• XSS– 入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する– 入力されたHTMLテキストから、スクリプトに該当する文字列を排除するCopyright © 2016 HASH Consulting Corp. 27

「信頼されたデータ」が要求される例• 信頼境界の中のデータ– プログラムコード– SQL文– evalの入力– 設定ファイル名に記載されたファイル名– 正規表現– オブジェクト• アプリケーションで「信頼できることを確認」– ログイン済みユーザ名（認証）– 管理者が入力するSQL文（認可）– CMSに入力するHTML（認可）– 制限されたHTML（フィルタリング）– 外部からのファイル名（basename）Copyright © 2016 HASH Consulting Corp. 28

信頼に関して…• 安全に使う方法があれば「信頼」を気にしない– SQL文のプレースホルダにバインドする値– シェルを経由しないコマンド呼び出しのパラメータ– 安全なメール送信APIに渡すメールアドレス• 信頼するしかないデータもある– プログラムコード、SQL文そのもの– evalの入力、正規表現– オブジェクト• 認証やフィルタリングにより「信頼」できる場合– basename関数を通したファイル名– 認証されたユーザ名– 権限を認可されたSQL文、HTMLテキストCopyright © 2016 HASH Consulting Corp. 29

phpMyAdmin: CVE-2013-3238Copyright © 2016 HASH Consulting Corp. 30case 'replace_prefix_tbl':$current = $selected[$i];$newtablename = preg_replace("/^" . $from_prefix . "/", $to_prefix, $current);preg_replace("/^/e0/", "phpinfo();", "test");preg_replace("/^/e", "phpinfo();", "test");$from_pref = "/e0“;$to_prefix = "phpinfo();”;PHP5.4.3以前では、0以降は無視される

脆弱性が混入した要因• preg_replaceに渡す正規表現をエスケープしていなかった– 最低限、/ をエスケープする必要がある• えーっと、preg_quoteって、マルチバイト対応だっけ?– Shift_JIS以外では問題ない?• そもそも、正規表現を外部から（信頼境界を超えて）渡す実装は避けるべき（実際にもその方向で改修された）Copyright © 2016 HASH Consulting Corp. 31preg_replace(“/^” . $from_prefix . “/”, …↓reg_replace("/^" . preg_quote($from_prefix, '/') . "/", …

Joomla2.5.2の権限昇格脆弱性攻撃の流れ1. 会員登録時にパスワードを不整合にしておく2. ユーザ登録時に jforms[groups][]=7 をPOSTパラメータに追加3. バリデーションでエラー発生4. 再入力に備えてリクエストのパラメータをすべてセッションに保存（コントローラ）5. モデル側で、セッションの中味をすべて取り込み6. 2.で追加したgroupsが取り込まれるCopyright © 2016 HASH Consulting Corp. 32

Joomla2.5.2の権限昇格脆弱性components/com_users/controllers/registration.php register()関数$data = $model->validate($form, $requestData);// Check for validation errors.if ($data === false) {// Save the data in the session.$app->setUserState('com_users.registration.data', $requestData);// Redirect back to the registration screen.$this->setRedirect(JRoute::_('index.php?option=com_users&view=registration', false));return false;// 中略// バリデーションが正常の場合// Flush the data from the session.$app->setUserState('com_users.registration.data', null);Copyright © 2016 HASH Consulting Corp. 33バリデーションエラーの場合、リクエストデータをまるごとセッション変数に放り込んでいる権限の情報も含まれている

components/com_users/models/registration.php getData() 関数内$temp = (array)$app->getUserState('com_users.registration.data', array());foreach ($temp as $k => $v) {$this->data->$k = $v; // セッションのデータをモデルに放り込んでいる}【中略】$this->data->groups = isset($this->data->groups) ? array_unique($this->data->groups) : array();// $this->data->groups = array(); 2.5.3でこのように修正Copyright © 2016 HASH Consulting Corp. 34セッション汚染、Trust Boundary Violationと呼ばれる問題

OWASP Top 10 Proactive Controls 20161. 早期に、繰り返しセキュリティを検証する2. クエリーのパラメータ化3. データのエンコーディング4. すべての入力値を検証する5. アイデンティティと認証管理の実装6. 適切なアクセス制御の実装7. データの保護8. ロギングと侵入検知の実装9. セキュリティフレームワークやライブラリの活用10. エラー処理と例外処理35OWASP Top 10 Proactive Controls 2016 より引用順序に注意

入力チェックとセキュリティに関する補足入力チェックの段階では、信頼できない入力値を「無害な状態に」変換してしまう必要はありません。危険と思われるデータも「正しいデータ」として受け入れなければならない場合があります。アプリケーションのセキュリティは、入力値が実際に使われる箇所で担保されるべきです。たとえば、入力値をHTMLの一部として出力するのであれば、クロスサイトスクリプティング対策としてHTMLエンコーディングを実装します。同様に、入力値をSQL文の一部として使うのであれば、クエリーのパラメータ化を使います。どのような場合であれ、セキュリティ対策を入力チェックに依存してはいけません。OWASP Top 10 Proactive Controls 2016 より引用 36

セキュアコーディングをこう分類したい• 脆弱性を解消する「まさにその場所での対策」– プレースホルダを用いてSQL文を呼び出す…• 緩和策を実施する– バリデーション– 最小権限• 前提条件を確認する– 引数チェック・戻り値チェック– 防御的プログラミング• バグの少ない開発に役立つ習慣– コンパイラのエラーを無視しない– 暗黙の型変換を避ける– …Copyright © 2016 HASH Consulting Corp. 38

Drupalのログイン処理のSQL文を調べるCopyright © 2012-2014 HASH Consulting Corp. 41name=admin&pass=xxxxxxxx&form_build_id=form-xQZ7X78LULvs6SyB9MvufbZh5KXjQYRHS05Jl2uD9Kc&form_id=user_login_block&op=Log+inSELECT * FROM users WHERE name = 'admin' AND status = 1name[]=user1&name[]=user2&pass=xxxxxxxx&form_build_id=form-xQZ7X78LULvs6SyB9MvufbZh5KXjQYRHS05Jl2uD9Kc&form_id=user_login_block&op=Log+inSELECT * FROM users WHERE name = 'user1', 'user2' AND status = 1通常時の要求通常時のSQL文nameを配列で指定nameを配列にした場合のSQL文文字列リテラルが複数生成される

IN句生成の便利な呼び出し方だが…Copyright © 2012-2014 HASH Consulting Corp. 42<?phpdb_query("SELECT * FROM {users} where name IN (:name)",array(':name'=>array('user1','user2')));?>SELECT * from users where name IN (:name_0, :name_1)array(':name_0'=>'user1', ':name_1'=>'user2'))db_queryにてIN句のバインド値を配列にすると…IN句の値がプレースホルダのリストに展開されるバインド値の配列は以下の様に変形される

空白付きのキーCopyright © 2012-2014 HASH Consulting Corp. 44array(2) {[":name_1 xxxxx"] => "user1" ← :name_1 ではない[":name_2"] => "user2"}SELECT * FROM {users} WHERE name = :name_1 xxxxx, :name_2 ANDstatus = 1キー名に空白をつけてみるプレースホルダに空白が含まれるちぎれたプレースホルダはSQL文の一部として認識されるプレースホルダには、キー :name_1がないので上記のSQL文呼び出しはエラーになるname[1 xxxxx]=user1&name[2]=user2

バインド値のつじつまを合わせるCopyright © 2012-2014 HASH Consulting Corp. 45array(2) {[":name_2 xxxxx"] => ""[":name_2"] => "user2"}SELECT * FROM {users} WHERE name = :name_2 xxxxx, :name_2 AND status = 1キー名に空白をつけてみるプレースホルダに空白が含まれるプレースホルダ :name_2 が2箇所現れるプレースホルダ配列は上記SQL文の要求を満たすのでSQL文は呼び出される…が、xxxxxの箇所でSQLの文法違反となるname[2 xxxxx]=&name[2]=user2

SQLインジェクションを試すCopyright © 2012-2014 HASH Consulting Corp. 46SELECT * FROM users WHERE name = 'user2' ;SELECT sleep(10) -- , 'user2' AND status = 1キー名に追加のSQL文を書く実際に呼び出されるSQL文name[2 ;SELECT sleep(10) -- ]=&name[2]=user2SELECT * FROM {users} WHERE name = :name_2 ;SELECT sleep(10) -- ,:name_2 AND status = 1プレースホルダの後ろに追加のSQL文が現れる

脆弱なソース// includes/database/database.incprotected function expandArguments(&$query, &$args) {$modified = FALSE;// $argsの要素から配列のみ処理対象として foreachforeach (array_filter($args, 'is_array') as $key => $data) {$new_keys = array();// $dataは配列であるはずなので、foreach 可能。 $i（キー）に注目foreach ($data as $i => $value) {$new_keys[$key . '_' . $i] = $value;}// $queryを改変 $new_keysのキーをarray_keysでSQL文に混ぜている$query = preg_replace('#' . $key . 'b#',implode(', ', array_keys($new_keys)), $query);unset($args[$key]);$args += $new_keys;$modified = TRUE;}return $modified;}Copyright © 2012-2014 HASH Consulting Corp. 47

対策版// includes/database/database.incprotected function expandArguments(&$query, &$args) {$modified = FALSE;// $argsの要素から配列のみ処理対象として foreachforeach (array_filter($args, 'is_array') as $key => $data) {$new_keys = array();// $dataは配列であるはずなので、foreach 可能。 $i（キー）に注目//foreach ($data as $i => $value) {foreach (array_values($data) as $i => $value) { // キーを削除$new_keys[$key . '_' . $i] = $value;}// $queryを改変 $new_keysのキーをarray_keysでSQL文に混ぜている$query = preg_replace('#' . $key . 'b#',implode(', ', array_keys($new_keys)), $query);unset($args[$key]);$args += $new_keys;$modified = TRUE;}return $modified;}Copyright © 2012-2014 HASH Consulting Corp. 48アドホックな対策にも見えるが、入力値が実際に使われる箇所で担保していることが重要

50http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-005632.html より引用想定される影響第三者により、巧妙に細工されたリクエストを介して、サービス運用妨害 (CPU 資源およびメモリの消費)状態にされる可能性があります。

巧妙に細工されたリクエスト…とは?POST /drupal731/?q=node&destination=node HTTP/1.1Host: example.jpUser-Agent: MozillaCookie: has_js=1Connection: keep-aliveContent-Type: application/x-www-form-urlencodedContent-Length: 10114name=admin&pass=1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890……..…1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890&form_build_id=form-Fw_Sa9fPZ5wQBHOURorm7aOILRlK2KXropvxrELFKtc&form_id=user_login_block&op=Log+inCopyright © 2012-2014 HASH Consulting Corp. 51100万バイトのパスワード

パスワードハッシュ値の計算部分function _password_crypt($algo, $password, $setting) {// ...// Convert the base 2 logarithm into an integer.$count = 1 << $count_log2; // $count は32768となる// We rely on the hash() function being available in PHP 5.2+.// ソルトとパスワードを連結したもののSHA-512ハッシュを求める$hash = hash($algo, $salt . $password, TRUE);do {// これまでのハッシュ値とパスワードを連結したもののSHA-512ハッシュ$hash = hash($algo, $hash . $password, TRUE);} while (--$count); // 32768回繰り返し$len = strlen($hash);$output = $setting . _password_base64_encode($hash, $len);$expected = 12 + ceil((8 * $len) / 6);return (strlen($output) == $expected) ? substr($output, 0, DRUPAL_HASH_LENGTH) : FALSE;}Copyright © 2012-2014 HASH Consulting Corp. 52

対策版function _password_crypt($algo, $password, $setting) {// Prevent DoS attacks by refusing to hash large passwords.if (strlen($password) > 512) {return FALSE;}// 後は同じ…}Copyright © 2012-2014 HASH Consulting Corp. 53アドホックな対策にも見えるが、入力値が実際に使われる箇所で担保していることが重要

MySQL: こうなる: name=‘tana’ + ‘ka’mysql> SELECT * FROM members WHERE name='tanaka';+----+--------+-------------------+| id | name | email |+----+--------+-------------------+| 8 | tanaka | tanaka@example.jp |+----+--------+-------------------+mysql> SELECT * FROM members WHERE name='tana'+'ka';+----+-----------+---------------------+| id | name | email |+----+-----------+---------------------+| 4 | tokumaru | tokumaru@example.jp || 5 | sato | sato@example.jp || 6 | yamada | yamada@example.jp || 8 | tanaka | tanaka@example.jp || 9 | suzuki | suzuki@example.jp |+----+-----------+---------------------+5 rows in set, 8 warnings (0.00 sec)Copyright © 2016 HASH Consulting Corp. 56まさかの全件一致暗黙の型変換が原因

MySQLの「暗黙の型変換の罠」• ‘tana’ + ‘ka’ は ‘tana’ と ‘ka’ の算術加算• MySQLは、算術加算のオペランドを数値に「暗黙に」型変換するちなみに浮動小数点数になる）• name = ‘tana’ + ‘ka’ は name=0 と同じ• 列nameが文字列型の場合、name列を数値に変換してから比較する• すなわち、’yamada’ = 0 となる →まさかの ‘yamada’ = ‘tana’ + ‘ka’Copyright © 2016 HASH Consulting Corp. 57

再(まとめとして) : セキュアコーディングをこう分類したい• 脆弱性を解消する「まさにその場所での対策」– プレースホルダを用いてSQL文を呼び出す…• 緩和策を実施する– バリデーション– 最小権限• 前提条件を確認する– 引数チェック・戻り値チェック– 防御的プログラミング• バグの少ない開発に役立つ習慣– コンパイラのエラーを無視しない– 暗黙の型変換を避ける– …Copyright © 2016 HASH Consulting Corp. 58

Movatterモバイル変換

Change Language

セキュアコーディング方法論再構築の試み

Embed presentation

Recommended

More Related Content

What's hot

Similar to セキュアコーディング方法論再構築の試み

More from Hiroshi Tokumaru

セキュアコーディング方法論再構築の試み