タグ『セキュリティ』 | いしなお!? | 1470.net

いしなお!? タグ『セキュリティ』

TypeKey はてな [D] [B] このフィードを集計

ランキング

マイページ

to all users' セキュリティ

# 2007/03/14 19:16 ishinao
はてなクラックセキュリティ
機能変更、お知らせなど - はてなの日記 - はてなサーバーへの不正な侵入について edit res
- URL はてなサーバーへの不正な侵入について - はてなの日記 - 機能変更、お知らせなど →18 links
  http://hatena.g.hatena.ne.jp/hatena/20070314/1173858953
辞書じゃなくてブルートフォースか。どのくらいの時間で突破したんだろうなー。
# 2007/03/02 17:51 ishinao
PHP セキュリティ
the Month of PHP Bugs edit res
- URL the Month of PHP Bugs →17 links
  http://www.php-security.org/
- URL Category: the Month of PHP Bugs - yohgaki's blog →7 links
  http://blog.ohgaki.net/index.php/yohgaki?cat=41
# 2007/02/02 16:58 ishinao
セキュリティ XSS
PHP使ってるんならstrip_tags()やhtmlspecialchars()くらい覚えておこう。 edit res
- URL PHP使ってるんならstrip_tags()やhtmlspecialchars()くらい覚えておこう。 →6 links
  http://neta.ywcafe.net/000719.html
こういう対応(追記の部分)はまずいよなー。
# 2006/08/15 08:44 ishinao
Ruby Rails セキュリティ
Riding Rails: Rails 1.1.6, backports, and full disclosure edit res
- URL Riding Rails: Rails 1.1.6, backports, and full disclosure →5 links
  http://weblog.rubyonrails.org/2006/8/10/rails-1-1-6-backports-and-full-disclosure
詳しい脆弱性情報。
# 2006/08/08 10:05 ishinao
Ajax セキュリティ CNet ITmedia
Ajaxとセキュリティに関するCNetとITmediaの記事 edit res
- URL 「Web 2.0」導入が進む中、後回しにされるセキュリティ:ニュース - CNET Japan →12 links
  http://japan.cnet.com/news/media/story/0,2000056023,20186967,00.htm
- URL 「Web 2.0」導入が進む中、後回しにされるセキュリティ:ニュース - page2 - CNET Japan →6 links
  http://japan.cnet.com/news/media/story/0,2000056023,20186967-2,00.htm
- URL 2006/08/01 | いしなお!? | 1470.net →1 links
  http://1470.net/user/ishinao/2006/08/01#m_72772
- URL Ajaxが招く新たなセキュリティリスク (1/2) - ITmedia エンタープライズ →7 links
  http://www.itmedia.co.jp/enterprise/articles/0608/07/news004.html
- URL Ajaxが招く新たなセキュリティリスク (2/2) - ITmedia エンタープライズ →2 links
  http://www.itmedia.co.jp/enterprise/articles/0608/07/news004_2.html
このITmediaの記事って、前に取り上げたCNetの記事と同じことを扱っているんだよね。CNetの記事には、

> Web 2.0ともAjaxともほとんど関係なく、Webアプリケーション一般に通じる話のような気がするんですが。単にWeb 2.0とかAjaxとかバズワードをタイトルに混ぜてキャッチーにしたかっただけちゃうんかい、みたいな。

という批判的なコメントをつけたけど、ITmediaの記事を読むと、ちゃんと元の講演ではAjaxに特化したセキュリティの話題(『攻撃者は、表面には現れてこないAjaxの機能を悪用し、Webサイトに複数のデータストリームを送信させるよう操作して、自らの攻撃の有効性を高めている』とか)になってるじゃん。CNetの記事でのまとめ方が悪かっただけなのね。
# 2006/08/02 19:16 ishinao
セキュリティ XSS
XSS - 表示系パラメータに存在する盲点 :: ぼくはまちちゃん! edit res
- URL XSS - 表示系パラメータに存在する盲点 :: ぼくはまちちゃん! →18 links
  http://mxxi.hamachiya.com/2006/08/xss_1.html
