Docker Engine 18.09 から使える Build-time secrets を試してみた | はったりエンジニアの備忘録
Docker Engine 18.09 から Build-time secrets という機能が使えるようになりました。この機能を使えば docker build するときに secrets (API key, credentials, etc) を安全に取り扱えるようになります。 Introducing Docker Engine 18.09 - Docker Blog Integrate secrets in your Dockerfile and pass them along in a safe way. These secrets do not end up stored in the final image nor are they included in the build cache calculations to avoid anyone from using the c
gh auth loginで作成されたクレデンシャルだけで生活するためにgh-doを作った - Copy/Cut/Paste/Hatena
やっとgh auth loginで得たクレデンシャル（OSのセキュアストレージに保存されているもの）のみを使う生活になったぞ— k1LoW (@k1LoW) 2023年5月15日 GitHub CLIの gh auth login で作成されたクレデンシャルはOSのセキュアストレージに保存されるようになりました。 次のエントリが詳しいです。 blog.kyanny.me 「じゃあ、もう全部セキュアストレージに保存されたクレデンシャルを使えばOK」となるのですが、なかなかそうはいきません。 なぜかというとGitHubのクレデンシャルを使うツールによって環境変数の扱いが異なるからです。 GitHubのクレデンシャル設定の歴史（私の記憶版） 注意: 以下は、あくまで私の記憶であって実際と異なるかもしれません。 前史 GitHub CLI（ gh ）やGitHub Actionsの登場以前は、クレ
Origin 解体新書
Web 技術解体新書 第一章 Origin 解体新書 Same Origin Policy とは Web において非常に重要なセキュリティモデルの 1 つだ fetch や XHR でリクエストを送信したときに、 CORS 違反で失敗したり、 Preflight という謎のリクエストが送信されたりして悩んだ経験があるかもしれない。これらは全て、ユーザを保護するために設けられた Same Origin Policy という制限を、ブラウザが遵守した結果なのだ。 本書はこの重要な Origin という概念について、そもそもなぜそんなものが必要なのかという背景や、それがユーザを保護するメカニズム、 JSONP はなぜ危険なのか、 Preflight が飛ぶ理由、 Service Worker など新しい API との連携、 Spectre によって発覚した脆弱性と CORP,COOP,COEP,
GitHub API を使ったリポジトリの監査を始めました - Techtouch Developers Blog
ヒアリングから見えた課題 定義したブランチ保護ルール GitHub API を利用した監査スクリプトの作成 終わりに こんにちは。SRE チームの izzii です。 つい先日、テックタッチでは GitHub リポジトリの利用ポリシーを定めました。創業から数年間、アクセル全開で開発して気がついたら、Owner 権限を持つ人間が増えてしまっていたことへの違和感を解消するためです。 ヒアリングを通して問題を分析し、リポジトリ利用ポリシーを定め、最終的には GitHub API を使って監査結果を Slack に通知する仕組みを作りました。 本記事はあくまで「リポジトリの利用ポリシー」の話に閉じます。GitHub の利用全般に及ぶ話に興味がある方は、Flatt Security さんが最近公開されたスライドが良さげなのでオススメしておきます。 https://blog.flatt.tech/en
Firefoxは危険なJavaScriptに対応しない - Qiita
Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important 優れた概念であり、Mozillaにとっても重要である。 worth prototyping 優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。 non-harmful 有害ではないが、良いアプローチではなく、取り組む価値
MDMで管理された3万台超の端末で意図せず発生した強制ロックについてまとめてみた - piyolog
2021年10月18日、アイキューブドシステムズは同社が提供するMDMサービス「CLOMO」を利用する一部の端末で、意図せず端末がロック状態となる事象が発生したことを公表しました。ここでは関連する情報をまとめます。 端末が突如使えなくなる 利用者、管理者が意図していないにもかかわらずCLOMOで管理されたモバイル端末が強制ロック状態となる事象が発生した。端末がロック状態となると「CLOMO MDMによりロックされています」と画面に表示され通常の操作ができない。同サービスは法人向けサービスとして提供されており、NTTドコモやKDDIで同サービスを利用する一部のユーザーでも影響が及んだと報じられた。*1 暫定対処として、ロック状態となった場合は、CLOMOの管理コンソールからロック解除のコマンド実行を行うことで解除を行うことが出来ると案内。その後同社からもロック解除のコマンドが実行されている。
Clubhouseを支えている技術とアーキテクチャ、セキュリティについて - LayerX Research
#LayerX_Newsletter 2021-02-19 TL;DR Clubhouseは極めてシンプルなアーキテクチャ 音声データはAgoraを、リアルタイム性の高い情報の扱い(ルームの中など)はPubNubを利用 音声データが暗号化されていないなどセキュリティ面での課題も多い Clubhouseは招待制の音声配信SNSで、2020年Aplha Exploration社が開発したこのサービスは、つながりがある人同士でラジオ放送のように自由に会話を楽しんだり、興味ある人はその会話を傍聴、さらには会話に飛び入り参加もできる特徴がある。2021年に入り世代・国籍・性別を問わず爆発的人気となっており、日本では2021年1月からスタートアップ界隈を中心に一気に話題が広がっている。また、テスラの創業者や有名人・著名人などが利用しはじめたことで大きな注目を浴びた。今回はClubhouseはどのような
Twitterのフリート機能に対する権限昇格
はじめにTwitterはBug Bountyプログラム(脆弱性報奨金制度とも呼ばれる)を実施しており、脆弱性の診断行為を行うことが認められています。 本記事は、そのプログラムを通して報告された脆弱性についてを解説したものであり、Twitterが認知していない未修正の脆弱性を公開する事を意図したものではありません。 また、Twitter上で脆弱性を発見した場合はTwitterのBug Bountyプログラムより報告してください。 (This article is written in Japanese. If you’d like to read this article in English, please visit HackerOne report.) TL;DRTwitterが公開したフリート機能が使用しているAPIに脆弱性が存在し、READ権限しか持っていないサードパーティアプリケ
GraphQL API を悪意あるクエリから守る手法 - yigarashiのブログ
実サービスで GraphQL API をインターネットに公開する際は、悪意あるクエリに対する防衛が欠かせません。この記事における「悪意あるクエリ」とはサービスに意図的に負荷をかけるクエリのことです。GraphQL では 、木構造や再帰的な構造を利用して、一回のクエリで容易に数百万・数千万件のデータを取得することができます。そのようなクエリを実行してしまうと、アプリケーションサーバーや、その後ろにいる別のサービスに甚大な負荷がかかります。これは攻撃者からしてみれば恰好の的で、なんらか対策を講じる必要があります。 幸いこうした問題はよく知られており、クエリを静的に解析するライブラリがいくつか存在します。しかし、そうしたライブラリをどう使うかといったことはあまり議論されておらず、効果的な対策を行うのは依然として難しい状況だと感じます。この記事では、典型的な負荷の高いクエリとその具体的な対策を紹介
［速報］GitHub、見られてはいけないコード中のアクセストークンを発見し通知してくれる「Token Scanning」発表。GitHub Universe 2018 － Publickey
［速報］GitHub、見られてはいけないコード中のアクセストークンを発見し通知してくれる「Token Scanning」発表。GitHub Universe 2018 クラウドサービスが充実してきたことで、コードからクラウドAPIを呼び出して利用することが一般的になってきました。クラウドAPIを呼び出す際には、適正な呼び出し権限を持つことを示すため、あるいは呼び出す側を特定して課金するなどの目的でアクセストークンを用いることがあります。 アクセストークンは第三者に知られないように安全に管理し利用する必要がありますが、何らかの原因でアクセストークンがコード内にそのまま記述されてそのコードがGitHubなどで公開された結果、悪意のある第三者に使われ、アクセストークン本来の持ち主に膨大な利用料金が請求される、といった事故がしばしば起きています。 GitHubはこうした事故を防ぐため、コード内に記
コマンド実行でシェルが怖いなら使わなければいいじゃない - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
http://blog.ohgaki.net/os-command-escape-shell-spec-command-implementation 「えすけーぷじゅうよう!!」を強調して言いたいからなのかシェルの理解が足りないからなのか、 意図がよくわからない文言やら説明が散見されますが、きりがないのでそれらはスルーします。 (シェルについては、なんで関係ない tcsh の話が出てくるんだとか、 位置パラメーター展開に $* 使うなとか、色々) 特に気になったのが以下の文章です。(強調は私によるもの) OSコマンドはOSが提供するシェルで実行されます。 シェルはテキストインターフェースを持ち、 テキストでコマンドとオプションを受け取り実行します。 例示した脆弱なPHPプログラムの場合、 ユーザーからの入力に対しセキュリティ処理を一切してないため、 簡単にサーバーを乗っ取られる可能性があり
Bacoor Inc. | Bring Blockchain Technology to the next level
August 12, 2019 - Update Simplex and Gacha on HB Wallet July 15, 2019 - We are sorry to announce that activities of Realboost.jp will be paused. Hence, from Thursday, July 18th, 2019, we will stop allowing registration. On July 25th, 2019, we will stop providing all services of Realboost. We have integrated Realboost to HB Wallet, where users can communicate with each other via HB Chat. The web
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
EU一般データ保護規則(GDPR)への対応に向けたやるべき事まとめ – 週休７日で働きたい
EUの個人情報保護に関する新しい法律(General Data Protection Regulation)が2018年5月25日から施行される。EUの居住者に対してサービスを提供していて個人情報を取り扱っている業者は、たとえ個人であろうとも遵守義務が課せられる。 最近多くのサービスがプライバシーポリシーの改定を行っているのはそのためである。個人で作っている自分のサービスにもEUのユーザが沢山いるので、そろそろ対応しなければならない(遅い)。 今回はEUの法律によるものだが、内容は至極真っ当な、客観的に見れば当たり前のルールだ。将来的には事実上のデファクトとなり、アメリカや日本もこの法律に倣うのは時間の問題だろう。だから「日本人向けのサービスだから大丈夫」とほったらかしにしている業者は後々痛い目に遭うだろう。 Twitter社がパスワードをログに記録していた件は記憶に新しいが、今これが公に
10分で脆弱性が見つかった、バグハンターと開発者が共同合宿で得たこと
10分で脆弱性が見つかった、バグハンターと開発者が共同合宿で得たこと：セキュリティ・アディッショナルタイム（21）（1/3 ページ） 缶詰め状態で集中して脆弱（ぜいじゃく）性を見つけてもらう「バグハンター合宿」を、サイボウズが2017年11月3～4日に実施。予想以上に多くの報告を受理しただけでなく、サービス開発者とバグハンターの双方に気付きが生まれた。 開発者にとって、セキュリティ担当者や外部のコンサルティング、そして「バグハンター」は、ちょっと面倒くさい存在かもしれない。 少しでも早く製品やサービスを市場に投入したいのに、セキュリティ上の問題や脆弱（ぜいじゃく）性を指摘し、やむを得ないときにはリリースに待ったをかけるからだ。海外では、脆弱性を報告してきたエンジニアに、詳細の公表を控えるよう求めたベンダーがあったことまで報じられている。 だが、開発者とバグハンターの関係にはもっとよい形があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
URL and website scanner - urlscan.io
Magic: Future-proof passwordless authentication
GitHub - mikewest/purification
認証しないWeb認証 限定公開URLのセキュリティについて考える 公開版
各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について
