PHPにないセキュリティ機能
PHPカンファレンス関西2015での私のセッション「PHPに無いセキュリティ機能」のスライドです。 何が無いのか、知っていれば対応できます。 何が問題になっているのか、知っていれば対応できます。 セキュリティ対策は職人技敵（脆弱性対策をコード中に散りばめ、全体を把握しないと安全にできない作り方）ではなく、CERT/SANS/OWASPが推奨するセキュリティ対策を行い、エンジニアリング的（科学的、体系的な作り方）を行う方が簡単かつより安全、高品質なアプリケーションを作れます。 PDFをダウンロードしたい方はブログをご覧ください。 http://blog.ohgaki.net/missing-security-related-parts-of-phpRead less
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
アクセス規制を突破するプロクシ「glype proxy」+「Proxilla」 :教えて君.net
プロクシの用途はいくつかあるが、「アクセス規制されているサイトへアクセスしたい」という目的なら、最強の使い勝手と言えるのが、ウェブプロクシシステム「glype proxy」と、それをFirefoxで快適に利用するためのアドオン「Proxilla」だ。 アクセス規制を突破する目的であれば、現実的な解決策としてあり得るのは、一部のウェブプロクシ。具体的に言うと、アクセスしたいウェブページのアドレスを暗号化してくれるウェブプロクシだ。……「ウェブプロクシ」という言葉自体が分からない人向けに書くと、例えば、ページ全体を翻訳する翻訳サービス（例えばこのページ）も、一種の「ウェブプロクシ」だ。直接接続している相手はexciteで、しかし教えて君.netの記事を読める。ただしこの場合、教えて君.netのアドレスがURL内にモロに記載されている。ログを流し見られただけで、「何らかのウェブプロクシで教えて君
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自分でできるWebアプリケーション脆弱性診断 - デブサミ2010
swee.to
PHPでのセキュリティ対策についてのメモ - Liner Note
