カスタムURLスキームの乗っ取りとその対策
カスタムURLスキームの乗っ取りとその対策 May 17, 2021 カスタムURLスキームは、モバイルアプリ内のコンテンツへ直接誘導するディープリンクに広く利用されている¹。そのような中で、2020年3月にLINEはカスタムURLスキーム line:// の使用を非推奨とした²。非推奨の理由をLINEは「乗っ取り攻撃が可能なため」と説明し、代わりにHTTP URLスキームによるリンクを推奨している。この変更に対して私は、なぜHTTP URLスキームによるリンクだと乗っ取り攻撃を防げるのか疑問を抱いた。この疑問に答えるためにLINEアプリの乗っ取りを試み、対策の有効性を確認した。 要約 HTTP URLスキームによるディープリンクは対象のアプリを一意に特定できるため、不正アプリによるリンクの乗っ取りが発生しない。カスタムURLスキームでは複数のアプリが同じスキームを宣言できるため、モバイル
脆弱性を抱えるソフトウェア開発キット「Moplus」、実はバックドア機能の実装が判明 | トレンドマイクロ セキュリティブログ
中国の検索エンジン「百度（Baidu）」のソフトウェア開発キット（Software Develoment Kit、SDK）「Moplus」に「Wormhole」と呼ばれる脆弱性が確認され、この脆弱性が利用された場合の影響の深刻さゆえに波紋を呼んでいます。この脆弱性は、中国の脆弱性報告プラットホーム「WooYun.og」により確認されました。 しかしながら、トレンドマイクロがこの脆弱性について調査を進めたところ、Moplus SDK 自体にバックドア機能が備わっており、必ずしもそれが脆弱性に由来または関連しているわけではないことが明らかになりました。現時点で、この問題は Moplus SDK のアクセス許可制御とアクセスの制限方法にあると見られています。そのため、脆弱性が関係していると考えられているのですが、実際には、この SDK のバックドア機能により、ユーザ権限なしに以下を実行する恐れが
JVNVU#94598171: Samsung Galaxy S にプリインストールされた SwiftKey が言語パックのアップデートを正しく検証しない脆弱性
JVNVU#94598171 Samsung Galaxy S にプリインストールされた SwiftKey が言語パックのアップデートを正しく検証しない脆弱性 Samsung Galaxy S にプリインストールされている、SwiftKey SDK を用いたキーボード機能には、言語パックのアップデートを正しく検証しない脆弱性が存在します。 Galaxy S4 Mini Galaxy S4 Galaxy S5 Galaxy S6 国内携帯大手 3社によると、3社で販売している日本国内向けのこれらの製品は、本脆弱性の影響を受けないとのことです。 Samsung Galaxy S における SwiftKey 言語パックのアップデート機能の実装には、skslm.swiftkey.net との通信を HTTP で行う脆弱性が存在します。攻撃者は中間者 (man-in-the-middle) 攻撃によ
モバイルファースト時代のネットワークレイヤデバッグ手法 - クックパッド開発者ブログ
こんにちは。インフラストラクチャー部 セキュリティグループの星 (@kani_b) です。 クックパッドでは主に "セキュリティ" か "AWS" というタグのつきそうな業務全般を担当しています。 ここ数年、クックパッドではいわゆるネイティブアプリの開発が非常に盛んです。 私達インフラストラクチャー部はネイティブアプリの直接の開発者ではありませんが、開発が円滑に進むように色々なレイヤでそのお手伝いをしています。 PC 向けサービス開発と比較して、スマートフォン向け、特にネイティブアプリにおいては、何かトラブルがあった際に どこで何が起きているか、そのデバッグを行うことが若干難しいと感じています。 今回はいわゆる jailbreak や root 化をせず、ネットワークのレイヤからデバッグを行う方法についていくつかご紹介します。 HTTP プロキシによるキャプチャ まずは HTTP プロキシ
AndroidのHttpURLConnection。 - なるようになるかも
これはAndroidじゃなくてJDKのインターフェースの設計の問題なのですが、HttpURLConnectionは入出力エラーが発生した際にIOExceptionを投げるという規定があります。 問題は、HTTPステータスコードが400番台ないし500番台のコードのボディを読もうとした際に、getInputStream()を使うと入出力エラー扱いされてIOExceptionが発生することです。 最近のRESTfulなサーバーインターフェースの設計だと、HTTPステータスコードに意味を持たつつ、レスポンスボディにコンテンツを渡すのが主流ですが、HttpURLConnectionのちょっとしたサンプルでは400 Bad Requestや401 Unauthrizedが返されることを考慮していないことが多いです。 HttpURLConnectionを本格的に使おうとすると、大抵ここで躓くことになり
Androidの通信処理に何使えばいいのか分からないって話。 - なるようになるかも
特に結論はないです。本当に分からないので。 ソケットレベルまで踏み込むと、途端に面倒になってどのライブラリを使っても手に負えませんし、単にGETとかPOSTとかする分には正直どれ使ってもそこまで変わらない気がしてます。 それより自己署名証明書の検証を無視して通信を行うと端末が爆発するライブラリが必要だと思います。 Apache HTTP Client みんなお馴染みDefaultHttpClient。色々なライブラリがあるけど、最終的にはここに行き着いていることが多いです。 しかし「Apache HTTP Clientとは何なのか」、という説明はあまり見ない気がします。 自分も「Apacheソフトウェア財団のトップレベルプロジェクトとして運用されている、RFCを満たす実装を目指したJava向けのHTTPインターフェース」という超ふんわりとした認識しかないです。 かなり巨大なライブラリで、全
Android組込みのHttpComponent（HttpClient）の正しい使い方といくつかのtips - terurouメモ
ブログ等に掲載されているHttpComponentのサンプルコードは、重要なところが端折られて紹介されている（というか間違っている事を知らずに書いている疑惑すらある）ことが多いので、正しいサンプルコードを書いておく。 まぁ、ここだけでなくApache HttpComponentsのドキュメントもちゃん読みましょう。あ、Androidのリファレンスにはロクに使い方が書いてないので、あんなゴミだけ読んでてもダメですよ。 要点 ポイントは2つ。 ResponseHandlerを使ってコードを書く HttpResponseの内部リソースを自動で解放してくれるので、ミスがなくなり、コードも簡潔になる。ブログ等ではHttpResponseを使わないコードもよく掲載されているが、リソースの解放処理が記述されていないことが多いのであまりよろしくない。 なお、ResponseHandlerを使わずに自分でリ
Androidエミュレータの通信をFiddlerで見る
Androidのアプリ開発をするときに、サーバとの通信を確認したいということはよくあります。 通信の確認にFiddlerを組み合わせて使うことで、XMLを整形された状態で見たり、詳細なHTTPヘッダを確認したり、リクエストを改ざんしたり、アプリプログラム側を変更せずに開発サーバを見に行くようにしたりできるようになります。自分のローカルマシンだけでサーバ・クライアントモデルの開発が完了できる環境を作っておくと楽ですね。 Fiddlerについてはこちら。 実はFiddlerがすごすぎたので、機能まとめ紹介 : blog.loadlimit – digital matter – AndroidエミュレータのHTTP Proxy設定方法について参考にしたのはこちら。 [Android] エミュレーターのプロキシ設定（Using the Emulator with a Proxy） – adakod
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - square/okhttp: Square’s meticulous HTTP client for the JVM, Android, and GraalVM.