タグ

SQLに関するockeghemのブックマーク (80)

  • 【書評】データベース関連書籍のご紹介 - k.hasunuma's programming studio

    ockeghem
    ockeghem 2012/06/20
    ここ違う>『Java等ではSQLインジェクションを回避する仕組みが整備されているのですが、PHPは言語仕様でデータベースアクセスを規定していることもあり、SQLインジェクションには脆いとされています』
  • PostgreSQL Conference 2012で講演します - ockeghem's blog

    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 2012で講演します - ockeghem's blog
    ockeghem
    ockeghem 2012/01/20
    PostgreSQL Conference 2012で「安全なSQLの呼び出し方」について講演します
  • PostgreSQL Conference Japan 2011(FY)

    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 チケット販売状況を掲載しました。カンファレンスのチケッ

    PostgreSQL Conference Japan 2011(FY)
    ockeghem
    ockeghem 2012/01/06
    【C4 】「安全な SQL の呼び出し方」について講演することになりました。よろしくお願いします
  • サービス終了のお知らせ

    平素より「PHPプロ!」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ!」ですが、サービスの利用状況を鑑みまして、2018年9月25日(火曜日)をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日(火曜日)を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 件に関するお問い合わせはこちらよりお願いいたします。

    ockeghem
    ockeghem 2011/12/18
    検索条件が動的に変わる場合のプレースホルダの使用法については徳丸本P135に説明しています(徳丸メソッド) #wasbook
  • PostgreSQL 9.0から使える識別子とリテラルのエスケープ

    (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

    PostgreSQL 9.0から使える識別子とリテラルのエスケープ
    ockeghem
    ockeghem 2011/12/12
    前提条件が書いてないのでわかりにくいけど、userをSQL文のフィールド名に使うためには"user"とダブルクォートで囲めばよい。エスケープ関数が必要なのはSQL文を動的生成する場合
  • 何が正しいのかを考える際は、正しさの基準が必要 - ockeghem's blog

    大垣さんの寄稿記事「第44回 セキュリティ対策が確実に実施されない2つの理由:なぜPHPアプリにセキュリティホールが多いのか?|gihyo.jp … 技術評論社」のまとめにて、『最後に「何が正しいのか?」常に考えるようにしてください』と書かれています。この部分は、私への反論のようですので、このエントリで返答したいと思います。 大垣さんの主張 先にも述べたように、大垣さんはこのエントリの「まとめ」として以下のように書かれています。 最後に「何が正しいのか?」常に考えるようにしてください。 http://gihyo.jp/dev/serial/01/php-security/0044?page=2 この主張自体には私も大賛成です。大垣さんの記事は以下のように続きます。 例えば,SQL文を作成する場合にリテラル(パラメータ)を文字列としてエスケープすると浮動小数点型のデータが正しく処理されないデ

    何が正しいのかを考える際は、正しさの基準が必要 - ockeghem's blog
    ockeghem
    ockeghem 2011/12/03
    日記書いた。数値を文字列リテラルとして処理する件について
  • PostgreSQLは標準でバックスラッシュをエスケープしない仕様になった

    PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール(シングルクォートを重ねるのみ)となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない(ISO規格と同様の)仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後

  • 株式会社VOYAGE GROUP

    株式会社VOYAGE GROUPは、2022年1月、株式会社CARTA HOLDINGSと合併いたしました。 関連リリース:CARTA HOLDINGS、基幹グループ会社のCCIおよびVOYAGE GROUPと統合へ https://cartaholdings.co.jp/news/20210513_01/ CARTA トップへ

    株式会社VOYAGE GROUP
    ockeghem
    ockeghem 2011/09/20
    ありがとうございます。私の本をきっかけにして、このような議論が広がっていくことはとても嬉しいです #wasbook
  • PostgreSQL 9.1 の新機能—Let's Postgres

    PostgreSQL 9.1.0 が 2011年9月12日にリリースされました。 最新版のバイナリやソースコードは "ダウンロード用ページ" で配布されています。 9.1 では、9.0 で新規に採用されたレプリケーション機能の使い勝手の強化の他、外部のファイルや DB に直接アクセスできる SQL/MED や、拡張モジュールの管理機能など、さらなる強化が行われています。 互換性に関する注意 最初が注意になってしまいますが、以前のバージョンとの互換性の無い設定がデフォルトに変更されています。比較的多くのアプリケーションで問題になる可能性があるため、あえて強調して注意させてもらいます。 standard_conforming_strings のデフォルトが on に変更 standard_conforming_strings = on がデフォルトになりました。E'...' 形式でない文字列内

    ockeghem
    ockeghem 2011/09/13
    こちらの方が読みやすい。バックスラッシュについての重要な注意。MySQL独自記法からISO標準に合わせたと言うことですね
  • Release 9.1

    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

    Release 9.1
    ockeghem
    ockeghem 2011/09/13
    『By default, backslashes are now ordinary characters in string literals』<デフォルトでバックスラッシュをエスケープしなくなるという重要な変更
  • 2011-05-20

    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じゃなくてサニタイズエスケープ、っ

    2011-05-20
    ockeghem
    ockeghem 2011/05/20
    『PreparedStatementだとテーブル名や列名がバインド変数にできない、というのと、だからPreparedStatementじゃなくてサニタイズエスケープ、っていうのはちょっと話が違うんじゃないかと思った』<然り
  • Mundane Life: MySQL の Prepared Statement

    Sunday, April 10, 2011 MySQL の Prepared Statement けさは、SQL インジェクションを少しだけ勉強したので、それに関して、ごく私的なメモを書き残しておこうと思う。情報処理推進機構 (IPA) の 「安全なウェブサイトの作り方」 では、SQL インジェクションの脆弱性を予防するための根的解決として、まず第一に 「SQL 文の組み立ては全てプレースホルダで実装する」(改訂第5版 p.9) と述べている。 プレースホルダーには、動的プレースホルダーと静的プレースホルダーがあって、これらについては IPA の 「安全な SQL の呼び出し方」 が詳しい。 また、最近刊行された 『体系的に学ぶ 安全な Web アプリケーションの作り方』(徳丸浩著 ソフトバンククリエイティブ ISBN978-4-7973-6119-3) にも詳しい解説が載っている。大

    ockeghem
    ockeghem 2011/04/10
    良い記事。MySQLの動的/静的プレースホルダをパケットキャプチャで確認している。その他ネタもあり
  • 「SQL 99 Complete, Really」が無償公開されました。 | キムラデービーブログ

    オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日オラクルに在籍していますが、サイト(ブログ、またはウェブサイト)において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。

    「SQL 99 Complete, Really」が無償公開されました。 | キムラデービーブログ
    ockeghem
    ockeghem 2011/01/31
    これはいいね
  • Bugtraq

    ockeghem
    ockeghem 2010/11/11
    JETセキュリティ問題の元祖はこれらしい。参考:http://www.tokumaru.org/d/20090327.html#p02
  • 【SQLインジェクション】回避策として考えたのですが、どうなんでしょうか??? - SQLインジェクションの対策で悩んで... - Yahoo!知恵袋

    フォームのデータを受け取った後に、エラーチェックをまずかけることです。 上記の流れで、ユーザ名を受け取った後何のチェックもしないでクエリに挿入してしまうと、たとえば「test'; update a_m_user set user_password = ''」なんて入力されると、すべてのユーザのパスワードがクリアされてしまうわけですね。 というわけで、ユーザ名に記号は使えないようにして、記号が入っていたらその時点でエラーとするとか、正しいエスケープ処理を行うとか(mysql_real_escape_string等)が必要になってくるわけですね。 とりあえず、SQLインジェクションについては、googleなどで検索すれば、その代表的な手法や防御手段はいくらでも出てきますので、ざっくり読んでみることです。 車輪の再発明にいそしむよりも、すでに確立されている対策をきちんととることが重要です。 ##

    【SQLインジェクション】回避策として考えたのですが、どうなんでしょうか??? - SQLインジェクションの対策で悩んで... - Yahoo!知恵袋
    ockeghem
    ockeghem 2010/08/02
    『ちなみに、プリペアードステートメントを使う「だけ」ではちっともSQLインジェクションは防げません』<正しいんだけど、ちょっとプリペアードステートメントを過小評価しすぎ。「ちっとも」は余計ですね
  • ストアドを使って、Webスクレイピングをしよう! - moriyoshiの日記

    こんにちは、SQLを愛してやまないmoriyoshiです。 ストアドプロシージャは、一連のSQL文をサブルーチンのようにDBサーバに記録しておき、後からそれを呼び出すことができるようにする仕組みです。近代的なRDBMSには標準的に備わっている機能といえます。 制御構造などもSQL文で記述することができるので、結果的に、あらゆるロジックをSQLのみで記述することができます。手続き型プログラミングにどっぷり浸かった現場の方から愛用されていると言われています。 今回は、ストアドプロシージャの応用として、Webスクレイピングを行なってみましょう。Webスクレイピングとは、特定のWebサイトにアクセスし、そのページの内容 (HTML) を取得、解析し、必要な情報を取り出すという一連の操作を自動化することです。Webスクレイピングを効果的に活用すると、人間がブラウザに向かって単純作業を繰り返す必要がな

    ストアドを使って、Webスクレイピングをしよう! - moriyoshiの日記
    ockeghem
    ockeghem 2010/07/15
    すごいなぁ
  • mysqlでskip-character-set-client-handshakeはもう使わないほうがいいと思われ | へぼい日記

    ホーム > 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_*は統一されるかもしれないがこれはあくま

  • blog.ishinao.net

  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    ockeghem
    ockeghem 2010/06/15
  • 『[Oracle] LIKE 検索では全角の'%'、'_'も特殊文字として扱われる?』

    SQL で LIKE 条件を使うとパターン一致検索が実行できます。 この時、'%'と'_'はそれぞれ任意の文字列、任意の1文字を表す特殊文字として扱われます。 したがって、'%'や'_'という文字を検索したい場合は、エスケープ文字を使用して、文字としての'%'、'_'であることを明示する必要があります。 例えば、COL1 に'_'を含む TBL1 のレコードを検索したい場合は以下のように記述します。 SELECT * FROM TBL1 WHERE COL1 LIKE '%\_%' ESCAPE '\' と、ここまでは SQL の常識です。 しかし、実はこの'%'と'_'、全角の'%'、'_'でもやはり特殊文字として認識されてしまうのです。 つまり、 SELECT * FROM TBL1 WHERE COL1 LIKE '%_%' と記述すると、”任意の1文字を含む”となりますので、Nul

    『[Oracle] LIKE 検索では全角の'%'、'_'も特殊文字として扱われる?』
    ockeghem
    ockeghem 2010/06/13
    色々面倒くさい