[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました | DevelopersIO
本日のアップデートで ALB および CLB が HTTP Desync 緩和モードをサポートするようになりました。 Application and Classic Load Balancers are adding defense in depth with the introduction of Desync Mitigation Mode 何がうれしいのか HTTP Desync 攻撃とは このアップデートの何が嬉しいのかを理解するには、まず HTTP Desync 攻撃 について知る必要があります。 近年では Web アプリケーションでは CDN やプロキシをフロントエンドに配置し、バックエンドのサーバーにリクエストを転送するような構成を一般的にとられているかと思います。まず大前提として HTTP Desync 攻撃は、このようなフロントエンド、バックエンド構成において成り立ちます
![[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
政府によるインターネットの検閲とSNIについて
しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。 簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム（ドメイン名と考えてください）をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ
Appcanary - Everything you need to know about HTTP security headers
Appcanary makes sure you never run vulnerable software on your servers. Like our blog? Subscribe to our newsletter or podcast. Browse the archive, or follow us on twitter, github or rss. Some physicists 28 years ago needed a way to easily share experimental data and thus the web was born. This was generally considered to be a good move. Unfortunately, everything physicists touch — from trigonometr
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
httpoxy
Recommended reading Summary What Is Affected Immediate Mitigation Prevention Interesting, but once you’ve mitigated How It Works Why It Happened History of httpoxy CVEs A CGI application vulnerability (in 2016) for PHP, Go, Python and others httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict: RFC 3
Referrer Policy
This version: https://w3c.github.io/webappsec-referrer-policy/ Latest published version: http://www.w3.org/TR/referrer-policy/ Version History: https://github.com/w3c/webappsec-referrer-policy/commits/main/index.src.html Feedback: public-webappsec@w3.org with subject line “[REFERRER-POLICY] … message topic …” (archives) GitHub Inline In Spec Editor: Dominic Farolino (Google Inc.) Former Editors: E
安全でない HTTP は廃止予定となります (影響あり) | Firefox サイト互換性情報
インターネット接続は常に暗号化されるべきという提案に関して、業界は大筋で合意に達しています。新しい Service Worker API は元々 HTTPS が必須となっています。Mozilla 開発者の提案によれば、Geolocation、Notification、Fullscreen、Pointer Lock、Media Stream API といったユーザーの許可設定を必要とする一部の機能に関しても、今後 HTTPS が必須となる可能性があります。 また、非 HTTPS の Cookie をセッション Cookie として扱うことで、広告ネットワークとパブリッシャーの HTTPS 移行を促すことも提案されています。 まだ明確なスケジュールは出されていませんが、安全でない HTTP の廃止はそう遠くない将来に行われます。ウェブコンテンツ提供者にはできる限り早い時期に HTTPS への移
Webサービスを常時SSL化しようとして諦めた話
弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。 世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。 うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。 つづく。 続き。 弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブ
Socket.io with Websocket の SSL/TLS 対応 - tail my trail
※ (2016/9/19 追記) Nginx 使った対応方法も記載しているので、あわせて参考にして下さい。 昨今のサービスにおいて、暗号化はもはや必須の流れである。 GoogleやFacebookなど主要なサービスはずいぶん前からHTTPS通信を標準としているし、HTTPS化対応しているサイトはSEO的にも優遇されるようになる という方針が出ていたりする。 前記事でSocket.IO + Redis PubSubを用いたリアルタイムメッセージ配信の仕組みをまとめたが、このままWebSocketを利用すると当然インターネット上を平文のテキストが流れてしまう。 また、チャット機能を呼び出す親元のWebページがHTTPSで提供されているものであれば、Mixed Content でブラウザによっては暗号化されていないWebSocket通信をブロックされることもあるだろう。 後からSSL/TLS対応
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
自堕落な技術者の日記 : ChromeのSHA1証明書のアラート表示ポリシの問題点 - livedoor Blog（ブログ）
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
HSTS Preload List Submission
I am the site owner of example.com or have their permission to preload HSTS. (If this is not the case, example.com may be sending the HSTS preload directive by accident. Please contact hstspreload@chromium.org to let us know.) I understand that preloading example.com through this form will prevent all subdomains and nested subdomains from being accessed without a valid HTTPS certificate: *.example
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Analyse your HTTP response headers
deprecate protocol relative URLs by patrickkettner · Pull Request #1694 · h5bp/html5-boilerplate
[HTTPCLIENT-1613] Support for so called 'private' domains in Mozilla Public Suffix List - ASF JIRA
SSL/TLSの基礎と最新動向
X-Content-Type-Options: nosniff from Anne van Kesteren on 2015-04-02 (public-webappsec@w3.org from April 2015)
Standardize "nosniff" · Issue #35 · whatwg/fetch