タグ

Web制作とセキュリティに関するpmakinoのブックマーク (125)

  • 千葉県のWebアクセシビリティ調査結果|有限会社ユニバーサルワークス

    公式サイト:千葉県ホームページへようこそ 音声化対応2点 操作性2点 可読性3点 レイアウト3点 汎用性3点 ファイルサイズ334,475バイト リンクページ数171 トップページと浅い階層だけの表面的なリニューアルがなされたが、各コンテンツは共通するナビゲーションすら付与されていないため、使い勝手の向上には寄与していない。 毎年のようにコメントしている問い合わせページのドメイン及びサーバ証明書について 「PANASONIC SYSTEM SOLUTIONS MARKETING CO.,LTD」名義のpref-event-chiba.jpドメインではなく、別の汎用JPドメインに移行されている。 ドメイン名自体を信頼するための情報として、サーバ証明書があることや、汎用JPドメインは誰でも取得できることを考慮すれば解決にはなっていない。 以前の「pref-event-c

    pmakino
    pmakino 2009/09/05
    「以前の「pref-event-chiba.jp」は空いていたので、当社代表清家順が取得しました。」
  • 千葉県とは無関係なページ

    pmakino
    pmakino 2009/09/05
    「2008年の終わりごろまでは、千葉県が問い合わせやらイベント参加申し込みやらで使っていたようですが、どうしてこんなことになっているのでしょう・・・。」
  • パスワードのマスキングは廃止すべき | スラド

    ウェブのユーザビリティの権威であるヤコブ・ニールセン氏が「パスワードのマスキングはセキュリティを向上することはなく、かえってユーザビリティを低下させる」との論を自身のサイトuseit.comで展開している(家記事より)。 ニールセン氏によると、システムステータスを可視化しユーザにフィードバックを提供することはユーザビリティの基原則であるとのこと。パスワード入力時に文字列を表示せずに「・」や「●」などの記号を表示することはこの原則と相反すると主張する。 入力時にパスワードがマスクされると誤入力が増えるだけでなく、入力内容を確認できないことからユーザは不安を覚えるという。この不安感からユーザは必要以上にシンプルなパスワードを設定したり、パスワードをどこかのファイルからコピペして、セキュリティを低下させる結果となるとのこと。パスワードのマスクは簡単である上、インターネットの黎明期からデフォル

  • パスワード入力の「****」は不要? 研究者の間で激しい論議

    入力したパスワードは「****」で隠さずに、はっきり見えるようにした方がいいのではないか。そんな提案をめぐり研究者が賛否両論を展開している。 Webサイトなどでパスワードを入力する際、「****」を使って入力した文字が見えないようにする必要はないのではないか――。そんな提案をめぐり、研究者が賛否両論を展開している。 最初に問題を提起したのはWebユーザビリティ研究の第一人者ヤコブ・ニールセン氏。「パスワードを入力する際、画面に“****”としか表示されないのはユーザビリティ上問題がある。一般的に、パスワードを隠してもセキュリティは向上しない。それどころかログインに失敗してコストがかさむ」と指摘し、入力したパスワードの文字がはっきり見えるようにした方がいいと提言した。 著名なセキュリティ研究者のブルース・シュナイアー氏も、ブログでニールセン氏の意見に賛同を表明。「パスワードの文字を表示すれば

    パスワード入力の「****」は不要? 研究者の間で激しい論議
  • パスワードは隠すべきか? | Accessible & Usable

    公開日 : 2009年7月26日 (2024年3月23日 更新) カテゴリー : ユーザビリティ ウェブユーザビリティの第一人者である Jacob Nielsen (ヤコブ・ニールセン) 氏が、自身のブログ記事「Alertbox」の中で、「Stop Password Masking」という興味深い問題提起をしています。通常、ウェブサイトなどでパスワードを入力すると、画面には入力された文字列が表示されず、代わりに文字の数だけ「黒い点」が表示されます。こうした状況は、「フィードバックをユーザーに提供し、システムの状態を視覚化する」という基的なユーザビリティ原則に反している、というのです。 さらにニールセン氏は、パスワードを隠すユーザーインターフェース (UI) について、以下のように否定的な見解を述べています。 画面上でパスワード表示を隠したところで、当にスキルのある輩は、入力しているユー

    パスワードは隠すべきか? | Accessible & Usable
  • i-mode端末にクッキー - Kimura.Memo

    COOKIEを送らないことで有名なi-mode端末の最新機種がCOOKIEを送っていることがわかった。 現時点でCOOKIEを送ってくることを確認している端末は以下の通り。 いずれもIPアドレス帯域は、210.153.84.**で、iモードセンタのIPアドレス帯域内のもの。 DoCoMo/2.0 P07A(c500;TB;W24H15) ※ちなみに送られてきたHTTP環境変数は以下の通り。 HTTP_COOKIE HTTP_HOST HTTP_REFERER HTTP_USER_AGENT HTTP_X_DCMGUID 【関連記事】 i-mode端末にリファラ(2009-04-28) 【2009/05/20 追記】 ドコモ公式発表 - iモードブラウザ2.0

    i-mode端末にクッキー - Kimura.Memo
  • パスワード強度を表示するインタフェースやスクリプト色々:phpspot開発日誌

    10 Password Strength Meter Scripts For A Better Registration Interface パスワード強度を表示するインタフェースやスクリプト色々が紹介されていました。 パスワード作成時や、ログインフォーム作成時に使えそうです。 PasswordMeter 入力したパスワードの強度を色々な視点からチェックできる 色々な項目を集計してScoreという形で点数が出ます。 Yet Another Password Meter 上記と同様のパスワード強度チェッカー Ultimate Password Strength Meter script.aculo.us で強度をグラフ表示するようにしたスクリプト Password Strength Field (A jQuery Plugin) パスワード強度表示用のjQueryプラグイン How to M

  • IEでiframe内の別ドメインのCookieを有効にする方法 - satoru.netの自由帳

    なにげにしらなかったんだけど、 IEで別ドメインのiframeを読み込むと、 そのiframe内のcookieが有効にならない。 そーゆーときは、HTTPのレスポンス時リクエスト時のヘッダーに 下記のkey&valueを出力しておけばOKらしい。 ("P3P", 'CP="CAO PSA OUR"')こーするだけで、あらふしぎ。IEがCookieを保存して意図した挙動をしてくれるじゃん。 この宣言の意味 P3P コンパクト ポリシー ヘッダーを追加し、ユーザーのデータを使用して悪質な操作が実行されないことを宣言すればCookieが有効になるみたい。Internet Explorer が適切なポリシーを検出すると、Cookie の設定が許可されます。 その、宣言の条件とは下記の3つ。 CAO サイトはユーザー自身の連絡先情報へのアクセスを提供すること PSA データはオンラインの個人に接続さ

    IEでiframe内の別ドメインのCookieを有効にする方法 - satoru.netの自由帳
  • C-Production – UNIXとプログラミングの備忘録

    大変ご無沙汰です。約1年半ぶりの更新です。 昨日、ブログを設置しているサーバでOSのアップデートに問題が発生したため、これを機に新サーバ・新OSに乗り換えることにしました。 現在のブログがマルチサイトのため、そのままでは新サーバの構築に苦戦すると予想されるため、他のブログの記事を統合しました。 統合内容は以下の通りです。 ・C-Production ・・・ メインサイトのため、他のブログを吸収して継続。 ・♪8thNote♪ ・・・ メインサイトに統合済みだったので、削除。 ・モバイル魂 ・・・ メインサイトに記事を引き継ぎ、並行稼働中。 ・無線のドキュメント ・・・ もともと閉鎖予定だったので、そのまま削除 外部SNSのアカウントについてはそのまま継続します。 今後ともよろしくお願いします。

  • 国土交通省のウェブサイトが改竄される | スラド セキュリティ

    4 月 11 日、日の国土交通省のウェブサイトが改竄され、一部の項目をクリックすると中国国旗や「歴史を忘れるな」などの英文を表示するようにされていたという (読売オンラインの記事、ITmediaの記事) 。 改竄されたのは 11 日の午前 11 時前後と見られており、改ざんが発見され内閣官房情報セキュリティセンターから連絡が入ったのが同日午後 6 時半ごろ、サーバが停止されたのが翌 12 日の午後 1 時 20 分ごろだった。ウイルスなどの感染は確認されていない模様。専門家からは、発見されてから対応を取るまでが遅すぎるという指摘も出ているらしい (サーチナの記事) 。

  • 岐阜県土岐市のサイトが改竄される | スラド セキュリティ

    岐阜県土岐市のサイトが 4 月 11 日 1 時 25 分から 4 月 12 日 10 時 50 分までの間、改竄された状態になっていたようだ (土岐市のお知らせより、改竄時のミラー) 。 改竄したのはブラジルの Fatal Error というクラッカーグループで、改竄されたページには「Não julgue meus erros admin !.... Julgue os seus ....」 (英語に機械翻訳すると「Don't judge my mistake admin ! Judge their (?)」) と書かれていた。土岐市は、利用者より電話連絡で改竄に気づいた模様。原因は「配下の既定のコンテンツのセキュリティ定義設定及び表示設定が不十分であったため。」としている。

  • [JS]アイコンをドラッグして認証する、かわいらしいCAPTCHA

    認証の流れ 音声ブラウザへの対応やマウス操作などアクセシビリティ的な弱点もありますが、アイデアやデザインはすばらしいと思います。 AJAX FANCY CAPTCHAはjQueryのため、動作にはjquery.jsが必要です。

  • ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)

    ヤフーの画像はなぜyimg.jpドメインなのか? サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し

    ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
  • 2008-08-06 - T.Teradaの日記 - HTTP用のページにHTTPSでアクセスする

    同一ホスト上にHTTPとHTTPSのページが同居しているサイトをしばしばみます。 そんなサイトでは、来はHTTPのページに、HTTPSでもアクセスできるようになっていることがあります。そういう場合、HTMLの中身によってはセキュリティ上の問題が出ますよという話です。 問題があるページ http://www.example.jp/index.html というURLのページがあるとします。 問題となるのは、そのページの中身に以下のようなHTMLがベタ書きされている場合です。 <script src="http://www2.example.jp/foo.js"></script> このページ(index.html)はHTTPでのアクセスを想定して作られているため、JSファイルをHTTPで読み込んでいます。 ここで、このページが実はHTTPSでもアクセス可能だとします。もしHTTPSでアクセス

    2008-08-06 - T.Teradaの日記 - HTTP用のページにHTTPSでアクセスする
    pmakino
    pmakino 2008/08/07
    あるあるw>「問題となるのは、そのページの中身に以下のようなHTMLがベタ書きされている」
  • サイトから削除してもRSSリーダで読める場合があるらしい - ある地方公務員電算担当のナヤミ

    ちょっと前に自治体サイトにおけるRSSフィードの対応の遅さについてふれました(「地方自治体サイトのRSS配信の実態」)が、何だかんだと言っても、RSSが普及しているかそうではないかと聞かれれば、未だ発展途上であるとしか答えようがありません。実際問題として提供する担当者が使っていないのであれば、RSSフィードにどういう利便性があるのか、またどういうデメリットがあるのかは理解されないものです。 担当者が配信しているRSSフィードの内容を確認していないんだろうなと思われる例もあります。ある自治体の首長がブログ形式で配信しているサイトのRSSフィードにはこうあります。 <author> <name>秘書課</name> (略) </author>いや、べつにいいんですけど、ちょっとどうかと思ったりもします。 また、RSSフィードを利用するスタイルは人それぞれです。ブラウザと違って特定のソフトウェア

    サイトから削除してもRSSリーダで読める場合があるらしい - ある地方公務員電算担当のナヤミ
  • ウェブサイトの会員登録に関する調査--約8割のユーザーが会員登録に不安

    また、Q1-2ではモバイルのウェブサイトにおける会員登録数を尋ねたところ、「1サイト〜3サイト未満」と回答したユーザーが最も多く35.8%。次いで、「会員登録をしたことはない」の31.6%が続く結果となった。 PCで最も回答が多かった「20サイト以上」の割合はわずか4.0%となり、PCの約10分の1程度の水準となっている。 Q1-1とQ1-2を比較すると、PCとモバイルにおける会員登録数には大きなギャップが存在していることがわかる。 もちろん今回の調査がPCのインタネットリサーチを使っていることを考慮する必要はあるが、この調査結果からは、「PCユーザーはモバイルでの会員登録を行わない傾向にある」や「モバイルでの会員登録がまだあまり進んでいない」といった仮説が見えてくる。 Q2では、会員登録をする上で不安に感じることがあるかどうかを尋ねた。 その結果、77.6%のユーザーが不安を感じたことが

    ウェブサイトの会員登録に関する調査--約8割のユーザーが会員登録に不安
  • 「ウェブサイト運営者のための脆弱性対応ガイド」などを公開:IPA 独立行政法人 情報処理推進機構

    独立行政法人 情報処理推進機構(略称:IPA、理事長:藤原武平太)は、ソフトウェア製品やウェブサイトのセキュリティ対策などを推進するため、「ウェブサイト運営者のための脆弱性対応ガイド」を含む報告書をとりまとめ、2008年2月28日(木)より、IPAのウェブサイトで公開しました。 ガイドは、「情報システム等の脆弱性情報の取扱いに関する研究会」(座長:土居範久 中央大学教授)において、昨年7月から行われた検討の成果です。 IPAでは、IPAから脆弱性に関して通知を行ったウェブサイト運営者や、情報システムの構築事業者、セキュリティに関する有識者など16組織に対して、昨年9月から年1月までにヒアリングを行い、ウェブサイトの脆弱性対策を促進する上での課題を抽出しました。 このヒアリングにおいて、一部のウェブサイト運営者は情報システムの脆弱性対策について、ウイルス・不正アクセス対策などの他の情報セ

  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • 高木浩光@自宅の日記 - 警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性

    ■ 警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性 最近、必要もなくやたら文字を小さく表示させるWebサイトが増えている。 官公庁も例外ではない。そのくせ、「文字を大きくするには」などという案内 を用意して、曰く、「アクセシビリティ」なのだという。アホかおまえら。 作っていておかしいと思わないのだろうか。もしかすると彼らは、文字を大き くするブラウザ設定で作業しているのかもしれない。だから自分のページでは、 文字を少し小さく作りたくなるのだろう。すると、そこを閲覧する人がまた少 しブラウザの文字サイズを大きくする。そして、そこが作るページはさらにま た少し小さい文字となり、そこを閲覧する人がまた少しブラウザの文字サイズ を大きくする。つまり、文字サイズのデフレスパイラルに陥っているわけだ。 一度地獄まで落ちたらよい。 たとえば、最近リニューアルされた警察庁のトップページ

  • サーバシグニチャは隠さないのが当たり前?

    (Last Updated On: 2013年11月6日)yohgaki’s blog – サーバシグニチャは隠すのが当たり前 http://blog.ohgaki.net/index.php/yohgaki/2007/09/04/a_ma_fa_a_ma_da_a_a_pa_me_na_a_ra_af_a_a に対するコメントを見つけました。このブログに対するご意見は探したことがないので、たまたま見つけたこのブログが初めてくらいだと思います。「サーバシグニチャは隠さないのが当たり前」とするご意見です。 なぜサーバのバージョン情報を公開する必要があるのか。それは、クライアント側で、サーバのバグや規格解釈の相違に起因する問題を回避するためです。 「当たり前」とするには理由が弱いと思います。サーバ側はサービス提供者が自由にコントロールできる要素です。サーバがオプションとして送信する特定のヘッダ

    サーバシグニチャは隠さないのが当たり前?