誰かうちもテストしてくれないかなー。

そういや俺も前に、汎用ページナビゲーションコンポーネントで似たようなXSSを出したことがある(運用前のセキュリティ監査で見つかった)。コンポーネント自体は、QUERY_STRINGの各パラメータの意味を理解せず(っつーか汎用だから、ロジックレイヤーで使われるパラメータの意味は理解できない)、ロジックレイヤーから渡されたQUERY_STRINGにページ処理系パラメータを付加して出力するようにしていて、うっかりロジックレイヤーから渡されたパラメータを(信用して? エスケープ済みと勘違いして?)エスケープせずに出力してしまっていた。

たとえロジックレイヤーから渡されたQUERY_STRING(の一部)だとしても、エスケープは出力時点でまとめて行うように決めてあったんで、エスケープしないで出..続きを読む
# 2006/08/01 16:10 ishinao
Web 2.0 Ajax セキュリティ
「Web 2.0」導入が進む中、後回しにされるセキュリティ - CNET Japan edit res
- URL 「Web 2.0」導入が進む中、後回しにされるセキュリティ:ニュース - CNET Japan →12 links
  http://japan.cnet.com/news/media/story/0,2000056023,20186967,00.htm
- URL 「Web 2.0」導入が進む中、後回しにされるセキュリティ:ニュース - page2 - CNET Japan →6 links
  http://japan.cnet.com/news/media/story/0,2000056023,20186967-2,00.htm
Web 2.0ともAjaxともほとんど関係なく、Webアプリケーション一般に通じる話のような気がするんですが。単にWeb 2.0とかAjaxとかバズワードをタイトルに混ぜてキャッチーにしたかっただけちゃうんかい、みたいな。

もしWeb 2.0やAjaxと絡めてこういう話をしたいんだったら、XSSとかセッションハイジャックとかコーディングテクニックとかの話じゃなく、マッシュアップ用APIを公開するに当たってのセキュリティ確保の要点とか、Ajaxによる非同期通信の悪用可能性とか、そういう話を中心に語るべきじゃないの。
参照: MEMO
# 2006/07/21 23:33 ishinao
セキュリティ XSS PayPal
フィッシングに悪用されたPayPalのXSS脆弱性,2年間放置されていた可能性あり:ITpro edit res
- URL フィッシングに悪用されたPayPalのXSS脆弱性,2年間放置されていた可能性あり:ITpro →8 links
  http://itpro.nikkeibp.co.jp/article/USNEWS/20060721/243976/
> 対応した同社スタッフはXSS脆弱性を理解できず,この脆弱性を突く検証コードを送るという申し出に対しても,会社のポリシーで禁止されているとして断った

PayPalって大手だし金を扱っているんだし、もっとましなところだと思っていた(特に根拠なし)んだけどなー。
# 2006/07/09 20:51 ishinao
セキュリティ trac
よくきたはてダ - trac脆弱性ですか edit res
- URL trac脆弱性ですか - よくきたはてダ →4 links
  http://d.hatena.ne.jp/elf/20060707/1152243182
- URL Edgewall Weblog : /news/trac_0_9_6.html →4 links
  http://www.edgewall.com/blog/news/trac_0_9_6.html?seemore=y
- URL TracDownload – The Trac Project →3 links
  http://projects.edgewall.com/trac/wiki/TracDownload
内容読んでないけど、ひとまずアップデートしておいた。
参照: MEMO
# 2006/03/29 00:00 ishinao
セキュリティ XSS 文字コード
[Webアプリ]文字コードとHTMLエンコードとCross-Site Scriptingの微妙な関係 edit res
- URL なんてこと全然もっと根が深い? - 交差点の猫 →3 links
  http://d.hatena.ne.jp/harupu/20060328#p1
ちゃんとやってれば攻撃が決まるパターンはそう多くないと思うけど、抜本的に解決するためには、対象の文字コード系として不正なバイト要素を除去しなきゃいけないのか。内部ではバイナリ列として扱って、表示時にHTMLエスケープという対応じゃだめなのね。
# 2006/02/22 00:00 ishinao
セキュリティ
脆弱性情報サイト「JVN」が実施したアンケートのCGIに脆弱性が指摘される edit res
- URL 脆弱性情報サイト「JVN」が実施したアンケートのCGIに脆弱性が指摘される →3 links
  http://internet.watch.impress.co.jp/cda/news/2006/02/21/10960.html
せっかく自分のところで発生した問題なんだから、具体的なセキュリティ問題の事例として、欠陥のあったコード、それにどういう問題があったのか、対策として行った修正、のすべてを公開するのがいいと思う。
# 2006/02/13 00:00 ishinao
PHP SJIS セキュリティ
[PHP][セキュリティ] addslashes() による SQL 文字列のエスケープ回避問題 edit res
- URL 2006-01-22 - t_komuraの日記 →5 links
  http://d.hatena.ne.jp/t_komura/20060122#1137944280
自分ではinternal_encodingにSJISを選ぶことはないけど、要望でSJISを使わざるを得ないときはたまにあるから、そういうときに気をつけるようにしないと。
# 2006/01/06 00:00 ishinao
セキュリティ CSSXSS はてな
はてなアイデア - CSSXSSを利用しなくても他人の日記に投稿したり、他人のプライベートモードの日記をパブリックにしたりできるようにして欲しい。現状では攻撃サイトのリンクを踏ませる必要があり面倒。 edit res
- URL はてなアイデア - CSSXSSを利用しなくても他人の日記に投稿したり、他人のプライベートモードの日記をパブリックにしたりできるようにして欲しい。現状では攻撃サイトのリンクを踏ませる →2 links
  http://i.hatena.ne.jp/idea/7917
CSSXSSはサーバー側のコーディングで対応できるレベルを超えた穴なんで、ブラウザ（IE）側で対処するべきだと思う。CSSXSS対策まで含めてWebアプリを作るとなると、安全を考えれば設計からやり直しになっちゃうし。っつーかMSとっとと対応しろよ。
# 2005/12/09 00:00 ishinao
CSSXSS セキュリティ
hoshikuzu | star_dust の書斎 edit res
- URL 2005-12-04 - hoshikuzu | star_dust の書斎 →2 links
  http://d.hatena.ne.jp/hoshikuzu/20051204#P2005204MATANGILLON
今頃ちゃんと読んだ。これはとてもまずい。Google Desktopはあくまで一例であって、たいていのパーソナライズドページでいけそう。いろんな応用例が思いついちゃって困る。うがー。
# 2005/11/02 00:00 ishinao
PHP セキュリティ
yohgaki's blog - PHPの現行リリースに重大な脆弱性(PHP4.4.0以下、PHP5.0.5以下) edit res
- URL PHPの現行リリースに重大な脆弱性(PHP4.4.0以下、PHP5.0.5以下) →2 links
  http://blog.ohgaki.net/index.php/yohgaki/2005/11/02/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp
もうあちこちアップデート＆検証大会ですよ。
# 2005/09/07 00:00 ishinao
セキュリティ HTTP Response Splitting
HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics edit res
- URL セキュリティホール memo - 2005.01 →1 links
  http://www.st.ryukoku.ac.jp/~kjm/security/memo/2005/01.html#20050127_ResponseSplitting
知らんかった。HTTPヘッダ出力に関する脆弱性。対策は分かるけど、何かあった場合の影響範囲がいまいち把握できない。プロキシーサーバーってどのくらいHTTP Responseヘッダ情報を使ってるんだろう。
# 2005/09/07 00:00 ishinao
はてなセキュリティ
CNET Japan Blog - 近藤淳也の新ネットコミュニティ論:不具合と信頼性 edit res
- URL 不具合と信頼性:近藤淳也の新ネットコミュニティ論 - CNET Japan →1 links
  http://blog.japan.cnet.com/kondo/archives/002324.html
