サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
衆院選
blog.ohgaki.net
(Last Updated On: 2021年6月29日) Gigagineで比較的珍しいバグが見つかったことを記事にしています。 「％p％s％s％s％s％n」というSSIDのネットワークに接続すると、iPhoneのすべてのWi-Fi関連機能が無効になってしまう https://gigazine.net/news/20210620-specific-network-name-disable-wi-fi-iphone/ 「セキュリティって難しいんだな」と感じるニュースではなく「大手でも基本が出来てないんだな」と思えれば、似たような問題で困ることが無くなります。 問題の原因 問題の原因は引用記事の予想通りだと思います。フォーマット文字列を使ったデータ出力関数の出力処理が問題のはずです。 上記のようなフォーマット文字列を使ったAPIを使用する箇所で「エスケープ無し文字列」、記事の問題の場合はSS
(Last Updated On: 2021年6月17日) JSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択／クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。 JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。 https://jsonpath.com/ JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。 典型的なJSONPathインジェクション 典型的なJSONPathインジェクションはSQLインジェクションやXPathインジェクションと同
(Last Updated On: 2020年1月27日) 同じ処理を行うコードの共通化は、基本的には、ベストプラクティスです。しかし、アンチプラクティスとなる場合もあります。 コードの共通化（モジュール化）が原則とされた時代もあった コードの共通化（モジュール化）とは、同じ／同類の処理を関数などに定義し、同じ処理を繰り返し書かない様にすることです。 先に書いた通り、コードの共通化、は基本的にはベストプラクティスです。このため、大昔は”プログラミングの基本原則”として扱われていた時代もありました。しかし、現代では”プログラミングの基本原則”とは考えられていません。 コードの共通化（モジュール化）とは、同じ／同類の処理を関数などに定義し、同じ処理を繰り返し書かない様にすることは当然の事で絶対にしなければならないことでは？なぜアンチプラクティスになるのか？と思ったかも知れません。 TL;DR;
(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 実は態々私
(Last Updated On: 2019年2月5日) 7PKという用語を聞いた事がある開発者も多いと思います。7PKは業界標準のソフトウェアセキュリティ分類です。まだの方はこれを機会に是非覚えてください。CERT Top 10 Secure Coding Practicesと同じく開発者全員に必修の用語と概念と言えます。何故なら、CERT Top 10 Secure Coding Practicesも7PKも知らないのならISO 27000(ISMS)、NIST SP800-171に対応するアプリケーションは作れないからです。 ※ 7PKやCERTセキュアコーディング原則を知らなくても、セキュアなソフトウェアを作ることも可能かも知れません。しかし、それはかなり遠回りになるでしょう。 7PK 〜 Seven pernicious kingdoms: a taxonomy of softw
(Last Updated On: 2019年2月1日) IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。 重大な誤りとは以下です。 CWE-20 – 出鱈目なデータを排除する検証（入力バリデーション）について一切記載がない コンピューターサイエンス／システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング／セキュアプログラミングの導入を要求しています。 ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題
(Last Updated On: 2018年12月2日) PHP 7.3が今月（2018/12）リリース予定です。新機能や機能変更は小振りですが、結構多くの追加／変更があります。ソースコード中のUPGRADINGに変更点は記載されています。ここでは独断と偏見で選んだ重要度が高い追加／変更を紹介します。 ※ PHP 7.3.0 RC6時点のUPGRADINGから紹介します。 記載していない変更の方が多いです。詳しくはリリース版のUPGRADINGを参照してください。 エラー処理の強化 バンドルされているモジュールのエラー処理はお世辞にも理想的と言える処理ではなかったモノがあります。これらのエラー処理が改善されました。エラーの発生の仕方やエラー発生後の動作が異なることになります。これでは困る事になるかも？と思うかも知れませんが、おかしな動作を起こすデータやコード、はそもそも問題の原因です。問
(Last Updated On: 2019年2月5日) セキュアコーディング／セキュアプログラミングはコンピューター動作の基礎的原理から構築されています。初めてプログラムが書かれた時から現在に至るまで、全てのプログラムは同じ基本構造を持っています。 基本原理／基本構造に合わないセキュリティ対策/構造では満足できるセキュリティ状態の達成は不可能です。残念ながら大半のWebアプリが原理に反する脆弱な構造を持っています。 IPAが出鱈目なセキュアプログラミングを啓蒙していた責任は大きいと言わざるを得ないでしょう。昨年、修正しましたが誤りを訂正すべく十分な啓蒙を行っているとは言えないように見えます。 はじめに セキュアコーディング原則よりも更に基礎的な2つの原則があります。 ゼロトラスト – 一切信頼しない、安全性が検証されたモノ以外。フェイルファースト – 失敗するモノはできる限り早く失敗させ
(Last Updated On: 2018年10月18日) インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。 この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。（もしくは気付いていても公開していない） 侵入されたことを検知／対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか？を考えます。 ※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。 セキュリティの基本が
(Last Updated On: 2022年10月1日) Attack Surface （攻撃可能面=攻撃可能な箇所）の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。 攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析（＝リスク分析）します。その上でできる限り攻撃可能な箇所を削減（＝リスク削減）します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。 Attack Surface (攻撃可能面) The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attack
(Last Updated On: 2018年8月13日)CORS問題でAJAXリクエストが失敗する場合の対策として、CORSを設定を紹介しているところまでは良いのですが、他のオプションとしてJSONPを挙げているページを見つけました。記事作成が2018年4月になっていたのでつい最近のことです。あまり知られていないようです。 誤解の無いよう正確に書いておきます。誰かに見られて困るデータが含まれる場合、JSONPは禁止です。 JSONP (JSON with padding) とは、scriptタグを使用してクロスドメインな（異なるドメインに存在する）データを取得する仕組みのことである。HTMLのscriptタグ、JavaScript（関数）、JSONを組み合わせて実現される。 https://ja.wikipedia.org/wiki/JSONP XHRだとサイト間をまたいでデータ共有でき
(Last Updated On: 2019年2月2日)一応、PHPの危い関数リスト、は存在します。例えば、以下のような物があります。 StackOverflow DangerousPHPFunction 後者は主にホスティング環境（？）でリスクがある関数の一覧を作るプログラムのようです。 ファイルを操作する関数、コマンドやスクリプトを実行する関数などのリスクは自明だと思います。少し趣向を変え、間違えて使うと危い関数の一覧を独断と偏見で作ってみました。 【重要】こういった「危険な物」を定義するのはブラックリストです。ブラックリストは仕組的に危険です。ブラックリストに頼るのは脆弱性を作るような物です。ブラックリスト”だけ”で安心しないでください。最後にどうすれば良いのか？を書きます。 hash_hkdf() hash_hkdf()は秘密鍵から実際に利用する鍵を導出する関数です。鍵を作る関数な
(Last Updated On: 2018年8月9日)Webブラウザに対するJavaScriptコードのインジェクションは サーバー側のコードが原因（サーバー側のPHP、Ruby、Python、JavaScriptが原因） クライアント側のコードが原因（クライアント側のJavaScriptが原因） サーバーとクライアント（上記の両方） で起きる可能性があります。ここでは主にクライアント側が関係するケースで注意しなければならない箇所を紹介します。 どこが危険なのか？ ブラウザ上のJavaScriptの場合、ECMAScriptの基本として実装されている機能、DOM機能として実装されている機能があります。更にこの他にもHTMLやCSS機能もあり複雑です。SVGなどこの他の標準にもJavaScriptが記述できるモノがあります。 JavaScriptを実行可能となる部分へユーザー入力データを出
(Last Updated On: 2018年8月13日)PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを１つインクルードする以外、ほとんど何も行う必要がありません。 CSRF Protection for PHPの機能 自動的にHTMLフォームやリンクにCSRFトークンを追加 CSRFトークンの有効期限を設定可能 まだまだ多くのアプリケーションが固定かつ有効期限を設定しないのCSRFトークンを使っています。この状態では一旦CSRFトークンを盗まれると、攻撃者にいつまででも攻撃される可能性があります。 このスクリプトの場合、有効期限付きのCSRFトークンをWebページに自動追加して防御します。 後で記載するようにPHP 7.1でoutput_rewrite_var()のバグを完全に直しました。なのでPHP 7.1以降の利用がお勧
(Last Updated On: 2018年11月15日)形式的検証とは 形式的検証（けいしきてきけんしょう）とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法や数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである 英語ではFormal Verificationとされ formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. と説明されていま
(Last Updated On: 2018年8月3日)往年のWeb開発者であれば X-Content-Type-Options: nosniff はIE専用のオプションHTTPヘッダーだと理解している方が多いと思います。 この理解は正しかったのですが、現在は正しくありません。nosniffはChromeやFirefoxの動作にも影響与えます。このため、IEをサポートしないサイトであっても X-Content-Type-Options: nosniff は必要なHTTPヘッダーです。 なぜ X-Content-Type-Options: nosniff はIE以外にも必要になったのか？ 主な理由はJSONPの動作にあります。 そもそもJSONは最初から標準規格として利用され始めた仕組みではありません。”JavaScriptのコード”として定義されたオブジェクトがデータとして扱えるので、それ
(Last Updated On: 2018年11月9日)セキュアコーディングの第1原則は「入力をバリデーションする」です。セキュアコーディングの第1原則はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。 入力バリデーションを第一のセキュリティ対策としているガイドライン： CERT Top 10 Secure Coding Practices OWASP Secure Coding ‐ Quick Reference Guide CWE/SANS Top 25 Monster Mitigations IPA セキュアプログラミング講座（NEW 2017年～） セキュアプログラミング／セキュアコーディングを要求するセキュリティ認証： ISMS – 国際情報セキュリティ標準 ISO 27000 の認証規格 PCI DSS – クレジットカード情報を取り扱う場合の認証規格 9
(Last Updated On: 2018年8月31日)ここ十数年で見聞きした、脆弱なアプリを作ってきたベストプラクティスもどきのアンチプラクティス、をリストアップしてみます。 限定された条件ではベストプラクティスと言える物でも、一般化するとアンチプラクティスになる物は多いです。 コード検査をしていると良く分るのですが、アンチプラクティスは強力な破壊力を持っています。ここに書いているアンチプラクティスを無くすだけでも、致命的な問題／脆弱なコードを多数無くすことができるでしょう。 特徴として原理や原則、適切な構造に合致しない物がアンチプラクティスになっています。 原理：コンピュータープログラムは妥当な入力でしか、正しく動作しない 原則：Fail Fast原則、失敗するモノはできる限り早く失敗させる、が守られていない 構造：セキュリティ対策では境界防御、それも最外周の防御、が欠かせないがアプ
(Last Updated On: 2021年6月10日)バリデーション、と一言で言っても一種類／一箇所だけではありません。バリデーションには3種類のバリデーションがあります。 バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に バリデーションはモデルで集中的に行うべきだ！ なのでコントローラー（入力）でバリデーションなんて必要ない！ モデル集中型バリデーション以外の方法／場所でバリデーションするのは非効率で馬鹿馬鹿しい考えだ！ があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。1PHP開発者MLで議論したのですが、紹介したような議論をした方が少なからず居ました。少し続くとすかさず「そもそもActiveRecord
(Last Updated On: 2018年8月8日)2017年2月にGoogleがSHA1ハッシュの衝突に成功した、とアナウンスしました。1 暗号学的に安全なハッシュ関数な場合、SHA2-256を使っていると思います。SHA3が利用可能になのでSHA3を利用している場合も多いと思います。SHA2もSHA3も暗号学的ハッシュ関数です。ざっくりとこれらのハッシュ関数を安全に使う方法を紹介します。 暗号学的ハッシュ関数とは？ 理想的な暗号学的ハッシュ関数には、次の性質が求められます。 ハッシュ値の計算が容易であること。 同じハッシュ値を持つメッセージの計算が不可能なほど複雑であること。 同じハッシュ値となるメッセージは事実上存在しないこと。 ※ 英語版Wikipediaの定義です。 これらの要素を満すハッシュ関数が暗号学的ハッシュ関数と考えられています。SHA2とSHA3は暗号学的なハッシュ
(Last Updated On: 2018年8月13日)PHPにHKDF関数、hash_hkdf()が追加されましたが、そのシグニチャは褒められるモノではありません。 出鱈目なシグニチャのhash_hkdf関数を安全に使う方法 hash_hkdf()が脆弱なAPI仕様になってしまった主な原因は、開発者がハッシュ関数を利用して鍵を導出する場合に知っておくべきFS/PFSの概念を知らなかったことにあります。（秘密鍵のセキュリティ維持にSaltが必須であるとの理解が足りなかったことも原因） FS/PFSはハッシュ関数を利用した安全な鍵導出に必須の知識です。簡単な概念なので直ぐに理解できると思います。 FSとPFS FSとはForward Secrecy、PFSとはPerfect Forward Secrecyの頭文字です。日本語では前方秘匿性と言われています。Wikipediaの解説だと fo
(Last Updated On: 2018年9月2日)PostgreSQLを使うならZFSで決まりです。数値で明らかです。ZFS以外を使うのは論外なくらいの性能差があります。 TL;DR; PostgreSQL（他のデータベースでも）はZFSで使いましょう。 ベンチマーク環境 ハードウェア CPU: Xeon E3-1230 v5 @ 3.40GHz MEM: 32GB ECC HDD: HGST 7200 rpm HDD – HDS721010CLA332 SSD: Crucial CT250MX200SSD HDDは古く、SDDの性能も良いとは言えない物です。 ソフトウェア OS: Fedora 27 Kernel: 4.14.8-300.fc27.x86_64 ZFS: ZFS on Linux 0.7.5 – zfs-0.7.5-1.fc27.x86_64 PostgreSQL
(Last Updated On: 2022年6月13日)Fedora（Linux）でボリューム管理、スナップショット、圧縮、RAID5以上の性能と可能性を持つファイルシステムで”安定しているファイルシステム”となるとZFSしかありません。 機能的にはBtrfsも同等の機能を持っています。しかし、少なくともこのブログを書いている時点では、RAID56はカーネルがクラッシュした場合などにファイルシステムが壊れてしまう問題があります。2017年8月に修正パッチが提案されていますが、12月現在でも運用環境では使用しないように、と注意書きがあります。 ZFS, Btrfsは両方ともデータの整合性のチェックが可能です。一般にログファイルシステムと呼ばれているファイルシステム（NTFS, XFS2, Ext4など）はディレクトリ情報などのメタデータの整合性をログで維持しています。ZFS、Btrfsはメ
(Last Updated On: 2018年8月13日)PostgreSQL Advent Calendar 9日目用のエントリです。 PostgreSQL 10のICUコレーション（照合順序）サポートの概要と基本的な使い方は以下のエントリに記載しています。ICUコレーションの使い方は以下を参照してください。 PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる 今回は日本語ソート順のJIS規格である JIS X 4061-1996にどの程度対応しているのか確かめてみます。 TL;DR; 仕様書にソート順を書く場合、JIS規格のソート順ではなく、Unicode技術標準（特定ICU バージョン）のソート順序であることを明記しておくとよい。 テストにはICU 60と一緒にビルドしたPostgreSQL gitのREL_10_STA
(Last Updated On: 2018年8月30日)ファイアーウォールで守っている、プロキシも使っている、だからインターネットからローカルネットワークは守られている！ 半分あたりですが、半分はずれです。よくあるネットワークシステムではローカルネットワークはインターネットから半分くらいしか守っていません。 まだ対策をしていない場合は実施することを強くお勧めします。 クロスサイト攻撃からローカルネットワークを守ることは簡単です。簡単なので会社、特にシステム開発／運用部門は必ずローカルネットワークへのクロスサイトアクセスを禁止＆検出すべきです。クロスサイト攻撃とはクロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）の事です。基本的な対策ですが、意外に実施されていることが少ないようです。 クロスサイト攻撃はWebシステムに対するよくある攻撃手法です。少しの手
PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる (Last Updated On: 2018年8月13日)PostgreSQL 10からICU（International Components for Unicode）のロケール/コレーションがサポートされました。 これまでサポートされてきた、libcのja_JPロケールの貧弱な日本語ソート機能とは比べ物にならないくらい高機能な文字比較をサポートしています。日本語や他の言語での照合順序を柔軟に変更できます。 マトモな日本語ソート順でソートする（かなり重要） 数字を後にソートする 大文字を先にソートする 仮名を先にソートする 自然ソートする これらをまとめて特別なソート順にする といったことがPostgreSQL 10から行えます。 基本的な使い方 ja-x-icuはICUサ
(Last Updated On: 2018年10月13日)ISO 31000（リスクマネジメント標準規格）はa)からk)まで、11のリスク管理の原則を定めています。 ITエンジニアであればISO 27000（情報セキュリティマネジメント標準規格）を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎／基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。 情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。 リスク対策の原則が知られていない？ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。 ISO 31000:2009 （JIS Q
(Last Updated On: 2018年8月12日)セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。 ※ より細かく考える、とはいっても「細かい事だけ」では合成の誤謬にハマります。全体と詳細、両方をバランスよく「ゼロトラスト」することが大切です。 信頼できるモノ、信頼できないモノ 信頼できるモノと信頼できないモノ、と単純に分類できれば良いのですが現実にはそうなりません。「モノ」の粒度が大きいと単純に「モノ」全体を信頼することができないからです。 セキュリティ設計を行う場合 物理的 ネットワーク的 ソフトウェア システム の各レベルで信頼境界を引き、可能な限り信頼できるように設計します。しかし、普通は信頼境界の中の「モノ」全体を
(Last Updated On: 2018年8月13日)Railsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。 Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。 Brakemanのインストールと使い方 Brakemanのページを見れば説明の必要もないですが、一応説明します。 rbenvを使っている場合、Railsで利用しているRubyのバージョンをローカルに合わせておきます。Rubyユーザーは普通にrbenvなどを使うべきでしょう。 $ cd MyRailsProject $ rbenv local 2.3.3 Brakemanのgemをインストールします。 $ gem install brakeman Brakemanを実行します。BrakemanはRa
次のページ
このページを最初にブックマークしてみませんか？
『yohgaki's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
