このサイトのデータをエンコーダに入力する場合に、何か楽な方法はありますかね？
というかエンコーダを聞きたいのも一つですし、
またエンコーダに合わせてこのサイトも出力できればとは思っています。
例えば作曲等のクレジット情報無しのリストが有った方が良いのかとか
csvとか
というかエンコーダを聞きたいのも一つですし、
またエンコーダに合わせてこのサイトも出力できればとは思っています。
例えば作曲等のクレジット情報無しのリストが有った方が良いのかとか
csvとか
一週間前くらいに書いて放置してあったものがあったので書き込み。
もしセキュリティ面で心配という方がいたら、ということで。
現在会員制はα版として「セキュリティがどうかわからない部分がある」
と書いたと思いますが、正直セキュリティ面でβ版や正式版で修正される部分があるかというとわかりません。
というのも、正直なところその当たりのチェックに関しては作りながら出来る範囲で結構頑張ったからです。
こちらが意図しない値を入力されたらエラーを吐くようにしてます。
つまりは待ってもセキュリティはおそらくあんまり改善されない！ということです。
出来る限りのことはしているつもりですが、セキュリティ面が完璧だとは思っていません。
β版なら大丈夫とか、正式版なら大丈夫ってことはありません。
さてそれについてちょっと技術的気味な話↓
いわゆるハッキング・攻撃的な手法でやられるとどうなるか分からない、といった感じです。
例えば外部からのフォームデータの送信だとか、SQLインジェクションと呼ばれるSQL（データベース）の操作などがそれに当たります。
これらは偶然出てしまうバグではなく、知っている人が狙ってやらないと出ないものなのでわかりにくいのが実際です。
まあこんな弱小サイトを狙っても価値は無いと思いますから、試みる人もいないとは思いますけどね。
SQLインジェクションなんかはWikipediaによると、ここ最近結構企業サイトで多発しているようです。
ちなみにこのブログはBlogn+というものですが、先日SQLインジェクションに対する脆弱性が見つかって、更新されていました。
まあこの場合は改竄されてもブログの内容程度でしょうけどね。
ブログをテキストモードからDBモードに移行する際にアップデートしました。
あとは「クロスサイトスクリプティング」と呼ばれる物とかですね。
これもフォームから送信したデータを使った物です。
少し技術的な話になりますが、
だいたいは
文字コードはShift_JIS以外を使う
フォームのデータ等閲覧者側が変化できる項目は htmlspecialchars( $str, ENT_QUOTES ); を通す
ということでそのあたりは大丈夫だとは思います。
そもそも、半角英数字以外を通さないっていう部分には、別の処理を行えば、htmlspecialcharsの必要はないですが。
ようはこれらを、使う場所が適切になっているか、というのが重要な点です。
書いたつもりになっているだけかもしれませんからね。
またMySQLですと _ % あたりは任意の一文字という風になるので
_ % とエスケープしないと
ログインパスワード欄に ________ と入力されたときに、パスワードが８文字であればログインできてしまう、ということも注意したい点です。
というか、このログインのセキュリティに気づいたのはα版の公開直前だったりします（笑
IDやパスワードに_そのものが使えないようにするという方法が一つ（入力されていた時点でエラー）
毎回エスケープする方法が１つ
結局使えない様にしました。
ログイン時に入力するメールアドレスはこちらでどうこうできる物ではないのでエスケープするしか無いわけですが
他にもあるようなのですが、そっちの職業の人ではないのでよくわかりません。
まあ、ちゃんとその手のが施されているプログラムを見るのが早いのかもしれませんね。
まあセキュリティに関してはそれなりにやったつもりですが、
使い勝手に関してはわかりません。
使いにくい点などございましたら、メールフォームやmixiメッセージ、コメント等でご連絡頂けると幸いです。
もしセキュリティ面で心配という方がいたら、ということで。
現在会員制はα版として「セキュリティがどうかわからない部分がある」
と書いたと思いますが、正直セキュリティ面でβ版や正式版で修正される部分があるかというとわかりません。
というのも、正直なところその当たりのチェックに関しては作りながら出来る範囲で結構頑張ったからです。
こちらが意図しない値を入力されたらエラーを吐くようにしてます。
つまりは待ってもセキュリティはおそらくあんまり改善されない！ということです。
出来る限りのことはしているつもりですが、セキュリティ面が完璧だとは思っていません。
β版なら大丈夫とか、正式版なら大丈夫ってことはありません。
さてそれについてちょっと技術的気味な話↓
いわゆるハッキング・攻撃的な手法でやられるとどうなるか分からない、といった感じです。
例えば外部からのフォームデータの送信だとか、SQLインジェクションと呼ばれるSQL（データベース）の操作などがそれに当たります。
これらは偶然出てしまうバグではなく、知っている人が狙ってやらないと出ないものなのでわかりにくいのが実際です。
まあこんな弱小サイトを狙っても価値は無いと思いますから、試みる人もいないとは思いますけどね。
SQLインジェクションなんかはWikipediaによると、ここ最近結構企業サイトで多発しているようです。
ちなみにこのブログはBlogn+というものですが、先日SQLインジェクションに対する脆弱性が見つかって、更新されていました。
まあこの場合は改竄されてもブログの内容程度でしょうけどね。
ブログをテキストモードからDBモードに移行する際にアップデートしました。
あとは「クロスサイトスクリプティング」と呼ばれる物とかですね。
これもフォームから送信したデータを使った物です。
少し技術的な話になりますが、
だいたいは
文字コードはShift_JIS以外を使う
フォームのデータ等閲覧者側が変化できる項目は htmlspecialchars( $str, ENT_QUOTES ); を通す
ということでそのあたりは大丈夫だとは思います。
そもそも、半角英数字以外を通さないっていう部分には、別の処理を行えば、htmlspecialcharsの必要はないですが。
ようはこれらを、使う場所が適切になっているか、というのが重要な点です。
書いたつもりになっているだけかもしれませんからね。
またMySQLですと _ % あたりは任意の一文字という風になるので
_ % とエスケープしないと
ログインパスワード欄に ________ と入力されたときに、パスワードが８文字であればログインできてしまう、ということも注意したい点です。
というか、このログインのセキュリティに気づいたのはα版の公開直前だったりします（笑
IDやパスワードに_そのものが使えないようにするという方法が一つ（入力されていた時点でエラー）
毎回エスケープする方法が１つ
結局使えない様にしました。
ログイン時に入力するメールアドレスはこちらでどうこうできる物ではないのでエスケープするしか無いわけですが
他にもあるようなのですが、そっちの職業の人ではないのでよくわかりません。
まあ、ちゃんとその手のが施されているプログラムを見るのが早いのかもしれませんね。
まあセキュリティに関してはそれなりにやったつもりですが、
使い勝手に関してはわかりません。
使いにくい点などございましたら、メールフォームやmixiメッセージ、コメント等でご連絡頂けると幸いです。
おととい更新しましたが、時間がなかったのでBlogには書きませんでした。
会員制にしようかと思って、仕様などは練っているのですが、
色々面倒ですね。
会員制＝パスワードの管理があります。
当然暗号化を行うわけですが、使う側としてそれを信頼出来るのか、というのがあるでしょう。
通信は暗号化ではありません（非SSL）
まあ絶対にSSLじゃないといけないのは、クレジット番号を扱う時、ネットバンクくらいなのかもしれませんけどね。
もちろんSSLにできればそれに越したことはないんでしょうけど、サーバーが対応してない、お金がかかるなどの問題点がありますし、
そもそも使う側から見たら、パスワードが管理者（私）に丸見えかもしれない、と思うかもしれません。
企業だと大丈夫だろうと思いますが、何も暗号化せずに保存したら
メールアドレス×パスワード などの情報が手にはいるわけです。
もちろん手に入れたところで悪用すれば犯罪ですし、そんなことする気はありませんが、軽いフィッシングにも似た感じにもなりうるということです。
それはこのサイトにのみ言えることではなく、当然他のパスワード系のサイトでも同様の事が起きている可能性はありえます。
このあたりは信頼してくれと言うしかないのですが。。。
パスワードを管理するなどの仕組を作る以上ある程度は規約みたいな物も作らないといけませんしね。
あとはメールアドレスの認証だとか、いろいろと面倒くさそうですね。
面倒と言いつつ、いずれ、今年中くらいには形になった物が公開したいと思っています。
データベースだけだとコンテンツとして物足りないので、まあ今のうちに、WEB2.0的に自分以外が面白いことをやってくれるようなシステムが作れたらと思っています。
会員制にしようかと思って、仕様などは練っているのですが、
色々面倒ですね。
会員制＝パスワードの管理があります。
当然暗号化を行うわけですが、使う側としてそれを信頼出来るのか、というのがあるでしょう。
通信は暗号化ではありません（非SSL）
まあ絶対にSSLじゃないといけないのは、クレジット番号を扱う時、ネットバンクくらいなのかもしれませんけどね。
もちろんSSLにできればそれに越したことはないんでしょうけど、サーバーが対応してない、お金がかかるなどの問題点がありますし、
そもそも使う側から見たら、パスワードが管理者（私）に丸見えかもしれない、と思うかもしれません。
企業だと大丈夫だろうと思いますが、何も暗号化せずに保存したら
メールアドレス×パスワード などの情報が手にはいるわけです。
もちろん手に入れたところで悪用すれば犯罪ですし、そんなことする気はありませんが、軽いフィッシングにも似た感じにもなりうるということです。
それはこのサイトにのみ言えることではなく、当然他のパスワード系のサイトでも同様の事が起きている可能性はありえます。
このあたりは信頼してくれと言うしかないのですが。。。
パスワードを管理するなどの仕組を作る以上ある程度は規約みたいな物も作らないといけませんしね。
あとはメールアドレスの認証だとか、いろいろと面倒くさそうですね。
面倒と言いつつ、いずれ、今年中くらいには形になった物が公開したいと思っています。
データベースだけだとコンテンツとして物足りないので、まあ今のうちに、WEB2.0的に自分以外が面白いことをやってくれるようなシステムが作れたらと思っています。
