タグ

securityとdevに関するgaeのブックマーク (12)

  • AndroidのWebView#addJavascriptInterfaceがどれだけ危険か検証してみた (Kanasansoft Web Lab.)

    Android SDKのJavaDocの説明はかなり簡素なんだけど、WebViewのaddJavascriptInterfaceの説明は珍しく説明が多い。 端的に意訳すると、「addJavascriptInterfaceを使うと、キミのアプリケーションをJavaScriptから操作できるようになるよ。とても便利な便利だけど、危険なセキュリティの問題があるよ。キミが書いたHTML以外では使わないでね。」という感じ。 「オブジェクトを公開する」行為が危険だというのは、技術者は直感的にわかると思うけど、じゃあどれくらい危険なのか実際に試してみた。 まず、次のようなAndroidアプリケーションを作った。 「android.permission.INTERNET」をパーミッションに指定して、WebViewを画面に設定し、後述するHTMLを開くようにした。 WebViewClientの説明は割愛。

  • 書籍「Android Security」の暗号鍵生成方法には課題がある - ockeghem's blog

    書籍「Android Security  安全なアプリケーションを作成するために」は既に各方面で絶賛されているように、Androidアプリケーションの開発者には必携の書籍だと思いますが、新しい分野だけに、首をひねらざるを得ない箇所もありました。このエントリでは、同書第10章「暗号化手法」から共通鍵の生成方法について議論します。 はじめに 書籍「Android Security」(業界では「タオ」と呼ばれているので、以下タオと記述)の10章では、端末内のファイルを暗号化して保存する手法について説明されています。その際に問題となるのが、鍵の生成と保管の方法です。スマートフォン端末、とくにAndroid端末は、アプリケーションのリバースエンジニアリングとルート化の可能性は常にあるため、あらゆる場合にも破られない暗号化というものはありません。このため、守るべき情報資産と、想定する脅威(言い換え

    書籍「Android Security」の暗号鍵生成方法には課題がある - ockeghem's blog
  • 【警告】ESファイルエクスプローラーでSDカードの中身が外部から見られてしまう恐れ【要検証】 - satoweb_log

    Android端末のファイルマネージャーとして 1・2を争うぐらい 便利に使える ESファイルマネージャーなのですが 特定条件で 外部からファイルが参照できてしまうようです。 事の発端はSGS2をいじっているときに ESファイルエクスプローラーの」NETタブでDropBOXをマウントし 音楽ファイルを再生すると ファイル名の欄に 127.0.0.1:~のアドレスが表示され 「もしかして ローカルに鯖たててる?!!!」 と  不安に思い検証してみました。 IPアドレスが 自宅Wifiで振られたIP ポート番号は 決め打ちです はい。。。 SDカードの中身がまるっと見えちゃいました。。。画像などもぜんぶ参照できちゃいます。 特定条件でしか発動しないとはいえどうなのよこの仕様。。。 Bloger的には画像が参照しやすくていいですが WANからも見れてしまう場合完全にセキュリティホール。 検証1:

  • サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会

    Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係

    サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
  • なぜiOSでUDIDが必要とされていたのか、メモ - snippets from shinichitomita’s journal

    iOSやその開発事情に詳しいと言える状態にはないので、調査を兼ねて書く。 Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID – TechCrunch http://wirelesswire.jp/Watching_World/201108221335.html 上記の「iOSでUDIDの利用が禁止」というニュースを聞いた時、正直TL上にこんなにいっぱい反応が貼り出されるとは思っていなかった。さすがにUDIDをいじるのはまずいよね、っていうコンセンサスは開発者の間では常識的部類に入ってくるのだろうと楽観的に捉えていたのかもしれない。 以下、なぜUDIDがそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。 アプリケーションのサーバとのセッション保持 い

    なぜiOSでUDIDが必要とされていたのか、メモ - snippets from shinichitomita’s journal
  • 私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか - ockeghem's blog

    昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方(この方)から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました(参考のやりとり)。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip

    私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか - ockeghem's blog
  • ダウンロードが少ないファイルは警告を出すIE9 - kkamegawa's weblog

    ちょっととある方のコメントを書く前に自分でもダウンロードしてみようかと思って、Microsoftが運営するcode gallaryのページからファイルをダウンロードすると、IE9がこんな警告を出しました。 たぶんSmart Screenとかの機能だと思いますが、ダウンロードが少ないから安心じゃないって…うーん、わからないではないですが、そういうものなんでしょうか(^^;。

    ダウンロードが少ないファイルは警告を出すIE9 - kkamegawa's weblog
    gae
    gae 2011/05/02
    面白いなぁ
  • スマートフォンで「できちゃうこと」って?

    スマートフォンで「できちゃうこと」って?:イチから始める! Androidセキュリティ(1)(1/3 ページ) 「もいちどイチから! HTTP基礎訓練中」でWebアプリケーションの脆弱性と対策について学んだクウが、今度はAndroidの世界に挑戦。Android特有の問題、PCや従来の携帯電話向けのWebアプリとの違いや対策について紹介します。(編集部) やっぱ時代はスマートフォンだよね? クウはベンチャー企業で働くエンジニア。同僚のユウヤや開発チームのリーダー、ナツさんと一緒にWebアプリケーションの開発に携わる傍ら、勉強会に顔を出してはWebアプリのセキュリティについて知識をためてきた。そんな彼が次に興味を持ったのは……。 クウ 「Androidアプリできたよー♪」 ユウヤ 「ん? なんでそんなん作ってんの?」 クウ 「お勉強のために自分で作ったのだ♪ いまどきは、スマートフォン向けア

    スマートフォンで「できちゃうこと」って?
  • 『まあぶっちゃけ』

    Amebaのセキュリティ対策について|スタッフブログアメブロまわりを数分程度ざざっと眺めただけでも、 いたるところでCSRFの対策が入ってないようなんだけど、 この規模のサービスなら、いちおうそれなりにやっておいた方が…。 たぶん現状だと脆弱性をひとつひとつどこかに報告するとかっていうレベルじゃないです…。 (これらをセキュリティホールと呼ぶのか仕様と呼ぶのかは知らないけど…) [» この日記のブックマークコメントを見る/書く ]

    『まあぶっちゃけ』
  • IE 8でセキュリティ機能のデフォルト設定が変更に

    IE 7ではデフォルトでオフになっていたセキュリティ機能のDEPとNXが、Windows VistaとWindows Server 2008上のIE 8ではデフォルトでオンになる。 MicrosoftはInternet Explorer(IE)の主要なデフォルト設定を変更し、ハッキングしようとする攻撃者を阻止する計画だ。 Microsoftは、Windows VistaとWindows Server 2008で稼働するIE 8では、データ実行防止(DEP:Data Execution Prevention)と非実行ページ保護(NX:No eXecute)機能をデフォルトでオンにする。これは、ブラウザの脆弱性を軽減するための大きな変更だ。 DEPとNX(以下DEP・NXと表記)はIE 7で既に備わっていたが、後方互換性を保つためにデフォルトでオフになっていた。 このデフォルト設定の変更によっ

    IE 8でセキュリティ機能のデフォルト設定が変更に
  • フィードリーダーの脆弱性まわりのこと

    最近、FreshReaderに脆弱性があったということで、いくつか調べて直したり、赤松さんと連絡取り合ったり、それからはてな使ってないのにユーザー様とか書かれて不愉快な気分になったりしてたんですが。 この記事はひどすぎると思う。 フレッシュリーダーの脆弱性に関連してSage++のこと そもそもの問題として「ローカルディスク上のHTMLファイルをブラウザで開くと超危険」です。XMLHttpRequestやIFRAMEでローカルファイルの内容を読み取れるからです。Sageに脆弱性があるということは、あらゆる個人情報の漏洩につながります。「開発者の個人情報を晒すリスクが云々」というのは、個人的には分からなくもないですが、ユーザーの個人情報を危険に晒していることを認識すべきです。 開発者人が過去に書いているので、危険性の大きさは十分に認識できているはずです。「脆弱性がある」と公表してしまった時点

  • それ Unicode で

    UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。

  • 1