『未知の脆弱性に対して、事前に完全な対策をすることなど不可能です。』。提供する機能との兼ね合いになるから別に現状でも悪くはないんだけど、根本的なアプローチとして、もっとセキュリティを気にした設計にすることは可能だよなー、と思うことは多い。
# 2005/07/15 00:00 ishinao
セキュリティ
【レポート】セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏 (MYCOM PC WEB) edit res
- URL 【レポート】セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏 | エンタープライズ | マイコミジャーナル →5 links
  http://pcweb.mycom.co.jp/articles/2005/07/12/wasf/
『『サニタイズ』はろくな対策をしていないことを一言で表現できる便利な言葉』。特殊な場合以外は、必要に応じてエスケープすれば済むはずだしな。入力時に置換や削除による対策をするってことは、データ利用時に適切なエスケープができていない可能性があるからだろう。
# 2005/07/08 00:00 ishinao
コ PHP CSRF セキュリティ
p0t: CSRF対策俺ルール2 edit res
- URL CSRF対策俺ルール2 - p0t →1 links
  http://p0t.jp/mt/archives/2005/07/csrf2.html#comments
セッションIDを使う場合は、ふつうに
<input type="hidden" name="sessionid" value="<?=session_id() ?>" />
でいいと思いますよ。
# 2005/07/06 00:00 ishinao
セキュリティ PHP XML-RPC PEAR
ITmedia エンタープライズ：オープンソースBlogとWikiに影響する脆弱性、各社が修正リリース edit res
- URL Expired →2 links
  http://www.itmedia.co.jp/enterprise/articles/0507/06/news015.html
相変わらずpear upgrade XML_RPCするとpingサーバーが動かなくなるんで、手作業でXML/RPC.phpの中でシングルクォーテーションを使ってパース結果（のPHPコード）を生成しているところをダブルクォーテーションを使うように修正した。
# 2005/07/06 00:00 ishinao
セキュリティ ACCS office
ACCSの不正アクセス裁判で有罪判決が確定、元京大研究員が控訴取り下げ edit res
- URL ACCSの不正アクセス裁判で有罪判決が確定、元京大研究員が控訴取り下げ →3 links
  http://internet.watch.impress.co.jp/cda/news/2005/07/05/8279.html
あきらめちゃったのか。ってことは、今後はこの判例を前提とした方がいいんだね。開発者としては楽だけど、利用者としてはいやな展開だ。でもふつうの利用者は、そのことに気づいていないだろうところがまた……。
# 2005/06/09 00:00 ishinao
セキュリティはてな XSS
はてなダイアリー内のXSS脆弱性について edit res
- URL 2005/06/09 | いしなお!? | 1470.net →1 links
  http://1470.net/mm/mylist.html/1?date=2005-06-09#m53911
- URL はてなダイアリー内のXSS脆弱性について - はてなダイアリー日記 →1 links
  http://d.hatena.ne.jp/hatenadiary/20050609/1118312128
修正された。
# 2005/06/09 00:00 ishinao
HTML サニタイズセキュリティ
「直しても直しても直らない」@水無月ばけらのえび日記 edit res
- URL 直しても直しても直らない | 水無月ばけらのえび日記 →3 links
  http://bakera.jp/hatomaru.aspx/ebi/topic/2341
なるほどその手もあるかと試してみたら、某所で新しい穴を発見してしまった（報告済み）。やっぱりHTMLを許可しつつも危険な要素を除去するというアプローチは良くないよなー。
# 2005/06/08 00:00 ishinao
flash セキュリティ
Macromedia - デベロッパーセンター : Macromedia Flash Player 7 におけるセキュリティの変更についてページ 3 edit res
- URL Adobe - デベロッパーセンター : Macromedia Flash Player 7 におけるセキュリティの変更について →1 links
  http://www.macromedia.com/jp/devnet/mx/flash/articles/fplayer_security_03.html
