PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
![安全なPHPアプリケーションの作り方2013](https://cdn-ak-scissors.b.st-hatena.com/image/square/93f9acb1d37dbdcbf4d680c851a561eaa5c55053/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fphpconf2013-130914044057-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
F's Garage @fshin2000 :magic_quotesを有害認定したのは間違いじゃなかろうか。 magic_quoteがダメなのは、セキュリティ対策として機能が足りないのであって、magic_qouteを使うとセキュリティ意識が思考停止するからと完全否定した結果として、今の状況があるのかもしれない。 ちがうよ。単にmagic_quote=addslashesが使えない関数だからだよ。addslashesはDB用に作ったけど、そんなの各DBの仕様にあわせなきゃダメに決まってるじゃん。使える関数になるわけじゃないじゃん。まぁ、負の遺産。こんなんを自動FILTERでデフォルトONにするPHPがクソと言われれば「はいそうですね」って感じだけど。 それより、自分は セキュリティ対策として機能が足りないのであって に「えぇー!?PHPのmagic_quoteってセキュリティ対策のために
SQLインジェクション対策は非常に簡単です。しかしブラウザに対する「スクリプトインジェクション」はなかなか無くなりません。スクリプトインジェクションが無くならない10の理由をあげてみます。 複雑な攻撃経路と対策 前回紹介したように、ブラウザに対するスクリプトインジェクション攻撃の経路は3種類あります。エスケープ方法も数種類あります。すべての出力を完全にエスケープできればセキュリティ維持も容易になりますが、タグや属性を出力したい場合もあるため、必ずしもすべての出力をエスケープできるわけではありません。さらに攻撃手法にも、サイトをまたがった攻撃、直接攻撃、間接攻撃などパターンがあります。エスケープできないデータへの不正なスクリプトの挿入を防ぐには、データの起源までさかのぼり安全性を確保しなければなりません。ブラウザに対するスクリプトインジェクション対策はデータベースサーバへのSQLインジェクシ
Keitaです。 ディレクトリトラバーサルという言葉があります。 今では、常識になっており、開発するときには無意識に対策する(されている)人がほとんどだと思います。 ただ、DBにデータを格納することが当たり前の昨今ファイルの扱いをちゃんとできない人もたまーにお会いするのでので、個人的にPHPでやっていることを書いておきます。 どんなものか 詳しい定義は各自調べてもらうとして一例を一つ。 次のコードをみてください <?php $file = $_GET['file']; $dir = '/pngdir/'; $filepath .= $dir . $file; if (! file_exists($filepath)) { $filepath = $dir . 'nofile.png'; } header("Content-Type: image/png"); header("C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く