2020/02/13 DevSumi 発表資料
2020/02/13 DevSumi 発表資料
Chrome 79以下や他ブラウザのデフォルト値。 Chrome 80からこの値を設定する場合、Secure属性も必須となる。 Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) 図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないため
JAWS-UG 初心者支部 #22 ハンズオン用の資料です。 目的 AWSアカウントを不正利用されないために、アカウントを作成したらまずやるべきセキュリティ周りの設定を行います。 前提 AWSアカウントを作成済みであること AWSアカウントにログインしていること リージョンは東京リージョンを利用します ハンズオン手順 アカウント周りの設定 ルートアクセスキーの削除 ※ルートアカウントのアクセスキーは、デフォルトでは作成されておりません。アクセスキーを作成済みの方を対象とします。 ルートアカウントは全てのサービスへのアクセスが出来てしまうため、ルートアカウントは使用せず、IAMユーザーを使用しましょう。 CLI等のプログラムアクセスも不要なため、アクセスキーを削除します。 https://console.aws.amazon.com/iam/home#/security_credential
架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策:徳丸浩氏が8つの試練を基に解説(1/3 ページ) ECサイトやWebサービスでセキュリティインシデントを起こさないためには何をすればいいのか。2019年12月に開かれた「PHP Conference Japan 2019」で徳丸浩氏が、架空企業で起きたセキュリティインシデントを例に、その対策方法を紹介した。 ECサイトやWebサービスを提供する会社で発生したセキュリティインシデントに関するさまざまなニュースが後を絶たない。どうすればこうしたインシデントは防げるのだろうか。 『体系的に学ぶ安全なWebアプリケーションの作り方』(通称:徳丸本)の筆者として知られる徳丸浩氏(EGセキュアソリューションズ 代表取締役)は、2019年12月に開かれた「PHP Conference Japan 2019」のセッション「オニギリペイのセキュリ
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR(長すぎて読みたくない) 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
徳丸浩氏が誤解を指摘――Webサービス運営者が知らないと損害を生む「パスワード保護の在り方」:@ITセキュリティセミナー サイバーセキュリティの世界で取り上げるべきトピックは多々あるが、「基本的な守りを固める」ことも重要だ。2019年6月26日に行われた「@ITセキュリティセミナーロードショー」の中から、その際に役立つセッションの模様をレポートする。 2019年初め、ファイル共有サイト「宅ふぁいる便」で会員情報の漏えいが発生した事件では、世間に大きな驚きが走った。漏えいの事実自体もさることながら、保存されていたパスワード情報が「暗号化されていなかった」ためであり、特にインターネット上では「今どき、パスワードを暗号化していないなんて」と厳しい批判が相次いだ。 複数の調査や報道によると、パスワードを平文で保存しているサイトは宅ふぁいる便に限らない。その後FacebookやGoogle、Twit
モバイルアプリケーションから大規模な金融機関のインフラストラクチャーまで、ソフトウェアの構築方法は急速に進化しており、セキュリティは開発者が最初から考慮するものとなりました。開発のペースが速まると、セキュリティ侵害のリスクが大きくなります。セキュリティに気を使っている大企業でさえ、公開されているソースコードにパスワードを残したり、お客様の個人データを漏洩したり、明らかに脆弱性があるのに重要なアプリケーションを本稼働させたり、といったことは珍しくありません。多くの企業が新しいソフトウェアをいち早くリリースしようと懸命になり、ソフトウェアの安全性を保つことに苦労しています。 このように、企業におけるソフトウェア開発は迅速な作業とセキュアな構築の両立が課題になっています。新しい開発手法はコードをより早く市場に投入できますが、不適切なツールやプロセスを使うと、セキュリティが不十分になりかねません。
自社でECサイトを持つ事業者であれば、ECのセキュリティ対策を不安に思っているのではないのでしょうか?ECサイトにおいて、セキュリティに関する事故は以下の2つに大別できます。 ① クレジットカードの不正利用 ② ECサイトからの個人情報漏えい クレジットカードの不正利用被害や情報漏えいが後を立たず、日本クレジット協会(JCA)が発表した「クレジットカード不正利用被害の発生状況」によると、2022年のクレジットカードの不正利用被害の総額は436億を超えました。 このように、カード決済の不正や情報漏えい事故が後を絶たないことから経済産業省が主導し、クレジット取引セキュリティ対策協議会より「クレジットカード取引におけるセキュリティ対策の強化に向けて」という実行計画が2018年6月に施行されました。これにより、EC事業者であれば以下の2ついずれかに必ず対応しなくてはならなくなりました。 (1)クレ
WebAuthnでパスワードレスなサイトを作る。安全なオンライン認証を導入するFIDOの基本 FIDO(Fast IDentity Online)とは、公開鍵認証方式を応用し、オンライン経由で認証を行う仕組みです。パスワード認証の安全性は限界が指摘されるなか、Webサイトにおいても生体認証などパスワードレスな仕組みを導入する企業が増えており、このFIDOやWebAuthnに注目が集まっています。Capy株式会社で情報セキュリティに関する研究開発や分析などに携わる、松本悦宜さんの解説です。 こんにちは、松本悦宜(@ym405nm)です。 FIDO(ふぁいど)に関しては、昨年(2018年)から多くのメディアや技術ブログで取り上げられ、導入するWebサイトも増えています。 FIDO2プロジェクトにおいて話題になったWebAuthn(Web Authentication API)についても、主なW
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く