「CSRF」を含む日記 RSS

はてなキーワード: CSRFとは

2018-12-18

(PHP) phpMyAdminのセキュリティー

アドバイスどうもありがとうございます

https://anond.hatelabo.jp/20181218231219

本番サーバには入れないでね

phpMyAdminセキュリティーって、過去の事例を見ると、あまり高くないようですね?

この手の管理ツールセキュリティ侵害を受けた場合ダメージが大きいので、インターネットからアクセスできないようにしておくのが基本です。特にphpMyAdmin過去に致命的な脆弱性が何度も発見されており、インターネットさらして利用するには向いていません。任意コード実行可能脆弱性の事例もあり、DB以外にもリスクがあります

 

内部ネットワークからしかアクセス出来ないようにしておきましょう。レンタルサーバのようなインターネット孤立したサーバであっても、VPNの経路を作りそちらからしかアクセス出来ないようにしておくようにした方がよいでしょう。

 

IPアドレスによる制限は次善策です。アクセス元のIPアドレスが固定されており他人と共有していないならそれなりに安全になります

 

URLによる隠蔽は外部から攻撃可能な既知の脆弱性スキャンするようなカジュアルアタック避け程度にはなりますが、URLは何かと漏洩するものですので、一般セキュリティ手法と見なされていません。

 

アクセス制限をした場合でも、認証は必ず設定する必要があります。例えばCSRFのような攻撃にはアクセス制限無意味です。

 

phpMyAdmin認証HTTP認証のどちらを使う方がよいかは使ったことがないのでわかりませんが、HTTP認証場合BASICではなくダイジェスト認証にしてください。BASIC認証は(ほぼ)生で認証情報が流れますので使ってはいけません。(ブラウザで人が操作する場合以外にはBASIC認証を使わざるを得ない場合もあります

対応

  1. phpMyAdminローカルの開発サーバーで使う。
  2. 本番サーバーのMySQLメンテナンスときだけ、Adminer.php等を使う。(使用前にコピーして、使用後は削除する) もしくはMySQLコマンド操作する。

こんなかんじでしょうか?

2018-08-04

普段使ってるサイトCSRF脆弱性を見つけた

IPAに届け出たら一週間くらいで修正されてた。

でも明らかに軽微な脆弱性だったから直接サイトに問い合わせたほうがよかったのかわからん

IPAの届出フォームも複雑で一度挫けかけたし素人には難しいわ。

2018-04-29

anond:20180429125147

こんにちは元増田です!

増田も大歓迎です!貴重なご意見ありがとうございます

荒らし対策については、実はあまり考えてません!

もちろん、CSRFとかXSSとかDos攻撃とか、セキュリティ上最低限の対策は取るつもりですが、それ以外は良いね/悪いねの数で投稿を大きくしたり小さくしたり、ユーザー側で一日限りのidを毎回弾いてもらったりとか、「どっかで見たなそれ」的なことしか考えてません!

なるべく投稿の敷居を下げたいという思いがあるのと、あとは何より、アカウント情報管理がめんどくさい!のです…

Twitter連携とかも今は簡単にできちゃうんですが、やりません!

はいえ万が一軌道に乗るなんてことがあれば、アカウント制については考えなきゃいけない時期が来るだろうなとも思ってます

そんな感じです!

2018-03-20

文系エンジニアなんて死ねばいいのに

文系エンジニアなんて死ねばいいのに

俺、Webサービス作ったんすよ(Rails

俺、iOSアプリ作ったんすよ(Swift

俺、Macbook使ってるんすよ(タッチバー付13インチPro

俺、プログラミングスクールプログラミング教えるアルバイトしてるんすよ(そいつはそのスクール卒業生

これぞ量産型文系エンジニア()

懇親会で「皆さん嫌いな言語とかフレームワークはありますか?」と話題になると私は即座にRailsと言う。

すると文系エンジニアはみんな嫌な顔をする。

そこでちょっとお話をすると皆怯んじゃう。

「あのコマンドを打つと中で何が起きてるか知ってますか?」(知らない

ActiveRecord?生でクエリいたことあるインデックス意味くらい知ってるよね?」(書いたことない、適当なこと言う

へーその作ったサービスURL教えてよ

3分

「alert('XSS')」

Session?Cookie?(何それどんな味のクッキー

CSRF?(企業理念か何か?

百歩譲って学生エンジニアならまあセキュリティ無知なのは分かる。

しかしだな、文系エンジニアは「俺もハッキングしたい(笑)」な勢いで詳しく解説することを要求してくる。非常にウザい。

"

お前はよぉ!自分で探すってことをできねぇのかよ!?

"

しょうがないので優しく解説すると「君ってハッキングとかしてそう(笑)」「君将来ハッカーになりそうだわ(笑)クラッキング的な意味で)」

死ねよ。

文系エンジニアはこれだけではない

俺、Git使って開発したんすよ(GUIのSourcetree

え?バグちゃんテストしたんだけどなぁ(完全手動テスト()

デプロイ先は9割Heroku。(HTTPS対応

AWSGCP登録はしたものの使い方が分からなくて結局放置

SSH証明書を使わずパスワードオンリー

pwdcdしか知らない(Makefileを作ったことないからいつもネットコピペコマンド

見た目重視のTerminal(ネットコピペ設定)

最近聞いた文系エンジニアもっと面白い

新規事業を開発してる文系エンジニア集団がいた。

開発は順調、プロモーションをかけていざリリース

はいゴールデンタイム鯖落ち。復旧した時にはゴールデンタイム終了のお知らせ

理由CDNを刺してない、貧弱なプランの鯖(勿論ロードバランサなんか使ってない)

噂による無線LANルーターの設定も出来ないレベルらしい。

でも彼らは一応優秀な文系エンジニア高学歴サービスも作ったこともある、それなりの実績も持っている。しか文系だ。

こういう奴らがいるかちゃんとしたエンジニアを軽視される。黙って営業職に転職してこい。

まあでも大学じゃ作者の気持ちしか考えてないのだから当然のなのかもな(笑)


追記

残念な理系名前を書くだけ一発採用派遣SIer対象としてない。論外だ。

給料が安い?

そんなことは無い。400万以上貰える会社内定もらっているか嫉妬も不満も特に無い。

だがしかし、ムカつく。

そんな奴が同期にいたら蹴り飛ばしてやりたくなる。

そうさ、今はSwiftiOS時代だ。

だが見てみろ、あいつらのアプリバックエンドが無いんだぞ?意欲は認める。だがそれで胸を張ってiOSエンジニアなんて無理があるだろ?

2017-01-20

短縮URL使う人が気持ち悪い

URLでググっても中身がわからいかCSRFみたいなのを警戒する

アングラ系の掲示板でもないのに短縮URL使う人って何を意図してるの

2016-09-03

http://anond.hatelabo.jp/20160902031012

http://anond.hatelabo.jp/20160902031012

はてブ批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみますおっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。

大学に行っても実用的なソフトウェアを書けるようにはならない

実務の話!! 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの

技術実態みたいなやつ。そういうのは学校で教わらないんですよね。

まず、日本大学勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。

これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間認知されてないというだけです。

具体的に挙げてみましょう。

大学で教えてる内容ってこんな感じなので、ゲームアプリサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学情報学科を出ていないのにゲームiOSアプリWebサービスを作っている人はゴマンといるし、逆に日本大学先生ゲームiOSアプリWebサービスを作れる人はほとんどいません。

日本大学先生実用的なアプリサービスを作った経験がない

これは重要ことなのでもう一度書きますが、日本大学先生ゲームアプリサービスを作れる人はほとんどいません。大学先生が得意なのはプログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。

そのため、大学勉強してもゲームアプリサービスが作れるようにはなりません。だって教えている側の先生が、ゲームアプリサービスを作ったこともなければ、作り方も知らないんだから

そういう経験のない人たちばかりですよ、日本大学先生って。そんな人たちの授業を受けて、アプリサービスが作れるようになると思うほうがおかしいでしょう。

ためしに、先生方のTwitterアカウント名でGithub検索してみてください。いまどきGithubアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないかGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ?

あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか?きっとXSSCSRFも知らないですよ。

ですので、そういうことを勉強したいなら、ベンチャーIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
(「大学はそんなことを教える場所ではない!」と怒る人いると思うけど、教えられる先生がいないという事実ごまかすために怒ってるだけだから。)

ジャンルが違う

はいっても、大学先生プログラムがいっさい書けないというわけではないです。彼らが得意なのはコンパイラインタプリタOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームアプリサービスとはジャンルが大きく違います

そのため、大学情報学科に進めばコンパイラOS機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームアプリサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。

大学で教えている内容ってムダなのか

じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。

大学で教えている内容って、ゲームiOSアプリWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、

こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。(情報系の学科で学んでいるなら、ライブラリ言語OSを「使う人」ではなく「作る人」にぜひともなってほしいですね。)

元増田に進めたい進路

元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。

こういう事情なので、元増田には大学ドロップアウトしてIT系会社入社することをお勧めします。ドロップアウトが難しいなら、インターンバイトでなんとしても入り込むことです。

入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなPixivクックパッドDeNAドワンゴ教育制度確立しているようです(違ってたらごめん)。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田目的にかなうのは間違いありません。

そして何年か働いて、iOSアプリWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。

上で説明したように、大学というところは、ゲームアプリサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田IT系会社に入ってアプリサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。

なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています

残念ながら、そういう会社東京に集中しているようです。例外京都はてなくらいでしょうか。地方大学生にとってはつらい現実なので、はてなPixivドワンゴ地方でのインターン開催をお願いします。あとレベル5は九大と九工大学生を鍛えてあげてください。

余談ですが、学生さんにひとこと:

インターンバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトからとかインターンからという軽い気持ち会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。

大学で授業を受けなくても独学で効率的勉強する方法

ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。

リツイートが100超えたら書く。

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-05-22

http://anond.hatelabo.jp/20160522003506

http://anond.hatelabo.jp/20160522003506

ども。

この辺りの一連の発言特に後二者)を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAWeb APIといったフロントエンド世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます

ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データ配信DB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリレベルに追いつき、同じやり方ができるようになった、というだけの話です。

とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。

具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドリアルタイム集計が登場する勤務予定表的なものを、1人でjQuerySPAで作った際、数百行のHTMLと数千行のJSスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代ベスト」として自信を持って残せますJSX局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません(私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います)。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。

「変な独自拡張を入れてまでJSを使い続ける理由わからん」についても、まるでJS生来嫌われ者で、クライアント側でもPythonRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね? たぶんES6は人々から積極的に愛されています。現状、クライアント側にPython進出するのではなく、逆にデスクトップモバイルサーバ側にどんどんJavaScript進出する流れが起きています

速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね(mustache使うよりは速いよね)ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通JS技術者普通に触れる程度の成熟はしています(枯れたとまでは言いませんが)。

2016-05-21

http://anond.hatelabo.jp/20160521190026

元増田です。

SPAは、クライアントが自立した1プログラムとして状態管理する。サーバUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバサーバサイドページ生成のスタイルを、サーバブラウザでやるようにシフトさせたものともみなせるだろう。

手間がかかりません?さらにもともとほぼサーバー側だけで済んでいたものを分けることでCSRFやSQLiなどの変なバグを仕込む可能だってありますよね。これに見合うメリットが見えないのですがいかがでしょうか。

そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。

というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。シンタックスハイライトとかインデントも効かないじゃないですか。そういう点ではAngularJSが一番気持ちいいですが。。

まあそれはそれとして、なるほど、JSX別にどうでもいい、というのはわかりました。まぁそれならわからんでもないです。

すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーものとしては残り続けるだろうが。

ここわかんないですね。活発なメンテがそんなに重要なのかな?ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか?

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

2016-03-11

増田ユーザだがカクヨムが利用できないはてな死ね

何故なら、w3mでカクヨムにログインしようとすると「csrf token required」とか出てログインできないからだ!

実質テキストサイトの癖にテキストブラウザログインできないとは何事だ!

作家として活躍出来ねーじゃん。はてな死ね

2014-06-27

徳丸本の内容を実践しながら学べた話

新卒入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェア制作販売するソフトウェアハウスだった。

入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページ管理があった。主な業務は、ページの文章更新と確認、誤字脱字の修正、古く間違ったHTML修正など。

会社ホームページには自社のサービス製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションセキュリティ勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。

から読み進める。1章に用語の整理があるおかげでだいぶ理解やすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。

なるほど、XSSクロスサイトスクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックス入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社ホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テストサーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……

検索ワード:
   +----------------+
   |                |
   |   1            |
   |       [  OK  ] |
   +----------------+

なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性修正の実習もできるな。

このようにして、徳丸本を読み進め、(テストサーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:

  1. 上述のXSS。直した。
  2. SQLインジェクション - XSSと同様の検索フォーム部分、ログイン部分。誰のアカウントにでもログインできた。急いで直した。
  3. CSRFクロスサイトリクエストフォージェリ) - ログイン済みのユーザを細工されたページに誘導すると、パスワード任意の値に変更できた。すぐ直した。
  4. クッキー不適切な利用 - httponlyでないCookieに、ユーザIDパスワードナンチャッテ暗号化(全ユーザ統一の値でxorしただけ)して保存していた。1のXSSとの合わせ技でその内容を外部に送信できたし、暗号の強度もダメだったし、そもそもログイン自体に使う情報Cookieに保存すべきではない。しかしこのCookie依存している箇所がたくさんあったため、XSS修正とhttponlyの対応だけになった。一応直った。

ショッピングシステムの中身が、フレームワークライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。

これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性始末書は、すべて現在担当である自分が書くことになった。

自分入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会コードレビューバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。

自分の作業はすべてgitで記録していたので、自分担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験からバージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。

こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さら勉強し、3年目に入るころには情報セキュリティスペシャリスト試験合格し、転職した。

Webサービスセキュリティ勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験環境CDもついているので、A社でホームページ担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)

すばらしい本を書いてくださった徳丸先生感謝します。

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

2014-05-20

http://anond.hatelabo.jp/20140520124907

犯人かどうか、というのは率直に言えばどうでもよろしい。

そんなもの警察法曹に任せておけばいい。

私個人の関心事項は、遠隔操作CSRFなどにより、犯罪踏み台にされること、

そして踏み台であったことをいかにして証明できるか、って事だった。

から片山容疑者無罪であったとして、それをいかにして証明できるのか。

そこを考え/学び/検証する必要があると考えている。

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。

プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう

求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった

バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった

3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?

5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...

7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。

8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー

9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた

11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。

2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。

気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする

今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

2013-09-27

君たちが増田に書いた記事を全部削除してしまおう!

ハローエブリバディ。

皆様、自分増田に書いた恥ずかしい記事を削除したいとか考えちゃっていたりしませんか?

心当たりのあるあなたに。思い切って、全部の記事を削除してしまいましょう!

というわけで、増田の全記事を削除するシェルスクリプト作成いたしました。

以下に説明するので、皆様使ってみてくだされ。

1.まず、適当bashwgetが使えるunixマシンログインします。

Linuxmacでも大丈夫。でもmacwget入ってないかもしれません。curlでも行けるけど…今回はwgetで。

ユーザとかは特に関係ありません。

レンタルサーバであっても、wgetコマンドが使えるのならば動作するはずです。

まずはwgetと打ってパスが通っているかコマンドが使えるかチェック!

2.以下のスクリプトを、適当コピーしてmasuda_delete.shとでも名前をつけてログインしたマシンに保存します。

おっと、保存する前に「"{!!!!!!PLEASE INPUT MASUDA ID!!!!!}";」の部分に自分増田ID入力して、

「"{!!!!!PLEASE INPUT MASUDA PASSWORD!!!!!}"」の部分に増田ログインパスワードを入れるのを忘れないで!

大丈夫ローカルで実行するだけだからパスワード漏えいとかは気にする必要はありませんよ。

シェルスクリプトなので、実行属性を付けるのを忘れずに。

chmod +x masuda_delete.sh

で実行属性が付けられますよ。

  #! /bin/bash
  cookie="/home/${USER}/cookie"

  HATENA_ID="{!!!!!!PLEASE INPUT MASUDA ID!!!!!}"
  PASS="{!!!!!PLEASE INPUT MASUDA PASSWORD!!!!!}"

  URL="http://anond.hatelabo.jp/${HATENA_ID}/"
  LOGIN_URL="https://www.hatelabo.jp/login"
  ua='Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405 Safari/7534.48.3'


  #LOGIN
  wget -q \
         --user-agent="$ua" \
         --load-cookies="$cookie" \
         --save-cookies="$cookie" \
         --post-data="key=${HATENA_ID}&password=${PASS}&mode=enter&backurl=http://anond.hatelabo.jp/&autologin=1" \
         "${LOGIN_URL}" \
         -O - > /dev/null
  echo "LOGIN END."
  while :
  do
  article_list=(`
      wget -q \
      --load-cookies="$cookie" \
      --save-cookies="$cookie" \
      "$URL" \
      -O - |egrep -o "edit\?id=[0-9]+"|egrep -o "[0-9]+"`)
  if [ 0 -eq ${#article_list[*]} ]
  then
  break
  fi
  for article_id in "${article_list[@]}"
  do
  src=`wget -q -O - \
      --load-cookies="$cookie" \
      --save-cookies="$cookie" \
      "${URL}/edit?id=${article_id}" `
  csrf=`\
       echo "$src"|egrep -o 'name="rkm"[^/]+'|\
       egrep -o "value=.+"|egrep -o '".+"'|\
       egrep -o '[^"]+'`
  wget -q -O - \
         --load-cookies="$cookie" \
         --save-cookies="$cookie" \
         "${URL}/edit" \
         --post-data="rkm=${csrf}&mode=confirm&id=${article_id}&delete=%8d%ed%8f%9c%82%b7%82%e9" > /dev/null
  echo "DELETE ARTICLE_ID=${article_id}"
  done
  done
  echo "DELETE COMPLETE!"

3.作成したスクリプトファイルを実行します。

./masuda_delete.sh

時間はかかるけど、今までに書いた増田の全部の記事を削除しに行くよ!

いかがでしょうか?

自分過去をすすぎ落とすことによって、新たな人生が歩めるような気がしてきたんじゃないでしょうか?

それでは、これからも良い増田ライフを!

さあ、使ってみてくれ。

http://anond.hatelabo.jp/20130927131033

てか、はてダスーパーpre記法がことごとく使えないのは何とかならんですかね……

追記

ソース中の&は半角の&に置換しないと動きませぬ……

増田システム勝手に置換してるせいです。もうしわけない……

2013-03-03

RailsとTwitterBootstrapでエロ動画ソーシャルブックマークWebサービス作った

Rails + Twitter bootstrapでエロ動画ソーシャルブックマークWebサービスソーシャルオナニー=ソシャニーを作りました


こちらです http://www.socianie.com


【なにこれ?】

かっこつけた言い方をすると、

「いっぱいエロ動画あるけど結局みんなどんなお宝動画で抜いてるの?という日常的な疑問への答え」

とかでしょうか。

実際どんな事が出来るサービスかというと、基本的には、はてなブックマークのようにエロいページをブックマークする(その時に、コメントを付記することができる)というものです。

サイト内の他のユーザーフォローすることができ、TwitterのようにTimelineのようなものがあってそこにフォローしている人がブックマークしたページが表示されます(そのページが、xvideos,fc2などの有名サイトならば埋め込みプレーヤーですぐ再生出来ます。)

まりフォローしてる人の最新お気に入りエロ動画がチェックできます

ブックマークされたページはそれぞれが固有のページを持っており、タグを付ける事ができます

ユーザーブックマークしたもの動画一覧で横断的に見ることができ、並び替え・検索などが出来ます

ブックマーク数で今日ランキング今週のランキングなどが見れます

あと、累計ブックマーク数によってユーザーランクが上がったりします。

TwitterOAuth認証ログインが出来ますTwitterツイート投稿などはしません。また、サイト内の名前アイコンTwitterのものを流用するかどうかも自分で決められます。)



他のエロサイトとの違いは、3つあると思っています

ソーシャル機能。他にも世の中に色々素晴らしいエロサイトがありますがそれらはソーシャル機能を持つものが少ない。

②上記の話とちょっと被ってますが、他のサイトは基本コンテンツ自体を自動クローリングするけれどソシャニーはそこをユーザー自身に委譲しているため、集まってくる動画の質はそれに比べて上がるんじゃないかというのと、

エロサイトありがちな出来るだけごちゃっと感を無く広告も無しでTwitter bootstrap使って小綺麗な感じ


作成後記】

Webサービス作るならRailsかな楽で便利らしいしというざっくりとしたイメージからRailsで作り始めましたが、

ネット情報入門書に取り組んでもサンプルと同じモノは作れても実際自分が作りたいモノになると、で、どうやるの?となりなかなか進みませんでした。

Railsは色々と勝手によろしくやってくれる機能が多すぎて実際何が起きてんの?というのがわかりづらいというのが第一印象でした。

色々試行錯誤した結果、一番参考になったのはRails tutorial( http://ruby.railstutorial.org/ruby-on-rails-tutorial-book )でした。

英語ですがバージョンは新しいしBootstrapの使い方もわかるしサンプルがTwitterクローンサービスを作ろうというなかなかおもしろものなので途中で飽きること無く取り組めました。

何かを学ぶ時は、モチベーションが続く形の学び方が一番いいと思いました。

僕はエロ動画が大好きなので、エロサイトというのもモチベーションの1つです(ただ、作業中に脱線して気づいたらキーボードではなく下半身に手が伸びているという事もありました。)

また、上記のチュートリアルテスト駆動開発なのでSpecテストをモリモリ書いているのですが、とりあえずはテストに関しては何をやってるのかざっと眺める程度で精読しませんでした。

まずは全体像を把握して何が必要か把握したかたからです。結果的に最後までやりきれたので良かったと思います



あとは、Rails固有の知識ではなくWebサービス全般の知識で足りないな、と思ったときネット上や本屋立ち読みで済ましました。

ネットで細切れにお勉強している場合本屋で体系的にまとまっている本をざっと読むと意外に抜けてる知識が保管されたり脳内インデックスが作れるのでいいと思いました。


バージョン管理gitを使いました。

理由はみんなが良い良いというので乗っておくかという安易なものです。

実際のところgitの良い所を使い倒せているのかというと全くそんな事ないですね。

せいぜいstash位でしょうか。あとbisectとか。


リポジトリ最初DropBoxに作ってたのですが、途中からBitbucketを使いました。

GitHubを使わなかった理由はBitbucketプライベートリポジトリ無料で持てるからです。

また、恥ずかしがり屋なのでGithubで公開は敷居が高いと感じたからです。

初のRailsプロジェクトというのもありソースがイケてないので恥ずかしいのです。

いつかイケメンコードGithubで公開してオレツエーしたいものです。


サーバーエロOKのところを探すのがなかなか難しく結局海外VPSを使いました。

Linodeというところですが、他との違いを挙げるとiPhoneアプリ経由で再起動などが出来たりします。あまりこの機能使ってないですが。

OSベタCentOSです。

構成はpassenger+apacheで、DBSQLite特にLBなどはないです。

諸々構築後に人気が出た時困らないように負荷分散のお勉強なんぞもやりかけましたがまずは不要かなということで辞めました。

ちなみにサーバーがUS西海岸なのでSSHで作業するとエディタちょっともっさりすることがありました。


プロジェクト管理は、会社でも使ってるのでRedmineかなと思ったのですがどうせ一人だしRedmineのUIきじゃないのでTrello( https://trello.com/ )を使いました。

TODO,Doing,Done,Bug,Suspendのリストを作ってやること忘れないように管理しました。

ふと出先で思いついた機能とかをiPhoneでスイっと追加など出来て便利でした。


正月に公開してお友達界隈で見てもらったんですが、よかれと思って作ったChrome拡張CSRFの対策が不備あり結局ブックマークレットにしたり、

ソースを見てもらったら設計RestfulじゃないとかControllerがfat過ぎるModelに押しこめなどアドバイスをもらえたり無知な僕には色々とお勉強になりました。

出来たものはしょぼいものですが、「Webサービス作ったことないコンプ」は少し解消出来た気がします。


以上、月19ドルも払ってるのにお友達だけで使われてるのも寂しいので増田でまとめついでに宣伝してみました。

叩かれるんでしょうか。怖いです。いじめないで。

2013-01-18

素人が完全自作SNSを二週間運営してみてわかったこと(後始末編、技術編、モチベーション編)


素人が完全自作SNSを作ってみてわかったこと。

http://anond.hatelabo.jp/20130104184115

元増田です。

ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、

まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。

素人のフリをしているとか、出版社ステマだとか色々言われましたが、嘘は一切書いてないです。

ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスステマしかなっていないような気がします…。

公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。



増田記事を公開してから今までの経過~

・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。

             ⇓

・以前、完全に一致を作った増田の方が、増田記事を書いてからアクセスが急に来たと書いてあったので真似して書いてみる。

             ⇓

・翌日ごろからアクセスが集中。ビビる。「うちの会社で働きませんか?」と言ったお誘いのメールをたくさん頂く。

いきなりの出来事にパニックになっている間にも増田記事が拡散していき、アクセスが急増する。

             

             ⇓

アクセスが爆発する。1時間あたり二万アクセスというアクセスを捌ききれずにサーバーが落ちる。サイトのウリであるが、メモリ使用量

が最も高いマッチングチャットを一時使用停止にする。

             

             ⇓

・その後、サーバーを増強。エラー情報や、寄せて頂いた情報をもとに各種エラー情報や、使い勝手などを改善

             

             ⇓

現在、安定稼働中。おかげさまで、ユーザー数もゆるやかに増加していて、基本的な機能も正常動作していますユーザー数はもうすぐ

1000人に届きそうでありがたいばかりです。


と、いうわけでなんとかようやく落ち着き、ウリのマッチングチャットも正常に作動しているようなので、後記事を書きます





~後始末編(Webサービスを実際に運用してみて)~

ウェブサービスの公開前に注意すべきだったこと。

①・セキュリティについては書かないほうが良い。色々といじられる。

前回の増田記事で、DoS攻撃の対策などについて語ったのですが、それを確かめるためなのかサイト公開してしばらくしてから、定期的に

Dos攻撃をくらいました。

おかげ様で、ちゃんと一時的にそのIPからアクセス遮断することはできたのですが、セキュリティについてあまり大々的しゃべると攻

撃対象となるので、あまり具体的なセキュリティ対策などについてはしゃべらないほうが良いのかな、と感じました。

また、DoS攻撃だけでなくCSRF試したり、色々といたずら(もしくは善意テスト?)をして下さる方がとても多かったのには驚きました。

はてな民技術レベルの高さを知りました……。いたずらされている間は本当に怖かったです。

とりあえず、今のところ攻撃は防げているようです。



②・作者のオナニーユーザー様をつきあわせてはいけない。

はじめ、私は調子に乗ってサイト内に英語を多用していたのですが、それがユーザー様にとって混乱のもとになっていたようです。

例えば、他のユーザーから自分の書いた日記などにコメントがついた時に、それを知らせるページがあります

普通に考えれば「友達からの反応一覧」とか「友人からの反応」とかにすれば良いのですが、何を血迷ったのか「Reaction」と中二病丸出

しで書いてしまったので、ユーザー様がものすごく混乱したようです。

結局、「使いにくい」、「サイト迷子になる」との声を受けて日本語メニューに変更しました。




③・使い方のページはくどいくらい書いても良かった。


フリーチャットや、マッチングチャットでは、基本的に相手が見つかるまでは「待ち」の状態になります

相手がすでにこちらを「待っている」状態だとすぐにチャットが始まるのですが、そのことに対する説明が足りなかったようで、チャット

ルームを出たり入ったりしている人が多かったようです。

また、チャットが終了した時にチャット相手にお礼をこめてメッセージを送る機能があるのですが、これも説明不足で上手く使われなかっ

たようです。


とにかく、くどいくらい説明しても良かったと思います









ウェブサービスリリースする前にやっておいて良かったこと。

①・Twitterアカウントを作りそこから最新情報を流せるようにする。

 これは本当に大きかったです。

 とつぜんの増田砲で一時間あたり二万アクセス近くのアクセスをさばけずに、サーバーがビジー状態になってしまった時も、Twitterを通

じて現在の状況などを流せたことは非常に大きかったです。





②・エラー情報を送ってもらえるようにメールアドレスを作っておく。

 本当にありがたいことに、実際に使ってみた使用感や、こんなエラーが出ていると言った情報を送って下さる方がいます

 一人でテストしていた時には気づかなかったエラーや、不便な点などをわざわざ時間をとってメールで教えてくれるのです。

どこの馬の骨ともわからん怪しい奴が作ったものに登録してくれ、使ってみてくれただけではなく、エラー情報や励ましの言葉を送って下

さるのです。

本当にありがたいことです。



③・それでもわからないエラー情報に対して対処できるようにしておく。

 優しいユーザーの方がエラー情報などを教えて下さるのは大変ありがたく、また開発の励みにもなるのですが、それに頼ってばかりいて

ダメです。

 サーバーの吐き出すエラー情報を調べて、おかし挙動にいち早く気づく必要があります

本当はhttpdエラーログとか見れば良いんですけど、はっきり言って物凄く見づらいので、ツールを使って毎日「こんなエラーがでました

」と教えてもらうようにしておきました。

色々なツールがあるみたいですが、私はlogwatchを使いました。

・参考URL

http://www.atmarkit.co.jp/flinux/rensai/root04/root04c.html

これでエラーの出ているところだけでも、修正するということをやっていました。


■ ウェブサービスを運営してみてわかったこと。

①・SNSの人の流れにはなんだかよくわからない規則性がある。

tag-chat.net グーグルアナリティクスでどれくらいの人が毎日来ているかをウォッチしているのですが、なぜか月曜日と週末にかけてア

クセスが増えます

謎です。週末はわかるけれど、どうして月曜日に……?



②・やっぱり非リアの気持ちは非リアじゃないとわからない。

前回の増田記事に対するコメントネットの反応などで、

「どうして普通にはてブに書かないのか。なんで増田なのか」とか「非リアを装って」

とかコメントしてる人たちがいたのですが、その人たちは非リアについてなんもわかってないアホだと思いました。


もともと自分名前なり、アカウントを明かした上ではてブ投稿できるくらいの度胸があれば非リアになんかなってないです。それは自

分でもわかってます

自己顕示欲人一倍強いくせに、人に名指しで批判されるのが怖いか増田投稿したのです。



フェイスブック実名ウェブサービス作ったことを投稿できるような度胸があればそうしてますし、はてブに書けるなら書いてます

そうするだけの度胸もなくて、でも誰かに認めては貰いたいか増田に書いたということをわかっていない。


③・ネットのみなさんが優しい。

 今までネットの人たちは2ちゃんねるとかで炎上したり、なんか面白そうなものを見つけてお祭り騒ぎする、ちょっと怖い人たちという

イメージだったのですが、それが今回のことでガラリと変わりました。

 本当に優しい人が多くて、どこの馬の骨ともわからない奴の作ったウェブサービスを使ってくれるだけでなく、感想や励ましのメール

どをたくさん頂きました。

 遥か雲の上の存在だと思っていた会社の方からメールなどを頂きました。本当に感謝してもしきれません。

 





技術編~

Tagchatの技術的なこと。

①・nodejsを使って外部にサービス公開するなら、認証必須。主に不正な負荷を減らすために。


さっき書いた、「セキュリティについてはあまり書くな」という話と矛盾するのですが。

nodejsでのセキュリティの話です。

nodejs、すごくアクセスさばけて、なおかつ軽いということで便利なんですが、サーバーなので、基本的にリクエストを受けたら非常に素

直に返事します。

例えば、nodejsとsocket.ioを使って、単純にメッセージサーバーに送るとして、クライアント側で

socket.emit('hoge','hoge');

のようにすると、サーバーはどこから来たアクセスなのか、とか悪意のあるアクセスなのか? とか一切気にすることなく、素直に'hoge'

というメッセージを受けます

これはつまり、第三者が悪意を持って大量にメッセージを送りつけるとそれを素直に受け取ってしまうということです。

なので、例えば大量に不正データを送りつけられたりするとレスポンスが悪くなります

なので、悪意のあるアクセスはsocketにそもそも接続させない、という対策がサーバー側で必要になると思います

socket.ioではコールバックを使って、簡単に認証させるかさせないか、という実装ができます。具体的には以下のURLなどを参考に実装す

ればいいかと思います

http://d.hatena.ne.jp/Jxck/20110809/1312847290



②・nodejsの最大接続数は、ファイルディスクリプタ依存する

ということにしばらく気づかずに、最大接続数が400ほどしか出ず悩んでいた時に以下のURLを参照して、なぞが解けました。

http://blog.livedoor.jp/mokepon/archives/182178.html

 またsocket.ioのテストの書き方ですが、

http://d.hatena.ne.jp/toritori0318/20120902/1346591831

という素晴らしいエントリーがあったので参考にさせて頂きました。


■楽できるところは楽するためのツールなど。

nodejsの開発で、面倒くさいところはできるだけ楽しました。以下、便利だったものまとめ。


・node-dev

コンソールにデバッグ情報を吐き出してくれ、サーバー側のコードをいじくった時に自動的に再起動してくれる。

いちいちコマンドプロンプトからnodejsを実行する必要がないため、作業の手間がはぶける。

nodejsを触り始めた時はエラーを吐いてばかりなので非常に役に立ちました。

参考URL

http://d.hatena.ne.jp/replication/20110224/1298474534


・forever

nodeのプロセスデーモン化してくれる便利ツール。

様々な使い方があるようですが、stop,list,startの3つぐらいしか使いませんでした。まだ、研究中です。

参考URL(基本的な使いかたが非常にわかやすく書かれています

http://nantekottai.com/2011/08/15/node-js-based-service-with-forever/


・mongoose

nodejsからmongoDBを扱うのに最適。

ドキュメントは色々ググったのですが、結局公式のドキュメントが1番わかりやすかったです。

http://mongoosejs.com/







モチベーション編~

■一人でウェブサービスを作る上で、心の支えになった記事。

はまちちゃんさんの、「セキュリティ過敏症の話」。

http://d.hatena.ne.jp/Hamachiya2/20080131/security

とにかく楽しんで、作ってみることが大事だよ、というお話です。すごい勇気づけられます


小飼弾さんの産声の話。

http://blog.livedoor.jp/dankogai/archives/51837985.html

弾さんは、お金持ちで、腕は一流で、PHPこき下ろすし、なんかすごく怖い職人イメージだったのですが、このエントリーを読んで、クソ

まみれでも産声を上げてみようと思えました。

実は優しい人なのかもしれません。私の高校時代担任先生にどことなく似ています

 





■お詫びと訂正

前回の増田記事で、OpenPNEについて間違った記載をしてしまいました。ソースコード公開に関する記述の部分です。

OpenPNEではそのソースコードを改変したら、そのソースコードを公開しなくてはならないと書いたのですが、これは間違いです。

OpenPNE方々には大変ご迷惑をお掛けしました。申し訳ありませんでした。




あと入家さんに謝りたいです。

勘違いサブカル野郎とか言ってすいませんでした。

フェイスブックにもとりあげて頂いたそうで、ありがとうございます

怖いのでどんな投稿なのかはまだ観ていませんが、本当にありがたいです。







最後に。

ウェブサービスをコツコツと作り続けて公開したところ、増田記事のおかげもありたくさんの反響を頂きました。


ただ、別にウェブサービスを公開したからと言って、実際のところ何かが劇的に変わったわけでもないです。


グーグルアドセンスは支払い規定の一万円を超えていないので、手元には一銭も入ってきませんし、実名出して行動できなかったので現実

ではほとんど反響はなかったです。

あいかわらず休日地元ゲームセンターレトロゲーをやって時間をつぶしていますし、学校から帰ってきたらももクロライブを観て

Chai Maxxを踊ってから寝るだけの毎日です。それでも結構楽しいのですが。

ただ、ネット上で様々な先輩エンジニアの方々や、同年代で同じようにフェイスブックが嫌いな方から励ましのメールをもらいましたし、

本当に、びっくりするような充実した二週間でした。

はてブで人気のエントリーにあがった時のスナップショットは未だに大事にとってあります

tag-chat.nethttp://tag-chat.net)を作って本当に良かったと思っています

2011-01-01

ひまわり動画って使ってるか?ログインに気をつけろよ

どっかの動画投稿サイト動画ソースをそのまま利用して、コメントつけられるようにしたニコニコの3番煎じぐらいのひまわり動画って知ってる人いる?

なんだかIDつくってログインできるらしいんだけど、そのなんだ…

IDパスワードが平文でCookieに保存されているの気づいてたか

http://himado.in/

しかも、登録時にはメールアドレス登録しなくてもいいんだぜ?

でも、パスワード忘れたときのためにってパスワードリマインドの機能があるんだが

http://himado.in/?mode=forgetname

こえー、マジこえー。

まぁ、いいんだけど。

どうせ、適当IDパスワードにしてるだろ、もちろん。

え?他のサイトと同じにしてる?

いやいや、そんなに信用しちゃっていいの?

XSSCSRF漏えいとか以前に、自分IDパスワードを他のサイト入力されてるかもしれないぞ!

こえー、マジこえー。

なにが言いたいかというと

パスワードの使いまわしはあぶないぞ!

という、お話した

あ、あけましておめでとうございます

2009-12-14

かんちょー

学内Webメールシステムが、もろにCSRFXSSのよわよわのシステムでした。NEC系のメーカーASPだったようだけど。

WebメールXSSCSRFがあるというのは本当に最悪で、「開いただけでメールボックスアドレス帳が全部どこかに送信されてしまう」ような攻撃メールが作れてしまうことを意味します。

で、担当部門がどこだかわからないのでメディアネットワークセンターというそれっぽい部署に教えてあげたんだけど、とにかく反応が遅い。対策の第一段階は即日システム停止することですよ、とまで書いてあげたのに。

2ヶ月たって何も修正がされないので、研究室内のゼミで発表してみました。情報系でも、知らない人はCSRFとか全然知らないからね、うちアルゴリズム系なのでみんな「Webってこんな攻撃ができるのか」って感心。教授はあわててどこかに電話

そしたらすぐに、「どこがそんなにまずいのか」と相談の電話が折り返されてきて、(即時停止レベルだって教えたじゃん)と思いつつも、「このメールを開いた後、自分の送信箱を見てご覧なさい。見覚えのないメールが送信されていませんか?」と攻撃例を教えてあげました。寸止めかんちょー。

これで即時停止だろうと思ったら、結局それから4ヶ月間修正が入らないまま運営が継続、そして「これで直りましたよね」と連絡が来たのでテスト環境版を試してみると、この「修正版」は script タグを無効にするだけで onload とかまったく手を付けないザル修正でした。

それを指摘したらしぶしぶイベントリガ系も消してくれたけど、CSSXSSとか不完全Shift-JIS文字とかexpressionとか知りもしないんだろうなー。セキュリティのこと知らないなら、HTMLメール扱う機能ごとばっさり削除が唯一の正解です。

本気でかんちょーしようと思えば簡単でした。自己増殖メールを誰かにぽんと送るだけでたぶん3日以内にメールシステム麻痺して、実質停止に追い込めたはず。あ、それじゃかんちょーどころか直腸裂傷か。でも、それで全員のクオータがあふれてしまえば真に悪意のある攻撃メールを受信する余地なくなるし、セキュリティ保護できたことにならないかな。

で、本当にそれをしなかった理由はひとつだけ、攻撃テストメール自分に送りまくっていたことがメールログに絶対残っているし、それで犯人とばれて退学とかいやだったから。うちの大学中退じゃなきゃハクがつかないんです。

2009-08-03

インターネット常時接続なのに、セッション管理とはこれ如何に!?

おい、kawango!一般人にも感じがつかめるようにセッション管理について教えてやる

 

一般の人にとって一番わかりにくいのが

ということ。

「えー、うちのインターネット常時接続だよ?」とかいう奴は蓬莱弾幕でも食らっていやがれ。

 

インターネット接続方法を例え話にすると

となる。接続状態(太郎くんのお家にお邪魔している状態)というものは存在しない。とにかく毎回毎回、「ピンポーン」とやって、いちいち要件を伝えないといけない。ちなみに執事はいつも受動的。言われたことしかしない。

 

さて、もうちょっと高度に

ことも出来る。

好きな人はさすがに一部の友達にしか伝えられないので、山田家の執事は決められたルールに従って、「太郎の様子は万人に伝えても良いが、太郎の好きな人はマブダチにしか伝えてはならない」といった篩い分けをする必要がある。今僕らが話題にしたい「認証」の問題だ。

もちろん人間執事なら、一度覚えれば、誰がマブダチで誰がそうでないかはわかるわけだが、現実Webサーバー杓子定規なので、毎回毎回「名前ユーザー名)と合言葉パスワード)」を聞いて、本当にマブダチかどうかを確認する。

マブダチA:「太郎君の好きな人って誰? 僕は《マブダチA》、合言葉は《おニャン子》だよ」

執事:「初音ミクです」

マブダチA:「その前は誰だったの?」

執事:「お名前と合言葉をどうぞ」

マブダチA:「その前は誰だったの? 僕は《マブダチA》、合言葉は《おニャン子》だよ」

執事:「アララ・ミルクです」

という面倒な方法をとらないといけない。

 

要するにページを移動するたびに(ひとつまえの好きな人を聞くたびに)、認証(マブダチ確認)を行う必要がある。

それはめんどくさいから、ある一定期間の間は特殊な記号を使って、認証を楽に済ませましょうというのが、HTTPにおけるセッション管理だ。

さっきの例え話でいくと、

山田家の執事がマブダチAの手間を考えて「毎回お名前と合言葉を言ってもらうのも面倒ですから、このバッジセッションID)をお渡ししますので胸に付けてください(クッキーに保存)。それを見ればわかりますから。但し、最後のお問合せから30分以上すぎたらお名前と合言葉をもう一度言ってもらいます(セッションIDの有効期限)。そのときはまた新しいバッジをあげます」となる。

大事なことは、このバッジが一時的にしか使われないものということだ。どのくらいの期限を有効とするかはその家族で決めたルールによる。いずれにせよ、バッジがあれば完全スルーであるので気をつける必要がある。

 

要するにセッション管理を利用することで、実はマブダチじゃない人にマブダチを騙られるリスクが増すんだ。

毎回毎回、ユーザー名とパスワードを答えるのは面倒だから、バッジでよろしくね!ってなったら、バッジジャイアンに奪われたり、スネ夫盗み見られたり、出来杉君に気付かないうちに誘導させられたりというリスクが出てきてしまう。それを心配しないといけないんだ。

 

ここで、もしだよ、マブダチAが、世界自分だけが持っている変更不可能な情報バッジの代わりに使ったとしよう。例えばDNAだ。

執事DNAでマブダチかどうかを判断する。簡単ログインのためにあなたはDNA情報を提供しますか?となる。山田さんの家も、佐藤さんの家も、田中さんの家もDNA情報ひとつで認証を済んでしまうような社会だ。しかもマブダチAを表すDNAはひとつしかない。よって、このDNAを1つコピーするだけでマブダチAになりすませる。hatenamixiもNaviTimeもDNA認証を使っているサービスは全部だ。もちろん、このDNA認証を一般のセッション管理と同じように有効期限を設定して、その都度破棄することもできるが……。それはあくまで、善意執事の場合であって……。DNA情報と本人の個人情報マッチングして裏でほくそえむ黒執事がいたら……ざわっざわざわ……。

しかも、DNA情報暗号化せずによこせと言ってる奴もいるッ!な……何を言ってるのかわからねーと思うが、おれも何が目的なのかわからねえ……。オレオレ詐欺だとか、クレジットマスターだとか、そんなチャチなもんじゃねえ……。DNA情報ばら撒きというもっと恐ろしいものの片鱗を味わったぜ……。

 

わかったか、kawango!

ニコニコ技術者が即対応したからよかったんだぞ!

っていうか、指摘されるまで気が付かないという業界は恐ろしいぞ。業界ぐるみDNA情報を集めて利用しようって魂胆か?

2009-07-14

可能性

twitterタイムラインから流れる都議会選の開票速報を横目に見ながら、時代錯誤な厚みと正方形に近い形状のブラウン管に映る政治家の無表情を装う苦しい顔を見つめると耳に入ってくる電車の音、ほのかな潮の香り、まとわり付くような湿った生暖かい空気を感じるとき、はてな民は自分のたるんだ白い腕が震えていることに気づき、その震えがクーラーもないような部屋や隣の住民が迷惑を省みない音量でサンボマスターカヴァーした「あの鐘を鳴らすのはあなた」をヘビーローテーションしていることによるものではまったくないことを知る……。

 

はてな民はなにができるだろうか? 注目エントリー一覧から2chまとめブログの記事を探してきて読みふけること? アイマス動画マイリストに叩き込んでいくこと? 自分のpostがさまざまなめりっとで取り上げられていないか定期的にチェックすること? ドラえもん釘宮理恵ゲスト声優で出演したときに「くぎゅううううう」って叫ぶこと? はてなブックマークが付くことを期待して、アルファブロガーの記事を思いっきDisる記事を書くこと? サブアカウントプライベートモードで作ってエロサイトブックマークしていくこと? はてサヲチスレに張り付いて特定個人を攻撃し続けること? 匿名ダイアリで「id:y_arim です。この前、美容室にいったんだけです。美容室。そしたらなんかもうヱヴァの話でいっぱいなんです。」と騙ること? 「リンクは許諾制です」という個人のファンサイトブックマークして晒し者にすること? ブックマークブックマークを重ねて、さらにブックマークを重ねて「馬鹿と煙は高いところに登る」とか書かれているコメントを一瞥だにせず、さらにブックマークを重ねること? ライフハック記事をブックマークして、「あとで読むタグをつけて、あとで読まないこと? 上から目線の非現実的なブコメはてなスターを連打すること? テレビを見ながら今までにやったことのないやり方でタダごとではない旨さのトマトソースを作ってしまうこと? ヨーロッパ旅行に行く日に空港まで行ってから、パスポートを忘れてしまっていたことに気付くこと? はてなキーワードの「子育て」を含む日記を追いかけて、主婦層の生活を夢想すること? あるいは twitter's fotolife に張り付いてかわいい女の子写真を探すこと? 将棋オタク取締役崩れにガツンと一言かますこと? 児童ポルノ単純所持違法問題に口は出すが、金と労力は出さないこと? 自分炎上したら、プライベートモードに変更してアカウント削除して何食わぬ顔で3日後にはてなに戻ってくること? 自分の書いた記事をプリントアウトして精神科に持って行くこと? 新サービスの開始と同時に XSS 脆弱性をついて遊ぶこと? あるいは CSRF のトラップを仕掛けること? 一旦ログアウトして、コメント欄通りすがりざまに袈裟切りすること? 「原作の「櫻の園」は、簡単に言うと女子高生同性愛を最大のテーマとしています」と書くこと? あるいは、ライトノベルに詳しくないのに「ゼロの使い魔」を「正統的なライトノベル」「非常にオーセンティックな、ライトノベルの鑑のような作品」と書くこと? iPhone を持って便座に座り、一本糞をひねり出すときの息みの勢いで 1get すること? その糞を流す前にプライベートアカウントに乗り換えて 2get して注目エントリー入りする素地を作ること? 流したらお尻を拭かずにパソコンで違うアカウントから 3get して注目エントリー入りさせること? id:finalvent の記事に100文字以内でクドクドとネガコメを書くこと? ネガコメを書きながら Air のトゥルーエンドを鑑賞すること? 病床の子供ネガコメ約束すること? あるいはたんにネガコメをすること……。

だが、できることといえば「死ねばいいのにタグを付ける、ないしはたんにネガコメする。ネガコメする。ネガコメするのはきもちいい。ネガコメするのはいい。ネガコメはいい。あまったるくネガコメする。ねこのあたまをなでるようにネガコメする。きぬのようになめらかにネガコメする。めをとじてネガコメする。うたいながらネガコメする。きもちよくネガコメする。ブックマークきもちいい、ネガコメ、いい。やさしくネガコメする。どきどきしながらネガコメする。もえるようにネガコメする。かわいくネガコメする。さそうようにネガコメする。ネガタグ、めをほそめる、ほほがあがる、ネガコメ、あまったるい。ネガコメする。ネガコメにスターをつける。ネガコメにスター。へんなネガコメにスター。かわいくスター、へんな、ネガコメ、スター。ネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスター、へんな、ネガコメにスター。ネガコメにスターをつける。ネガコメにスター。ネガコメにスターネガコメにスターネガコメにスター、きもちいい、ネガコメにスターネガコメにスターネガコネコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスター、あまったるい、ネガコメにスターメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスターネガコメにスター。

2009-05-27

高木浩光さんの芸風

http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/Rockridge/20090504/1241415765

http://b.hatena.ne.jp/HiromitsuTakagi/20090505#bookmark-13284789

HiromitsuTakagi セキュリティ, 事件, Firefox, NoScript うわ、最悪。NoScriptはどうも嫌な感じがすると前から思ってたが、作者が信用ならないことが明るみに出た。こんなのを一般の人に推奨するJPCERT/CCとかおかしいだろと前から思ってる。(US CERTも推奨しているが。) 2009/05/05

http://b.hatena.ne.jp/entry/http://www.jumperz.net/texts/csrf.htm

http://b.hatena.ne.jp/HiromitsuTakagi/20090527#bookmark-1662791

HiromitsuTakagi セキュリティ, ニセ脆弱性, CSRF, 金床問題, bad ↓今もたくさん読まれているようだけど、根拠レスだらけの有害記事なので注意。当時沢山の指摘があったのにいまだに訂正していないのね。http://slashdot.jp/developers/comments.pl?threshold=-1&mode=thread&commentsort=0&sid=309361 2009/05/27

昔からそうなのかは検証してないが、後出しジャンケンで「俺は前から全く信用できないクソだってことを知ってたんだけどね(キリッ」と言ってくる芸風が目立ちつつあるな。

後者なんか既に公開から3年、自分の前に727人もぶくましてる状況になってからこれだし。

2008-07-27

Webアプリ脆弱性オタがふつーのSE彼女脆弱性世界を軽く紹介(ry

まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、

「オタではまったくないんだが、しか自分のオタ趣味を肯定的に黙認してくれて、

 その上で全く知らない脆弱性世界とはなんなのか、ちょっとだけ好奇心持ってる」

ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために

説明するべき10パターンを選んでみたいのだけれど。

(要は「脱オタクファッションガイド」の正反対版だな。彼女脆弱性布教するのではなく

 相互のコミュニケーションの入口として)

あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。

できれば、秋葉原とか筑波とかから突っ込みはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。

あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。

プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。

そういう感じ。

彼女の設定は

セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。

ひろみちゅとか、はまちちゃんてなんだろうという好奇心もある

サブカル度も低いが、頭はけっこう良い

という条件で。

まずは俺的に。出した順番は実質的には意味がない。

XSS

まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。

ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。

この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報彼女

伝えられるかということは、オタ側の「真のコミュニケーション能力」試験としてはいタスクだろうと思う。

MITM, DNS Rebinding

アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性(そうオタクが思い込んでいるだけ。実際は全然受け入れられない)」そのもの

という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには

一番よさそうな素材なんじゃないのかな。

Webアプリ専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう?」って。

パストラバーサル

侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを

彼女に紹介するという意味はいいなと思うのと、それに加えていかにもマニアック

「よく眼にするけどあまり実害の思いつかない」/etc/passwd

「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow

の2ファイルをはじめてとして、オタ好きのするファイル世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。

CSRF

たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。

そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性日本で大人気になったこと、

ひろみちゅがはまちを焦がしたのは事故か、わざとか?

なんかを非オタ彼女と話してみたいかな、という妄想的願望。

メールヘッダインジェクション

「やっぱりWebアプリ脆弱性個人情報DBなんかがあるサイトものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」

でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから

断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、

その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまから

ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが

Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。

なのに、安全APIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても

自分過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、

親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。

ディレクトリリスティング

今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。

SQLインジェクションよりも前の段階で、個人情報漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、

こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、

別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、

いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。

OSコマンドインジェクション

UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。

ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、

からこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。

「侵入先のコンピュータコードが動いてこそなんぼ」というクラッカー感覚今日さらに強まっているとするなら、その「クラッカーの気分」の

源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、

単純に楽しんでもらえるかどうかを見てみたい。

Hiddenフィールド改ざん

これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。

こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか

突っ込みを誘発するか、というのを見てみたい。

SQLインジェクション

9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。

XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と

なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。

というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら

教えてください。


「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。

こういう試みそのものに関する意見も聞けたら嬉しい。


Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本

2008-03-14

諸君 私は脆弱性が好きだ

諸君 私は脆弱性が好きだ

諸君 私は脆弱性が大好きだ

PHPが好きだ

XSSが好きだ

SQLインジェクションが好きだ

CSRFが好きだ

UTF-7が好きだ

expressionが好きだ

シェアウェア

Web

Google

スペシャルねこまんま

LiveHTTPで

Filemonで

Regmonで

OllyDbgで

Perl

この地上に存在するありとあらゆる脆弱性が大好きだ

セキュリティに関して口うるさく言っているサイト脆弱性をいとも簡単に見つけるのが好きだ

大企業サイトGoogleによって脆弱性発見された時など心が踊る

Googleがあっけなく脆弱性を見つけてしまうのが好きだ

Perl馬鹿にしていた奴のアカウントを乗っ取った時など胸がすくような気持ちだった

粘り強い同業者MS Officeシリアル認証と格闘している様が好きだ

PHP覚えたての野郎共が続々と脆弱性を作り出していく様など感動すら覚える

気に入らない奴のPCトロイの木馬を忍ばせ奴の個人情報Winnyネットワークに流れてゆく様などはもうたまらない

精魂込めて更新していたであろうWikiを滅茶苦茶にするのが好きだ

必死に守るはずだった同業者が次々に逮捕されてゆく様はとてもとても悲しいものだ

FBIに追いまわされ泥棒の様に捕まる恐怖と戦うのは屈辱の極みだった

諸君 私は攻撃を地獄の様な攻撃を望んでいる

諸君 私に付き従うクラッカー諸君

君達は一体何を望んでいる?

更なる攻撃を望むか?

情け容赦のない糞の様な攻撃を望むか?

鉄風雷火の限りを尽くし三千世界の鴉を殺す嵐の様な政府との闘争を望むか?

『攻撃! 攻撃! 攻撃!』

よろしい ならば攻撃だ

我々は渾身の力をこめて今まさに振り降ろさんとする握り拳だ

だがこの暗い闇の底で半世紀もの間堪え続けてきた我々にただの攻撃ではもはや足りない!!

大攻撃を!!

一心不乱の大攻撃を!!

我々はわずかに小数

セキュリティ専門家に比べれば物の数ではない

だが諸君は一騎当千クラッカーだと私は信じている

ならば我らは諸君と私で総兵力100万と1人の集団となる

我らを忘却の彼方へと追いやり、眠りこけている奴らを叩きのめそう

髪の毛をつかんで引きずり下ろし 我々の方が強いことを眼(まなこ)をあけて思い出させよう

連中に恐怖の味を思い出させてやる

連中に進入される恐怖に怯えながら眠る夜を過ごさせてやる

連中に我々の技術を思い知らせてやる

天と地のはざまには奴らの哲学では思いもよらない事があることを思い出させてやる

一千人の吸血鬼クラッカー達で

世界を恐怖に陥れてやる

目標 情報処理推進機構!!

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん