At WWDC 2024, Apple introduced new options for developers to promote their apps and earn more from them in the App Store.
![TechCrunch | Startup and Technology News](https://cdn-ak-scissors.b.st-hatena.com/image/square/92584d6251feb0822f349cf0211361b2833c9939/height=288;version=1;width=512/https%3A%2F%2Ftechcrunch.com%2Fwp-content%2Fuploads%2F2018%2F04%2Ftc-logo-2018-square-reverse2x.png)
Dropbox Lack of Security - Miguel de Icaza ワタシはクラウドストレージサービス Dropbox のサービス利用者というだけでなく彼らのファンと言ってよい。 その彼らがセキュリティポリシーを改訂した。要点を一文で言うなら、「なにかあったらユーザーのデータを復号して当局に提出するのでよろしく!」ということになるのだが、Miguel de Icaza はそれは自分にとって問題ではないと言う。 それでは何が問題か? それは、Dropbox に預けられたファイルは、ファイル転送通信は SSL、サーバ上のファイルは256ビット AES で暗号化され、社員はそのメタデータにしかアクセスできないので、Dropbox の内部者にも見られないように暗号化されているという主張が、今回のポリシー改訂によりはじめからウソだったと露見したことだと言う。 結局、Dropbox
このエントリでは、evernoteクライアントを使って、evernote社にも復号できない状態でテキストを暗号化する方法について紹介します。 昨日、EvernoteのXSS問題に関連して、「Evernoteの開発者も徳丸本読んでいたらよかったのにね」などとつぶやいていたら、「EvernoteのCEOが徳丸さんに会いたがっている」という連絡をもらいました。こういうのは異例のことでちょっと悩みましたが、行くっきゃないだろうということで、Evernote社の日本法人でmalaさんと一緒にCEOにお会いしました。 XSSやポリシーについては非常に誠実な対応をお約束いただいたのでよいミーティングだったと思います。僕が指摘した脆弱性についても、当日の夜のうちに直っていたようです。米国時間では深夜から早朝という時間帯で、迅速な対応だったと思いますが、本題はこれからです。 その場で、malaさんが「Eve
Evernoteに任意のHTMLを注入できる脆弱性がありました。 http://togetter.com/li/125281 Evernoteのセキュリティポリシーとかには触れず、とりあえず何が可能だったのか、どういう状況だったのかを書きます。 4/18 16時ごろ Evernoteの登録ページのHTMLに以下のような記述があります。 <script type="text/javascript"> $(document).ready(function() { suggestedTags = []; suggestedNotebook = ""; sourceUrl = ""; providerName = ""; payload = { "user" : { ... }, ..後略.. </script> このsourceUrl = ""の部分、https://www.evernote.c
要するに、解決されるまではログアウトしとけということだそうデス。 【2011/04/20 12:20 追記】ひゃっはー的なおまけを追加しました。 【2011/04/20 00:30 追記】多分これで最後。以降は Evernote の正式発表を待った上で、それを信用して利用するかどうかは各個人の判断にお任せします。 【2011/04/19 17:05 追記】午後の部追記。なお、エントリを起こされている方がおりましたのでご紹介。>『bulkneets氏によって報告されたEvernoteのXSS脆弱性とは 危険と対策』( http://d.hatena.ne.jp/pichikupachiku/20110419/1303158373 ) 続きを読む
IPの実装におけるサービス運用妨害(DoS)の脆弱性について ヤマハルーターシリーズのIPの実装に脆弱性が存在することが分かりました。対象となる機種及び対策方法につきましては下記をご確認いただき、必要な場合には対策を行ってください。 脆弱性とその概要 JVN#55714408 ヤマハルーターシリーズのInternet Protocol (IP) の実装には、不正なIPヘッダオプションを処理することに起因するサービス運用妨害 (DoS) の脆弱性が存在します。 IPヘッダの特定箇所に不正な値が挿入されていると不正なメモリ領域を参照してしまうため、場合によってはリブートすることがあります。 なお本脆弱性は、ルーターに直結されたPCからの攻撃に対しては成立する可能性がありますが、インターネット経由での攻撃に対して成立する可能性は低いと判断しております。具体的な理由につきましては「インターネット経
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Reach out to get featured—contact us to send your exclusive story idea, research, hacks, or ask us a question or leave a comment/feedback!
補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています(同書P338)。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
最近TL上で「新しいタイプのSQLインジェクション攻撃」というキーワードを見かけます。情報元をたどっていくとどうやらこの攻撃は「LizaMoon(ライザムーン)攻撃」という名称の模様。攻撃で用いられた手法があまりないパターンであったということでどういうものか調べてみました。 (1) LizaMoon攻撃とは何か 先月末、3/29にwebSenceのBlogに「新しい悪意ある大規模なインジェクションが行われた」として、次のポストが行われました。 Websense Security Labs and the Websense Threatseeker Network have identified a new malicious mass-injection campaign that we call LizaMoon. Websense customers are protected wit
あんまりにもひどいなぁ、と思うので、エントリーとして書いておく。 さくらのVPSでサーバ立てたのは、既に書いたとおりなのだけど、iptablesでパケットフィルタリングかけて、fwanalogでその状況をチェックしていると、大量のUDPパケットをブロックしているのがわかったので、ちょっと調べてみたらところ、 i wondering about the broadcast on port 17500 (udp) in our network. Why broadcasting on udp 17500? « Dropbox Forums どうやら、Dropboxが同一LAN内にいるDorpboxとのsyncをするために、ブロードキャストに向けてUDPパケットをバラ撒いて、その存在を見つけようとしているらしい・・・。 「適当なサーバにDorpbox入れておけば、外出先でも自宅でも会社でも、ネッ
前回半分くらい読んで積読になってしまっていた「徳丸本」こと「安全な Web アプリケーションの作り方」を週末に読みきりました。本当にいい教科書だと思いますので、脱初心者を目指す人は読んでみると良いと思います。 特に今までぼんやりとしか理解していなかった「パスワード管理」について非常に体系的に分かりやすく説明されていたので、せっかくなので Plack アプリで実装してみました。ソースは gist に貼っておきました。 基本的には徳丸本にあったとおりに実装しています。 パスワードはハッシュをかけた値を DB に保存 但し単純なハッシュ関数だと漏洩したときにクラックされる(=逆方向に解析される) そこで 2 つの対策を組み合わせる salt 値 user_id と固定値を利用して salt 値を作りパスワードに付加してハッシュを取る もし同じパスワードのユーザがいてもハッシュ値は異なる ストレッ
--------------------------------------------------------------------- ■qmail/netqmailにおける512バイトを超えるDNS応答の不適切な取り扱いについて 株式会社日本レジストリサービス(JPRS) 2011/03/03(Thu) --------------------------------------------------------------------- ▼背景 伝統的なDNSの仕様では、通信プロトコルとしてUDPを用いる場合のDNS応答 のサイズを512バイト以下に制限しています。DNSにおいて512バイトを超え る応答を取り扱う必要がある場合、通信プロトコルとしてTCPを使用するか、 RFC 2671で定められた拡張機能であるEDNS0を使用します。 そのうち、TCPの使用は従来からあるDNS
cles::blog 平常心是道 blogs: cles::blog NP_cles() « Android版ノートンが正式版に :: 家賃の更新料の是非が決着するらしい » 2011/03/04 qmail に DNS 用のパッチあたってますか? qmail jprs 26 2へぇ JPRS から qmail が DNS の応答サイズが大きい場合にうまく取り扱えない問題についてのお知らせが出ていたのでメモ。 qmail/netqmailにおける512バイトを超えるDNS応答の不適切な取り扱いについて*1 近年、DNSSECの本格運用開始やIPv6、SPFなどの技術の普及により、DNS応答のサイズが増大する傾向にあります。これにより、これまで潜在していた512バイトを超えるDNS応答の不適切な取り扱いが顕在化し、予期しない障害が発生する場合があります。 現時点において、メール配送ソフト
今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く