「ウェブアプリケーション」を含む日記 RSS

はてなキーワード: ウェブアプリケーションとは

2019-09-12

ISUCON9予選のレギュレーションバグについて

ことの顛末

ISUCON 9 参加記 - kyuridenamidaのブログ

ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog

TL;DR

本文

そもそもレギュレーション違反なのか問題

パスワードを平文で保存すること禁止する」というレギュレーションに対して、「パスワード+#」が違反したと見なされたのが最初見解

ここでいう「平文」が出てくる文脈は、初期実装のbcryptからも明らかなように暗号理論文脈だと考えられる。ここに疑念を挟む人はまずいないだろう。

そして暗号理論文脈で言う「平文」とは明確な定義があり、今回で言えば「パスワード文字列のもの」だ。

まりパスワード+#」は「平文」ではない。

これは学問的には異論余地がないので、このことを知らなかった人や、どっちもどっち論に立っていた人は、素直にごめんなさいすべきだ。

たとえば以下のツイート主が主張するような「原理的に元に戻せるのは全部平文」なんて定義暗号理論では受け入れられていない。複合可能なら全部平文なの?


もう話はここで終わってもいいのだが、まだまだ論点があるので続ける。

平文と同程度の強度は実質平文なのでは問題

この立場に立っている人も結構いるように見かけたが、レギュレーションからそれが読み取れないので無理がある。

第一に、レギュレーションでは暗号強度に関して全く触れられていない。

第二に、OK暗号強度の線引きがあるのならベンチマークでチェックすべきだ。

特に後者は今回(自分の知る限り)誰も言っていなかった気がするが、セキュリティの側面も持たせるのなら仕組みで担保しなきゃダメだろう。

運営側が想定していたレギュレーションが、平文よりも高い暗号強度での保持であったとしても、そのことが明確にわか文章になっていないので、レギュレーション文言実装バグしか言いようがない。

そもそも効率化のためにセキュリティ犠牲にするのはどうなのよ問題
ウェブアプリケーションとしてありえない実装ダメでしょ問題

実はこの立場運営擁護していた人が一番多かった気がしてしまうのだが、見事にハシゴを外されてドンマイとしか言いようがない。

たとえば有名人だとこの人とか。


残念ながらISUCON運営公式の言説として、平文とまではいかなくても暗号強度を犠牲にすることは想定内であったことがアナウンスされている。

bcryptによる負荷の対処方法として、サーバを追加、軽量なハッシュ関数での代替、あるいは平文での保持を開発チームにおいて想定しましたが、現実問題として、パスワードなどの情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ちました。

ウェブアプリケーション開発者として、みたいなことを大上段に出されても、ISUCON現実ウェブサービスであれば許容できないようなハックを用いてでも高速化するコンテストである、という文脈は、それこそ過去ISUCON確立されてきたものなわけで、ISUCONを知らないのなら黙っといたほうがいい、としか言いようがない。

なお実サービスでは当然やらないことをやるのはどうよ、みたいな話を持ち出すと、今回おそらく運営脳内レギュレーションではMD5あたりもOKだったのでは、という辺りを考え出すと、やはりどこがラインなのか明確じゃないよねって話に結局なる。(2019年MD5を許す実サービスは流石にないよね?)

そこを明確にしたいなら文章化(脳内レギュレーション実装)をがんばるか、ベンチマークなどで担保するしかなかったという結論は変わらない。

それが出来ないなら何でもありになるのは当然の帰結だし、それを美学だとかプライドだとか個々人の価値観が大きく異なる概念で縛ろうとするのは、こと競技に関しては真摯姿勢ではない。

(たとえば大相撲のような競技でも、横綱が変化しちゃダメという美学に関して喧々諤々な議論が起きたりする)

運営はどうすべきだったか

今回は見逃して次回からルール文化をがんばる

王道はこれ。

脳内レギュレーションを明文化できていなかった、という反省を踏まえて次がんばるしかない。

今回は他チームから問い合わせがあったらしいが「平文」の定義をきちんと調べさえすれば、想定していた回答ではないが「パスワード+#」は平文ではないので今回のレギュレーション違反には当たらない、という結論を伝えるべきだったように思う。

運営側が求める最低限の強度の実装で追試験

現実的な落とし所はこっちだったかもしれない。おそらく該当チームも、これなら反発はしなかったんじゃないか

今回は競技中の質問に回答をしなかったという問題もあった。

まりこういうことを伝えたらどうだったか



今後のこと

まだ本戦があるんやで

ということで騒ぎは終わりにしたい、という気持ちに関しては多くの人の一致を見るはずだ。

一方で運営側の朝令暮改のような対応に不信感や疑問を持つ人が多いのも事実だと思う。

ボランティアでがんばってるんだから目を瞑ろう、という感情的意見もまあ分かる。お疲れ様だ。

たこれは個人的見解だが、特に今回の予選問題過去最高傑作と言っても過言ではないくらいよく出来ていると思うし、流通額をスコアとするビジネス上の目的意識させるというメッセージ性も素晴らしいと思うので、今回の一件を持って問題作扱いされてほしくない気持ちは正直ある。


でもきちんと総括しないで先に進んでも誰も幸せにならないのもまた事実だと思う。

ということで、運営側はレギュレーション文言バグっていたことをちゃんと認めて、該当チームに落ち度が全く無かったことを謝罪した上で、次に進んでほしい。

競技中に質問に答えなかったこと、参戦後ブログ根拠裁定をくだしたことも悪手だと思うが、それ以上に、「レギュレーション違反はなかった」ことをきちんと伝えて名誉回復してあげるのが一番の筋のはずだ。

2019-07-12

anond:20190712134213

