GitHubユーザーのSSH鍵6万個を調べてみた - hnwの日記
（2015/1/30 追記）時期は不明ですが、現時点のgithub.comはEd25519鍵にも対応しています。 （2016/5/31 追記）「GitHubにバグ報告して賞金$500を頂いた話」で紹介した通り、既に弱い鍵はGitHubから削除され、新規登録もできなくなっています。 GitHub APIを利用して、GitHubの31661アカウントに登録されているSSH公開鍵64404個を取得してみました。抽出方法*1が適当すぎて偏りがあるような気もしますが、面白い結果が得られたと思うのでまとめてみます。 SSH鍵の種類 鍵の種類 個数 割合 RSA鍵 61749 (95.88%) DSA鍵 2647 (4.11%) ECDSA鍵 8 (0.01%) 約6万個の鍵のうち、8個だけECDSA（楕円DSA）鍵が見つかりました！常用しているのか試しに登録してみただけなのかはわかりませんが、何にせよ
改ざん攻撃はこう防げ！Webサイトの正しい守り方
Webサイトの改ざんが後を絶たない。今年3月には，国内で中国からのSQLインジェクション攻撃が多数発生し，話題になった。Web改ざんは以前から継続して起こっている問題だが，改ざんする側の目的が変わると同時に攻撃の技術が進歩し，ファイアウォールなど従来の対策では防御できなくなってきている。そこで本連載では，最近のトピックを中心にWebサイト改ざんの代表的な手口を紹介し，その対策を解説する。 目次 第1回 急増するWebサイト改ざん事件 第2回 いつも基本はパスワード管理 第3回 サーバー・ソフトのぜい弱性をなくす 第4回 話題のSQLインジェクションを防ぐ 第5回 クロスサイト・スクリプティング対策も忘れずに
高木浩光＠自宅の日記 - B-CAS社の個人情報登録サイトのSSL証明書がNTT DATA
■ B-CAS社の個人情報登録サイトのSSL証明書がNTT DATA B-CAS社の「オンラインによるB-CASカードのユーザー登録」の画面から、登録画面に進むと、個人情報入力画面が現れるのだが、ここでページが https:// になっていることを確認の上、サイト証明書の内容を確認してみると、「NTT DATA CORPORATION」と表示される。 よく見てみると、さっきまでは b-cas.co.jp を閲覧していたはずが、この画面はいつのまにか、b-cas.jp という別サイトに飛ばされている。 しかも、b-cas.jp ドメインの保有者が誰なのか、whois で調べてみると、さらに別の会社になっている。 不特定多数からの大量の登録を受け付けるサイトにしてはずいぶんと稚拙だ。
徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本稿ではSQLインジェクション対策として、SQLのエスケープ処理の方法について検討する。 最近SQLインジェクション攻撃が猛威を振るっていることもあり、SQLインジェクションに対する解説記事が増えてきたようだが、対策方法については十分に書かれていないように感じる。非常に稀なケースの対応が不十分だと言っているのではない。ごく基本的なことが十分書かれていないと思うのだ。 SQLインジェクション対策には二通りある。バインド機構を使うものと、SQLのエスケープによるものだ。このうち、SQLのエスケープについて、十分
【レビュー】IPAが無償提供するソフト「安全なウェブサイトの運営入門」を体験する | パソコン | マイコミジャーナル
IPAは、増加するSQLインジェクション攻撃などの危険性の認知とセキュリティ対策の重要性を喚起するために、「安全なウェブサイト運営入門−7つの事件を体験しウェブサイトを守り抜け−」を無償で公開している。本稿では、そのソフトウェアを紹介する。 セキュリティ事故を模擬体験 「安全なウェブサイト運営入門」は、架空の会社でネットショップの開設から約3年の中で発生する各種のセキュリティ事故を題材にし、どのような対応が望ましいといったことをゲーム感覚で体験できる。動作環境は、OSがWindows Vista、XP(SP2)で、DirecX 3以上、Adobe Flash Player 8以上、インストールのためにHDDの空き要領が300MB以上必要になる。BGMなどもあるので、サウンド再生環境もあると望ましい。 本ソフトでは、新たにネットショップの担当になった主人公が SQLインジェクション クロスサ
AJAX vs. Flash、fladdictブログより
昨日のエントリーで、深津氏のブログに「Flash使いから見たAJAX」のことが書かれていて読んで勉強になった話を書いたのに、それらのエントリーへのリンクを張るのを忘れていたので、今日はそのリンク集。 以下のエントリーは、AJAXが騒がれ始めた2005年３月から２００６年１月の間に書かれたものだが、この「閉じたFlash」vs.「オープンなAJAX」という構図は相変わらずである。特に、FlashはActionScript3.0で大幅に言語として整備されたにも関わらず、AJAXに押されぎみなのはなんとも微妙である。 それで思い出したのが、GoogleにUIEngineの説明に行った時の会話。「もっとオープンにしてくれ」という彼らに、「Flashはどうなんだ」と答えると、「Macromediaの連中にもオープンにしろと言いつづけている」と言う。GoogleもYoutubeなど一部のサービスではF
ウェブサービスAPIにおける『成りすまし問題』に関する一考察
先週の末に、はてなのウェブ・サービスAPIを使ったMash-upアプリをFlash上で作り始めていきなりつまずいたのが、Cross-Domainセキュリティ。satoshi.blogs.comから取得したswfファイル上のActionScriptからb.hatena.ne.jp下にあるRSSフィードだとかXML-RPCにアクセスができないのだ。 「確か方法があったはず」と調べてみると、はてな側がサーバーにcrossdomain.xmlというファイルを置いて明示的にCross-Domainアクセスを許可していなければならない、という。そこで見つけたのが、「Flashから各APIの操作、データのロードができるよう、サーバ上に「crossdomain.xml」というポリシーファイルの設置をお願いしたい。」というはてなアイデアへのリクエスト。2006年の2月にリクエストが出されているのだが、11月
ITmedia エンタープライズ：大量の「はまちちゃん」を生み出したCSRFの脆弱性とは？
「mixi」上で、あるURLをクリックすると「ぼくはまちちゃん！」という日記が勝手にアップされてしまうという現象が多発した。その原因はCSRFの脆弱性だ。 4月19日以降、ソーシャル・ネットワーキングサイトの「mixi」で、URLをクリックすると勝手に「ぼくはまちちゃん！」というタイトルで日記がアップされてしまうという現象が多発した。 サービスを提供しているイー・マーキュリーでは、この現象について一応の対処は取った模様だ。ただ、技術的な詳細については「ハッキングでもなく、サーバ攻撃やウイルスでもない。ID盗難などの被害は発生していない」という回答のみで、「それ以上はコメントできない」と述べるにとどまっている。 だがある意味、このコメントは正しい。「はまちちゃん」現象は、ウイルスなどの仕業ではないからだ。 正規ユーザーの操作で「意図しない」結果に URLをクリックすると勝手に日記が書き込まれ
Yahoo! 足あとちょう(ver.302) :: ぼくはまちちゃん！
Yahoo! 足あとちょう (ver.302) ※IE系のブラウザかつ、Yahoo!ログイン済みだったら、うまくいけば↓にYahoo! IDが表示される…！ きみのYahoo! IDをとってこれるってことは、他の情報もとってこれるかもしれないね！ それどころか、 掲示板への書き込みとか、メールとかの、何らかの操作もできちゃうかもしれない！ きみのIDで…！(できるかどうかは調べてないけど) もし単にIDの文字がとれるだけだったとしても、 人によってはヤフオクの履歴(評価)なんかはすごい個人情報だったりするから、注意しないとね！ 架空請求とかに利用されたらきっと怖いよ！ 下のリンクにある、他の足あとちょうと組み合わせたりするのも、かなりヤな感じ…！ mixiの誰それさんは、xxx県在住で、ヤフオクでxxxxを買っている とかね。 これも CSSXSS っていうIEのセキュリティホールを使った
まこと先輩と星野君とCSRFの微妙な関係
星野君の検査には見落としがあります！ ミーティングの開始時間を5分ほど過ぎたところで、ようやく高橋さんが姿を現した。 高橋さん 「じゃあ、早速始めますか。まずは……」 高橋さんによる大まかな仕様の確認が終わって、星野君へとバトンタッチされた。星野君は用意してきた資料に基づき、発見した脆弱性についての説明を行った。今回発見した脆弱性の話は、以前行ったWebアプリケーション検査と似た話であったので、すんなり説明できた。開発会社の2人にもちゃんと理解してもらえたようで一安心だ。 最後に、赤坂さんの説明に移った。赤坂さんには、事前に高橋さん経由で星野君の資料が渡っていたみたいで、星野君の説明内容を踏まえたうえでの話になるようだ。 赤坂さん 「それでは、いまの星野君の検査結果を補足しますね。このWebアプリケーションにはクロスサイトリクエストフォージェリが存在しています」 赤坂さんは星野君が発見でき
＠IT：クロスサイトスクリプティング対策の基本
最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング」と呼ばれる脆弱性が有名であるが、クロスサイトスクリプティング脆弱性について正確に理解している人が依然として少ないと感じる。 本稿では、クロスサイトスクリプティングとはどのような脆弱性であるのか、この脆弱性を持ったサイトが攻撃されるとどのような被害が起き得るのか、なぜそのようなセキュリティホールが作り込まれてしまうのか、どのように対策をすればよいのかを解説していく。 ※以下本文中では、クロスサイトスクリプティング脆弱性のことを「XSS」と表記する。「Cross Site Scripting」の略であるから「CSS」と表記している記事もあるが、「Cascading Style Sheets」の略も「CSS」となり紛らわしいため、「XSS」と表記する場合が多くなってきている。本稿で
カスタムポリシーファイル crossdomain.xml について - yoshiweb.NET
Flash でドメインをまたいで外部ファイルを読み込みたい場合 参照側のサーバー（外部ファイルが置いてある方）に crossdomain.xmlという名前のXMLが必要らしいです。 XMLの書き方は 全てのドメインのアクセスを許可する（どこからでもOK〜！にする）ときは 以下の記述をしたXML「crossdomain.xml」をルートディレクトリに配置 他の全てのドメインから読み込まれるのを防ぐ（他のドメインは全部ダメー！にする）ときは crossdomain.xmlファイルを設置しない！ もしくはallow-access-from タグのない crossdomain.xml ファイルをルートディレクトリに配置 crossdomain.xml の各要素の内容 メタポリシー設定 all： すべてのポリシーファイルが許可されます。 by-content-type： Content-Typeがt
crossdomain.xml と CSRF 脆弱性について - 2nd life (移転しました)
crossdomain.xml を安易に設置すると CSRF 脆弱性を引き起こす可能性があります。というのも、ここ数が月、それなりの数の crossdomain.xml による CSRF 脆弱性を発見し(現在、それらのサイトでは対策がなされています)、まだまだ Web プログラマに脆弱性を引き起こす可能性がある、という考え方が浸透してないんじゃないか、と思ったので。 先月、Life is beautiful: ウェブサービスAPIにおける『成りすまし問題』に関する一考察にも crossdomain.xml について書かれてたのですが、その後もいくつかのサービスで crossdomain.xml を許可ドメインすべてにしているサービスがあったので、注意喚起としてエントリーに書き起こします。 自分も一年半ぐらい前は、crossdomain.xml を許可ドメインすべて ('*') にして設置し
第4回 Flash、JSONでのクロスドメインアクセス | gihyo.jp
Flashを用いたクロスドメインアクセス 前回までは、クロスドメインアクセスを行うための方法として、リバースProxyを使う方法とJSONPを使う方法を紹介しましたが、どちらの方法も少し変わった方法だったと思います。なにか無理やりのように感じた方もいるのではないでしょうか。今回紹介するFlashを使った方法では前回までの方法とは違い、自然な形でクロスドメインアクセスを行うことができます。 Flashでは、呼び出される側で設定を行うことでクロスドメインアクセスが可能になります。 設定といっても非常に簡単で、呼び出される側のWebサーバにcrossdomain.xmlというファイルを設置するだけです。このときのURLは http://www.example.com/crossdomain.xml となります。 ファイルの内容は以下のようになります。 crossdomain.xmlの内容 <cr
カスタムポリシーファイル crossdomain.xml について - yoshiweb.NET-blog
Flash でドメインをまたいで外部ファイルを読み込みたい場合 参照側のサーバー（外部ファイルが置いてある方）に crossdomain.xmlという名前のXMLが必要らしいです。 XMLの書き方は 全てのドメインのアクセスを許可する（どこからでもOK〜！にする）ときは 以下の記述をしたXML「crossdomain.xml」をルートディレクトリに配置 他の全てのドメインから読み込まれるのを防ぐ（他のドメインは全部ダメー！にする）ときは crossdomain.xmlファイルを設置しない！ もしくはallow-access-from タグのない crossdomain.xml ファイルをルートディレクトリに配置 crossdomain.xml の各要素の内容 メタポリシー設定 all： すべてのポリシーファイルが許可されます。 by-content-type： Content-Typeがt
窓の杜 - 【NEWS】MS、Vista/Server 2008に対応した脆弱性チェックツール「MBSA」v2.1を公開
Microsoft Corporationは22日、システム管理者向けの脆弱性チェックツール「Microsoft Baseline Security Analyzer（MBSA）」v2.1を公開した。今回公開されたv2.1での主な変更点は、Windows VistaおよびWindows Serever 2008に対応したこと。また、64ビット版のOSやコンポーネント、「SQL Server 2005」などの脆弱性チェックにも対応した。 「MBSA」は、Windowsがインストールされたネットワーク上の複数PCに対して、セキュリティ上の脆弱性を調査できるシステム管理者向けのソフト。OSだけでなく「SQL Server」「Microsoft Office」など同社が提供する製品全般におけるセキュリティ更新プログラムの適応状況を調査したり、セキュリティ上好ましくないPCの設定を検出できる。 本ソ
高木浩光＠自宅の日記 - 新型myloのオレオレ証明書を検出しない脆弱性がどれだけ危険か
自己署名の証明書になっていた。 これは明らかにセキュリティ脆弱性だ。この種類の脆弱性（ブラウザが証明書を検証しない）は、伏せておくよりも早く事実を公表して利用者に注意を促した方がよいという考え方もあり、すぐに日記に書こうかとも考えたが、このケースではIPA、JPCERT/CCを通した方が修正が早く行われるのではないかと考え、IPAの脆弱性届出窓口に通報した。 この届け出は3月27日に受理された。そして本日、JVNで公表となった。修正版が提供されているので、利用者はアップデートで対応できる。 JVN#76788395 ソニー製 mylo COM-2 におけるサーバ証明書を検証しない脆弱性, JVN, 2008年4月23日 パーソナルコミュニケーター "mylo" COM-2 セキュリティ脆弱性対策プログラムご提供のお知らせ, ソニー株式会社, ソニーマーケティング株式会社, 2008年4月2
第8回 クロスサイトスクリプティング対策の落とし穴 | gihyo.jp
今回は熟練したWebアプリ開発者なら常識のクロスサイトスクリプティング対策の落とし穴を紹介します。 JavaScriptを排除しているつもりで排除に失敗？！ 最近はSanitize（サニタイズ）という言葉の代わりにValidation（検証）という言葉をよく聞くようになったと思います。Sanitizeの意味を辞書で調べると「汚れている物をきれいにすること」とされています。この意味の通り汚れた変数をきれいにして使えば安全に利用できるとする考え方に基づくのがサニタイズ手法です。典型的な例は、「テキストを出力する前に"<"と">"を取り除く」方法があります。 例1 "<"と">"をereg_replaceで取り除く $safe_text = ereg_replace($_GET['text'], '[<>]', ''); この$safe_textを <a href="/script.php?t
PHPパッチ、一部の脆弱性は未修正
先日リリースされたPHP 5.2.3で対処されたはずの脆弱性が、実は修正されていないことが分かったと、セキュリティ研究者が指摘した。 PHPのアップデートで対処されたはずの脆弱性が、実は修正されていないことが分かったと、セキュリティ研究者が指摘した。 PHP開発チームは6月1日にアップデートバージョンの5.2.3をリリースし、複数の脆弱性に対処した。リリースノートによれば、この一環として「chunk_split()」の整数オーバーフローの脆弱性も修正されたはずだった。 しかしこれについて、PHPチームを脱退した研究者のステファン・エッサー氏が、自身の運営するPHPセキュリティブログで問題を指摘した。同氏によると「フィックスは壊れているばかりかまったく無意味」であり、PHP 5.2.3で整数オーバーフロー問題は未修正のまま、別の行に移されただけだという。 US-CERTも6月6日付で、PHP
19. マルチバイト文字とXSS脆弱性
比較的新しい攻撃方法に、不完全なマルチバイト文字列を送信することでHTMLに 記述されているクォートを無効化する方法があります。この攻撃はHTML エス ケープのみでは防げない事に注意が必要です。では、どのように対策をすれば良 いのでしょうか？ まずは、不完全なマルチバイト文字を利用してクォート（"）を無効化できるこ とを確認しましょう。次のスクリプトをブラウザから実行して下さい（最後の ダブルクォテーションとPHPタグの間にスペースを入れないで下さい）。 <?php $str = urldecode('%81'); header('Content-Type: text/html; charset=SJIS'); ?> <?php echo htmlentities($str, ENT_QUOTES, 'SJIS') ?>" コードが分かりづらいので注意してください。PHPタグを２つに大別
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
