タグ

関連タグで絞り込む (7)

タグの絞り込みを解除

validationに関するsugyanのブックマーク (6)

  • 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の落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、RubyonRails 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 の型を作ってる
    web アプリケーションの入力の validator の悩みを - soh335 memo

  • 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両方でそれ
    HTML5のclient-side form validationで書かれたattributeからvalidation rulesを抽出し、client/serverでルールを共通化するモジュールを書いた - Kentaro Kuribayashi's blog
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.