title_parttitle_parttitle_part
静岡県浜松市であれこれソフトを開発している A.K.I Software のブログです。日々の開発日記やサーバー・セキュリティ関連の話題なども掲載。
<< 2024/04 >>123456789101112131415161718192021222324252627282930
《《《 ネットワーク機器の購入は Amazon で! 》》》
Powered by BLOM Android端末での BASIC認証後のダウンロード
小さくも大きくも閉じたりもしません
14/06/28 00:01 / 開発メモ

一つ前の記事で、Android端末で動画ファイルのダウンロードを行おうとすると、download Unsuccessfull となりダウンロードが失敗するのですが、自前HTTPサーバから通信ログを全て出力するようにして、きちんと確認してみた所、以下のような挙動を起すようです。(ある程度省略しています)

01) Connect from 192.168.1.1
02) Recv:GET /download?hogehoge.dat
03) Recv:Host: example.com:80
04) Recv:Connection: keep-alive
05) Recv:Referer: http://example.com/
06) Recv:Authorization: Basic xxxxxxxxxxxxxxxxxxxxx
07) Recv:Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
08) Recv:User-Agent: Mozilla/5.0 (略)
09) Recv:Accept-Encoding: gzip,deflate
10) Recv:Accept-Language: ja-JP, en-US
11) Recv:Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7
12) HTTP/1.1 200 OK
13) クライアント側から切断されました(10054)
14) Disconnect from 192.168.1.1
15) Connect from 192.168.1.1
16) Recv:GET /download?hogehoge.dat
17) Recv:Host: example.com:80
18) Recv:Connection: Keep-Alive
19) Recv:User-Agent: AndroidDownloadManager
20) HTTP/1.1 401 Unauthorized
21) Disconnect from 192.168.1.1

上から順に追ってみると

1) Android端末の Browser から接続。

2) GET で /download〜を指定

3〜5) 色々送信してくる。

6) BASIC認証を行う。BASIC認証は通過します。

7〜11) 色々送信してくる。

12) HTTPサーバから 200 OK を応答。

13〜14) Android端末の Browser 側から切断。

15) 即座に再接続してくる。

16) 2 と同じ URL を GET してくる。

17〜19) 色々送信してくる。

19 から AndroidDownloadManager が再接続していることがわかります。

20) 認証していないので当然サーバに弾かれます。

21) AndroidDownloadManager は速攻で諦めて切断。

AndroidDownloadManager は認証もなにもしないので、当然ダウンロードできません。
通常の Browser はいきなり認証をしてくるので、Browser 自身は HTTP認証のデータを持っているのですが、AndroidDownloadManager はそのデータにアクセスができない為(おそらくセキュリティの為でしょう。)認証が出来ずに終わるという仕組みのようです。
(それでもプロセス間通信(Androidアプリは殆どやっていないのですが、多分類似的な事はできるでしょう)や、401 応答したら Download Manager で再認証させれば良いのですが、それはやっていない or やらない。ようです)

解決するには・・・

a) BASIC認証をしない。

そのまんまですが、殆ど意味無いですね。

b) BASIC認証しないで、ワンクッションおいたり、Cookie などを使ってセッション管理を行う。

Expire を過去にしたりして、最初に認証した IP アドレスと時間を記録しておき、指定秒数以内であれば、認証を通過させるなどです。
色々と手法はありますが、まぁ普通のセッション管理です。
ワンタイムパスワードなどをサーバ側に記録しておいて、それをセッションIDとして使ってもいいですね。

おそらくですが、通常はこの2つの方法しか回避する策は無いと思います。

そして、行った対策は、折角独自の Web サーバを開発している訳ですので、Web サーバ自身に組み込んでしまいました(笑)

やっていることはセッション管理ですが、セッション管理自体を Web サーバ内に組み込んで、BASIC 又は Digest 認証を行ってから指定秒数以内は、同IPからの接続は認証を行わなくてもアクセスできるようにする仕組みです。

簡単に言えばサーバ内部で、認証の有無をセッションに従って動的に切り替えてしまう訳です。

セッションの生存時間は数秒ですが、理論上はセッションが生存している間に(IPパケットを偽装した上で)同一IPからアクセスがあった場合、認証を抜けてしまうセキュリティホールになりますが、現実的にはかなり難しいでしょう。

生存時間を長くすればするほど抜ける確立は高くなりますが、数秒の間ですし、そのタイミングを狙ってアクセスしたとしたら毎秒1回くらいのペースでアクセスをし続ける必要があります。
更に確実性を増すのならば、動的フィルタとかを導入して認証を一定回数失敗したら24時間接続を受け付けないなども導入すればより完全に近くなります。

まぁ、本来はこんなことせずに素直に Download Manager が認証してくれるとか、もしくは Download Manager を Disable にする設定があれば良いだけなんですけどねぇ。

[更新日付:2014/06/28 00:01:09]
トラックバックを見る(0)
Log Link [https://akisoftware.com/cgi-bin/blom.exe?akisoft+sl+d82921092bd43c16b58d992fd85da74850b70ab2]
TB Link [https://akisoftware.com/cgi-bin/blom.exe?akisoft+tb+d82921092bd43c16b58d992fd85da74850b70ab2]

記事へのコメント

コメントはありません

名前
コメントキー
 
コメントする時はキーを正確に入力して下さい
コメント
アドレスを含んだコメントはできません
© 2008-10 A.K.I Software all rights reserved.