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.
端的には「PHPで、動的にSQL文を組む必要があるときにどうやってプリペアドステートメントで組んでいくか」の一例と、それに合わせて「INをうまいことプリペアドステートメントで使いたい」時の一例を書いてみます。 いやなんか知られてるような知られてないような微妙なナレッジだったので「まぁ書いておけばいいや」的な、雑な発想ですw 毎度のお話な気もするのですが。 「ここクラックできるんぢゃね?」とかあったらコメント等にて突っ込みをいただければ、速やかに修正を入れます ノ さて「PHPで、動的にSQL文を組む必要があるとき」って例えばどんな? ってのがあるのですが。 割と端的には「(複数の入力項目がある)検索系のフォーム」。 「なにか入力されていたらその項目を検索用に使う」「なにも入力されてなかったらその項目は検索用に使わない」ってのは、多分、業務的には「ちょいちょいあって」かつ「ある程度、動的に対
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
エグゼクティブサマリ 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に入ってくる値を検証することです。 外というと主に$_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:
WEBサイトの脆弱性を狙った攻撃手法は数多くありますが、その中でもSQLインジェクションはサイト乗っ取りや情報流出の可能性がある致命的な攻撃です。 そこでSQLインジェクションに特化した脆弱性チェックツール「Havij」を使ってその恐ろしさを体感してみたので、手順と結果をご紹介します。 脆弱性チェックツール「Havij Advanced SQL Injection」とは IT Security Teamというチームによってリリースされている脆弱性チェックツールです。SQLインジェクションのチェックに特化しており、数多くのデータベースに対応しています。対応しているデータベース製品の一例は以下の通りです。 MySQL PostgreSQL Microsoft SQL Server Oracle Microsoft Access Sybase (ASE) 本来は自サイトのセキュリティを向上させる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く