httpとセキュリティに関するnanakosoのブックマーク (12)
-
nanakoso 2022/02/04
-
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
-
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
-
Twitter や Facebook が SSL 3.0 を無効にしたので死にかけた話 - しばやん雑記
今朝、Twitter や Facebook が SSL 3.0 を素早く無効化したため、API を使って処理を行っていたアプリが全滅するという悲惨な出来事が発生しました。 Twitter や Facebook の API を使っている場合、Global.asax.cs とかの初期化コードに以下のような設定を書いていると、接続を確立出来ないので死にます。 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 実際に twitter.com へアクセスするコードを書くと、見事に例外が投げられます。 SSL 3.0 は無効化されているので、チャネルを作れないのは当たり前と言えば当たり前です。 ちなみに SecurityProtocolType.Ssl3 以外を指定している場合には成功します。 当然ながら、何も指定してい
-
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
-
サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
-
WebSocketがセキュリティ問題を解決して再び実装へ
Webブラウザとサーバのあいだで専用のプロトコルを用いて通信を行うことで、サーバからのプッシュなど、より柔軟なデータのやりとりをWebブラウザとサーバ間で可能にするWebSocket。当初はHTML5仕様の一部として検討され、その後独立した仕様となりましたが、昨年12月にセキュリティ上の問題が発覚。見直しが行われていました。 WebSocketはプロトコルをIETFが、APIをW3Cが策定中ですが、IETFがセキュリティ問題を解決したプロトコル仕様のラストコールを発表しています。いつもWeb標準の動向を伝えてくれる「Web標準Blog」の記事「WebSocketプロトコルがLast Callに」が伝えています。 過去のバージョンとの互換性はなし WebSocketは、昨年にFirefox 4やOperaに実装されましたが、プロトコルにセキュリティの問題が発覚。いったん機能が無効になりました
-
特定の国からのアクセスを禁止する方法 など10記事（海外&国内SEO情報） | 海外&国内SEO情報ウォッチ
ErrorDocument 403 http://www.blockacountry.com/blocked.php <Limit GET HEAD POST> order allow,deny deny from 58.14.0.0/15 deny from 58.16.0.0/16 deny from 58.17.0.0/17 deny from 58.17.128.0/17 deny from 58.18.0.0/16 deny from 58.19.0.0/16 deny from 58.20.0.0/16 deny from 58.21.0.0/16 deny from 58.22.0.0/15 deny from 58.24.0.0/15 deny from 58.30.0.0/15 deny from 58.32.0.0/13 deny from 58.40.0.0/15 d
-
P-07AでもJavaScriptが再開され、あらたな制限がみつかった - ockeghem's blog
i-mode2.0は前途多難 - ockeghem(徳丸浩)の日記にて報告したように、ドコモのiモードブラウザ2.0のJavaScript機能が5/28に停止されていたが、本日ケータイアップデートが準備されたので、深夜3時まで待たずに即座にアップデートを実行した。そして、JavaScriptが復活していることを確認した。 iモードブラウザ2.0のJavaScript « mpw.jp管理人のBlogで報告されているように、alert関数や、setRequestHeaderメソッドが無効化されていることを確認した。関数自体は削除されていないのだが、実行しても何もおこらない状態になっている。alertを無効化した理由は理解に苦しむが、setRequestHeaderを無効化したのは、携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性で指摘したような危険性を
-
Hamachi+HTTPプロキシで職場のネット規制を楽勝突破 | 教えて君.net
職場などの出先マシンから安全に会員制サイトや掲示板などを利用したいなら、自宅のマシンにHTTPプロクシを仕込んでおこう。出先マシン→自宅マシン→ウェブサーバという形で、自宅マシンを経由したウェブ巡回を行うことができるようになる。 Hamachiを利用すれば、出先マシンと自宅マシンの間の通信が暗号化されるので、職場のウェブ規制を突破してネットを自由に利用することが可能。ウェブサーバから見たアクセス元が、出先マシンでも第三者が公開するプロクシサーバでもなく、自宅マシンになる点もポイントだ。 公開プロクシを使っているわけではないので2ちゃんねるのプロクシ規制に引っかかる可能性がないし、真のアクセス元である出先マシンのIPアドレスは一切漏洩しないので、自社製品を褒める書き込みなどを行い「GK乙」的な事態を招く危険性もない。 Hamachiの設定方法はこちら ■ 『BlackJumboDog』を自宅
-
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
-
MOONGIFT: Web2.0時代のセキュリティ査定ツール「Ratproxy」:オープンソースを毎日紹介
ブラウザが多用されるようになり、ローカルのアプリケーションだけだった時代では想定されなかったセキュリティリスクが出てきている。そして、それらの問題に対応するべく様々な情報がインターネット上に掲載されている。 レポート だが一般ユーザはもちろん、ITに詳しい人であっても、それらの情報を活用しているとは言い難い。情報を元に、どのような施策を行うか、それが重要だ。 今回紹介するオープンソース・ソフトウェアはRatproxy、グーグラーが開発したWebアプリケーションセキュリティ査定ソフトウェアだ。 Ratproxyはいわゆるプロキシとして動作するソフトウェアだ。デフォルトで8080を使って立ち上がる。後はブラウザのプロキシを設定して、様々なサイトを閲覧すれば良い。結果はログファイルに吐き出され（ファイル名を予めしておく必要がある）、その結果を解析してレポートを作成してくれる。 実行中 検査する項
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました