  |
はてなキーワード: xhrとは
pixiv内で完結する方法ではないため海外の無断転載サイト等に画像そのものが存在していることが前提。
Chromeで検索したい非公開作品があるブックマークページを開き、F12で開発者ツールを開いてF5で更新する。
ゴチャゴチャした上の方に『Fetch/XHR』とあるので選択し、『bookmarks?tag=』で始まるファイルか何かの『Preview』を開く。
『Preview』の『▶body』、『▶works』の順で開くとブックマーク作品の題名が並んでいて、その中に『-----』という名前のものがあればそれが目当ての非公開作品についての情報。
複数ある場合でもブックマークのページと同じ順番なため照らし合わせれば問題なく判別可能。
情報と言ってもタグや投稿日時、作者名までほとんど消去されているため確認できるのはURLの作品IDのみ。
『{id: "********", title: "-----",～』となっている部分のアスタリスク部分が作品IDであり今回必要な情報。
次に他タブで検索ページを開き、pixivと作品IDで検索する。
仮に作品IDが12345678であった場合検索ワードは『pixiv 12345678』、作品ID部分を””で囲み完全一致検索にすると余計な情報も省きやすい。
https://twitter.com/piyokango/status/844361226767380481
http://www.freezepage.com/1490165400GAZZVSXBDT
である。キャッシュの freezepage ですまんが、まあいいだろ。
これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題は JINS の対応だ。
t_jins_gmo_brandtoken_cancel_if_rireki
t_jins_gmo_brandtoken_change_if_rireki
t_jins_gmo_brandtoken_entry_if_rireki
t_jins_gmo_brandtoken_exec_if_rireki
などといったテーブル名から、おそらく GMO ペイメントトークン決済を利用しているものと思われる。これはクレジットカード番号を一切 JINS 側のサーバーに通過させなくていいような構成になっており、今回のこの事例から JINS 側が保存していたクレジットカード情報が流出した可能性は、恐らくない。
しかしながら今回攻撃されたドメイン https://www.jins.com/ にはクレジットカードの入力ページが存在している( http://s.ssig33.com/gyazo/d09c0f5915f84eab8c8712eb0d23150d )。
この為、こうしたページも不正に改造されていた場合、攻撃を受けていた期間に入力されていたクレジットカード番号が不正に流出している可能性がある。
ところで JINS 側はこうした問題を認識して今朝未明にメンテナンスを行なっていたようである( https://www.jins.com/jp/news/2017/03/322.html )。
推測するに、調査をしたところクレジットカード番号入力ページの jsp なりなんなりが改竄されていた事実はとりあえず確認できなかったので、特になんの発表もしていないのであろう。ところで JINS は 4 年前にもサイトをクラックされクレジットカード番号を流出させた経験がある( https://www.jins.com/jp/illegal-access/info.pdf )。にも関わらずこの対応はちょっとおざなりすぎではないだろうか。
現実に可能性は低いと思うが、例えば以下のような可能性が考えられる。
1. ハセカラ関係者っぽく見せかけた低レベルのクラック ↑ を行なう。
2. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける
3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す
このようにすることで、クレジットカード情報を収集していたという事実を関係各位に認識させる時間を可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実はバカなスクリプトキディが適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。
こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処も必要ではないか。
JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータや資産を防護する基本的な姿勢が欠けているとしか思えない。
下見て思った。
http://mizchi.hatenablog.com/entry/2013/09/25/190313
知識が離散して蓄積されてない気がする。
シングルページスタイルのJavaScriptWebアプリケーションのアーキテクチャ
JavaScriptMVCライブラリを利用するよ！
とりあえず今回は、乱立する名称候補たちを紹介
HTML5って言いたいだけのJavaScrtipt使ったスマホのアプリフレームワークとかも呼ばれたり。
HTML5とか言われる前にJavaScriptアプリケーションやるとこれになってた。
アーキテクチャとしては、もっとも正解の名前なのだが、NET系界隈でしかきかん。
ASP.NET MVC Single Page Applicationは、キー要素がかなり詰まってて、参考になる。
このあたりのやろうとしてる奴は一度触っておくが吉
JavaScriptMVCライブラリ、AMD等の依存モジュール管理とか
英語ソースだと結構ポピュラーな感じの名前だが、指針的な匂いでアプリケーションとは言わない感も。
日本でも一時期、大規模Javascript開発とか言われてたが、Bakcbone.jsって名前に変わった。
Node.jsと被るために、このアーキテクチャの説明にはあんまり使われない。
動物本の、
「ステートフルJavaScript MVCアーキテクチャに基づくWebアプリケーションの状態管理 」
原題は、「JavaScript Web Applications」
これだけで、どのぐらい困ったか分かる感じ。
ちなみに、JavascriptMVCアーキテクチャの解説本としてはありなので読むが吉
といっても、10年ぐらい前からXHRとHTMLとDOMでほげるのは
実はあんまり変わってない。
Java界隈から出したかっただけ。oracleが呼んでた気がする。
Struts死んだけど、JSFでやるの？JSF無理筋だから違うフレームワーク作るの。
JSFみたいな抽象化使い始めると、コボルみたいにJava世界に閉じそうだけど大丈夫なの？
このあたりのライブラリ使えば、簡単にこのスタイルのアプリ作れると思ってるでしょ？
ライブラリの名称なのだが、背負ってるものは、大体この界隈全て
だけど、使えば、この界隈のアプリが簡単に作れるかというと、そうでもない。
