CWE-20は知られているか？ 〜 開発者必修のNo.1脆弱性のハズが知られていない 〜
(Last Updated On: 2021年6月17日) CWE-20とは何か？と聞かれて即答できる開発者は多くないと思います。そもそもCWEとは何か？もあまり知られていないかも知れません。 実はCWE-20 不適切な入力バリデーション はソフトウェアセキュリティで最も重要な脆弱性とされています、CWEのみでなく情報セキュリティ標準的に情報セキュリティ関連法的にも。 ※ CWE: Common Weakness Enumeration (共通脆弱性タイプ) CWEは脆弱性識別子のCVEで有名なMITRE（米国でのIPAの様な組織）が管理するソフトウエア脆弱性パターンを列挙したドキュメント／データベースです。日本語名の通り、よくある共通のソフトウェア脆弱性を集めた物がCWEです。 CWE-20の解説 – CWE/SANS Top 25 Monster Mitigation M1 実は態々私
正規表現でのメールアドレスチェックは見直すべき – ReDoS
(Last Updated On: 2018年8月13日)前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。 結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー） 追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイト
2要素認証のTOTPとHOTP、どちらがより安全か？
(Last Updated On: 2018年8月18日)今すぐできる、Webサイトへの2要素認証導入では簡単に2要素認証が導入できること、2要素認証には 時間ベースのOTP（TOTP：Time-based One Time Password RFC 6238) カウンターベースのOTP（HOTP：HMAC-based One-Time Password RFC 4226） があることを紹介しました。Google認証は両方をサポートしています。※ ※ 今すぐできる、Webサイトへの2要素認証導入で紹介したライブラリはTOTPのみサポートしています。 TOTP、HOTPのどちらを導入してもユーザー名とパスワードのみによる認証に比べ、より高いアカウント（認証）の安全性を維持することができます。しかし、TOTPはHOTPに比べ以下の理由で脆弱です。 TOTPは特定の時間内なら何度でも利用できる（
徳丸さんのブログに対するコメント
(Last Updated On: 2018年8月4日)最初、書いた時はユーザーが一人だけと頭にあったので思いっきり誤解していました。確かに複数ユーザーの場合は真正性に問題があります。修正版の差分をアーカイブを更新しておきました。 本題のブログはこちらです。 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CREATE TABLE form_id (sha1 TEXT PRIMARY KEY, created TEXT NOT NULL) sha1がトークン、createdが生成日時を保持します。 シンプルな構造ですが、これだとトークンは、ユーザーやセッションを超えて、アプリケーション全体
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイド
(Last Updated On: 2018年8月4日)単純にこういった定義や標準があります、と紹介してもなかなか原文を参照することは敷居が高いです。このブログでも色々紹介できてきたので、ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドなどをまとめて紹介します。 セキュリティ対策の定義 そもそも定義を間違えていたら、ボタンの掛け違いは止まりません。まず、正しい定義を理解しなけばなりません。ソフトウェアのセキュリティといっても、他のセキュリティ対策の定義と基本は同じです。ISO 27000では広範囲なITセキュリティの対策を定義しています。勿論、用語の定義もあります。 ISO 27000のセキュリティ対策の定義 標準と基本概念から学ぶ正しいセキュリティの基礎知識 ざっくり言うと、基本的にはセキュリティ対策の本質は緩和策である、と理解していれば良いでしょう。 ISO 2700
PHPに無いセキュリティ機能 – PHPカンファレンス関西2015
(Last Updated On: 2018年8月13日)PHPカンファレンス関西に参加してきました。私のセッションの資料をPDFまたはSlideshareで見れるようにしました。 PHPにないセキュリティ機能（PDF） ここに書いたPHPに無い機能ですが、他の言語／フレームワークでも無い物の多いです。PHPに限った話しではありません。言語／ライブラリに潜む脆弱性もPHPに限った話しではありません。他の言語やPHP＋フレームワークで利用されている方も十分注意してください。 このスライドを見れば何故私が「出力のセキュリティ対策としてエスケープ（エンコード）を第一に考えるべき」と解説しているのか解ると思います。 「入力をセキュリティ対策としてバリデーションしない」「出力のエスケープをセキュリティ対策として考えない」これらは攻撃者と一部のセキュリティ業者を喜ばせるだけで、開発者とシステムの利用者
SHA1でハッシュ化したパスワードは危険になった
(Last Updated On: 2018年4月3日)パスワードを平文で保存するのは論外で、MD5やSHA1でハッシュ化するのは当たり前です。しかし、SHA1を2000倍早くクラックする方法などが発見され「SHA1は脆弱だ」（ちなみにMD5はもっと危険）とされてからしばらく経ちます。アメリカ政府や大手企業はSHA1は使わない、としています。 Slashdot.orgにまた載っているので更に高速化できた、ということか? 参考： RainbowテーブルによるMD5ハッシュのクラック（英語） RainbowテーブルによるSHA1ハッシュのクラック（英語） 前のエントリ PostgreSQLでSHA1 でPostgreSQLでSHA1を使う方法の一つを紹介していますが可能であればSHA512など、より強いハッシュ関数を利用したり、Saltを利用する、等の方法を採用した方が良いと思います。 備考：
PHP7のタイプヒントベストプラクティス
(Last Updated On: 2018年9月26日)PHP 7から基本的なデータ型（整数型、浮動小数点型、配列型）タイプヒントが追加されます。直感的に書くコードと正しいコードには乖離があります。PHP7でタイプヒントを使う場合のベストプラクティスを紹介します。 タイプヒントとタイプヒントの問題点については前回のブログを参照してください。 PHP7タイプヒントの注意点 PHPはWebシステムで利用され、データベースやJSONなどの外部データとのやり取りが必要になります。PHP7のタイプヒントはデータ型変換を伴うので 入力データの形式／表現範囲 PHPデータ型の表現範囲 タイプヒント／キャストの動作 に注意する必要があります 入力データの形式 データベースの場合、入力データは基本的に”文字列”になります。データベースのデータ型をPHPなどの言語のデータ型と完全に一致するとは限りません。こ
安全なAPI過信症候群の処方箋 – execv/SQLite3編
(Last Updated On: 2018年8月13日)またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。 安全なAPI過信症候群（同類にプリペアードクエリ過信症候群など）：「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。 このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
