タグ

ブックマーク / www.jpcert.or.jp (12)

  • MSC30-C. 疑似乱数の生成に rand() 関数を使用しない

    MSC30-C. 疑似乱数の生成に rand() 関数を使用しない 疑似乱数生成器は数学的アルゴリズムを用いて数列を生成する。生成される数列は統計的には十分な乱数特性を持つが、真にランダムではない。 C の標準関数 rand() には、生成する乱数列の特性についてなんの保証もない。rand() の実装によっては、生成される数値列の周期が比較的短くなってしまい、どのような値が生成されるか予測される恐れがある。良い乱数特性を必要とするアプリケーションは、必要とする乱数特性を持つことが保証されている擬似乱数生成器を使わなければならない。 違反コード 以下のコード例は、rand() 関数を使って生成された数値部分を持つ識別子を生成する。生成された識別子は予測可能であり十分にランダムではない。 #include <stdio.h> #include <stdlib.h> enum { len = 1

    MSC30-C. 疑似乱数の生成に rand() 関数を使用しない
  • IDS10-J. 一文字を構成するデータを分割しない

    過去のソフトウェアでは、文字列を構成する文字は8ビットであると想定していることが多い(Java のbyte 型)。Java 言語では文字列を構成する文字は16ビットである(Java の char 型)。残念ながら、byte 型、char 型のいずれも、すべての Unicode 文字を表現することはできない。多くの場合、文字列は UTF-8 エンコーディングで扱われる。UTF-8 では、1文字のサイズは可変長である。 Java の文字列は文字型データの配列あるいはバイト型データの配列として保存されるが、1文字を表すデータは byte 型や char 型データ1個ではなく、2つ以上の並びで表現されることがある。char 型や byte 型の配列を分割すると、多バイト文字を表すデータを分割してしまう危険がある。 補助文字、多バイト文字、結合文字(他の文字を変化させる文字)の存在を考慮しないと、攻

    IDS10-J. 一文字を構成するデータを分割しない
  • IDS11-J. 非文字コードポイントは検証を行う前に削除する

    Unicode 5.2 より前のいくつかのバージョンでは、適合性条件 C7 において、非文字コードポイント(noncharacter code points)を削除することを認めている。たとえば、Unicode 5.1 の適合性条件 C7 には以下のように記述されている[Unicode 2007]。 C7. valid な文字列の解釈を変えないようにするためには、プロセスは正準等価な文字列への変換および非文字コードポイントの削除以外の変換を行ってはならない。 Unicode Technical Report #36 「Unicode Security Considerations」[Davis 2008b] の セクション3.5 "非文字コードポイントの削除" には以下のように記述されている。 C7 の古いバージョンで認められていたような、暗黙のうちに文字を削除する動作(置き換えでなく)は

    IDS11-J. 非文字コードポイントは検証を行う前に削除する
  • MSC10-C. 文字の符号化 - UTF8 に関連する問題

    UTF-8 は元々 Plan 9 の開発者によって作成されたが [Pike 93]、Plan 9 自身は文字セットの下位16ビットの範囲だけをサポートしている。一般に、"Unicode" システムの多くは、21 ビットの ISO 10646 コード領域全体ではなく、下位16ビットの範囲だけをサポートしている [ISO/IEC 10646:2012]。 セキュリティに関する問題 [Yergeau 98] には以下のように書かれている。 UTF-8 の実装者は、無効な UTF-8 シーケンスの取扱いに関してセキュリティ面への影響を考慮する必要がある。攻撃者が、UTF-8の構文上認められないオクテットの並びを使って UTF-8 パーサを攻撃するというのは大いにあり得る話だ。 UTF-8 符号化形式の入力に対するセキュリティチェックを行うパーサに、巧妙な形式のデータを渡すことにより、特定の無効なオ

    MSC10-C. 文字の符号化 - UTF8 に関連する問題
    masakielastic2
    masakielastic2 2012/10/23
    U+1000..U+FFFF の範囲が正しくなく、U+1000..U+CFFF、U+D000..U+D7FF、U+E000..U+FFFF で異なる。RFC 3629 のセクション4 や Table 3-7 を参照。http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf
  • FIO02-C. 汚染された情報源から取得したパス名は正規化する

    FIO02-C. 汚染された情報源から取得したパス名は正規化する パス名、ディレクトリ名、およびファイル名には、検証することが難しい文字や正しくない文字が含まれていることがある。また、パス名の一部がシンボリックリンクの場合は、ファイルの実際の場所や同一性がさらにわかりにくい。ファイル名の検証を容易にするため、名前を正規化した形式に変換することを推奨する。ファイル名を正規化することで、パス名、ディレクトリ名、ファイル名を比較しやすくなり、検証がはるかに容易になる。 正規化形式はオペレーティングシステムやファイルシステムごとに異なる。オペレーティングシステム固有の仕組みを使用して正規化するのが望ましい。 一例として、パス名が POSIX システム上のユーザのホームディレクトリ内のファイルを参照することを確認する関数を示す。 #include <pwd.h> #include <unistd.h

    FIO02-C. 汚染された情報源から取得したパス名は正規化する
    masakielastic2
    masakielastic2 2012/09/19
    バッファオーバーフローの問題から realpath() を避けるよう man ページで呼びかけられてきた。POSIX.1-2008 で resolved_name に NULL ポインタを割り当てられるようになった。
  • Java コーディングスタンダード CERT/Oracle 版

    Top へ AA参考情報 References (CERT Oracle Secure Coding Standard for Java のページにとびます) 『Java セキュアコーディング 並行処理編』 Top へ BBGlossary Glossary (CERT Oracle Secure Coding Standard for Java のページにとびます) Top へ XXお問い合わせ ページに関するご質問・お問い合わせは、secure-coding@jpcert.or.jp までメールにてお願いいたします。 Top

    Java コーディングスタンダード CERT/Oracle 版
  • C/C++ セキュアコーディングセミナー資料 | JPCERT コーディネーションセンター

    これまでにC/C++ セキュアコーディングセミナーで使用した講義資料を公開しています。2010年度にセミナを実施した、文字列、整数、動的メモリ管理、書式指定文字列、CERT C セキュアコーディングスタンダード、ROSE については、それぞれ最新版の資料を掲載しています。 文字列 ユーザとソフトウエア間に発生するデータのやりとりの大部分は文字列によって行われます。 また、プログラム間でのデータ交換も文字列形式で行われるようになり、その結果、文字列表現や文字列管理、文字列操作における弱点がソフトウエア脆弱性を生み出しています。 文字列では、C/C++ 言語における文字列操作、一般的なセキュリティ上の欠陥と、その結果発生する脆弱性と対処方法について解説します。 C/C++ における文字列の特性 犯しやすい文字列操作の間違い 文字列の脆弱性 プロセスのメモリ構成 スタック破壊の仕組み コードイン

    C/C++ セキュアコーディングセミナー資料 | JPCERT コーディネーションセンター
  • セキュアなソフトウエア開発を支援する資料 | JPCERT コーディネーションセンター

    Java セキュアコーディング 並行処理編」 「Java セキュアコーディング 並行処理編」(原著 CERT/CC「Java Concurrency Guidelines」)は、カーネギーメロン大学ソフトウエア工学研究所の CERTプログラムと Oracle の共同作業の成果である「CERT Oracle Secure Coding Standard for Java」の中から、次のカテゴリに含まれる並行処理プログラミングに関連したガイドラインをまとめた資料です。 可視性とアトミック性(VNA) ロック(LCK) スレッドAPI(THI) スレッドプール(TPS) スレッドの安全性に関する雑則(TSM) セキュアな Java マルチスレッドプログラミングに取り組む際の手引きとしてご活用ください。 資料に記述されたガイドラインを含む「CERT Oracle Secure Coding S

    セキュアなソフトウエア開発を支援する資料 | JPCERT コーディネーションセンター
  • 新入社員等研修向け情報セキュリティマニュアル - JPCERT コーディネーションセンター

    新入社員等研修向け情報セキュリティマニュアル 企業や組織の教育担当者や情報セキュリティ担当者に向けて、新入社員等に情報セキュリティに関する知識を教える際のガイドライン、研修資料のベースとなるような情報やトピックをまとめたものです。 教育担当者や情報セキュリティ担当者向けのメッセージをコラム形式(「教育担当者・システム管理者の方へ」という囲み記事)で記載することで、新入社員向けのコンテンツとして直接利用できる部分と、そうでない部分を区別できるようにしています。 また、編の補助教材として、初心者にセキュリティ意識を高めてもらうために、簡単なクイズ形式により、考え方やアプローチを身につけることを意識するように工夫してあります。 編と併せて、セキュリティ対策やインシデント対応に関する社内ルールの教育、研修等にご活用ください。

    新入社員等研修向け情報セキュリティマニュアル - JPCERT コーディネーションセンター
  • JPCERT Coordination Centerソースコード解析ツールを活用した CERT セキュアコーディングルールの有効性評価報告書

    こちらはご意見・ご感想用のフォームです。各社製品については、各社へお問い合わせください。 ※フォームにいただいたコメントへの返信はできません。 返信をご希望の方は「お問合せ」 をご利用ください。

    JPCERT Coordination Centerソースコード解析ツールを活用した CERT セキュアコーディングルールの有効性評価報告書
    masakielastic2
    masakielastic2 2009/07/30
    ソフトウエア設計工程における脆弱性低減対策 「セキュアデザインパターン」
  • JPCERT コーディネーションセンター

    一般社団法人JPCERTコーディネーションセンター 〒103-0023 東京都中央区日町4-4-2 東山ビルディング8階 TEL: 03-6271-8901 FAX 03-6271-8908 ご利用にあたって プライバシーポリシー お問い合わせ モバイル向けコンテンツ © 1996-2024 JPCERT/CC

    JPCERT コーディネーションセンター
  • JPCERT C Secure Coding Standard 日本語版 - プリプロセッサ (PRE) (#c01)

    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 Programming Interface (API) 14. 並行性 (CON) 49. 雑則 (MSC) 50. POSIX (POS) AA. 参考情報 BB. Definitions CC. 未定義の動作 DD. 未規定の動作 XX. お問い合わせ 00はじめに このページ

    JPCERT C Secure Coding Standard 日本語版 - プリプロセッサ (PRE) (#c01)
  • 1