Enviar pesquisa
Carregar
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
•
74 gostaram
•
14,616 visualizações
Hiroshi Tokumaru
Seguir
Tecnologia
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 99
Recomendados
phpMyAdminにおけるスクリプト実行可能な脆弱性3種盛り合わせ
phpMyAdminにおけるスクリプト実行可能な脆弱性3種盛り合わせ
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2013
安全なPHPアプリケーションの作り方2013
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014
Hiroshi Tokumaru
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
Hiroshi Tokumaru
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
Hiroshi Tokumaru
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
Hiroshi Tokumaru
徳丸本ができるまで
徳丸本ができるまで
Hiroshi Tokumaru
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
Hiroshi Tokumaru
Recomendados
phpMyAdminにおけるスクリプト実行可能な脆弱性3種盛り合わせ
phpMyAdminにおけるスクリプト実行可能な脆弱性3種盛り合わせ
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2013
安全なPHPアプリケーションの作り方2013
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014
Hiroshi Tokumaru
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
Hiroshi Tokumaru
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
Hiroshi Tokumaru
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
Hiroshi Tokumaru
徳丸本ができるまで
徳丸本ができるまで
Hiroshi Tokumaru
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
Hiroshi Tokumaru
Webアプリでパスワード保護はどこまでやればいいか
Webアプリでパスワード保護はどこまでやればいいか
Hiroshi Tokumaru
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
Hiroshi Tokumaru
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
Hiroshi Tokumaru
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?
Hiroshi Tokumaru
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
Hiroshi Tokumaru
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Hiroshi Tokumaru
PHPカンファレンス2014セキュリティ対談資料
PHPカンファレンス2014セキュリティ対談資料
Yasuo Ohgaki
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
Hiroshi Tokumaru
HTML5のセキュリティ もうちょい詳しく- HTML5セキュリティその3 : JavaScript API
HTML5のセキュリティ もうちょい詳しく- HTML5セキュリティその3 : JavaScript API
Yosuke HASEGAWA
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
Hiroshi Tokumaru
Phpcon2015
Phpcon2015
Hiroshi Tokumaru
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
zaki4649
他人事ではないWebセキュリティ
他人事ではないWebセキュリティ
Yosuke HASEGAWA
いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方
Hiroshi Tokumaru
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016
Hiroshi Tokumaru
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
Hiroshi Tokumaru
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
Hiroshi Tokumaru
[デブサミ2012]趣味と実益の脆弱性発見
[デブサミ2012]趣味と実益の脆弱性発見
Yosuke HASEGAWA
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
Hiroshi Tokumaru
Pentest Apocalypse
Pentest Apocalypse
Beau Bullock
Mais conteúdo relacionado
Mais procurados
Webアプリでパスワード保護はどこまでやればいいか
Webアプリでパスワード保護はどこまでやればいいか
Hiroshi Tokumaru
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
Hiroshi Tokumaru
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
Hiroshi Tokumaru
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?
Hiroshi Tokumaru
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
Hiroshi Tokumaru
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Hiroshi Tokumaru
PHPカンファレンス2014セキュリティ対談資料
PHPカンファレンス2014セキュリティ対談資料
Yasuo Ohgaki
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
Hiroshi Tokumaru
HTML5のセキュリティ もうちょい詳しく- HTML5セキュリティその3 : JavaScript API
HTML5のセキュリティ もうちょい詳しく- HTML5セキュリティその3 : JavaScript API
Yosuke HASEGAWA
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
Hiroshi Tokumaru
Phpcon2015
Phpcon2015
Hiroshi Tokumaru
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
zaki4649
他人事ではないWebセキュリティ
他人事ではないWebセキュリティ
Yosuke HASEGAWA
いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方
Hiroshi Tokumaru
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016
Hiroshi Tokumaru
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
Hiroshi Tokumaru
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
Hiroshi Tokumaru
[デブサミ2012]趣味と実益の脆弱性発見
[デブサミ2012]趣味と実益の脆弱性発見
Yosuke HASEGAWA
Mais procurados
(20)
Webアプリでパスワード保護はどこまでやればいいか
Webアプリでパスワード保護はどこまでやればいいか
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
PHPカンファレンス2014セキュリティ対談資料
PHPカンファレンス2014セキュリティ対談資料
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
HTML5のセキュリティ もうちょい詳しく- HTML5セキュリティその3 : JavaScript API
HTML5のセキュリティ もうちょい詳しく- HTML5セキュリティその3 : JavaScript API
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
Phpcon2015
Phpcon2015
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
他人事ではないWebセキュリティ
他人事ではないWebセキュリティ
いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
[デブサミ2012]趣味と実益の脆弱性発見
[デブサミ2012]趣味と実益の脆弱性発見
Destaque
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
Hiroshi Tokumaru
Pentest Apocalypse
Pentest Apocalypse
Beau Bullock
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
CODE BLUE
120225 bootstrap
120225 bootstrap
TechGardenSchool
WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱
WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱
Hiroshi Tokumaru
ガラケーで楽しむオレJSの勧め
ガラケーで楽しむオレJSの勧め
Hiroshi Tokumaru
UnicodeによるXSSとSQLインジェクションの可能性
UnicodeによるXSSとSQLインジェクションの可能性
Hiroshi Tokumaru
文字コードに起因する脆弱性とその対策
文字コードに起因する脆弱性とその対策
Hiroshi Tokumaru
ログイン前セッションフィクセイション攻撃の脅威と対策
ログイン前セッションフィクセイション攻撃の脅威と対策
Hiroshi Tokumaru
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
Hiroshi Tokumaru
XSS再入門
XSS再入門
Hiroshi Tokumaru
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
Hiroshi Tokumaru
Destaque
(12)
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
Pentest Apocalypse
Pentest Apocalypse
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
120225 bootstrap
120225 bootstrap
WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱
WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱
ガラケーで楽しむオレJSの勧め
ガラケーで楽しむオレJSの勧め
UnicodeによるXSSとSQLインジェクションの可能性
UnicodeによるXSSとSQLインジェクションの可能性
文字コードに起因する脆弱性とその対策
文字コードに起因する脆弱性とその対策
ログイン前セッションフィクセイション攻撃の脅威と対策
ログイン前セッションフィクセイション攻撃の脅威と対策
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
XSS再入門
XSS再入門
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
Semelhante a 徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
クロスサイトリクエストフォージェリ(CSRF)とその対策
クロスサイトリクエストフォージェリ(CSRF)とその対策
JPCERT Coordination Center
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
Sen Ueno
Osc2017 tokyo spring_soss_sig
Osc2017 tokyo spring_soss_sig
Kazuki Omo
Java/Androidセキュアコーディング
Java/Androidセキュアコーディング
Masaki Kubo
Spacewalkにおけるクロスサイト リクエストフォージェリ(CSRF)の脆弱性
Spacewalkにおけるクロスサイト リクエストフォージェリ(CSRF)の脆弱性
JPCERT Coordination Center
Osc2018 tokyo spring_scap
Osc2018 tokyo spring_scap
Kazuki Omo
Webシステム脆弱性LT資料
Webシステム脆弱性LT資料
Tomohito Adachi
NGINX Ingress Controllerで実現するセキュリティ.pdf
NGINX Ingress Controllerで実現するセキュリティ.pdf
FumieNakayama
第一回 社内勉強会 PHP Application Security Checklist に学ぶ PHP セキュリティ (Excerpt)
第一回 社内勉強会 PHP Application Security Checklist に学ぶ PHP セキュリティ (Excerpt)
Yuya Takeyama
レガシーなWebアプリケーションと向き合う
レガシーなWebアプリケーションと向き合う
Yuta Ohashi
『PHP逆引きレシピ』とセキュリティのこと
『PHP逆引きレシピ』とセキュリティのこと
kenjis
Security Learning Vol2 話題の脆弱性をコードで紐解く!
Security Learning Vol2 話題の脆弱性をコードで紐解く!
YOJI WATANABE
Cve 2013-0422
Cve 2013-0422
abend_cve_9999_0001
クラウドセキュリティ基礎 #seccamp
クラウドセキュリティ基礎 #seccamp
Masahiro NAKAYAMA
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
Hiroh Satoh
NSDI2015読み会 Correctness セッション
NSDI2015読み会 Correctness セッション
Daisuke Kotani
[SC09] パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例
[SC09] パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例
de:code 2017
Web applicationpenetrationtest その5
Web applicationpenetrationtest その5
Tetsuya Hasegawa
WTM53 phpフレームワーク いまさらcodeigniter
WTM53 phpフレームワーク いまさらcodeigniter
Masanori Oobayashi
C#の書き方
C#の書き方
信之 岩永
Semelhante a 徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
(20)
クロスサイトリクエストフォージェリ(CSRF)とその対策
クロスサイトリクエストフォージェリ(CSRF)とその対策
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
Osc2017 tokyo spring_soss_sig
Osc2017 tokyo spring_soss_sig
Java/Androidセキュアコーディング
Java/Androidセキュアコーディング
Spacewalkにおけるクロスサイト リクエストフォージェリ(CSRF)の脆弱性
Spacewalkにおけるクロスサイト リクエストフォージェリ(CSRF)の脆弱性
Osc2018 tokyo spring_scap
Osc2018 tokyo spring_scap
Webシステム脆弱性LT資料
Webシステム脆弱性LT資料
NGINX Ingress Controllerで実現するセキュリティ.pdf
NGINX Ingress Controllerで実現するセキュリティ.pdf
第一回 社内勉強会 PHP Application Security Checklist に学ぶ PHP セキュリティ (Excerpt)
第一回 社内勉強会 PHP Application Security Checklist に学ぶ PHP セキュリティ (Excerpt)
レガシーなWebアプリケーションと向き合う
レガシーなWebアプリケーションと向き合う
『PHP逆引きレシピ』とセキュリティのこと
『PHP逆引きレシピ』とセキュリティのこと
Security Learning Vol2 話題の脆弱性をコードで紐解く!
Security Learning Vol2 話題の脆弱性をコードで紐解く!
Cve 2013-0422
Cve 2013-0422
クラウドセキュリティ基礎 #seccamp
クラウドセキュリティ基礎 #seccamp
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
NSDI2015読み会 Correctness セッション
NSDI2015読み会 Correctness セッション
[SC09] パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例
[SC09] パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例
Web applicationpenetrationtest その5
Web applicationpenetrationtest その5
WTM53 phpフレームワーク いまさらcodeigniter
WTM53 phpフレームワーク いまさらcodeigniter
C#の書き方
C#の書き方
Mais de Hiroshi Tokumaru
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
Hiroshi Tokumaru
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
Hiroshi Tokumaru
SQLインジェクション再考
SQLインジェクション再考
Hiroshi Tokumaru
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
Hiroshi Tokumaru
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
Hiroshi Tokumaru
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
Hiroshi Tokumaru
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
Hiroshi Tokumaru
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
Hiroshi Tokumaru
秀スクリプトの話
秀スクリプトの話
Hiroshi Tokumaru
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
Hiroshi Tokumaru
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
Hiroshi Tokumaru
ウェブセキュリティの常識
ウェブセキュリティの常識
Hiroshi Tokumaru
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
Hiroshi Tokumaru
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
Hiroshi Tokumaru
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かり
Hiroshi Tokumaru
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
Hiroshi Tokumaru
Mais de Hiroshi Tokumaru
(17)
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
SQLインジェクション再考
SQLインジェクション再考
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
秀スクリプトの話
秀スクリプトの話
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
ウェブセキュリティの常識
ウェブセキュリティの常識
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かり
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
Último
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
Hiroki Ichikura
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
Toru Tamaki
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Yuma Ohgami
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
Toru Tamaki
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
iPride Co., Ltd.
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
taisei2219
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
Toru Tamaki
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
sugiuralab
Último
(9)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
1.
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
2012年9月15日 徳丸 浩
2.
本日お話しする内容 • 鉄則1: PHP自体の脆弱性対処をしよう •
鉄則2: Ajaxの脆弱性対処をしよう • 鉄則3: 競合条件の脆弱性対処をしよう • 鉄則4: htmlspecialcharsの使い方2012 • 鉄則5: escapashellcmdは使わないこと • 鉄則6: SQLインジェクションの対処 • 鉄則7: クロスサイト・スクリプティングの対処 • 鉄則8: クロスサイト・リクエスト・フォージェリの対処 • 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト レッチングも • 鉄則10: 他にもたくさんある脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 2
3.
徳丸浩の自己紹介 • 経歴
– 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかることも • 現在 – HASHコンサルティング株式会社 代表 http://www.hash-c.co.jp/ – 京セラコミュニケーションシステム株式会社 技術顧問 http://www.kccs.co.jp/security/ – 独立行政法人情報処理推進機構 非常勤研究員 http://www.ipa.go.jp/security/ Copyright © 2012 HASH Consulting Corp. 3
4.
鉄則1: PHP自体の脆弱性対処をしよう
Copyright © 2012 HASH Consulting Corp. 4
5.
PHPの脆弱性ってどれくらい危険なの?
Copyright © 2012 HASH Consulting Corp. 5
6.
JVN iPediaで検索してみよう http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja
6
7.
2011年5月以降のPHP高危険度脆弱性
JVN iPediaより引用 7
8.
#1 JVNDB-2011-002207(CVE-2011-1938) PHP の
socket_connect 関数におけるスタックベースのバッファオーバーフローの脆弱性 概要 PHP の ext/sockets/sockets.c 内にある socket_connect 関数には、スタックベースのバッファ オーバーフローの脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的 影響を受けるシステム PHP 5.3.3 から 5.3.6 通常あり得ない想定 想定される影響 攻撃者により、UNIX ソケットの過度に長いパス名を介して、任意のコードを実行される可能性 があります。 8
9.
#2 JVNDB-2011-002218(CVE-2011-3268) PHP の
crypt 関数におけるバッファオーバーフローの脆弱性 概要 PHP の crypt 関数には、バッファオーバーフローの脆弱性が存在します。 本脆弱性は、CVE-2011-2483 とは異なる脆弱性です。 CVSS による深刻度 (CVSS とは?) 基本値: 10.0 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 全面的 完全性への影響(I): 全面的 可用性への影響(A): 全面的 影響を受けるシステム PHP 5.3.7 未満 通常あり得ない想定 想定される影響 攻撃者により、過度に長い salt 引数を介して、詳細不明な影響を受ける可能性があります。 9
10.
#3 JVNDB-2011-002770(CVE-2011-3379) PHP の
is_a 関数における任意のコードを実行される脆弱性 概要 PHP の is_a 関数は、__autoload 関数の呼び出しを誘発するため、任意のコードを実行される 脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的 影響を受けるシステム PHP 5.3.7 PHP 5.3.8 ???? 想定される影響 第三者により、巧妙に細工された URL、および特定の PEAR パッケージおよびカスタムオート ローダの安全でない動作を利用されることで、任意のコードを実行される可能性があります。 10
11.
CVE-2011-3379入門 • 以下のソースの結果わかりますか? (PHP5.3.7~5.3.8)
function __autoload($class_name) { echo "autoload $class_name¥n"; } class Class1 { } $a = new Class1(); var_dump(is_a($a, "Class1")); var_dump(is_a("test", "Class1")); • 結果は以下の通り bool(true) autoload test bool(false) Copyright © 2012 HASH Consulting Corp. 11
12.
CVE-2011-3379のPoC • 以下は脆弱なソース
// /var/data にユーザアップロードファイルが格納される想定 <?php require_once 'File.php'; function __autoload($class_name) { include $class_name . '.php'; } $uploaded_filename = '/var/data/test.dat'; $uploaded_file = File::readAll($uploaded_filename); if (PEAR::isError($uploaded_file)){ echo "error : $uploaded_file¥n"; }else{ echo "success : $uploaded_file¥n"; } • /var/data/test.dat の内容 /var/data/test2 • /var/data/test2.php がインクルードされる Copyright © 2012 HASH Consulting Corp. 12
13.
CVE-2011-3379の影響を受ける条件(AND条件) • __autoload関数によりクラスの自動ロード機能が定義されて
いる • 直接・間接に、is_a関数に「攻撃者の入力した文字列」を渡 すことができる(PEARのFileクラスなど) • 以下のいずれかにより任意スクリプトを指定できること – アップロード機能などにより、サーバー上にPHPファイルを書き込み、 そのファイル名が推測できる – allow_url_includeが有効になっている • 影響を受ける環境はまれと推測される Copyright © 2012 HASH Consulting Corp. 13
14.
#4 JVNDB-2012-001323(CVE-2012-0830) PHP の
php_variables.c 内の php_register_variable_ex 関数における任意のコードを実行され る脆弱性 概要 PHP の php_variables.c 内の php_register_variable_ex 関数には、任意のコードを実行され る脆弱性が存在します。 本脆弱性は CVE-2011-4885 に対する修正が不十分だったことによる脆弱性です。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的 影響を受けるシステム PHP 5.3.9 想定される影響 第三者により、大量の変数を含むリクエストを介して、任意のコードを実行される可能性がありま す。 14
15.
#番外 JVNDB-2011-003565(CVE-2011-4885) PHP におけるサービス運用妨害
(CPU 資源の消費) の脆弱性(hashdos) 概要 PHP は、ハッシュ衝突を想定した制限を行わずにフォームパラメータのハッシュ値を算出するた め、サービス運用妨害 (CPU 資源の消費) 状態となる脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 5.0 (警告) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): なし 完全性への影響(I): なし 可用性への影響(A): 部分的 影響を受けるシステム PHP 5.3.9 未満 想定される影響 第三者により、巧妙に細工されたパラメータを大量に送信されることで、サービス運用妨害 (CPU 資源の消費) 状態にされる可能性があります。 15
16.
http://blog.tokumaru.org/2011/12/webdoshashdos.html
Copyright © 2012 HASH Consulting Corp. 16
17.
#5 JVNDB-2011-001388(CVE-2012-0831) PHP における
SQL インジェクション攻撃を行われる脆弱性 概要 PHP は、環境変数のインポート中の magic_quotes_gpc ディレクティブへの一時的変更を適切 に処理しないため、容易に SQL インジェクション攻撃を行われる脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 アプリケーション側 可用性への影響(A): 部分的 でSQLインジェク 影響を受けるシステム ション対策をしてい PHP 5.3.10 未満 れば問題ない 想定される影響 第三者により、main/php_variables.c、sapi/cgi/cgi_main.c、および sapi/fpm/fpm/fpm_main.c に関連する巧妙に細工された要求を介して、容易に SQL インジェ クション攻撃を行われる可能性があります。 17
18.
勝手に訂正: 「PHP における
SQL インジェクション攻 撃を行われる脆弱性 (JVNDB-2012-001388)」 http://co3k.org/blog/25 より引用 18
19.
#6 JVNDB-2012-002235(CVE-2012-1823) PHP-CGI の
query string の処理に脆弱性 概要 PHP には、CGI として使用される設定において query string をコマンドラインオプションとして認識してしま う脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的 影響を受けるシステム PHP version 5.4.2 より前のバージョン PHP version 5.3.12 より前のバージョン PHP の開発者によると、本脆弱性の修正を含む更なるリリースを予定しているとのことです。 そのため、影響を受けるシステムに関する情報が今後変更される可能性があります。 想定される影響 遠隔の第三者によって、php スクリプトの内容を取得されたり、サービス運用妨害 (DoS) 攻撃を受けたり、 ウェブサーバの権限で任意のコードを実行されたりする可能性があります。 19
20.
#7 JVNDB-2012-002392(CVE-2012-2311) PHP の
sapi/cgi/cgi_main.c における任意のコードを実行される脆弱性 概要 PHP の sapi/cgi/cgi_main.c は、CGI スクリプトとして設定される際、%3D 文字列を含み = (等号) 文字を含まないクエリ文字列を適切に処理しないため、任意のコードを実行される脆弱 性が存在します。 本脆弱性は、CVE-2012-1823 に対する修正が不十分だったことによる脆弱性です。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的 影響を受けるシステム PHP 5.4.3 未満の 5.4.x PHP 5.3.13 未満 想定される影響 第三者により、クエリ文字列内にコマンドラインオプションを配置することで、任意のコードを実行 される可能性があります。 20
21.
CVE-2012-2311のPoC
allow_url_include=On auto_prepend_file=php://input <?php readfile(‘/etc/passwd’); ?> Copyright © 2012 HASH Consulting Corp. 21
22.
飽きてきたので、この辺で… Copyright
© 2012 HASH Consulting Corp. 22
23.
とりあえずのまとめ • PHPの高危険度脆弱性は多いが、影響を受ける局面が限ら
れるものが多い • アプリケーションが、当該脆弱性の影響を受けるか、外部か らは判別しにくい • アプリケーションやフレームワークの脆弱性の原因となった 場合、外部からの攻撃が容易となる • IPA、JPCERT/CC、セキュリティ専門家の情報をウォッチし、 「騒ぎ出したら」急いで対処の準備をすること Copyright © 2012 HASH Consulting Corp. 23
24.
脆弱性対処のアプローチ • 正当的な方法 –
脆弱性情報が出る毎に影響を評価し、対処方法を決める – 影響が大きく、回避策がある場合は、まず回避策を適用する – パッチ、PHP新バージョンのアプリケーションに対する影響をテスト する – 本番環境にパッチ適用、バージョンアップ • Linuxディストリビューションのパッチに任せる – 基本的に、ディストリビューションのパッチが出るのを待って適用す る – テスト環境でパッチの影響を調べる (えいやっ! で当ててしまうのもあり) – 高危険度で攻撃が容易、かつパッチが間に合わない脆弱性につい ては、回避策を適用する Copyright © 2012 HASH Consulting Corp. 24
25.
鉄則2: Ajaxの脆弱性対処をしよう
Copyright © 2012 HASH Consulting Corp. 25
26.
とある入門書のサンプル
26 よくわかるJavaScriptの教科書、たにぐちまこと著、2012 P228より引用
27.
この本です
27
28.
動かしてみる
28
29.
結果
29
30.
JSON作成をPHPに 生成されるJSON [{"image":"img¥/1.jpg","image_big":"i mg¥/1_big.jpg","caption":"¥u30ad¥u30e 3¥u30d7¥u30b7¥u30e7¥u30f31"}]
30
31.
結果
31
32.
データにJavaScriptを入れてみる 生成されるJSON [{"image":"img¥/1.jpg","image_big":"i mg¥/1_big.jpg","caption":"¥u30ad¥u30e 3¥u30d7¥u30b7¥u30e7¥u30f31<script>ale rt(1)<¥/script>"}]
32
33.
結果
33
34.
脆弱性の原因と対策 • htmlメソッドによりHTMLテキストを設定しているにも関わら
ず、データをHTMLエスケープしていない • ただし、元文献は固定テキストなので、必ずしも脆弱性とは 言えない • HTMLエスケープするタイミングは、以下の候補がある – ブラウザでレンダリングする箇所 – JSONを組み立てる段階で、あらかじめHTMLエスケープしておく Copyright © 2012 HASH Consulting Corp. 34
35.
次の話題 evalインジェクション Copyright ©
2012 HASH Consulting Corp. 35
36.
JSON解釈をevalでやってみる
36
37.
JSON作成も自前で <?php $image
= 'img/1.jpg'; $image_big = 'img/1_big.jpg'; $caption = 'キャプション2'; $a = '[{"image":"' . $image . '","image_big":"' . $image_big . '","caption":"' . $caption . '"}]'; echo $a; 生成されるJSON [{"image":"img/1.jpg","image_big":"img/1_b ig.jpg","caption":"キャプション2 "}] 37
38.
結果
38
39.
データにJavaScriptを入れてみる <?php $image
= 'img/1.jpg'; $image_big = 'img/1_big.jpg'; $caption = 'キャプション2x"+alert("1")+"'; $a = '[{"image":"' . $image . '","image_big":"' . $image_big . '","caption":"' . $caption . '"}]'; echo $a; 生成されるJSON [{"image":"img/1.jpg","image_big": "img/1_big.jpg","caption": "キャプション2x"+alert("1")+""}] 39
40.
結果
40
41.
脆弱性の原因と対策 • JSON/JavaScriptとしての適切なエスケープを怠っているこ
とが根本原因 • 根本単位策:JSON生成を自前でしないで、信頼できるライブ ラリを用いる • 保険的対策(強く推奨):evalでJSONを解釈しない。 Copyright © 2012 HASH Consulting Corp. 41
42.
次の話題 json.phpを直接ブラウズしてみる
Copyright © 2012 HASH Consulting Corp. 42
43.
データを少しいじりましょう Copyright ©
2012 HASH Consulting Corp. 43
44.
さまざまなブラウザでの結果 Copyright ©
2012 HASH Consulting Corp. 44
45.
で、IE9は? Copyright © 2012
HASH Consulting Corp. 45
46.
大丈夫なのか Copyright © 2012
HASH Consulting Corp. 46
47.
でも、だめ http://example.jp/json.php/a.html
Copyright © 2012 HASH Consulting Corp. 47
48.
Copyright © 2012
HASH Consulting Corp. 48 http://d.hatena.ne.jp/hasegawayosuke/20110106/p1 より引用
49.
Copyright © 2012
HASH Consulting Corp. 49 http://d.hatena.ne.jp/hasegawayosuke/20110106/p1 より引用
50.
X-Content-Type-Options: nosniff を入れてみる
生成されるJSON X-Content-Type-Options: nosniff Content-Length: 125 Content-Type: application/json; charset=utf8 [{"image":"img¥/1.jpg","image_big":"img¥/1_b ig.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥ u30e7¥u30f31<body onload=alert(1)>"}] Copyright © 2012 HASH Consulting Corp. 50
51.
IE9だとOK(IE8以上) Copyright © 2012
HASH Consulting Corp. 51
52.
IE7だとだめ Copyright © 2012
HASH Consulting Corp. 52
53.
53
54.
対策 • 必須対策(全ブラウザ共通)
– レスポンスがブラウザによりtext/htmlと解釈されないようにする X-Content-Type-Options: nosniff Content-Type: application/json; charset=utf8 • IE6,7対策 – IE7以前をサポートしない – ブラウザからの直接リクエストを受け付けない – 「<」、「>」などもエスケープする Copyright © 2012 HASH Consulting Corp. 54
55.
Json_encodeのパラメータを追加 生成されるJSON [{"image":"img¥/1.jpg","image_big":"img¥/1_bi g.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥u3 0e7¥u30f31¥u003Cbody onload=alert(1)¥u003E"}]
Copyright © 2012 HASH Consulting Corp. 55
56.
今度は大丈夫 Copyright © 2012
HASH Consulting Corp. 56
57.
次の話題はJSONハイジャック
Copyright © 2012 HASH Consulting Corp. 57
58.
Firefox3などで発現。現在の主要ブラ
ウザでは対策されている Copyright © 2012 HASH Consulting Corp. 58
59.
JSONハイジャックとは • JSONを罠サイトからscript要素で読み出す • 利用者のブラウザからは、正規のCookieが送信されるので、
認証ずみの状態でJSONが取得できる • なんらかの手法で、このJSONの中味を読むのがJSONハイ ジャック これは罠サイト <script> ここにJSONを読み出す仕掛けを置く // script要素で読み出したJSON [{"name":"Yamada", "mail":"yama@example.jp"}] </script> Copyright © 2012 HASH Consulting Corp. 59
60.
サンプルスクリプト(罠) Copyright © 2012
HASH Consulting Corp. 60
61.
結果 Copyright © 2012
HASH Consulting Corp. 61
62.
Firefox11.0だと問題なし Copyright ©
2012 HASH Consulting Corp. 62
63.
Androidの標準ブラウザでハイジャック成功
Xperia ARC(SO-01C) Android 2.3.4 でキャプチャ Galaxy Nexus Android 4.0.3では取得できず Copyright © 2012 HASH Consulting Corp. 63
64.
対策 • script要素からのリクエストにはレスポンスを返さないように
する – XMLHttpRequestからのリクエストに特別なヘッダを入れておき、 JSON提供側でチェックするなど Jqueryの以下のヘッダを使っても良いかも X-Requested-With: XMLHttpRequest – POSTにのみ応答(個人的には好みません) • JSONデータを、JavaScriptとして実行できない形にする – 1行目に for(;;) ; を置く(個人的には好みません) – JSONデータをJavaScriptとして実行できない形にする(同上) • JSONハイジャック可能なブラウザを使わない(利用者側でと れる対策) Copyright © 2012 HASH Consulting Corp. 64
65.
鉄則3: 競合条件の脆弱性対処をしよう
Copyright © 2012 HASH Consulting Corp. 65
66.
ドリランド カード増殖祭りはこうしておこ った…かも?
Copyright © 2012 HASH Consulting Corp. 66
67.
67 https://help.gree.jp/app/answers/detail/a_id/3231 より引用
68.
こんな感じだった? 必要なもの 携帯もしくはPCを二台 gleeアカウント二つ 二台の機器でそれぞれのgleeアカウントでログインしてドリランド起 動後お互いでトレードさせる トレード(受け取りはしない)が終わったら片方の機器はログアウトし て二つの機器のアカウントを同じにする それぞれトレード品受け取り画面にして受け取るボタン同時押し カード毎にID振って無いのかよ。。。。 馬鹿じゃねぇの? >>277 ちゃんとふってあるけど、トレード時にトレードされる側とする側で ちゃんとアイテムIDが変わる仕様だったw
68 http://jin115.com/archives/51849925.html より引用
69.
こんな感じだった? DBからトレード元のカードのデータを読み取る 新しいIDをつけてトレード先に保存する トレード元のデータを削除する
http://bakera.jp/ebi/topic/4722 より引用 69
70.
作ってみた // トレードするカードのidと新オーナーのidがパラメータ $item_id =
(int)$_GET['item_id']; $newowner = (int)$_GET['newowner']; // カード情報を取得 $stmt = $pdo->query( "SELECT * FROM cards WHERE item_id=$item_id"); $row = $stmt->fetch(PDO::FETCH_ASSOC); $kind = $row['kind']; $owner_id = $row['owner_id']; // トレード後のカードを作成 $stmt = $pdo->exec("INSERT INTO cards VALUES (NULL, $kind,". "$newowner, $item_id, $owner_id, NOW())"); // 元のカードを削除 $stmt = $pdo->exec( "DELETE FROM cards WHERE item_id= $item_id "); ※デモスクリプトはプレースホルダをちゃんと使っています! Copyright © 2012 HASH Consulting Corp. 70
71.
DEMO Copyright © 2012
HASH Consulting Corp. 71
72.
中ではこうなった Copyright © 2012
HASH Consulting Corp. 72
73.
対策 • トランザクションを使う –
PDOの場合は、begeinTransaction ~ commit / rollbackの間 • ロック(排他制御) – SELECT … FOR UPDATE など • 上記の両方が必須 – トランザクションを使うだけでは排他制御にならない場合が多い 厳密にはDB依存 および モードに依存 • 「クリティカルセクション」に注意 – このスクリプトの場合は、SELECT ~ DELETE FROMまではクリテ ィカルセクションであり、同一カードIDについては並行動作してはい けない • ちゃんとRDBを基礎から勉強しよう Copyright © 2012 HASH Consulting Corp. 73
74.
トランザクションと行ロックで対策 try {
$pdo->beginTransaction(); $item_id = (int)$_GET['item_id']; $stmt = $pdo->query( "SELECT * FROM cards WHERE item_id=$item_id FOR UPDATE"); $row = $stmt->fetch(PDO::FETCH_ASSOC); if (! $row) throw new DataNotFoundException(); $kind = $row['kind']; $owner_id = $row['owner_id']; $stmt = $pdo->exec("INSERT INTO cards VALUES (NULL, $kind,". "$newowner, $item_id, $owner_id, NOW())"); $stmt = $pdo->exec( "DELETE FROM cards WHERE item_id=$item_id"); $pdo->commit(); } catch (DataNotFoundException $e) { $pdo->rollback(); } catch (Exception $e) { // …… ※上記は概要でありデモスクリプトはプレースホルダをちゃんと使っています! Copyright © 2012 HASH Consulting Corp. 74
75.
中ではこうなる Copyright © 2012
HASH Consulting Corp. 75
76.
鉄則4: htmlspecialcharsの使い方2012
Copyright © 2012 HASH Consulting Corp. 76
77.
htmlspecialcharsの使い方 • PHPのリファレンスから string htmlspecialchars
( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = ‘UTF-8’ [, bool $double_encode = true ]]] ) • 属性値をダブルクォートで囲むことにすれば、第2引数はデフ ォルト値( ENT_COMPAT )で問題ない • PHP5.4以降、文字エンコーディングのデフォルト(第3引数) はUTF-8になった。mbstring.internal_encodingがUTF-8の 場合は指定しなくてもよくなった – PHP5.4限定というのも難しいので当面は第3引数明示した方がよ い Copyright © 2012 HASH Consulting Corp. 77
78.
鉄則5: escapashellcmdは使わないこと
Copyright © 2012 HASH Consulting Corp. 78
79.
escapeshellcmdは仕様がおかしい • escapeshellcmdはコマンドライン全体をまるっと指定して得スープする
ことを意図している • しかし、パラメータ中に空白があった場合、パラメータの区切りが区別 できない • すなわち、escapeshellcmdは、本質的にパラメータインジェクションの 危険性がある – 例: $cmd = 'grep ' . $_POST[’key’] . '/var/data/data.txt'; $escaped_command = escapeshellcmd($cmd); system($escaped_command); – keyに下記を与えると : /etc/passwd – 以下が実行される grep : /etc/passwd /var/data/data.txt • 対策:escapeshellargを使う Copyright © 2012 HASH Consulting Corp. 79
80.
鉄則6: SQLインジェクションの対処
Copyright © 2012 HASH Consulting Corp. 80
81.
SQLインジェクション • SQLインジェクションとは、
WHERE句に or ’a’=’a’ を追加する攻撃…ではない • 多くの場合、SQL文の後半を自由に改変できる – WHERE句の改変 – UNION SELECTの追加 – … • DB内の任意テーブルの情報を取得可能 – 大規模な情報漏洩につながる • MS SQLやPostgreSQLの場合、第2、第3のSQL文を追加 できる(複文の実行) – 複文が実行できる場合、データの改変、追加、削除が可能 Copyright © 2012 HASH Consulting Corp. 81
82.
SQLインジェクション対策 • プレースホルダを用いてSQL文を呼び出す…の一択 –
エスケープはややこしすぎる • DB接続の際に文字エンコーディングを指定すること • (できれば)静的プレースホルダを用いること • 安全なSQLの呼び出し方を良く読むこと(無料です) Copyright © 2012 HASH Consulting Corp. 82
83.
鉄則7: クロスサイト・スクリプティングの
対処 Copyright © 2012 HASH Consulting Corp. 83
84.
クロスサイトスクリプティング(XSS)とは • XSSは、ブラウザ上でalertを表示する攻撃…ではない • 攻撃者が、一般利用者のブラウザ上で、勝手なJavaScriptを
実行できる脆弱性 / 攻撃手法 • それって、ウイルス? – XSS自体はウイルスではないが、XSS脆弱性を悪用してウイルス の一種(ワーム)を作ることはできる – 不正確だが「ウイルスのように凶悪なもの」という理解はあり • 対策は、HTMLのエスケープ – これが複雑 Copyright © 2012 HASH Consulting Corp. 84
85.
HTMLの構成要素 Copyright © 2012
HASH Consulting Corp. 85
86.
HTMLエスケープの概要 場所
説明 エスケープの概要 要素内容(通常の タグと文字参照が解釈さ 「<」と「&」を文字参照に テキスト) れる「<」で終端 文字参照が解釈される 属性値を「”」で囲み、「”」と 属性値 引用符で終端 「&」を文字参照に URLの形式を検査してから 属性値(URL) 同上 属性値としてのエスケープ JavaScriptとしてエスケープ イベントハンドラ内 同上 してから属性値としてのエス の文字列リテラル ケープ JavaScriptとしてのエスケー script要素内の文 タグも文字参照も解釈さ プおよび「</」が出現しないよ 字列リテラル れない。「</」により終端 う考慮 Copyright © 2012 HASH Consulting Corp. 86
87.
鉄則8: クロスサイト・リクエスト・フォージ
ェリの対処 Copyright © 2012 HASH Consulting Corp. 87
88.
クロスサイト・リクエスト・フォージェリの対処 • クロスサイト・リクエスト・フォージェリ(CSRF)とは –
Webアプリケーションの「機能」を勝手に実行させられる – サーバー側の作用(更新、送金、投稿、削除…)に限られる • 勝手に実行させられるのは、「サーバー側に元々ある機能」 – SQLインジェクションは任意のSQLが実行可能 – XSSは任意のJavaScriptが実行可能…という点で異なる • でも、XSSとCSRFは、なんか、似ている Copyright © 2012 HASH Consulting Corp. 88
89.
反射型XSSとCSRFの比較
徳丸本P147より引用 Copyright © 2012 HASH Consulting Corp. 89
90.
クリックジャッキング攻撃 • 機能を勝手に実行させられるという点でCSRFと類似 • ターゲットの画面をiframe上で「透明に」表示する •
その下にダミーの画面を表示させる。ユーザにはダミーの画 面が透けて見える • 利用者がダミーの画面上のボタンを押すと、実際には全面の ターゲット画面のボタンが押される 本当の画面(前面、透明) ダミーの画面(後面) Copyright © 2012 HASH Consulting Corp. 90
91.
CSRF/クリックジャッキングの対策 • CSRF対策はトークンによる方法に統一しよう
– 「ワンタイムトークン」である必要はない • クリックジャッキングされると困るページには、X-FRAME-OPTIONSヘッダを指定す る(徳丸本P63) – frame/iframeを禁止して良い場合 header('X-FRAME-OPTIONS', 'DENY'); – frame/iframeを禁止できないが単一ホストの場合 header('X-FRAME-OPTIONS', 'SAMEORIGIN'); • CSRF対策のトークン発行しているページが対象となる 入力画面 実行画面 メールアドレス foo@pexample.jp メールアドレスアドレスを 変更しました 変更 header('X-FRAME-OPTIONS', 'DENY'); セッション等に保存したtokeとhiddenの … token値を比較) <input type="hidden" name="token" value="a89daf89af0…"> Copyright © 2012 HASH Consulting Corp. 91
92.
鉄則9: パスワードの保存はソルトつき ハッシュ、できればストレッチングも
Copyright © 2012 HASH Consulting Corp. 92
93.
どうして暗号化ではなくてハッシュなの? • 暗号化の場合、鍵の管理が難しい • アプリケーションは鍵を使わなければならないが、攻撃者には鍵を見せ
たくない • PSNの事件では、権限昇格されたことになっているので、暗号鍵も盗ま れていると想定せざるを得ない • ハッシュだと鍵を使わないので、鍵管理のわずらわしさがない • パスワードをサイト管理者にも知られたくないというニーズも – 暗号化されたパスワードだと、サイト管理者やヘルプデスク担当者がパスワードを 知り得るのが嫌だ – ヘルプデスクに見せないようにするには、サポート用画面の機能次第で可 – 管理者の悪事は総合的な対策が必要で、パスワードの問題だけではない • PCI-DSS2.0 8.4項には「8.4 強力な暗号化を使用して、すべてのシス テムコンポーネントでの伝送および保存中のすべてのパスワードを読 み取り不能にする」とあり、ハッシュを求めてはいない Copyright © 2012 HASH Consulting Corp. 93
94.
ハッシュで保存されたパスワードは本当に安全なの? • 一般的に、(暗号論的)ハッシュ値から平文を「復元する」ことはできな
い – 「password」のMD5ハッシュ: 5f4dcc3b5aa765d61d8327deb882cf99 • しかし、パスワードの場合は特別な事情がある • 例:4桁の暗証番号をハッシュ値で保存している場合 – 全ての可能性は1万通りしかないのだから、総当たりで確認すれば、平文の暗証 番号はすぐに判明する • 原理は8桁パスワードでも同じ • ハッシュ保存の場合、アルゴリズムは攻撃者が知っている前提で安全 な設計とする – 平文パスワード以外は、すべて「ばれている」想定を置く • 攻撃者にとって未知であることが保証された情報があれば、それを鍵と して暗号化すればよい。現実にはそのような保証がないから暗号化を 用いない Copyright © 2012 HASH Consulting Corp. 94
95.
Saltってなに? • ソルト(Salt)とは、ハッシュの元データ(パスワード)に追加する文字列 • 見かけのパスワードの長さを長くする
– 公開されたレインボーテーブルは10文字までのパスワードに対応しているので、 パスワードとソルトを合わせて20文字以上にしておけば、当面は大丈夫 • ユーザ毎にソルトを変えることで、パスワードが同じでも、異なるハッシ ュ値が得られる • ソルトの要件 – ある程度の長さを確保すること – ユーザ毎に異なるものにすること • ソルトには乱数を用いることが多いが、乱数が必須というわけではない (暗号論的に安全な乱数である必要はもちろんない) • ソルトは秘密情報ではない。ソルトは、通常ハッシュ値と一緒に保存す る Copyright © 2012 HASH Consulting Corp. 95
96.
Stretchingってなに? • ストレッチング(Stretching)とは、ハッシュの計算を繰り返すこと • ハッシュの計算を遅くすることにより、辞書攻撃や総当たり攻撃に対抗
する • 1万回ストレッチすると、「 GPU で 7 時間である」が7万時間になる計算 – 7万時間 = 2916日 = 約8年 • 「悪い」パスワードまで救えるわけではない – 「password」というパスワードをつけていたら、100万回ストレッチしてもすぐに解 読されてしまう • 十分長いパスワードをつけてもらえば、ストレッチングは必要ない – 1文字パスワードを長くすることは、約100回のストレッチングに相当する。パスワ ードを2文字長くしてもらえば… – でも、中々難しいのでストレッチングの値打ちがある • ストレッチングはメリットとデメリットがあるので、導入の有無と回数をよ く検討すること Copyright © 2012 HASH Consulting Corp. 96
97.
鉄則10: 他にもたくさんある
脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 97
98.
徳丸本に載っている主な脆弱性 4.3.1 クロスサイト・スクリプティング 4.4.1 SQLインジェクション 4.5.1
クロスサイト・リクエストフォージェリ(CSRF) 4.6.2 推測可能なセッションID 4.6.3 URL埋め込みのセッションID 4.6.4 セッションIDの固定化 4.7.1 オープンリダイレクタ脆弱性 4.7.2 HTTPヘッダ・インジェクション 短時間ではとても 4.8.2 クッキーのセキュア属性不備 説明できません 4.9.2 メールヘッダ・インジェクション脆弱性 4.10.1 ディレクトリ・トラバーサル脆弱性 4.10.2 意図しないファイル公開 4.11.1 OSコマンド・インジェクション 4.12.2 アップロードファイルによるサーバー側スクリプト実行 4.12.3 ファイルダウンロードによるクロスサイト・スクリプティング 4.13.1 ファイルインクルード攻撃 4.14.1 evalインジェクション 4.15.1 競合状態の脆弱性 Copyright © 2012 HASH Consulting Corp. 98
99.
結論 徳丸本を買ってよく読め ご清聴ありがとうございました Copyright
© 2012 HASH Consulting Corp. 99