以下に3種類の攻撃について概要を説明します。概要の後に、もう少し詳細の情報を書いています。 本記事で「MySQL」と書いてある箇所は、MariaDBも含むと考えてください。 A-1 数値攻撃 [MySQL] 本攻撃は、文字列と数値の比較に関する、MySQLに特有の仕様を利用します。 以下は、文字列カラム(token)と数値(0)を比較させた結果です。 mysql> SELECT id, token FROM users WHERE id=1 AND token=0; +----+------------------------+ | id | token | +----+------------------------+ | 1 | M4fjL71F4e6oFw5WBCmHew | ← これが「0」と一致 +----+------------------------+ 明らかに0ではない文
ANDPADボードチームの原田(tomtwinkle)です。 Node.jsの mysqljs/mysql の仕様に起因するSQLインジェクションが話題に上がっていたので、それGolangのORMであるGormでも同じような「仕様」があるよ！ という注意喚起の意味も込めて筆を執りました。 ※ 2022/02/21追記 コードレビューを自動化して指摘してもらう記事を公開しました！ tech.andpad.co.jp Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション | 株式会社Flatt Security TL;DR GormのQuery Conditions関数に関する危険な仕様 対策 締め TL;DR GormのConditions関数(Find, First, Delete...)を使用する際、第2引数の値にStringを引き渡
※本記事は筆者styprが英語で執筆した記事を株式会社Flatt Security社内で日本語に翻訳したものになります。 TL;DR Node.jsのエコシステムで最も人気のあるMySQLパッケージの一つである mysqljs/mysql (https://github.com/mysqljs/mysql)において、クエリのエスケープ関数の予期せぬ動作がSQLインジェクションを引き起こす可能性があることが判明しました。 通常、クエリのエスケープ関数やプレースホルダはSQLインジェクションを防ぐことが知られています。しかし、mysqljs/mysql は、値の種類によってエスケープ方法が異なることが知られており、攻撃者が異なる値の種類でパラメータを渡すと、最終的に予期せぬ動作を引き起こす可能性があります。予期せぬ動作とは、バグのような動作やSQLインジェクションなどです。 ほぼすべてのオンラ
This wiki's mission is to be a one stop resource for fully identifying, exploiting, and escalating SQL injection vulnerabilities across various Database Management Systems (DBMS). This wiki assumes you have a basic understanding of SQL injection, please go here for an introduction if you are unfamiliar. Below is an outline of the wiki's structure, laid out in the order of a normal escalation path.
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
"CaseA-SQLInj" by KeigoYAMAZAKI - The Golden Axe from Aesop SQL Injection Simulator (Joke App) これは何？ ジョークアプリです。 SQLインジェクションの練習ができます。 以下のエントリに触発されて作りました。 ケースA 落とした斧の種類を尋ねた際に攻撃を受けた事例 - 脆弱性を攻撃される童話事例集（鶴見トイ） - カクヨム https://kakuyomu.jp/works/1177354054882453808/episodes/1177354054882454106 徳丸 浩さんのツイート: "このSQLインジェクション攻撃は末尾にシングルクォートが残りシンタックスエラーになるはずだ。無粋なようだが立場上指摘しないわけにはいかない / “ケースA 落とした斧の種類を尋ねた際に攻撃を受けた事例
はじめに 環境構築 インストール データベース設定 データベース・テーブル初期化 動作確認 Less-1 (GET - Error based - Single quotes - String) Less-5 (GET - Double Injection - Single Quotes - String) Less-10 (GET - Blind - Time based - double quotes) level 1 ⇒ 失敗 Less-11 (POST - Error Based - Single quotes - String) Less-18 (POST - Header Injection - Uagent field - Error based) Less-23 (GET - Error based - strip comments) Less-53 (GET - Blin
SQLI-LABS is a platform to learn SQLI Following labs are covered for GET and POST scenarios: Error Based Injections (Union Select) String Intiger Error Based Injections (Double Injection Based) BLIND Injections: 1.Boolian Based 2.Time Based Update Query Injection. Insert Query Injections. Header Injections. 1.Referer based. 2.UserAgent based. 3.Cookie based. Second Order Injections Bypassing WAF B
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
結論 ・PHPに入ってくるときに入力値検証 ・PHPから出ていくときにエスケープ ・サニタイズはない サニタイズ サニタイズって言うと怖い人たちがやってくるから言わないようにしましょう。 サニタイズは入力値検証もエスケープもなにもかもを含んだ広い意味になってしまったので、うっかり言ってることが食い違うと大変です。 入力値検証 入力値検証は、PHPの外からPHPに入ってくる値を検証することです。 外というと主に$_REQUEST/$_GET/$_POST等のリクエストパラメータがイメージされますが、実際はそれ以外にも環境変数、コマンドライン引数、ファイルやデータベースからの読み込みなど、PHP以外からやってくる全てのものを指します。 入力値検証はセキュリティ対策ではない もう入力値検証はセキュリティ対策としてあてにしないようにしようという記事がありますが、「もう」以前に、そもそも入力値検証は
Tweet はじめに システムのセキュリティリスクを把握する一つの手段として、セキュリティ診断が有効だと言われています。セキュリティ診断の代表的なものに、サーバーやネットワーク機器を対象とするネットワーク診断、主に顧客が独自作成したWebアプリケーションを対象としたWebアプリケーション診断があります。当社でも、これらの診断サービスを提供しています。 診断サービスを選択する際に、重要な点として以下があります(費用は、以下の項目に応じて決まるため、観点から除いています)。 診断手法 診断対象 診断項目 Webアプリケーション診断に適用すると、具体的には以下のようになります。 1. 診断手法 スキャナーを利用するのか、診断員が手動オペレーションで診断するのかなどの診断の手法に関係するもの。 2. 診断対象 全てのページなのか、一部のページに限定するのか(例：同じ作りのページは代表的なページ
つい最近まで、グローバル・スタンダードのセキュリティ施策ではバリデーションが極めて重視されている、いささか過剰ではないかと思っていたのですが、OWASPの文書を読みなおしたところ、これは僕の思い過ごしだったかと思い始めました。あくまでOWASPに限った話ではありますが… OWASP Top 10 2004については、以下のようなプレゼンをしたことがあります（2012年3月27日）。 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ OWASP Top 10 2004をはじめとして、バリデーションが過剰に重視されているのではないかという指摘でした。 しかし、最近OWASPの文書を読みなおしてみると、OWASP Top 10 2004当時にあった「バリデーション至上主義」のようなものはすっかり影を潜め、私が（そして日本の専門家の多くが）言っていることとほとんど変わらないことに
SQL injectionのテストツールであるsqlmapを使ってみる。 環境 Ubuntu 14.04.3 LTS 64bit版、Docker 1.9.1 $ uname -a Linux vm-ubuntu64 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty $ sudo docker version Client: Version: 1.9.1 API version:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
