「セキュリティ対策」
「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。 攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。セキュリティ対策っていうのはコードとは切り離された領域で行うDEPだったりASLRだったりX-Frame-OptionsだったりCSPだったりiframe sandboxだったり、そういうものがセキュリティ対策だ。コード上で書くのは「アプリケーションとして正しく動作するための処理」だけだ。 もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書く
弊社ホームページ改ざんに関するお詫びとご報告 | gihyo.jp
弊社ホームページにおいて、2014年12月6日11時～14時のあいだ、第三者からの不正アクセスによりサイトが改ざんされていた事が判明いたしました。ご利用頂いておりますユーザの皆さまにおかれましてはご迷惑をお掛けいたしまして、深くお詫び申し上げます。 なお、現在は被害を受けたサーバは復旧作業を実施済みです。ご利用ユーザーの皆さまの個人情報流出等は、現在のところ確認されておりません。 被害対象サイト／コンテンツ URL：http://gihyo.jp 改ざん内容とその影響 サーバの中身を入れ替えられ、外部のサイトにリダイレクトされるように設定されていた。 リダイレクトされていたサイト（アクセスしないようご注意ください） www.koushin-lawfirm.net live.livelistingreport.com 現在把握している改ざんされていた可能性がある期間 2014年12月6日
先程から騒ぎになっているbashの脆弱性について – 上田ブログ
確認しました（苦笑） （追記: envを抜いてましたが、それだとCシェル系で確認できないので加えました） ueda@remote:~$ env x='() { :;}; echo vulnerable' bash -c 'echo this is a test' vulnerable this is a test 最初のワンライナーでなにがおこってるかというと、xの値であるはずの「() { :;}; echo vulnerable」の、echo vulnerableの部分がなぜか実行されています。 bashの文法ではシングルクォートで囲んだ中のものは何がどう書いてあっても単なる文字列であって、evalとかshとかに突っ込まない限り実行されるわけはないので、これは実装ミスかと。（と、書いたのですが環境変数に関数を仕込めるという仕様があるという話を初めて聞いて愕然と・・・。いま慌てて調べてます
ASCII.jp：データ消失！あのとき、ファーストサーバになにが起こったか？ (1/2)｜データ消失事故から2年！ファーストサーバ、再生への第一歩
今から2年前の2012年の6月20日、レンタルサーバー会社のファーストサーバは、大規模な顧客データの消失事故を引き起こした。あのときなにが起こったか？ ファーストサーバのさまざまな部門の担当に、当時の状態を振り返ってもらった。 ファーストサーバは今も変わらずビジネスを展開している ファーストサーバの顧客データ消失事故に関するドキュメンタリーを書きたいと思った。事故の原因究明や責任の所在を明らかにするのではなく、当事者の話を積み上げていくような記事が書きたいと思った。 そして、今回ファーストサーバの全面的な協力により、事故当時から現場を統率してきた現代表取締役社長の村竹昌人氏をはじめ、営業、開発、運用、マーケティング、広報、サポート、管理など各部門の担当者に話を聞くことができた（以下、敬称略・役職は現職）。 事故から2年間の間、ファーストサーバはひたすら事故の影響を受けたユーザーへの対応と再
2014-06-20
はてなへのリスト型アカウントハッキングと思われる不正ログインについてのご報告と、パスワード変更のお願い 昨日6月19日（木）、はてなアカウントにおいて、ご登録ユーザーご本人以外の第三者による不正なログインが発生したことを確認しました。同日、疑わしいIPアドレスからのアクセスを遮断しました。このお知らせは本告知と並行して、全ユーザー様にも現在、メール送信しております。 前回告知した不正ログインと同様に、他社サービスから流出または不正取得されたアカウント情報（IDとパスワードの組み合わせ）を流用された「リスト型アカウントハッキング（リスト型攻撃）」である可能性が高いと考えています。 参考資料：「リスト型アカウントハッキングによる不正ログインへの対応方策について」（総務省） http://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000063.h
Twitter連携アプリが乗っ取られる 「ツイート数カウントくん」ユーザーが身に覚えのないブロック
Twitter連携アプリ「ツイート数カウントくん」のアクセストークンが流出し、ユーザーが意図せず特定のユーザーをブロックする事態が多発していたことが分かった。作者の@bombom583さんは6月14日、同アプリを削除。15日付けの告知で、「被害にあった方々に深くお詫びする」と謝罪している。 ツイート数カウントくんは、1日のツイート数をカウントし、自動でつぶやくTwitter連携アプリ。アクセストークンは、Twitterアプリを認証した際、そのユーザーに代わってフォローやブロックなどの操作を行える鍵。この鍵が何らかの原因で流出し、ユーザーのアカウントが実質的に乗っ取られた形になった。 ブロックを受けたユーザーが13日、「一晩で大量にブロックされた」とTwitterで報告。数日で12万件のブロックを受けたという。意図せずブロックしていたユーザーに連携アプリリストを公開してもらうなどして調べたと
Googleドメイン用の不正証明書が発行される、各社が失効措置へ
「google.com」「.google.co.jp」などのドメイン用の不正証明書が発行されていたことが分かり、Google、Microsoft、Mozillaが対応を表明した。 米Googleは12月7日、同社傘下の複数のドメイン用に不正なデジタル証明書が発行されていたことが分かり、問題の証明書を失効させるなどの措置を講じたことを明らかにした。Googleから連絡を受けたMicrosoftやMozillaも対応を表明した。 Googleによると、不正な証明書は12月3日に発見され、調べたところ、フランスの政府系認証局ANSSI傘下の中間認証局で発行されていたことが分かった。 電子証明書は、ユーザーがアクセスしているWebサイトが本物であることを確認するために使われる。不正な証明書を利用すれば、偽サイトであってもWebブラウザの警告が表示されず、ユーザーがだまされて個人情報などを入力してし
不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）| JINS - 眼鏡（メガネ・めがね）
平成25年３月15日「不正アクセスによるお客様情報流出の可能性に関するお知らせとお詫び」でご報告いたしました当社オンラインショップに対する不正アクセス（以下、「本件不正アクセス」といいます。）により、お客様をはじめとする皆様に多大なるご迷惑およびご心配をおかけしましたことを深くお詫び申し上げます。 当社は、事案発覚直後より、逐次最新情報をご報告させていただいておりましたが、この度、当社、専門調査機関および情報漏えい事故調査委員会による本件不正アクセスに関する一連の調査が終了いたしましたので、下記のとおりご報告させていただきます。 なお、本件不正アクセスに関するお客様へのご対応および再発防止に対する取り組みについては引き続き行ってまいりますが、本件不正アクセスに対する調査結果につきましては、特段の報告事項が発生しない限り、下記をもって最終報告とさせていただきます。 当社は、自社が運営する「J
eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策
eBook Japanに対する不正アクセスについて、詳細の発表があり、いわゆる「パスワードリスト攻撃」であることが発表されました。 前回のご報告までは「複数のIPアドレスからログインページに対して機械的に総当たり攻撃等を行う大量アクセス行為（ブルートフォースアタック）」とご説明しておりましたが、詳細調査の結果、「不正の疑われる複数のIPアドレスからログインページに対して、予め持っていたログインIDとパスワードの適用可否を試行する大量アクセス行為」であることが判明いたしました。 つまり、大量アクセス行為を仕掛けてきた者は、当社以外の他のサービスなどで他のサービスのログインIDとパスワードを不正に入手し、ユーザーがログインIDとパスワードを共通に設定している可能性を狙って当社サービスに不正にログインしようとし、上記件数についてはログインに成功してしまったということです。 そのように判断した根拠
ファーストサーバ事件で情報漏洩の2次被害、2300社に影響か
ヤフー子会社でレンタルサーバー事業を展開するファーストサーバは2012年6月29日、6月20日に発生した大規模障害（関連記事）の復旧作業において、情報漏洩が起きていた可能性があると発表した。 発表文によると「対象サーバー数103台、最大2308者（法人や非法人）分の復元データの一部が、同じく障害の影響を受けた145者のデータ領域に混在した可能性がある」という。 ファーストサーバのサービスでは、1台の物理サーバーにつき最大で60契約を収容している。平常時はある顧客は他の顧客のファイルにアクセスできないように制御されているため、情報漏洩は発生しない。 ところが6月20日の大規模障害でファイルが消失したため、可能な範囲でファイルの復元を試み、復元できたものを顧客に提供していた。この時に、ある顧客に提供したファイルに別の顧客のファイルが混入したまま提供してしまった可能性があるという。 発表文では、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Sass を今すぐ実務で使おうよ！ « LINE Engineers' Blog