http://softonhouse.jp/sakadon テストブログ ja 使ってみるテスト。 http://softonhouse.jp/sakadon~3575 2009-10-04T10:18:04+09:00 気になったので久々にログインしてみた。ユーザ新規登録に、CAPTCHAっぽいのがあるけれども、これはこれはとても解析しやすいCAPTCHAだなあと思った。まず、画像1つ1つが切り離されてる。これだと、解析する画素数が少ないので、まあ分布的に何の文字か解析しやすくなってしまう。さらに、HTML上からの呼び出しが普通にimg要素による表現のため、ファイル名から用意に分かってしまう。http://softonhouse.jp/images/user/C1.jpghttp://softonhouse.jp/images/user/C2.jpghttp://softonhouse.jp/images/user/C3.jpghttp://softonhouse.jp/images/user/C4.jpghttp://softonhouse.jp/images/user/C5.jpghttp://softonhouse.jp/images/user/C6.jpghttp://softonhouse.jp/images/user/C7.jpghttp://softonhouse.jp/images/user/C8.jpghttp://softonhouse.jp/images/user/C9.jpghttp://softonhouse.jp/images/user/C0.jpgしかも、模様がランダム生成とかではなく1つだけなので、より解析する負担が減る。つまり、その画像がどんな文字か分かったらOKでござる的。すなわち、これは人間が素直に画像を見て解読するより、何らかのプログラムが処理したほうが早いですね。意味が無いので、取っ払った方が良いです。もしくは、世の中にはCAPTCHAのAPIがあるんでそれを利用するのも手です。あとは、OpenIDとかそういうのも良いかと思います。むしろ、なぞなぞ認証とかどうですかね。そっちの方がまともなCAPTCHAより実装楽かもしれません。
ユーザ新規登録に、CAPTCHAっぽいのがあるけれども、これはこれはとても解析しやすいCAPTCHAだなあと思った。

まず、画像1つ1つが切り離されてる。これだと、解析する画素数が少ないので、まあ分布的に何の文字か解析しやすくなってしまう。
さらに、HTML上からの呼び出しが普通にimg要素による表現のため、ファイル名から用意に分かってしまう。

http://softonhouse.jp/images/user/C1.jpg
http://softonhouse.jp/images/user/C2.jpg
http://softonhouse.jp/images/user/C3.jpg
http://softonhouse.jp/images/user/C4.jpg
http://softonhouse.jp/images/user/C5.jpg
http://softonhouse.jp/images/user/C6.jpg
http://softonhouse.jp/images/user/C7.jpg
http://softonhouse.jp/images/user/C8.jpg
http://softonhouse.jp/images/user/C9.jpg
http://softonhouse.jp/images/user/C0.jpg

しかも、模様がランダム生成とかではなく1つだけなので、より解析する負担が減る。つまり、その画像がどんな文字か分かったらOKでござる的。
すなわち、これは人間が素直に画像を見て解読するより、何らかのプログラムが処理したほうが早いですね。

意味が無いので、取っ払った方が良いです。もしくは、世の中にはCAPTCHAのAPIがあるんでそれを利用するのも手です。
あとは、OpenIDとかそういうのも良いかと思います。