# 2005/06/06 00:00 ishinao
セキュリティ
狙われたのはゲームユーザー--韓国MSNサイトへの攻撃の詳細が明らかに edit res
- URL 狙われたのはゲームユーザー--韓国MSNサイトへの攻撃の詳細が明らかに:ニュース - CNET Japan →2 links
  http://japan.cnet.com/news/sec/story/0,2000050480,20084164,00.htm
これって価格.comがやられたのと同じ内容じゃない？　MSNってことはやっぱりMS系サーバーを使っていたんだろうな。アプリレベルの脆弱性ではなく、MS系サーバー共通の脆弱性の可能性が気になってくる話だ。
# 2005/06/03 00:00 ishinao
セキュリティ kakaku.com
【単独インタビュー】「当社が不正アクセスの手口を公開しない理由」，カカクコムの穐田CEO : IT Pro ニュース edit res
- URL 【単独インタビュー】「当社が不正アクセスの手口を公開しない理由」,カカクコムの穐田CEO:ITpro →7 links
  http://itpro.nikkeibp.co.jp/free/NCC/NEWS/20050602/161996/
『同じセキュリティ会社から，セキュリティ対策のレベルは決して低かったわけではないと指摘された点も付け加えておきたい』。その評価をセキュリティ会社から公式に発表してもらいたい。具体的な内容はなくていいから。
# 2005/06/03 00:00 ishinao
swatch firewall ssh セキュリティ
swatchとipfwでsshの不正アクセスを自動拒否する方法 edit res
- URL swatchとipfwでsshの不正アクセスを自動拒否する方法 →1 links
  http://www.hodogaya.org/home-server/swatch-ipfw.html
認証ログを見てアタック元のIPアドレスをipfwで自動的にdenyするのか。今度試してみよう。と思ったけど、これもし自分でユーザー名を間違ってログインしようとしたら、そのIPアドレスからの接続を拒否られちゃう？
# 2005/06/03 00:00 ishinao
セキュリティ kakaku.com
[PC・携帯関連] 「カカクコム＝被害者」を批判するバカの無教養。 edit res
- URL http://blog.livedoor.jp/nmpf/archives/23949241.html →3 links
  http://blog.livedoor.jp/nmpf/archives/23949241.html
『SQLインジェクションを許すような部分があったとしたら、たしかにカカクコムにも落ち度があったと言えるでしょう。クロスサイト・スクリプティング対策は基本中の基本ですからね』。SQLインジェクションとXSSは違うよ。エスケープの問題ならばすべて一緒くたかよ。
# 2005/05/26 00:00 ishinao
セキュリティ DB kakaku.com
Article 8466 at 05/05/26 15:00:30 From: sanaki@cc.rim.or.jp Subject: [memo:8466] Re: 過失は無いから責任は無い？ edit res
- URL http://memo.st.ryukoku.ac.jp/archive/200505.month/8466.html →1 links
  http://memo.st.ryukoku.ac.jp/archive/200505.month/8466.html
『なぜって? 分離したら、アプリケーション/システムが個人情報を表示できなくなっちゃう。』んなことないよ。分離したい部分だけ、別権限でDB接続するようにすればいいだけだよ。
# 2005/05/26 00:00 ishinao
kakaku.com セキュリティ IPA
IPAにはkakaku.comから具体的な報告は来ていないそうだ edit res
- URL ITmediaニュース:「過失はない」「地震のようなもの」――カカクコム、侵入手口明らかにせず →4 links
  http://www.itmedia.co.jp/news/articles/0505/25/news086.html
- URL http://memo.st.ryukoku.ac.jp/archive/200505.month/8456.html →2 links
  http://memo.st.ryukoku.ac.jp/archive/200505.month/8456.html
