<body> <span>このページはフレーム対応のブラウザでご覧ください。</span> </body>
<body> <span>このページはフレーム対応のブラウザでご覧ください。</span> </body>
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間(例えば5秒)スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
問題 MySQLの巨大なダンプファイルから、ごく一部を抜き出したい。 うまく途中だけ抽出したり、ファイルを分割する方法は? 答え ファイルの大きさによって対応を変えるとよい。 ファイルサイズがほどほどの場合 巨大すぎなければ、以下で分割できる。 csplit ダンプファイル.dump '/DROP TABLE IF EXISTS/' {*} ファイルが大きい場合 行数を調べて分割する場合は、「– Current Database:」のようなダンプファイルによくある表現で検索して、 egrep -n '^-- Current Database:' mysql_2014-11-18.dmp …… 401237:-- Current Database: `aaaa` 414577:-- Current Database: `bbbb` 425362:-- Current Database: `c
メリークリスマス!!やあ、良い子のみんな!!サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ!! というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID(Global Transaction ID)である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
MySQLのinteractive_timeout(アイドルタイムアウトのようなもの) MySQLの設定でinteractive_timeoutという項目があり、これがディフォルトでは8時間に設定されているようだ。 よって8時間連続で、クエリ等を発行しなければコネクションは自動的に切断されてしまうのだ。 しかし、この設定を無効にする方法が存在しない。0を指定しても無駄である。 最大値は31536000秒(= 365日)なので、これを指定するか。 また、interactive_timeoutと同時にwait_timeoutも設定しておく必要があるよう。 interactive_timeoutとwait_timeoutの値のうち、 小さい値のほうの時間アクセスが無いとコネクションが自動的に切断されるようだ。 結局のところ、my.iniに以下のように追記することで自動切断時間を延ばせる。 [my
KeepAlivedのコネクションタイムアウトと、MySQLのコネクションタイムアウトが気になったのですこし調べてみました。結果的に調べておいて良かった・・と思う内容だと個人的には思っているのですが・・・どうでしょうか? * 無通信時のコネクションプーリングのタイムアウト時間のデフォルトは、interactive_timeoutで確認できます。ちなみに、MySQL 28800秒なので8時間です。 mysql> show variables like '%timeout%'; +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | interactive_timeout | 28800 | | wait_timeout
重い集計SQLなんかを実行したけど、いつまでたっても帰ってこない時の対処についてです。 まずは、topコマンドで確認します。大抵、以下の例のように、mysqldがリソースを使い切っています。 [root]# top top - 16:20:17 up 15 days, 6:50, 1 user, load average: 5.39, 5.14, 5.04 Tasks: 177 total, 2 running, 175 sleeping, 0 stopped, 0 zombie Cpu(s): 33.7%us, 66.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st Mem: 1048752k total, 826136k used, 222616k free, 194584k buffers Swap: 562264k total
[mysqld] slow_query_log = 1 #スロークエリログ出力有効化 slow_query_log_file = mysql-slow.log #スロークエリログファイル名 long_query_time = 2 #スロークエリとして認識させる時間[秒] log-long-format #インデックスを使用していないクエリをログに残す 上記の設定は[mysqld]のところに書かなければ正しく変数名を解決してくれないので注意。 slow_query_logはONではなく1としなければスロークエリログ出力が有効化されないので注意。 slow_query_log_fileの場所はfind パス名 -name mysql-slow.logで検索すればわかる。 → /var/lib/mysql/mysql-slow.logに生成された。 long_query_timeで設定した秒数以
<< トップページへ << 目次へ 更新日:2013.4.29 小技集・豆知識 日付データへの変換 MySQLで「日付」の操作を行うことがよくあります。例えば、顧客の購買履歴のデータから「基準日からの直近購買日までの日数」などを計算することがあります。MySQLには以下に示す4つのデータ型が用意されています。 DATE型 ・・・ YYYY-MM-DD DATETIME型 ・・・ YYYY-MM-DD HH:MI:SS TIMESTAMP型 ・・・ YYYY-MM-DD HH:MI:SS TIME型 ・・・ HHH:MI:SS データマイニング業務において、実質的に取り扱うことが多いのは「DATE型」のみといってもよいでしょう。データとしてDATETIME型として保持しているケースもありますが、時間単位(HH:MI:SS)でデータを保持していても、使用するのはほぼ日付単位(YYY-MM-DD
プログラミング言語や環境設定を中心としたパソコン関連の技術メモです。 主にシステム開発中に調べたことをメモしています。TIPS的な位置付けで、気が向いたときにちまちま更新していきます。
タイトル通りのことがやりたかったので、調べてみて以下のようなSQLを作った。 UPDATE TABLE1 T1 SET ( T1.VAL1 ,T1.VAL2 ,T1.VAL3 ) = ( SELECT T2.VAL1 ,T2.VAL2 ,T2.VAL3 FROM TABLE2 T2 WHERE T1.ID = T2.ID ); でも、動かない。。。 さらに調べてみると、MYSQLの場合は以下のようにするみたい。 UPDATE TABLE1 T1 ,TABLE2 T2 SET T1.VAL1 = T2.VAL1 ,T1.VAL2 = T2.VAL2 ,T1.VAL3 = T2.VAL3 WHERE T1.ID = T2.ID; 知らなかった。
MySQLでは以下のようなクエリーでカラムを追加することができる。 ALTER TABLE <テーブル名> ADD <カラム名> <型情報>; ALTER TABLE test ADD name varchar(255); ALTER TABLE test ADD num int unsigned; ALTER TABLE sample ADD address varchar(1023) NOT NULL; また、以下のようにカラムを追加する位置を指定することもできる。 ALTER TABLE <テーブル名> ADD <カラム名> <型情報> AFTER <カラム名>; ALTER TABLE <テーブル名> ADD <カラム名> <型情報> FIRST; ALTER TABLE test ADD comment text AFTER name; ALTER TABLE test ADD
MySQLで「tinyint(1)」を設定すると 「tinyint(1)」は「0」と「1」に変わる CakePHPのプログラムを作っていて、登録された値が想定していた値にならず困っていました。 まだまだ CakePHPの初心者の私はプログラムの記述が間違ってるのだとさんざん悩んでいました。 登録する項目は下記の「authority」の項目に「1:システム管理者」「2:マネージャー」「3:オペレーター」「4:一般ユーザ」といった 4種類の権限を保存するというものでした。 ———————— CREATE TABLE IF NOT EXISTS users ( : : authority tinyint(1) NOT NULL DEFAULT ‘1’, : : ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=0 ; ———————— 何度も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く