むしろ、なぞなぞ認証とかどうですかね。そっちの方がまともなCAPTCHAより実装楽かもしれません。]]>脆弱性メモ sakadon http://softonhouse.jp/sakadon~735 2008-12-07T15:27:22+09:00 ブログを書く際に、様々なHTMLを利用することにより表現の幅が広がります。さて、ここでどのようなHTMLを認可すると良いか、簡単に検討してみましょう。HTMLには、大きく分けて3種類あります。インライン要素ブロック要素その他の要素1番目のインライン要素とは、主に文字列の意味を定義付けする際に仕様する要素です。この要素を駆使することによって、単なる文字列が意味のある文章へと変化します。主にHTMLで良く使われるのはインライン要素となります。ブロック要素は、その名の通りで主に段落や文章全体のセクションを分ける為に使用します。デザインのためにも使われますが、デザインのために要素を使うのは意図されていない使われ方です。その他は、強制改行要素などの空要素、インライン要素だったりブロック要素になったりする変化要素なども有ります。詳しくは用語の説明を参照。ここで今回意識するのは、脆弱性を産まない要素を探す事です。例えば、インライン要素でも意味付けだけの要素であるem要素やq要素cite要素、code要素、samp要素などは許可しても差し支えは無いでしょう。ブロック要素でも、p要素やbr要素などあります。基本的な部分は許可してもまあ大丈夫でしょうが、これらは記述表現で代用が出来ます。例えば段落は、投稿内容記入欄で1行の前後に改行が有ればそれを1つの段落と認識してp要素で囲むのが通常だと思われますし、強制改行であるbr要素も、イコールただの改行と捉えても問題はありません。むしろ、br要素などは許可を与えるとbrを1行に30個書けば30行改行されるという書きやすさという脆弱性（嫌がらせとも言うか）があります。出来れば只の改行をbrと見なして解釈し、連続改行の数も制限した方が良いかと思われます。さて、問題が無い要素を出すのは難しいですが、もうハッキリとダメと言える要素を出すのは簡単です。まずは要素外に記述する要素、html要素や要素、要素（つまり2個以上書く）、link要素要素などは要素の中に記述することは論外なので、エラー判定することが出来ます。html要素や要素が2個以上あるとブラウザによってはレンダリングがずれる場合も有ります。また、要素に記述出来るが是非エラー判定して頂きたいものとしては、java要素要素、param要素、要素フレーム関連（要素など）全部フォーム関連（form要素や要素など）全部（と言ってもlegend要素やlabel要素は大丈夫です）あたりでしょうか。特にjava要素は勝手にjavaを動かされる危険性、要素などは勝手にFlashやexeファイルまでもを読み込まれる危険性、では勝手にJavaアプレットなどが、フレームでは要素をつかって他の外部ページを読み込ませる事ができる危険性、フォーム関連では個人情報を引き出される可能性（を使えばブラウザが記入欄に記載済みで、あとは投稿ボタンを間違って押して貰えば個人情報が入手可能に！）があります。もっと厳密な判定判断が出来れば、Flashを読み込んだりすることで幅を広げることも可能ですが、直接HTMLでそれをやらせるのは現実的ではありません。出来れば、Flash等を記事へ貼る際には独自記法を採用し、HTMLで必要以上な事をさせない、許さない事が基本です。また、要素だけ語っても意味がありません。その要素自体がまったくの無害であっても、属性値が悪意を持つ場合があります。その中でも、style属性は諸刃の刃です。参考までに以下にstyle属性でフォントサイズを50pxに、文字色を赤にした文字列を用意しました。どぎゃーん！このように、表現次第では無害な使われ方ですが、悪意を持ったことも出来るのは確かで、200pxあたりの文字列を並べられても困りどころです。しかし、表現の幅が広がるとても便利な属性なので、厳密に判断できる処理を施し、解禁すると良いのではないでしょうか。はてなダイアリーの例が良い例です。その他にも、脆弱性、危険性、迷惑性を含めた属性は色々とあります。が、そろそろ長ったらしく飽きてきたのでこの辺にしときます。あと、特筆事項としては要素、span要素は、意味を持たない要素（要素は文章のセクションを分けるとかに使いますが）なので、基本的にダメという形にしておいたほうが良いかもしれません。この辺はポリシーに沿って許すかどうかを決めると良いかと思います。また、フォント要素というものもあり、意味を持たない要素のことを指します。例えばfont要素、i要素、b要素、center要素などです。これらも意味を成さない要素なので除外すべき（現に最新のHTMLでは非推奨）ですが、初心者には扱いやすいので許可しておいても差し支えないのと思います。そろそろ飽きたのでこの辺にしておこう。まあHTMLは様々な要素がまだまだたくさんあります。一つ一つ精査して行くのが良いかとおもいます。XHTML リファレンスなどを見るとおおざっぱにHTMLの要素について分かるのではないかとおもいます。XHTMLとHTMLの違いなどは、ここでは特に気にしなくても良いと思いますので説明しません。ああ、長かった。
さて、ここでどのようなHTMLを認可すると良いか、簡単に検討してみましょう。
HTMLには、大きく分けて3種類あります。

1. インライン要素


2. ブロック要素


3. その他の要素

1番目のインライン要素とは、主に文字列の意味を定義付けする際に仕様する要素です。この要素を駆使することによって、単なる文字列が意味のある文章へと変化します。主にHTMLで良く使われるのはインライン要素となります。
ブロック要素は、その名の通りで主に段落や文章全体のセクションを分ける為に使用します。デザインのためにも使われますが、デザインのために要素を使うのは意図されていない使われ方です。
その他は、強制改行要素などの空要素、インライン要素だったりブロック要素になったりする変化要素なども有ります。
詳しくは用語の説明を参照。

ここで今回意識するのは、脆弱性を産まない要素を探す事です。
例えば、インライン要素でも意味付けだけの要素であるem要素やq要素cite要素、code要素、samp要素などは許可しても差し支えは無いでしょう。
ブロック要素でも、p要素やbr要素などあります。基本的な部分は許可してもまあ大丈夫でしょうが、これらは記述表現で代用が出来ます。
例えば段落は、投稿内容記入欄で1行の前後に改行が有ればそれを1つの段落と認識してp要素で囲むのが通常だと思われますし、強制改行であるbr要素も、イコールただの改行と捉えても問題はありません。
むしろ、br要素などは許可を与えるとbrを1行に30個書けば30行改行されるという書きやすさという脆弱性（嫌がらせとも言うか）
があります。出来れば只の改行をbrと見なして解釈し、連続改行の数も制限した方が良いかと思われます。

