タグ

securityとWebに関するf99aqのブックマーク (23)

  • Protecting Against HSTS Abuse

    HTTP Strict Transport Security (HSTS) is a security standard that provides a mechanism for web sites to declare themselves accessible only via secure connections, and to tell web browsers where to go to get that secure version. Web browsers that honor the HSTS standard also prevent users from ignoring server certificate errors. Apple uses HSTS on iCloud.com, for example, so that any time a visitor

    Protecting Against HSTS Abuse
  • HTTPS 化する Web をどう考えるか - Block Rockin’ Codes

    Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である

  • エフセキュアブログ : 管理者達へ:Heartbleedの修正するときに設定基準を見直そう

    管理者達へ:Heartbleedの修正するときに設定基準を見直そう 2014年04月09日18:39 ツイート fsecure_corporation ヘルシンキ発  by:ジャルノ・ネメラ とにかくSSLの更新は必要なので、設定が最近の基準に沿っているかについても確認しようではないか。 Heartbleedについてたくさんの大騒ぎがあったから、管理者ならすでに何をすべきか知っているだろう。 1. 脆弱なバージョンのOpenSSLを使っているものをすべて特定する 2. 最新バージョンのOpenSSLに更新する 3. 古いプライベートキーとSSL証明書は漏えいした可能性があるので、新しいものを作成する 4. 古い証明書を失効にする だがサーバの設定を触って、新しいSSL証明書を作成しなければならないのなら、証明書生成の設定やサーバの設定にも手を伸ばすことをお勧めする。HeartbleedはS

    エフセキュアブログ : 管理者達へ:Heartbleedの修正するときに設定基準を見直そう
  • HTTPSを使ってもCookieの改変は防げないことを実験で試してみた

    寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP(アクセスポイント)があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します(Secure属性使うと盗聴は防げますが、改変は防げません)。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe

    HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
  • [デブサミ関西2013] JavaScript Security beyond HTML5

    [デブサミ関西2013] JavaScript Security beyond HTML5 Presentation Transcript JavaScript Security beyond HTML5 ネットエージェント株式会社 長谷川陽介 Developers Summit 2013 Kansai Action! #kansumiB5 NetAgent http://www.netagent.co.jp/Developers Summit 2013 Kansai Action! #kansumiB5 自己紹介 長谷川陽介 - はせがわようすけ  ネットエージェント株式会社  株式会社セキュアスカイ・テクノロジー 技術顧問  セキュリティ・キャンプ Webセキュリティクラス講師  Microsoft MVP for Consumer Security Oct 2005 - 

  • Masato Kinugawa Security Blog: location.hrefの盲点

    夏ということで、怖い話をします。 Webアプリケーション開発者の皆さん、聞いて下さい。 時間がない人や、他の人に問題を説明するときなどには簡潔にまとめた版をどうぞ。 これは2011年12月27日にAppleに報告したSafariの問題です。Appleからは修正する予定はないという回答を貰っていましたが、2012年7月25日にリリースされたMacのSafari 6のアドバイザリによるとどうもMacのSafari 6では修正されたようです。 About the security content of Safari 6 http://support.apple.com/kb/HT5400 WebKit Available for: OS X Lion v10.7.4, OS X Lion Server v10.7.4 Impact: Visiting a maliciously crafted

  • CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん!

    こんにちはこんにちは!! 今日はCSRF脆弱性のちょっとした話です! このCSRFってなにかっていうと、 サーバーへのリクエストを『誰かに勝手に送らせる』っていうセキュリティがらみの攻撃手法のひとつ。 わかりやすい例だと、 HTMLの画像タグを以下のようにしたページを誰かに教える。 <img src="何々SNSの足跡.php" width="1" height="1"> そうすると、そのページを「見た人」が何々SNSの足跡.phpにアクセスしたことになる。 ※詳しくはこちらのマンガで → [はまちちゃんのセキュリティ講座]ここがキミの脆弱なところ…! : 第2回 しーさーふって何ですか? CSRFってこんな風に、 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対

    CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん!
  • SSL/TLSの脆弱性を攻撃する”BEAST”を防ぐ修正をChromeが追加 - うさぎ文学日記

    今週のEkoparty security conference で発表される予定の、SSL/TLSによる暗号化の脆弱性を攻撃するPoC ”BEAST”の攻撃からの防御策をChromeブラウザが搭載するようです。 GoogleChromeブラウザのアップデートの準備が完了しているようで、すでに開発者バージョンには追加済みとのこと。 Google preps Chrome fix to slay SSL-attacking BEAST • The Register BEASTは、SSLやTLSに対してAES暗号に対する選択平文攻撃を仕掛けます。前の平文ブロックを暗号化した結果を、次のブロックの平文にXOR演算して、その結果に対して暗号化を行う”暗号文ブロック連鎖モード(CBC:Cipher Block Chaining)”に対しての攻撃のようです。 Chromeはこの攻撃を防ぐために攻撃者が

    SSL/TLSの脆弱性を攻撃する”BEAST”を防ぐ修正をChromeが追加 - うさぎ文学日記
    f99aq
    f99aq 2011/09/22
    「”暗号文ブロック連鎖モード(CBC:Cipher Block Chaining)”に対しての攻撃のようです。」
  • yebo blog: TLS 1.0に深刻な弱点が見付かる

    2011/09/20 TLS 1.0に深刻な弱点が見付かる セキュリティ研究者のThai Duong氏とJuliano Rizzo氏は、TLS 1.0/SSL 3.0を使っているウェブサイトで、攻撃者にエンドユーザとウェブサイト間に流れるデータを気付かれずに復号化できるという深刻な弱点を発表するそうだ。今のところ、TLS 1.1や1.2は影響はないとのこと。今週、ブエノスアイレスで開催されるekopartyセキュリティ会議で、両氏はBEAST (Browser Exploit Against SSL/TLS)と呼ばれるコードでそのデモを行うそうだ(デモは23日)。Duong氏は、デモではPayPalアカウントにアクセスするために使われる認証用のcookieを復号化すると語っている。このBEASTは、標的となるブラウザにBEASTのクライアント側のJavaScriptコードを埋め込み、中間(

  • PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記

    昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します(同書P20の図1-23)。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成(エンコード)に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常

    PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記
  • mixi足あと廃止に寄せて - 最速転職研究会 | コメント mixiって今ほとんどがモバイルでアクセスされてたはずだけど、スマホ以外のガラケーでもこの問題が起きるの?

    mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後) アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。 過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。 http://internet.kil

    mixi足あと廃止に寄せて - 最速転職研究会 | コメント mixiって今ほとんどがモバイルでアクセスされてたはずだけど、スマホ以外のガラケーでもこの問題が起きるの?
  • iOSのTwitter統合とAndroidのAccountManager、そしてBrowserIDに見るUser-Centric Identityの再来?について - snippets from shinichitomita’s journal

    最近、自分自身のテクノロジー的な世界観に対して影響を与える刺激がいろいろとあったわけだけど、その中におぼろげながら共通点が感じられたので、最初はGoogle+にLimitedなメモとして書いたのだが、ブログの方に清書する。 - 最初のきっかけは、AppleのiOS5へTwitter APIが組み込まれる、というニュースだった。それはTwitterサービスにiOSの提供するAPIを通してアクセスでき、その際の認証はOSが代行してくれる、というものだ。それが基調講演で発表された時には「なんでそこにOSが絡まなきゃいけないのか、オープンスタンダードなやり方があるのだからいいじゃないか」という理由で否定的に受け取ったわけだけども、よくよく考えてみれば位置情報でもストレージでも、リソースへのアクセス許可に対して承認許可ダイアログをOSが出しているわけだし、それがWebサービスでもまあありかもな、と考

    iOSのTwitter統合とAndroidのAccountManager、そしてBrowserIDに見るUser-Centric Identityの再来?について - snippets from shinichitomita’s journal
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記

    最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty

    1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記
  • 他人のCookieを操作する - T.Teradaの日記

    脆弱性検査をしていてしばしば出くわすのは、他人のCookieの値を操作できるとXSSやセッション固定等の攻撃が成功するようなWebアプリケーションです。 このようなアプリがあると、業界的には「Cookie Monsterという問題がありまして、、、でも、、、基的に現状のブラウザではリスクは低いです」みたいな話がされることが多いのではないかと思います。 日の日記では、それ(Cookie Monster)以外にも状況によっては考慮すべきことがある、という話をしたいと思います(過去の日記でも少し書いた話ですが、もう少しちゃんと書いておこうと思います)。 通信経路上に攻撃者がいる 被害者のブラウザとサーバの通信経路上に、アクティブな攻撃者がいると想定しましょう。 そのような状況では、攻撃者は正規のサーバになりかわってブラウザと通信をしたり、ブラウザと正規のサーバで交わされる通信に介入することが

    他人のCookieを操作する - T.Teradaの日記
  • Google Code Archive - Long-term storage for Google Code Project Hosting.

    Code Archive Skip to content Google About Google Privacy Terms

  • OBB vs AABB - Radium Software Development

    iPhoneの一般修理店は予約なしでも来店できる? 基的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、

  • インターネットカフェからmixiをするときの注意点:キーロガー対策

    漫画喫茶やインターネットカフェなどから、読書やオンラインゲームをしながらmixiに入ることもあるだろう。 だが、家にいるときと同じようにしていないだろうか? もしそうなら危険すぎるので止めたほうがいい。 少なくともわたしはネットカフェからmixiするとき、以下をするようにしている。 キーロガー対策 キーロガーとは、パソコンのキーボードからのキーストローク情報を記録するソフトウェア、またはハードウェアのことだ。 近年、インターネットカフェなど不特定多数のユーザが使うPCにインストールされ、口座の暗証番号やパスワードなどが盗まれて現金を引き出されるといった被害が発生している。 mixiに入るときはメールとパスワードを聞かれるわけだが、そのまま入力しているとキーロガーなどが仕掛けられている場合アウトだ。 それでログインされると成りすまされ何をされるか分からない。 もし、プロフィールに個人情報を

    f99aq
    f99aq 2006/06/20
    そんなにやりたいなら携帯を使いなされ
  • yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須

    (Last Updated On: 2016年3月3日)最近PostgreSQLMySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考:セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQLMySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト~6バイト必要なのか

    yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須