アプリケーションサーバ自体クラックされているんです。

それで、カーネルレベルルートキットが仕組まれていて、

ID&PASS相当の情報メモリ上の通過するたびに自動漏洩しています

まりセブンペイに会員登録して、ID&PASSが発行されると同時に

ウェブアプリケーション上には一切のセキュリティホールが無いにもかかわらず

クラッカーは知ることができてしまます

なんでアプリケーションサーバクラックされているかというと、

開発の下請け孫請け中国人がこっそり仕掛けたからです。

ぶっちゃけて言えば内部犯行であり、サービス開始前から仕掛けが出来上がっていたのです。

2019-05-31

anond:20190529223043

むかし、2chスレに書き込んだら、それが火に油をそそぐことになって後悔したこと

あるのだけど、その反省きっかけとなって、今はウェブアプリケーション脆弱性診断

生業にしている。

この十年いろいろあったけど、振り返ればあっという間だった気がする。

https://tsushima.5ch.net/test/read.cgi/news/1260662520/

2018-05-14

例の大学ウェブサイト

ウェブアプリケーションXSS 脆弱性があるんだけど、IPAに報告してもネタとして喜びそうなので報告したくない。

2017-07-06

無知無理解プロジェクトが殺されそうだ

当方フリーIT 技術者。ある Web ベースシステムを開発しているのだが、プロジェクトマネージャーリーダーをはじめとするメンバー無知無理解のおかげで作業が進まずに困っています

ブラウザーキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。

登場人物

私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。

A 社内のチームメンバーは以下のとおり。

さて、今開発しているシステム(以下システム P)はもともとスタンドアローン運用する形態だったが、最近クラウドバージョン提供も始まり現在スタンドアローンバージョンクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバー管理や、私や W さんが作った部分のテスト担当している。

問題発覚

クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードアップデートすると、ブラウザーキャッシュが効いていて表示がおかしくなるというのだ。

プログラマー以外の 4 人は実は Web システム案件は初めてで、ブラウザーキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーキャッシュクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミークエリ文字列をつければよい。アップデートのたびに数字を変える。これは一般的採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。

これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。

前回リリースから変更のあったファイルの洗い出しを命じられる

X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルリストを出してほしい」と言われる。変更のないリソースにはクエリ文字列をつけたくないらしい。

内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコード確認し、この一覧表に載っているファイルにはクエリ文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイル対象にしたほうが作るほうもテストするほうも楽です」と伝えた。

問題発生箇所の調査を命じられる

6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラスID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。

私は「ブラウザーキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュ問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。

ブラウザーキャッシュの仕組みを基本から説明する

プログラマー 4 氏の知識底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーキャッシュの仕組みを解説する文書投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまりかいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。

キャッシュとは

キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります

ウェブブラウザーにおけるキャッシュ一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイルJavaScript ファイル画像ファイルなど)に対して適用されます

キャッシュが作られるタイミング

ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。

キャッシュが破棄されるタイミング

キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルキャッシュが同じ期間だけ存在するかどうかも分かりません。

キャッシュユーザーブラウザー操作で明示的に削除(クリアー)することはできますが、 サーバーからクライアント(ブラウザー)のキャッシュクリアーすることはできません。

ウェブアプリケーションキャッシュ対策

ウェブアプリケーションアップデートした際、クライアントキャッシュ無効にするために、以下の手法がよく使われます

link rel="stylesheet" type="text/css" href="style.css" >
< script type='text/javascript' src='script.js' >< /script >
< img src="picture.jpg" alt="" width="640" height="480" >

このような外部リソース読み込みについて、ファイル名の後ろにクエリ文字列を追加します。

link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >
< script type="text/javascript" src="script.js?v=2.4.0" >< /script >
< img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" >

スクリプトでない静的ファイルクエリ文字列を付加しても、読み込まれファイルは同じです。つまりstyle.cssstyle.css?v=2.4.0 は同じ style.css というファイルを指します。

ブラウザーが style.cssキャッシュしている状態で、この行を読み込んだとします。

link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >

ブラウザーは「style.css?v=2.4.0 というファイルキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれスタイルシート更新されます

この HTML をまた読み込んだ時は、「style.css?v=2.4.0 というファイルキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。

ウェブアプリケーションバージョン 2.5.0 にアップデートする時には、「?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。

link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" >
< script type="text/javascript" src="script.js?v=2.5.0" >< /script >
< img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" >

同様の仕組みで、2.4.0 時代キャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれキャッシュ問題は起こりません。

この手法は、キャッシュ問題解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます

上記に長々と書いた内容を踏まえ、今回の問題についてご説明します。

「暫定対応」の指示が出る

日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(< div style="..." >)で指定すればよい」と結論づけていた。

報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。

この報告書を元に、X さんから「この行とこの行にインラインスタイル指定してください。これで暫定対応します」と指示が出た。

私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境たまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業完了した。Gitコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。

しばらくすると X さんから「うまく表示されていますOK です」と報告があった。

その日のうちに問題再発

夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScriptキャッシュですね」。

聞けば、Y さんは「キャッシュスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタン有効だったとも。

私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。

Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。

私は繰り返し、ブラウザーキャッシュ環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。

「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者意見を聞いてください」

対応が先送りになる

この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。

聞けば、リリースを急いでいるのは特定顧客要望によるものらしい。その顧客スタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーキャッシュを消してくればいいとのこと。

リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。

レビュー開催

そして今日夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。

X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。

ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態対応策を一生懸命協議していたのですな。

レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者説明してもらったって、信じないんだったら意味がないのにねえ。

追記

文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。

https://anond.hatelabo.jp/20170706122924

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