  |
はてなキーワード: クォートとは
近頃人気ですね。一時期のGREE・モバゲーバッシングはどこへやら。
と言う話はさておいて、今までソーシャルゲームとは縁の無かった方々がプレイしている影響か、
このゲームにやたらと夢を抱いている人が多いようです。
特に、『アニメ化されないか』『アイマス新作に誰か出演しないか』等のメディア展開に関係するものや、
『新イベントの提案』『全体的な動作改善』『ゲームバランスの変更』等のゲームそのものに対する要望が目立ちます。
断言しておくと、動作改善がやや望みある程度で、他は「ありえない」ですね。
理由は下記。
・KONAMIの戦国コレクションがアニメ化と言う前例がありますが、
あれはKONAMIが自社で製作しているゲームだから実現できた話です
よって、新作への出演も無理
知っての通りモゲマスは、既存ゲーム（神撃のバハムート→戦国サーガ→モゲマス）の
モゲマス独自の要素（親愛度）もありますが、バグの温床となっています
（しかもそのバグ修正の方法が非常に稚拙かついい加減だったことは記憶に新しいですね、
（ダブルクォートがあったりなかったり、スラッシュで閉じていたり閉じていなかったり）
パーサに掛けたらエラー連発でしょうね
既存ゲームの挿げ替えであるがゆえに、上記2つのゲームの同じ箇所で誤字脱字が存在しています
気付いていないのか、直す気がないのか…
・モゲマスに限った話ではありませんが、
この手のゲームは『人よりお金を多くかけた人』が俺TUEEEEを実現出来ないと成り立ちません
人よりお金を払わない・そもそも一銭も落としていない人に対する運営の優先度は極端に低いです
だからこそSRカードの性能は壊れていますし、今後もっと壊れていきます
これらを理解した上でプレイしたり数万円つぎ込むのは、別段問題があるとは思いません。
RubyでうどんげQuine(とAA型Quineの作り方講座)
perl - Quine.pm で(ほぼ)あらゆるPerl Scriptをquineに
Ruby、Perlと来たら、次はもうPHPしかないでしょう。
そもそもQuineとは何か？Wikipedia先生にご登場願いましょう。
コンピュータプログラムにおけるメタプログラミングの一形態であり、自身の完全なソースコードだけを出力するプログラムである。
なるほど。
くくく。実はこの分野であればRubyやPerlなんぞ足元にも及ばない。
PHPはまさしく最強なのだ
a
なんと一文字！
$ php quine.php > q.php $ diff quine.php q.php
自身の完全なソースコードだけを出力するプログラム、ここに極まり！！！！！さすが天下のPHPだ！
汚い言語仕様や、高度なテクニックなど、必要ない！過程や方法なぞどうでも良いのだ！
・・・・・・・・・・・・さて、そろそろ本題に入ろう。
上記のPHPの出力機能を使わずにQuineプログラミングするにはどうするか？
Rubyは文字列の変数展開をしないし、Perlには文字列クォート記号を別の文字に指定することができるのでなんら問題なくQuineを実現できるが、PHPにはそのような機能がないので思ったよりも苦戦した。
<?php function a(){return'print"<?php function a(){return".var_export(a(),1).";}eval(a());";';}eval(a());
仕方なく関数の戻り値とすることで文字列変数展開を避けた。これ以外良い方法が思い浮かばない。ヒアドキュメントでなんとか出来ないかと思ったのだが、変数を展開しないNowdocという機能が、PHP5.3だったのでとりあえずパスした。それにそもそも関数を使うよりもコード量が減るのか甚だ疑問であり、結局この形に落ち着いたわけなのだ！
おわり。
まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らない脆弱性の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために
（要は「脱オタクファッションガイド」の正反対版だな。彼女に脆弱性を布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。
できれば、秋葉原とか筑波とかから突っ込みがはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。
あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。
プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。
サブカル度も低いが、頭はけっこう良い
という条件で。
まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタのバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのもの
という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには
一番よさそうな素材なんじゃないのかな。
「Webアプリの専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう？」って。
侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにもマニアックな
「よく眼にするけどあまり実害の思いつかない」/etc/passwd
「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow
の2ファイルをはじめてとして、オタ好きのするファイルを世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。
たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性が日本で大人気になったこと、
「やっぱりWebアプリの脆弱性は個人情報DBなんかがあるサイトのものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」
でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから。
断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、
その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまうから。
ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが
Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。
なのに、安全なAPIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても
「自分の過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、
親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。
今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。
SQLインジェクションよりも前の段階で、個人情報の漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、
こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、
いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。
UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。
「ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、
だからこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。
「侵入先のコンピュータでコードが動いてこそなんぼ」というクラッカーの感覚が今日さらに強まっているとするなら、その「クラッカーの気分」の
源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。
こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか
突っ込みを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。
XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と
なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本
