セキュリティ関連のHTTPヘッダを一括指定する Baseline ヘッダ - ASnoKaze blog
現在のWebでは、セキュリティ上レスポンスヘッダで色々なものを指定します。Webデベロッパーは個別に指定しなければなりません。 そこで、セキュリティ関連のヘッダを推奨デフォルト値に設定できるようにする「Baseline ヘッダ (Opt-into Better Defaults)」が、GoogleのMike West氏によって提案されています。 まだたたき台であり、これからW3CのWebAppSec WGで議論されている予定になっています。 Baseline ヘッダ 次のようにレスポンスヘッダを指定します。 Baseline: Security=2022これは、次のヘッダを送信するのと同様です。 Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none'; require-trusted-ty
暗号スイートの暗号強度と、公開鍵のビット数の設定、及びRSAとECDHEでサーバ負荷の比較 - Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。
見ず知らずの他人同士が、リーズナブルな計算量で、秘密の通信を行うためには、公開鍵暗号と秘密鍵暗号を組み合わせる必要があります。 この暗号の組み合わせのことを「暗号スイート」と呼びます。 OpenSSLには、多くの暗号スイートが用意されています。どの暗号スイートを選べばいいのか、迷ってしまうと思います。 そして、暗号スイート全体としての暗号強度は、公開鍵の強度も関係してきます。 ここでは、総当たり攻撃の耐性を基準に、暗号スイートと公開鍵の決め方を説明していきます。 以下、私の独断と偏見ですが、なぜGoogleやFacebookが、ECDHE(256bit)-ECDSA(256bit)-AES(128bit)の暗号スイートを使用するのか、ご理解いただけると思います。 併せて、Apache Webサーバ(httpd)のECDHEのビット数の変更方法(P-256, P-386)も、説明しています。
badssl.com
badssl.com 🎛Dashboard Dashboard 🎫Certificate expired wrong.host self-signed untrusted-root revoked pinning-test no-common-name no-subject incomplete-chain sha256 sha384 sha512 1000-sans 10000-sans ecc256 ecc384 rsa2048 rsa4096 rsa8192 extended-validation 🎟Client Certificate Certificate Downloads client client-cert-missing 🖼Mixed Content mixed-script very mixed mixed-favicon mixed-form ✏️HTTP h
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“C
HTTP ページ上でのパスワード要求はやめましょう
[これは Mozilla のセキュリティエンジニア Tanvi Vyas 氏のブログ記事 No More Passwords over HTTP, Please! を同氏の許可を得て翻訳したものです] Firefox 46 Developer Edition は、HTTP ページ上でログイン情報の入力を求められた場合、開発者に警告を行います。 ユーザ名とパスワードの組み合わせは、ユーザの個人データへのアクセスを管理する手段です。Web サイトはこうした情報を注意深く扱い、パスワードは HTTPS のような安全な (認証、暗号化された) 接続を通じてのみ要求すべきです。しかし残念なことに、HTTP のような安全でない接続でユーザのパスワードが扱われている例が 非常に多く 見られます。このプライバシーとセキュリティの脆弱性を開発者の皆さんに知らせるため、最新の Firefox Develope
Host:リクエストヘッダによるXSS - 葉っぱ日記
本日、とある会合にてTwitterで交わされていたこの会話が話題になりました。 紹介されている例はHostヘッダの操作を経路とする攻撃ということであり、Hostヘッダインジェクションという脆弱性はないと思いますよ / “PHPにおけるHostヘッダインジェクション脆弱性 ― A Day in Serenit…” https://t.co/sTzTQEE7a8— 徳丸 浩 (@ockeghem) 2015, 11月 6 @ockeghem @okumuri 実はIEでは細工したホストヘッダを送出できる手法が知られています。間違いなくIEのバグですが、このせいで値をそのまま出力しているサイトではXSSがありえてしまいます。ここが参考になります： https://t.co/G419aaUgNi— Masato Kinugawa (@kinugawamasato) 2015, 11月 9 知る人ぞ
HTTP リクエストの改ざん方法いろいろ - miauのブログ
私の会社／部署はいちおうセキュリティに強いことを売りにしているらしく、最近作ってる Web アプリケーションでは某セキュリティ会社による診断（ペネトレーションテスト）を受けることが増えています。 今作ってる Web プリケーションも診断を受けたのですが、今回指摘されたのは「HTTP リクエストを Host: ヘッダなしで送ると Location: に内部 IP アドレスが表示されている」というもの。 この検証を軽くやっておくかー、と思ったら結構いろいろやってしまったのでメモしておきます。ちょっとした HTTP リクエスト改ざんツール比較みたいになってますが、他にもいいやり方があったら教えてくださいませ。 ツールの選定基準について 「ローカルプロキシを立ちあげてブラウザのプロキシ設定を立ちあげて〜」というツールは、使い方を説明するのが面倒なのであまり使いたくありません。ブラウザのプラグインと
脆弱性の見つけ方（初心者向け脆弱性検査入門）
WEB系の情報セキュリティ関連の学習メモです。メモなので他情報のポインタだけ、とかの卑怯な記事もあります。 ※2020.9 注記:本ブログの解説記事は内容が古くなっております。OWASP ZAPなどのソフトウェアの解説は現行バージョンの仕様から乖離している可能性があります。 EC-CUBEで脆弱性を見つけたり、mixiの脆弱性報告制度で成果を挙げたりしたせいか、「どうやって脆弱性を見つけてるんですか？」という質問をされることが時折あり、一応手順は説明するのですが、いつも口頭で細かくは説明できなくて申し訳ないので、自分のやり方をまとめてこのブログにアップしておきます。 標準的な脆弱性検査のやり方しか説明していないので、脆弱性検査のやり方を既に把握している人が読んでも得るものは少ないのではないかと思います。今回は脆弱性検査に興味があるが何をどうしたらいいか分からないような初心者向けコンテンツで
大学の課題がわかりません。問題はGETリクエストとPOSTリクエスについて１セキュリティの高低がどのように違うか２保存再現性がどのように... - Yahoo!知恵袋
基本的には，GET は受信要求（リソースの取得）で POST は送信要求（データの送信）であり，GET と POST の違い (特徴) は，以下です． 下記の特性から問題の回答は分かると思います． ■GET ・データは Request-URI に含まれる（URL の末尾に '?' で連結する．複数のリクエストパラメータがある場合は，各パラメータと '&' で連結する． ==> ・URL はブックマーク保存できる． ・URL に含まれるため再現性がある（他人にその URLを教えるだけで同一データにアクセス可能)． ・URL にデータが含まれるので，Webサーバやプロキシサーバのログに残る． --> パスワードなどの秘匿性の高い情報を送信するのは危険である． ・GET に対するレスポンスはキャッシュできる場合が多い．キャッシュされると，ブラウザによってはリクエストせずに画面を表示する．このとき
Firefox 23 が Content Security Policy 1.0 仕様に対応
Firefox 23 （2013年 8月 6日正式リリース予定） が、クロスサイトスクリプティング （XSS） などの攻撃から Web ページを保護するための仕組み 「Content Security Policy 1.0」 仕様に対応しました。 Mozilla Hacks で、現在 Aurora チャンネルの、Firefox 23 が、Content Security Policy (CSP) 1.0 の仕様に対応した件、紹介されていました。 Content Security Policy (CSP) 1.0 は、あらかじめその Web ページで読み込まれることが想定されている JavaScript などのコンテンツを、ホワイトリストとして指定することによって、攻撃者によって挿入される悪意のあるスクリプトの読み込みを遮断し、クロスサイトスクリプティング （XSS） など、インジェクション
Webに関わる人のための『HTTPの教科書』を発売 - うさぎ文学日記
ひさびさの単著となる『HTTPの教科書』が2013年5月24日に発売になります。 内容はタイトルの通り、Webに関わる全ての人に捧げるHTTPを学ぶための教科書です。基礎を学びたい初心者の方から、机の上に置いてリファレンス的に使いたい方までを対象としています。 HTTPの教科書発売元: 翔泳社価格: ￥ 2,730発売日: 2013/05/25posted with Socialtunes at 2013/05/21 HTTP関連の書籍は『今夜わかるHTTP (Network)』というタイトルの本を2004年に出しています。その頃からHTTP/1.1が主流であるというのは、今でも変わりませんがそれを取り巻く環境というのは変わりつつあります。 HTTPを学ぶ上での要点がわかりやすく、そして読みやすくなっております。前作のリニューアルっぽく感じるかと思いますが、9割以上は書き直しや追記しており
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記
最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty
エラーメッセージの危険性
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 完璧なアプリケーションをいきなり作り上げられる人はまずいないだろう。多くの人はアプリケーション中にデバッグ用のメッセージやコメントを残しながら開発を進めていくことになる。またユーザーにとって重要なのがエラーメッセージである。エラーメッセージを頼りにアプリケーションを利用していく。しかし、ユーザーにとって有用な情報なのだが、同様に攻撃者にも有用な情報を与えてしまうことにもなることがある
スクリプトインジェクション対策の特集 – gihyo.jp
(Last Updated On: 2008年4月10日)技術評論社でブログっぽい記事を書かせて頂いています。4月3日からスクリプトインジェクション対策で注意すべき項目が掲載されます。一般的なスクリプトインジェクション対策「バリデーションしエスケープする」ではなく、万が一スクリプトインジェクションに脆弱であった場合でも被害を最小限に留める対策、見落とされがちな対策を中心に解説しています。 # 一度に書いた記事なのでどう分割されるか私も分かりません。 # 物によっては2回に分割するかもしれないので20弱くらい # だと思います。 http://gihyo.jp/dev/serial/01/php-security から最新の一覧を参照できます。 ご意見やご希望などございましたらこのブログから送って頂いても、メールで送って頂いても歓迎致します。ご興味がある方はご覧ください。 現在（4/9）時点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google、「Chrome」でHTTPサイトを“安全でない”サイトとして扱う方針を明らかに
HTTP通信の詳細内容を一覧表示する「HTTPNetworkSniffer」NOT SUPPORTED