大学内の勉強会に呼ばれたので学部生向けにお話しました
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー Pythonには「後方互換性を大切にする」というモットーがあって,時にはそれが裏目に出ることがある。PythonでWebにリクエストを送る時の手法は,目的に応じて複数存在するが,これも後方互換性を守るがために起こっている現象といえる。当初はシンプルな機能を持つモジュールが利用されていて,その後より高度な機能を持つモジュールが追加されたのだが,後方互換性を守るために古いモジュールが残されているのだ。 たとえば,普通にhtppでGETリクエストを送って結果を取得するなら簡単で from urllib import urlopen src = urlopen('http://www.exam
通信内容をキャッチすることによって、POP3・IMAP・SMTP・FTP・HTTPのパスワードを表示することができるフリーソフトがこの「SniffPass」です。「このメールアドレスのパスワードなんだったっけ?」という場合や「FTPのパスワードがわからないので実際に使っているFTPソフトの設定を見たが***になって表示されない」という場合に便利です。 パケットキャプチャ用のドライバは「WinPcap」と「Microsoft Network Monitor」が使用可能となっており、「Microsoft Network Monitor」のドライバを使えば無線LANからもパスワードを抜き出すことが可能となります。 というわけで、ダウンロードと使い方は以下から。 ◆有線LANの場合 まずは下記サイトから「WinPcap」をダウンロードします。 WinPcap, the Packet Capture
Translation of: Adding meaning to your HTTP error pages! by Stuart Colville This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license はじめに ウェブ上で何かを検索しようとすると、既に存在しないページしか検索結果になく、それらへのリンクをクリックすることはよくあるだろう。その開いたページにデフォルトのエラー・メッセージの他に何も情報が載っていなかった場合、多くの人々は戻るボタンを押し次の検索結果を開こうとするだろう。 サイト製作者である我々はもっと訪問者に意味のあるエラーページを作成することができる。そうすればたとえエラーページであっても訪問者をサイトに留まらせ、彼ら
今回は、Webサイトやサービスをメンテナンス中にする場合に、どのURLにアクセスしても「メインテナンス中です」の画面を出す正しいやり方を、人間にも検索エンジンにも適切にする作法を主眼に解説します。 この週末の土曜深夜~日曜早朝にかけて、データセンターの設備メインテナンスのため、Web担を含むインプレスグループのほとんどのWebサイトが、どのURLにアクセスしても「メンテ中です」という表示になっていました。 なのですが、その実装がちょっと気になったので、「正しいメンテナンス画面の出し方」を説明してみます。 ※2010-01-16 Retry-Afterを指定するHeaderの指定を修正しました(コメント参照) ※2009-06-17 RewriteCondから [NC] 条件を削除しました(コメント参照) ※2009-06-16 Retry-Afterの記述をGMTに変更しました(コメント参
PHPで開発をすることが多くなりPerlの良さを再確認している今日この頃ですが皆さんいかがお過ごしでしょうか。 さて、今日は今もっともナウいPHPのWebアプリケーションフレームワークであるCakePHPのお話を一つ。 CakePHPには組み込みコンポーネントとしてリクエストハンドラ(RequestHandler)が備わっています。 リクエストハンドリング :: 組み込みのコンポーネント :: マニュアル :: 1.2 Collection :: The Cookbook: このRequestHandlerのメソッドであるgetClientIPが小学生には危険そうだというお話。(あ、このエントリのタイトル逆w) まずはgetClientIPの実装コードを。(1.2を例にとっているが1.1もほぼ一緒である) https://trac.cakephp.org/browser/trunk/c
同一ホスト上にHTTPとHTTPSのページが同居しているサイトをしばしばみます。 そんなサイトでは、本来はHTTPのページに、HTTPSでもアクセスできるようになっていることがあります。そういう場合、HTMLの中身によってはセキュリティ上の問題が出ますよという話です。 問題があるページ http://www.example.jp/index.html というURLのページがあるとします。 問題となるのは、そのページの中身に以下のようなHTMLがベタ書きされている場合です。 <script src="http://www2.example.jp/foo.js"></script> このページ(index.html)はHTTPでのアクセスを想定して作られているため、JSファイルをHTTPで読み込んでいます。 ここで、このページが実はHTTPSでもアクセス可能だとします。もしHTTPSでアクセス
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Online classifieds Top Smart Phones Healthy Weight Loss Parental Control music videos Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
目次 この技術ですべてのフィッシング被害を防止できるとは思えないのですが。 この技術で救われるのはどんな人たちですか。 初期登録はどうするのですか。 Mutual アクセス認証を使えばTLSは不要になるのですか。 どんな場合に TLS の併用が必要ですか。 TLS を併用しない場合にはどんな危険が生じ得ますか。 なぜ通信内容も暗号化するように設計しなかったのですか。 TLS と Mutual アクセス認証の位置づけを簡潔に説明してもらえますか。 サーバを認証するというのは TLS のサーバ認証とは違うのですか。 EV SSL では不足ですか。 Digest 認証にも相互認証の機能はあったはずですが、Digest 認証では不足ですか。 PAKE を使わなくても相互認証は実現できるのではないですか。 PAKE を使うなら既に TLS-SRP があるのになぜ TLS-SRP を使わないのですか。
2008/04/23 産業技術総合研究所(産総研)とヤフーは4月22日、新しい認証プロトコル「HTTP Mutualアクセス認証」を組み込んだWebブラウザ「MutualTestFox」と、同プロトコルに対応したApache用モジュール「mod_auth_mutual」を開発し、オープンソースで公開した。 MutualTestFoxは、Firefox 3のソースコードをベースとし、新認証プロトコルを機能追加したWebブラウザで、mod_auth_mutualを組み込んだApacheと組み合わせることで新プロトコルを試すことができる。 HTTP Mutualアクセス認証は、これまで産総研の情報セキュリティ研究センターとヤフーが共同で進めてきたWeb向けのパスワード相互認証プロトコルの研究開発の成果を実装したもので、2007年3月に発表した「抜本的なフィッシング詐欺防止技術」に基づいている。
http環境では動いていたFlashがSSLに移したとたん動かなくなった。 エラーの内容はioErrorのストリームエラー。 発生ブラウザはIEのみ。 「Safari、Firefox等はばっちり動いているのになぜ!!」って感じでいろいろ調べてみたら、どうやら、サーバーサイドプログラムのレスポンスヘッダーの影響によるものらしい。 レスポンスヘッダーに Pragma: no-cache があったら、値を「no-cache」以外の値に変更すればokみたい。 参考にさせていただきました。 ありがとうございます! FLASHとSSLとIEの関係 — Garage with Blue Sky red日記: Flash + SSL
新人に捧げる「Webブラウザの仕組み」 皆さんが毎日利用している「Webブラウザ」。インターネットの創成期から現在まで進化を続けながら、一線で活躍する技術です。今回はこのWebブラウザについてあらためて見てみましょう。 前編・後編2回に分けて、前編ではWebブラウザとサーバの通信の仕組みや役割、後編ではWebブラウザやHTMLの歴史と未来について説明します。 基本的な説明ですが、読めば新しい発見があるかもしれません。 WebサーバとWebブラウザの甘い関係 インターネットを通じてWebブラウジングするとき、私たちはInternet Explorer(以下、IE)やFirefoxといった「Webブラウザ」ソフトを使ってWebサーバにアクセスします。Webサーバが画像やテキストといったデータをWebブラウザに送り、Webブラウザが情報を解釈して表示します。では、ここでのWebサーバとWebブラ
2008/2/22: sotarok様より、連絡がありコードを一部訂正 参考1)http://d.hatena.ne.jp/odz/20080215/1203099900 参考2) http://d.hatena.ne.jp/cocoiti/20080221#1203611811 PHPでファイルをDLさせる際のPHPコード例 通常、PHPでファイルをダウンロードさせるとすると、次のようにシンプルにかけます。<?php header('Content-Type: application/octet-stream'); readfile("dl.zip"); ?> が、これだと、ダウンロード時に、保存名がアクセスしたphpでのファイル名になってしまいます(例えば、dl.php)。 そこで次のように Content-Disposition でファイル名をブラウザに通知することで、dl.zip
as3httpclientlib - a better http-client in ActionScript by Gabe 21 Jan 2008 Gabriel Handford left a comment with as3httpclientlib link, this is a very well written http-client, with TLS support, in ActionScript 3.0. Let me clear some points here, as3httpclientlib is not as3httpclient. The as3httpclient, let's call it my-project in rest of the post, was a better version of HTTPURLLoader. HTTPURLLoa
Flash | FlashでHTTPステータス HTTPStatusEvent - Adobe Flex™ 2 リファレンスガイド HTTP ステータスコードをプレーヤーに渡すことができないブラウザで実行される Flash Player プラグインでは、常に値 0 が生成されます。該当するブラウザには、Netscape、Mozilla、Safari、Opera、および Internet Explorer for the Macintosh があります。URLLoaderクラスでサーバから受け取ったレスポンスのHTTPステータスコードを参照しようとしたら、常にゼロ。どういうわけだ?と思ってAPIドキュメントを調べてみたら、ちゃんと書いてありました。 って、Win IE以外の主要ブラウザではHTTPステータス取得できないじゃん。HTTPステータス取得は諦めるしかないか。 URLLoader
こんにちはこんにちは!! 先日、Twitterで声をかけてもらって、 第一回 Port801 セキュリティ勉強会っていうのに参加してきたよ!! (↑pw: security) そこで、すこし喋った時のビデオを頂いたので、もったいないので公開しちゃいますね! プレゼンだとかそういうの慣れてなくて、ぐだぐだな感じだけど、 よかったら何かの参考にしたり、晩ご飯のおかずにしてください>< Port801 セキュリティ勉強会 - Hamachiya2 その1 (http編) Port801 セキュリティ勉強会 - Hamachiya2 その2 (CSRF編1) Port801 セキュリティ勉強会 - Hamachiya2 その3 (CSRF編2) Port801 セキュリティ勉強会 - Hamachiya2 その4 (XSS編1) Port801 セキュリティ勉強会 - Hamachiya2 その5
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう?というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して(HTTP1.1では303応答)、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
--------------------------------- 11/15追記:Flash Playerのヘッダインジェクションの脆弱性が直ったようです。 Update available for HTTP Header Injection Vulnerabilities in Adobe Flash Player これで、とりあえず、Referer操作はできないみたいです。そして、何故か、「Expect」ヘッダも同様に操作できなくなってるみたいです。そういう直し方微妙です。 他のヘッダは?問題が出るWebアプリケーション結構あるのですが・・・。 そして、気になるのが、Flash Playerの新しいのが出たからといって、更新する人がいるかってとこですね。自動更新されないすよね。を、一応あるのか。設定しないといけないっぽいけど。→ここ? Flashで作られてるって事は、勝手に自動更新オ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く