「クォート」を含む日記 RSS

はてなキーワード: クォートとは

2012-01-25

モゲマスに夢を抱いている方々へ

アイドルマスター シンデレラガールズ 通称モゲマス

 

近頃人気ですね。一時期のGREEモバゲーバッシングはどこへやら。

 

と言う話はさておいて、今までソーシャルゲームとは縁の無かった方々がプレイしている影響か、

このゲームにやたらと夢を抱いている人が多いようです。

特に、『アニメ化されないか』『アイマス新作に誰か出演しないか』等のメディア展開に関係するものや、

『新イベントの提案』『全体的な動作改善』『ゲームバランスの変更』等のゲームそのものに対する要望が目立ちます

 

断言しておくと、動作改善がやや望みある程度で、他は「ありえない」ですね。

理由は下記。

 ・KONAMI戦国コレクションアニメ化と言う前例がありますが、

  あれはKONAMIが自社で製作しているゲームから実現できた話です

  モゲマスバンナム製作ではありません

  よって、新作への出演も無理

 

 ・新イベントもここの技術力では無理でしょう

  知っての通りモゲマスは、既存ゲーム(神撃のバハムート戦国サーガモゲマス)の

  グラフィック挿げ替えでしかありません

  モゲマス独自の要素(親愛度)もありますが、バグの温床となっています

  (しかもそのバグ修正の方法が非常に稚拙かついい加減だったことは記憶に新しいですね、

   皆さんもう忘れてしまいましたか?)

 

 ・ソースを覗くと誤字脱字が大量に存在しま

  英単語スペルミスは当たり前、構文も統一感がありません

  (ダブルクォートがあったりなかったり、スラッシュで閉じていたり閉じていなかったり)

  パーサに掛けたらエラー連発でしょうね

  既存ゲームの挿げ替えであるがゆえに、上記2つのゲームの同じ箇所で誤字脱字が存在しています

  気付いていないのか、直す気がないのか…

 

 ・モゲマスに限った話ではありませんが、

  この手のゲームは『人よりお金を多くかけた人』が俺TUEEEEを実現出来ないと成り立ちません

  人よりお金を払わない・そもそも一銭も落としていない人に対する運営の優先度は極端に低いです

  だからこそSRカードの性能は壊れていますし、今後もっと壊れていきます

 

 

これらを理解した上でプレイしたり数万円つぎ込むのは、別段問題があるとは思いません。

それでは楽しいモバゲーライフを(^^ゞ

2010-09-21

PHPでQuineプログラミング

RubyでうどんげQuine(とAA型Quineの作り方講座)

perl - Quine.pm で(ほぼ)あらゆるPerl Scriptをquineに

RubyPerlと来たら、次はもうPHPしかないでしょう。

そもそもQuineとは何か?Wikipedia先生にご登場願いましょう。

クワイン (プログラミング)

コンピュータプログラムにおけるメタプログラミングの一形態であり、自身の完全なソースコードだけを出力するプログラムである。

なるほど。

くくく。実はこの分野であればRubyPerlなんぞ足元にも及ばない。

PHPはまさしく最強なのだ


a

なんと一文字!


$ php quine.php > q.php
$ diff quine.php q.php

自身の完全なソースコードだけを出力するプログラム、ここに極まり!!!!!さすが天下のPHPだ!

AAなんて、コピペするだけで動く!

汚い言語仕様や、高度なテクニックなど、必要ない!過程や方法なぞどうでも良いのだ!





・・・・・・・・・・・・さて、そろそろ本題に入ろう。

上記の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だったのでとりあえずパスした。それにそもそも関数を使うよりもコード量が減るのか甚だ疑問であり、結局この形に落ち着いたわけなのだ!

おわり。

プログラ増田のあなぐら

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本

ログイン ユーザー登録
ようこそ ゲスト さん