GodaddyのSSL証明書にドメイン認証の脆弱性があり8850件の証明書が失効された
エグゼクティブサマリ GoDaddy社の発行するドメイン認証SSL証明書に認証不備の脆弱性があり、予防的な処置として8850件の発行済証明書が失効された。これは同期間に発行された証明書の2%未満である。現在は脆弱性は解消されている。 概要 GoDaddy社は米国のホスティング（レンタルサーバー）やレジストラの大手で、認証局（CA）の事業も手がけています。 GoDaddyが発行するドメイン認証証明書の認証手続きに不備があったとして報告されています。 In a typical process, when a certificate authority, like GoDaddy, validates a domain name for an SSL certificate, they provide a random code to the customer and ask them to p
ブルース・シュナイアーさんの安全なパスワード文字列の作り方
前回は、サービスごとにユニークなパスワードを作る方法を提案しました。 今日一緒にランチを食べていた、元同僚からこんなことを教わりました。 「似たことを、ブルース・シュナイアーが言ってたよ」 ブルース・シュナイアー（Bruce Schneier、1963年1月15日 – ）は、アメリカ合衆国の暗号研究者、コンピュータのセキュリティ専門家、作家。BT Counterpaneのコンピュータセキュリティと暗号に関する著作があり、Counterpaneインターネットセキュリティ社[1]の創設者であり、最高技術責任者（CTO）でもある それはこちらのエントリでした。 興味深かったのでざっくりサマって見ます。 私の英語力は非常に残念なので、ミスがあったらぜひ教えて下さい。 Passwords / paul.orear はじめに 一番良いパスワードは、それが壊れた言葉であることです。 と言うのは攻撃者はた
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
パスワード認証を脆弱にする10の方法とアンチパターン
いかにしてパスワード認証を脆弱にするか。プログラミング黎明期からずっとデベロッパーの頭を悩ませ続ける問題です。 ここでは脆弱なパスワード認証を実現するための方法を紹介します。 パスワード自動入力の禁止 不届きなブラウザがパスワードを記憶してしまうことがあります。 パスワードは間違いの無いように、ひともじひともじ、人間が入力するべきです。 <input name="pw" type="password" autocomplete="off" /> とするのは常識ですね。ブラウザのパスワード管理機能より、脳内の文字列の方がずっと安心です。 フォームを動的生成、AjaxでPOST cursor: textスタイルで偽input などで、ブラウザのパスワード保存をスキップする方法もあります。 パスワード貼り付けの禁止 貼り付けも自動入力と同罪です。onpaste属性を利用して <input nam
勝手に査読:Webアプリにおける11の脆弱性の常識と対策
「Webアプリにおける11の脆弱性の常識と対策」という記事を久しぶりに読みました。出た当事も思いましたが、基本的な誤りが多く、読者が誤解しそうです。このため、編集部から頼まれたわけではありませんが、「勝手に査読」してみようと思います。 細かい点に突っ込んでいくとキリがないので、大きな問題のみ指摘したいと思います。 ※2013年2月25日追記 このエントリに対して、編集部が元記事を修正くださいました。徳丸も修正に協力いたしましたが、十分正確な内容ではないことをお含みおきください。 ※追記終わり 同記事の想定読者は誰か査読にあたり、この記事の想定読者を明確にしておいた方がよいですね。記事の冒頭には、連載の説明があります。 本連載は、JSP／サーブレット＋StrutsのWebアプリケーション開発を通じて、Java言語以外（PHPやASP.NET、Ruby on Railsなど）の開発にも通用する
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
CookieにログインIDを保存してはいけない
phpproのQ&A掲示板で下記の質問を読みました。 ログインの際に、クッキーにログイン情報を保存し、ログアウトの際には、フォームタグの中でPOSTでログアウトの為の値を飛ばし、値を受け取ったらクッキーの有効期限をマイナスにしてクッキー情報を消すというログアウト処理を作っています。 同一ページでのCookieでのログアウト処理より引用 クッキーにそのままログイン情報を保持するのはよくありませんね。質問を更に読むと、以下のソースがあります。 setcookie("logid",$row["f_customer_logid"],time()+60*60*24); setcookie("point",$row["f_customer_point"],time()+60*60*24);どうも、SQL呼び出しの結果からログインIDを取り出し、それをそのままCookieにセットすることで、ログイン状態
monoweb.info - このウェブサイトは販売用です！ - monoweb リソースおよび情報
このウェブサイトは販売用です！ monoweb.info は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、monoweb.infoが全てとなります。あなたがお探しの内容が見つかることを願っています！
「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...
タイトルが長くて略称があれば知りたい感じの「安全な Web アプリケーションの作り方」を暇を見つけて読んでいます。今まであいまいなままだった部分を順を追って説明してくれるので、本当に助かります。Web アプリ作りの初心者は卒業したかなーという人は必ず目を通しておくと良いと思います。 Cookie を用いたセッションについて復習 「HTTP はステートレスで」とかいう話はよく聞きますが、じゃあどうやってセッション管理するのがいいの？って話をよく考えると体系的に聞いたことがなかった！というわけで、この本で文字通り体系的に学び直すことができました。 その中でも、「セッション ID の固定化」という話題はちゃんと分かってなかった部分があったので、こちらのサイトを参考に PSGI なアプリケーションを作ってみました(僕の書いたアプリ自体はその他の脆弱性に溢れていますがｗ)。コードはエントリの最後に。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高速ハッシュの 脆弱性