パスワードの入力文字列を任意で表示する | Accessible & Usable
公開日 : 2024年3月23日 カテゴリー : ユーザビリティ / アクセシビリティ フォームのパスワード入力欄 (<input type="password">) は基本的に、入力された文字列がマスキングされ、代わりに文字数の分だけ「黒い点」が提示されるようになっています。他人によるパスワードの盗み見を防ぐためですが、ユーザーは、大半のケースでは背後から覗く人が誰もいない状況でパスワードを入力するでしょうし、入力した文字列が視認できないと正しくタイプできているか不安になったり、タイプミスしたときの修正がしづらい (どの箇所でミスしたか確信が持てず、はじめから入力し直さざるを得なくなる) といった問題もあるでしょう。こうしたことを考慮に入れると、パスワードのマスキングはユーザーの任意で解除できる (入力した文字列を表示させる) ようにしたほうが、ユーザビリティの観点では望ましいと考えるこ
多要素認証におけるワンタイムパスワードの入力欄 | Accessible & Usable
公開日 : 2022年10月17日 カテゴリー : ユーザビリティ / アクセシビリティ 各種サービスへのログイン、インターネットバンキングなどの取引実行前の本人確認、といったシチュエーションで、多要素認証としてワンタイムパスワード (†) の入力が求められることが珍しくなくなってきました。従来の認証方法であるユーザー ID とパスワードの組み合わせに加えて、都度、動的に生成される一定の桁数の数字の並びをユーザーに入力させることで、セキュリティをより強固なものにしています。 † ワンタイムパスコード、確認コード、認証コード、などと呼ばれることもあります。 ところで、このワンタイムパスワードの入力欄の実装には、<input type="password"> が用いられているケースを時折見かけます (個人的な感覚としては、インターネットバンキングでこのような実装が比較的多く見られる印象です)。
Web開発者はもっと「安全なウェブサイトの作り方」を読むべき - Flatt Security Blog
画像出典: https://www.ipa.go.jp/files/000017316.pdf こんにちは。株式会社Flatt Security セキュリティエンジニアの奥山です。 本稿では、独立行政法人 情報処理推進機構(以下、IPA)が公開している資料「安全なウェブサイトの作り方」を紹介します。 「安全なウェブサイトの作り方」は、無料で公開されているにも関わらず、Webセキュリティを学ぶ上で非常に有用な資料です。これからWeb開発やセキュリティを勉強したいと考えている方はもちろん、まだ読んだことのない開発者の方々にも、ぜひ一度目を通していただけたらと思います。 一方、「安全なウェブサイトの作り方」では、一部にモダンなアプリケーションには最適化されていない情報や対象としていない範囲が存在します。それらについても本記事で一部、触れていきたいと考えていますので、資料を読む際の参考にしていただ
OpenSSHがSHA-1を使用したRSA署名を廃止、BacklogのGitで発生した問題と解決にいたるまでの道のり | 株式会社ヌーラボ(Nulab inc.)
サービス開発部SRE課の@vvatanabeです。 2021年9月26日、OpenSSH 8.8がリリースされました。大きな変更として挙げられるのは、SHA-1ハッシュアルゴリズムを使用したRSA署名の廃止です。 本記事では、この変更がBacklogに与えた影響、その時現場で起こっていたこと、問題解決のプロセス、なにを教訓にしたのか等、順を追って解説します。 ※ 本記事はNuCon 2021で発表した内容をブログ化したものです。 問題の発覚 BacklogのGitへSSHでアクセスできない TypetalkのBacklog開発者のトピックで、以下のフィードバックが投稿されました。 「OpenSSH 8.8へアップデートすると、BacklogのGitへSSHアクセスできない」という内容でした。 問題の調査 Inside SSH protocol v2 深堀りしていく前に、SSHプロトコルの接
Spectre の脅威とウェブサイトが設定すべきヘッダーについて
長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ
badssl.com
badssl.com 🎛Dashboard Dashboard 🎫Certificate expired wrong.host self-signed untrusted-root revoked pinning-test no-common-name no-subject incomplete-chain sha256 sha384 sha512 1000-sans 10000-sans ecc256 ecc384 rsa2048 rsa4096 rsa8192 extended-validation 🎟Client Certificate Certificate Downloads client client-cert-missing 🖼Mixed Content mixed-script very mixed mixed-favicon mixed-form ✏️HTTP h
コードを静的解析して脆弱性を検出する「SCALe」、米CERTがオープンソースで公開
米Software Engineering Institute（SEI）のCERT部門は、静的解析によってコードの脆弱性を検出するアプリケーション「SCALe」（Source Code Analysis Laborator）をオープンソースで公開しました。 SCALeは、複数の静的解析ツールをまとめて実行するためのフレームワークでできており、今回公開されたアプリケーションにはセキュリティに関するコーディング規約「SEI CERT Coding Standards」およびSQLインジェクション、クロスサイトスクリプティング、バッファオーバーフローなど多くのソフトウェアの脆弱性を体系的に一覧化した「CWE（Common Weakness Enumeration）」（共通脆弱性タイプ一覧）の2つをベースにしたツールが含まれています。 SEI CERT Coding Standardsは現在、C/
Webとセキュリティとソフトウェア工学 - こめんと(2016-06-20)
■ [Security] Webとセキュリティとソフトウェア工学 超久しぶりに、かつ真面目な内容で更新です。 徳丸浩さんのTwitterでの 何度でも言うが、自力でトラブルシューティングできない人や組織は、自前でWordPres立ててはいけない / “一般ブロガーがAmazon Web Service(AWS)で独自ドメインのWordpressサイトを10分で作る方法…” に対して、 山田さんの（恐らく）達観したコメント「こうやってセキュリティが素人プログラマーや、見習いプログラマーを殺すんだろうなぁ。想像していたとはいえ、現実になってくると絶望しかない。」 を、 奥くんのコメント経由で見たわけです。 正直なところ、徳丸さんの元のコメントには100％同意で、山田さんもわかった上での達観なんだと思うのです（少なくとも「批判」ではないと思う）が、 ソフトウェア科学→セキュリティ→ソフトウェア工
SRI をビルドプロセスへ組みこもう
この記事は “How to implement SRI in your build process” の抄訳です。 顧客から「おたくのサイトがマルウェアを配布している」との連絡があった場合を想像してみてください。心臓は止まり、冷汗をかき、Tweet が溢れ始めるでしょう。 「あれ？おかしいぞ」 システムは汚染されていませんでした。 実際にハッキングされたのはWeb サイトで利用しているスクリプトを配布している CDN のプロバイダで、そのスクリプトがマルウェア化していたのでした。そこで顧客に事実を報告しましたが、彼らは気にしません。製品の安全性と、顧客からの信頼は失われてしまいました。これが 2 年前に起きたとしたら、 「気の毒なことだったね」 と言ったでしょう。しかし今ならこう言うでしょう： 「SRI を使うべきだ」 Subresource Integrity (SRI) は比較的新しい
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
継続的WEBセキュリティテストサービス VAddy - 株式会社ビットフォレスト
VAddy integrates with your existing CI tools and performs robust security checks — so your developers can code secure. How secure is your code? VAddy gives you insight into the security of your web apps — and easily hooks into your standard deployment process. Help your developers code securely With VAddy, there’s no need for your developers to be security experts. Easily discover vulnerabilities,
VisualStudioでOpenFileDialogを使うとデータが消える？
2014/02/01追記 http://www.cyphertec.co.jp/news/cymon_revision.html 暫定的なものでなく、ちゃんと修正されたプログラムが配信されました。 DMM用は後日ソフトのアップデートがあるとのこと。 2014/01/17追記 http://www.cyphertec.co.jp/news/cymon_issue.html 改良されるのは望み薄…と書いてたけど、ここ数日Twitter上で話題になったようで、メーカー側から調査結果と、暫定的な対処方法が出ています。 ただあくまで暫定的なもので、一度電子書籍を読んだら再起動しないと同じ事が起きるということです。 （電子書籍リーダーはこの記事書いた時に消したきりなので、自分では試してないです） 2014/01/17修正 メーカーによると問題のファイル名がcymon.dllじゃなくcymon.sysだ
HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記
localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitwarden Passwordless.dev | Bitwarden
OSS or Freeのセキュリティ診断ツール - Qiita
私が考える安全なプログラムを書くために必要なこと
地獄のJavaScriptセキュリティ