（この記事は、Dropbox社に対してフェアじゃないものになっています。続きの「Dropbox Businessは馬鹿が使うと非常に危険なことを検証しました」も読んでください） 最近、非常に重大な事故を起こしてしまったので報告します。実際の被害は、最高が7だとすると3か4ぐらい、しかし潜在的な危険度からいうと7段階で7、ってくらい重大。Dropboxでファイルを大量に失なってしまったばかりか、個人情報流出の危険をおかしてしまいました。（実際には流出といえるものはありませんでしたが） Dropbox Businessチームに招待され参加して「アカウントを統合」すると、自分では抜けられない状態になる それだけでなく、それまで自分がもっていたファイルもすべてチームのものになる 個人用の契約が勝手に解除されてしまう 私のアカウントを削除すると、管理者は私のファイルを自分のものにすることができる 管
ソニーネットワークコミュニケーションズのインターネットワークサービス「NURO光」でレンタルされるネットワーク機器について、NURO光側が管理時に使用するアカウントIDとパスワードが特定されました。このアカウントを利用することで、通常はユーザーがアクセスできない機能にアクセスできるほか、root権限によるコマンド実行が可能になります。 GitHub - meh301/HG8045Q: Pwning the Nuro issued Huawei HG8045Q https://github.com/meh301/HG8045Q/ 目次 ◆1：「HG8045Q」の脆弱性の指摘 ◆2：脆弱性を確認してみた ◆3：新たな脆弱性を発見 ◆4：脆弱性の報告とNURO光の対応 ◆1：「HG8045Q」の脆弱性の指摘 研究者のAlex Orsholits氏によって報告された今回の脆弱性は、通信ネットワーク
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dropbox Businessは非常に危険です | 江口某の不如意研究室
NURO光で使用する管理者アカウントが特定される、見えてはいけない画面がまる見え＆root権限も奪取可能
アプリケーションにおける権限設計の課題 - kenfdev’s blog
Microservices における認証と認可の設計パターン