  |
はてなキーワード: APKとは
Sunwin | Tải Game Sun Win APK/IOS | Uy tín Hàng Đầu châu Á. Sunwin cổng game bài đổi thưởng số 1 Sunwin ông lớn trong thị trường game tại Việt Nam. Game bài Sunwin được biết đến là sòng bài macau quốc tế thu nhỏ và cho phép người chơi trải nghiệm hoàn toàn miễn phí. Cổng game đổi thưởng đang dẫn đầu về chất lượng trải nghiệm và chất lượng nhất Việt Nam. Hiện nay cổng game bài đổi thưởng Sunwin đã xây dựng cập nhật một hệ thống một cách bài bản ở phiên bản Sunwin 14
iPhoneからandroid（pixel7 pro）に移行したんだけど、フリック精度が悪い
Twitterや5chブラウザや漫画アプリで画像を開いて、次のページに移動するのにフリック操作をするんだけど、iPhoneやiPadminiなら軽くフリックするだけで移動できるのにPixel7だとちょっと強く（？）フリックしないといけない
なんかこういう、ちょっとした操作の精度が全体的に5年前のiPhoneにすら追いついていない
Galaxyも触らせてもらったけど同じような感じ。
iPhoneと違ってapkファイルで簡単に非公式アプリをインストールできる利点が大きすぎるからandroidに移行したことは後悔してないし次もandroidにする予定だけど、もうちょっと頑張ってほしい。
議論がすっ飛んで聞こえると思うけど
如何に効率良くそのゲームを攻略するかという意味でのハッキングは3種類に分かれるのね
ポケモンで言うとさ
その1. 捕獲厳選や孵化厳選：ゲーム外のツール等を用いずに手作業で完結する攻略法。 手作業・人力で再現できることのみ行う
その2. 乱数調整：ゲーム外のツールを用いるが、ゲーム自体には侵襲しない攻略法。 「手作業・人力で再現することは理論上可能だが現実的には不可能」なことを再現する
その3. 改造：ゲーム外のツールによってゲーム自体に侵襲する攻略法。 ツール無しで再現することが理論的に不可能な状態を再現する
通常ガチャマクロに関しての侃侃諤諤の議論は、要は「その2を許容するか否か」が論点だと思うのね。
その1を論難する人は居ないと思う。ゲームが好きな人はみんなそうする
その3を許容する人も居ないと思う。改造apkとかBANされるし
じゃあその2はどうかと言うと、俺は許容されるべきだと考えてる
なぜなら、可能な努力は全て行われるべきだから。ゲームに真剣になれ
もちろんマクロやBOTが、サーバーに大きな負担を掛けたり、他のプレイヤーの迷惑になったり、ゲームバランスを大きく毀損するならその努力は行われるべきでないけど、通常ガチャマクロに関してはセーフだと思う。誰か迷惑した？
直感的にその2に嫌悪を覚える向きも分かる。俺もゲーマーだからその感情は知ってる。
でも「俺が嫌だから、それを公式に禁止させ、他のプレイヤーから努力の選択肢を奪う」って態度がゲーマーとしてフェアで健全かと言われると、そうじゃないだろ？
まあ今回は公式に禁止されるので、運営が想定していなかった遊び方なんだろう、恐らく。それにしては禁止が遅いが。
じゃあな
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
7と8。
技術的なところが気になる人はこれだけ読んでくれたらいい
最後に技術的な観点からエアレペルソナが純国産ではないということを指摘する。
RocketChatという海外で開発されたOSSチャットアプリをフォーク、改変したもののよう。
ttps://github.com/RocketChat/Rocket.Chat.ReactNative
ttps://rocket.chat
フォーク元はバリバリ多国籍、外資である。(RocketChat自体は問題のないアプリであり、このエアレペルソナとはフォーク関係を超える関係はないと思われる)
冒頭のこの部分に関してである。
ttps://play.google.com/store/apps/details?id=chat.airlex.reactnative
Google Playで公開されているエアレペルソナのAndroidアプリをリバースエンジニアリングして調べてみた。
ちなみに、エアレペルソナには利用規約のようなものは見当たらず、リバースエンジニアリング禁止条項も無いようだった。
ttps://apps.evozi.com/apk-downloader/
ttps://github.com/pxb1988/dex2jar
この辺を使ってapkをダウンロードし、apkを解凍し、chat.airlex.reactnative/classes.dexをjar fileに変換した。
classes.dexから変換されたjarファイルを展開するとchat/airlex/reactnativeというフォルダ、パッケージが見つかる。
このパッケージ内のファイル(.class、クラス)がエアレペルソナの処理を行うもののようである。
このクラスをJadを使い、デコンパイルしてみた。その結果が以下である。
ちなみにここからapkをアップロードするとdex2jarをしなくてもJavaのソースコードにまでデコンパイルしてくれた。便利。
package chat.airlex.reactnative; import android.content.Context; import com.ammarahmed.mmkv.SecureKeystore; import com.facebook.react.bridge.ReactApplicationContext; import com.tencent.mmkv.MMKV; public class Ejson { private String TOKEN_KEY = "reactnativemeteor_usertoken-"; String cardId; String host; String messageId; String messageType; /* access modifiers changed from: private */ public MMKV mmkv; String msg; String notificationType; String rid; Sender sender; String senderName; String type; public Ejson() { ReactApplicationContext reactApplicationContext = CustomPushNotification.reactApplicationContext; if (reactApplicationContext != null) { MMKV.initialize((Context) reactApplicationContext); new SecureKeystore(reactApplicationContext).getSecureKey(C0617Utils.toHex("com.MMKV.default"), new RNCallback() { public void invoke(Object... objArr) { if (objArr[0] == null) { MMKV unused = Ejson.this.mmkv = MMKV.mmkvWithID("default", 1, objArr[1]); } } }); } } public String getAvatarUri() { if (this.type == null) { return null; } return serverURL() + "/avatar/" + this.sender._id + "?rc_token=" + token() + "&rc_uid=" + userId(); } public String token() { String userId = userId(); MMKV mmkv2 = this.mmkv; return (mmkv2 == null || userId == null) ? "" : mmkv2.decodeString(this.TOKEN_KEY.concat(userId)); } public String userId() { String serverURL = serverURL(); MMKV mmkv2 = this.mmkv; return (mmkv2 == null || serverURL == null) ? "" : mmkv2.decodeString(this.TOKEN_KEY.concat(serverURL)); } public String privateKey() { String serverURL = serverURL(); MMKV mmkv2 = this.mmkv; if (mmkv2 == null || serverURL == null) { return null; } return mmkv2.decodeString(serverURL.concat("-RC_E2E_PRIVATE_KEY")); } public String serverURL() { String str = this.host; return (str == null || !str.endsWith("/")) ? str : str.substring(0, str.length() - 1); } public class Sender { String _id; String username; public Sender() { } } }
フィールド名を見てみると、cardId, host, messageId, messageType, mmkv, msg, notificationType, rid, sender, senderName, typeが存在する。
メソッドには、getAvaterUri、token、userId、privateKey、severURLが存在する。
ところで、RocketChatというOSSのチャットアプリが存在する。
ttps://rocket.chat
そのRoketChatのAndroid実装の中に同名のEjsonというクラスが存在する。
ttps://github.com/RocketChat/Rocket.Chat.ReactNative
ttps://github.com/RocketChat/Rocket.Chat.ReactNative/blob/develop/android/app/src/play/java/chat/rocket/reactnative/Ejson.java
見比べてみると、フィールドにcardIdが追加されている以外はフィールドやメソッド名、そしてその処理の内容まで一致している。
他にもReplyBroadcastなど、同様のクラスがエアレペルソナに見つかる。
以上のことからエアレペルソナはRocketChatをフォークして、パッケージ名を変えて作られたチャットアプリであり、開発の大部分はRocketChat社の努力と多数のOSSコントリビュータによってなされたものであると思われる。
そもそもこのOSS時代に純だの何だの言っている時点で怪しい。
さて、エアレペルソナがRocketChatをフォークして作られたものであるとすると、気になるのはライセンスである。
RocketChatのOSSライセンスはMITライセンスである。
ttps://github.com/RocketChat/Rocket.Chat.ReactNative/blob/develop/LICENSE
MITライセンスは非常に緩いライセンスであるため、エアレペルソナの様にフォークして別のアプリケーションとして公開することにはおそらく問題がないということは強調しておく。
現状エアレペルソナにログインできておらず(2要素認証のコードが送信されないといった問題が起きている模様)、使用している各OSSのライセンス表示が適切に行われているかまでは調べられていない。
昨今はAppleのApp StoreやGoogleのGoogle Play Store上での問題が注目を集めている。大きな組織によって自分たちの首根っこが抑えつけられ自由を侵害されるというのは今に始まったことではないが、ここに関する反発は日々強まってきていると感じる。大きな組織がさらなる大きな力を持ち、中央集権を強めるなかで我々が模索し目指さなければならないのは脱中央集権、非中央集権である。自分たちの在り方は自分たちで決めるし自分たちの個人情報は自分たちに権利があるのだ。
Mastodonという非中央集権なSNSがある。プロジェクトはオープンソースで誰もがMastodonのサーバーをホストすることができる。このサーバーたちは相互に繋がることができるので違うサーバーであってもメッセージを送り合うことができる。
今回問題になったのは、Google Play上で公開されているいくつかのMastodon向けクライアントだ。これらのアプリはGoogleの主張によれば「ヘイトスピーチ」に関する内容を含んでいるため改善しろ、というものであった。クライアントはただサーバーにアクセスするだけである。ユーザーがアクセスしているサーバーにはGoogleが指摘するようなヘイトスピーチを扇動するようなサーバーがあるかもしれないが、それを理由にGoogleが該当サーバーをホストしている訳ではないアプリ開発者に対して改善をするよう脅迫するのは理不尽である。彼らのGoogle Chromeでもこれらのサーバーにアクセスすることは可能であり、ただクライアントがWebページを表示しているのとなんら変わりない。Googleの主張からすれば、彼らのGoogle Chromeも同様に取り締まられるべきだ、と言えてしまう。
今回の問題は既に一度議論されたことがある。Gabという極右コミュニティがMastodonを使ってMastodonを始めとしたネットワークに参入してきた。これを機にMastodon創始者のオイゲン氏はGabをサーバー管理者やクライアント開発者に排除するよう呼びかけた。サーバー管理者やクライアント開発者はGabをブロックしたりしなかったりした。サーバー同士で繋がることができると言っても例えば日本語と英語とで言語圏の違ったりと接点が無い場合はわざわざブロックする必要はないだろうということだ。またはサーバー管理者がわざわざブロックしなくともユーザーが各自に対応する自由な判断に任せるということもある。クライアントはただサーバーにアクセスするだけであるからハードコーディングによってそれらを排除するのはナンセンスであるし、この行動はユーザーの自由を制限することであるからやるべきではないという意見もあった。一方でGabにアクセスすることができることを理由にApp StoreやGoogle Play Storeからアプリを削除されてしまうのではないかという意見もあった。ただこの懸念はただのクライアントに対して合理性を持たないだろうと思われていたがその懸念が愚かなことに現実となってしまった。
さて幸いなことに今回の問題はGoogle Play上で起こったものである。Google Play Storeを使わなくてもAndroid端末にインストールすることができる。F-DroidやAPKの配布などインストールする手段は残されている。これがApp Storeでの問題ならば開発者とユーザーに残された生き残る手段はないだろう。
2017年頃にMastodonが注目された頃に比べて大きなメディアがMastodonを取り上げることはめっきりなくなった。国内で言えばITmediaがよく特色のある記事を書いていたが今では全く更新されることはなくなってしまった。mstdn.jp の管理者が変わったことの詳細な記事がITmediaから出ると期待しているが既に変更されてから2ヶ月が経とうとしている。仕方がないよね。Fediverseの思想がいくら素晴らしくても金にならないんだもの。金にならない話は注目されない。記事にする価値はない。世の中は金の話が本質的に価値を持つのか？
Mastodonに対するメディアの関心というは昔に比べて低くなったものの今回の問題はHacker Newsにて大きな注目を集めているのでメディアに取り上げてもらって大きな世論を形成していって欲しい。ITmediaはGabとMastodonについての記事を書いてくれなかったので期待することさえ無駄だろうが。
Subway Tooter blog - Playストアからの削除警告について - Subway Tooter blog
http://subwaytooter.hatenadiary.jp/entry/2020/08/29/113948
Google is apparently taking down all/most Fediverse apps from the Play Store | Hacker News
https://news.ycombinator.com/item?id=24304275
How the biggest decentralized social network is dealing with its Nazi problem - The Verge
新しいiPhoneな11衝動買いしてホームボタンないとこんな挙動なんだなーといろいろ調べながら楽しく便利に充電もすげー持つからいい買い物したなー
で、iOSの引き継ぎってバックアップでほぼ一瞬なんだけどほとんどそのまま移行されるのに一部アプリが再認証とかIDpass必要だったりするのめんどくせーつうてもそんなもんだろ無料のアプリなんかならなおさらとか思いながら
同僚も丁度スマホ切り替え時期で新しいあいぽん出るから待って考えたらの矢先
リコール製品で無料取り換えしてくれたらしいスマホの申請期間過ぎてから壊れて気付いて手遅れで2年くらい前の古い泥機を慌てて買い
先々週末全部潰していっこいっこ引き継ぎ大変だったとかお前のGooglePlayアカウントどうなってんだ…
のバカさ加減を見るに本当に仕事できない人って何やってもダメなんだなあを観測している
なのになんでかアプデされなかった古いアプリをapkファイルからインストールする方法は知ってたりとか意味わかんねえ…
古いのが使い勝手いいのは勝手にしろいやでも新しいのを受け入れられない老害か？とか思うし
仕事で使うブラウザも古いアドオン使いたいから古いほうがいいって更新しないのもクソだし
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
要するに PackageInstaller が権限チェックするタイミングと、実際にインストールするタイミングの間に、対象の .apk を置き換えてしまうという手法となります。(Google Play ストアからのインストールの場合は、一時的な .apk は /sdcard などではなく端末内のセキュアな場所に置かれるために、書き換えることができません。)
また Android 4.3 以降は、権限チェック時に AndroidManifest.xml のチェックサムを記録しておき、インストール時にももう一度それを確認するように PackageInstaller が修正されているようです。(一部のベンダの端末では 4.3 でもこのチェックをしていないので脆弱性の影響を受ける)
さらには、4.4 以降であれば、上記のチェックサム確認の他に、そもそもアプリが自由に /sdcard を書き換えることができなくなっているので、.apk を書き換えること自体ができなくなっていますね。
ユーザにできる自衛策としては、Google Play からのみアプリをインストールする、といったところでしょうか。
あるいは、/data/local/tmp はアプリからは書き換え可能でしたっけ？
できないのであれば、PC で .apk ファイルをダウンロードしたのち、adb install でインストールする、という手もありなのかな。
あ、ちなみに Amazonアプリストアアプリ (ややこしいな) は既にこの問題に対処しているようなので、Amazonアプリストアは安心して利用しても大丈夫かと思います。
この間、AmazonでKindle Fire HDXの7インチのヤツが5000円引きだったからホイホイ釣られて買った
そのうちKindle Fire端末は買うつもりだったからちょうど良かった、と思ってた
Amazonプライムの会員だったら毎月１冊無料でKindle本が読めるし
Android互換だからマイナーなアプリはなくても、有名どころなら当然ストアにあるだろうし
いいことづくめじゃん！
そう、思ってた
でも実際は違ってた
オーナー ライブラリーのメニューからカテゴリまで絞り込んで、
あとはページを送ってシーケンシャルに自分で探さなければいけないとかなんなの、ばかなの？
あと、カテゴリ分けもクソ
「IT・コンピュータ」のサブジャンルの「プログラミング」に１冊しか本がない
あの・・・親ジャンルの「IT・コンピュータ」にはScalaだのJavaScriptだのPythonだのという文字の含まれたタイトルが結構見えるんだけど・・・？
つーか、「IT・コンピュータ」カテゴリの最初に出てくるのがちきりん日記の育て方とかいうどう考えても関係なさそうな本なのもどうなの
なんか自費出版本の数も以上に多いし
http://www.amazon.co.jp/gp/feature.html/?ie=UTF8&docId=3077716126
まあ、ここまではいい、だいたいそんな気はしてた
でもKindleではGooglePlayはつかえない
よしんばAmazonになくても、はてなのことだからapkファイルをダウンロードできる様にくらいしてくれてると思ってた
でもなかった
これは完全に予想外だった
かくして、年末年始はごろごろしながらKindle端末で本読んだり、はてブでgdgdしたりするかー、という私の予定は崩れ去った
