プラネックスコミュニケーションズ株式会社が提供する「スマカメ CS-QR10」および「スマカメ ナイトビジョン CS-QR20」には、複数の脆弱性が存在します。
JVNVU#90766406: プラネックスコミュニケーションズ製ネットワークカメラにおける複数の脆弱性
プラネックスコミュニケーションズ株式会社が提供する「スマカメ CS-QR10」および「スマカメ ナイトビジョン CS-QR20」には、複数の脆弱性が存在します。
20日目: 正規表現が ReDoS 脆弱になる 3 つの経験則
はじめに 皆さんこんにちは．3回生のらん（@hoshina350）です． 文字列マッチングに便利な正規表現ですが，テキトーに書くと脆弱になり得るという情報を耳にしてから色々と原因や対策を調べていました． しかし，多くの記事で紹介されていた対策方法は，「独自の正規表現を使用しないー」とか「 * や + などの繰り返し表現はなるべく使わないー」とかいう なんともふわっとしたものでした．これでは「いやぁ確かにそうなんかもしれんけど…そうゆう訳にはいかんやんか…」と納得できません． つまり，「本質的に何が問題」で，「具体的にどんな特徴のある正規表現が脆弱になり得るのか」を知りたい訳です． そこで，様々な文献を調査してみました．本記事では調査して溜まった知見を紹介していきます． 本記事は， Purdue大学のJames Davis教授による “The Regular Expression Denia
MDN を信じずに「Cache-Control」には「private」を含めよう (#4073928) | IIJmioの新アプリ「My IIJmio」で別ユーザー情報が誤表示されるトラブル。サービス停止へ | スラド
Web開発者がトップクラスとして信用しているサイトは MDN ですが、そこの Cache-Control の解説が酷いです。 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control [mozilla.org] にっこりしている顔文字🙂 [mozilla.org] 付きの「良い例」として Cache-Control: no-store を挙げていて、 プンスカしている顔文字😡 [mozilla.org] 付きの「悪い例」として Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0 を挙げていますが、「良い例」の方だと今回のような漏洩事故の原因となります。 今回の件が、このせいかど
ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
ssh-agent のしくみ - eagletmt's blog
ssh-agent のように daemon として起動し秘密の情報を保持しつつ別プロセスと通信するようなプログラムを書きたくて、ssh-agent はどう実装しているのかざっくり調べた。 https://github.com/openssh/openssh-portable 通信方法 これは普通に ssh-agent を使っていてもすぐ気付くことだけど、ssh-agent は UNIX domain socket を使って通信している。 eval $(ssh-agent) のように実行すると SSH_AUTH_SOCK と SSH_AGENT_PID の2つの環境変数がセットされ、SSH_AUTH_SOCK は UNIX domain socket のパスを、SSH_AGENT_PID は daemon 化した ssh-agent の pid を指している。 SSH_AUTH_SOCK は
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
第５９５号コラム：「私たちはなぜパスワード付きｚｉｐファイルをメール添付するのか」 | デジタル・フォレンジック研究会
第５９５号コラム：上原 哲太郎 副会長（立命館大学 情報理工学部 教授） 題：「私たちはなぜパスワード付きｚｉｐファイルをメール添付するのか」 皆さんの組織でも、重要な情報を含むファイルをメールで外部に送付する際に、その漏洩防止等のため、何らかのルールを設けておられるところが多いのではないかと思います。その中で非常によく見かける方式に、このようなものがあります。 ①添付するファイルをあるパスワードを使って暗号化ｚｉｐファイルにする。 ②そのファイルをメール添付して送信する。 ③続いてそのパスワードをメール送信する。 私が見聞きする限り、多くの日本企業や組織がこのようなファイル送信法をセキュリティ強化策と信じて」内規で義務づけたり、自動化システムを導入したりしています。しかしこの種のメール、少し考えるだけでセキュリティの観点からは効果がないことは明らかです。同一経路でファイルとパスワードを送
国際化ドメイン名(IDN)のフィッシング詐欺脆弱性について - 日本語.jp
ホーム ＞ 対応環境について ＞国際化ドメイン名(IDN)のフィッシング詐欺脆弱性について - 既に対策は存在し、.JPはサービス開始当初より対策済み - 2005年2月7日から8日にかけて、国際化ドメイン名(IDN)に起因するフィッシング詐欺脆弱性が発見されたとの報道がありました。しかしながら、その本質的な内容はブラウザなどのアプリケーションの問題ではなく、そのドメイン名を運用・管理するレジストリの側がどれだけきちんとした対応を行うかという問題であると言うことができます。ここでは、その内容を 問題の本質 報道されている問題に対する解決策は既に存在し、多くのレジストリでは適用されていること JPドメイン名ではサービス開始当初から適切に対策をしていること という流れでご説明します。 なお、現実には、フィッシングでは誘導先のURIを偽装したり隠蔽したりするなど、もっと巧妙な手段が使われているこ
SSHとSSLの違いについてSSLはブラウザとwebサーバ間の暗号化（公開鍵）で行われて、SSHはホスト間の暗号化（公開... - Yahoo!知恵袋
SSLもSSHも公開鍵暗号を使用し、認証やトンネリングを行うことができるという点は共通していますね。 SSLとSSHの違いですが、SSLの方がSSHより、きめ細かい仕組みになっています。SSHでは通信する全ての相手の公開鍵を事前に入手しておく必要があります。通信相手が100人いるなら、100人分の公開鍵を入手しておく必要があります。それに対して、SSLではその必要はありません。 SSHにおいて、もし相手の公開鍵を事前に入手していなかった場合は、アクセスした時点で相手が送ってきた公開鍵を受け入れるかどうか判断する必要があります。SSHで初めてアクセスするときに相手の公開鍵を受け入れるかどうか確認するためのメッセージが表示されますよね？ もし受け入れなかった場合はその通信できません。逆に受け入れる場合も注意が必要です。もし受け入れた鍵が偽物だった場合にどうなるかは容易に想像できますね？ 他方、
高木浩光＠自宅の日記 - 天動説設計から地動説設計へ：7payアプリのパスワードリマインダはなぜ壊れていたのか（序章）
■ 天動説設計から地動説設計へ：7payアプリのパスワードリマインダはなぜ壊れていたのか（序章） 7payの方式はなぜ許されないのか、なぜあんな設計になってしまったのか、どう設計するのが正しいのか、急ぎ書かなくてはいけないのだが、前置きが長くなっていつ完成するかも見えない。取り急ぎ以下のツイートでエッセンスを示しておいた*1が、すでにわかりかけている人達にしか刺さらなそうだ。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) July 8, 2019 同様のことは4年前にNISCのコラムに書いたが、消えてしまっているので、ひとまず、その原稿を以下に再掲しておく。 スマホ時代の「パスワード」のあり方を再考しよう 高木浩光 2015年2
DockerHubで公開されているコンテナが安全か確かめてみた結果【人気のコンテナ上位800個】 - Qiita
はじめに Docker Hubに公開されているイメージはどの程度安全なのか、 Dockle と Trivy を利用して検証しました。 検証結果は、 https://containers.goodwith.tech/ に公開しています。 結論 基本的にどのコンテナにも脆弱性はある！ 人気が高いコンテナ/最近ビルドされているコンテナでも関係ない！ ただ、Docker公式が用意しているコンテナは今のところ大丈夫。 より詳しいことを知りたい人は 操作方法 を見て、 https://containers.goodwith.tech/ を操作してみてください。 操作方法 ① ソートやフィルタが簡単にできます ※ Scoreは脆弱性のCVSSスコアなどを元にした参考値です。指標を一つに統一したかったので作りました。 ガチ勢の方々、怒らないでください & よりよい指標をつくるためのアドバイスをください。
CWE-20入門
サマリ この記事の想定読者は、企業等の脆弱性ハンドリング担当者です。脆弱性情報にしばしば出てくるCWE-20の読み解き方を説明します。 CWEとは CWEはCommon Weakness Enumerationの略で、日本語では「共通脆弱性タイプ一覧」と訳されています。この訳からも分かるように、脆弱性をタイプ毎に分類しているものです。つまり、SQLインジェクション、XSS、バッファオーバーフロー等に、CWE-XXXという「分類番号」をふったものと考えるとわかりやすいでしょう。以下は、IPAが公表しているCWEの解説記事からの引用です。 1999年頃から米国政府の支援を受けた非営利団体のMITRE(*2)が中心となり仕様策定が行われ、2006年3月に最初の原案が公開されました。その後、40を超えるベンダーや研究機関が協力して仕様改善や内容拡充が行われ、2008年9月9日にCWEバージョン1.
SSHの公開鍵認証における良くある誤解の話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 背景 これを知っていたからと言って何かの役に立つかというと、そうでない人の方が多いとは思うのですが、いい加減、SSHの公開鍵認証の説明がデマばかりなので、少しはちゃんとした説明もあった方が良いかもな、ということで記事にしました。 SSHについて 皆さんご存知の通り、SSHはSecureSHellの略であり、暗号によって保護された通信を通じて遠隔操作を行う1アプリケーション、またはプロトコル2を指します。 Linux等のUNIX系OSの遠隔操作3、またはネットワーク機器の管理に広く使われており、その実装としてはOpenSSHが有
パスワード保存のベストプラクティスと bcrypt のメモ書き | tech - 氾濫原
考えてみるとほとんどパスワードを保存するコードを書いたことがない。現状のベストプラクティスを知らなかったのでメモ書き。 現状では bcrypt 使うのがいいみたい。b は Blowfish の b。 Modular Crypt Format というフォーマットとコンパチの出力をする。crypt (3) はもともと DES の短いフォーマットだが、弱すぎたため md5 拡張なりSHA512 拡張などが存在している。(htpasswd でも使われているので見たことある人は多いだろう) これの Blowflish を使ったものが bcrypt で、prefix に $2$, $2a$, $2x$, $2y$ $2b$ がついている。prefix の違いはバージョンの違いであり、現在は 2b を使うのが良い。ストレッチング回数も出力に含まれるので、あるとき急にストレッチング回数を増やしても特に問題
認証にまつわるセキュリティの新常識 - Speaker Deck
2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。 そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-6…
2段階認証アプリ「Authy」の使い方。非常に便利でスマホが壊れても安心 - ラブグアバ
Android、iOSアプリが準備されている他、WindowsでもChormeアプリとして利用できるようになっています。 ただ、Chromeアプリは今後収束していく見通しなので、私はあえてインストールしませんでした。 Chrome拡張機能とChromeアプリの違いとは？どっちがいいの？簡単に説明します Authyを設定するインストールが終わったらさっそく起動しましょう。今回はAndroidアプリの画面でご紹介します。 ▼起動すると下記の画面が表示されます。 電話番号とEメール（電話番号を入力すると表示される）を入力します。 ▼登録に必要な確認コードを伝える方法を選択します。私は「SMS」を選びました。 するとSMSに確認コードが届くので、これをAuthyに入力します。 これでAuthyが利用できるようになりました。 Authyのバックアップ設定を行うAuthyはクラウド上にワンタイムパスワ
クラウドを支えるこれからの暗号技術
『クラウドを支えるこれからの暗号技術』 本書は公開鍵暗号に続く、新しい暗号技術を紹介します。 対象読者 『暗号技術入門』（結城浩）を読んで最先端暗号理論はどうなってるのだろうと興味を持った方 「入門書に載っているRSA暗号は安全ではないので使ってはいけない」ということを知らない方 Hash(secret key||message)で認証してはいけない理由（SHA-2とSHA-3の違い）を知りたい方 楕円曲線暗号の楕円曲線を直感的に把握したい方 最近ちょいちょい聞く「準同型暗号」って何だろうと思っている方 楕円曲線といえばy2 = x3 + ax + bという式が唐突に出てくるけど何故なのと疑問に思った方 EdDSAって何? ECDSAの書き間違い?と思ったらEdwards曲線が出てきて、それ何だろうと思った方 暗号で使われる数学の話をきちんと理解したい方 などなど。 購入 秀和システム 正
vuls/README.ja.md at master · future-architect/vuls · GitHub
Vuls: VULnerability Scanner Vulnerability scanner for Linux, agentless, written in golang. README in English Slackチームは こちらから 参加できます。(日本語でオッケーです) Abstract 毎日のように発見される脆弱性の調査やソフトウェアアップデート作業は、システム管理者にとって負荷の高いタスクである。 プロダクション環境ではサービス停止リスクを避けるために、パッケージマネージャの自動更新機能を使わずに手動更新で運用するケースも多い。 だが、手動更新での運用には以下の問題がある。 システム管理者がNVDなどで新着の脆弱性をウォッチし続けなければならない サーバにインストールされているソフトウェアは膨大であり、システム管理者が全てを把握するのは困難 新着の脆弱性がどのサーバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wi-Fi再入門〜見えない電波を知識で見抜く
