Serverless Web Hosting Strategy For Modern Front-end Application
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
息子に「お父さんカエルの匂いがする」と言われているセキュリティエンジニアリングの 西川です。カエルの匂いとはこれ如何に。。 カミナシに関わって1年経って 見出しで入社してではなく、関わってと表現したのは業務委託で関わり始めたのが去年の4月からだったからです。1年経って色々と今までの活動などの振り返りをしたいと思い筆を取りました。 そもそも振り返るきっかけとなったのは、IssueHunt 社のイベント(https://issuehunt.jp/seminar/lounge3)でプロダクトセキュリティについて話をする機会があったからです。できるだけ無意識下にあったものを言語化したいなと思いました。自分の考えを整理する貴重な機会をいただけて本当にありがたかったです。 私はセキュリティに関する競技への参加などを通じてチームビルディングないしは、組織に馴染むといいますか、その組織に最適化するのが得意
ゴールデンウィークのはじめ(4月29日)に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ!スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい! pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
あぁ、しくじった。毎日書こうとしたら休みの日である事を完全に忘れてゲームばかりした結果 0時を回って書いてしまっている。 しかも今回の内容が多分長くなりそうだから既に明日やる口実を作って明日作成しようとしている。 あぁ、憂鬱だ。 そんな始まり方のoauth 最近でこそoauth認証って普及されてますけど、 最初見た時、???ってなりませんでしたか? 僕は謎過ぎて良くわからなかったから、こんなのやらないと思ってました。 が、、、今になってみるとあまりにも便利が故に もはや、Googleサインインとかappleサインインが無いと嫌ですもんね。 おいおいおい、入れておけや。と。。。 それだけ楽にしてくれた認証機能ですが、 実は、認証機能以外にも認可という部分もあるので 今日はその辺を自分の備忘録的に書いていこうと思っています。 参考にしたもの まず先に参考にした動画を貼ります。 ざっくりと簡単に
ふと気になって調べたことの備忘メモです ✍ (2022/11/3追記)ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思
「クラウドサービス利用・提供における適切な設定のためのガイドライン」(案)に対する意見募集の結果と「クラウドサービス利用・提供における適切な設定のためのガイドライン」及び「ASP・SaaSの安全・信頼性に係る情報開示指針(ASP・SaaS編)第3版」 の公表 総務省では、「クラウドサービス利用・提供における適切な設定のためのガイドライン」(案)について、令和4年7月26日(火)から同年8月24日(水)までの間、意見募集を行いました。 その結果、15件の意見の提出がありました。提出された意見及び当該意見に対する総務省の考え方をとりまとめるとともに「クラウドサービス利用・提供における適切な設定のためのガイドライン」と、本ガイドラインの内容を反映するため改定した「ASP・SaaSの安全・信頼性に係る情報開示指針(ASP・SaaS編)第3版」を併せて公表します。 ここ数年、クラウドサービスを利用す
Macのセキュリティシステム、実はかなり強固だった...!2022.09.28 21:0022,584 David Nield :Gizomodo US [原文] ( Mme.Valentin/Word Connection JAPAN ) 見えないところでしっかり保護 macOSはコンピュータとデータをマルウエアの危険から守ることに定評があります。ですが、Windowsに標準搭載されている「Windowsセキュリティ」のような、目に見えるウイルス対策ツールがmacOSにあるわけではありません。しかし目立たないだけで、macOSにもウイルス対策ツールやセキュリティツールは搭載されています。 たとえば、XProtect(エクスプロテクト)がその一例。ドックにも、ランチャーにも、Spotlightで検索しても表示されませんが、Mac内には存在しています。XProtectは、YARAというパター
ソフトウェア開発者でなくとも、セキュリティ・バイ・デザインという言葉は聞いたことがあると思います。しかし、セキュリティ・バイ・デザインが十分に実施できていると言える組織は多くないのではないでしょうか。 いざセキュリティ・バイ・デザインを実施しようとしても「何をすればよいのだろう?」「どうやれば良いのだろう?」となかなか手が動かない。そんな状況の一助となるよう、我々がセキュリティ・バイ・デザインを学び、実践した内容を文書化し公開する運びとしました。 セキュリティ初心者でも読みやすいように、以下の特徴を念頭において本書を執筆しました。 軽快な文章 図表を多用したグラフィカルな見た目 キャラクターのセリフに共感しながら理解ができる 1章 セキュリティ・バイ・デザイン -セキュリティ・バイ・デザインの概要や必要性の説明 2章 脅威分析 -組織やシステムに対する脅威分析の実施方法 3章 セキュリティ
こんにちは @zaru です。今回は昔からある CSRF (クロスサイト・リクエスト・フォージェリ) の今時の対策についてまとめてみました。もし、記事中に間違いがあれば @zaru まで DM もしくはメンションをください (セキュリティの細かい部分についての理解が乏しい…) 。 2022/08/29 : 徳丸さんからフィードバック頂いた内容を反映しました。徳丸さん、ありがとうございます! 認証あり・なしで対策方法が違う点 トークン確認方式のデメリットのクロスドメインについての言及を削除、代わりに Cookie 改変リスクを追記 Cookie 改ざん可能性について徳丸さんの動画リンクを追記 SameSite 属性で防げない具体的なケースを追記 nginx 説明が関係なかったので削除 そもそも CSRF ってなに? 昔からインターネットをやっている方であれば「ぼくはまちちゃん」 騒動と言えば
はじめに 2022年のセキュリティ・キャンプ全国大会に講師として参加しました。その際に、Goにおける脆弱性への対策はどうなっているのか調べました。この記事では、github.com/google/go-safeweb/safesqlがどのようにSQLインジェクションを防いでるのかについて解説します。 なお、@rungさんの文書を多いに参考にしております。また、セキュリティ・キャンプで用いた資料はこちらから閲覧できます。 SQLインジェクションとは? 独立行政法人情報処理推進機構(IPA)が公開している安全なウェブサイトの作り方を見ると、SQLインジェクションは以下のように説明されています。 データベースと連携したウェブアプリケーションの多くは、利用者からの入力情報を基にSQL文(データベースへの命令文)を組み立てています。ここで、SQL文の組み立て方法に問題がある場合、攻撃によってデータベ
政府情報システムにおける 脆弱性診断導入ガイドライン 2022(令和 4)年 6 月 30 日 デジタル庁 〔標準ガイドライン群ID〕 DS-221 〔キーワード〕 セキュリティ、脆弱性、脆弱性診断 〔概要〕 政府情報システムの関係者が脆弱性診断を効果的に導入するための基準及 びガイダンスを提供する。 改定履歴 改定年月日 改定箇所 改定内容 2022年6月30日 - 初版決定 1 目次 1 はじめに ......................................................... 2 1.1 目的とスコープ .............................................. 2 1.2 適用対象 .................................................... 3 1.3 位置づけ ...
Send feedback Firebase security checklist Stay organized with collections Save and categorize content based on your preferences. To keep your Firebase resources and your users' data secure, follow these guidelines. Not every item will necessarily apply to your requirements, but keep them in mind as you develop your app. Avoid abusive traffic Set up monitoring and alerting for backend services To d
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2. 他人にメー
Amazon.com、同社内で使われていた従業員向けのセキュリティオンライントレーニングを無償で一般公開、日本語版も提供 Amazon.comは、これまで同社内で従業員向けに提供してきたセキュリティのオンライントレーニングコースを無償で一般公開しました。 Starting today, we're making the same cybersecurity training used by Amazon employees available to businesses and individuals around the world at no cost. #CybersecurityAwarenessMonth https://t.co/h1EXJf6lrn — Amazon News (@amazonnews) October 26, 2021 セキュリティトレーニングは「Cyber
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く