Suche senden
Hochladen
SQLインジェクション再考
•
1 gefällt mir
•
1,123 views
Hiroshi Tokumaru
Folgen
WASForum 2008 における講演資料です。古いものですが、資料的な意味で公開します
Weniger lesen
Mehr lesen
Technologie
Melden
Teilen
Melden
Teilen
1 von 31
Empfohlen
SQLインジェクション総”習”編
SQLインジェクション総”習”編
Yasuo Ohgaki
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
Hiroshi Tokumaru
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
Hiroshi Tokumaru
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
Hiroshi Tokumaru
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
XSS再入門
XSS再入門
Hiroshi Tokumaru
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
Hiroshi Tokumaru
Weitere ähnliche Inhalte
Was ist angesagt?
PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点
zaki4649
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
Hiroshi Tokumaru
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
Hiroshi Tokumaru
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
zaki4649
最近のやられアプリを試してみた
最近のやられアプリを試してみた
zaki4649
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
kwatch
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
Hiroshi Tokumaru
今さら聞けないXSS
今さら聞けないXSS
Sota Sugiura
ウェブセキュリティの常識
ウェブセキュリティの常識
Hiroshi Tokumaru
猫でもわかるかもしれない SQLインジェクション
猫でもわかるかもしれない SQLインジェクション
kinme modoki
Redmineをちょっと便利に! プログラミング無しで使ってみるREST API
Redmineをちょっと便利に! プログラミング無しで使ってみるREST API
Go Maeda
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
Hiroshi Tokumaru
flaws.cloudに挑戦しよう!
flaws.cloudに挑戦しよう!
zaki4649
Proxy War
Proxy War
zaki4649
SQLアンチパターン - ナイーブツリー
SQLアンチパターン - ナイーブツリー
ke-m kamekoopa
テストとリファクタリングに関する深い方法論 #wewlc_jp
テストとリファクタリングに関する深い方法論 #wewlc_jp
kyon mm
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
Hiroshi Tokumaru
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
エンジニア必見!Sreへの第一歩
エンジニア必見!Sreへの第一歩
Takuya Tezuka
Was ist angesagt?
(20)
PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
とある診断員と色々厄介な脆弱性達
とある診断員と色々厄介な脆弱性達
最近のやられアプリを試してみた
最近のやられアプリを試してみた
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
今さら聞けないXSS
今さら聞けないXSS
ウェブセキュリティの常識
ウェブセキュリティの常識
猫でもわかるかもしれない SQLインジェクション
猫でもわかるかもしれない SQLインジェクション
Redmineをちょっと便利に! プログラミング無しで使ってみるREST API
Redmineをちょっと便利に! プログラミング無しで使ってみるREST API
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
flaws.cloudに挑戦しよう!
flaws.cloudに挑戦しよう!
Proxy War
Proxy War
SQLアンチパターン - ナイーブツリー
SQLアンチパターン - ナイーブツリー
テストとリファクタリングに関する深い方法論 #wewlc_jp
テストとリファクタリングに関する深い方法論 #wewlc_jp
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
エンジニア必見!Sreへの第一歩
エンジニア必見!Sreへの第一歩
Ähnlich wie SQLインジェクション再考
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
Hiroshi Tokumaru
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
Hiroshi Tokumaru
Phpcon2015
Phpcon2015
Hiroshi Tokumaru
Webアプリでパスワード保護はどこまでやればいいか
Webアプリでパスワード保護はどこまでやればいいか
Hiroshi Tokumaru
徳丸本ができるまで
徳丸本ができるまで
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
Ähnlich wie 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
Mehr von Hiroshi Tokumaru
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
Hiroshi Tokumaru
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
Hiroshi Tokumaru
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
Hiroshi Tokumaru
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
Hiroshi Tokumaru
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
Hiroshi Tokumaru
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
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
Mehr von Hiroshi Tokumaru
(19)
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
秀スクリプトの話
秀スクリプトの話
デバッガで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年間でどの程度対策されたか?
Kürzlich hochgeladen
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
arts yokohama
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
Shumpei Kishi
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
Industrial Technology Research Institute (ITRI)(工業技術研究院, 工研院)
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
arts yokohama
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
Tetsuya Nihonmatsu
2024 04 minnanoito
2024 04 minnanoito
arts yokohama
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
Ayachika Kitazaki
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
Matsushita Laboratory
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
ssuser539845
2024 03 CTEA
2024 03 CTEA
arts yokohama
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
ssuser370dd7
Kürzlich hochgeladen
(11)
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
2024 04 minnanoito
2024 04 minnanoito
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
2024 03 CTEA
2024 03 CTEA
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
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 ご清聴ありがとうございました