今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編今時のアプリ開発において、コンテナは避けて通れないものになっています。そして数多くあるコンテナ実行環境の中でも、デファクトスタンダードと言えるのがDockerです。そんなDockerのイメージですが、皆さんは正しくビルドできていますか? そのコンテナは無駄に太っていませんか? 効率よく最短時間でビルドできていますか? セキュリティは大丈夫ですか? 今回はDockerfileの書き方をテーマに、「今さら聞けない」Docker入門をお届けします。
採用サイトに｢社員の氏名｣載せる企業の危うさ
また、自社の信用を高めるために、ホームページに取引先一覧を掲載している会社もありますが、これもセキュリティの観点からは危ない。 いわゆる「サプライチェーン攻撃」ですが、最終的に攻撃したい大企業の情報を持っていると推測され、サイバー攻撃を受けるリスクが高まります。一般に大企業よりも中小企業のほうがセキュリティは甘く、攻撃者はその弱点を狙ってくるのです。 セキュリティに関する情報を集約、ルール化して ――ホームページやパンフレットでの情報発信から事故が発生するのを防ぐには、どのような対策が有効ですか。 情報セキュリティ委員会を立ち上げて、セキュリティに関する情報がそこに集約されるような仕組みが望ましいです。 前述の通り、攻撃者は社員の名前を入手するとメールや郵送などさまざまな手段で接触してきます。「個人情報やメールアドレスの掲載、拠点の電話番号など掲載する場合は必ずここに一報を入れる」とルール
【業務効率革命】GAS Interpreter の衝撃｜ChatGPT研究所
今までで最もインパクトのあるGPTsが完成しました。 その名も、「GAS Interpreter」です。 このGPTは名前の通り、Code Interpreter のように Google Apps Script コードを生成し、その実行までを行います。 他者に使ってもらうものではなく、自分専用のプライベートGPTです。 人によっては、Code Interpreter よりも便利です。なぜかというと、インターネットアクセスができることに加えて、GAS の便利で豊富なライブラリやリソースが活用できるためです。 例を示します。 GAS Interpreter の可能性以下に示す、いくつかの業務フローの実例をGAS Interpreterで行い、業務活用への可能性を示します。 今日の予定を聞きます今日の予定を教えて下さい 正確に今日の予定を教えてくれました。 会議参加者の相手に連絡したいので、その
登大遊氏が憂う、日本のクラウド、セキュリティ、人材不足、“けしからん”文系的支配
登大遊氏が憂う、日本のクラウド、セキュリティ、人材不足、“けしからん”文系的支配：ITmedia Security Week 2023 冬 2023年11月29日、アイティメディアが主催するセミナー「ITmedia Security Week 2023 冬」の「実践・クラウドセキュリティ」ゾーンで、情報処理推進機構（IPA）サイバー技術研究室 登大遊氏が「コンピュータ技術とサイバーセキュリティにおける日本の課題、人材育成法および将来展望」と題して講演した。日本における「ハッカー」と呼ぶべき登氏が初めてアイティメディアのセミナーに登壇し、独特の語り口から日本におけるエンジニアリングの“脆弱性”に斬り込んだ。本稿では、講演内容を要約する。
Cloudflare Workers | サーバーレスアプリケーションを構築
最新クラウド向けのアプリケーションを構築サーバーレスコードをデプロイして、優れたパフォーマンス、信頼性、拡張性をグローバルに実現しましょう。 Cloudflareグローバルネットワークの全世界310か所以上のデータセンターへグローバルにデプロイする際にインフラの設定や保守をすることなく、Web機能やアプリケーションを構築しましょう。
SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
サブドメインの異なるサービス間で cookie を共有する - Qiita
https://www.nicovideo.jp // ニコニコ動画 https://live.nicovideo.jp // ニコニコ生放送 https://ch.nicovideo.jp // ニコニコチャンネル 例えば上記のように、異なるサブドメインにおいてもログインセッションなどのデータを共有したい場合があります。 セキュリティの都合上オリジン(<scheme>://<hostname>:<port>)の異なる場所と JavaScript 内でデータの送受信を行う場合はオリジン間リソース共有(CORS)の仕組みを利用する必要があります。 しかし、 CORS のような仕組みを信頼されうるサブドメインの違いだけで利用するのは面倒です。 今回は Cookie の仕様を用いて、データを共有出来るようにします。 要約 ;domain=example.com オプションを付けること。 doma
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か？ - Flatt Security Blog
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2
SQLiteデータ型の仕様とセキュリティ問題
(Last Updated On: 2018年10月8日)SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。 普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。 追記：論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析／対応できるようになります。 SQLiteの仕様 最も特徴
隠しカメラを見つける方法
指向性マイクや隠しカメラなどの監視装置は、普通の人にとってはスパイ映画に出てくる小道具ですが、現実の世界にも普通にあります。アパートの一室、高級ホテルの客室、オフィスの中やスポーツジムなどに仕掛けられていることがありますし、もしかすると自宅に仕掛けられているかもしれません。今回は、そうした監視装置を見つける方法を探っていくことにしましょう。 小さなスパイたち ミニサイズのカメラは、それほど高価ではありません（本記事執筆時点では約4,000円〜）。また、普通のWi-Fiに接続してクラウドなどにデータを送信する機能を持っています。ということは、誰でもスパイごっこができるということです。そんなことをする人の動機は何なのでしょうか？ 例えば、賃貸アパートの大家が、盗難や器物破損に備えて設置する場合が考えられます。相手の行動を疑う配偶者や、どんな手を使ってでもライバルを蹴落としたい人にも、そうする理
「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au
[pdf] JWT ハンドブック Sebastián E. Peyrott、Auth0 Inc.
JWT ハンドブック 著者: Sebastian Peyrott JWT ハンドブック Sebastián E. Peyrott、Auth0 Inc. バージョン 0.14.1、2016〜2018 1 ⽬次 ⽬次........................................................................................................................................................................................ 1 謝辞.........................................................................................................
Firestoreセキュリティルールの基礎と実践 - セキュアな Firebase活用に向けたアプローチを理解する - Flatt Security Blog
こんにちは、株式会社Flatt Security セキュリティエンジニアの梅内(@Sz4rny)です。 本稿では、Cloud Firestore (以下、Firestore) を用いたセキュアなアプリケーション開発を行うためのアプローチについて説明するとともに、そのアプローチを実現するセキュリティルールの記述例を複数取り上げます。 本稿を読むことで、そもそも Firestore とは何か、どのように Firestore に格納するデータの構造を設計、実装すればセキュアな環境を実現しやすいのか、また、Firestore を利用するアプリケーションにおいてどのような脆弱性が埋め込まれやすいのかといったトピックについて理解できるでしょう。 なお、本稿は以前に投稿した記事と共通する部分があります。理解を補強するために、こちらの記事も適宜ご覧ください。 flattsecurity.hatenablo
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
Firestore Security Rules の書き方と守るべき原則
概要と投稿の背景 本投稿では、下記の参考にした記事や動画を通じて私が学習した、Firestore Security Rules の書き方と守るべき原則についてまとめます。 まず、そのような学習に有益な情報をオープンに発信して下さっているディベロッパー・クリエイター、Google 公式の皆さんへのリスペクトと感謝を表明します。本当にありがとうございます。 私と同じ学習者・初学者の方の参考になればと思い、具体的なユースケースを想定しながら、実際のコードを含む形でまとめています。 参考にした記事や動画 本記事では、以下のような記事や動画を通じて学んだ内容をまとめています。 【公式】Firebase CLI リファレンス 【公式】Cloud Firestore セキュリティ ルールを構造化する 【公式】Cloud Firestore セキュリティ ルールの条件の記述 【公式】Firebase 公式
Google、セキュリティスキャナー「Tsunami」をオープンソースで公開。ポートスキャンなどで自動的に脆弱性を検出するツール
Google、セキュリティスキャナー「Tsunami」をオープンソースで公開。ポートスキャンなどで自動的に脆弱性を検出するツール Announcing the release of the Tsunami security scanning engine to the open source communities to protect their users’ data, and foster collaboration.https://t.co/qrvmilHm1r — Google Open Source (@GoogleOSS) June 18, 2020 Tsunamiは、アプリケーションに対してネットワーク経由で自動的にスキャンを行い、脆弱性を発見してくれるツールです。 Googleは、現在では攻撃者が自動化された攻撃ツールへの投資を続けており、ネット上に公開されたサービスが攻
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go をセキュアに書き進めるための
「ガードレール」を整備しよう / Let's Build Security Guardrails For Your Go Programs!
