とある診断員とSQLインジェクション
7. 通常のWebサーバとの通信 <html> <body> <form action=“register” method=“POST”> 氏名:vultest<BR> メールアドレス:vultest@example.jp<BR> 性別:男<BR> （以下略） </html> POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name=vultest&mail=vultest%40example.jp&gender=1 HTTP Response HTTP Request 8. 色々いじってみてどういう応答があるか確認 POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
Facebookが何千台ものMySQLを人手を使わず自律管理する仕組み「MySQL Pool Scanner（MPS）」
おそらく世界でもっとも大規模にMySQLのクラスタを展開し、運用しているのがFacebookでしょう。複数のデータセンターにまたがり何千台ものMySQLサーバを運用するために、自動化の仕組みは欠かせません。 その自動化がどのような仕組みになっているのか。FacebookのデータベースエンジニアであるShlomo Priymak氏が、Under the hood: MySQL Pool Scanner (MPS)という記事をFacebookで公開しています。 かなり長い記事なので、ここではそのポイントをまとめて解説してみました。詳細はぜひ原文をあたってみてください。 MPSのおもな3つの機能 Facebookで稼働しているMySQLは、つねに1つのマスターとそこからレプリケーションされた複数のスレーブによるレプリカセットを構成しています。このレプリカセットの構造を維持し続けることで、可用性と
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
MySQL 5.6正式リリース！！ #mysql56
待望のMySQL 5.6が正式にリリースされた。正式版の最初のバージョンは5.6.10である。コミュニティ版（MySQL Community Server）は下記のページからダウンロードできるので、ぜひ今すぐダウンロードして頂きたい。 MySQL Downloads MySQL 5.6のリリースにあわせて、GUIツールであるMySQL Workbenchやドライバも新しいバージョンがリリースされており、MySQL 5.6対応となっている。それらの周辺ソフトウェアもチェックして頂けると幸いである。 新機能について正式版の機能はリリース候補版の頃から特に変更はない。（リリース候補版まで到達したということは、正式版の機能セットは固まったということであり、大きな機能の変更はないことを意味するからだ。）なので新機能については、リリース候補版が出たときに書いたエントリを参照して頂きたい。 漢(オトコ)
O/R Mapper におけるページャーの実装について - tokuhirom's blog
欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
InnoDBの意外な制約: Got error 139 from storage engine | へびにっき
環境: MySQL 5.0 （マニュアルを見る限りバージョン5.1でも事情は同じ） 某CMSにて、1つのテーブルにTEXT型のフィールドをたくさん作ったところ、次のようなエラーが出てデータを保存できなくなった。 Got error 139 from storage engine このエラーメッセージで検索すればいろいろと情報が出てくるが、こういうことらしい： InnoDBの行サイズの上限はページサイズの約半分で、デフォルトでは約8000バイト 可変長カラム(VARBINARY, VARCHAR, BLOB, TEXT)のデータは行の外部に保存されるが、先頭の768バイトだけは行の内部に保存される よって例えば一つのテーブルに11個のTEXT型フィールドを作り、それぞれに768バイト以上のデータを入れようとすると、768*11=8448 > 8000 なので保存できない ページサイズは8〜6
Spider DeNA Technology Seminar #2
12. テーブルリンク Spider Storage Create table tbl_a ( tbl_a tbl_a col_a int, Engine’s table col_b int, primary key(col_a) DB1 ) engine = Spider Other Storage Connection ‘ 2.Get data tbl_a host “DB1”, Engine’s table table “tbl_a”, user “user”, password “pass” ‘; tbl_a tbl_b Local DB 3.Join 1.Request select tbl_a.col_a, tbl_b.col_c 4.Response from tbl_a, tbl_b where tbl_a.col_a = 1 and tbl_a.col_b = tbl_b
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
MySQLパフォーマンスチューニングのためのクエリの基礎知識 - プログラマーkkの勉強/成長ブログ@ライブレボリューション(モバイル広告代理店)
前回書いたMySQLパフォーマンスチューニングのためのインデックスの基礎知識に引き続き、MySQLのパフォーマンスチューニングについて学んだことをまとめ。 MySQLを使っていると、クエリが遅い理由をつきとめる必要が出てくる。 どうやって遅いクエリをつきとめ、改善すればよいかについて学んだのでまとめた。 下記のような基礎知識があればパフォーマンスチューニングをうまくやれる、と思う。 クエリ処理の基礎 MySQLがクエリを処理する手順 まずはMySQLがクエリを処理する手順を知っておく必要がある。 処理は以下のような流れで進む。 クエリキャッシュの中からクエリの結果を探す。見つかればそれを返す。 クエリを解析して構成要素に分解する。 クエリの構文が正しいことを確認 クエリについて基本情報を収集する。 クエリを基本的な要素に分解した後、何を実行すべきかを判断する。 クエリオプティマイザが動き始
libmysqlclientを使うプログラムはset namesをutf8であっても使ってはいけない | へぼい日記
mysql_enable_utf8 => 1 で DBIC::UTF8Columns 要らなくなるっぽいComments 上記の記事のブクマに set namesを直接実行しちゃうのはutf8であってもコンパイルオプションによっては問題起こるのでお勧めできない http://b.hatena.ne.jp/nihen/20090204#bookmark-11950629 ってことを書かせてもらったんだけど、この最後のset namesはutf8でも使っちゃダメという話を軽く説明します。 まずは、基本的なことはMySQL5開拓団 – 日本語処理の鉄則 / KLab株式会社を読んでください。mysqlの日本語処理についてのドキュメントとしては、私は今一番信頼できるドキュメントだと思っています。 さて、上記のページの< 図3：クライアント側文字コードの指定チャート>を、勝手ながらすべて引用させてい
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
zeroDateTimeBehavior - garbagetown
MySQL で Date 型や Timestamp 型の列を定義している場合、この列の値が null の時に jdbc でアクセスすると SQLException が飛んできます。 java.sql.SQLException: Cannot convert value '0000-00-00 00:00:00' from column 11 to TIMESTAMP. com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055) com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) com.mysql.jdbc.ResultSetRow
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL | GREE Engineering
https://blogs.oracle.com/takemura/entry/mysql_statement_based_replication%E3%81%A7%E3%81%AE%E5%AE%89%E5%85%A8%E3%81%AA%E9%96%A2%E6%95%B0
大規模ソーシャルゲーム開発から学んだPHP＆MySQL実践テクニック
Loading...