Database – yohgaki's blog

Computer, Database

PostgreSQL 8.2をインストール

3月 26, 2021 #CentOS, #Fedora, #GCC, #PostgreSQL 投稿者 yohgaki

訳あってCentOS7にPostgreSQL 8.2をインストールしようとするとコンパイルは出来ても動作しませんでした。8.2はかなり古いPostgreSQLなので仕方ないですが、動作させることは可能でした。

CentOS6ならPostgreSQL 8.2を普通にコンパイルできると思います。

Database, Development, PHP Security, Programming, Secure Coding, Security

JSONPathインジェクション

8月 3, 2020 #PostgreSQL, #SQLインジェクション, #インジェクション, #エスケープ, #セキュアコーディング, #出力対策投稿者 yohgaki

JSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択／クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。

JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。

https://jsonpath.com/

JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。

Computer, Database, Development, PHP Security, Secure Coding

IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき – その2

12月 12, 2018 #SQLインジェクション, #セキュアコーディング, #セキュリティ標準, #入力バリデーション, #出力対策投稿者 yohgaki

IPAは”旧セキュアプログラミング講座は更新しない”とWebサイトに記載していましたが、次のブログで「IPAは旧セキュアプログラミングガイドの基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき」と指摘したところ修正されたので第二弾です。

※ 2018年3月に指摘し、少なくとも秋頃には修正されていました。因みに現在セキュアプログラミング講座はCERTのセキュアコーディング習慣（原則）に則った科学的／エンジニアリング的に妥当な解説になっています。

IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき

第一弾では「入力処理セキュリティ対策の解説が出力処理のセキュリティ対策の解説になっており、出鱈目である」と指摘しました。修正後のページは改善はされていますが、まだ入力処理と出力処理のセキュリティ対策とを一緒に説明している点はダメなままです。入力対策と出力対策は実施する場所が異ります。分けて説明すべきでしょう。CERT Top 10 Secure Coding PracticesもCWE/SANS Top 25 Monster MitigationもOWASP Secure Coding Quick Reference Guideも分けています。全て1番目が入力対策でが、IPAの旧セキュアプログラミング講座では入力対策の重要性が理解らないでしょう。

”入力対策”の解説としていた項目が”出力対策”の解説になっていたモノを無理矢理”入力・注入対策”にした、といった事情もあると思います。

しかし、なぜCERTがセキュアコーディング原則の第一番目としている入力対策が独立した項目ではないのでしょうか？OWASP TOP 10:2017を策定する際に「ほぼ全てのWebアプリが十分な入力対策を行っていない」と指摘されています。この現状に異論はないと思います。入力対策の不備がWebアプリにとって大きなリスクとなっています。これは今に始まったことではなく、昔からですが。入力対策解説の不備は第三弾としてブログを書くかも知れません。

今回はSQLインジェクション対策の問題点を指摘します。

Computer, Database, Development, PHP Security, Programming, Secure Coding

コードで学ぶセキュアコーディング〜 SQLインジェクション編

11月 12, 2018 #SQLインジェクション, #セキュアコーディング, #セキュアコーディング技術, #フェイルセーフ, #フェイルファースト, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

セキュアコーディング原則において、インジェクション対策の為に重要な原則は

原則1：全ての入力をバリデーションする
原則７：全ての出力を無害化する

の２つです。これらに、一般的なプログラミング原則であるフェイルファースト原則とフェイルセーフ原則、ゼロトラストを適用するとセキュアコーディングになります。

簡単なSQLインジェクション対策コードを使ってセキュアコーディングの概念を紹介します。

セキュアコーディング／セキュアプログラミングの原則と技術は国際情報セキュリティ標準（ISO 27000）でも要求される技術です。しかし、根本から誤ったセキュリティ対策の概念が長年啓蒙されています。GDPR対策にもISO 27000は重要です。日本に於てもISO 27000が要求する基礎的対策ができていない場合、法的リスクが非常に高いと言わざるを得ません。

Computer, Database, Development, PHP Security, Programming, Secure Coding

遅すぎるサニタイズではダメな例

10月 26, 2018 #PostgreSQL, #セキュアコーディング論理, #セキュリティ構造, #フェイルファースト, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

PostgreSQL 11がリリースされました。このリリースでto_number()、to_char()、to_date()、to_timestamp()関数の仕様が変更されました。これらは名前の通り入力を変換する関数です。その際に

サニタイズ – ダメな形式のデータを使える／安全なデータ形式に変換する

を行います。保存されるデータ形式は、保存可能な形に変換されます。しかし、これは十分ではないです。遅すぎるサニタイズがダメな例として紹介します。

※ エスケープやプリペアードクエリもサニタイズ（無害化）の一種です。

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

リスク分析とリスク対応をしよう

10月 16, 2018 #セキュアコーディング, #セキュリティ標準, #ゼロトラスト, #フェイルセーフ, #フェイルファースト, #ベストプラクティス, #リスク分析, #リスク管理, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。

情報システムは「モノ」（物と人）、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。

当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない！といった場合も多いので仕方ない側面もあります。

しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。

※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。

Computer, Database, PHP Security, Programming, Secure Coding

「フェイルセーフ」とは何なのか？

8月 3, 2018 #MySQL, #PHP, #PostgreSQL, #セキュアコーディング論理, #フェイルセーフ, #ベストプラクティス, #出力対策投稿者 yohgaki

「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」¹と言われることもありますが、基本概念は同じです。よく聞く言葉＆簡単な概念ですが、割と広く誤解されている概念の１つに見えます。

フェイルセーフを一言で言うと

何かに失敗しても致命的な問題に至らないよう安全に失敗させる

これがフェイルセーフです。可能ならば「失敗／故障しても、失敗／故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。

Wikipediaの定義では

フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。

となっています。

こんな単純な概念は間違いようがないでしょ？

と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。

Computer, Database

PostgreSQLの文字列型の最大長は？

7月 24, 2018 #PostgreSQL, #セキュアコーディング技術投稿者 yohgaki

PostgreSQLには

varchar(n) 型
char(n) 型
text型

の文字列型があります。他にバイナリも保存できる

bytea型

もあります。

text／byteaの最大サイズは1GiBだ、と私も思っていたのですが違いました。

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

RDBMSから学ぶデータセキュリティ

6月 18, 2018 #MySQL, #PostgreSQL, #セキュアコーディング技術, #セキュアコーディング論理, #入力バリデーション投稿者 yohgaki

RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。

プログラムが正しく動作する為には

正しいコードであること
正しい（妥当な）データであること

が絶対条件です。どちらが欠けてもプログラムは正しく動作しません。

SQLiteは手軽で良いのですが、組み込み型であるためデータセキュリティを学ぶには機能的に問題があります。SQLiteにはデータ型を保証する機能もデータの内容を検証する機能もありません。¹

利用するRDBMSはPostgreSQLを用い、データセキュリティに関連性の強い機能のみを対象とします。

Computer, Database, Development, Programming, Secure Coding

SQLクエリと識別子エスケープの話

3月 30, 2018 #MySQL, #PostgreSQL, #SQLインジェクション, #エスケープ, #セキュアコーディング技術投稿者 yohgaki

Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。

テーマは「SQLクエリと識別子エスケープ」です。

とあるブログの結論として

“「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり

プリペアドクエリでSQL発行は行うこと
この場合変数のバインドは必ずプレースホルダを用いること。

SQL文の文字列操作は禁止であり、これほどシンプルなことも無いだろう”

と書かれていました。しかし、私はこの意見に対して

実践的なSQLクエリを書いたことが全くない開発者なのでしょう？？
ソートカラム、抽出カラムを指定するSQLクエリでは「識別子（カラム名）が変数」になります。
初歩的なSQLクエリですが”自分が書いたことないから”といって一般的ではないと勘違いしています。行のソート順、抽出カラムを指定するSQLクエリは業務アプリでは”一般的”です。当たり前ですが。

こうやってベストプラクティスもどきのアンチプラクティスが使われて、喜ぶのはサイバー犯罪者とセキュリティ業者だけですよ。

とコメントしました。SQLのテーブルやジョイン結果を「表」として表示した際に、任意のカラムのソート順を指定するUIは、自分で作ったことが無かったとしても、ごく一般的だと分かると思うのですが・・・