Submit Search
Upload
SQLインジェクション再考
•
1 like
•
1,128 views
Hiroshi Tokumaru
Follow
WASForum 2008 における講演資料です。古いものですが、資料的な意味で公開します
Read less
Read more
Technology
Report
Share
Report
Share
1 of 31
Recommended
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
Hiroshi Tokumaru
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
Hiroshi Tokumaru
SQLインジェクション総”習”編
SQLインジェクション総”習”編
Yasuo Ohgaki
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
zaki4649
XSS再入門
XSS再入門
Hiroshi Tokumaru
徳丸本ができるまで
徳丸本ができるまで
Hiroshi Tokumaru
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
Hiroshi Tokumaru
Recommended
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
Hiroshi Tokumaru
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
Hiroshi Tokumaru
SQLインジェクション総”習”編
SQLインジェクション総”習”編
Yasuo Ohgaki
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
zaki4649
XSS再入門
XSS再入門
Hiroshi Tokumaru
徳丸本ができるまで
徳丸本ができるまで
Hiroshi Tokumaru
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
Hiroshi Tokumaru
ウェブセキュリティの常識
ウェブセキュリティの常識
Hiroshi Tokumaru
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
Hiroshi Tokumaru
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
Hiroshi Tokumaru
セキュリティを楽しむ(CTFとbugbountyの始め方)
セキュリティを楽しむ(CTFとbugbountyの始め方)
kazkiti
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
Hiroshi Tokumaru
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
Sen Ueno
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
Hiroshi Tokumaru
130821 owasp zed attack proxyをぶん回せ
130821 owasp zed attack proxyをぶん回せ
Minoru Sakai
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
Hiroshi Tokumaru
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
Hiroshi Tokumaru
今夜わかるWebアプリケーション脆弱性診断 (OWASP Day 758 / 2018)
今夜わかるWebアプリケーション脆弱性診断 (OWASP Day 758 / 2018)
Sen Ueno
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
Hiroshi Tokumaru
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku0825
XSSフィルターを利用したXSS攻撃 by Masato Kinugawa
XSSフィルターを利用したXSS攻撃 by Masato Kinugawa
CODE BLUE
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
infinite_loop
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
Hiroshi Tokumaru
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
Hiroshi Tokumaru
Phpcon2015
Phpcon2015
Hiroshi Tokumaru
More Related Content
What's hot
ウェブセキュリティの常識
ウェブセキュリティの常識
Hiroshi Tokumaru
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
Hiroshi Tokumaru
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
Hiroshi Tokumaru
セキュリティを楽しむ(CTFとbugbountyの始め方)
セキュリティを楽しむ(CTFとbugbountyの始め方)
kazkiti
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
Hiroshi Tokumaru
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
Sen Ueno
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
Hiroshi Tokumaru
130821 owasp zed attack proxyをぶん回せ
130821 owasp zed attack proxyをぶん回せ
Minoru Sakai
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
Hiroshi Tokumaru
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
Hiroshi Tokumaru
今夜わかるWebアプリケーション脆弱性診断 (OWASP Day 758 / 2018)
今夜わかるWebアプリケーション脆弱性診断 (OWASP Day 758 / 2018)
Sen Ueno
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
Hiroshi Tokumaru
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku0825
XSSフィルターを利用したXSS攻撃 by Masato Kinugawa
XSSフィルターを利用したXSS攻撃 by Masato Kinugawa
CODE BLUE
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
infinite_loop
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
Hiroshi Tokumaru
What's hot
(20)
ウェブセキュリティの常識
ウェブセキュリティの常識
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
セキュリティを楽しむ(CTFとbugbountyの始め方)
セキュリティを楽しむ(CTFとbugbountyの始め方)
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
130821 owasp zed attack proxyをぶん回せ
130821 owasp zed attack proxyをぶん回せ
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
今夜わかるWebアプリケーション脆弱性診断 (OWASP Day 758 / 2018)
今夜わかるWebアプリケーション脆弱性診断 (OWASP Day 758 / 2018)
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
XSSフィルターを利用したXSS攻撃 by Masato Kinugawa
XSSフィルターを利用したXSS攻撃 by Masato Kinugawa
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
Similar to SQLインジェクション再考
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
Hiroshi Tokumaru
Phpcon2015
Phpcon2015
Hiroshi Tokumaru
Webアプリでパスワード保護はどこまでやればいいか
Webアプリでパスワード保護はどこまでやればいいか
Hiroshi Tokumaru
DDD 2016 DB 12c クエリー・オプティマイザ新機能活用と統計情報運用の戦略
DDD 2016 DB 12c クエリー・オプティマイザ新機能活用と統計情報運用の戦略
歩 柴田
Wtm
Wtm
Soudai Sone
[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシア...
[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシア...
Insight Technology, Inc.
45分で理解する SQL Serverでできることできないこと
45分で理解する SQL Serverでできることできないこと
Insight Technology, Inc.
[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)
[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)
Insight Technology, Inc.
オープンソース・データベースの最新事情
オープンソース・データベースの最新事情
Meiji Kimura
[OSC 2017 Tokyo/Fall] OSSコンソーシアム DB部会 MySQL 8.0
[OSC 2017 Tokyo/Fall] OSSコンソーシアム DB部会 MySQL 8.0
Ryusuke Kajiyama
JPAのキャッシュを使ったアプリケーション高速化手法
JPAのキャッシュを使ったアプリケーション高速化手法
Chihiro Ito
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
Hideo Takagi
Developers.IO 2019 Effective Datalake
Developers.IO 2019 Effective Datalake
Satoru Ishikawa
ついにリリース!! MySQL 8.0 最新情報
ついにリリース!! MySQL 8.0 最新情報
yoyamasaki
安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014
Hiroshi Tokumaru
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
infinite_loop
Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Ryota Watabe
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
Operation Lab, LLC.
Introduction of SQL Anti-pattern at Phpcon Hokkaido
Introduction of SQL Anti-pattern at Phpcon Hokkaido
Kenta Kawai
Similar to SQLインジェクション再考
(20)
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
Phpcon2015
Phpcon2015
Webアプリでパスワード保護はどこまでやればいいか
Webアプリでパスワード保護はどこまでやればいいか
DDD 2016 DB 12c クエリー・オプティマイザ新機能活用と統計情報運用の戦略
DDD 2016 DB 12c クエリー・オプティマイザ新機能活用と統計情報運用の戦略
Wtm
Wtm
[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシア...
[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシア...
45分で理解する SQL Serverでできることできないこと
45分で理解する SQL Serverでできることできないこと
[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)
[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)
オープンソース・データベースの最新事情
オープンソース・データベースの最新事情
[OSC 2017 Tokyo/Fall] OSSコンソーシアム DB部会 MySQL 8.0
[OSC 2017 Tokyo/Fall] OSSコンソーシアム DB部会 MySQL 8.0
JPAのキャッシュを使ったアプリケーション高速化手法
JPAのキャッシュを使ったアプリケーション高速化手法
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
Developers.IO 2019 Effective Datalake
Developers.IO 2019 Effective Datalake
ついにリリース!! MySQL 8.0 最新情報
ついにリリース!! MySQL 8.0 最新情報
安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
Introduction of SQL Anti-pattern at Phpcon Hokkaido
Introduction of SQL Anti-pattern at Phpcon Hokkaido
More from Hiroshi Tokumaru
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
Hiroshi Tokumaru
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
Hiroshi Tokumaru
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
Hiroshi Tokumaru
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
Hiroshi Tokumaru
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
Hiroshi Tokumaru
秀スクリプトの話
秀スクリプトの話
Hiroshi Tokumaru
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
Hiroshi Tokumaru
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
Hiroshi Tokumaru
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かり
Hiroshi Tokumaru
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016
Hiroshi Tokumaru
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
Hiroshi Tokumaru
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
Hiroshi Tokumaru
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
Hiroshi Tokumaru
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
Hiroshi Tokumaru
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Hiroshi Tokumaru
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Hiroshi Tokumaru
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
Hiroshi Tokumaru
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?
Hiroshi Tokumaru
More from Hiroshi Tokumaru
(18)
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
秀スクリプトの話
秀スクリプトの話
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かり
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?
Recently uploaded
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Atomu Hidaka
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
danielhu54
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
Shota Ito
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
osamut
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
sugiuralab
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdf
furutsuka
Recently uploaded
(9)
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdf
SQLインジェクション再考
1.
Copyright © 2008
HASH Consulting Corp. 1 SQLインジェクション対策再考 HASHコンサルティング株式会社 代表取締役 徳丸 浩
2.
Copyright © 2008
HASH Consulting Corp. 2 アジェンダ • 本日の構成 – 正しくないSQLインジェクション対策の今昔 – SQLインジェクション対策の考え方 – SQLインジェクション対策の実際 • 議論の焦点 – 入力値検証とは何か – SQLのエスケープ方法詳細 – 数値項目の対策 – 最近のトピックス
3.
Copyright © 2008
HASH Consulting Corp. 3 第1部 正しくないSQLインジェクション対策の今昔
4.
Copyright © 2008
HASH Consulting Corp. 4 正しくない例1(2001年) 実践! セキュアなWebプログラミング 日経オープンシステム2001年5月号 から引用 正しい これは余計 でもこれは 2001年の記事だから…
5.
Copyright © 2008
HASH Consulting Corp. 5 正しくない例2(2007年) (1) 入力値のチェック 【中略】 データベースで扱う値に対して上記のような文字種、文字数等の条件を明確にし、ブラウザか ら渡された値が、入力値として正しい形式であるかどうかをチェックする。条件を細かく設定し、 厳密にチェックすることによって、任意のSQL文の混入を避けることができる。 (2) 特殊記号のエスケープ 1) シングルクォート「'」のエスケープ 【中略】 3) セミコロン「;」の拒否 次の特殊記号が含まれているときは、パラメータを受理しない。 ; → 受理しない 「;」は、SQL文のコマンドの区切りに使用される。 【中略】 5) その他の特殊記号のエスケープ(Microsoft Jetエンジン) またMicrosoftのJetエンジンでは、次の文字も機能をもつ特殊記号として扱われる。 | VBAステートメント実行文字 IPA ISEC セキュア・プログラミング講座:Webアプリケーション編 第6章 入力対策:SQL注入 より引用 http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/502.html 場合もある わけにいかない どうやってエスケープ? 正しい
6.
Copyright © 2008
HASH Consulting Corp. 6 正しくない例3(2008年) 被害が続くSQLインジェクション攻撃,もう一度対策を見直そう より引用 http://itpro.nikkeibp.co.jp/article/COLUMN/20080514/301660/ 【前提1】 ・Webアプリケーションは文字列を入力として受理できる ・リレーショナル・データベース管理システムと連携 【入力の例】 DECLARE%20@S%20NVARCHAR(4000)SET%20@S=hogehoge EXEC(@S) ・文字列として入力 ・特殊文字を文字として扱うために「」を挿入 ・「;」は削除 【入力値チェックの結果】 DECLARE%20@S%20NVARCHAR(4000)SET%20@S=hogehoge EXEC(@S) 【前提2】 ・SQLクエリーはアプリケーションで生成 ・SQL構文に用いるような文字列はユーザーの入力としてはありえない 【入力の例(入力値チェックの結果)】 DECLARE%20@S%20NVARCHAR(4000)SET%20@S=hogehoge EXEC(@S) ・SQL構文に用いられる代表的な文字列をフィルタリングして削除 ・アットマーク(@)はデータベース上で変数の識別子やスクリプト の実行に用いられることがあるため削除 【サニタイジングの例】 %20S%20(4000) %20S=hogehoge (S) パーセントエンコー ドをデコードしてから でないと無意味 むやみに「」を 挿入しても…セミコロンを勝手 に削除しないで! 意味不明 サニタイズ!!
7.
Copyright © 2008
HASH Consulting Corp. 7 なぜ誤った解説がなくならないのか • 攻撃方法からの発想 – 攻撃に使用する文字・文字列を削除・改変するアプローチ – いわゆる「サニタイズ」 – 脆弱性が混入する根本原因からのアプローチではない • 実はアプリケーションなんか書いた人が説明している? – セキュリティのプロが全員アプリケーションを書けるとは限らない • そのサンプルコード、動かしてみた? – でもテスト環境構築するだけでも大変だしぃ • コピペの悪弊 – 昔の間違った解説が延命されられる みんな攻撃が大好きだww
8.
Copyright © 2008
HASH Consulting Corp. 8 【参考】なぜセミコロン「;」を削除したがるのか? • 実はセミコロンの削除には実効的な意味はあまりない • セミコロン削除の意図は、複文実行の防止と思われる – SELECT * FROM XXX WERE ID=’’;UPDATE XXX SET … • SQLインジェクションの文脈で複文が実行できるのは、MS SQL とPostgreSQL • 現実にMS SQLは、複文を使った改ざん事件が多発 • しかし、MS SQLは、セミコロンなしでも複文が書ける – SELECT * FROM XXX WERE ID=’’UPDATE XXX SET … でもよい • すなわち、セミコロンの削除で保険的にせよ意味があるのは、 PostgreSQLの場合だけ 続きはWebで http://www.tokumaru.org/d/20080502.html http://www.tokumaru.org/d/20080627.html
9.
Copyright © 2008
HASH Consulting Corp. 9 「危険文字と言わないで」
10.
Copyright © 2008
HASH Consulting Corp. 10 第2部 SQLインジェクション対策の考え方
11.
Copyright © 2008
HASH Consulting Corp. 11 そもそもなぜSQLインジェクションが発生するのか? • 原因は、リテラルとして指定したパラメータが、リテラルの枠をは み出し、SQLの一部として解釈されること • 文字列リテラルの場合 – シングルクォートで囲まれた(クォートされた)範囲をはみ出す SELECT * FROM XXX WHERE A=’’OR’A’=A’ • 数値リテラルの場合 – 数値でない文字(空白、英字、記号など)を使う SELECT * FROM XXX WHERE A=1OR TRUE はみ出した部分
12.
Copyright © 2008
HASH Consulting Corp. 12 エスケープは檻にしっかり入れるイメージ • 檻に入っている分には、中身の「危険性」を気にする必要なはい • 危険性がなくても、檻から出てしまうのはバグ select * from animals whre kind=' ' 「危険な文字・文字列」 ; | ' @ declare union xp_cmdshell @ ...
13.
Copyright © 2008
HASH Consulting Corp. 13 SQLインジェクションは檻から逃げるイメージ • パラメタがリテラルからはみ出し、SQL文の命令として解釈される 状態 「危険な文字・文字列」 ; | ' @ declare union xp_cmdshell @ ... select * from animals whre kind=' '
14.
Copyright © 2008
HASH Consulting Corp. 14 [プロの礼儀作法としての参考文献] ライオン・エスケープ http://www.rakuten.co.jp/torito/659325/660549/ から引用
15.
Copyright © 2008
HASH Consulting Corp. 15 第3部 SQLインジェクション対策の実際
16.
Copyright © 2008
HASH Consulting Corp. 16 ではどうすればいいのか? • 基本は、リテラルをしっかりと檻に閉じ込めること – 方法1:バインド機構の利用(推奨) • バインド機構の実装にバグがない限り安心(どうやって確認する?) – 方法2:SQLの動的組み立て+エスケープ • ただし数値の場合は別の方法が必要 my $sth = $db->prepare("SELECT ERRMSG FROM ERRINFO WHERE ERRNO=?"); my $rt = $sth->execute($n);
17.
Copyright © 2008
HASH Consulting Corp. 17 第二の選択肢 動的SQL生成+エスケープ • なぜバインド機構を利用しないのか – プラットフォームの制約 – フレームワークの制約 – 古いアプリケーションの保守
18.
Copyright © 2008
HASH Consulting Corp. 18 動的SQL生成の場合は文字列と数値で対応が変わる • 文字列の場合 – エスケープ • 数値の場合 – 変数に型のある言語 Java、C#など • 数値型を使っている場合は問題ない • 文字列型を使って数値を処理する場合は、変数に型のない言語と同じ方法 – 変数に型のない言語 Perl、PHP、Ruby、VBScript(ASP)など • 数値の妥当性確認
19.
Copyright © 2008
HASH Consulting Corp. 19 文字列リテラルのエスケープ • どの文字をエスケープするのか? – SQL製品の文字列リテラルのルールに従う – ISO標準では、「'」→「''」 – MySQLとPostgreSQLは「'」→「''」 「」→「」 – PostgreSQLの場合は、standard_conforming_stringsおよび backslash_quoteの影響を受ける • standard_conforming_strings=onの場合は、ISO標準と同じ方法になる • backslash_quoteの場合は、「'」→「'」というエスケープがエラーになる 元の文字 エスケープ後 Oracle MS SQL IBM DB2 ’ ’’ MySQL PostgreSQL ’ ’’ または ’ (’’を推奨)
20.
Copyright © 2008
HASH Consulting Corp. 20 【参考】商用RDBMSの文字列リテラルの定義 • Oracle:cは、データベース・キャラクタ・セットの任意の要素です。リテラル内の 一重引用符(‘)の前には、エスケープ文字を付ける必要があります。リテラル 内で一重引用符を表すには、一重引用符を2つ使用します。 http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19201-02/sql_elements.html#41297 • DB2:ストリング区切り文字で始まりストリング区切り文字で終わる文字のシー ケンス。この場合のストリング区切り文字はアポストロフィ (‘) です。【中略】文 字ストリング内で 1 つのストリング区切り文字を表したいときは、ストリング区 切り文字を 2 つ連続して使用します。 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r0000731.html • MS SQL:単一引用符で囲まれた文字列に単一引用符を埋め込む場合は、単 一引用符を 2 つ続けて並べることで 1 つの単一引用符を表します。 http://technet.microsoft.com/ja-jp/library/ms179899.aspx
21.
Copyright © 2008
HASH Consulting Corp. 21 【参考】 MySQLの文字列リテラルの定義 8.1.1. 文字列 一部のシーケンスは、個々の文字列内で特別な意味を持ちます。これらのシーケンスは、いず れも、エスケープ文字として知られるバックスラッシュ(‘’)で始まります。MySQLでは、次のエ スケープシーケンスが認識されます。 文字列に引用符を含める方法は、いくつかあります。 •‘’’で囲んだ文字列内で、‘’’を使用する場合、‘’‘’と記述することができます。【後 略】 「MySQL :: MySQL 5.1 リファレンスマニュアル :: 8.1.1 文字列」から引用 http://dev.mysql.com/doc/refman/5.1/ja/string-syntax.html
22.
Copyright © 2008
HASH Consulting Corp. 22 【参考】 PostgreSQLの文字列リテラルの定義 4.1.2.1. 文字列定数 SQLにおける文字列定数は、単一引用符(‘)で括られた任意の文字の並びです。 例えば、’This is a string‘です。 文字列定数内の単一引用符の記述方法は、2つ 続けて単一引用符を記述することです。 【中略】 エスケープ文字列の中では、バックスラッシュ文字()によりC言語のようなバック スラッシュシーケンスが始まります。バックスラッシュと続く文字の組み合わせが 特別なバイト値を表現します。 bは後退(バックスペース)を、fは改頁を、nは改 行を、rは復帰(キャリッジリターン)を、tはタブを表します。また、digitsという形 式もサポートし、digitsは8進数バイト値を表します。 xhexdigitsという形式では、 hexdigitsは16進数バイト値を表します。(作成するバイトの並びがサーバの文字 セット符号化方式として有効かどうかはコード作成者の責任です。)ここに示した 以外のバックスラッシュの後の文字はそのまま解釈されます。したがって、バック スラッシュ文字を含めるには、2つのバックスラッシュ()を記述してください。また、 通常の''という方法以外に、'と記述することで単一引用符をエスケープ文字列に 含めることができます。 http://www.postgresql.jp/document/current/html/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
23.
Copyright © 2008
HASH Consulting Corp. 23 MySQLとPostgreSQLで「」のエスケープが必要な理由 SELECT * FROM XXX WHERE ID='$id' $id として 'or 1=1# が入力されると 'or 1=1# ↓ エスケープ(「」のエスケープをしない場合) ''or 1=1# 元のSQLに適用すると、 SELECT * FROM XXX WHERE ID=''' or 1=1#' すなわち、SQLの構文が改変された(「’」で「’」一文字と見なされる)
24.
Copyright © 2008
HASH Consulting Corp. 24 Shift_JISの問題 表 ' 0x95 0x5c 0x27 ↓フロント側でのエスケープ処理 表 ' ' 0x95 0x5c 0x27 0x27 ↓データベース側の解釈 0x95 0x5c 0x27 0x27 0x95 ' で'一文字 ' がエスケープされずに余る 表 ' 0x95 0x5c 0x27 ↓フロント側でのエスケープ処理(0x5cと0x27をそれぞれエスケープ) 0x95 0x5c 0x5c 0x27 0x27 ↓データベース側の解釈 0x95 0x5c 0x5c 0x27 0x27 「表」一文字 'で一文字 ' がエスケープされずに余る DB側の 日本語処理が 不完全な場合 フロント側の 日本語処理が 不完全な場合
25.
Copyright © 2008
HASH Consulting Corp. 25 文字コードの問題 • 例えば、Shift_JISを避ける • 言語レベルで文字コードを意識したものを – Java # 元々内部はUnicode – Perl5.8 # それ use utf8; で • PostgreSQLの対応(8.1.4) •常にサーバ側で無効なコードのマルチバイト文字を拒否するように修正されました (8.1系~7.3系) これにより、一律にすべての文字エンコーディングのすべてのテキスト入力に対して検査が行わ れ、単に警告が出るのではなく常にエラーが出るようになりました。この変更は CVE-2006-2313 に記述されているような SQLインジェクション攻撃に対抗するものです。 •文字列リテラル中の安全でない「'」を拒否する機能が追加されました (8.1系~7.3系) CVE-2006-2314 に記述されている類のSQLインジェクション攻撃をサーバ側で防ぐため、SQL 文字列リテラルとして ’’ だけを受け付け、 ’ を受け付けないように変更されました【中略】 この振る舞いを調整するため、新たな設定パラメータ backslash_quote が追加されました。なお、 CVE-2006-2314 を完全に防ぐには、おそらくクライアント側の修正も必要です。 backslash_quote は、安全でないクライアントが「安全でない」ことを明らかにするのを目的として います。 http://www.sraoss.co.jp/PostgreSQL/8.1.4/changes.html
26.
Copyright © 2008
HASH Consulting Corp. 26 数値リテラルの場合 • 数値としての妥当性確認をSQL組み立て時に行うとよい • 最初に妥当性検証していても気にしないで再度検証する – 大したオーバーヘッドにはならない # 呼び出し例 eval { my $sql = "SELECT ERRMSG FROM ERRINFO WHERE ERRNO=" . int_check($n); .... } if ($@) { # エラー発生時の処理 } ... # 整数チェック関数の例 sub int_check { my $val = shift; if ($val =~ /^-?[0-9]+$/) { return $val; } else { die "整数値エラー"; # エラーメッセージは$@に格納 } }
27.
Copyright © 2008
HASH Consulting Corp. 27 SQLエスケープの実装はどれを使う? • 「安全なウェブサイトの作り方改定第3版(P7)」には、以下の記述 があるが、 – データベースエンジンによっては、専用のエスケープ処理を行うAPI を提 供しているものがあります(たとえば、Perl ならDBIモジュールのquote()な ど)ので、それを利用することをお勧めします。 • DBIのquote()が全てDB側で用意したAPIを呼んでいるわけでは ない – DBD::PgPPでの実装 $s =~ s/(?=[‘])//g; # PostgreSQLのAPIを呼んでいない return "'$s'"; • 「安全なウェブサイトの作り方」の趣旨には同意するが、具体的に どの関数・メソッド・APIなら安全というガイドラインがないと、開発 現場では使えない – プロジェクトの度にコンサルタント雇って調べさせる?
28.
Copyright © 2008
HASH Consulting Corp. 28 入力値検証は何をすればよいか • アプリケーションレベルで、「’」や「;」を削除、あるいは拒否するわ けにはいかない – クォートやセミコロンも正しく処理できるよう、バインド機構やエスケープを 用いる • ミドルウェアレベルでは、「半端なマルチバイトコード」や「UTF-8 の冗長表現」をチェックし、エラーにすべき • アプリケーションレベルでは、「業務要件」にしたがって入力値検 証する – 結果としてSQLインジェクション対策になる場合もあれば、ならない場合も ある – メタ文字ではなく、制御文字(ヌル文字を含む)のチェックは必要 (改行・タブ以外の制御文字はミドルウェアレベルでチェックして欲しい)
29.
Copyright © 2008
HASH Consulting Corp. 29 おまけ:述語LIKEのワイルドカードのエスケープ • 述語LIKEのワイルドカード「_」、「%」にも注意 • 狭義のSQLインジェクションとは違うが、サーバーに過負荷をか ける場合がある(全件検索) • MySQL以外の場合はESCAPE句の利用 – … LIKE ’#%%’ ESCAPE ’#’ -- 「#%」で文字としての「%」を示す • MySQLの場合は「」によりエスケープ – … LIKE ’%%’ -- 「%」で文字としての「%」を示す • 商用RDBMSの場合は全角の「_」 や「%」にも注意
30.
Copyright © 2008
HASH Consulting Corp. 30 まとめ・提言 • そろそろ「入力値の未検証」という表現はやめよう • バインド機構の利用促進 • 正しいエスケープ方法の普及 • 安全なフレームワーク • 安全なバインド機構はどれ? • 安全なエスケープ関数はどれ? • 「安全なウェブサイトの作り方」のさらに具体的なガイドライン の必要性
31.
Copyright © 2008
HASH Consulting Corp. 31 ご清聴ありがとうございました