A brief explanation of spectre(variant 1) and Meltdown(variant 3)
図解でわかるSpectreとMeltdown
A brief explanation of spectre(variant 1) and Meltdown(variant 3)
「クロスサイトスクリプティング対策」でGoogle検索して上位15記事を検証した
昨年の11月にブログエントリ『「SQLインジェクション対策」でGoogle検索して上位15記事を検証した』という記事を書いたところ、非常に好評で、「次はXSSについて書いてください」という要望をいただいておりました。中々XSSについては手がついておりませんでしたが、ようやく書いてみました。以下のURLで検索した結果の上位15位の記事を検証しました。 http://www.google.co.jp/search?q=クロスサイトスクリプティング対策&pws=0 検索結果は変動するため、私が検索した際の結果をEvernoteの公開ノートとして記録しています。 1～10位 11～20位 記事の「正しさ」の検証基準としては、IPAの「安全なウェブサイトの作り方改訂第5版」を参考に、最低限として以下が記述されているかどうかを確認しました。 HTMLのエスケープ処理を行う 属性値はダブルクォートで囲む
ミクシィのアプリケーションセキュリティの代表的な取り組みについて - mixi engineer blog
こんにちは、opera 大好き 松岡 剛志 です。今日は部長職ではなくて、セキュリティチームリーダー立場でブログを書いています。 今回は弊社の様々なアプリケーションセキュリティの取り組みのうち、以下の4つのコンテンツについて書きます。この内容はほとんどが弊社のセキュリティイベントである Scrap Challenge で使われたスライドの焼き直しです。 トレーニング セキュリティレビュー コードレビュー セキュリティチェック トレーニング 現在ミクシィでは新卒エンジニアに対して1カ月程度の缶詰の教育を行っています。そのコンセプトは以下です。 関係各所、チーム、チーム横断でのタスクに関して 迷惑をかけずに自分で判断できる/あるいは正しく判断を仰げる状態までの成長。 現状の技術的問題点や課題を把握し、改善策や改善のためのプランニングができる。 各項目への知識体系の羅針盤を提供して、自学自習によ
Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策
28C3(28th Chaos Communication Congress)において、Effective Denial of Service attacks against web application platforms（Webプラットフォームに対する効果的なサービス妨害攻撃）と題する発表がありました（タイムスケジュール、講演スライド）。 これによると、PHPをはじめとする多くのWebアプリケーション開発プラットフォームに対して、CPU資源を枯渇させるサービス妨害攻撃(DoS攻撃)が可能な手法が見つかったということです。この攻撃は、hashdos と呼ばれています。 概要PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。 連想配列の実装には
ハッキング(笑)の研究してるけれど質問ある？ - ゴールデンタイムズ
1 ：以下、名無しにかわりましてVIPがお送りします ：2011/11/09(水) 07:52:02.95 ID:ULW0dTK40 はいはい厨二厨二 10 ：以下、名無しにかわりましてVIPがお送りします ：2011/11/09(水) 07:56:49.53 ID:rAyb58Mj0 大学の研究？ 19 ：以下、名無しにかわりましてVIPがお送りします ：2011/11/09(水) 08:03:18.20 ID:ULW0dTK40 >>10 大学の特別研究員もやってるけれど、今はメインは自宅研究員ですお 3 ： 忍法帖【Lv=40,xxxPT】 ：2011/11/09(水) 07:53:09.89 ID:WgNHOLRk0 レインボーアタックについて分かりやすく教えて 7 ：以下、名無しにかわりましてVIPがお送りします ：2011/11/09(水) 07:55:28.35 I
高木浩光＠自宅の日記 - テレビ録画機「トルネ」の視聴ジャンルが無断公開されている
■ 何が個人情報なのか履き違えている日本 昨日の日記の件、みなさんからの声により、PlayStation 3をテレビ録画機にする製品「トルネ」についても同じ問題があり、どんなジャンルの番組をよく視聴しているかや、視聴時刻までもが公開状態になっていることが判明した。これについては後述する。 それより先に今言いたいのは、こういうことが起きるのは、何が「個人情報」なのかを、日本の事業者や行政がみんな揃って履き違えているためではないかということだ。 今回の件について、ソニーはこう釈明するかもしれない。「オンラインIDは個人情報に該当しない。オンラインIDに氏名などの個人情報を含めないよう登録画面で注意書きしている*1」と。しかしそういう問題でないのは明らかである。 日本の事業者はどこもかしこも、「個人情報」に該当しなければ何をやってもいいという誤った道に進み始めている。そして、日本の個人情報保護法
スマホアプリとプライバシーの「越えてはいけない一線」 － ＠IT
スマートフォンアプリは果たしてどこまで、端末に関する情報を取得してもいいのだろうか。 位置情報と連動してお勧め店舗情報を表示したり、過去の検索履歴を基に商品を提案したりと、端末の情報やユーザーの行動履歴を活用するスマートフォンアプリが登場している。中には便利なものも多いが、一歩間違えれば、ユーザーのプライベートな情報が筒抜けになりかねない。結果として、スマートフォンを活用したビジネスやそれを支える広告市場までもが、否定的な目で見られ、発展を阻害される恐れもある。 この議論が起こったきっかけの1つは、ミログが公開していた「AppLog」と「app.tv」というアプリだ。AppLogはSDKの形で提供され、これを自前のアプリに組み込むと、Android端末にインストールされているアプリの情報やその起動回数を収集し、同社のアプリケーション分析サービスに送信するようになっていた。開発者にはインスト
Webアプリでパスワード保護はどこまでやればいいか
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
昨今の学校のセキュリティ事情【第一章 学校のPC(生徒使用PC)について】 - toriimiyukkiの日記
昨今における学校のセキュリティ事情についてこの回を含めて全4話構成で話そうと思います。 0話から4話含めて、学校のPCにおける話から学校のWebサイトにおけるセキュリティまでをお話しします。 次のような話構成で進めていきたいと思います。 第一章 学校のPC(生徒使用PC)について 第二章 学校のWebサイトについて-SQLインジェクション 第三章 学校のWebサイトについて-コマンドインジェクション/その他 第四章 昨今の学校のセキュリティ事情のまとめ ここでやっていることはかなり危険な部類も入っています。 真似しないようにお願いします。また、この記事によっていかなる損害が発生してもその責任を負いません。 この記事によって自分のサービスのセキュリティを再認識してもらえばと思います。 第一章 学校のPC(生徒使用PC)について 学校のPCについては誰もが一回はいたずらをしたくなるだろう。 も
Apache killerは危険～Apache killerを評価する上での注意～
Apacheの脆弱性(CVE-2011-3192)いわゆるApache killerが話題になっていますが、その脅威については一部誤解があるようです。 以下は、非常に脅威とする報告の例です。 一方今回のはプロセスの肥大化を伴うので、実メモリ消費して更にスワップも使い尽くしてOS毎激重になったあげくLinuxとかの場合はOOM Killer発動と、他のプロセスや場合によってはOSを巻き込んで逝ってしまいます。 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.xより引用 以下は、それほど脅威でなかったとする報告の例です。 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 Apache Killer (CVE-2011-3192) 対策 for CentOS 5
UDIDが使えなくなりそうなので、UIIDを使えるようにしました
■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c
Rails 3.0.4と2.3.11からXHRリクエストの際もCSRFトークンの検証が必須になったので注意 - YomuKaku Memo
Rails 3.0.4と2.3.11がリリースされました。重要なセキュリティ対策のリリースのようです。 最も大きな変更点はCSRF対策強化で、この結果として、AJAXのために従来使用していたJavaScriptのコードでは、get以外のメソッドの部分が動作しなくなるため、当該箇所の修正が必要になります。 RailsではCSRFの防止にトークンが用いられています。Rails 3.0.3以前はAjaxのXHRリクエストではCSRFが起こりえないという前提でトークンの検証を行わないようになっていましたが、FlashやJava appletを利用した場合にcsrfが起こる可能性があるとのことで、Rails 3.0.4（およびRails 2系のRails 2.3.11）ではXHRリクエストの場合もトークンの検証を行うように変更されたようです。 したがって、Rails 3.0.4（およびRails 2
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
WEBプログラマー必見！WEB脆弱性基礎知識最速マスター - 燈明日記
以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。 WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。 また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。 WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。 そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。 今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。 このまとめがWEBアプリケーション開発の参考になれば幸いです。 インジェクション クロスサイト・スクリプティング セッション・ハイジャック アクセス制御や認可制御の欠落 ディレクトリ・トラバーサル(Directory Traversal) CSRF（
知らなかったらNGなWEBアプリケーション脆弱性一覧 : mwSoft blog
先日、AmebaなうがCSRFという非常にポピュラーな脆弱性を披露したかと思ったら、ここ数日はセブンネットショッピングでXSSの脆弱性と、ID推測による他ユーザの個人情報閲覧の問題が発生しているという噂が流れています。 ユーザの情報を預かっておきながら、基本的なセキュリティの対策もできていないというのは、銀行に例えるなら、お金を預けようとした時に「お金は預かります。ちゃんと保管します。でも警備はあまりしないので盗まれたらスイマセン」と言われるようなものだと思う。 警備に穴があったというのではなく、まともに警備してませんでした、というのはさすがにありえないことです。 そこで、野良WEBプログラマである私が知っている脆弱性を列挙してみた。 私はプログラマであってセキュリティの専門家ではないです。しかも今年の春辺りからずっと外向けのWEBプログラムは組んでません。 その人間が知っているものを並べ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.monoweb.info/article/2012021823.html
http://www.machu.jp/posts/20090801/p01/
YAPC::Asia Tokyo 2011 - Webアプリでパスワード保護はどこまでやればいいか
紙だけでサイトごとに異なるパスワードを生成する暗号、米研究者が考案 
Research