さて、問題が無い要素を出すのは難しいですが、もうハッキリとダメと言える要素を出すのは簡単です。
まずは要素外に記述する要素、html要素や要素、要素（つまり2個以上書く）、link要素要素などは要素の中に記述することは論外なので、エラー判定することが出来ます。html要素や要素が2個以上あるとブラウザによってはレンダリングがずれる場合も有ります。
また、要素に記述出来るが是非エラー判定して頂きたいものとしては、

• java要素


• 要素、param要素、要素


• フレーム関連（要素など）全部


• フォーム関連（form要素や要素など）全部（と言ってもlegend要素やlabel要素は大丈夫です）

あたりでしょうか。特にjava要素は勝手にjavaを動かされる危険性、要素などは勝手にFlashやexeファイルまでもを読み込まれる危険性、では勝手にJavaアプレットなどが、フレームでは要素をつかって他の外部ページを読み込ませる事ができる危険性、フォーム関連では個人情報を引き出される可能性（を使えばブラウザが記入欄に記載済みで、あとは投稿ボタンを間違って押して貰えば個人情報が入手可能に！）があります。

もっと厳密な判定判断が出来れば、Flashを読み込んだりすることで幅を広げることも可能ですが、直接HTMLでそれをやらせるのは現実的ではありません。
出来れば、Flash等を記事へ貼る際には独自記法を採用し、HTMLで必要以上な事をさせない、許さない事が基本です。

また、要素だけ語っても意味がありません。その要素自体がまったくの無害であっても、属性値が悪意を持つ場合があります。
その中でも、style属性は諸刃の刃です。参考までに以下にstyle属性でフォントサイズを50pxに、文字色を赤にした文字列を用意しました。


どぎゃーん！


このように、表現次第では無害な使われ方ですが、悪意を持ったことも出来るのは確かで、200pxあたりの文字列を並べられても困りどころです。
しかし、表現の幅が広がるとても便利な属性なので、厳密に判断できる処理を施し、解禁すると良いのではないでしょうか。はてなダイアリーの例が良い例です。
その他にも、脆弱性、危険性、迷惑性を含めた属性は色々とあります。が、そろそろ長ったらしく飽きてきたのでこの辺にしときます。

あと、特筆事項としては要素、span要素は、意味を持たない要素（要素は文章のセクションを分けるとかに使いますが）なので、基本的にダメという形にしておいたほうが良いかもしれません。この辺はポリシーに沿って許すかどうかを決めると良いかと思います。
また、フォント要素というものもあり、意味を持たない要素のことを指します。例えばfont要素、i要素、b要素、center要素などです。これらも意味を成さない要素なので除外すべき（現に最新のHTMLでは非推奨）ですが、初心者には扱いやすいので許可しておいても差し支えないのと思います。

そろそろ飽きたのでこの辺にしておこう。
まあHTMLは様々な要素がまだまだたくさんあります。一つ一つ精査して行くのが良いかとおもいます。XHTML リファレンスなどを見るとおおざっぱにHTMLの要素について分かるのではないかとおもいます。
XHTMLとHTMLの違いなどは、ここでは特に気にしなくても良いと思いますので説明しません。

ああ、長かった。]]>脆弱性メモ sakadon http://softonhouse.jp/sakadon~733 2008-12-07T15:06:50+09:00 バグのメモなので簡単に書き留めておくコーナー。気づいた時にテキトーに書く。自分の詳しいプロフィール画面で、どうやら記入した文字列が別な所へ継承されるようで…上記リンク先の例だと、私の秘密に書いたものが、他の書いていないはずの欄へ継承されていることが分かると思います。コレを応用するととんでもない事になるので辞めておくことにする。
自分の詳しいプロフィール画面で、どうやら記入した文字列が別な所へ継承されるようで…

