This process is automatic. You will be redirected to your destination shortly. This will take up to 5 seconds.

お仕事のやり取りでたまに遭遇しつつ気になっていたのが、メールでファイルをやり取りする際にパスワードを設定し、そのパスワードを「メールで別途送ります」というやりとり。ファイル開くのに手間がかかるばかりで、セキュリティ的にもさほど高いとはとても思えず、でもこのやり方がビジネス上時折発生するのを不思議に思っておりました。 そんなことをわーわー騒いでいたら周囲の人がいろいろ意見をいただいたのでこのエントリーで簡単にまとめ。とはいえ、今のところ「パスワードはメールで別途送ります」のメリットが全然見えてなかったりもするのですが……。 1.誤送信防止のため 「パスワードは別途送ります」の理由として最初に教えられたのがこれ。1通だと間違えて送ってしまった場合にやり直しが効かないけれど、2通に分けて送ることで誤送信を対処できるとの理由だったんですがこれがどうにも腑に落ちない。 そもそも「宛先を間違う」ことを

This tool is designed for those situations during a pentest where you have upload access to a webserver that’s running PHP.  Upload this script to somewhere in the web root then run it by accessing the appropriate URL in your browser.  The script will open an outbound TCP connection from the webserver to a host and port of your choice.  Bound to this TCP connection will be a shell. This will be a

I’ve prepared a pretty comprehensive PHP security checklist that’s a good scan through. Update: This list was written in 2009 and now it is outdated, incomplete, and you can find more modern sources, such as OWASP. If you have any questions, feel free to leave a comment. The following is also now in a very concise printable form. Basic: Have strong passwords be sure that your “password recovery qu

Sunday, April 10, 2011 MySQL の Prepared Statement けさは、SQL インジェクションを少しだけ勉強したので、それに関して、ごく私的なメモを書き残しておこうと思う。情報処理推進機構 (IPA) の 「安全なウェブサイトの作り方」 では、SQL インジェクションの脆弱性を予防するための根本的解決として、まず第一に 「SQL 文の組み立ては全てプレースホルダで実装する」(改訂第5版 p.9) と述べている。 プレースホルダーには、動的プレースホルダーと静的プレースホルダーがあって、これらについては IPA の 「安全な SQL の呼び出し方」 が詳しい。 また、最近刊行された 『体系的に学ぶ 安全な Web アプリケーションの作り方』(徳丸浩著 ソフトバンククリエイティブ ISBN978-4-7973-6119-3) にも詳しい解説が載っている。大

補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの

著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz