PHPカンファレンス2014セキュリティ対談資料「ウェブエンジニアが必要なセキュリティとは」の対談セッション時の資料として用意したスライドです。Read less
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: )一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに対して文字エンコーデ
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
PHP4.4.9のセキュリティ状態
(Last Updated On: )PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。 PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。 PHP4セキュリティ保守サービスではPHP 4にも対応しています。サポートしている脆弱性の概要は、弊社のお知らせをご覧下さい。 まだまだ、SQLインジェクションが無くなっていない事は非常に残念です。PHP4で作られたWebアプリケーションはSJISやEUCを文字エンコーディングに利用してい
Re:ENT_QUOTES脳？ - Memo
突っ込み頂いたから返信します。 via 岩本隆史の日記帳 さん 「こんにちは」から始まる1行のみmain.phpに書かれているということだろう。 このコード、htmlspecialcharsの第2引数が「ENT_QUOTES」でなかったらどんな問題があるというのか。私にはまったく分からない。 「いや、問題がある」という方は、高木浩光さんの下記記事も批判してみてはどうか。 http://d.hatena.ne.jp/IwamotoTakashi/20080411/p1 こんな簡単なコードに一々 目くじら立てて、ENT_QUOTES 漏れを突っ込むなよって事でしょうか？ それなら「セキュリティを気にしましょうね」と啓蒙している web デザイナ向けの記事で、エスケープ漏れのあるコードを提示していることです。 これを読んだ PHP 初心者が htmlspecialchars に第二引数、第三引数
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
(Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
(Last Updated On: 2014年12月5日)LAMPセキュリティを強化する4つの方法 http://enterprisezine.jp/article/detail/311 書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。 # 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。 実行できる最も重要な対策は、PHPを使わないことです。腐った果物を導入する前に、以下に目を通してください。 後にPerl/Ruby/Pythonの方がかなり安全である旨の記述があります。メモリ管理が必要ない同じスクリプティング言語のレベルで「Perl/Ruby/Pythonを使えばセキュアなアプリケーションができる」と考
LAMPセキュリティを強化する4つの方法：CodeZine
はじめに Apache HTTPサーバーのセキュリティは、少なくともLinuxやその他の適切なUnix系オペレーティングシステムで実行している限りにおいては、信頼できます。しかし、今や平凡な静的な読み取り専用Webサイトは絶滅危惧種となりました。最近では、LAMPと呼ばれる一連の技術（つまりLinux、Apache/Lighttpd、MySQL/PostgreSQL/SQLite、Python/PHP/Perl/Ruby）を使って動的Webサイトを提供するのが一般的になっています。これは進歩であるとも、ないとも言えます。 私個人は、平凡な静的HTMLの日々が好きでした。今と比べてブラウザのHTMLサポートやサイトの質に疑問が多かったとはいえ、少なくとも、エラーを吐き散らす役立たずの巨大なスクリプトを実行して私のコンピュータを過労に追い込んだり、ときには完全に固まらせてしまうことはありません
コメント: PHPは駄目な言語なのか? - スラッシュドット・ジャパン
趣味でやっている人のことは、まあ、いいとして（踏み台にされる可能性はあるけど）、仕事でPHPを使うときの注意を書いておこう。 コーディング規約を守る。組織にコーディング規約がないなら、Zend Framework PHP標準コーディング規約 [zend.com]を使う。オレ流コーディングスタイルは禁止。 内部コードにはEUC-JPかUTF-8を使う。入出力もできるだけShift JISを避ける。Shift JISを使う場合には2byte目に0x5Cを含む文字の動作を忘れずに確認する。 開発環境の警告レベルをE_STRICTにする。本番環境ではdisplay_errorsをオフにする。 register_globals、magic_quotesはオフにする。 type hintingを積極的に使う。 スコープの長い配列をクラスでラップする。 プレゼンテーションとロジックを分割すること。プレゼ
我々は公共性の進化に見あった速度で進化しているか - アンカテ
Attacking PHP - Matzにっき(2008-01-26) まつもとさんのこのエントリから凄い騒ぎになっているようだけど、ここで一番重要なことは、PHPやRubyがどうのこうのでなくて Webアプリケーションをなめるな こっちの方だと思う。 「初心者にやさしい言語(技術、方法論)の開発」→「本質的な問題の隠蔽と関係者の人口増加の同時進行」→「問題の拡散」というパターンはこれまで何度も繰り返されてきたことだ。 たとえば、VisualBasicやAccessやExcelのユーザが増えはじめた時は、「DBをなめるな」と私は思った。データベースというものは、しっかり業務分析をした上で、論理設計と物理設計をきちんとしないと、最後には破綻する。イージーなツールにも使い道はあるけど、明かに想定を超えた使い方で業務ソフトを作ってしまい、つぎはぎだらけになって収拾がつかなくなる例を何度も見てきた
だからもう初心者にWeb開発させるのやめようぜ - novtan別館
まつもとゆきひろ氏が英語の記事でPHPを叩いてるやつを翻訳してコメント付きで載せたら「Matz酷すぎ」みたいな反応がわらわら出てきてお前らちゃんと読んでいるのかよ、と思ったわけです。 特に「PHPは初心者に学びやすい(と言われていることが問題である)」という部分に共感する。 PHPは初心者に簡単かもしれないが、初心者による手を抜いたWebアプリケーションは PHPが作られた当初はともかく、現代では害悪ではないだろうか。 http://www.rubyist.net/~matz/20080126.html#p04 これは同感。というか、もはや社会インフラと化したWebの世界は初心者の手に負えるものではないはずだ。かつてPerl4でベタベタCGIを書いていた頃は想像もしなかったセキュリティーの脆弱性。未だに過去の遺産として残っているものは多い。 どの言語でもそうだけど、初心者向けの入門書にセキ
ITmedia エンタープライズ：「Zend Framework」で加速するPHP開発 最終回：「ソースは明かせない……」――ソースコードをバイナリ／難読／暗号化する (1/2)
最終回：「ソースは明かせない……」――ソースコードをバイナリ／難読／暗号化する：「Zend Framework」で加速するPHP開発（1/2 ページ） PHPはスクリプト言語であるため、PHPでアプリケーションを作成して配布すると、ソースコードが読める状態になってしまいます。今回は、PHPのソースコードをバイナリ／難読／暗号化する「Zend Guard」を紹介します。 PHPはスクリプト言語であるため、PHPでアプリケーションを作成して配布すると、「オープンソースとして公開する／しない」という意図にかかわらず、ソースコードが読める状態になってしまいます。しかし、商用製品などでは、クライアントにソースコードを公開したくない場合もあるでしょう。今回は、PHPのソースコードをバイナリ／難読／暗号化する「Zend Guard」を紹介します。 Zend Guardの機能 Zend Guardは、PH
第10回 スクリプトインジェクションが無くならない10の理由 | gihyo.jp
SQLインジェクション対策は非常に簡単です。しかしブラウザに対する「スクリプトインジェクション」はなかなか無くなりません。スクリプトインジェクションが無くならない10の理由をあげてみます。 複雑な攻撃経路と対策 前回紹介したように、ブラウザに対するスクリプトインジェクション攻撃の経路は3種類あります。エスケープ方法も数種類あります。すべての出力を完全にエスケープできればセキュリティ維持も容易になりますが、タグや属性を出力したい場合もあるため、必ずしもすべての出力をエスケープできるわけではありません。さらに攻撃手法にも、サイトをまたがった攻撃、直接攻撃、間接攻撃などパターンがあります。エスケープできないデータへの不正なスクリプトの挿入を防ぐには、データの起源までさかのぼり安全性を確保しなければなりません。ブラウザに対するスクリプトインジェクション対策はデータベースサーバへのSQLインジェクシ
SRA OSS，2007年末でサポートが終わるPHP4に対する保守サービスを開始
写真 セキュリティ保守サービスの詳細な内容を紹介するWebページ。URLは，<a href="http://www.sraoss.co.jp/prod_serv/support/php4-security.php" target="_blank">http://www.sraoss.co.jp/prod_serv/support/php4-security.php</a>。 SRA OSSは2007年11月6日，オープンソースのスクリプト言語「PHP」のバージョン4に対するセキュリティ保守サービスを同年12月1日から開始すると発表した。 PHPは，2004年7月にバージョン5にアップデートされている。しかし，現在でもバージョン4のまま運用されているシステムが多い。ところが，PHPを開発するPHP development teamは2007年7月13日，サポートを年内で終了すると表明していた
ふつうのリロード対策
一般的な登録フォームの画面遷移は、 入力画面→入力確認画面→完了画面 であるかもしれないけど処理の流れとしては、 入力画面表示処理→入力確認画面表示処理→登録(メール送信)処理→完了画面表示処理 になる。 処理を分けることにより、完了画面でリロードされても、二度も登録処理が行われることはない。 個人的には、完了画面で登録(メール送信)処理を行うのは、あまり好きではない。 登録(メール送信)処理と完了画面表示処理を同一処理上で行おうとすると、面倒なリロード対策を行わなくてはいけない。 それで件のページの内容に行き着く。 すごいリロード対策 件のページの内容が『すごい』というのはCSRF(クロスサイトリクエストフォージェリ)対策を同時に行っている点でしょう。 CSRFは、通常のフローを通らずに登録処理だけを行おうとする攻撃である。コメントスパムなんかがよい例。 CSRF対策としては、『リファラ
58. すごいリロード対策
まず、日本のサイトにある一般的な登録フォームの画面遷移は 入力画面→入力確認画面→完了画面 となっている場合が多いようです。ここでリロード問題となるのは完了画面でのDBへのINSERT処理やCSV書き出し処理、メール送信処理など「一度しか行わない処理」です。例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプトで制御します。 まずは確認画面のスクリプト 確認画面でチケットを発行し、セッションに保存しておきます。同時に完了画面へチケットがPOSTされるよう、hiddenにセット。こうして完了画面へ遷移させます。それでは完了画面のスクリプトを見てみましょう。 このように、確認画面で発行されたチケットは一度使い切ってしまえば2度処理さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2008/04/25/20080424firewallscript-provides-php-based-protection/
Psyrens.com
teacup. byGMO サービス終了のお知らせ｜GMO MEDIA
PHPでシステム開発する際のセキュリティ関係や負荷分散に関する技術的な手法、傾向、等が掲載されているサイトを探しています。…