.devドメインと.appドメインがHTTPSを強制する仕組み - Qiita
トップレベルドメインの中に.devと.appがある．これらはHTTPS接続を強制するドメインとして知られている．この仕組みが気になっていたので調べてみた． 参考: グーグル、完全HTTPS接続で安全なアプリ用ドメイン「.app」--早期登録を受付開始 - CNET Japan 結論: HSTSのPreload Listという技術を使っている． HSTS HSTS(HTTP Strict Transport Security)はHTTPでアクセスしてきたユーザ(HTTPクライアント)にHTTPSでのアクセスを強制するための技術である．対応しているWebサイトでは，HTTPレスポンスのヘッダに Strict-Transport-Security: xxx が付与されている．Qiitaの場合はstrict-transport-security: max-age=2592000が設定されている．R
XXE、SSRF、安全でないデシリアライゼーション入門
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
SSRF対策としてAmazonから発表されたIMDSv2の効果と限界
サマリ Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。 SSRFとは SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。 最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得する
Why Turning on HTTP/2 Was a Mistake - Lucidchart
Why Turning on HTTP/2 Was a Mistake. HTTP/2 is a great leap forward for HTTP. It increases bandwidth efficiency by using a binary compressed format for headers, decreases latency by multiplexing requests on the same TCP connection, and allows the client to specify priorities for requests. In many cases moving to HTTP/2 is the right thing to do, but for some applications, HTTP/2 can cause significa
2018年に公開されたセキュリティ関連文書まとめ - トリコロールな猫/セキュリティ
もう3月ですがやらないよりはいいだろうということで・・・。 2018年はリアルタイムには情報を追っておらず、お知らせ一覧等から調べているため抜けがあるかもしれません。 ルールは以下。 公共性の高いものを載せています WGや研究会の純粋な活動報告書、個別のインシデント・脆弱性は載せていません 情報源はこの辺。 security.nekotricolor.com 政府機関 METI 文書タイトル 公開日 情報セキュリティサービス基準 2018/02/28 情報セキュリティサービスに関する審査登録機関基準 2018/02/28 システム監査基準 2018/04/20 システム管理基準 2018/04/20 総務省 文書タイトル 公開日 公衆無線 LAN セキュリティ分科会報告書*1 2018/03/22 テレワークセキュリティガイドライン（第４版） 2018/04/13 IoTセキュリティ総合対
TLS1.3時代の新常識
TLS • TLS (reliable) endpoint endpoint CC BY 3.0 https://www.youtube.com/user/TheWikiLeaksChannel ClientHello+ ApplicationData end_of_early_data Finished ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData
安全なWebアプリケーションの作り方2018 - slideshare
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Securing Sensitive Data in Rails
It feels like data breaches are showing up every week in the news. If you haven’t taken a second look at how you’re storing sensitive data, now is probably a good time. Users trust you with the privacy and security of their information. This guide will walk through what data is sensitive, best practices for storing it, and pitfalls to avoid. What’s Sensitive? The National Institute of Standards an
徳丸浩の日記: SSRF(Server Side Request Forgery)徹底入門
SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート（岩間編） この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー（192.168.0.5）はファイアウォールで隔離されているため外部から直接
サーバー群への管理者アクセス権限を統制する | ロードバランスすだちくん
シンジです。sshを利用してサーバーへアクセスする際、IDとパスワードでrootにダイレクトアクセスさせてるケースもままあるでしょうが、監査も通らないし乗っ取りリスク高すぎ問題なので辞めたいところです。クラウドを日常的に利用する方々の場合、通常は証明書認証によってサーバーログインを行っていると思います。証明書ファイルが次々と増えていく問題、証明書ファイルを手に入れれば多くの人がサーバーにログインできちゃう問題は目をつぶるしかないのか。 そこでエンプラなどでは、「踏み台サーバー」を作って、そこでアクセス権限をコントロールすることで、サーバーログインへの統制を図るわけですが、第一踏み台から第二踏み台へそして第三踏み台とかいう絶望も現実的に存在している実状です。そもそも、エンプラが踏み台サーバーを自前で作るわけがなく、そういう製品を購入して作ってもらう、はい数千万円、保守費毎年よろしくみたいな世
Connect Okta to the 1Password SCIM bridge -Oktaから1Passwordへのユーザーアカウントプロビジョニングを実現する-
Connect Okta to the 1Password SCIM bridge -Oktaから1Passwordへのユーザーアカウントプロビジョニングを実現する-AWSTerraform1Password俺でもわかるシリーズokta 俺です。 組織運営をしていると、チーム単位などでパスワード情報を管理したいということがあるとおもいます。 そんな時はスプレッドシートに書いて共有設定仕掛けて安全だぜ。 という付箋紙にパスワードを書いてデスクに貼っておくレベルのITでしか仕事できない俺たちのために1Passwordというパスワードマネージャサービスがあります パスワードマネージャを導入する上で面倒なのがユーザープロビジョニングです。 入退社、異動や休職、復職に合わせてアカウントを管理するのは重要です。 退職したけどパスワード閲覧できてます。ああ声に出して読みたい。を防ぐため、 この1Pass
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
マイクロソフト、CPUの脆弱性対策でAzureの計画メンテを前倒し、全リージョンの仮想マシンを今朝から強制再起動。Googleは対策済みと発表
マイクロソフト、CPUの脆弱性対策でAzureの計画メンテを前倒し、全リージョンの仮想マシンを今朝から強制再起動。Googleは対策済みと発表 インテルやAMD、ARMなどのCPUに存在する脆弱性が発見された問題で、マイクロソフトはあらかじめ計画されていたMicrosoft Azureの計画メンテナンス期間を急きょ前倒しし、今日1月4日の8時半（日本時間）からAzure IaaS 仮想マシンが強制的に順次再起動されると発表しました。 CPU の脆弱性から Azure のお客様を保護するために – Japan Azure Technical Support Engineers' Blog [重要: 2018 / 1 / 4 更新] [告知] 2018 年 1 月 2 日より Azure IaaS 仮想マシンのメンテナンス期間が開始します – Japan Azure Technical Sup
さよならCSRF(?) 2017
はじめに 2017年、ついにOWASP Top 10が更新されました。筆者が一番印象的だったのは「Top 10にCSRFが入っていない」ということです。 なぜCSRFが圏外になってしまったのかは4ページのリリースノートで軽く説明されています。「retired, but not forgotten」つまり「引退したね...でも君の事は忘れてないよ」という感じでしょうか。全米がCSRFのために泣きそうです。 それはさておき、具体的には「as many frameworks include CSRF defenses, it was found in only 5% of applications.」という部分が引退理由だと思われます。「多くのフレームワークがCSRF対策を備えた結果、5%のアプリケーションにしかCSRFは見つからなかった」というのが引退の理由です。 この理由を読むと、「というこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
認証しないWeb認証 限定公開URLのセキュリティについて考える 公開版
Railsエンジニアのためのウェブセキュリティ入門
How JSON Web Token (JWT) Secures Your API
https://www.soumu.go.jp/main_content/000606964.pdf
祝RFC！Transport Layer Security (TLS) 1.3 発行の軌跡 ～熟成された4年間の安全性解析～｜株式会社レピダム
AWS のマネージドサービスを使ったセキュリティ強化のための自動化 / aws-security-automation - Speaker Deck
