おさかなラボ - CAPTCHAを使わないspam判定
私はspamよけの専門家ではないので、この方法に欠点があったり、すでにある技法でしたらすみません。実際に導入してみたところ、1日300くらい来てたspamがぱったり止んだので紹介することにする。 私はCAPTCHAはあまり好きではありません。あれは私の脳を多少なりとも浪費させるし。誤判定すらある。 あと、普通のクイズ形式のCAPTCHAとかアホかと本気で思う。機械が人間に使われてどうする。 Googleなどではしかたないと思う。Googleだけをターゲットにするspammerがいるので、普通の対策はほとんど意味をなさない。 しかしうちのような一般のBlogに対する無差別なspam行為に対してはどうだろうか？個人BlogにCAPTCHは大げさすぎる。そこが有名サイトであるとか、DoS攻撃に遭っているならともかく、ごく単純な方法でspamよけは可能。「アルファベットのaを入れてください」とでも
おさかなラボ - passwordのより安全な保管方法(saltとは何か)
UN*Xパスワードの保存方法を知っている人には常識のはずだが、最近パスワードの保存方法について誤解が散見されるように思うのでこのエントリを立てた。 パスワードはMD5などでハッシュを取って保存する(DES等を使う場合もある)方法が広く使われている。その際、パスワードをそのままハッシュすると危ないので、プログラム側でMD5を取る時に、ランダムな定数を混ぜ、これのハッシュを取ることによってハッシュの安全性が増加する。つまり以下のようなコードになる $passwd = Digest::MD5::hex_md5($user_id . ‘woeifoweij’); # これで大丈夫(?) これで簡単にクラックすることはできない。 ……という理屈は正しいとは呼べない。パスワードに付加する文字列をsaltと呼んだりするが、これでは充分とは言えない。saltの利点はそれだけではないのだ。 このク
おさかなラボ - 礼儀正しい.bakファイルの作り方
バックアップファイルの作り方。20年近く前に教えてもらったもの。リビジョン管理が発達したせいか、知らない人が多かったので書いてみる。 cp foobar foobar.bak とするのではなくて、 mv foobar foobar.bak cp foobar.bak foobar とする。こうすることでタイムスタンプやらi-nodeやらも保持される。これは、 mv foobar{,.bak} cp foobar{.bak,} とも書ける。csh系であれば alias bak 'mv \!^{,.bak}; cp \!^{.bak,}' としておくと便利。bashのことはよくわからない。 カテゴリー » UN*X 投稿日 » 2007/09/26 水曜日 - 18:41:07 by かなだ コメントはこちらからどうぞ。ご自身のサイトからトラックバックを利用する場合は以
おさかなラボ / API駆動型開発ってアリかもしんない。
近年、様々なWebAPIが公開され、利用されるようになったが、MVCからWebAPIを呼び出すWebアプリケーションってコードがとてもスッキリする。 逆に、WebAPIの開発もWebアプリケーションに比べると肩の荷が軽い。API開発者は渡されたデータのハンドリングに専念でき、エラーハンドリングも楽（エラーコードを返せば良いだけ）だからだ。Viewに至ってはデータ構造をシリアライズ（JSONとかXMLとか）するだけですむ。 これって何も外部APIに限らなくても良いのではないか。Webアプリケーションから、ビジネスロジック部を内部専用の（つまりlocalhostからしかアクセスできない）WebAPIとして切り離し、それをWebアプリケーションから呼んでやれば、今よりももっと開発が楽になるのではないだろうか、というのが今日のお話。 WebAPIの開発も当然MVCフレームワークが使われるので
おさかなラボ - 人間様には見えなくて、spamボットには見える不思議なCAPTCHA
それは偶然発見した。なんとGmailのパスワード入力画面にもちゃんと歪んだ画像CAPTCHAが実装されているのだ。しかもほとんどのボットに見え、ほとんどの人間に見えないCAPTCHAである。ちょっとした工夫でCAPTCHAの欠点を補い、利点を生かしているのだ。見つけた時、思わず拍手してしまった。 事の始まりはこうだ。さっき、Gmailにログインしようとしたら、以下のようなエラーが出た。 平凡なエラーだ。しかしまずいことに、2度目、3度目も間違えた。そこでふと「Gmailは何回くらいでアカウントがロックされるんだろう」という疑問が湧いた。そもそも自分には、ブルートフォースアタックに対抗するにはアカウントロックしかないと考えていた。 するとなんと、10回目のミスで、次の画面が現れたのだ。 アカウントがロックされる代わりに、突然CAPTCHAが現れた。 つまりこうだ。パスワードを10回
おさかなラボ - 携帯電話のIPアドレス制限神話
珍しく間違った批判をしている高木先生＠y-kawazの日記 但し、キャリア毎にIPアドレス制限をする限りにおいて この前提を満たすことが可能なのかどうかについて。 DoCoMo(i-mode) 本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。 SoftBank 本情報はあくまでも目安としてご参照ください。ゲートウェイ以外から本ＩＰアドレスでのアクセスがない事を保証するものではありません。 au(EZweb) 本情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。 まるでコピp…いや判で押したような記述だ。つまり、この情報を元にIPアドレス制限を行なっても携帯電話からのアクセスであると保証されるわけではないということだ。これではいわゆる野良
おさかなラボ - 携帯電話からセッションIDの漏洩を防ぐ
携帯電話向けWebアプリの脆弱性事情はどうなっているのか@高木浩光＠自宅の日記 より リンク先のWebサイトには、Refererと共に端末IDもリクエストヘッダとして送信されているわけで、セッションID入りURLと端末IDがセットで流出するのだから、当然、同じHTTPリクエストを送るだけの方法でなりすましアクセスされてしまう。 URIにセッションIDを含める方法では、悪意のあるサイトにリンクを張るだけでRefererヘッダからセッションIDが取り放題となる。また、悪意のあるサイトにアクセスしたユーザーは端末IDもHTTPヘッダに含めそのサイトに送信してしまう。端末IDは簡単に詐称することが出来るので、端末IDをチェックしてもセッションハイジャックの防止線にはならない、というお話。 私は携帯端末は専門ではないので細かいことは良くわからないのだが、以下を前提にして、携帯電話からセッション
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
