商用環境で設定しておきたいセキュリティ関連 HTTP ヘッダまとめ - A Memorandum
TL;DR X-Content-Type-Options X-Frame-Options(XFO) X-XSS-Protection Content-Security-Policy (CSP) Upgrade-Insecure-Requests Strict-Transport-Security (HSTS) Public-Key-Pins (HPKP) 設定 TL;DR X-Content-Type-Options MIME スニッフィングの無効化 X-Frame-Options(XFO) フレーム表示を制限しクリックジャッキングを予防 X-XSS-Protection XSSフィルタの有効/無効 Content-Security-Policy (CSP) XSSなどの攻撃を軽減するセキュリティレイヤー Strict-Transport-Security (HSTS) HTTP の代わり
HTTP/2における双方向通信とgRPCとこれから - Qiita
この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。
セキュリティを強化する7つの便利なHTTPヘッダ | DevCentral
Webアプリケーションの開発・展開を行っている人々にとって、セキュリティ確保は大きな関心事の1つだといえます。そのためのベストプラクティスやフレームワーク、ガイドラインを提供しているのがOWASP（Open Web Application Security Project）です。OWASPのWikiサイト（OWASP.org）には、Webアプリケーションのセキュリティ確保のための様々な情報がありますが、それらの中でも即効性の高いのが「便利なHTTPヘッダのリスト（List of useful HTTP headers）」だといえるでしょう。 このページには、アプリケーションのHTTPレスポンスに追加することで、事実上無料でセキュリティを強化できるHTTPヘッダが7種類掲載されています。 これらの中でまず活用したいのが、以下の2つのHTTPヘッダです。 X-XSS-Protection 最近
マンションのLAN内のゲートウェイが中間者攻撃してくるお話 - Qiita
来歴 私は去年、とある賃貸マンションへ入居した。 インターネットは無料で利用可能、壁の端子にLANケーブルを挿すだけ。 ただ、この物件のインターネット回線がおかしい。1日に1回くらい、Webサイトを閲覧しようとしたときに、マンションの管理会社のホームページへリダイレクトされる現象が起きる。 イメージとしてはこんな感じ。 東京の天気が表示されるべきなのに、入居者用Webページのログイン画面へリダイレクトされる。 腹が立ったので今年の5月くらいに現象を調べ、原因がわかったことで満足していたが、重い腰を上げて結果を以下の記事にして公開する。改めてGoogle先生に聞いたら、同じことで悩んでいる人がいた。 自動リダイレクトの回避方法について。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10165027165 なお、後述の図には
Apache HTTP Server向けのWebアプリケーションファイアウォール（WAF）「ModSecurity」を使ってみよう | さくらのナレッジ
オープンソースのWAF WAFとして利用できるソフトウェアは多数存在しており、その多くはセキュリティ企業などが提供する商用製品/商用サービスとなっている。しかし、数は少ないがオープンソースのWAFも存在する。オープンソースのWAFとしてよく知られているのが次の5つだ。 ModSecurityはApache HTTP ServerやNginx、Microsoft IISのモジュールとして提供されているものだ。このモジュールを組み込むことで、これらWebサーバーをWAFとして利用できるようになる（図1）。 図1 ModSecurityのWebサイト 活発な開発が続けられており、採用実績も多い。DebianやUbuntu、Red Hat Enterprise Linux（RHEL）およびCentOSといったその互換OSなどでは標準でパッケージが提供されており、導入も容易だ。検出用のルールセットは
【暗号化】「http」と「https」って何が違うの？【SSL/TLS】 - Milkのメモ帳
「https」って何？ 何が問題になるの？ 「https」は暗号化して通信を行う 「SSL/TLS」とは？ 暗号化は進化している 「https」と「SSL/TLS」の関係 暗号化と復号化 HTTPSの方式は掛け合わせる SSL証明書 HTTPSを利用するにはサーバの設定が必要 最後に こんにちは。Milkです。 Googleの方針が明確になり、ちょっと「http」と「https」の話題が多くなりましたね。 私にもGoogle神から直接メールが来ました。 早く「https」に対応しないと、ユーザに入力を求める画面では「警告」を表示するようにしちゃうぞ☆って これは、2017年10月以降に行われるらしいです。 現時点（2017年8月19日）では、このブログは「http」で運営されています。 「https」に切り替えたいけど・・・その前に、「https」って何だったっけ？ これは私の勉強も兼ねて
実践的なアプリケーションを書いてみよう！ Rustの構造化プログラミング【第二言語としてのRust】 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
実践的なアプリケーションを書いてみよう！ Rustの構造化プログラミング【第二言語としてのRust】 Rustを使って、実際にアプリケーションを3つ書いてみましょう！ その前に、プログラムの構造化に必要な手法、ジェネリクス、構造体、列挙型、それにトレイトといった概念についても説明します。 前回の記事では、Rustの基本的な文法や型を説明し、他のプログラミング言語ではあまり見かけない、Rustならではのメモリ管理の仕組み（所有権・参照・ライフタイム）についても解説しました。 今回は、Rustを使って、実際にアプリケーションを書いてみましょう。 制作するのは、Unix環境ではお馴染みの文字列検索プログラムであるgrep（その機能限定版をRustで書いたrsgrep）、アナグラム（単語の文字を入れ替えた単語）を求めるプログラム、そしてHTTP/0.9サーバです。 しかし、アプリケーション開発に入
グーグル、HTTPページへの警告表示を強化へ--10月リリース予定の「Chrome 62」から
Googleは、多くのHTTPページに「Not secure（保護されていません）」と表示する計画の次の段階に備える時間として、ウェブ開発者に6カ月の猶予を与える。 「Google Chrome」ですべてのHTTPページに「Not secure」と表示するGoogleの計画は、10月より第2段階に入る。 Googleは1月、「Google Chrome 56」のリリースに併せて、HTTPの一部のページで安全性の警告表示を開始した。この段階で影響を受けたのは、ウェブ上でログイン情報や決済カードデータなどの機密情報を送信するページだ。 Chromeは10月より、ユーザーがHTTPページで何らかのデータを入力できるようになっていれば、そうしたページに安全性の警告を表示する。Googleはこの表示について、テキストボックスを含むすべてのページに適用されると強調している。 GoogleでChrome
HTTP/2とは？ - ロリポップ！レンタルサーバー
「HTTP/2」による通信では、複数のリクエストを同時に処理する能力が向上したことで、表示速度が改善されるんです（※）。 従来の「HTTP/1.1」による通信では、サーバーへのリクエスト順に応答させていく必要があって、たくさんのコンテンツを扱う最近のウェブサイトだと表示速度が遅くなるなどしていました。
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
CakePHP の書き方 | php-tips.com
この記事は、CakePHP3 Advent Calendar 2016 25日目の記事ではありません。 まとめ Controller/Componentにビジネスロジックを書かない カスタムfindを活用しよう 1テーブル1モデルではなく、場面によってモデルクラスを増やそう Modelless Form / Tableless Modelを活用しよう beforeSave/afterSaveは諸刃の刃 Behaviorにビジネスロジック書くのもあり View層ではView Cell/View Blockを活用しよう CRUDプラグインお勧め この記事を書いた動機 CakePHPにおいてビジネスロジックに該当するものをComponentに書くという記事を見かけるたびに、それはアンチパターンじゃないのと感じている日々。 ビジネスロジックをどこに書くべきか、共通処理をどこに書くべきかというのを、
JMeter でシナリオを書く時に HTTP プロキシサーバを使えば少し捗るかもしれないメモ - ようへいの日々精進XP
台風直撃の朝。 tl;dl 先日立ち上げた Redmine 環境に対して JMeter で負荷テストを行う為のシナリオを作ってみようと思った 但し HTTP リクエストをポチポチ作るのは辛いと思ったら HTTP プロキシサーバ（HTTP(S) Test Script Recorder）という機能を利用すると少し捗りそうな気がした ということで、雑なメモ。 参考 https://blazemeter.com/blog/how-load-test-csrf-protected-web-sites http://jmeter.apache.org/usermanual/component_reference.html#HTTP%28S%29_Test_Script_Recorder http://qiita.com/t_cyrill/items/9d5376f38b4c15fd4eb1 ありがと
HTTPとサーバ技術の最新動向
デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
DC内通信のHTTP/2化を検討する | GREE Engineering
こんにちは、インフラストラクチャ部の後藤です。 懲りずにHTTP/2の記事です。 HTTP/2を実サービスに投入するのには様々な障壁があり、議論が足りてない部分だと感じています。 サイトのHTTPS化 TLS ALPN, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 サポート モニタリング・監視 Dependency Based PriorityとRUM コネクションの生存時間が長く、運用上のDNSを用いたサーバ切り替えと相性が悪い(GOAWAY出せるものもあるが) ELBを使用している場合はTCPで利用する必要がある そもそもL7ネットワーク機器が対応していないという場合もあるかとおもいます。 そこで、今回は比較的容易なDC内のHTTP通信をHTTP/2化することを考えます。 DC内HTTP通信のHTTP/2化 DC内でサーバ間のHTTP/2通信であれば、h
Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]
この記事は ピクシブ株式会社 Advent Calendar 2015 10日目の記事です。 qiita.com こんにちは。Androidアプリエンジニアのいとおちゃんです。 高校生の頃からアルバイトとしてピクシブに入社してから4年目になりました。昨年は若手アルバイトと名乗っていましたが、気づいたらもう大学生です。最近はpixivマンガアプリの開発をしています。 今回はAndroidアプリ開発の話ではなく、個人的に最もアツいと感じているLet's Encryptを使ってnginxでHTTP/2サーバを立てる話をします。 Let’s Encryptを使おう Let's Encryptを利用すると、無料で認証されたSSL証明書を簡単に発行することができ、ここ最近話題を集めています。今月、Let's EncryptはようやくPublic Betaになりました。そこで、まさに今が旬ともいえるLe
![Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4567d7f0adf50228a21ca960797fc34b9d5e6d7/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Fitochan315%2F20151209%2F20151209202000.png)
HTTP のステータスコードを簡単に調べる - tellme.tokyo
HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードで、RFC 2616、RFC 7231等によって定められている。via HTTPステータスコード - Wikipedia 403とか404はよく目にもするので覚えていますが、300番台は？500番台は？とかとなると思い出せないことが多いです。いちいちググり直すのも手間。そんなときに、bash なりのシェルにてエイリアスとして登録しているハックを目にしました。 Jxck/dotfiles - GitHub このまま参考にさせてもらおう、と思ったのですがすべて登録するのもな、と思いコマンドで用意しました（番号が変わるものでもないので一度登録して変更することになる心配がないためエイリアスもいいと思います）。 b4b4r07/http_code - GitHub antigen で簡単に
Golangで作ったhttpdの接続数を制限してみよう
こんにちは。斎藤です。 ここ1〜2年、私は仕事でGolangを書くことが増えています。きっかけは、ITインフラをお預かりする中で、お客様のサーバにツールを置く場合でも1つのバイナリさえ置けば良いという手軽さからだったのですが、最近はScalaと並び手軽に並列処理が書けるプログラミング言語として重宝しています。 さて、今回はGolangで作ったhttpdの接続数をLimitListenerを利用して接続数の制限をしてみようというお話です。以下に紹介するお話は、Githubのリポジトリ "github.com/koemu/go-http-max-connections-demo" にデモプログラムを保存しています。Golangのビルド環境がある方は、実際にビルドしながらお試しいただければと思います。 ※Golang 1.5.1でビルドする前提で説明しています モティベーション 仕事でとあるAP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「http://」も暗号化通信する仕様へ？ HTTPの「高速化」や「日和見暗号」の標準化議論【IETFトピックス2016-17】