『「不正アクセスを受けた」という被害の届出がありましたが、現時点ではその原因や対策については報告を受けておりません。』。ってことは『情報処理推進機構（IPA）からも情報開示が行われる』（関連URL）てのは嘘かよ。くそだな。
# 2005/05/26 00:00 ishinao
セキュリティ開発
サニタイズ？何それ edit res
- URL 価格.com、サービス再開へ →1 links
  http://slashdot.jp/comments.pl?sid=257337&cid=740079
俺の場合は、バリデーション（入力値のチェック。不正なら再入力やエラー等）→サニタイズ（使用不可文字の強制除去・変換等）→エスケープ（そのまま利用できない文字を、利用時に正しく処理）といった使い分けだなー。
# 2005/05/26 00:00 ishinao
セキュリティ IPA
「製品開発者が脆弱性ではないと主張した場合」@水無月ばけらのえび日記 edit res
- URL 製品開発者が脆弱性ではないと主張した場合 | 水無月ばけらのえび日記 →1 links
  http://bakera.jp/hatomaru.aspx/ebi/topic/2320
なるほど、IPAってセキュリティ関連の処理に関して、仲介と情報公開の窓口としてはそれなりに動けるけど、具体的な「判断」に関しては弱い（基本的に当事者の判断優先）って感じなのね。本当はそこを期待したいんだけど。
# 2005/05/25 00:00 ishinao
セキュリティ kakaku.com
「価格.com」事件，「当社に過失はなかった」とカカクコム社長 : IT Pro ニュース edit res
- URL 「価格.com」事件,「当社に過失はなかった」とカカクコム社長:ITpro →5 links
  http://itpro.nikkeibp.co.jp/free/SI/NEWS/20050525/161513/
単にDBに持っているコンテンツデータを書き換えられた＆見られただけなのか、もっといろいろやられたのかだけでも知りたいなー。っつーかもろアプリの問題だから、過失がないってのは無理がありすぎ。あと搾取はされてないだろう。
# 2005/05/25 00:00 ishinao
セキュリティ暗号化人質
スラッシュドットジャパン | ファイルを暗号化して「人質」にする新手の攻撃 edit res
- URL スラッシュドット・ジャパン | ファイルを暗号化して「人質」にする新手の攻撃 →1 links
  http://slashdot.jp/article.pl?sid=05/05/25/0350229&topic=117&mode=nested
なるほど、面白い。完全破壊するのではなく、攻撃者のみ復号可能な形で暗号化（本来の所有者にとっては破壊に相当）してしまうわけか。なんかいろいろ応用例が思いつきそうだな。
# 2005/05/22 00:00 ishinao
セキュリティ IPA 脆弱性
その１ edit res
- URL orz - TOTOROの自堕落日記 →2 links
  http://d.hatena.ne.jp/magisystem/20050517#1116315079
まさかIPAって、開発者本人が「仕様」と「脆弱性」のどちらと答えるかを脆弱性かどうかの判断基準として採用しているんじゃなかろうな。と、ちょっと不安になった。じゃなきゃ「開発者が仕様だと答えたから」を理由にしちゃまずいだろう。
# 2005/05/20 00:00 ishinao
セキュリティ携帯
asahi.com：ＴＢＳ携帯サイトで個人情報流出か　第３世代に未対応?-?社会 edit res
- URL http://www.asahi.com/national/update/0520/TKY200505200163.html →1 links
  http://www.asahi.com/national/update/0520/TKY200505200163.html
『システムが第３世代携帯電話に対応していなかったため、最新機種で会員登録画面にアクセスすると、他人の登録情報が誤って表示されるようになっていた』。詳細が知りたい。何がどうなったんだ？
# 2005/05/20 00:00 ishinao
セキュリティ kakaku.com
価格.comサイトが不正アクセス被害で閉鎖中 edit res
- URL 価格.comサイトが不正アクセス被害で閉鎖中 →1 links
  http://slashdot.jp/comments.pl?sid=255839&cid=735814
