PHP カンファレンス 2021 10月2日(土) 15:40〜 Track2 でお話ししたスライドです https://fortee.jp/phpcon-2021/proposal/a795874d-9f0d-48a7-924f-a386bd1cea02 少しずつ加筆修正するかもしれません …
2. 徳丸浩の自己紹介 • 経歴 – 1985年京セラ株式会社入社 – 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – HASHコンサルティング株式会社代表http://www.hash-c.co.jp/ – 独立行政法人情報処理推進機構非常勤研究員http://www.ipa.go.
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
PHP Advent Calendar 2013 in Adventarの15日目です。 みなさん、史上空前のSQLのエスケープブームの中、いかがお過ごしでしょうか? なお、「我が社のプリペアドステートメントは大丈夫なのか?」という疑問をお持ちの方には、以下の記事をお薦めします。 漢(オトコ)のコンピュータ道: SQLインジェクション対策に正解はない さて、あまりにエスケープが人気なので、プリペアドステートメントにもう少しがんばってもらいたい気がしました。そこで、今日は、以下の徳丸さんの大変に力作な記事に関連した、PDOでのプリペアドステートメントについての記事を書いてみたいと思います。 PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた | 徳丸浩の日記 一応、今でこそPDOは普通に使われていますが、細かい点までみていくと、仕様なのかバグなのか、あるいはこ
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
※Ver1.2の情報なので最新バージョンと合わない部分があるかもしれません... タイトルそのまま。FuelPHP1.2のクエリビルダ関連を表にまとめました。 SELECT // SELECT * FROM... \DB::select() // SELECT `hoge`, `fuga` FROM... \DB::select(column1, column2...) \DB::select_array(array(column1, column2...)) // SELECT `hoge` AS `h`, `fuga` AS `f` FROM... \DB::select(array(column1, alias), array(column2, alias)...) \DB::select_array(array(column1, alias), array(column2, ali
この記事はPHP Advent Calendar 2012の20日目です。昨日はTakayuki Miwaさんの「ComposerとHerokuではじめる!PHPクラウド生活」でした。 以前、「『よくわかるPHPの教科書』のSQLインジェクション脆弱性」というタイトルで、同書のSQLインジェクション脆弱性について説明しましたが、SQLインジェクション脆弱性のあるSQL文がDELETE FROMだったので、先のエントリでは、脆弱性の悪用方法としてはデータ(ミニブログの記事)の削除を説明しました。簡単に「全ての記事を削除できる」ので重大な脆弱性ではありますが、個人情報などが漏洩する例ではありませんでした。 このエントリでは、ブラインドSQLインジェクションという技法により、DELETE FROM文の脆弱性から、個人情報を得る手法を説明します。 脆弱性のおさらい ここで、脆弱性のおさらいをしまし
以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは? と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ?と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ
JWordを支えるエンジニアたちによるブログ※記載されている情報は、全て執筆者個人の経験と環境に基づくものであり、その内容を弊社として保証するものではございません。 技術情報の適用については、各自の責任において行ってください。 今回は、CodeIgniterでのメモリ開放のテクニックについて語りたいと思います。 我がチームでは大量のデータ(1万件以上)を頻繁に取り扱うことが多いのですが これら大量データについて処理を施す際、よくメモリサイズオーバーとなることが ありました。 以下のようなPHPエラーですね。 PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 565468 bytes) in /var/www/html/xxxxx/test.php on line
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く