上記リンク先の例だと、私の秘密に書いたものが、他の書いていないはずの欄へ継承されていることが分かると思います。
コレを応用するととんでもない事になるので辞めておくことにする。]]>バグメモ sakadon http://softonhouse.jp/sakadon~732 2008-12-07T14:49:12+09:00 さて、このブログサービスでは各所で画像などのアップロードが出来ます。それは素敵な事なのですが、画像などにはメタデータとして様々な情報を入力しておくことが可能です。間違って、その情報（文字列です）がプログラムのしゃくに障るようなものであったら、どうなってしまうでしょう。最悪、バッファオーバーフローしてブラウザが落ちる、コンピュータがクラッシュしてしまうなどの危険も伴います。また、このブログでは有る程度のファイルチェックを行なっているみたいですが、危険なファイルがチェックを通過してアップロードされてしまったら、そしてそれが原因でここのユーザのコンピュータにウイルスが…などという危険性（他にも有りますが）が存分に含まれています。対策をお願いしたいところです。有名なはてなのブログサービス、はてなダイアリーでは脆弱性に対しての対策をリストアップした記事があります。参考までに。はてなダイアリーXSS対策
それは素敵な事なのですが、画像などにはメタデータとして様々な情報を入力しておくことが可能です。
間違って、その情報（文字列です）がプログラムのしゃくに障るようなものであったら、どうなってしまうでしょう。
最悪、バッファオーバーフローしてブラウザが落ちる、コンピュータがクラッシュしてしまうなどの危険も伴います。
また、このブログでは有る程度のファイルチェックを行なっているみたいですが、危険なファイルがチェックを通過してアップロードされてしまったら、そしてそれが原因でここのユーザのコンピュータにウイルスが…

などという危険性（他にも有りますが）が存分に含まれています。
対策をお願いしたいところです。

有名なはてなのブログサービス、はてなダイアリーでは脆弱性に対しての対策をリストアップした記事があります。参考までに。
はてなダイアリーXSS対策]]>脆弱性メモ sakadon http://softonhouse.jp/sakadon~731 2008-12-07T14:34:42+09:00 まあ気が向いてるので、色々書こう。このブログサービスでは、URI（URLとも言いますね）が hoge.asp?user=username~id のような形ですが、ちょっとURIに小細工をすると、やはりこれもXSSな感じになって割と簡単に以下略。ここで怖いのは、URIでの判定で内部プログラムのバグを当たられたりして、もごもごされちゃった日にはサーバ側が最悪な事になる危険性も！一番いやなのは、ユーザリストが見えたりしたり、ユーザの情報が引き出されたりなど、ですかね。出来れば、URIの設計も見直した方が良いかもしれません。サービス開始した後だから難しいかもしれないけど…。何事も基礎があるから自治が形成されると思うので、基本的な対策は打っておいて損はありません。この辺のリスクマネジメントをしっかりと行なう事でユーザも安心して使ってくれるのではないでしょうか。
このブログサービスでは、URI（URLとも言いますね）が hoge.asp?user=username~id のような形ですが、ちょっとURIに小細工をすると、やはりこれもXSSな感じになって割と簡単に以下略。
ここで怖いのは、URIでの判定で内部プログラムのバグを当たられたりして、もごもごされちゃった日にはサーバ側が最悪な事になる危険性も！
一番いやなのは、ユーザリストが見えたりしたり、ユーザの情報が引き出されたりなど、ですかね。
出来れば、URIの設計も見直した方が良いかもしれません。サービス開始した後だから難しいかもしれないけど…。

何事も基礎があるから自治が形成されると思うので、基本的な対策は打っておいて損はありません。
この辺のリスクマネジメントをしっかりと行なう事でユーザも安心して使ってくれるのではないでしょうか。]]>脆弱性メモ sakadon http://softonhouse.jp/sakadon~730 2008-12-07T14:24:33+09:00 プロフィールなどの記入欄にHTMLを記入すると割と普通にそのまんま出るので、割と普通にjava読み込んだりとかFlash読み込んだりして、割と簡単にクラックしたりなども出来ます。こういうのを、XSS（クロスサイトスクリプティング）といって、基本的にウェブサービスなどを行ないブラウザ上から記入できる投稿フォームなどを設計スル際には、特に注意しなければならない部分ですので、ぜひ対策してほしいなあと。alert("あばばばばばばば！こんちは！");詳しくは、＠IT：クロスサイトスクリプティング対策の基本。まずはこの対策をされたらまた何か、書こう。
こういうのを、XSS（クロスサイトスクリプティング）といって、基本的にウェブサービスなどを行ないブラウザ上から記入できる投稿フォームなどを設計スル際には、特に注意しなければならない部分ですので、ぜひ対策してほしいなあと。
<>alert("あばばばばばばば！こんちは！");

詳しくは、＠IT：クロスサイトスクリプティング対策の基本。

まずはこの対策をされたらまた何か、書こう。]]>脆弱性メモ sakadon http://softonhouse.jp/sakadon~729 2008-12-07T14:15:38+09:00 が、この、もやもやとする部分が多いのは、なぜ、だ。どこから突っ込むと良いんだろ…うか…
どこから突っ込むと良いんだろ…うか…]]>ほげ sakadon