PostgreSQL Conference 2012で講演する機会を頂きましたので報告します。 日時:2012年2月24日(金曜日) 14時30分〜17時20分(徳丸の出番は16:30〜17:00) 場所:AP 品川 (東京都港区) 費用:3,500円(申し込みはこちら) 講演タイトル:安全なSQLの呼び出し方 今回は、IPAの安全なSQLの呼び出し方を題材として、SQLインジェクションの発生原理から、安全なSQLの利用方法を基礎から実際までを説明します。 あまりトリッキーな攻撃の方法はしないつもりで、基礎的な話が中心となります。安全なSQLの呼び出し方の作成経緯については、「今夜こそわかる安全なSQLの呼び出し方 〜 高木浩光氏に聞いてみた」を参照下さい。 さて、「安全なSQLの呼び出し方」は以下の五名による執筆となっています。 執筆者 徳丸 浩 永安 佑希允 相馬 基邦 勝
PostgreSQL Conference は、日本 PostgreSQL ユーザ会(JPUG)が毎年開催している 技術的話題を中心としたカンファレンスで、PostgreSQL に関する内外の導入事例 および技術情報を提供する恒例のイベントとなっております。 昨年、PostgreSQL はレプリケーション機能を伴ったバージョン 9.0 が公開され、 今年はさらに進化したバージョン 9.1 が公開されるなど、 現在も発展と進化を着実に続けている先進的な DBMS です。 更新履歴 資料を公開しました。 New! 2012/02/22 ご参加の皆様へのご案内を掲載しました。 2012/02/22 Ustream での中継について掲載しました。 2012/02/20 VMware さまのランチセッションを掲載しました。 2012/02/20 チケット販売状況を掲載しました。カンファレンスのチケッ
平素より「PHPプロ!」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ!」ですが、サービスの利用状況を鑑みまして、2018年9月25日(火曜日)をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日(火曜日)を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
(Last Updated On: 2018年8月13日)PostgreSQL Advent Calender用のエントリです。 エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。 PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、 yohgaki@[local] test=# CREATE TABLE user (name text); ERROR: syntax erro
大垣さんの寄稿記事「第44回 セキュリティ対策が確実に実施されない2つの理由:なぜPHPアプリにセキュリティホールが多いのか?|gihyo.jp … 技術評論社」のまとめにて、『最後に「何が正しいのか?」常に考えるようにしてください』と書かれています。この部分は、私への反論のようですので、このエントリで返答したいと思います。 大垣さんの主張 先にも述べたように、大垣さんはこのエントリの「まとめ」として以下のように書かれています。 最後に「何が正しいのか?」常に考えるようにしてください。 http://gihyo.jp/dev/serial/01/php-security/0044?page=2 この主張自体には私も大賛成です。大垣さんの記事は以下のように続きます。 例えば,SQL文を作成する場合にリテラル(パラメータ)を文字列としてエスケープすると浮動小数点型のデータが正しく処理されないデ
PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール(シングルクォートを重ねるのみ)となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない(ISO規格と同様の)仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後
PostgreSQL 9.1.0 が 2011年9月12日にリリースされました。 最新版のバイナリやソースコードは "ダウンロード用ページ" で配布されています。 9.1 では、9.0 で新規に採用されたレプリケーション機能の使い勝手の強化の他、外部のファイルや DB に直接アクセスできる SQL/MED や、拡張モジュールの管理機能など、さらなる強化が行われています。 互換性に関する注意 最初が注意になってしまいますが、以前のバージョンとの互換性の無い設定がデフォルトに変更されています。比較的多くのアプリケーションで問題になる可能性があるため、あえて強調して注意させてもらいます。 standard_conforming_strings のデフォルトが on に変更 standard_conforming_strings = on がデフォルトになりました。E'...' 形式でない文字列内
E.76.1. Overview This release shows PostgreSQL moving beyond the traditional relational-database feature set with new, ground-breaking functionality that is unique to PostgreSQL. The streaming replication feature introduced in release 9.0 is significantly enhanced by adding a synchronous-replication option, streaming backups, and monitoring improvements. Major enhancements include: Allow synchrono
http://pc.nikkeibp.co.jp/article/column/20110519/1031877/ 今後に期待。現段階ではそれ以外に特に結論はない。 ということでよいのか。 QVC = QにVoールがCuiたので。 苦しい。急にボールが来たらグラブを投げればいいですか? それなんてオーティズ。 http://gihyo.jp/dev/serial/01/php-security/0042 巷で叩かれていますね。 この記事読んでも、それでもオレはバインド変数を使用して無害化はJDBCドライバに任せるべきだと思うけどね。漏れるもの。サニタイズエスケープだと。RDBMSによって対象の文字も変わるしさ。 Javaで言うPreparedStatementだとテーブル名や列名がバインド変数にできない、というのと、だからPreparedStatementじゃなくてサニタイズエスケープ、っ
Sunday, April 10, 2011 MySQL の Prepared Statement けさは、SQL インジェクションを少しだけ勉強したので、それに関して、ごく私的なメモを書き残しておこうと思う。情報処理推進機構 (IPA) の 「安全なウェブサイトの作り方」 では、SQL インジェクションの脆弱性を予防するための根本的解決として、まず第一に 「SQL 文の組み立ては全てプレースホルダで実装する」(改訂第5版 p.9) と述べている。 プレースホルダーには、動的プレースホルダーと静的プレースホルダーがあって、これらについては IPA の 「安全な SQL の呼び出し方」 が詳しい。 また、最近刊行された 『体系的に学ぶ 安全な Web アプリケーションの作り方』(徳丸浩著 ソフトバンククリエイティブ ISBN978-4-7973-6119-3) にも詳しい解説が載っている。大
フォームのデータを受け取った後に、エラーチェックをまずかけることです。 上記の流れで、ユーザ名を受け取った後何のチェックもしないでクエリに挿入してしまうと、たとえば「test'; update a_m_user set user_password = ''」なんて入力されると、すべてのユーザのパスワードがクリアされてしまうわけですね。 というわけで、ユーザ名に記号は使えないようにして、記号が入っていたらその時点でエラーとするとか、正しいエスケープ処理を行うとか(mysql_real_escape_string等)が必要になってくるわけですね。 とりあえず、SQLインジェクションについては、googleなどで検索すれば、その代表的な手法や防御手段はいくらでも出てきますので、ざっくり読んでみることです。 車輪の再発明にいそしむよりも、すでに確立されている対策をきちんととることが重要です。 ##
こんにちは、SQLを愛してやまないmoriyoshiです。 ストアドプロシージャは、一連のSQL文をサブルーチンのようにDBサーバに記録しておき、後からそれを呼び出すことができるようにする仕組みです。近代的なRDBMSには標準的に備わっている機能といえます。 制御構造などもSQL文で記述することができるので、結果的に、あらゆるロジックをSQLのみで記述することができます。手続き型プログラミングにどっぷり浸かった現場の方から愛用されていると言われています。 今回は、ストアドプロシージャの応用として、Webスクレイピングを行なってみましょう。Webスクレイピングとは、特定のWebサイトにアクセスし、そのページの内容 (HTML) を取得、解析し、必要な情報を取り出すという一連の操作を自動化することです。Webスクレイピングを効果的に活用すると、人間がブラウザに向かって単純作業を繰り返す必要がな
ホーム > mysql | perl > mysqlでskip-character-set-client-handshakeはもう使わないほうがいいと思われ 新しい 古い skip-character-set-client-handshake を [mysqld] セクションに追記すると、クライアントがどんな文字コード設定をもっていようが問答無用で character_set_* を (_system をのぞいて) すべて同じ値に統一してくれる http://d.hatena.ne.jp/a666666/20090826/1251270979 ふーむ。 skip-character-set-client-handshakeを薦める文書がネット上にはやたら転がってるんだけど、これには大きな落とし穴がある。 たしかに表示されるcharacter_set_*は統一されるかもしれないがこれはあくま
SQL で LIKE 条件を使うとパターン一致検索が実行できます。 この時、'%'と'_'はそれぞれ任意の文字列、任意の1文字を表す特殊文字として扱われます。 したがって、'%'や'_'という文字を検索したい場合は、エスケープ文字を使用して、文字としての'%'、'_'であることを明示する必要があります。 例えば、COL1 に'_'を含む TBL1 のレコードを検索したい場合は以下のように記述します。 SELECT * FROM TBL1 WHERE COL1 LIKE '%\_%' ESCAPE '\' と、ここまでは SQL の常識です。 しかし、実はこの'%'と'_'、全角の'%'、'_'でもやはり特殊文字として認識されてしまうのです。 つまり、 SELECT * FROM TBL1 WHERE COL1 LIKE '%_%' と記述すると、”任意の1文字を含む”となりますので、Nul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く