SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
django で論理削除を実現してみる - 記憶は削除の方向で
イベント系のデータならともかく、リソース系のデータの論理削除というのは結構需要が多そうな気がするけど、あまり触れられてないのはなんでだろうか？すでに Django Snippets とかにあるような気もするけど、なかなかいいアイデアが浮かんだのでメモしておく。 まずは前提とするモデルから。 class Author(models.Model): name = models.CharField(u'名前', max_length=255) deleted = models.BooleanField(u'論理削除フラグ', default=False) def delete(self): self.deleted = True self.save() class Entry(models.Model): content = models.TextField(u'内容') author = mo
NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
テーブル一覧、テーブル定義情報取得用SQL Ver.2 - Diary of absj31
前回記事のSQLではテーブル項目の桁数が取得出来ていなかったのだが、取得方法がどうやらあるようなのでちょっぴり改造。 まず、以下の様なテーブルCREATE文を用意し、テーブルを作成。。 DROP TABLE mst_smpl; CREATE TABLE mst_smpl ( user_id character varying(10) NOT NULL, -- サンプル管理マスタ.ユーザID data_id character varying(5), -- サンプル管理マスタ.データID user_name character varying(50), -- サンプル管理マスタ.ユーザ名 tel_home character(15), -- サンプル管理マスタ.自宅電話番号 points numeric(10), -- サンプル管理マスタ.点数 reg_ymd date, -- サンプル管理
PostgreSQLでテーブル定義を取得するSQL - ブログリトライ
商用RDBMSだとこの辺楽チンなんだけど。。。 select attnum as 列番, attname as 列名, case typname when '_bpchar' then 'char' when '_varchar' then 'varchar' when '_date' then 'date' when '_float8' then 'float8' when '_int4' then 'integer' when '_interval' then 'interval' when '_numeric' then 'numeric' when '_float4' then 'float4' when '_int2' then 'smallint' when '_text' then 'text' when '_time' then 'time' when '_timestam
データベースが遅くなった原因を自動的にスキャンして分析するフリーソフト「Trace Analyzer for SQL Server」
Windows XP SP1/VistaとWindows Server 2003/2008の32ビットおよび64ビット版で動作し、SQL Server 2005/2008のデータベースを分析することで速度が遅くなってしまった原因を見つけてくれるのがこのフリーソフト「Trace Analyzer for SQL Server」です。インストールして起動させるには他に「.Net Framework 3.5 SP1」と「Microsoft SQL Server Compact 3.5 SP1」も必要です。 数百あるいは数千もあるファイルイベントをトレースしたり、サーバに過負荷をかけているバッチがどれが特定したりするわずらわしさから解放してくれるはずです。 ダウンロードは以下から。 DBSophic | Trace Analyzer for SQL Server http://www.dbsoph
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ClientFrameworkTutorialContents
DB Ghost - SQL Server Change Management - Home
リレーショナル・データベースの世界