STOP! パスワード使い回し!キャンペーン2018
□ パスワードの文字列は、長めにする（12文字以上を推奨） □ インターネットサービスで利用できる様々な文字種（大小英字、数字、記号）を組み合わせると、より強固になる □ 推測されやすい単語、生年月日、数字、キーボードの配列順などの単純な文字の並びやログインIDは避ける □ 他のサービスで使用しているパスワードは使用しない これまでは、英大文字・小文字、数字に加えて記号を混ぜ込むことが多々推奨されてきました。しかし、「アルファベットを数字や記号に置き換える」等の方法では、憶えやすさが損なわれたり（※後述のコラムを参照）、「p@ssword」（aをアットマーク「@」に置き換え）のような置き換えの場合、辞書攻撃であらかじめ推測されている恐れがあります。したがって、現在では、これまでの方法より数文字でも多くの文字を使うことが望ましいと考えられています。 例えば、8文字で英大小文字＋数字＋記号（9
)
信頼できるコンピューティングのセキュリティ開発ライフサイクル
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 Steve Lipner Michael Howard Security Engineering and Communications Security Business and Technology Unit Microsoft Corporation March 2005 日本語版最終更新日 2005 年 5 月 27 日 概要 : この文書では、マイクロソフトが悪質な攻撃に耐える必要のあるソフトウェア向けに採用した開発プロセスである、信頼できるコンピューティング (Trustworthy Computing) のセキュリティ開発ライフサイクル (Security Development Lifecycl
共通セキュリティ設定一覧CCE概説 (パスワード編)
共通セキュリティ設定一覧CCEは、SCAP の構成要素の1つであり、 PCの「設定上のセキュリティ問題」を解決するための共通的なセキュリティ設定一覧です。 本ページでは、CCE(Common Configuration Enumeration)で規定されているセキュリティ項目について、 パスワード設定に関連する項目の解説を MyJVN セキュリティ設定チェッカでの確認方法を交えて紹介します。 利用者のPCのセキュリティ設定値とCCEの具体的な内容と対策手順を参照して確認することで、 CCEについてより理解が深められます。また、パスワード設定における各公的機関が 推奨しているセキュリティ設定値と利用者自身のPCの設定を見比べることで、セキュリティ設定の 見直しに役立てることができます。 CCEのより詳しい解説については、共通セキュリティ設定一覧CCE概説を参照してください。 ■ 共通セキュリ
glibc の脆弱性 CVE-2015-0235（通称：GHOST）についてまとめてみた - piyolog
2015年1月27日(現地時間) Qualysはglibc(GNU C Library)に脆弱性を発見し、情報を公開しました。ここでは関連情報をまとめます。(暫定まとめなので精度低め、網羅性無しです。。) (1) 脆弱性関連情報 Qualysが公開した脆弱性情報 The GHOST Vulnerability Qualys Security Advisory CVE-2015-0235 注意喚起 IPA (注意) libc の脆弱性対策について(CVE-2015-0235) 脆弱性の概要 glibcの__nss_hostname_digits_dots() にヒープバッファオーバーフローの脆弱性。 当該関数はglibcのgethostbyname()とgethostbyname2()から呼ばれている。 アプリケーションによっては、DoS、またはリモートから任意のコードが実行可能となる可能性
はてなIDがクッキーで約50サイトに送られていた話 - こせきの技術日記
(追記) 要点を整理をした記事を書きました。こっちのほうが、余計なこと書いてない分、わかりやすいかもしれません。 はてなブックマークに、マイホットエントリーという大変すばらしい機能があって、毎日見ている。 マイホットエントリー機能のご紹介 - はてなブックマーク開発ブログ 自分のマイホットエントリーのURLはこう。 http://b.hatena.ne.jp/koseki/ マイホットエントリーを見ていると、はてなID koseki を含むリファラが各サイトに送信される。 リファラは Google アナリティクスの __utmz に記録される。 Firefox には、全クッキーの値を横断検索する機能がある。 設定 ＞ プライバシー ＞ Cookieを個別に削除 ＞ 検索 自分の環境では、およそ50個*1のクッキーに koseki という文字列が含まれていた。 あんなサイトやこんなサイトを、
formタグを利用したtoken奪取 - ma<s>atokinugawa's blog
スクリプトの実行はできない（XSS対策されている）し、tokenは導入されている（CSRF対策されている）のに、tokenを奪取され、不本意な操作をされてしまう例というのを1つ、やってみたいと思います！ 実証だニャン！ http://d.hatena.ne.jp/kinugawamasanyan/20101012/nyan 原理 こういうフォームがあったら、submitボタンを押下した時にtokenの値がA、Bどっちにポストされるでしょうか。 <form action="A" method="post"> <form action="B" method="post"> <input type="hidden" name="token" value="123123123"> <input type="submit"> </form> 答えはAです。 つまり本来設置されたフォームより前に別のf
hashdos攻撃をmod_securityで防御する(CentOS+yum編)
このエントリでは、hashdos対策としてのmod_securityの導入と設定の方法を説明します。CentOS環境でyumによりApacheを導入しているサイトに対して、yumによりmod_securityを導入するというシナリオで説明します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。まだhashdosによる攻撃事例は報告されていないようですが、既に攻撃コード（PoC）が公表されているため、いつ攻撃が起こっても不思議ではない状況です。 PHPも影響を受けるプラットフォームであり、PHP5.3.9で対処予定となっていますが、まだPHP5.3.9はリリースされて
Cookieによるhashdos攻撃と対策
このエントリでは、Cookieを用いたhashdos攻撃の可能性について検討し、実証結果と対策について報告します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。 先の記事でも説明しているようにPOSTパラメータ(HTTPリクエストボディ)に多数のパラメータを仕込む攻撃が典型的ですが、POSTパラメータ以外のパラメータを用いた攻撃についても検討しておかないと、防御漏れの可能性が生じます。 そこで、POSTパラメータ以外を用いた攻撃方法について検討します。 POST以外に多数のパラメータを仕込めるかPOST以外に多数のパラメータを仕込む場所があるでしょうか。候補となる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
