例えば、「\%foo」から始まる文字列を検索する場合には、どのようなSQL文を書けばよいのでしょうか。 条件は以下の通りです。 DBMSソフトはMySQL ESCAPE節は使わない MySQLでESCAPE節を使わない場合、ワイルドカード文字（「%」や「_」）は「\」でエスケープすることになります。 間違った答え 直感的に以下のようなSQL文を書いてしまう人もいると思います。 SELECT * FROM table1 WHERE hoge LIKE '\\\%foo%'; 実際に試して見ます。 mysql> SELECT 123 FROM dual WHERE '\\%foo456' LIKE '\\\%foo%'; +-----+ | 123 | +-----+ | 123 | +-----+ 1 row in set (0.00 sec) mysql> SELECT 123 FROM
Cookie でログイン状態を管理すればいいんじゃいのかな。 まず、ログインボタンを押した時「だけ」is_logged_on を真にする。 HTTP/1.1 Authorization Required Set-Cookie: is_logged_on=1 WWW-Authenticate: Basic realm="Hoge123456" ...サーバ側では、Basic 認証のパスワードがあり、かつ、is_logged_on の値が真であることをチェックすればいい。 GET / HTTP/1.1 Cookie: is_logged_on=1 Authorization: Basic ... ... HTTP/1.1 200 OK ...で、ログアウトの際には、Cookie を消す。 HTTP/1.1 200 OK Set-Cookie: is_logged_on=0 ...そして、is_
Passpackは4日(スイス時間)、Host-Proof Hostingを実装したAjax Webアプリケーションを開発するためのライブラリ"Passpack Host-Proof Hosting package"を公開した(以降、Passpack HPH)。ライブラリはThe MIT LicenseとLGPLのデュアルライセンスで提供されており、執筆現在でのバージョンは1.0とされている。ライブラリをjQueryから使うサンプルコードも用意されている。簡単なリファレンスドキュメントも公開されているため利用はそれほど困らないだろう。 Passpack HPH 1.0でサポートされているアルゴリズムはAES (128、192、256ビット)、xxTEA、セキュリティ改善されたRC4、XMLHTTPRequestポストにおける問題を避けるために'+''が'!'に変更されたBase64、SHA
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本稿ではSQLインジェクション対策として、SQLのエスケープ処理の方法について検討する。 最近SQLインジェクション攻撃が猛威を振るっていることもあり、SQLインジェクションに対する解説記事が増えてきたようだが、対策方法については十分に書かれていないように感じる。非常に稀なケースの対応が不十分だと言っているのではない。ごく基本的なことが十分書かれていないと思うのだ。 SQLインジェクション対策には二通りある。バインド機構を使うものと、SQLのエスケープによるものだ。このうち、SQLのエスケープについて、十分
……なんと「そのままアクセスする」とか「一時的に受け入れる」とかいう選択肢がありません。そのかわり「例外として扱うこともできます」という謎のリンクがあります。クリックすると、「例外を追加」というボタンが現れます。 「インターネット接続環境を完全には信頼できない場合や、これまでこのサーバではこの警告が表示されなかった場合は、このサイトを例外として追加しないでください。」という注意書きが。そして例外に追加しようとすると、だめ押しの一撃。 「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません。」太字で断言ですよ。これは気持ち良い! ここまでされると、本物サイトをオレオレ証明書で運用するのもかなり抵抗が出てくるでしょう。 ※興味本位で一時的にアクセスしてみたりするのがやりにくくなりますが……。まあ、一般の人はそんなことをする必要がありませんしね。 「Firefox3のオレオレ
Fedora42など、Kernelが新しいLinuxではVMware Workstationのカーネルモジュールがコンパイルできず使えません。古いカーネルを使えばコンパイルできるのですが、新しいカーネルでも使いたいので調べました。 Fedora42からはSecure Boot用にカーネルモジュールへのサインも必須になっています。（無効にもできますが、サインするのは簡単） (さらに…) Dockerfileの中で永続化が必要なディレクトリ（ボリューム）としてVOLUMEを指定すると、-vまたはvolume:で明示的にマウントしないと匿名ボリューム（名前なしのボリューム）が作られます。匿名ボリュームが起動する度に新しく作成されるので放っておくとどんどん溜まります。 どのコンテナが匿名ボリュームを作っているのかはdocker inspectで判別出来るのですが、何度も、何度も、手動でやっているの
最近少し調べていたのが、PHPの任意コード実行系の脆弱性です。中でも、preg_replace関数（Perl互換の正規表現による置換を行なうための関数）を不適切な方法で使った場合に発生する脆弱性について調べていました。 せっかくなので、日記にまとめてみます。 3種類の脆弱性 preg_replace関数を使ったPHPコード実行系の脆弱性には、大きく分けて3つの種類があります。 第一引数への挿入を許す e修飾子付き・第二引数への挿入を許す e修飾子付き・第三引数への挿入を許す 以下でそれぞれについて見ていきます。 タイプ１：第一引数への挿入 以下のコードに、任意のPHPコードが実行可能な脆弱性があります。 $m = preg_replace("/([^<]*)$kw([^>]*)/i", "\\1<font color=red>$kw</font>\\2", $m); $kwと$mは外部から
こんにちは。nabokov7 です。YAPC::Asia 2008で発表してきましたので、その資料を公開します。 ライブドアでは、各サービスで共通に使える内部サービスをいくつか独自開発しています。そのうちのひとつが、今回紹介した共通スパムフィルタ「スパムちゃんぷるー」です。ライブドアブログやライブドアwiki、したらば掲示板などのスパム書き込みのフィルタリングを共通化するために開発したものです。 これにより、スパム判定のロジックが一元化され、統計情報、ブラックリスト、ホワイトリストなどが共有できるようになります。また、過去の判定結果から学習する機能もあります。 スパム判定の基準は各サービス、あるいはユーザ毎の設定によっても変わってくるので、判定ロジックはプラグイン形式になっており、判定時にはこれらのプラグインが並列で動作する仕組みになっています。リクエスト時に必要なプラグインを指定し、任意
Last Updated on: 2018年8月8日http://www.0x000000.com/?i=567 にmod rewriteを利用した簡易WAF(Web Application Firewall)の定義例が掲載されています。同じようなアイデアをお持ちの方、既に似たような設定を使われている方も多いとは思います。 簡単なWAFですが、実用性も高いです。例えば、ヌル文字やHTML特殊文字のインジェクションは様々な攻撃で利用されます。アプリケーションで対処が忘れられがちなCOOOKIEやREFER、USER_AGENT等に特殊文字が入っていた場合にアクセスを拒否する部分だけもで導入する価値は十分にあると思います。 元ネタのサイトは英語ですが、解説付きです。 これを入れると問題となる場合もあるので、内容を理解してから利用しなければなりません。 RewriteEngine On Opti
Last Updated on: 2008年4月3日Smarty 2.6.19未満のregex_replaceは脆弱だったと言うよりは、今でも脆弱と言った方が良いと思います。 Smarty 2.6.19は2008/2/11にリリースされました。ちょっと古い話ですが、Smarty 2.6.19より前のバージョンのregex_replaceは脆弱、とアナウンスされています。 subversionを見てみると if (($pos = strpos($search,"\0")) !== false) $search = substr($search,0,$pos); が追加されています。 ヌルバイトアタックに脆弱、と言う話です。 しかし、それ以前にマルチバイト環境では2.6.19でも話になりません。幾つかのプロジェクトでSmartyを取り扱った事がありますが、当然マルチバイト対応して使っていました
「なぜPHPアプリにセキュリティホールが多いのか?【スクリプトインジェクション対策07】予期しないエラーが発生した場合，プログラムの実行を停止する (gihyo.jp)」。 「プログラムの実行を停止」というのは表現がおかしいと思いますが、要は処理を続行せずにエラー終了すべきということですね。 しかしこういうときに悩むのが、「どういうステータスコードで応答したら良いのか」ということ。普通に考えると500系のレスポンスになると思うのですが、501 (Not Implemented) では変ですし、503 (Service Unavailable) だと一定期間後に復活しそうに見えますし、他に使えそうなコードはないし……。というわけで、まあ素直に500 (Internal Server Error) で良いかなぁ……と思うわけですが。 ところがついこの前、とある案件にて、セキュリティ屋さんから「
なぜPHPアプリにセキュリティホールが多いのか? 【スクリプトインジェクション対策08】自動ログインを実装しない。実装する場合は正しく実装する 自動ログイン機能は便利ですが、セキュリティ上のリスクを確実に増加させます。安全性が重要なサイトでは自動ログイン機能は実装すべきではありません。 自動ログイン機能を実装する場合、正しく実装しなければなりません。 間違った自動ログインの実装方法 セッションIDクッキーの有効期限を長くする 固定の自動ログイン鍵をクッキーに保存する 自動ログイン鍵をすべてのページで送信する 自動ログインの実装にはセッションID以外の予測不可能なランダム文字列を利用します。複数のWebブラウザから自動ログインできるようしたい場合、ユーザIDと自動ログイン鍵、その鍵の有効期限を保存したテーブルを作成して鍵を管理します。 正しい自動ログインの疑似コードは次のようになります。 /
クッキーには参照可能な範囲を制限する機能が定義されています。 パス プロトコル スクリプトからのアクセス の3種類の制限方法があります。制限するのではなく、反対に参照可能な範囲をドメインパラメータで増やすことも可能です。当然ですが参照可能なドメインを増やすのは好ましくありません。セッションIDを共用するアプリケーションが増えれば増えるほど、スクリプトインジェクションなどでセッションIDが漏洩するリスクが増加します。 同じドメインで複数のアプリケーションを利用している場合、パスでセッションIDを保存したクッキー送信を制限することができます。例えば、www.example.comドメインの/myapp/以下にアプリケーションがインストールされている場合、session_set_cookie_params関数を用いて以下のURLからのみクッキーを参照可能に設定できます。 http://www.e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
