CMS四天王のバリデーション状況を調査したところ意外な結果になった
バリデーションでSQLインジェクション攻撃をブロックしないCMSが多い ログインIDにおける典型的なSQLインジェクション攻撃として、'OR 1=1# をバリデーションがブロックするかどうかを確認しました。ログインIDとして許容される文字を見る限り、WordPress、Joomla、Drupalはブロックしそうですが、結果は下記の通りです。 WordPress: ブロックしない Joomla: ブロックする Drupal: ブロックしない MovableType: ブロックしない ということで、意外なことに、バリデーションでSQLインジェクション攻撃を止めるのはJoomlaのみという結果でした。 ログインIDにヌルバイトや改行が使えるCMSがある テストをしていてもっともびっくりしたことの一つがこれです。JoomlaとMovableTypeはヌルバイトや改行など制御文字がログインIDとして
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
ゆーすけべー日記
ユーザーからのPOST等された入力値の妥当性をチェックする Validation をどこでやるか問題が個人的にありまして〜、DBを使わないケースならばいわゆるFomrValidator::*を使ってControllerでやればいいのですが、Modelを経由するようなアプリだとControllerだけじゃ不安よねぇ〜、Modelだけ使う時もあるし、Model単体のテストで再現出来ないよね〜なんて思ってます。で、実際の実装をControllerではFormValidator::Lite、Modelの一部にData::Validatorを使っているのですが、なんかコレも効率悪い感じしてたんで、ちょいと実験的に理想の一つを実装してみました。 こんな条件です。 エラーメッセージを簡単に設定したいのでValidationモジュールにはFormValidator::Liteを使う 色々錯誤していたらOR
web アプリケーションの入力の validator の悩みを - soh335 memo
最近は考える事が多くて、全然しっくりこなくて困ってる。 rails 的な model に validator を寄せるのが良い時もあるし、やなときもあると思っていて、 controller で formvalidator に request object をぶつけて validate すると、model を他の controller ( api と web, admin とか ) で使う時に不安だなぁとは思う。 けど、同じ valiadte rule を各 controller でやるのはちょっと... みたいな感じもする。 page parameter は 1 から 200 までみたいなのはやっておいたほうがなんとなく安心だなぁというのもあるので、じゃあ data::validator で page 型を作るか ? みたいなことも考える。 けど、全部の parameter の型を作ってる
HTML5のclient-side form validationで書かれたattributeからvalidation rulesを抽出し、client/serverでルールを共通化するモジュールを書いた - Kentaro Kuribayashi's blog
Validation Ruleの記述ってけっこう面倒で、うまい方法を思いつけないのでいたのですが、今日、なんとなくHTML5にclient-side form validation specなんてものがあるんだから、それを使ったらいいんじゃないかと思って、ちょっと実装してみました。 http://prepan.org/module/3Yz7PYrBGs https://github.com/kentaro/HTML-ValidationRules 以下のようなメリットがあるのではないかと思っています。 client-side form validationを使いつつ、server-sideでも同じルールを別の形式で書くのは無駄感。 HTML5が、validation rulesをHTMLというフォーマットによって定めているとみなせば、client-side/server-side両方でそれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
