管理プログラムがGoogleにインデックスされないようにする ２０１０年０４月０２日
ＷＥＢインベンターのご利用に心から感謝いたします。 さて、当社のカートを利用しているお店で個人情報流出の事故が発生しました。それは、管理プログラムがGoogleにインデックスされてしまったことによるものです。原因は調査中ですが、しかし、そのような場合でも検索エンジンに拾われないような対策を施してありますので、お知らせいたします。 対処方法： １．パスワードの管理に気をつける ２．最新の管理プログラムを使う ３．検索エンジンにインデックスされてしまったときの対処 ４．今後の対応 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ １．パスワードの管理に気をつける ━━━━━━━━━━━━━━━━━━━━━━━━━━━ パスワード付きのＵＲＬが検索エンジンに拾われないようにするために気をつけてください。間違っても、パスワード付きのＵＲＬを一時的にもホームページで公開しないようにしてください
IIS 7.5 详细错误 - 404.0 - Not Found
错误摘要 HTTP 错误 404.0 - Not Found 您要找的资源已被删除、已更名或暂时不可用。
続: Winny研究者がなぜウィルスによる情報漏洩の責任を問われうるか - ものがたり(旧)
前回のエントリは15分くらいで率直な思考を手短にまとめただけだったので、はてブコメントを見る限り、いろいろと拡大解釈されたり、表現が安易でよろしくない部分もあったようだ。後者については単純にわたしの書き方の問題でそこは反省するとして、前者は払拭して、話がワープしないように長々と書いておこう。 まず、誰もセキュリティ対策として既に流出したものを消すようにしろとか出来るとか書いているわけではない。この意味で「『出来るはず』なんて言っているが出来るわけがない」という主張には意味がない。セキュリティ対策とは現実的なコストにおいて問題発生の可能性を低めることであるはずで、出来ないことを出来るようにしろというものではないはずだ。少なくとも法は不可能を要求しない。また、「出来ない」と主張しつつ、Winnyの作者に何とかしろと対応を要求する人がいるとすれば、それはダブルスタンダードである。 改善可能なのは
2008-12-25
戦場の最前線がやられちゃってます。原因はまったく出ていないけど。これが原因じゃないでしょうかね。（憶測） うわさでは、このサイトは、あんなのや、こんなので多重で防御していると聞きましたが、*1なぜこんな重要なサイトでPHPなんぞ（暴論）使っているんでしょう？静的コンテンツで十分じゃないですか。 Web経由の問合せ窓口でも、もう少しやりようがあったと思いますが・・・ DNSポイゾニングかと思ったけど、ドメインで引っ張れるIPアドレスは靖国神社のものだったので、やっぱり不正アクセスなのかな？ ちなみに、まっちゃさんから、良く見つけたとお褒めの言葉がありましたので、そのときの思考を書いておきます。 ・まず、DNSポイゾニングを疑った→ちがうっぽい ・某対策がされているはずなので、HTTPサーバの脆弱性の可能性は低いよな。→じゃ、定番のWebアプリが怪しい ・Webサイトが見れないので、Web.a
第14回 減らないSQLインジェクション脆弱性 | gihyo.jp
SQLインジェクション脆弱性を狙った大規模な攻撃が繰り返し行われ、数万から数十万ページが改竄される事件が何度も発生しています。SQLインジェクションは簡単に対策できる脆弱性ですが、未対策のアプリケーションが多く利用されています。外部からの脆弱性の検出も容易であるため、現在でもWebアプリケーション脆弱性の代表的存在です。 SQLインジェクション脆弱性が無くならない理由には以下のようなものが考えられます。 過去のコードやアプリケーションの再利用 基本的なセキュリティ知識不足 セキュアコーディングプラクティスの未実施 コード監査の不在 SQLインジェクション脆弱性の発見だけを目的にコード監査を行うことはあまりありませんが、SQLインジェクション脆弱性のコード監査は比較的簡単です。MySQLモジュールまたはPostgreSQLモジュールを利用している場合を例に紹介します。 本題に入る前にSQLイ
プログラミングではホワイトリスティングが基本
(Last Updated On: 2018年8月8日)「ホワイトリスト方式の優位は神話」と題するエントリに私のブログホワイトリストはどう作る? が引用されている事を教えていただきました。 ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。 誤解されないように書こうとすると、どうしても長文になります。暇な方だけお付き合いください。 参考： セキュリティを論理的に構築する方法 （こちらは科学的なセキュリティの基本構造の作り方の話です。ぜひどうぞ） 意地悪なブログエントリと書籍の文章 まず、ちょっと意地悪なブログエントリと書籍の文章を同列に比較されても困ります。言い訳ですが著書の”Webアプリケーションセキュリティ対策入門”では金床さんと同様の表現になっています。90年代にホワイトリ
サーバシグニチャは隠すのが当たり前
(Last Updated On: 2007年9月4日)私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。犯罪者がどのように攻撃するか？を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。攻撃に使える情報は全て使わない訳がありません。 最新版を使っているから安全ではない事も明白です。サーバに0day攻撃の脆弱性が発見された場合どの情報を使います？公開または推測できるバージョン情報に決まっています。 フィンガープリンティングでかなりの確率で推測可能、という議論もあるとは思います。しかし、適切に運用／設定されているシステムなら細かいバージョン番号までは推測できない場合が多いと考えられます。 犯罪者が攻撃に利用している、利用する可能性が
厚労省の電子申請ソフト欠陥、原因はパッチ更新の慢性的な滞り
雇用保険などを申請するための厚生労働省の電子申請ソフトに欠陥があった問題で、ソフトのパッチ更新が昨年から滞っている状態であったことが分かった。欠陥があったのは電子申請ソフトが採用しているサン・マイクロシステムズのJava実行環境ソフト「Java 2 Runtime Environment（JRE）」。問題のある電子申請ソフトを使い続けた場合、入力した個人情報が流出する恐れがある。システムの構築は日本ユニシスが担当している。 サン・マイクロシステムズは昨年の12月と今年5月の2度に渡ってパッチを公開していたが、厚労省はこのときも更新していなかった。6月にはサン・マイクロシステムズが、今回の問題の原因となった新たな脆弱性が見つかったと発表している。それを受けて6月26日に内閣官房情報セキュリティセンターがJREを導入している各省庁に注意を促した。しかし、厚労省では対策を講じず欠陥のあるソフトが
高木浩光氏のWinnyへの怨念 - よくわかりません
前から思ってたけど、なんなんだろう、この人の尋常ならざるWinny*1への憎しみは。ときおり根拠らしく述べる内容は、どう見ても「nyは絶対悪」の結論ありきの後付的な臭いがする物ばかり。 単なるアスペ性の粘着（によるバランス欠如）なのか。単なる成人型中二病なのか。 「病気」かどうかはどうでもいい。実際その症状は、それは日本におけるセキュリティの意識向上に相当貢献してる事は間違いないだろう。でも、それはやはりたまたまなのか。反逆の正義ネタとしてセキュリティに粘着してたら、それがたまたまヒットしたと。たまたま社会的にもセキュリティが重要な物になってしまったと。 それとも、本気で社会のためを思うのが先にあって、セキュリティの啓蒙活動をしてきたのだろうか。本気で社会のためを思って、本気で社会の発展の為にこそ、法も憲法も無視してnyの抹殺活動をしているのだろうか。 もちろん、仮にそうならそうで、それは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトバンク端末100機種以上にJavaScript関連の不具合
raguweb.net