![Gmailにメールが届かなくなる!? 5月中にやるべき対応策をマンガで教えてください!WACUL安藤健作さんに聞いてきた | Webのコト、教えてホシイの!](https://cdn-ak-scissors.b.st-hatena.com/image/square/25528941d32958dcecde68a71a4b3f4d7994ee9a/height=288;version=1;width=512/https%3A%2F%2Fwebtan.impress.co.jp%2Fsites%2Fdefault%2Ffiles%2Fstyles%2F1200x630%2Fpublic%2Fimages%2Farticle2012%2Fhoshii%2F2024%2Fhoshiino101_gmail_ogp.png%3Fitok%3DeRqR8W3c)
パブリック・プライベートを問わず、AWSのストレージサービスであるS3のバケット名からアカウントIDを突き止める方法をセキュリティ企業「Tracebit」のCTOであるサム・コックス氏が公開しました。 How to find the AWS Account ID of any S3 Bucket https://tracebit.com/blog/2024/02/finding-aws-account-id-of-any-s3-bucket/ コックス氏の方法はS3のVPCエンドポイントを使用することでVPCエンドポイントポリシーを適用するのがポイントとのこと。ポリシーで「アカウントIDが1で始める場合のみ許可」などアカウントIDに基づいて許可を行う事で、ポリシーレベルでの拒否が発生するかどうかをチェックします。 具体的な方法は下記の通り。 まず最初にターゲットとなるバケットのリージョンを
Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。 なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。 SPF: Sender Policy Framework (RFC 7208) DKIM: DomainKeys Identified Mail (RFC 6376) DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) SPFは従来
$ sudo apt-get update Ign:1 http://archive.ubuntu.com/ubuntu jammy InRelease Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease Ign:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease Ign:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
GitではPGP鍵を利用したCommitへの署名ができることを以前から知っていましたが, 下記記事を拝見して簡単に設定できることを知ったのでPGP鍵の生成から設定までやろうと思いました. また, とあるプロジェクトのCode Ownerになったため, リポジトリへのCommitに対して署名をすることで偽装を防げる方が良いのではないかと感じたことにも起因しています. 本記事では, 下記4点について実施したことをまとめます. macOSでのPGP鍵の生成 Gitでの署名つきCommitの実行 GitHubへの公開鍵の登録 他のPCへの秘密鍵のインポート macOSでのPGP鍵の生成 まずは必要なツールをインストールします. PGP鍵を生成するためのGnuPGとパスフレーズ入力に利用するPinentryをインストールします. インストールが完了したらGnuPGのバージョンを確認して, 2以降であ
あらすじ 公衆WiFiに繋いだ状態でいつものように docker container run -p 8080:80 nginx のような感じでDockerコンテナを動かしていたら、外部からリクエストを受信した。 ファイアウォールを設定し、外部からのアクセスを拒否しているはずなのになぜアクセスできたんだ... 環境 Docker desktop for mac with apple silicon 4.21.0 何が起きた? Dockerはデフォルトの設定では-p 8080:80のようにポートマッピングするとファイアウォールの設定を書き換え、外部からそのポートへのアクセスを許可するようになっている。 その結果LAN内の他のPCから対象ポートにアクセス出来てしまう。 ちなみにこれはDocker公式からも注意が出ている。 Publishing container ports is insecur
※タイトルの元ネタは以下の作品です。 はじめに この記事は、公開鍵暗号の全体感を正しく理解するためのものです。数学的な部分や具体的なアルゴリズムは説明しません。気になる方は最後に紹介するオススメ書籍をご覧ください。 少し長いですが、図が多いだけで文字数はそこまで多くありません。また、専門的な言葉はなるべく使わないようにしています。 ただしSSHやTLSといった通信プロトコルの名称が登場します。知らない方は、通信内容の暗号化や通信相手の認証(本人確認)をするためのプロトコルだと理解して読み進めてください。 公開鍵暗号の前に:暗号技術とは 公開鍵暗号は暗号技術の一部です。暗号と聞くと、以下のようなものを想像するかもしれません。 これは情報の機密性を守るための「暗号化」という技術ですが、実は「暗号技術」と言った場合にはもっと広い意味を持ちます。まずはこれを受けて入れてください。 念のため補足して
2023年1月4日、CircleCIはセキュリティインシデントが発生したことを公表し、利用者へ注意を呼びかけました。また1月13日には侵入経路を含む調査結果などをまとめたインシデントレポートを公表しました。ここでは関連する情報をまとめます。 CircleCIより流出したデータから利用者のサードパーティシステムに影響 CircleCIが不正アクセスを受け、同社のプラットフォーム上に保存された利用者のサードパーティシステム(Githubなど)の環境変数、キー、トークンを含む情報の一部が流出した。不正アクセスにより情報が流出したのはクラウドで提供されるCircleCIで、オンプレミス型のCircleCI Serverは影響を受けない。 2023年1月13日公表時点で本件の影響を受け、利用者よりサードパーティシステムへの不正アクセスが生じたと報告を受けたケースは5件未満。但しCircleCIは不正
Vaultとは 最近のアプリでは、データベースやAWS等、必ずといっていいほど外部システムとの連携があります。 その際に必要になるのが、パスワードやキー情報などの機密情報です。 そういった機密情報の管理は、特に注意しなければいけません。 例えば、大事なAWSキー情報やパスワードを、プログラム中やプロパティファイルに記述して、 それをGithubのようなリポジトリにpushしてしまったら、大変なことになってしまいます。 そういったミスをしないよう、安全に機密情報を管理するためのツールが、今回紹介するVaultです。 Vaultとは機密情報を管理するためのツールであり、クライアント/サーバ形式で動きます。 Vaultを使用するには、まずサーバを起動し、そこに対して機密情報を登録します。 その後、コマンドラインやHTTPでアクセスすることで、登録した情報を取得することができます。 Vaultの特
背景 私たちは中核人材育成プログラム 第5期受講生として、1年間にわたり様々な講義を受け、演習を実施してきました。その過程で、変化し続けるサイバーセキュリティの世界では、世界中の情報を的確に収集し成長を続けることが大事であることを学びました。 世界中の情報を利用するためには英語の力、中でもリーディングの力が不可欠です。しかし、私たち日本のセキュリティエンジニアの多くは英語に苦手意識を持っており、的確な情報活用ができていないのが現状です。 本プロジェクトは、日本のセキュリティエンジニアの情報収集力・成長力レベルアップのため、その手段としての英語リーディングの意欲・能力向上を目指して企画されました。実務や学習にお役立ていただければ幸いです。 想定利用者 日本語話者のセキュリティエンジニア全般ですが、中でも「ユーザー企業や官公庁で働く実務担当者」を主なターゲットとしています。「英語はちょっと……
2021年12月10日、Javaベースのログ出力ライブラリ「Apache Log4j」の2.x系バージョン(以降はLog4j2と記載)で確認された深刻な脆弱性を修正したバージョンが公開されました。セキュリティ関係組織では過去話題になったHeartbleedやShellshockと同レベルの脆弱性とも評価しています。ここでは関連する情報をまとめます。 1.何が起きたの? Javaベースのログ出力ライブラリLog4j2で深刻な脆弱性(CVE-2021-44228)を修正したバージョンが公開された。その後も修正が不完全であったことなどを理由に2件の脆弱性が修正された。 広く利用されているライブラリであるため影響を受ける対象が多く存在するとみられ、攻撃が容易であることから2014年のHeartbleed、Shellshock以来の危険性があるとみる向きもあり、The Apache Software
log4jとはJava用のloggingライブラリだ。loggingライブラリというのはログとして記録すべき文字列を受け取り、それをどこかに出力するものだ。文字列の中身を通常のloggingライブラリは気にしない。 log4jが通常のloggingライブラリと違うのは、文字列の中身を見て、一部の文字列を変数とみなして置換することだ。これはlog4jのドキュメントではlookupと呼ばれている。 Log4j – Log4j 2 Lookups 例えばプログラムを実行中のJava runtimeのバージョンをログに含めたい場合は、"Java Runtime: ${java:runtime}"などとすると、"Java Runtgime: Java(TM) SE Runtime Environment (build 1.7.0_67-b01) from Oracle Corporation"などの
Access to XMLHttpRequest at 'http://localhost:8081' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is ther
2021/4/23 追記 Twitter にて指摘を頂いたので追記。 詳細は当該ツイートを読んで頂きたいが、プリフライトリクエストを CSRF 対策として用いるのは適切ではないという内容。 この記事に書いた仕組みや挙動そのものが間違っているわけではないのだが、プリフライトリクエストはそもそもセキュリティのための機能ではない。 そして、詳しくは記事の続きを読んでほしいが、プリフライトリクエストが発生するということは、HTTP メッセージのやり取りが 1 回増えるということなので、パフォーマンス上、望ましくない。 代替案がないならともかく、リクエストのオリジンをチェックすれば対応できるのだから、敢えてプリフライトリクエストを利用する必要はない。素朴に書けば以下のようになるだろうか。 const ALLOW_ORIGIN = `http://localhost:${constants.SPA_P
– という名前の JavaScript/TypeScript パッケージについて警告を発している記事が話題となっています。 このパッケージ、中身はほとんど空で、Readme と、dev で TypeScript を動かせるようにするライブラリ群を呼ぶ箇所だけのもの。 しかし、この “-” を使っている他の npm パッケージが 50個以上あり、約一年前の公開時からのトータルのダウンロード数は72万回にもなります。 しかし、”-” を読み込んでいるパッケージを見てみても、”-” が必要そうには見えません。 警告記事では、この無名のパッケージが密かに使われるようになった原因が、npm コマンドのコマンドラインを打つときのミスタイプにあるのではないかとの仮説を立てています。 つまり、someFlag というオプションを使い npm i -someFlag somepackage と打つべきところ
アスツール社からSmoozのサービス終了が発表されました。 Smoozのサービス終了のお知らせ | Smooz Blog さて、問題を拡大解釈する人がとても多いので、改めて書いておきますが、私が指摘したのは主に以下の点です。 ・プライバシーポリシーが非常に大雑把で、アプリを使う上でのユーザーの情報は企業側が柔軟に使えてしまうようなものだったこと ・何に利用するために、どのような情報を送信しているかが明確ではないこと ・サービス利用データの提供をオフにしても、ユーザーIDと紐付けた情報の外部送信が止まらないこと ・どのようなユーザー情報が記録保存されているか明確になっていないこと ちゃんと説明をして、送られる情報の範囲を線引きし、ユーザーに対して提示することが必要だと言っているんです。 情報を提供することに対して見合った対価が得られるのであればユーザーは使うだろうということも書いてきたように
2020年7月16日(日本時間)、Twitter上で複数の著名なアカウントや有名企業のアカウントからビットコイン詐欺の投稿が行われました。Twitterはその後の調査で、社内サポートチームが使用する管理ツールが不正利用されたことが原因と発表しました。ここでは関連する情報をまとめます。 何が起きたの? 2020年7月16日未明から著名アカウントを中心に詐欺投稿が行われた。その後アカウント侵害の影響は大部分が回復した。 一連の投稿にはTwitter社内のサポートチームが使用する管理ツールが悪用された。さらに複数のアカウントでDM閲覧やデータのダウンロードが行われた恐れがある。 社内ツールはソーシャルエンジニアリングにより不正利用された。Slackがその舞台となったと報じられている。 1. アカウントのっとり詐欺投稿 4時間続く 7月16日に発生したビットコイン詐欺の投稿は大まかに2種類が確認さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く