Skip to content

Instantly share code, notes, and snippets.

@mala
Created April 21, 2017 05:25
Show Gist options
  • Star 11 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mala/f2b7659f78bb396bf1eb6788be38a72d to your computer and use it in GitHub Desktop.
Save mala/f2b7659f78bb396bf1eb6788be38a72d to your computer and use it in GitHub Desktop.
Orarioについての雑感

調べたこと

通信をキャプチャして調べた。似たようなことをしている人が既にいて仕組みについてはサービス提供者側が説明されているとおりだった。

IDパスワードはネイティブUIで表示して、html中のどこに入力するかなどはリモートから受信するjsで定義している。特に難読化や独自の暗号化などがされているわけではない。

"例のアプリの方式、運営がその気になったらこっそり(アプリのアップデートを必要とせず)情報収集が可能な上、apiサーバがpwnされたら終わりという点でリスクはサーバ側で大学アカウント保持するのと大差無いという感じ"

自分は「大差ない」とは思わない。アプリ内においても、サービスの説明においても、Appが大学サーバーと直接通信を行うことは説明されているので、この説明から外れる動作をすれば不正指令電磁的記録になるだけだ。ちゃんと法的な縛りがある。

パスワードをサーバーに預けるのであれば、実際に何をしているか、安全かどうか、事業者の信頼性でしか判断できないことになるが、クライアント側で動くコードであれば(それが動的に受信するものであっても)自分の計算機上で動くのだから、ちゃんと検証することが出来る。

後天的にマルウェア化可能だという批判

この問題は技術的に解決できる可能性がある。IDパスワードやスクレイピング結果がjsで別サーバーに送信されるといったことが起きてはいけないので、アプリの静的なコード部分でそのようなことが起きないことを保証すればいい。 任意のjsを実行しつつも、CSPによる制限でjsからリモートのサーバーには接続できないようになっていれば、スクレイピング結果がローカルのみに保存されることが保証できる。

(WebView部分の細かい実装は見ていないので、jsが改竄された場合にどこまで起こりうるのかは、実際の調査していない)

解決不能な問題ではない。サーバー側で動いてようがクライアント側で動いていようが結局のところアプリ提供者の信頼が全てで大差ないよねーなどというのは自分の計算機で何が起きているのかを知る権利を自由を手放した豚の発想であって、そんな自由を手放すような教育をするのはもはや大学ではない養豚場に改名しろ。

グレーゾーンとか言いたがる人たち

不正アクセスかどうか微妙とか、判断は保留みたいなコメント付ける人よくいますよね、お前は歯に何が挟まってんだ。

利用権者の承諾を得て行うのは不正アクセスじゃないんで、グレーゾーンじゃねえよ。ホワイトだよ。何勝手にグレーにしてるんだ、法律読めよ。馬鹿か。

法律で禁止されてるのと、管理者が禁止してるとか規約規定で禁止されてるとかの区別をちゃんとつけて欲しいし、Orarioのケースに関してはただの専用ブラウザであってIDパスワードの第三者への提供なんてそもそも起きてないわけ。ほんとに禁止されているような行為が起きてるんですか?

一般論として、非公認のアプリを使って被害が発生しうるとか責任負えないとか言うのは分かるんだけど、特定のアプリ名指しで、ろくな根拠無しに安全ではないとか不審であるとか批判するのは、まともな人間のすることではない。 そんなものが情報リテラシーであってたまるか。俺は学生の情報リテラシーではなくて大学教員の情報リテラシーが不安だよ。いい加減にしろ。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment