http://www.rubyist.net/~matz/20080126.html#p04 趣味でやってるプログラミング初心者の立場で言わせてもらう。だいたいな、あんたらプロのプログラマが小難しい顔してセキュリティセキュリティ言うもんだから初心者プログラマのセキュリティ意識がまったく向上しないばかりか、よけいに低下するんだよ。ごちゃごちゃ言われたり叩かれるのはイヤだけど、眼前の問題はプログラムで解決したいってヤツは耳塞いで黙ってPHPでやりたいようにやるんだよ。何が「楽しいRuby」だよ。「Webアプリケーションをなめるな」ってその時点でもう全然楽しくねーだろが。 それでこれだよ。 http://d.hatena.ne.jp/essa/20080130/p1 もう萎縮萎縮！初心者超萎縮ですよ。「あーセンコーうぜー。隠れてタバコ吸おう」って高校生の心境だよ。難しい顔して訳知り顔でかっこつけ

PHPがいかに駄目な言語かについてを、「日本発オブジェクト指向スクリプト言語Rubyの作者」まつもとゆきひろさんが客観的にコメントしました。 そのコメントに対して、いろいろと論争が起こっているようです。 流れのまとめと、個人的な思いを書いておきます。 1月26日、PHPがいかに駄目な言語かについてを、「日本発オブジェクト指向スクリプト言語Rubyの作者」まつもとゆきひろさんが客観的にコメントしました。 Attacking PHP PHPがいかに駄目な言語か、という話。 （中略） 特に「PHPは初心者に学びやすい(と言われていることが問題である)」という部分に共感する。 PHPは初心者に簡単かもしれないが、初心者による手を抜いたWebアプリケーションは PHPが作られた当初はともかく、現代では害悪ではないだろうか。 Webアプリケーションをなめるな PHPならではの理由がないわけではないこと

ロードバランサーの機能のうち、セッション維持は重要な役割な一つです。セッション維持を実現するための方法としては主に4つあります。 ソースIPアドレス利用 Cookie利用 SSL Session ID利用 URL利用 一番手軽なのはソースIPアドレスを利用する方法なのですが、NAT環境では全てのマシンが同じIPに見えてしまうのでこの方法が使えない場合も多いと思います。そんなわけで私はこれまでCookieを利用する方法をよく使っていました。しかし最近になってCookieを利用したセッション維持が失敗するケースが増えてきました。それはなぜか？ 【Cookieを利用する方法の問題点】 Cookieを利用したロードバランスでは、セッション情報をCookieに書き込みます。ところでCookieの仕様をRFC2965で確認してみると at least 300 cookies（少なくとも300個のCoo

こんにちは、佐々木です。 他社サイトへのリンクが含まれるような開発環境で作業を進める場合、使用しているブラウザを「リファラを送信しない設定」にする必要があります。うっかりクリックしてしまったサイトに送信したリファラから「開発環境のURLがばれてしまう」という危険を防ぐためです。 つまり、リファラを送信する設定のまま開発環境で作業を進めることは、「スーツの内ポケットにキャバクラのマッチが入ったままになっている」のと同じくらい無防備な状態といえます。惨事が起こる前に、しっかりと準備をしておきましょう。 『Internet Explorer』の場合 『Internet Explorer』（以下、IE）の場合は「Proxomitron」を使う方法もありますが、リファラを送信しない設定だけであれば「Fiddler2」のほうが簡単ですので、ここではその方法を紹介します。 Fiddler2 を使ってIE

ログインが必要なサイトの多くは、IDとパスワードを入力するフォームが設置されています。 通常、このようなフォーム内のパスワード部分に入力した文字は盗み見防止のため、「********」のようなアスタリスクになって文字が隠されるようになっていますが、しばしば、この入力したパスワードを確認したい状況になる場合も少なくありません。 このようなケースに役立つハックの紹介。 以下のJavaScriptをアドレスバーに入力すると、次のようなダイアログ内にパスワードが表示されます。 javascript:(function(){var s,F,j,f,i; s = ""; F = document.forms; for(j=0; j<F.length; ++j) { f = F[j]; for (i=0; i<f.length; ++i) { if (f[i].type.toLowerCase() ==

Linuxの勉強の為、自宅サーバをCentOS4.2で構築し、http:80を公開（後にsshも）したいと思っています。その際のパッケージ管理ですが、基本的にyumをやっておけば良いものなのでしょうか？ それとも、個別のパッケージ毎にアップデートされた時点で、インストールしなおす運用の方が良いのでしょうか？ yumを使ってみて、Windows updateの様にお手軽にパッケージ管理が出来るので、出来ればこれを使いたいと思っています。 でも、Apacheを見るとyum updateしても2.0.52のままで、Apacheサイトを見ると、2.0.55が最新のようです。 しかも、2.0.55ではセキュリティの問題が修正されている様です。 一般的に、自宅サーバ等を構築する場合、どの様に管理されているのでしょうか？是非、教えていただけませんか？よろしくお願いします。 一応、使っているブロードバンド

Copyright © 2024 Information-technology Promotion Agency, Japan（IPA）　法人番号 5010005007126

■CSRF - クロスサイトリクエストフォージェリ CSRF - クロスサイトリクエストフォージェリ SpecIII - CSRF - クロスサイトリクエストフォージェリから引用させて頂きます。 CSRFの概略 CSRFはCross Site Request Forgeriesの略です。恥ずかしながら私は最近こういったこういった攻撃方法があることを知りました。日頃のアンテナの低さがバレますね。 CSRFはサイトに対する正規のユーザーの権限を利用した攻撃です。あるサイトのある処理を行うページに正規のユーザーを誘導し、強制的に望まない処理を発生させます。 具体的には記事の編集や削除といった機能を持つページのURLをダミーのリンクに埋め込んで踏ませたり、imgタグのsrcとして指定して知らず知らずのうちにアクセスさせます。特に後者の例ではユーザーが全く気がつかぬうちに攻撃が完了します。攻撃の結果

情報処理推進機構（IPA）は11月1日，安全なWebサイトを構築・運用するためのポイントをまとめたドキュメント「安全なウェブサイトの作り方」の改訂版（改訂第2版）を公開した。改訂版ではクロスサイト・リクエスト・フォージェリ（CSRF）の解説などを追加した。 同ドキュメントの第1版は2006年1月末に公開された。ドキュメントでは，IPAへの届け出件数が多かった脆弱性や，攻撃を受けた場合の影響が大きい脆弱性を取り上げ，それらを作りこまない実装方法や影響を軽減できる実装方法を具体的に紹介している。 改訂版では，第1版で取り上げた「SQLインジェクション」「OSコマンド・インジェクション」「ディレクトリ・トラバーサル」「セッション管理の不備」「クロスサイト・スクリプティング」「メールの第三者中継」に加えて，「CSRF（Cross-Site Request Forgeries）」と「HTTPヘッダー