(Last Updated On: 2006年6月23日)HTTPヘッダでASCIIを文字エンコーディングに設定していてもISO-8859として解釈してしまうブラウザ（Firefox、Operaなど）とASCIIとして解釈するブラウザ（IE）とが在るためIPSなどのフィルタをすり抜けられるかも知れない、という話。珍しくIEの方が標準に厳格(?)に対処しています。 リンク先のページをIE 6で表示すると7bit ACSIIでは無視されるべき8ビット目が無視され読める文字列が表示されますが、Firefox 1.5では8ビット目を無視せずISO-8859として解釈してしまい文字化けしているように表示されます。IEの動作の方が仕様的には正しいように思えますが、Firefox、Operaの動作の方が安全ですね。 どちらかと言うとWeb開発者が注意すべき問題ではなく、JavaScriptの脆弱性を利用

あるWebページにアクセスしたら、自分のYahoo! JAPAN IDやHatenaのID、mixiで使っている名前などが表示された。何の縁もゆかりもないページにこれらのプライベートな情報がなぜ表示されてしまったのだろうか。 これは「CSSクロスドメインの情報の漏えいの脆弱性（CVE-2005-4089）」という、Webブラウザがスタイルシート（CSS）を呼び出す機能にある脆弱性を利用した攻撃だったのだ。この脆弱性は通称「CSSXSS（CSS Cross Site Scripting）」とも呼ばれている。 CSSインポート時にCSS以外のファイルがテキストとして読み込める 最近のWebページは、文書の構造をHTML形式で記し、フォントや色やレイアウトなどの視覚的な表現をスタイルシートで記述するというHTMLの仕様に従っていることが多い。 HTMLファイルから外部のスタイルシートを呼び出すた

前回の「ステップ1」で書き出したリストをもう一度見ながら、「やっぱりこれはやりたい」「ゼロベース思考で考えてもやりたい」「時間対価値を考えてもやりたい」、「優先順位も高い」「やりたいと思い込んでいるだけでもない」「本当にやりたいんだ」、というものをチェックしてください。 「ステップ2」――先延ばしする心理的な要因が何かを調べ、自分の陥っているパターンに気づく 次に下にある「快・苦痛原理の実習」の表の「行動」の行にそのチェックしたあなたのやりたいことを1つずつ書き込んでください。 ステップ１で本当にやりたいことが抽出されたので、今度は心理的な抵抗がないか、自分の陥っているパターンをこの表を使って確認していきます。 やりたいのに先延ばしされている仕事は、たいていの場合、「やること」と「苦痛」が結びつき、「やらないこと」と「快」が結びついています。 「快・苦痛原理の実習」の表にある例、「机の片付

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

[p.s.] 2007-04-15 Subversion 1.4.0以降について少し補足しました。 – さくらインターネットでSubversionの補足。 cvsは入ってるんだけどSubversion使いたい→でも入ってない→じゃぁ自分で入れるか→Portsの使い方がワカラン てことで、調査に数時間を費やし、結局「make install」で「あんたはwheelグループじゃないからダメ(当然だ)」的なことを言われしょげてたんですが、どうせ入れたいのはSubversionだけなんだからパッケージ管理なんていらないしソースから入れればいいんじゃない？ってことに気が付き実行。 あっさり使えるようになりました。以下に手順。コピペで実行すれば、「$HOME/local/bin」にインストールされます。 $ mkdir -p $HOME/local/src $ cd $HOME/local/src $

4.4BSD カーネルは 4 つの基本機能を提供します。 それはプロセス、ファイルシステム、コミュニケーション、そしてシステムの起動です。 この節ではその 4 つの基本サービスのそれぞれについて この本で書かれていることを紹介します。 プロセスはアドレス空間上でのコントロールの流れを構成します。 生成や終了やその他のプロセスをコントロールするための仕組みは 4 章に述べます。システムは各プロセスの個別の仮想アドレス空間を 多重化します。このメモリ管理については 5 章で議論します。 ファイルシステムとデバイスへのユーザインタフェースは似ているため、 6 章ではそれらに共通する特徴について議論します。 7 章で説明するファイルシステムは、 ディレクトリが木構造になった階層で組織された名前付きのファイルと、 それらを扱うための操作からなります。 ファイルはディスクのような物理的なメディア上に存

■XSS脆弱性修正に失敗してしまった駄目な例 はじめに 本件は本日IPAに報告したものです。未修正の脆弱性を抱えているサイトについてつまびらかにすることは宜しくありませんし、そのことは重々承知しております。しかしながら色々な意味で非常に教訓的ですので、やや辛口の意見をここに書くことにしました。 XSS脆弱性があったのはどんなサイトでどんなページか 世界的に有数の超優良営利企業であり、主たる利益をITのセキュリティ方面で叩き出している某企業の公式サイトです。XSS脆弱性が存在するページは、その企業の収益を支える基幹ないし中核部分を担うサービスを行うCGIページです。 過去の恥辱と現在と 該当するページには、最近のことではありませんが、かつてXSS脆弱性が存在することが明らかになり広く報道された経緯があります。セキュリティ方面の企業としてはいかがなものかという評価を誰もが下すことでしょう。 そ

先日は，必要に迫られて Apache 1.3 の mod_access を改造したという話を書きました．その時は単にあるものを改造しただけでしたが，ふと思い立って，一から Apache 2.0 用のモジュールを書いてみました．書く上で色々 Web サイトを探してみたのですが，あまり日本語の入門向けの文章が見あたらなかったので，開発する上で分かったこと(と言うほど大したものじゃないですが)をまとめておこうと思います． フェーズには，例えばそのリクエストを受け付けるか拒否するかを決めるフェーズや，リクエストされた URI と実際のディスク上のファイルとの間の対応付けを解決するフェーズ，そしてもちろん実際のレスポンスを生成するフェーズ等があります．hook 関数を挿入するポイントはこれらのフェーズになりますが，もちろんその全てのフェーズのための関数を用意する必要はありません．また個別の設定を施す

onload とか onclick とかのイベントハンドラの種類ってどれくらいあるんだろうと思って <script> function EnumEvent( t ){ document.write( '<b>' + t.nodeName + '</b><br>' ); for( var i in t ){ if( i.substring( 0, 2 ) == 'on' ){ document.write( i ); // document.write( '=' + t[ i ] ); // with value document.write( '<br>' ); } } } EnumEvent( document ); EnumEvent( document.getElementById( 'div1' ) ); </script>みたいなスクリプトを書いてIEで調べてみたら、docume

第1回 Ajax技術の目に見えない通信内容をのぞいてみようでは、Ajaxの技術背景を解説しました。今回は、「セキュリティ」という観点でAjaxを見ていきたいと思います。 2回目の今回は、非常に幅広く、奥が深い「Ajaxの特徴に潜むセキュリティリスク」を、実際のサンプルアプリケーションの通信や、マウスの動きを動画で見ながら、理解しましょう。スパイウェアやキーロガーへの基本的な対策も解説します。 通常のWebアプリと異なるAjaxの特徴に潜むリスク 「Ajaxのセキュリティ」といきなりいっても、『Ajaxとはいえ、単なるWebブラウザで動作するアプリケーションなのだから、これまでのWebアプリケーションのセキュリティとあまり変わらないのでは？』と予想される方も多いでしょう。確かに、Webアプリケーションとして注意すべきセキュリティのポイントは、Ajaxにおいても共通して当てはまると考えて問題あ

このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー

ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増