『元中の人から言わせると、自業自得です。』
# 2005/05/19 00:00 ishinao
セキュリティ Wiki アップロード
Wiki クローンにおけるクロスサイトスクリプティングの脆弱性 edit res
- URL JP Vendor Status Notes →3 links
  http://jvn.jp/jp/JVN#465742E4/index.html
IEのバグ（仕様）対策も面倒だし、ブラウザ側のセキュリティだけでなく、サーバー側のセキュリティ対策も複合的に考える必要があるし、ファイルアップロード関連への対策は、かなり面倒くさい。
# 2005/05/18 00:00 ishinao
Webサーバークラックセキュリティ
asahi.com：静岡新聞社運営のサイトに不正アクセス　ウイルス感染も-社会 edit res
- URL http://www.asahi.com/national/update/0517/TKY200505170312.html?t →2 links
  http://www.asahi.com/national/update/0517/TKY200505170312.html?t
やっぱりWindowsサーバーが徹底的にやられているっぽいな。早く原因を発表してくれ。最新のパッチを当てたWindowsサーバー＋IISで、80と443しか開けてなくてもやばいというのならば、それなりの対策を考える必要が出てくるし。
# 2005/05/17 00:00 ishinao
セキュリティクラック
NetSecurity - 20件を超える大量のWebサイト改竄被害が発生 edit res
- URL ScanNetSecurity - 20件を超える大量のWebサイト改竄被害が発生 →2 links
  https://www.netsecurity.ne.jp/1_2770.html
ああ、kakaku.comの他にもクラックされたサーバーはあったのか。だとすると、未知のセキュリティホールを狙われた可能性も出てくるな。パッチを当ててないサーバーがわらわらあったという可能性もあるけど。
# 2005/05/17 00:00 ishinao
kakaku.com クラックセキュリティ
ITmediaニュース：「最高レベルのセキュリティが破られた」――カカクコム、不正アクセス事件を説明 edit res
- URL ITmediaニュース:「最高レベルのセキュリティが破られた」――カカクコム、不正アクセス事件を説明 →2 links
  http://www.itmedia.co.jp/news/articles/0505/16/news077.html
ここまで言っておいて、すでにパッチが出ている既知のセキュリティホールから侵入された、とかだったりしないだろうな。でも未知のものだった場合、他に事例が出てこないのが不審だ。
# 2005/05/16 00:00 ishinao
kakaku.com セキュリティクラック
【速報】価格.comがハッキングで閉鎖、閲覧者にウイルス感染の可能性も : IT Pro ニュース edit res
- URL Site report for kakaku.com →1 links
  http://toolbar.netcraft.com/site_report?url=http://kakaku.com
- URL 【速報】価格.comがハッキングで閉鎖、閲覧者にウイルス感染の可能性も:ITpro →4 links
  http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050516/160843/
kakaku.comって昔Accessでデータ管理とかしていた気がするし、多分MS系サーバーだろうなーと思ったら、やっぱりそうだった模様（関連URL）。
# 2005/05/16 00:00 ishinao
セキュリティ不正アクセス kakaku.com
kakaku.comが不正アクセスで閉鎖　閲覧ユーザーはウイルス感染も edit res
- URL kakaku.comが不正アクセスで閉鎖閲覧ユーザーはウイルス感染も →1 links
  http://news19.2ch.net/test/read.cgi/newsplus/1116172924/
あとで詳しい情報が発表されるといいなー（参考情報として）。
# 2005/05/14 00:00 ishinao
コセキュリティ movabletype 脆弱性
「旅行びと日記」日記: いっぱい叩かれてしまった訳ですが edit res
- URL [ bROOM.LOG ! ]: いっぱい叩かれてしまった訳ですが →1 links
  http://tdiary.seesaa.net/article/3630283.html#comment
『ただそれが最後まで「脆弱性」として扱われるのは、私の感覚とはずいぶん違っているので、そのあたりのずれを修正（あるいは私の方の感覚が間違っているならそれを修正）するために、あのような記事を書いています。』
# 2005/05/14 00:00 ishinao
コ MovableType セキュリティ脆弱性
Movable Type の脆弱性の件 : NDO::Weblog edit res
- URL Movable Type の脆弱性の件 : NDO::Weblog →2 links
  http://naoya.dyndns.org/~naoya/mt/archives/001688.html#comments
『改善するべき問題ですけど、これを脆弱性というと、secure Cookieを使った認証維持以外の方法すべてが脆弱性になってしまいそう。』
# 2005/05/14 00:00 ishinao
セキュリティ MovableType 脆弱性
[Blog全般] Movable Type 3.151以前のセッションハイジャック脆弱性問題 edit res
- URL [ bROOM.LOG ! ]: Movable Type 3.151以前のセッションハイジャック脆弱性問題 →1 links
  http://tdiary.seesaa.net/article/3600409.html
この人が報告者らしい。けど、これはやっぱり脆弱性じゃーないだろう。より安全性が高い設計が望ましい仕様ではあるけれども、これを脆弱性といったのでは、セッションCookieすべてが脆弱性にならないか？　度合いの問題ってだけだし。
# 2005/05/13 00:00 ishinao
セキュリティ movabletype 脆弱性
Tociyuki::Diary - MovableTypeの不正アクセス対策前のクッキー edit res
- URL Tociyuki::Diary →1 links
  http://d.hatena.ne.jp/tociyuki/20050513/1115961428
なるほど、Cookieに記録している内容自体がやばいって話がメインなのね。平文パスワードじゃない分ちょっとはましだけど、無期限にあちこち（Web/Atom API等）で使える認証キーをそのまんまCookieに載せていたと。
# 2005/05/13 00:00 ishinao
コセキュリティ movabletype 脆弱性
Movable Type の脆弱性の件 : NDO::Weblog edit res
- URL Movable Type の脆弱性の件 : NDO::Weblog →2 links
  http://naoya.dyndns.org/~naoya/mt/archives/001688.html#comments
『「漏れてはまずいから漏れないようにしている情報が、もしも万が一漏れたら危険なことになりますよ」ってのはふつう脆弱性情報じゃないと思いますし、それを脆弱性と言うのだから他にも何かあるのかなー、と。』
# 2005/05/12 00:00 ishinao
Movable Type Cookie セキュリティ
Movable Typeで第三者の不正アクセスを許可してしまう脆弱性 edit res
- URL Movable Typeで第三者の不正アクセスを許可してしまう脆弱性 →2 links
  http://bb.watch.impress.co.jp/cda/news/9554.html
いまいちわからん。Atom APIの認証でも使っているにしても、基本的にWeb管理ツールの認証Cookie漏れた時点で十分やばい（Web管理ツールで詐称ログインされる）んじゃないの？　そっちは対策してあるってことかな？
# 2005/05/09 00:00 ishinao
セキュリティ Firefox JavaScript
Secunia - Advisories - Mozilla Firefox Two Vulnerabilities edit res
- URL Mozilla Firefox Two Vulnerabilities - Secunia Advisories - Vulnerability Intelligence - Secunia.com →1 links
  http://secunia.com/advisories/15292/
安全なURLを詐称することによって、強制的に拡張機能相当の権限を持つスクリプトを実行させることができるという、激やばな脆弱性。って理解であっているかな。インストール許可サイトをすべて削除しておけば、警告が出るか？

1 2 →

メニュー

ホーム (携帯)

いしなお!?

話題のMONO

MONO エンジェル高校 2 (2) (サンデーGXコミックス)

スポンサードリンク

Powered by PHP 5.2.4 / Zend Framework 0.1.5 / WEBXP 0.1.1 / Hyper Estraier / Amazon Webサービス / Amazon.co.jpアソシエイト / Yahoo! UI Library / Prototype JavaScript Framework / script.aculo.us