ファイルアップロードの例外処理はこれぐらいしないと気が済まない - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。 脆弱性について 参考リンク PHPにおけるファイルアップロードの脆弱性CVE-2011-2202 PHP 5.4.1リリースのポイント 上記に対する補足説明 PHP 5.4.1以降 PHP 5.3.11以降 どちらかを満たしているならば，脆弱性は（今のところ）無い．どちらも満たしていないと， $_FILES 変数の構造を崩す攻撃 ../ をファイル名に含めて送信する攻撃 (ディレクトリトラバーサル) の何れか，もしくは両方の脆弱性を所持していることになるので要注意． 脆弱性対策と注意事項 $_FILES Corruption 対策 改竄されたフォームからの複数ファイル配列送信対策 脆弱性が修正された環境でも 改竄フォーム対策 も兼ねて
ApacheのAddHandlerはセキュリティ上の懸念から使用すべきではない - このブログはURLが変更になりました
元ネタはこちら。 Apache AddHandler madness all over the place Gentoo Bug 538822 どういうことか 次のような指定は危険である。 AddHandler php5-script .php この時に指定される.phpはファイル名の末尾である必要はない。例えば、 aaa.php.html bbb.php.pngなどもphp5-scriptとして解釈されてしまうのだ。これは.XXX.YYYと複数の拡張子が書かれた場合、.XXXと.YYYもAddHandlerの対象となることが原因。 ちなみに次のような場合にはphp5-scriptとして解釈されない。 ccc.php_foo (.php_fooとして解釈されるため) ddd.php_bar.html (.php_barと.htmlとして解釈されるため)実はこのことはApacheのドキュメン
プラグイン作者必読！実例に学ぶ脆弱なWordPressプラグインの作り方、又はwp-adminを守る理由 | ゆっくりと…
セキュリティ・コンサルティング Sucuri の 2014年11月の記事 によると、WordPress プラグインの3大脆弱性は、SQL インジェクション（SQLi）、クロス・サイト・スクリプティング（XSS）、ファイル・インクルージョン（FI）とのことです。 冒頭のグラフ は最新の分析結果で、この事実を裏付けています。プラグイン開発の チュートリアル や 手引き には、脆弱性を作り込まないためのポイントが上手にまとめられているのに、なぜ無くならないのでしょうか？ 「ヒトが作るものだから、バグがあって当然」と言ってしまえばそれまでですが、 Sucuri のブログ を読み漁っていると、こと脆弱性に関する限り、 WordPress に特有の「思い込み」や「見過ごし」といった、ヒトの心理的・認知的な盲点が原因の多くを占めているんじゃないかと思えてきます。 だから単に PHP のセキュリティ Ho
[PHP] リクエストパラメータ・セッションに関するまとめ - Qiita
予備知識 スーパーグローバル変数とは？ 「スーパーグローバル変数って何？」って感じの駆け出しPHPプログラマのために念のためマニュアルへのリンクを記載しておきます．全然知らない人は軽く読んでおいてください． PHP Manual - 変数のスコープ PHP Manual - スーパーグローバル HTTPとは？ リクエストヘッダー・レスポンスヘッダー と聞いてピンと来ない人はまず下記サイトにて予習をお願いします．細かいことは覚える必要は無いので，大雑把に「ヘッダーとはどんなものか」ということを理解してください． Qiita - 【PHP超入門】HTTP（GET・POST）について Qiita - 【PHP超入門】Cookieとセッションについて @7968さんによるQiitaの記事です．右も左もわからない人はまずこれで． とほほのWWW入門 - HTTP入門 最初の記事をもう少し体系的にまと
![[PHP] リクエストパラメータ・セッションに関するまとめ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9a30d104e80dc55548f1091f2724071ad76ae3fa/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUEhQJTVEJTIwJUUzJTgzJUFBJUUzJTgyJUFGJUUzJTgyJUE4JUUzJTgyJUI5JUUzJTgzJTg4JUUzJTgzJTkxJUUzJTgzJUE5JUUzJTgzJUExJUUzJTgzJUJDJUUzJTgyJUJGJUUzJTgzJUJCJUUzJTgyJUJCJUUzJTgzJTgzJUUzJTgyJUI3JUUzJTgzJUE3JUUzJTgzJUIzJUUzJTgxJUFCJUU5JTk2JUEyJUUzJTgxJTk5JUUzJTgyJThCJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz05YjM2Njc3MWQ1NmZlMWMxMDlmOGI5OGNlYmUyOWMxMQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBtcHl3JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05YWI3NzllNDFiNDU0ODg3NzdmYTFhYmQ2ZDA3MzIzYQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D6ea9450da89142c2c1335e932ac3354d)
$_GET, $_POSTなどを受け取る際の処理 - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。 予備知識 PHPはフォームから送信された値などをコード実行開始に自動的に変数として使えるようにしてくれる非常に便利なプログラミング言語です．しかし，それをそのまま用いるとエラーが発生したり，脆弱性になってしまったりするケースがたくさんあります．使う前には適当なチェック処理が必要です． どういった変数が対象になるか 以下に挙げられた変数は，ユーザーが勝手に値や構造を書き換えたり，送信をそもそも行わずにアクセスしたりすることが可能な信用できない変数だと思ってください．例え，ラジオボタンで選択肢を限定していたり，隠し要素として埋め込んでいたりしたとしても，これに該当してしまいます．
PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能
基礎からのPHPという書籍を読んでおりましたら、SQLインジェクションの攻撃例として、以下のSQL文ができあがる例が紹介されていました。PHP+PDO+MySQLという組み合わせです。 SELECT * FROM tb2 WHERE ban=1;delete from tb2 2つのSQL文がセミコロンで区切って1つにまとめられていますが、これを「複文(multiple statement)」と言います。私は、SQLインジェクション攻撃の文脈で複文が使える組み合わせを調べたことがあり、PHPとMySQLという組み合わせでは、複文は使えないと思っていましたので、この攻撃は成立しないのではないかと思いました。 しかし、決めつけも良くないと思い手元の環境で動かしてみたところ、あっさり動くではありませんか。 PDOを用いてMySQLを呼び出す場合は複文が実行できると気づきましたが、なぜPDOの場合
安全を考えてPHPの実行時設定を調整する
PHPを初期設定のまま使うと、いろいろ問題が起こる可能性があります。今回は、問題の発生を未然に防ぐ設定法をいくつか紹介します。（編集部） 初期設定のままでは良くないところもある ここ数回はPHP実行時の設定について解説しています。実行時設定を変更する方法として、PHPの設定ファイル（以下php.iniファイル）に設定を記述する方法と、Apache HTTP Server（以下Apache）の設定ファイルにPHPの設定を記述する方法の2つがあり、前回はその使い分けについて解説しました。 サーバ全体で標準の設定値としたいものはphp.iniファイルに、バーチャルホストやURLごとに変更したいものはApacheの設定ファイルに記述する、という使い分けの指針も示しました。 今回は、php.iniで設定できる項目、つまりサーバ全体にかかわる設定項目の中でも、初期設定のままにしておくことがあまり適切で
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
書籍「気づけばプロ並みPHP」にリモートスクリプト実行の脆弱性
書籍「気づけばプロ並みPHP」のサンプルスクリプトにリモートスクリプト実行の脆弱性があるので報告します。 はじめに Yahoo!知恵袋の質問を読んでいたら、以下の質問がありました。 気づけばプロ並みPHP （著）谷藤賢一 （発行）リックテレコムP１１２の画像をアップロードする機能でエラーがでます。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11119835496 より引用 質問に対しては回答が既についてクローズされていましたが、引用されているソースを見て任意のファイルを任意のファイル名で、Web公開ディレクトリにアップロードできることに気づきました（下記）。 <?php // 略 $pro_gazou=$_FILES['gazou']; // 略 if($pro_gazou['size']>0) { if ($pro_
register_globals = On の恐怖 - PHP Note
PHP 4.2.0 (2003/05) から、register_globals の初期値が Off に変更されました。これによりこれまで稼動していたスクリプトや書籍に記載されているサンプルコードが動かないといった現象に戸惑った方もいらっしゃるかと思います。 セキュリティ上の理由で変更されたのですが、入門者や初心者にとっては PHP の都合に振り回されているように感じるばかりです。いくらかでもこの初期値の変更を理解していただきたいと思い、register_globals = On で何が危険なのか、どうすれば安全なコードを書くことが出来るか考えてみました。 上書きによる改ざん register_globals = On の場合、環境変数や GET、POST などの PHP の外部からくる値は全て $変数名 という書式で使用することが出来ます。 では、同じ変数名が存在した場合はどうなるのでしょ
PHP文字列のエスケープ
(Last Updated On: 2021年5月9日) PHP文字列をテキストとして出力したい場合もあります。PHPの文字列型はバイナリセーフなのでどのようなデータでも保存可能ですが、プログラム中でPHP変数をPHPのテキスト（リテラル）として出力するにはaddslashes()によるエスケープ処理が必要です。 【重要】エスケープ／API／バリデーション1は出力先に合った方法でないと意味がないです。一口にHTMLと言っても複数の”コンテクスト”があります。 JavaScript（識別子、変数など）、CSS、タグ属性名、タグ属性値（URIコンテクストに特に注意。BASE64、JavaScriptを使う場合もある） があります。 SQLクエリと言っても 引数（更にLIKE、正規表現、JSON、XMLなどに別れる）、識別子、SQL語句 などがあります。全てのテキストインターフェースにコンテクス
13. $_SERVER['PHP_SELF']とXSS脆弱性
皆さんは同じスクリプトへのリンクを貼る時、どの様に記述していますか？ $_SERVER['PHP_SELF']を用いることがあるのではないでしょうか。これを直接用 いることは危険です。なぜならば、$_SERVER['PHP_SELF']にはクロスサイト・ス クリプティング（XSS）脆弱性が存在するからです。 $_SERVER['PHP_SELF']はしばしば次のように使われます。 <form method="post" action="<?php echo $_SERVER['PHP_SELF'] ?>"> このページ（ここではhttp:/www.example.jp/example.php）へ下記の様にリンク を貼り、クリックしてみて下さい。 <a href="http://www.example.jp/ example.php/%22%3E%3Cscript%3Ealert(%27XS
![13. $_SERVER['PHP_SELF']とXSS脆弱性](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
![[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ](https://cdn-ak-scissors.b.st-hatena.com/image/square/abd76f3bb0ec0750428a791cbfbf7959c317f97d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127052840568%2F17680117127052842215%2F1555633900)
第40回 MOPS：安全性の高いパスワードハッシュ作成ツール - phpass | gihyo.jp
第32回 PHPセキュリティ月間（Month of PHP Sercurity）で「PHPセキュリティ月間」（MOPS - Month of PHP Security）について簡単に紹介しました。 今回はパスワードを安全に保存するツールの紹介です。今まで数回に渡ってMOPSの成果の一部を紹介してきましたが、今回で最後です。 MOPS Submission 10: How to manage a PHP application’s users and passwords http://www.php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/index.html この論文は1位を取得した論文です。Drupal 7でこのライブラリが利用されてい
PHP と Web アプリケーションのセキュリティについてのメモ
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
$_SERVER['PHP_SELF']は危険？ - [PHP + PHP] ぺんたん info
PHPで自ページから自ページへ遷移する動作をさせるとき、AタグやFORMタグに$_SERVER['PHP_SELF']を使う方法があります。 Aタグに使う場合 <a href="<?php echo $_SERVER['PHP_SELF']; ?>"> FORMタグに使う場合 <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>"> しかしこのような目的で$_SERVER['PHP_SELF']を使うときには気をつけたほうがいいです。 XSS(クロスサイトスクリプティング)というセキュリティーホールになります。 CakePHPやZend Frameworkなどmod_rewriteを使っているときです。 例えば次のようなURL http://example.com/hoge.php/"><script>alert('
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
れいさの本当に目が覚めるPHP - Togetterまとめ
IBM Developer
PHPでのセキュリティ対策についてのメモ - Liner Note