Hatena::Diary - スーパpre記法で実行可能なJavaScriptを : 404 Blog Not Found
2007年05月06日18:45 カテゴリLightweight LanguagesBlogosphere Hatena::Diary - スーパpre記法で実行可能なJavaScriptを そのはてなダイアリーで、こうすれば比較的安全に実行可能なJavaScriptを記述できるのではないかという提案。 404 Blog Not Found:javascript - はてダでは書けないはてなブックマーク技25個 こういう技の紹介って、JSがあればもっとわかりやすいんだけどはてダはJS禁なので。 はてなアイデア - スーパpre記法で実行可能なJavaScriptを投稿できるようにしてほしい cf. http://blog.livedoor.jp/dankogai/archives/50824976.html レシピ まずは、スーパーpre記法を以下のように拡張。 はてなダイアリーのヘルプ
当社のサイトにおける不正コード混入ページ公開について ご報告と対処のお願い - 会社・事業紹介
アイティメディア株式会社 代表取締役社長 大槻利樹 このたび、当社が運営するIT総合情報ポータル「ITmedia」の公開準備サーバ上のファイルが不正侵入によって書き換えられ、不正なコードを含むページが利用者に公開されるという事態が発生しました。 書き換えられたページ及び掲載時期 「ITmedia Biz.ID」トップページ （ http://www.itmedia.co.jp/bizid/index.html ） 「TechTargetジャパン」Webキャストページ （ http://techtarget.itmedia.co.jp/tt/webcast/index.html ） 「ITmediaメールマガジン」ご案内ページ （ http://www.itmedia.co.jp/mailmag/index.html ） 2007年4月27日18時から5月1日13時までの期間中、上記ページに
Kazuho@Cybozu Labs: 安全な JSON, 危険な JSON (Cross-site Including?)
« クロスサイトのセキュリティモデル | メイン | E4X-XSS 脆弱性について » 2007年01月06日 安全な JSON, 危険な JSON (Cross-site Including?) 先のエントリで、 JSON については、JavaScript として副作用をもたない (もたせようがない) ゆえに文法違反であるがゆえに、秘密情報を含むデータフォーマットとして使用することができるのです。 (Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル) と書いたのですが、認識が甘かったようです。Jeremiah Grossman: Advanced Web Attack Techniques using GMail によると、配列の初期化演算子 [] の動作を外部から変更することができる注1とのこと。 実際に手元の Firefox 1.5 で試してみたところ、JS
2007-03-15
はてなサーバーへの不正な侵入について2 昨日報告いたしました弊社サーバーへの不正侵入につきまして、その後詳細な調査を行いましたところ、昨日報告した2台のサーバーに加えて、昨日の侵入対策の際に構成を変更したホストにもセキュリティ設定の不備があり、もう一台はてなサーバー群の入り口にあたるホストへの侵入が行われていたことが判りました。 現在は当該ホストも昨日の対応に同じく不正アクセスを遮断、ネットワークから隔離し別サーバーでリプレイスする作業を完了しております。 調査の結果、侵入方法、侵入経路ならびに被害は昨日のものと同様でした。そのため、データベース上のユーザー情報、皆様にご利用いただいているサービスのデータが取得/改竄された可能性は低いと考えております。 今回の不正侵入を受けて本日弊社社内にて協議検討を行い、管理体制とセキュリティポリシーの見直し並びに監視体制の強化、新たに監視システムの開発
機能変更、お知らせなど - はてなの日記 - はてなサーバーへの不正な侵入について
はてなサーバーへの不正な侵入について 本日、はてなのサービスを提供する2台のサーバーに、先週金曜日より不正な侵入が行われていたことが判明しました。 はてなでは本日午前4時頃にこの事実を認識し、午前6時頃に不正なアクセスの遮断を行いました。また、現在継続的に詳細な調査、対策を行っております。 今回の不正侵入は、はてなサーバー群の入り口に当たるサーバーのうちの2台に対して、サーバーのログイン情報を機械的に総当たりする方法によって行われました。不正侵入に成功したアカウントにより、ftp scanner, irc botプログラムが設置され、外部に対して実行されるという被害が発生しました。 はてなではさらに、内部に存在するデータベースサーバーなどへのアクセスの形跡などについて調査を行いましたが、これらの形跡は発見されておらず、データベース上のユーザー情報が取得されたり、皆様にご利用いただいているサ
アップロード可能掲示板（いわゆるあぷろだ、ファイル置き場）を設置していると、誰かが著作権法違反をする以外にも犯罪に巻き込まれてサーバを押収されることがある - 駄文待避所
(2.27追記) 当時の状況が少し分かりました。2.27の記事もご覧ください。画像をちょっと貼られたくらい、という認識は激甘でした。 (2.26追記) 以下の文章は2007/2/24に書いたものでありますが、当日の動揺と、自分のミスを認めたくない気持ちが入り混じって不正確、不明瞭な点があります。管理が行き届いていない自宅サーバの危険性と、アップローダーを放置することの危険性についても混ざってしまっているので追記により修正する予定です。消すことはしません。 これを読んだ自宅サーバーを立てている人、ファイルアップローダーを設置している人は今すぐ自分の管理状況を見なおしてください。お願いします。 家宅捜索されました。マジに。 結論からいうと、自分がある2chのスレのために3年前くらいに自宅サーバに提供していたあぷろだに、海外で不正アクセス事犯で捕まった被疑者が何かの画像（恐らくイスラム教関係、ら
Norton AntiVirus、Wikiをウイルスと誤認して全削除
アンチウイルスソフトとして世界的に有名なNortonシリーズですが、先月末の2月28日に行われたアップデートの際に何をドコでどう間違ったのか、「TiddlyWiki」というWikiソフトのデータを「W32.Feebs」というウイルスと誤認し、全データを削除するという事件が世界中で発生。データを失った「TiddlyWiki」ユーザーが続出しているようです。 詳細は以下の通り。 これが公式サイト。トップページに告知が出ています。 TiddlyWiki - a reusable non-linear personal web notebook http://www.tiddlywiki.com/ Googleグループで行われているディスカッションでの第一報。データが全滅したユーザーが続出。 I lost all my TiddlyWiki pages - TiddlyWiki | Google
携帯業界の認証事情 Part2 - y-kawazの日記
先日の日記で携帯の認証に関しての考察をして、とりあえずキャリア毎のIP制限を行っていれば端末IDやユーザID認証を信用していいのでは無いか？と書いたのだが、更に調べた結果どうも怪しい実態が見えてきたので危険度と合わせて再度纏めてみようと思う。 とりあえず指摘があったので前回のテストに加えて以下を試してみました。 NO uidに指定した値 実際に送信されてくる値 8 %30%31%32%33%34%35%36%37%38%39%61%62*1 1234567890ab うわ弱っ、駄目じゃん。見事にuidの詐称が成功してしまった…。 DoCoMoのユーザIDの信頼性が地に落ちた瞬間です。 2007-03-01追記）DoCoMoスゲー！昨日は確かに上記の方法で詐称できたのに、今日はもう既に対策されとるし(^^; 今、同じことを試すと以下のメッセージが出るのみでした。 IPサイトの記述に誤りがある
携帯業界の認証事情 - y-kawazの日記
巡回サイトの一つである高木浩光＠自宅の日記で以下のようなエントリーがあった。 高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか ここではいつもの高木氏の口調で、「携帯向けWEBアプリ開発では未だにGETパラメータでセッションIDを渡しており、それはこれまでも何度もいかんことだと言っている。」というような内容が語られている。 確かにWEB+DBの記事に対して高木氏が注釈で言っているように「IPアドレスによる制限に関して書いていない」という点に関してはWEB+DB側の落ち度だと思う。実際これを行わない限り端末IDやユーザID*1による認証が意味をなさなくなってしまうからだ。*2 但し、キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認
高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか
■ 携帯電話向けWebアプリの脆弱性事情はどうなっているのか WEB+DB PRESS誌のVol.37に「携帯サイト開発 実践テクニック 2007」という記事が掲載されているのだが、そこにこんな記述があった。 端末認証 登録が必要なサイトの場合，利用する際にはログインが必要です．ID/パスワードを毎回入力するのでは，携帯の場合では特に面倒です． そこで携帯ならではの認証方法として，現在の端末では取得が容易にできる端末自体の情報（端末ID）を利用します． （略） セッション PCサイトでセッションを使う場合は，通常セッションIDをCookieに保存しますが，携帯ブラウザではCookieにデータを保存することができません．そこで携帯サイトでCookieを使う場合はURLにセッションIDを埋め込むことになります． セッションIDをGETで渡す セッションIDをGETで渡す場合は，PHPの設定ファ
高木先生のご指摘はもっともな面があるものの、一部でヒステリックな反応..
高木先生のご指摘はもっともな面があるものの、一部でヒステリックな反応があるので、言及をする。 NTT DoCoMoの端末はCookieを利用できない。そこで、セッションを引き継ぐために、セッションIDをURLに含める必要がある。ただし、端末はHTTP_REFERERを送信しないので、セッションIDが端末の参照元情報から漏れる心配はない。 一方、AU・SoftbankはCookieを利用できるので、セッションIDをURLに含める必要はない。 全キャリア対応のためと称して、セッションIDをURLに含めると、セッションハイジャックの危険性がうまれる。ただし、フレームワークでそのセッションIDをURLへ埋め込むかどうかを切り替えれば済む話なので、対応が難しいというわけではない。 さらに、携帯電話向けのサービスでは、キャリアの指定するIPアドレスの範囲以外からのアクセスを制限することが一般的になって
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
ルータ設定 - 情報処理推進機構IPA セキュリティセンター
使用するポートのみ開ける これは、一見単純な設定のように思えます。 しかし、単純に設定を行うとLAN側からも通信できない等の現象を引き起こします。 この作業は、実はTCP/IPを理解していないと行えない設定作業なのです。 セキュリティポリシーを考える段階で充分に検討を行ってください。 ルータでの防御は一要素にすぎない ルータにおけるセキュリティ設定において心がけておくことがあります。 それは「ルータのセキュリティはサイト全体のセキュリティの一要素にすぎない」ということです。 前述のリモートアクセスの回線をバックドアとして利用する場合や、 もしルータに致命的なセキュリティホールが見つかった場合などを考慮し、 そのLAN側でも防御を行うべきでしょう。 しかし、もし守るべきデータがルータレベルのもので十分であると判断した場合や、 利便性を考慮し別に設置するFirewallで賄
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
x.com
http://neta.ywcafe.net/000727.html
ソーシャルブックマークユーザーのIDとPASSをいとも簡単に抜き取る手口*ホームページを作る人のネタ帳
http://www.kobe-np.co.jp/kobenews/sg/0000272539.shtml
Want to destroy your computer?
大日本印刷の関連会社元社員による個人情報流出、合計43社・約864万件に
携帯で端末ID詐称は可能かもしれない話
